From hallam@gmail.com Sat Oct 1 07:28:00 2011 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 C198E21F9698 for ; Sat, 1 Oct 2011 07:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.483 X-Spam-Level: X-Spam-Status: No, score=-3.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, 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 1GUCYOGo1mVT for ; Sat, 1 Oct 2011 07:28:00 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 128D221F9697 for ; Sat, 1 Oct 2011 07:27:59 -0700 (PDT) Received: by yxt33 with SMTP id 33so2950357yxt.31 for ; Sat, 01 Oct 2011 07:30:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Ecrz5DuUDrIkpt00stGOnrPi8D4KmFUd/vazcadKWEY=; b=qeYmVyA6H7T7l4T34iDzsL86jgPU3KP1SfJyuLwkEU9ech0+Aw37W5YAluKKbpyjYn 87tvb/vjTl3dtDHKVVt/3vYKCcJKdZ1NeCJw7DY4DEyC1sCc6NlKPdpwt0WnWb7A0KNz c7VW2a6zNd82gT1iYzSCCW7XF802EkzFnUzaY= MIME-Version: 1.0 Received: by 10.101.218.6 with SMTP id v6mr11470718anq.140.1317479456758; Sat, 01 Oct 2011 07:30:56 -0700 (PDT) Received: by 10.100.212.14 with HTTP; Sat, 1 Oct 2011 07:30:56 -0700 (PDT) In-Reply-To: References: <20110508004502.3883.40670.idtracker@ietfa.amsl.com> <4E7DB8E4.9040208@gmx.de> <4E83AA99.6080308@gondrom.org> <4E83BF67.3040207@it.aoyama.ac.jp> <4E86A1B0.3090601@it.aoyama.ac.jp> Date: Sat, 1 Oct 2011 10:30:56 -0400 Message-ID: From: Phillip Hallam-Baker To: Adam Barth Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: websec@ietf.org Subject: Re: [websec] I-D Action:draft-ietf-websec-mime-sniff-03.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, 01 Oct 2011 14:28:00 -0000 On Sat, Oct 1, 2011 at 2:47 AM, Adam Barth wrote: > On Fri, Sep 30, 2011 at 10:14 PM, "Martin J. D=FCrst" > wrote: >> On 2011/09/29 11:45, Adam Barth wrote: >>> On Wed, Sep 28, 2011 at 5:44 PM, "Martin J. D=FCrst" >>> =A0wrote: >>>> >>>> On 2011/09/29 8:26, Adam Barth wrote: >>>>> >>>>> As I recall, the nosniff directive is pretty controversial. >>>> >>>> But then, as I recall, the whole business of sniffing is pretty >>>> controversial to start with. Are there differences between the >>>> controversiality of sniffing as such and the controversiality of the >>>> nosniff >>>> directive that explain why one is in the draft and the other is not? >>> >>> The reason why one is in and the other isn't is just historical. >>> nosniff didn't exist at the time the document was originally written. >> >> Your first answer sounded as if the nosniff directive was too controvers= ial >> to be included in any draft, but your second answer seems to suggest tha= t it >> was left out by (historical) accident, and that it might be worth to inc= lude >> it. > > The essential question isn't whether we should include it in the > draft. =A0The essential question is whether folks want to implement it. > If no one wants to implement it, putting it in the draft is a > negative. =A0If folks want to implement, then we can deal with the > controversy. +1 The controversy seems to be of the 'cut off nose to spite face' variety. Sniffing is definitely terrible from a security perspective but people do it. Java and Java Script were terrible as well but people did them and then left the rest of us with a mess that had to be fixed slowly over then next ten years. Sure this is not something we should have to think about but the fact is that the browsers do it and it is better for the standards to describe what the browsers actually do than what people think they should do. --=20 Website: http://hallambaker.com/ From ryan-ietfhasmat@sleevi.com Sun Oct 2 03:40:05 2011 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 04F2021F8E51 for ; Sun, 2 Oct 2011 03:40:05 -0700 (PDT) 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 2ShnMxu5bUYm for ; Sun, 2 Oct 2011 03:40:04 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1A821F8E4B for ; Sun, 2 Oct 2011 03:40:04 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id 6F8FF2F4059 for ; Sun, 2 Oct 2011 03:43:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sleevi.com; h=message-id:date :subject:from:to:reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=sleevi.com; b=cLcVi4kGGn9Cr2 7ESEOR0Zjx99ylWqj8k9/oHCoY6pdDU+fk+i6FmeWAu13rqw6HoX9pXywCVQgzxX 3MCeE9xl50k4sUQ/s6wOClP06dPcqcOEk06Qzw2AIbmhCqODT3xkY1oE9LzQKefd By7Fd0ZeqYC0kbYy4XA2bOGaS90Z0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :date:subject:from:to:reply-to:mime-version:content-type: content-transfer-encoding; s=sleevi.com; bh=ss4bXY+DNS3hOb/UA5Kh 8oMgrG8=; b=KlzRPNvRtY2Tap2psUOU8qnw1pmN9dKWkVDSa5GteKwsa/EskpHe ELoyoYKKHqjy9JOXWg26XAWK9s4rAVckoURqlQnKu8aRBFFrj9oOXukwxam2vh+8 eSPOW3q4qrY4TBQ0pnqLN4na4QkFzEi6GqgPLgoF/TI11aUr3faehr8= Received: from webmail.sleevi.com (ahfbbjcaiaae.dreamhost.com [75.119.208.4]) (Authenticated sender: ryan@sleevi.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPA id 637682F401C for ; Sun, 2 Oct 2011 03:43:03 -0700 (PDT) Received: from 72.189.105.152 (proxying for 72.189.105.152) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.sleevi.com with HTTP; Sun, 2 Oct 2011 06:43:03 -0400 Message-ID: Date: Sun, 2 Oct 2011 06:43:03 -0400 From: "Ryan Sleevi" To: websec@ietf.org User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [websec] Strict-Transport-Security syntax redux X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ryan-ietfhasmat@sleevi.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Oct 2011 10:40:05 -0000 Following Julian Reschke's questions, I also had a few questions related to the draft-02 syntax. I've been basing my understanding on RFC 5234, which I understand to be the most current/relevant to understanding the syntax. First, maxAge and includeSubDomains both include value extension points, defined as: maxAge =3D "max-age" OWS "=3D" OWS delta-seconds [ OWS v-ext ] includeSubDomains =3D "includeSubDomains" [ OWS v-ext ] v-ext =3D value ; STS extension value However, the rule for OWS is specified as: OWS =3D *( [ CRLF ] WSP ) As written, it would seem that the OWS between either delta-seconds or "includeSubDomains" can legitimately be omitted before the v-ext. As best I can tell, this would mean that the following values would still be valid: max-age=3D123.456 includeSubDomainsabc In the first case ".456" is the v-ext, while in the second, "abc" is. In both cases, because the OWS is truly optional (valid to have 0 occurrences), only the v-ext is present. For maxAge in particular, this can lead to very silly parsing interpretations. Considering the following value: max-age=3D123 If I'm not mistaken, ABNF doesn't specify any sort of greedy matching, so this could be interpreted as: delta-seconds =3D 1 (1DIGIT), v-ext =3D 23 (0OWS 2tchar) delta-seconds =3D 12 (2DIGIT), v-ext =3D 3 (0OWS 1tchar) To remedy this, I believe some form of explicit delimiter between the existing values and the v-ext should be defined for the existing headers. If the intent was to have extension values whitespace separated, then would the following modification to introduce required whitespace solve it? maxAge =3D "max-age" OWS "=3D" OWS delta-seconds [ RWS v-ext ] includeSubDomains =3D "includeSubDomains" [ RWS v-ext ] v-ext =3D value ; STS extension value OWS =3D *( [ CRLF ] WSP ) RWS =3D 1*( [ CRLF ] WSP ) Alternatively, can/should the v-ext be dropped entirely, and extensions t= o the STS header be accomplished via defining a new STS-d-ext? Second, as currently specified, extension directives take the form of: STS-d =3D STS-d-cur / STS-d-ext STS-d-ext =3D name ; STS extension directive name =3D token token =3D 1*tchar tchar =3D "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA As currently written, STS-d-ext doesn't seem to be able to contain name "=3D" value pairs such as those used by Evans' and Palmer's pinning draft= , because "=3D" is not a valid token character. Likewise, it wouldn't be ab= le to contain "#rule" style lists, because comma is not a valid tchar. Should STS-d-ext be defined as "value" instead, so that it contain a wide= r range of characters? Alternatively, if the intent for STS-d-ext was that it would always include some name, should it be defined as "name [ OWS "=3D= " OWS value ]"? Either way seems to offer a solution. It seems that if a parser were written based on the current draft, it would be correct/valid to reject a= n STS header that included cert pins, as specified in the current pinning draft. This would be because the cert pinning draft makes use of "=3D" within the extension definitions, which is not a legal character for an STS-d-ext in the base spec. Best regards, Ryan From tobias.gondrom@gondrom.org Sun Oct 2 14:40:48 2011 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 3F13121F8560 for ; Sun, 2 Oct 2011 14:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.53 X-Spam-Level: X-Spam-Status: No, score=-96.53 tagged_above=-999 required=5 tests=[AWL=0.248, 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 9m0hAUSQ7RgS for ; Sun, 2 Oct 2011 14:40:47 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0F521F851F for ; Sun, 2 Oct 2011 14:40:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=WWGnCWBpRRvyt/IuTcP1y5zS2bgL6b0CU6ZJHIYM1y5dZasYFaeHxCQYatP7bmXjL1JStbre+QoUc5U35i1p35Q4kumbOvOK7qTkee0QP0nd0Dma4wuUKHPJjIvyP0dn; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:X-Priority:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 17759 invoked from network); 2 Oct 2011 23:43:45 +0200 Received: from 94-194-102-93.zone8.bethere.co.uk (HELO ?192.168.1.65?) (94.194.102.93) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 2 Oct 2011 23:43:45 +0200 Message-ID: <4E88DB11.2010409@gondrom.org> Date: Sun, 02 Oct 2011 22:43:45 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110923 Thunderbird/7.0 MIME-Version: 1.0 To: hallam@gmail.com X-Priority: 4 (Low) References: <20110508004502.3883.40670.idtracker@ietfa.amsl.com> <4E7DB8E4.9040208@gmx.de> <4E83AA99.6080308@gondrom.org> <4E83BF67.3040207@it.aoyama.ac.jp> <4E86A1B0.3090601@it.aoyama.ac.jp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: websec@ietf.org Subject: Re: [websec] I-D Action:draft-ietf-websec-mime-sniff-03.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: Sun, 02 Oct 2011 21:40:48 -0000 Whether browser will implement it, can't tell. Maybe we can learn more when we progress further with the mime-sniff draft. I don't have a strong opinion on the nosniff header. Depending on where the mime-sniff debate will lead us, it might be a way to mitigate concerns that in certain cases you really SHOULD NOT or MUST NOT (RFC2119) sniff. Well and with such a header you could enforce exactly that for your sources, without breaking other unknown things/sites - which is the main reason for many browser vendors to start do sniffing in the first place. (in one way nosniff could even be a migration path to less sniffing....) Best regards, Tobias On 01/10/11 15:30, Phillip Hallam-Baker wrote: > On Sat, Oct 1, 2011 at 2:47 AM, Adam Barth wrote: >> On Fri, Sep 30, 2011 at 10:14 PM, "Martin J. Dürst" >> wrote: >>> On 2011/09/29 11:45, Adam Barth wrote: >>>> On Wed, Sep 28, 2011 at 5:44 PM, "Martin J. Dürst" >>>> wrote: >>>>> On 2011/09/29 8:26, Adam Barth wrote: >>>>>> As I recall, the nosniff directive is pretty controversial. >>>>> But then, as I recall, the whole business of sniffing is pretty >>>>> controversial to start with. Are there differences between the >>>>> controversiality of sniffing as such and the controversiality of the >>>>> nosniff >>>>> directive that explain why one is in the draft and the other is not? >>>> The reason why one is in and the other isn't is just historical. >>>> nosniff didn't exist at the time the document was originally written. >>> Your first answer sounded as if the nosniff directive was too controversial >>> to be included in any draft, but your second answer seems to suggest that it >>> was left out by (historical) accident, and that it might be worth to include >>> it. >> The essential question isn't whether we should include it in the >> draft. The essential question is whether folks want to implement it. >> If no one wants to implement it, putting it in the draft is a >> negative. If folks want to implement, then we can deal with the >> controversy. > +1 > > The controversy seems to be of the 'cut off nose to spite face' > variety. Sniffing is definitely terrible from a security perspective > but people do it. Java and Java Script were terrible as well but > people did them and then left the rest of us with a mess that had to > be fixed slowly over then next ten years. > > Sure this is not something we should have to think about but the fact > is that the browsers do it and it is better for the standards to > describe what the browsers actually do than what people think they > should do. > > From derhoermi@gmx.net Sun Oct 2 14:59:44 2011 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 D279621F8541 for ; Sun, 2 Oct 2011 14:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=-2.243, BAYES_40=-0.185] 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 cEMx2jJDEXAt for ; Sun, 2 Oct 2011 14:59:44 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 821DC21F84B2 for ; Sun, 2 Oct 2011 14:59:43 -0700 (PDT) Received: (qmail invoked by alias); 02 Oct 2011 22:02:42 -0000 Received: from dslb-094-222-152-232.pools.arcor-ip.net (EHLO HIVE) [94.222.152.232] by mail.gmx.net (mp006) with SMTP; 03 Oct 2011 00:02:42 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX19n3MJOyaZn1OXq6A7V8Llx8nIqCGX1KTFufsB8Zd bOoh8ILdwk7J7t From: Bjoern Hoehrmann To: Tobias Gondrom Date: Mon, 03 Oct 2011 00:02:46 +0200 Message-ID: References: <4E7DB8E4.9040208@gmx.de> <4E83AA99.6080308@gondrom.org> <4E83BF67.3040207@it.aoyama.ac.jp> <4E86A1B0.3090601@it.aoyama.ac.jp> <4E88DB11.2010409@gondrom.org> In-Reply-To: <4E88DB11.2010409@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] I-D Action:draft-ietf-websec-mime-sniff-03.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: Sun, 02 Oct 2011 21:59:44 -0000 * Tobias Gondrom wrote: > >Whether browser will implement it, can't tell. Maybe we can learn more >when we progress further with the mime-sniff draft. Per http://www.browserscope.org/?category=security it's already in IE and "Chrome", should Mozilla decide to support it, it's a "standard". -- 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 Oct 2 15:11:46 2011 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 E38EB21F8586 for ; Sun, 2 Oct 2011 15:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.046 X-Spam-Level: X-Spam-Status: No, score=-3.046 tagged_above=-999 required=5 tests=[AWL=-0.069, 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 CQEryP0h8gYS for ; Sun, 2 Oct 2011 15:11:46 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id CA6A421F8560 for ; Sun, 2 Oct 2011 15:11:40 -0700 (PDT) Received: by iaby26 with SMTP id y26so5423484iab.31 for ; Sun, 02 Oct 2011 15:14:41 -0700 (PDT) Received: by 10.42.18.198 with SMTP id y6mr6533159ica.189.1317593679036; Sun, 02 Oct 2011 15:14:39 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id eh34sm22545478ibb.5.2011.10.02.15.14.36 (version=SSLv3 cipher=OTHER); Sun, 02 Oct 2011 15:14:37 -0700 (PDT) Received: by iaby26 with SMTP id y26so5423382iab.31 for ; Sun, 02 Oct 2011 15:14:36 -0700 (PDT) Received: by 10.231.63.209 with SMTP id c17mr1680335ibi.65.1317593676193; Sun, 02 Oct 2011 15:14:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.200.203 with HTTP; Sun, 2 Oct 2011 15:14:06 -0700 (PDT) In-Reply-To: <4E7C3547.5070405@gmx.de> References: <20110922223352.30413.93196.idtracker@ietfa.amsl.com> <4E7C3547.5070405@gmx.de> From: Adam Barth Date: Sun, 2 Oct 2011 15:14:06 -0700 Message-ID: To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: websec@ietf.org Subject: Re: [websec] I-D Action: draft-ietf-websec-origin-05.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: Sun, 02 Oct 2011 22:11:47 -0000 On Fri, Sep 23, 2011 at 12:29 AM, Julian Reschke wr= ote: > On 2011-09-23 00:33, internet-drafts@ietf.org wrote: >> >> 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. >> ... > > Nits...: > >> =A0 The OWS (optional whitespace) rule is used where zero or more linear >> =A0 whitespace characters MAY appear: >> >> =A0 OWS =A0 =A0 =A0 =A0 =A0 =A0=3D *( [ obs-fold ] WSP ) >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0; "optional" whitespace >> =A0 obs-fold =A0 =A0 =A0 =3D CRLF > > We changed the definition of OWS nin HTTPbis: > Updated. >> =A0 1. =A0If the URI does not use a hierarchical element as a naming >> =A0 =A0 =A0 authority (see [RFC3986], Section 3.2), or if the URI is not= an >> =A0 =A0 =A0 absolute URI, then generate a fresh globally unique identifi= er >> =A0 =A0 =A0 and return that value. >> >> =A0 =A0 =A0 1. =A0NOTE: Running this algorithm multiple times for the sa= me URI >> =A0 =A0 =A0 =A0 =A0 can produce different values each time. =A0Typically= , user >> =A0 =A0 =A0 =A0 =A0 agents compute the origin of, for example, an HTML d= ocument >> =A0 =A0 =A0 =A0 =A0 once and use that origin for subsequent security che= cks >> =A0 =A0 =A0 =A0 =A0 rather than recomputing the origin for each security= check. > > It seems the NOTE shouldn't be in a numbered list (same for item 4). Fixed. >> 7.1. Syntax >> >> >> =A0 The Origin header field has the following syntax: >> >> >> =A0origin =A0 =A0 =A0 =A0 =A0 =A0 =A0=3D "Origin:" OWS origin-list-or-nu= ll OWS >> =A0origin-list-or-null =3D "null" / origin-list >> =A0origin-list =A0 =A0 =A0 =A0 =3D serialized-origin *( SP serialized-or= igin ) >> =A0serialized-origin =A0 =3D scheme "://" host [ ":" port ] >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ; , , produ= ctions from RFC3986 > > a) Reformat do it doesn't need to be outdented Done. > b) "null" in ABNF means case-insensitive; consider replacing with octet > sequence and putting the literal "null" into a comment. Done. > References: may need updates, such as WEBSOCKETS. Also consider sorting t= hem > (xml2rfc sortrefs PI). I've updated WEBSOCKETS. It will probably need to be updated again. Thanks! Adam From tobias.gondrom@gondrom.org Sun Oct 2 15:22:55 2011 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 A6F6521F8515 for ; Sun, 2 Oct 2011 15:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.54 X-Spam-Level: X-Spam-Status: No, score=-96.54 tagged_above=-999 required=5 tests=[AWL=0.238, 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 pgzXBUz8RMZu for ; Sun, 2 Oct 2011 15:22:54 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2C221F849E for ; Sun, 2 Oct 2011 15:22:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=hsqQ1lDhdNl5/uRHQn2NsiHfQTb1feekiX5/JGB9ylh/mD4b7kWEcLR+DeuD3xupEk+T/VG1ok9IG9KJhkNCKhSJhMxSeiBht3LBFT4mraoEoBapRjz9VNZVYc+CNEsU; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:X-Priority:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 17949 invoked from network); 3 Oct 2011 00:25:22 +0200 Received: from 94-194-102-93.zone8.bethere.co.uk (HELO ?192.168.1.65?) (94.194.102.93) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 3 Oct 2011 00:25:22 +0200 Message-ID: <4E88E4D1.4020404@gondrom.org> Date: Sun, 02 Oct 2011 23:25:21 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110923 Thunderbird/7.0 MIME-Version: 1.0 To: websec@ietf.org X-Priority: 4 (Low) References: <7bd9badd19e0e9296750117013a93aa0.squirrel@webmail.scss.tcd.ie> <7bb25df9c583e9553d4cf6b7b2c4d98c.squirrel@webmail.scss.tcd.ie> In-Reply-To: <7bb25df9c583e9553d4cf6b7b2c4d98c.squirrel@webmail.scss.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [websec] Digest URI scheme 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, 02 Oct 2011 22:22:55 -0000 Hi guys, a big +1 for the "do it once". ;-) Whether DECADE or WEBSEC - think that is something we can sort out in Taipei or shortly afterwards. As we already have several ideas on that, it seems interesting enough to discuss at the websec meeting in Taipei? Any volunteers for a short presentation/discussion slot on this bit? (if yes, please drop a quick email to Alexey, Yoav and me so we can adjust the agenda...) Kind regards, Tobias On 30/09/11 15:40, stephen.farrell@cs.tcd.ie wrote: > Hiya, > >> Come to think of it, didn't you send this to us when we first proposed >> the ODI thing in CAA v1.0? > Could be. When my little brain sees a good idea, it tends to repeat > it:-) > >> I really don't care about the specifics of the design half so much as >> we end up with having one, not three. > Strongly agree. I think a URI for naming things with digests should > have broad applicability. > >> Only real issue for me is that it has to fit in URI type slots. The >> scheme I was thinking of would be a pure URN scheme, your proposal >> includes URL like things. > Yep. We have use-cases for that. Note though that the authority > part is optional, so a fairly bare digest is quite possible and > would look like ni:///sha256:NDVmZTMzOGVkY2Jj... > >> Clearly, your scheme is a better way to reference external content in >> a resolvable format. I have to go look at the URN and URI specs again >> in detail. > I also thought about URNs but was told (by PSA I think) that those > are intended for managed name spaces and not things like this. > >> I note that you have a content type, which I have but someone here was >> objecting to. I consider the content type to be essential meta-data >> for obvious security reasons. > Our use-case for that is for cases where the named object actually > arrives in some wrapped form (e.g. encrypted) and you need to know > the "inner" content type. However, I could see it being used otherwise > or being dropped as things progress. > >> You want to share your design issue here or should we go offline, rev >> the proposal and come back? > I'm not bothered by where or how we progress this, so long as we do > the right thing and do it once:-) > > I need to check with co-authors about what DECADE want, but this I-D > could be worked there or here in WEBSEC. I'm very happy to have more > help as well if it gets us closer to doing this once only. > > FWIW, we're part of a project that is coding this up, and will > almost certainly release a library with a reasonable license in a > few months. > > Cheers, > S. > >> On Thu, Sep 29, 2011 at 6:00 PM, wrote: >>> >>> >>> I agree with the motivation but not the design. A while ago >>> I posted my idea for a design for this. [1] It may become a >>> work item for the DECADE WG, ... or not, we'll see. >>> >>> S. >>> >>> [1] http://tools.ietf.org/html/draft-farrell-ni-00 >>> >>> >>>> As I mentioned previously, the need to refer to a static data object >>>> by means of a digest comes up frequently. Rather than re-invent the >>>> mechanism for creating a reference each time we need one, it would be >>>> better if we had a single format that could be re-used. >>>> >>>> We used to have this back in the days when we trusted MD5 since we >>>> used that everywhere as a 'fingerprint'. Then things got muddy after >>>> the Dobertin attack and it became SHA1 and MD5. With SHA2 vs SHA3 it >>>> will be very muddy. >>>> >>>> This would be relevant to the cert pinning debate. >>>> >>>> >>>> I wrote a draft making the proposal: >>>> >>>> http://www.ietf.org/id/draft-hallambaker-digesturi-00.txt >>>> >>>> >>>> On the digest front the objective would be to make it possible to use >>>> the URI format with any digest at all in theory but strongly encourage >>>> people to only use the digests IETF is confident in. Use of OIDs as >>>> the identifier has the nice property that anyone can get an identifier >>>> to distinguish their algorithm from other people's but getting an OID >>>> does not produce any paper trail that can be used to imply an IETF >>>> endorsement. >>>> >>>> We could add in support for the text based identifiers as well, but >>>> since the only identifiers that I would want to encourage are SHA2 and >>>> SHA3, I don't see a need. For all applications that make sense it is >>>> going to be perfectly OK to simply generate the prefix for the >>>> identifier part as a static array of octets and append / verify it as >>>> such whenever it is needed. I do not see any need to write ASN.1 >>>> handling code for these apps :-) >>>> >>>> >>>> The basic idea here is that we need to allow for algorithm agility and >>>> to prevent a content substitution attack. So imagine that we have web >>>> page A linking to some off site static content via a digest. Site A >>>> regards the static content as a PNG and has checked out the page and >>>> it works fine. What they don't know is that buried in the PNG there is >>>> some malicious Jscript and if the content server delivers it as >>>> application/script the result will be a series of syntax errors (that >>>> are silently ignored because the app is stupid) and then it finds the >>>> malicious code... ooops. >>>> >>>> OK, so maybe not an attack that you find to be a worry in every >>>> circumstance, but it is definitely an attack vector we should address >>>> in a general purpose crypto building block. >>>> >>>> >>>> Having produced a static building block like this it is very easy to >>>> generate a fingerprint for a static data object in a cut and paste >>>> ready format. I don't need a separate tool to generate digest >>>> identifiers for WebSec vs other applications. In terms of ease of use >>>> we get back to what things were like when we used MD5 fingerprints. >>>> >>>> It is also quite easy to make use of truncated fingerprints should >>>> that be necessary. For example, to put on a business card. >>>> >>>> -- >>>> Website: http://hallambaker.com/ >>>> _______________________________________________ >>>> websec mailing list >>>> websec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/websec >>>> >>> >>> >> >> >> -- >> Website: http://hallambaker.com/ >> > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From duerst@it.aoyama.ac.jp Sun Oct 2 23:23:16 2011 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 A6D5A21F886A for ; Sun, 2 Oct 2011 23:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.745 X-Spam-Level: X-Spam-Status: No, score=-99.745 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, 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 6RdBcCBmY+nW for ; Sun, 2 Oct 2011 23:23:15 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3DD21F86A5 for ; Sun, 2 Oct 2011 23:23:15 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id p936QCbd005370 for ; Mon, 3 Oct 2011 15:26:12 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 6bf4_13e5_96a6223e_ed88_11e0_820b_001d096c5782; Mon, 03 Oct 2011 15:26:11 +0900 Received: from [IPv6:::1] ([133.2.210.1]:37550) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 3 Oct 2011 15:26:11 +0900 Message-ID: <4E895581.1070900@it.aoyama.ac.jp> Date: Mon, 03 Oct 2011 15:26:09 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Adam Barth References: <20110922223352.30413.93196.idtracker@ietfa.amsl.com> <4E7C3547.5070405@gmx.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: websec@ietf.org Subject: Re: [websec] I-D Action: draft-ietf-websec-origin-05.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: Mon, 03 Oct 2011 06:23:16 -0000 On 2011/10/03 7:14, Adam Barth wrote: > On Fri, Sep 23, 2011 at 12:29 AM, Julian Reschke wrote: >> References: may need updates, such as WEBSOCKETS. Also consider sorting them >> (xml2rfc sortrefs PI). > > I've updated WEBSOCKETS. It will probably need to be updated again. My policy in cases like this is: Whenever I update a draft, I check the references and update them if needed. However, the RFC editor is very good at getting these things right, so there's no need to produce a new draft just because another one as increased its number. Regards, Martin. From ietf@adambarth.com Sun Oct 2 23:31:03 2011 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 03E4121F889A for ; Sun, 2 Oct 2011 23:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.894 X-Spam-Level: X-Spam-Status: No, score=-2.894 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, 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 WJqJ98V+mIrp for ; Sun, 2 Oct 2011 23:31:02 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 64A4321F84CC for ; Sun, 2 Oct 2011 23:31:02 -0700 (PDT) Received: by iaby26 with SMTP id y26so5895427iab.31 for ; Sun, 02 Oct 2011 23:34:03 -0700 (PDT) Received: by 10.43.51.6 with SMTP id vg6mr7190035icb.193.1317623643855; Sun, 02 Oct 2011 23:34:03 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id v16sm27360082ibe.0.2011.10.02.23.34.01 (version=SSLv3 cipher=OTHER); Sun, 02 Oct 2011 23:34:02 -0700 (PDT) Received: by iaby26 with SMTP id y26so5895382iab.31 for ; Sun, 02 Oct 2011 23:34:01 -0700 (PDT) Received: by 10.231.0.140 with SMTP id 12mr15373949ibb.98.1317623641090; Sun, 02 Oct 2011 23:34:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.200.203 with HTTP; Sun, 2 Oct 2011 23:33:31 -0700 (PDT) In-Reply-To: <4E895581.1070900@it.aoyama.ac.jp> References: <20110922223352.30413.93196.idtracker@ietfa.amsl.com> <4E7C3547.5070405@gmx.de> <4E895581.1070900@it.aoyama.ac.jp> From: Adam Barth Date: Sun, 2 Oct 2011 23:33:31 -0700 Message-ID: To: =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: websec@ietf.org Subject: Re: [websec] I-D Action: draft-ietf-websec-origin-05.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: Mon, 03 Oct 2011 06:31:03 -0000 On Sun, Oct 2, 2011 at 11:26 PM, "Martin J. D=FCrst" wrote: > On 2011/10/03 7:14, Adam Barth wrote: >> >> On Fri, Sep 23, 2011 at 12:29 AM, Julian Reschke >> =A0wrote: > >>> References: may need updates, such as WEBSOCKETS. Also consider sorting >>> them >>> (xml2rfc sortrefs PI). >> >> I've updated WEBSOCKETS. =A0It will probably need to be updated again. > > My policy in cases like this is: Whenever I update a draft, I check the > references and update them if needed. > > However, the RFC editor is very good at getting these things right, so > there's no need to produce a new draft just because another one as increa= sed > its number. Thanks. That's useful to know. Adam From duerst@it.aoyama.ac.jp Mon Oct 3 00:26:40 2011 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 2950B21F8ABE for ; Mon, 3 Oct 2011 00:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.746 X-Spam-Level: X-Spam-Status: No, score=-99.746 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, 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 nijOB4CweFlG for ; Mon, 3 Oct 2011 00:26:39 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 5E25321F8AD6 for ; Mon, 3 Oct 2011 00:26:38 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id p937TOGE023718 for ; Mon, 3 Oct 2011 16:29:28 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 6bfd_1dc4_6af273d2_ed91_11e0_820b_001d096c5782; Mon, 03 Oct 2011 16:29:24 +0900 Received: from [IPv6:::1] ([133.2.210.1]:47049) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 3 Oct 2011 16:29:24 +0900 Message-ID: <4E896451.9080406@it.aoyama.ac.jp> Date: Mon, 03 Oct 2011 16:29:21 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: stephen.farrell@cs.tcd.ie References: <7bd9badd19e0e9296750117013a93aa0.squirrel@webmail.scss.tcd.ie> <7bb25df9c583e9553d4cf6b7b2c4d98c.squirrel@webmail.scss.tcd.ie> In-Reply-To: <7bb25df9c583e9553d4cf6b7b2c4d98c.squirrel@webmail.scss.tcd.ie> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: websec Subject: Re: [websec] Digest URI scheme 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, 03 Oct 2011 07:26:40 -0000 On 2011/09/30 23:40, stephen.farrell@cs.tcd.ie answered Phillip Hallam-Baker: >> Only real issue for me is that it has to fit in URI type slots. The >> scheme I was thinking of would be a pure URN scheme, your proposal >> includes URL like things. If you use what RFC 2396 calles the 'opaque' syntax (e.g. no slashes at all; in RFC 3986, I think slashes would even be allowed if they don't appear directly after the first ':'), then you can define an URI scheme without including host-like stuff and you don't have to use "urn:" as a prefix. > Yep. We have use-cases for that. Note though that the authority > part is optional, so a fairly bare digest is quite possible and > would look like ni:///sha256:NDVmZTMzOGVkY2Jj... The triple slash at the beginning is a bad idea. There should only be slashes if the scheme conforms to the generic syntax (i.e. a double slash, something like a host name, and then slashes for something pathlike). Just ni:sha256:NDVmZTMzOGVkY2Jj... is way better. >> Clearly, your scheme is a better way to reference external content in >> a resolvable format. I have to go look at the URN and URI specs again >> in detail. > > I also thought about URNs but was told (by PSA I think) that those > are intended for managed name spaces and not things like this. This recently came up on the urn mailing list. Please e.g. see http://www.ietf.org/mail-archive/web/urn/current/msg01616.html. >> I note that you have a content type, which I have but someone here was >> objecting to. I consider the content type to be essential meta-data >> for obvious security reasons. I don't think Paul Hoffman, who brought this up, was objecting. He just wanted to know what it's good for. Some security reasons may be obvious for you, but not for everybody :-). > Our use-case for that is for cases where the named object actually > arrives in some wrapped form (e.g. encrypted) and you need to know > the "inner" content type. However, I could see it being used otherwise > or being dropped as things progress. Just curious: Why would you need to know the inner content type? Wouldn't the wrapper contain that information? Regards, Martin. From internet-drafts@ietf.org Mon Oct 3 00:34:48 2011 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 303D221F8AF1; Mon, 3 Oct 2011 00:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 uogxCPGAuB+4; Mon, 3 Oct 2011 00:34:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA0E621F8ACE; Mon, 3 Oct 2011 00:34:47 -0700 (PDT) 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.60 Message-ID: <20111003073447.4648.58580.idtracker@ietfa.amsl.com> Date: Mon, 03 Oct 2011 00:34:47 -0700 Cc: websec@ietf.org Subject: [websec] I-D Action: draft-ietf-websec-origin-06.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: Mon, 03 Oct 2011 07:34:48 -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 : The Web Origin Concept Author(s) : Adam Barth Filename : draft-ietf-websec-origin-06.txt Pages : 26 Date : 2011-10-03 This document defines the concept of an "origin", which is oft= en used as the scope of authority or privilege by user agents. Typically, user agents isolate content retrieved from different origins to prevent malicious web site operators from interfering with the operation of benign web sites. In addition to outlining the principles that underlie the concept of origin, this document defines how to determine the origin of a URI, how to serialize an origin into a string, and an HTTP header field, named "Origin", that indic= ates which origins are associated with an HTTP request. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-websec-origin-06.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-origin-06.txt From duerst@it.aoyama.ac.jp Mon Oct 3 00:44:47 2011 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 3958321F88A0 for ; Mon, 3 Oct 2011 00:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.002 X-Spam-Level: X-Spam-Status: No, score=-99.002 tagged_above=-999 required=5 tests=[AWL=-0.701, BAYES_05=-1.11, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, 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 12WfjwsdKY6E for ; Mon, 3 Oct 2011 00:44:46 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 8B92721F8713 for ; Mon, 3 Oct 2011 00:44:46 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id p937llIT006571 for ; Mon, 3 Oct 2011 16:47:47 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 6bfb_6664_fc6672bc_ed93_11e0_820b_001d096c5782; Mon, 03 Oct 2011 16:47:47 +0900 Received: from [IPv6:::1] ([133.2.210.1]:49741) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 3 Oct 2011 16:47:47 +0900 Message-ID: <4E8968A0.5040506@it.aoyama.ac.jp> Date: Mon, 03 Oct 2011 16:47:44 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <4E82E996.8020003@mozilla.org> <4E82FC64.4020803@it.aoyama.ac.jp> <4E83518F.8080609@gondrom.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: websec@ietf.org Subject: Re: [websec] Digest URI scheme 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, 03 Oct 2011 07:44:47 -0000 On 2011/09/30 1:33, Phillip Hallam-Baker wrote: > OK, I will rev the draft to make it text identifiers. Great! > I will also check up on the uri syntax issues. Base64 uses two non > ascii characters and these need to be checked for legality. These are '+' and '/'. As for '+', this is a sub-delim in RFC 3986, but I don't see any problem in using it, unless you create a query-part syntax and expect users to enter it in HTML forms (In which case you would get hit by the space->'+' conversion). The '/' is somewhat different, because it's heavily involved in resolution of relative references,... But even there, I don't see a problem if we never have a '/' (or worse, two or more) after the initial colon. And relative references won't make sense for digests anyway, as far as I understand. > We might also reduce the length of the scheme name maybe? digest is 6 > chars, do we need them all? The shortest you could go is just one character, 'd'. But frankly, I don't understand why we need to be short and opaque. This would be another thing if the term we started was 10 or 20 characters long. > I would also like to see if we can ditch > the urn: prefix legally, it was bogus from the start, names and > locators are not disjoint categories. Just go ahead and ditch it. Regards, Martin. From julian.reschke@gmx.de Mon Oct 3 01:16:15 2011 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 9D91821F8AF9 for ; Mon, 3 Oct 2011 01:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.374 X-Spam-Level: X-Spam-Status: No, score=-104.374 tagged_above=-999 required=5 tests=[AWL=-2.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 yrkw8+P-oehj for ; Mon, 3 Oct 2011 01:16:14 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 48B9321F8AEA for ; Mon, 3 Oct 2011 01:16:13 -0700 (PDT) Received: (qmail invoked by alias); 03 Oct 2011 08:19:14 -0000 Received: from p5DCC8851.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.136.81] by mail.gmx.net (mp070) with SMTP; 03 Oct 2011 10:19:14 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19rgRNDSdFrzRn31FY4iiDbSn6MHqheDluJRCoVfx 53W/bZ8GxOmjvW Message-ID: <4E896FFE.8090601@gmx.de> Date: Mon, 03 Oct 2011 10:19:10 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= References: <20110922223352.30413.93196.idtracker@ietfa.amsl.com> <4E7C3547.5070405@gmx.de> <4E895581.1070900@it.aoyama.ac.jp> In-Reply-To: <4E895581.1070900@it.aoyama.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: websec@ietf.org Subject: Re: [websec] I-D Action: draft-ietf-websec-origin-05.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: Mon, 03 Oct 2011 08:16:15 -0000 On 2011-10-03 08:26, "Martin J. Dürst" wrote: > On 2011/10/03 7:14, Adam Barth wrote: >> On Fri, Sep 23, 2011 at 12:29 AM, Julian >> Reschke wrote: > >>> References: may need updates, such as WEBSOCKETS. Also consider >>> sorting them >>> (xml2rfc sortrefs PI). >> >> I've updated WEBSOCKETS. It will probably need to be updated again. > > My policy in cases like this is: Whenever I update a draft, I check the > references and update them if needed. > > However, the RFC editor is very good at getting these things right, so > there's no need to produce a new draft just because another one as > increased its number. Indeed. And if you use xml2rfc, those checks can be automated: Best regards, Julian From julian.reschke@gmx.de Mon Oct 3 01:44:08 2011 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 D236E21F8B0C for ; Mon, 3 Oct 2011 01:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.682 X-Spam-Level: X-Spam-Status: No, score=-103.682 tagged_above=-999 required=5 tests=[AWL=-1.383, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 zzHwPdIxHV0d for ; Mon, 3 Oct 2011 01:44:08 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id EEAAA21F8B14 for ; Mon, 3 Oct 2011 01:44:02 -0700 (PDT) Received: (qmail invoked by alias); 03 Oct 2011 08:46:55 -0000 Received: from p5DCC8851.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.136.81] by mail.gmx.net (mp003) with SMTP; 03 Oct 2011 10:46:55 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX189kcd9qjM9fUGucAAY2Nak1iIDuDPNf41Ep5wVzh 365wOq6muBFAqx Message-ID: <4E897679.8050100@gmx.de> Date: Mon, 03 Oct 2011 10:46:49 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= References: <7bd9badd19e0e9296750117013a93aa0.squirrel@webmail.scss.tcd.ie> <7bb25df9c583e9553d4cf6b7b2c4d98c.squirrel@webmail.scss.tcd.ie> <4E896451.9080406@it.aoyama.ac.jp> In-Reply-To: <4E896451.9080406@it.aoyama.ac.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: websec Subject: Re: [websec] Digest URI scheme 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, 03 Oct 2011 08:44:08 -0000 On 2011-10-03 09:29, "Martin J. Dürst" wrote: > On 2011/09/30 23:40, stephen.farrell@cs.tcd.ie answered Phillip > Hallam-Baker: > >>> Only real issue for me is that it has to fit in URI type slots. The >>> scheme I was thinking of would be a pure URN scheme, your proposal >>> includes URL like things. > > If you use what RFC 2396 calles the 'opaque' syntax (e.g. no slashes at > all; in RFC 3986, I think slashes would even be allowed if they don't > appear directly after the first ':'), then you can define an URI scheme > without including host-like stuff and you don't have to use "urn:" as a > prefix. > >> Yep. We have use-cases for that. Note though that the authority >> part is optional, so a fairly bare digest is quite possible and >> would look like ni:///sha256:NDVmZTMzOGVkY2Jj... > > The triple slash at the beginning is a bad idea. There should only be > slashes if the scheme conforms to the generic syntax (i.e. a double > slash, something like a host name, and then slashes for something > pathlike). Just ni:sha256:NDVmZTMzOGVkY2Jj... is way better. > ... Also keep in mind that if you use "/" for a different purpose than hierarchy, surprising things will happen when relative references are resolved. It's good to avoid them in this case. Best regards, Julian From hallam@gmail.com Mon Oct 3 06:27:23 2011 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 B6E4B21F8509 for ; Mon, 3 Oct 2011 06:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.333 X-Spam-Level: X-Spam-Status: No, score=-3.333 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 1aNOf-S4MMr9 for ; Mon, 3 Oct 2011 06:27:18 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 01DDA21F8498 for ; Mon, 3 Oct 2011 06:27:17 -0700 (PDT) Received: by yxt33 with SMTP id 33so4400857yxt.31 for ; Mon, 03 Oct 2011 06:30:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=dSDyMQlDwF4s6NceEwDxfPJ2JT/6Hr6ESYELLANHGx0=; b=wwAoQVjLJgHpX0tia7n7xDR28TE8MTdKp1qIuwcf9imciQhYp7xuoiZSkiEeY0ESDv W3upfg93K7/PmrS8QBYW58QJraPVIbnzsQuXFLoRQ2dU8jprtuvti+oMrVPynXUkyZuK No3ql2SitpG/5MQdjupxkY5T8/Labzoaf79jc= MIME-Version: 1.0 Received: by 10.101.218.6 with SMTP id v6mr12660733anq.140.1317648618669; Mon, 03 Oct 2011 06:30:18 -0700 (PDT) Received: by 10.100.212.14 with HTTP; Mon, 3 Oct 2011 06:30:18 -0700 (PDT) In-Reply-To: <4E896451.9080406@it.aoyama.ac.jp> References: <7bd9badd19e0e9296750117013a93aa0.squirrel@webmail.scss.tcd.ie> <7bb25df9c583e9553d4cf6b7b2c4d98c.squirrel@webmail.scss.tcd.ie> <4E896451.9080406@it.aoyama.ac.jp> Date: Mon, 3 Oct 2011 09:30:18 -0400 Message-ID: From: Phillip Hallam-Baker To: =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: websec Subject: Re: [websec] Digest URI scheme 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, 03 Oct 2011 13:27:23 -0000 On Mon, Oct 3, 2011 at 3:29 AM, "Martin J. D=FCrst" wrote: > On 2011/09/30 23:40, stephen.farrell@cs.tcd.ie answered Phillip > Hallam-Baker: > >>> Only real issue for me is that it has to fit in URI type slots. The >>> scheme I was thinking of would be a pure URN scheme, your proposal >>> includes URL like things. > > If you use what RFC 2396 calles the 'opaque' syntax (e.g. no slashes at a= ll; > in RFC 3986, I think slashes would even be allowed if they don't appear > directly after the first ':'), then you can define an URI scheme without > including host-like stuff and you don't have to use "urn:" as a prefix. I think that 'some' structure would be useful. I don't see that keeping the Base64 character scheme needs to be a priority. There have been plenty of alternatives that don't use a slash as one of the two extra chars. >> Yep. We have use-cases for that. Note though that the authority >> part is optional, so a fairly bare digest is quite possible and >> would look like ni:///sha256:NDVmZTMzOGVkY2Jj... > > The triple slash at the beginning is a bad idea. There should only be > slashes if the scheme conforms to the generic syntax (i.e. a double slash= , > something like a host name, and then slashes for something pathlike). Jus= t > ni:sha256:NDVmZTMzOGVkY2Jj... is way better. That was Stephen, not me. I was also somewhat surprised by the tripple slash. It is the sort of thing that could break assumptions. One of the things I was thinking about was that for our case the essence of the digest is really the digest part. The domain is really just a location hint. Why stick at just one domain? If the same content is present at foo.com and bar.com why not have an identifier that can specify both: dig:sha-256:wkjfhskjhfskjdhkjdshfjksdkfjhsdkfjh$#=3D?loc=3Dfoo.com&loc=3Dba= r.com&ct=3Dtext/plain Now I know that we do not need this for our particular application, but if we are going to come up with a common scheme with DECADE we have to meet their use cases as well as out own. I have some other ideas that would be interesting in the DECADE context. Right back in 1995 Rohit Khare and myself were fooling about with identifiers that had decryption keys built in. For their particular application, the ability to send a single identifier that allows the content to be uniquely identified, authenticated and located would be quite interesting I think. Adding a symmetric decryption key means that the set of people who can read the plaintext is precisely the set of people with access to the plaintext plus the people who can access the identifier. The host on which confidential content resides is thus moved outside the zone where security concerns apply. >>> I note that you have a content type, which I have but someone here was >>> objecting to. I consider the content type to be essential meta-data >>> for obvious security reasons. > > I don't think Paul Hoffman, who brought this up, was objecting. He just > wanted to know what it's good for. Some security reasons may be obvious f= or > you, but not for everybody :-). Since we already had this discussion at great length in another place I think that he just does not understand the security issue and never will. >> Our use-case for that is for cases where the named object actually >> arrives in some wrapped form (e.g. encrypted) and you need to know >> the "inner" content type. However, I could see it being used otherwise >> or being dropped as things progress. > > Just curious: Why would you need to know the inner content type? Wouldn't > the wrapper contain that information? Probably so that they can perform negotiation. If the consumer is a video player, it wants to be able to select content that it knows how to play. In most cases the player will be grabbing the bits and negotiating the decryption capability in parallel. In my case the concern is that it should be possible to use the generalized form of this identifier as a secure URL for referencing static content from a secure Web page. So imagine that we have anybank.com that has its main pages on HTTPS but has the images etc. on a separate server that really does not need SSL for any purpose other than authenticating the source. It would be a trivial matter to write a script that could transform such Web pages into Web pages with 'hardened' URLs of the digest form being discussed here. This would in turn provide a long term answer to the problem of efficiently supporting the strict security concerns we discuss here without the overhead of SSL everywhere. The only problem with that being that the content-type is actually a security sensitive piece of meta-data and manipulation of content-types is a major attack vector (probably the fastest growing at the mo). --=20 Website: http://hallambaker.com/ From hallam@gmail.com Mon Oct 3 07:10:27 2011 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 695BD21F8B67 for ; Mon, 3 Oct 2011 07:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.483 X-Spam-Level: X-Spam-Status: No, score=-3.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, 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 Z97S8Xbi17Mh for ; Mon, 3 Oct 2011 07:10:22 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8117A21F8B5F for ; Mon, 3 Oct 2011 07:10:22 -0700 (PDT) Received: by gyd12 with SMTP id 12so4340756gyd.31 for ; Mon, 03 Oct 2011 07:13:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=x9CoAjAQq3pEeWgre//LiHcFvYyzu+OzF4P0V6C04KQ=; b=oz73qsmSktiC3k2PhjhYJplKnAIFs/yoO9PKnkWebiHJxlJPqnAX+ez0HQ+otMTQNp A5FhEEKfW6eHnfRyrKoiuMtK390NFa4tqpULNfsIKXVsgbPhpC6EU4kp5hCR4lEa389g DSNmVe1PP0x75QiDwC6za2JUmKAcr3TwcVOls= MIME-Version: 1.0 Received: by 10.100.18.21 with SMTP id 21mr1315214anr.118.1317651188155; Mon, 03 Oct 2011 07:13:08 -0700 (PDT) Received: by 10.100.212.14 with HTTP; Mon, 3 Oct 2011 07:13:07 -0700 (PDT) In-Reply-To: <4E897679.8050100@gmx.de> References: <7bd9badd19e0e9296750117013a93aa0.squirrel@webmail.scss.tcd.ie> <7bb25df9c583e9553d4cf6b7b2c4d98c.squirrel@webmail.scss.tcd.ie> <4E896451.9080406@it.aoyama.ac.jp> <4E897679.8050100@gmx.de> Date: Mon, 3 Oct 2011 10:13:07 -0400 Message-ID: From: Phillip Hallam-Baker To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: websec Subject: Re: [websec] Digest URI scheme 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, 03 Oct 2011 14:10:27 -0000 On Mon, Oct 3, 2011 at 4:46 AM, Julian Reschke wrot= e: > On 2011-10-03 09:29, "Martin J. D=FCrst" wrote: >> >> On 2011/09/30 23:40, stephen.farrell@cs.tcd.ie answered Phillip >> Hallam-Baker: >> >>>> Only real issue for me is that it has to fit in URI type slots. The >>>> scheme I was thinking of would be a pure URN scheme, your proposal >>>> includes URL like things. >> >> If you use what RFC 2396 calles the 'opaque' syntax (e.g. no slashes at >> all; in RFC 3986, I think slashes would even be allowed if they don't >> appear directly after the first ':'), then you can define an URI scheme >> without including host-like stuff and you don't have to use "urn:" as a >> prefix. >> >>> Yep. We have use-cases for that. Note though that the authority >>> part is optional, so a fairly bare digest is quite possible and >>> would look like ni:///sha256:NDVmZTMzOGVkY2Jj... >> >> The triple slash at the beginning is a bad idea. There should only be >> slashes if the scheme conforms to the generic syntax (i.e. a double >> slash, something like a host name, and then slashes for something >> pathlike). Just ni:sha256:NDVmZTMzOGVkY2Jj... is way better. > >> ... > > Also keep in mind that if you use "/" for a different purpose than > hierarchy, surprising things will happen when relative references are > resolved. It's good to avoid them in this case. That is probably the killer argument here. I suggest that we use Base 64 Encoding with URL and Filename Safe Alphabet: http://tools.ietf.org/html/rfc4648#page-7 This would mean using the characters - and _ for char codes 63 and 64 and dropping the padding completely. There is a great summary table here that folk can choose from http://en.wikipedia.org/wiki/Base64 I am strongly tending towards: "digest:" algorithm ':' base64(content) ['?' tag '=3D' value [ '&' tag '=3D' value]* ] Where: algorithm - is from the IANA registry discussed earlier base64 - is the RFC 4648 file and url safe version content is the referenced content tag is taken from the URL encoding precedent value is taken from the URL encoding precedent If people need a locator then it would be formed from a tag/value pair as follows: tag =3D "http" value =3D domain name The corresponding url would be formed as: "http://" + domain-name + "/.well-known/digest/" + algorithm + "/" + base64(content) This can then be transformed inside the Web Server as is necessary to support the constraints of the local file system. Other protocol tags can be specified to support alternative protocols. Stephen's DECADE application then becomes a special case of the general form of the identifier. It is essentially a different lookup protocol. Some additional tweakage: For certain applications the full 256 bits of the content URL are unnecessa= ry. If an encryption key is in use then the encryption key can be used to form part of the identifier for the purpose of distinguishing identifiers. For example: let the plaintext be p and the encryption key be k. The identifier might be digest:sha-2-128:Ry_yKcfFmWj4cs9ucvm10Q?enc=3Daes&key=3D491X0pTnLkJHFN_AVct= JUA Where sha-2-128 is SHA256 truncated to 128 bits as per NIST instructions. The collision resistant digest identifier for the content is then formed as= : digest + E ( digest, key ) "Ry_yKcfFmWj4cs9ucvm10Q" + AES ("Ry_yKcfFmWj4cs9ucvm10Q", "491X0pTnLkJHFN_AVctJUA") The result is an identifier of 256 bits that has 128 bits worth of authentication security, 128 bits worth of confidentiality security and 128 bits worth of birthday attack collision resistance. For the current WebSec use cases, only the digest is actually required. I am not entirely convinced, but I suspect that for our use cases the truncated identifier would be sufficient since we rely only on the 2nd preimage resistance property. --=20 Website: http://hallambaker.com/ From paul.hoffman@vpnc.org Mon Oct 3 07:57:56 2011 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 6A88921F8B05 for ; Mon, 3 Oct 2011 07:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 TzQ3IeDCpx02 for ; Mon, 3 Oct 2011 07:57:56 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id D9B5621F85F1 for ; Mon, 3 Oct 2011 07:57:55 -0700 (PDT) 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 p93F0sGq022531 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 3 Oct 2011 08:00:55 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Paul Hoffman In-Reply-To: <4E897679.8050100@gmx.de> Date: Mon, 3 Oct 2011 08:00:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7bd9badd19e0e9296750117013a93aa0.squirrel@webmail.scss.tcd.ie> <7bb25df9c583e9553d4cf6b7b2c4d98c.squirrel@webmail.scss.tcd.ie> <4E896451.9080406@it.aoyama.ac.jp> <4E897679.8050100@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1244.3) Cc: websec WG Subject: Re: [websec] Digest URI scheme 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, 03 Oct 2011 14:57:56 -0000 On Oct 3, 2011, at 1:46 AM, Julian Reschke wrote: > On 2011-10-03 09:29, "Martin J. D=FCrst" wrote: >> On 2011/09/30 23:40, stephen.farrell@cs.tcd.ie answered Phillip >> Hallam-Baker: >>=20 >>>> Only real issue for me is that it has to fit in URI type slots. The >>>> scheme I was thinking of would be a pure URN scheme, your proposal >>>> includes URL like things. >>=20 >> If you use what RFC 2396 calles the 'opaque' syntax (e.g. no slashes = at >> all; in RFC 3986, I think slashes would even be allowed if they don't >> appear directly after the first ':'), then you can define an URI = scheme >> without including host-like stuff and you don't have to use "urn:" as = a >> prefix. >>=20 >>> Yep. We have use-cases for that. Note though that the authority >>> part is optional, so a fairly bare digest is quite possible and >>> would look like ni:///sha256:NDVmZTMzOGVkY2Jj... >>=20 >> The triple slash at the beginning is a bad idea. There should only be >> slashes if the scheme conforms to the generic syntax (i.e. a double >> slash, something like a host name, and then slashes for something >> pathlike). Just ni:sha256:NDVmZTMzOGVkY2Jj... is way better. > > ... >=20 > Also keep in mind that if you use "/" for a different purpose than = hierarchy, surprising things will happen when relative references are = resolved. It's good to avoid them in this case. That's silly for this case. The proposed URL scheme has no hierarchy = scheme, nor is it even resolvable because there is no host. I know Phill = has already responded that he intends to use an encoding that changes = Base64 for the reason you give; I believe that will lead to likely lack = of interop due to complexity. --Paul Hoffman From hallam@gmail.com Mon Oct 3 09:19:26 2011 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 3FB9821F8B62 for ; Mon, 3 Oct 2011 09:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.484 X-Spam-Level: X-Spam-Status: No, score=-3.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, 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 zVVFKeQxlGGj for ; Mon, 3 Oct 2011 09:19:25 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 759C821F8B5B for ; Mon, 3 Oct 2011 09:19:25 -0700 (PDT) Received: by yxt33 with SMTP id 33so4606025yxt.31 for ; Mon, 03 Oct 2011 09:22:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=fJW8yy98bp7GF11nrAjYr9hGUVRrIWaIbG3bf+qsFwo=; b=Y+ATA/VwociYV4JUAu7x0eQwObSwchouNTrTZiZCg7Dj8Xk6ijXo0VJ+Yrg5zegIgv X1nTqlCGdAtt2vuXG9GGZAjYcAffBMnoeWQD77emk+4DqkUczjuLXv2Lx3aj5S+q5z8k meP6QlQS9kuK9/ugPdM3aIs68y7lPxuR3sMLE= MIME-Version: 1.0 Received: by 10.101.28.40 with SMTP id f40mr128523anj.30.1317658944156; Mon, 03 Oct 2011 09:22:24 -0700 (PDT) Received: by 10.100.212.14 with HTTP; Mon, 3 Oct 2011 09:22:24 -0700 (PDT) In-Reply-To: References: <7bd9badd19e0e9296750117013a93aa0.squirrel@webmail.scss.tcd.ie> <7bb25df9c583e9553d4cf6b7b2c4d98c.squirrel@webmail.scss.tcd.ie> <4E896451.9080406@it.aoyama.ac.jp> <4E897679.8050100@gmx.de> Date: Mon, 3 Oct 2011 12:22:24 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: websec WG Subject: Re: [websec] Digest URI scheme 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, 03 Oct 2011 16:19:26 -0000 On Mon, Oct 3, 2011 at 11:00 AM, Paul Hoffman wrote= : > > On Oct 3, 2011, at 1:46 AM, Julian Reschke wrote: > >> On 2011-10-03 09:29, "Martin J. D=FCrst" wrote: >>> On 2011/09/30 23:40, stephen.farrell@cs.tcd.ie answered Phillip >>> Hallam-Baker: >>> >> >> Also keep in mind that if you use "/" for a different purpose than hiera= rchy, surprising things will happen when relative references are resolved. = It's good to avoid them in this case. > > > That's silly for this case. The proposed URL scheme has no hierarchy sche= me, nor is it even resolvable because there is no host. I know Phill has al= ready responded that he intends to use an encoding that changes Base64 for = the reason you give; I believe that will lead to likely lack of interop due= to complexity. Complexity, shmexity. We have a case where Julian has pointed out that failing to properly address these cases will lead to interop failures. I don't see how using the URI-safe encoding in a URI is more complex than using the one we already know to be broken. URLs are used in cases where hierarchy is assumed. Thus there is code to attempt to apply relative naming to identifiers that are put in URI slots. Julian is completely right on this. This is a known issue and the IETF already has a standards based fix for it= . There is a fine line between simple and simplistic. Using the +/ encoding would be simplistic and definitely not simple. Interop issues due to incompetent programmers not reading the spec will on average be detected in (64/2) / ((4/3)*(256/8)) trials, that is 0.75. We can even choose test vectors that ensure that these issues are exposed. --=20 Website: http://hallambaker.com/ From paul.hoffman@vpnc.org Mon Oct 3 10:02:51 2011 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 7AA1421F8C48 for ; Mon, 3 Oct 2011 10:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 xv+an1LLXdMS for ; Mon, 3 Oct 2011 10:02:51 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id E851A21F8C46 for ; Mon, 3 Oct 2011 10:02:50 -0700 (PDT) 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 p93H5pcb094902 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 3 Oct 2011 10:05:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Paul Hoffman In-Reply-To: Date: Mon, 3 Oct 2011 10:05:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7bd9badd19e0e9296750117013a93aa0.squirrel@webmail.scss.tcd.ie> <7bb25df9c583e9553d4cf6b7b2c4d98c.squirrel@webmail.scss.tcd.ie> <4E896451.9080406@it.aoyama.ac.jp> <4E897679.8050100@gmx.de> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1244.3) Cc: websec WG Subject: Re: [websec] Digest URI scheme 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, 03 Oct 2011 17:02:51 -0000 On Oct 3, 2011, at 9:22 AM, Phillip Hallam-Baker wrote: > URLs are used in cases where hierarchy is assumed. I didn't see such use cases in your draft, nor in Stephen's. Maybe = you'll put them in your next proposal. --Paul Hoffman From hallam@gmail.com Mon Oct 3 10:09:04 2011 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 9E6AA21F8C7F for ; Mon, 3 Oct 2011 10:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.485 X-Spam-Level: X-Spam-Status: No, score=-3.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, 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 8dSHMho6+PaI for ; Mon, 3 Oct 2011 10:09:04 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id DDE2721F8C42 for ; Mon, 3 Oct 2011 10:08:59 -0700 (PDT) Received: by gyd12 with SMTP id 12so4548514gyd.31 for ; Mon, 03 Oct 2011 10:12:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=It0ImBprS2mdzQB300Pjvw3YSuuw8DCoMfs73yZ5XNM=; b=hw8d1861JfqcXPTLFxat/XBi8Wo8/OOw0PPjGDztfC0Q8bwFzOVUOz9OUR6H0OE+tL FYM4kSux1NfHSczWwpQdTOE64Myt3FxXizT5IqowGnJLzWUUGsOhnnj+mXIPchmYaHld /TCf6uC14Cbjbix/ZLHV6dW9hENSAsQUdFFzI= MIME-Version: 1.0 Received: by 10.101.218.6 with SMTP id v6mr138358anq.140.1317661922561; Mon, 03 Oct 2011 10:12:02 -0700 (PDT) Received: by 10.100.212.14 with HTTP; Mon, 3 Oct 2011 10:12:02 -0700 (PDT) In-Reply-To: References: <7bd9badd19e0e9296750117013a93aa0.squirrel@webmail.scss.tcd.ie> <7bb25df9c583e9553d4cf6b7b2c4d98c.squirrel@webmail.scss.tcd.ie> <4E896451.9080406@it.aoyama.ac.jp> <4E897679.8050100@gmx.de> Date: Mon, 3 Oct 2011 13:12:02 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Cc: websec WG Subject: Re: [websec] Digest URI scheme 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, 03 Oct 2011 17:09:04 -0000 On Mon, Oct 3, 2011 at 1:05 PM, Paul Hoffman wrote: > On Oct 3, 2011, at 9:22 AM, Phillip Hallam-Baker wrote: > >> URLs are used in cases where hierarchy is assumed. > > I didn't see such use cases in your draft, nor in Stephen's. Maybe you'll put them in your next proposal. As Julian correctly pointed out, a generic URI will be used in situations where the application will (correctly) assume that anything in URI syntax that has a slash character in it will be hierarchical. Thus a URI scheme that does not intend to indicate hierarchy MUST NOT include a slash character in that part of the identifier. Plus it is essential to ensure that anything that is to fit in a URI slot is compatible with code for making entries URI-safe. A URI that contains a + character is likely to end up being mangled. This issue has already been litigated in the IETF and the result of that consensus was RFC 4648. I see no reason to re-open that discussion in case someone does not bother to test their code. -- Website: http://hallambaker.com/ From paul.hoffman@vpnc.org Mon Oct 3 10:20:52 2011 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 9794321F8C46 for ; Mon, 3 Oct 2011 10:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 G+-8WYgYa9xJ for ; Mon, 3 Oct 2011 10:20:52 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1717921F8C3F for ; Mon, 3 Oct 2011 10:20:52 -0700 (PDT) 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 p93HNrZi005591 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 3 Oct 2011 10:23:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Mon, 3 Oct 2011 10:23:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <23F40A42-C2B3-4597-A8CD-444E5C2D09FD@vpnc.org> References: <7bd9badd19e0e9296750117013a93aa0.squirrel@webmail.scss.tcd.ie> <7bb25df9c583e9553d4cf6b7b2c4d98c.squirrel@webmail.scss.tcd.ie> <4E896451.9080406@it.aoyama.ac.jp> <4E897679.8050100@gmx.de> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1244.3) Cc: websec WG Subject: Re: [websec] Digest URI scheme 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, 03 Oct 2011 17:20:52 -0000 On Oct 3, 2011, at 10:12 AM, Phillip Hallam-Baker wrote: > On Mon, Oct 3, 2011 at 1:05 PM, Paul Hoffman = wrote: >> On Oct 3, 2011, at 9:22 AM, Phillip Hallam-Baker wrote: >>=20 >>> URLs are used in cases where hierarchy is assumed. >>=20 >> I didn't see such use cases in your draft, nor in Stephen's. Maybe = you'll put them in your next proposal. >=20 > As Julian correctly pointed out, a generic URI will be used in > situations where the application will (correctly) assume that anything > in URI syntax that has a slash character in it will be hierarchical. Did Julian say that? The one thing that I saw him say was "Also keep in = mind that if you use "/" for a different purpose than hierarchy, = surprising things will happen when relative references are resolved. = It's good to avoid them in this case." I don't see how the digest URL you propose has either "relative = references" nor "resolved". More detail in your next draft would be = valuable. --Paul Hoffman From hallam@gmail.com Mon Oct 3 10:27:46 2011 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 77F8721F8B36 for ; Mon, 3 Oct 2011 10:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.485 X-Spam-Level: X-Spam-Status: No, score=-3.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, 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 3MolU5ioaiAx for ; Mon, 3 Oct 2011 10:27:45 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 70CFB21F8B35 for ; Mon, 3 Oct 2011 10:27:45 -0700 (PDT) Received: by gyd12 with SMTP id 12so4567763gyd.31 for ; Mon, 03 Oct 2011 10:30:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DYRK04fHr2bckqaNWzuI705VWqBtDMz7EjAc/itdFu0=; b=bQFgnig20dMrVFT5wRWXTP0BimTNShiPWLMEKkierFtI0Uhigu8bYiUIa1HNjDq9j8 LuTieUCuHmjr7kDGQ3ECMZc7Q7B/VA0BDuZqXsTKdVMFGtxAoqS2YqVNw5h7PAuZiSK5 B+xptv4f5YOYZ2ZV+kVrT/qyW+NEbY+YKwMd0= MIME-Version: 1.0 Received: by 10.101.27.34 with SMTP id e34mr152480anj.162.1317663048159; Mon, 03 Oct 2011 10:30:48 -0700 (PDT) Received: by 10.100.212.14 with HTTP; Mon, 3 Oct 2011 10:30:48 -0700 (PDT) In-Reply-To: <23F40A42-C2B3-4597-A8CD-444E5C2D09FD@vpnc.org> References: <7bd9badd19e0e9296750117013a93aa0.squirrel@webmail.scss.tcd.ie> <7bb25df9c583e9553d4cf6b7b2c4d98c.squirrel@webmail.scss.tcd.ie> <4E896451.9080406@it.aoyama.ac.jp> <4E897679.8050100@gmx.de> <23F40A42-C2B3-4597-A8CD-444E5C2D09FD@vpnc.org> Date: Mon, 3 Oct 2011 13:30:48 -0400 Message-ID: From: Phillip Hallam-Baker To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Cc: websec WG Subject: Re: [websec] Digest URI scheme 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, 03 Oct 2011 17:27:46 -0000 >From RFC 4395: 2.2. Syntactic Compatibility RFC 3986 [5] defines the generic syntax for all URI schemes, along with the syntax of common URI components that are used by many URI schemes to define hierarchical identifiers. All URI scheme specifications MUST define their own syntax such that all strings matching their scheme-specific syntax will also match the grammar described in Section 4.3 of RFC 3986. New URI schemes SHOULD reuse the common URI components of RFC 3986 for the definition of hierarchical naming schemes. However, if there is a strong reason for a URI scheme not to use the hierarchical syntax, then the new scheme definition SHOULD follow the syntax of previously registered schemes. URI schemes that are not intended for use with relative URIs SHOULD avoid use of the forward slash "/" character, which is used for hierarchical delimiters, and the complete path segments "." and ".." (dot-segments). Question closed in my view. I don't see any point in responding to further comments that simply repeat the original statement. There is a clear requirement that URI schemes are required to meet stated in the URI standards documents. The rules were developed from long experience and are designed to encourage interoperability. I don't see any reason to second guess that reasoning on the basis of the vague and unsubstantiated concerns you have raised. On Mon, Oct 3, 2011 at 1:23 PM, Paul Hoffman wrote: > On Oct 3, 2011, at 10:12 AM, Phillip Hallam-Baker wrote: > >> On Mon, Oct 3, 2011 at 1:05 PM, Paul Hoffman wrote: >>> On Oct 3, 2011, at 9:22 AM, Phillip Hallam-Baker wrote: >>> >>>> URLs are used in cases where hierarchy is assumed. >>> >>> I didn't see such use cases in your draft, nor in Stephen's. Maybe you'll put them in your next proposal. >> >> As Julian correctly pointed out, a generic URI will be used in >> situations where the application will (correctly) assume that anything >> in URI syntax that has a slash character in it will be hierarchical. > > Did Julian say that? The one thing that I saw him say was "Also keep in mind that if you use "/" for a different purpose than hierarchy, surprising things will happen when relative references are resolved. It's good to avoid them in this case." > > I don't see how the digest URL you propose has either "relative references" nor "resolved". More detail in your next draft would be valuable. > > --Paul Hoffman > > -- Website: http://hallambaker.com/ From derhoermi@gmx.net Mon Oct 3 10:33:39 2011 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 622DE21F8C91 for ; Mon, 3 Oct 2011 10:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=-0.849, 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 c+wn3sSuCkol for ; Mon, 3 Oct 2011 10:33:38 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 12A8821F8C8F for ; Mon, 3 Oct 2011 10:33:37 -0700 (PDT) Received: (qmail invoked by alias); 03 Oct 2011 17:36:39 -0000 Received: from dslb-094-222-152-232.pools.arcor-ip.net (EHLO HIVE) [94.222.152.232] by mail.gmx.net (mp048) with SMTP; 03 Oct 2011 19:36:39 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX19KXFhN8ltKeNm8zIxR+5YIA4bE+yI+F3VUxf8h6r B8NdrNvlUGzKBO From: Bjoern Hoehrmann To: Paul Hoffman Date: Mon, 03 Oct 2011 19:36:43 +0200 Message-ID: References: <7bb25df9c583e9553d4cf6b7b2c4d98c.squirrel@webmail.scss.tcd.ie> <4E896451.9080406@it.aoyama.ac.jp> <4E897679.8050100@gmx.de> <23F40A42-C2B3-4597-A8CD-444E5C2D09FD@vpnc.org> In-Reply-To: <23F40A42-C2B3-4597-A8CD-444E5C2D09FD@vpnc.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 WG Subject: Re: [websec] Digest URI scheme 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, 03 Oct 2011 17:33:39 -0000 * Paul Hoffman wrote: >I don't see how the digest URL you propose has either "relative >references" nor "resolved". More detail in your next draft would be >valuable. Resolving a relative reference with respect to a base reference is some- thing you can do regardless of the scheme. Scheme definitions don't need to discuss relative references at all, there are always relative forms, and anything that can be said about them is already defined in RFC 3986. -- 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 derhoermi@gmx.net Mon Oct 3 10:39:10 2011 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 4BCFB21F8CB1 for ; Mon, 3 Oct 2011 10:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.383 X-Spam-Level: X-Spam-Status: No, score=-3.383 tagged_above=-999 required=5 tests=[AWL=-0.784, 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 c-bZCZX0arli for ; Mon, 3 Oct 2011 10:39:09 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 390AD21F8CA5 for ; Mon, 3 Oct 2011 10:39:09 -0700 (PDT) Received: (qmail invoked by alias); 03 Oct 2011 17:42:10 -0000 Received: from dslb-094-222-152-232.pools.arcor-ip.net (EHLO HIVE) [94.222.152.232] by mail.gmx.net (mp047) with SMTP; 03 Oct 2011 19:42:10 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1/dUskD+VndmvVpahQeQ1pp9OHWtgAbCzm602pGX2 dUxI6Y58DVk715 From: Bjoern Hoehrmann To: Phillip Hallam-Baker Date: Mon, 03 Oct 2011 19:42:14 +0200 Message-ID: References: <7bd9badd19e0e9296750117013a93aa0.squirrel@webmail.scss.tcd.ie> <7bb25df9c583e9553d4cf6b7b2c4d98c.squirrel@webmail.scss.tcd.ie> <4E896451.9080406@it.aoyama.ac.jp> <4E897679.8050100@gmx.de> 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 Subject: Re: [websec] Digest URI scheme 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, 03 Oct 2011 17:39:10 -0000 * Phillip Hallam-Baker wrote: >I suggest that we use Base 64 Encoding with URL and Filename Safe Alphabet: How about Base 16 instead? Like we use it for checksums everywhere else? -- 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 hallam@gmail.com Mon Oct 3 10:47:38 2011 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 7CCF021F8C3C for ; Mon, 3 Oct 2011 10:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.486 X-Spam-Level: X-Spam-Status: No, score=-3.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, 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 RAWalQRf9-Bb for ; Mon, 3 Oct 2011 10:47:36 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id DF4AD21F8AE9 for ; Mon, 3 Oct 2011 10:47:17 -0700 (PDT) Received: by yxt33 with SMTP id 33so4699364yxt.31 for ; Mon, 03 Oct 2011 10:50:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=LVNAlNi1Mw2AkK5sDJldHRhQkvp2PTxSg+Zidi+fwME=; b=oeDal3O025lE/BF6R/A+wtNgT1OlLkNRvrCbXh5SPEKS+QAa5egCyRLCL8MPsxiu0u r57iI1U2KgbFlfnRhJdoEd2eGivFhOT/q3SltEe4cm+XXzlHkfcyL+1yXPIpkATg2f8a Fx98Ge7PV2wXLFfHGbugQ3ptltu9mBnvIUUEY= MIME-Version: 1.0 Received: by 10.101.180.25 with SMTP id h25mr221887anp.8.1317664220496; Mon, 03 Oct 2011 10:50:20 -0700 (PDT) Received: by 10.100.212.14 with HTTP; Mon, 3 Oct 2011 10:50:20 -0700 (PDT) In-Reply-To: References: <7bd9badd19e0e9296750117013a93aa0.squirrel@webmail.scss.tcd.ie> <7bb25df9c583e9553d4cf6b7b2c4d98c.squirrel@webmail.scss.tcd.ie> <4E896451.9080406@it.aoyama.ac.jp> <4E897679.8050100@gmx.de> Date: Mon, 3 Oct 2011 13:50:20 -0400 Message-ID: From: Phillip Hallam-Baker To: Bjoern Hoehrmann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: websec Subject: Re: [websec] Digest URI scheme 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, 03 Oct 2011 17:47:38 -0000 That adds significantly to the size of the identifiers. For my application the amount of space that is available to transport the identifiers will be constrained. Thus if X bytes permits 100 sites to be secured using a base64 encoding, use of base16 will drop that to 60 or so. There is already an IETF specification and precedent that covers this issue= . On Mon, Oct 3, 2011 at 1:42 PM, Bjoern Hoehrmann wrote: > * Phillip Hallam-Baker wrote: >>I suggest that we use Base 64 Encoding with URL and Filename Safe Alphabe= t: > > How about Base 16 instead? Like we use it for checksums everywhere else? > -- > Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoehr= mann.de > Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 http://www.bjoernsworld= .de > 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev= .de/ > --=20 Website: http://hallambaker.com/ From hallam@gmail.com Mon Oct 3 13:38:09 2011 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 A14E021F8E44; Mon, 3 Oct 2011 13:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.487 X-Spam-Level: X-Spam-Status: No, score=-3.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, 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 iAP96zhJnzil; Mon, 3 Oct 2011 13:38:08 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id AAED821F8E39; Mon, 3 Oct 2011 13:37:53 -0700 (PDT) Received: by vws5 with SMTP id 5so4856599vws.31 for ; Mon, 03 Oct 2011 13:40:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=MAyGC8+FRk4H2GjX0QWsd4CisQ7hVqvq8VaQtgFA56c=; b=OW09vOUCc63TR5i4ZPQlsi5ZkbrwqAcrkiuqDId1KPonOjpIUdRJn7rKmkO9czUJlP kjQNMwjZELaQc3QFNsUtQumx6veNWUc+cCyYg8MoHPikNoKV98alzjpbsYbD58wOo5vL u8Ah7C0sADa2VIjZRHEUx31HCWAQ45hJwTMJU= MIME-Version: 1.0 Received: by 10.52.174.36 with SMTP id bp4mr392757vdc.256.1317674456675; Mon, 03 Oct 2011 13:40:56 -0700 (PDT) Received: by 10.220.200.198 with HTTP; Mon, 3 Oct 2011 13:40:56 -0700 (PDT) Date: Mon, 3 Oct 2011 16:40:56 -0400 Message-ID: From: Phillip Hallam-Baker To: websec , khare@alumni.caltech.edu, decade@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [websec] Updated Digest Scheme URI 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, 03 Oct 2011 20:38:09 -0000 I have made major modifications to the digest scheme from the first version: http://www.ietf.org/id/draft-hallambaker-digesturi-01.txt The main changes relevant to the initial WebSEC use cases are: * Identifiers are now text strings using the IANA crypto algs registry * A 'start' has been made on getting the URI template filled in * The encoding scheme base64url encoding is used to comply with URI requirements * The content type is specified as a parameter In addition the following features have been outlined to demonstrate that it is possible to create a digest URI that WebSec and DECADE could both use: * Optional parameters section * Scheme for specifying one or more locations for retrieval * Scheme for decrypting encrypted stored content. Note that these particular use cases actually address recurring WEBSEC type issues, namely how to securely reference content stored on an untrusted server. Simply saying 'SSL' does not in fact solve this question since the linked content may be in a different trust zone. this turns up all the time with 'rickrolling' and general Slashdot fun. The main difference between my approach and Stephen's is that Stephen puts the domain portion first as is traditional for a URL. I throw it in as a parameter. Why? Well for static data (as we are doping here) the digest is a far more permanent and specific identifier of the content than one location that might return the data. So it really makes sense to put that up front and make it the first thing in the digest. Some form of URL transformation is going to be required in either scheme. As has been discussed on the list, relativity really does not provide much leverage here. The big payoff in my mind for DECADE is that this makes specifying more than one download location easy as well. It also makes it easy for aware applications to add and subtract locations as is sensible. If content is deposited in a cache, the cache can add its domain into the URI scheme. So the simplest URI described in the paper is: di:sha-256:B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc The simplest secure reference is: di:sha-256:B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc?ct=text/plain Addressing DECADE type use cases: A reference can be specified to external content: di:sha-256:B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc?http=di.example.com This maps to the following URL: http://di.example.com/.well-known/B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc And the scheme can be extended to cover encrypted content as well: di:sha-128:B_K97zTtFuOhug27fke4_Q?enc=aes-cbc:Fw3x20nEKfq6FDGzq7ttIQ Have to credit Rohit Khare's work here as we both played around with this stuff back in 1995 when we were working for the Web Consortium. Note that the parameter schemes are proposed as illustration, not as something that I insist on. The point I want to make here is purely about the extensibility of the format proposed. If people want to only consider the WEBSEC use cases in that WG and ignore DECADE, then we could strip them out for the base draft and then have a supplemental draft that describes the extra features. My view is that the locator hints are actually very useful in the WEBSEC cert pinning context as they allow means for downloading the related certs. The encryption stuff is likely very interesting in DECADE as it means that the identifier is essentially a self contained capability for the referenced content. -- Website: http://hallambaker.com/ From derhoermi@gmx.net Mon Oct 3 16:14:04 2011 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 0016121F8E2F for ; Mon, 3 Oct 2011 16:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[AWL=-0.728, 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 92F33Gw2Zlfu for ; Mon, 3 Oct 2011 16:14:03 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 8BEF121F8DDF for ; Mon, 3 Oct 2011 16:14:02 -0700 (PDT) Received: (qmail invoked by alias); 03 Oct 2011 23:17:04 -0000 Received: from dslb-094-222-152-232.pools.arcor-ip.net (EHLO HIVE) [94.222.152.232] by mail.gmx.net (mp055) with SMTP; 04 Oct 2011 01:17:04 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX18/oMU7D2E/KMwFnt8vsNt7KBHHMpcmsQe8tMDtcJ tSC2Jj3kvuHN7o From: Bjoern Hoehrmann To: Phillip Hallam-Baker Date: Tue, 04 Oct 2011 01:17:08 +0200 Message-ID: <9bgk875tk3ue5g5uksii731purgptrq04k@hive.bjoern.hoehrmann.de> References: <7bd9badd19e0e9296750117013a93aa0.squirrel@webmail.scss.tcd.ie> <7bb25df9c583e9553d4cf6b7b2c4d98c.squirrel@webmail.scss.tcd.ie> <4E896451.9080406@it.aoyama.ac.jp> <4E897679.8050100@gmx.de> 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 Subject: Re: [websec] Digest URI scheme 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, 03 Oct 2011 23:14:04 -0000 * Phillip Hallam-Baker wrote: >That adds significantly to the size of the identifiers. > >For my application the amount of space that is available to transport >the identifiers will be constrained. Thus if X bytes permits 100 sites >to be secured using a base64 encoding, use of base16 will drop that to >60 or so. So? Maybe for my application I want people to easily compare the URI with the output from GNU sha256sum which does not have an option for your particular Base 64 dialect, and maybe you should use Base 256 without a "digest:" prefix if size is so important? -- 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 hallam@gmail.com Mon Oct 3 16:20:36 2011 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 CFAE621F8EE0 for ; Mon, 3 Oct 2011 16:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.488 X-Spam-Level: X-Spam-Status: No, score=-3.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, 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 rIMPND942hMj for ; Mon, 3 Oct 2011 16:20:36 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id D40AA21F8591 for ; Mon, 3 Oct 2011 16:20:35 -0700 (PDT) Received: by gyd12 with SMTP id 12so4907304gyd.31 for ; Mon, 03 Oct 2011 16:23:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=gUo5bAFj/IiC0gJvoXa06tIWiDOWPDad3swunwgfamY=; b=vjV4rJeyv98rhJ/URUDtlxjuPtfPVOkUdtli0Hu9dJI7f5Y6q0ILGRsNfhTmV+ei7E YlrtA98/FYCBYIJR7Mr3M1mwSbCrO/z5Y7yK2kfDXXHScTrz+ei/oeTzW0fVtWUTVE1K eSkGLhqyybfTHNI9Z3QzI53kfYqYkm7hVHi8E= MIME-Version: 1.0 Received: by 10.101.27.34 with SMTP id e34mr430929anj.162.1317684216253; Mon, 03 Oct 2011 16:23:36 -0700 (PDT) Received: by 10.100.212.14 with HTTP; Mon, 3 Oct 2011 16:23:36 -0700 (PDT) In-Reply-To: <9bgk875tk3ue5g5uksii731purgptrq04k@hive.bjoern.hoehrmann.de> References: <7bd9badd19e0e9296750117013a93aa0.squirrel@webmail.scss.tcd.ie> <7bb25df9c583e9553d4cf6b7b2c4d98c.squirrel@webmail.scss.tcd.ie> <4E896451.9080406@it.aoyama.ac.jp> <4E897679.8050100@gmx.de> <9bgk875tk3ue5g5uksii731purgptrq04k@hive.bjoern.hoehrmann.de> Date: Mon, 3 Oct 2011 19:23:36 -0400 Message-ID: From: Phillip Hallam-Baker To: Bjoern Hoehrmann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: websec Subject: Re: [websec] Digest URI scheme 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, 03 Oct 2011 23:20:36 -0000 I have implemented Base64 from scratch many times. It takes about 30 lines. If that is too hard it is easy enough to swap the characters over. Base 256 would use a whole rack of characters that are illegal in URIs. Isn't the alleged point of free software that it is easy to add in features= ? On Mon, Oct 3, 2011 at 7:17 PM, Bjoern Hoehrmann wrote: > * Phillip Hallam-Baker wrote: >>That adds significantly to the size of the identifiers. >> >>For my application the amount of space that is available to transport >>the identifiers will be constrained. Thus if X bytes permits 100 sites >>to be secured using a base64 encoding, use of base16 will drop that to >>60 or so. > > So? Maybe for my application I want people to easily compare the URI > with the output from GNU sha256sum which does not have an option for > your particular Base 64 dialect, and maybe you should use Base 256 > without a "digest:" prefix if size is so important? > -- > Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoehr= mann.de > Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 http://www.bjoernsworld= .de > 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev= .de/ > --=20 Website: http://hallambaker.com/ From derhoermi@gmx.net Mon Oct 3 16:46:21 2011 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 D516521F8F40 for ; Mon, 3 Oct 2011 16:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.279 X-Spam-Level: X-Spam-Status: No, score=-3.279 tagged_above=-999 required=5 tests=[AWL=-0.680, 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 BS+3S13Lvxli for ; Mon, 3 Oct 2011 16:46:21 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id A5A8E21F8F12 for ; Mon, 3 Oct 2011 16:46:15 -0700 (PDT) Received: (qmail invoked by alias); 03 Oct 2011 23:49:17 -0000 Received: from dslb-094-222-152-232.pools.arcor-ip.net (EHLO HIVE) [94.222.152.232] by mail.gmx.net (mp025) with SMTP; 04 Oct 2011 01:49:17 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1+pwawhwEOpXRExLq3cs+lC4i+E5x0be/7TxFVVN2 So5JItQ2zLuMes From: Bjoern Hoehrmann To: Phillip Hallam-Baker Date: Tue, 04 Oct 2011 01:49:22 +0200 Message-ID: References: <7bb25df9c583e9553d4cf6b7b2c4d98c.squirrel@webmail.scss.tcd.ie> <4E896451.9080406@it.aoyama.ac.jp> <4E897679.8050100@gmx.de> <9bgk875tk3ue5g5uksii731purgptrq04k@hive.bjoern.hoehrmann.de> 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 Subject: Re: [websec] Digest URI scheme 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, 03 Oct 2011 23:46:21 -0000 * Phillip Hallam-Baker wrote: >I have implemented Base64 from scratch many times. It takes about 30 >lines. If that is too hard it is easy enough to swap the characters >over. > >Base 256 would use a whole rack of characters that are illegal in URIs. > >Isn't the alleged point of free software that it is easy to add in features? You started this thread saying "it would be better if we had a single format". How about you abandon this idea, you call your scheme "d64:" to keep things concise, and the rest of us develop our own format? -- 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 hallam@gmail.com Mon Oct 3 17:00:43 2011 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 9C8B621F8D8B for ; Mon, 3 Oct 2011 17:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.488 X-Spam-Level: X-Spam-Status: No, score=-3.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, 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 IGAJxjknzMbD for ; Mon, 3 Oct 2011 17:00:43 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id E73FF21F8D83 for ; Mon, 3 Oct 2011 17:00:42 -0700 (PDT) Received: by ywm3 with SMTP id 3so1705598ywm.31 for ; Mon, 03 Oct 2011 17:03:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=doAi/AFZnpglS6LoLmRjQJ/kddd/6Fbspes/5XGsRTQ=; b=T38VQ8tt9PZEsxWaiY0rKVaokr7DvZQZVg1kd60/Y9BvhJnhr/pNkI5Lw78UqnQMso sK0Jcgmb61IvzAAu44aN4RYX6nxoOFlonX00UpKwX0xZ3Xu/svK2vZ3fqAkzqA1IBiki TqLZBiGceqzEq4xjLBNeYXc7AsWwkg6JnwOek= MIME-Version: 1.0 Received: by 10.101.28.40 with SMTP id f40mr490474anj.30.1317686626380; Mon, 03 Oct 2011 17:03:46 -0700 (PDT) Received: by 10.100.212.14 with HTTP; Mon, 3 Oct 2011 17:03:46 -0700 (PDT) In-Reply-To: References: <7bb25df9c583e9553d4cf6b7b2c4d98c.squirrel@webmail.scss.tcd.ie> <4E896451.9080406@it.aoyama.ac.jp> <4E897679.8050100@gmx.de> <9bgk875tk3ue5g5uksii731purgptrq04k@hive.bjoern.hoehrmann.de> Date: Mon, 3 Oct 2011 20:03:46 -0400 Message-ID: From: Phillip Hallam-Baker To: Bjoern Hoehrmann Content-Type: text/plain; charset=ISO-8859-1 Cc: websec Subject: Re: [websec] Digest URI scheme 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, 04 Oct 2011 00:00:43 -0000 On Mon, Oct 3, 2011 at 7:49 PM, Bjoern Hoehrmann wrote: > * Phillip Hallam-Baker wrote: >>I have implemented Base64 from scratch many times. It takes about 30 >>lines. If that is too hard it is easy enough to swap the characters >>over. >> >>Base 256 would use a whole rack of characters that are illegal in URIs. >> >>Isn't the alleged point of free software that it is easy to add in features? > > You started this thread saying "it would be better if we had a single > format". How about you abandon this idea, you call your scheme "d64:" > to keep things concise, and the rest of us develop our own format? Implicit in the idea of a single format is the notion that at least some people will write code for it. Compatibility with unix command line tools would rank really low in my list of priorities if at all. They are easily written and easily added to. That is the whole point of them. I was planning to write a command line tool for supporting the format anyway. There seems to be no man page entry for di. How about something like: di [-d ] [-e ] [-http domain]* input output If someone wants to compare with a dumb string comparison they need do the necessary case conversions and chop off the parameters part since that is not canonical. -- Website: http://hallambaker.com/ From duerst@it.aoyama.ac.jp Mon Oct 3 18:04:21 2011 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 1BB4921F8EB5 for ; Mon, 3 Oct 2011 18:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.736 X-Spam-Level: X-Spam-Status: No, score=-99.736 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, 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 p9SehwfJz7eA for ; Mon, 3 Oct 2011 18:04:20 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 5332121F8EAB for ; Mon, 3 Oct 2011 18:04:19 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id p94178ef022863 for ; Tue, 4 Oct 2011 10:07:11 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 24b4_0e72_2e724e84_ee25_11e0_b7c4_001d096c5782; Tue, 04 Oct 2011 10:07:08 +0900 Received: from [IPv6:::1] ([133.2.210.1]:42438) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 4 Oct 2011 10:07:11 +0900 Message-ID: <4E8A5C38.5030001@it.aoyama.ac.jp> Date: Tue, 04 Oct 2011 10:07:04 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <7bd9badd19e0e9296750117013a93aa0.squirrel@webmail.scss.tcd.ie> <7bb25df9c583e9553d4cf6b7b2c4d98c.squirrel@webmail.scss.tcd.ie> <4E896451.9080406@it.aoyama.ac.jp> <4E897679.8050100@gmx.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: websec Subject: Re: [websec] Digest URI scheme 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, 04 Oct 2011 01:04:21 -0000 On 2011/10/03 23:13, Phillip Hallam-Baker wrote: > On Mon, Oct 3, 2011 at 4:46 AM, Julian Reschke wrote: >> Also keep in mind that if you use "/" for a different purpose than >> hierarchy, surprising things will happen when relative references are >> resolved. It's good to avoid them in this case. > > That is probably the killer argument here. It's not a killer argument, because these URIs aren't going to be used in a relative form (except potentially leaving out the scheme, which is irrelevant), and aren't going to be used as base URIs (same irrelevant exception again). Paul is actually right on that one. But it's okay to stay on the safe side, and to comply with a SHOULD in RFC 3986. However, there's no reason for shouting about this on either side, or for coming up with MUSTs where there are none (only SHOULDs). > I suggest that we use Base 64 Encoding with URL and Filename Safe Alphabet: > > http://tools.ietf.org/html/rfc4648#page-7 Makes sense. Actually, http://tools.ietf.org/html/rfc4648#section-5 is a better pointer. > This would mean using the characters - and _ for char codes 63 and 64 > and dropping the padding completely. Yes. I wish RFC 4648 would say this upfront, and move the reasons why other characters such as '.' and '~' were not chosen later. And the character numbers, in RFC 4648 terminology, are the 62:nd and 63:rd character. > I am strongly tending towards: > > "digest:" algorithm ':' base64(content) ['?' tag '=' value [ '&' tag > '=' value]* ] > > Where: > > algorithm - is from the IANA registry discussed earlier > base64 - is the RFC 4648 file and url safe version > content is the referenced content > tag is taken from the URL encoding precedent > value is taken from the URL encoding precedent > > > If people need a locator then it would be formed from a tag/value pair > as follows: > > tag = "http" > value = domain name Can you explain why we need a domain name as a locator? Wouldn't tag = "uri" value = URI be much more general? > The corresponding url would be formed as: > > "http://" + domain-name + "/.well-known/digest/" + algorithm + "/" + > base64(content) > > This can then be transformed inside the Web Server as is necessary to > support the constraints of the local file system. Sorry, but I'm much more an URI expert than a security expert. Can you explain what all that is about? What would be at that location? Why all this hard-coded stuff? > Other protocol tags can be specified to support alternative protocols. So it would be possible to use all the URI scheme names as tag names? Like tag = "https" tag = "ftp" ... Then we'd get collisions between URI schemes and other tag uses. > Stephen's DECADE application then becomes a special case of the > general form of the identifier. It is essentially a different lookup > protocol. > > > Some additional tweakage: > > For certain applications the full 256 bits of the content URL are unnecessary. Which 256 bits exactly? > If an encryption key is in use then the encryption key can be used to > form part of the identifier for the purpose of distinguishing > identifiers. > > For example: > > let the plaintext be p and the encryption key be k. > > The identifier might be > > digest:sha-2-128:Ry_yKcfFmWj4cs9ucvm10Q?enc=aes&key=491X0pTnLkJHFN_AVctJUA > > Where sha-2-128 is SHA256 truncated to 128 bits as per NIST instructions. > > > The collision resistant digest identifier for the content is then formed as: > > digest + E ( digest, key ) > > "Ry_yKcfFmWj4cs9ucvm10Q" + AES ("Ry_yKcfFmWj4cs9ucvm10Q", > "491X0pTnLkJHFN_AVctJUA") > > The result is an identifier of 256 bits that has 128 bits worth of > authentication security, 128 bits worth of confidentiality security > and 128 bits worth of birthday attack collision resistance. > > > For the current WebSec use cases, only the digest is actually > required. I am not entirely convinced, but I suspect that for our use > cases the truncated identifier would be sufficient since we rely only > on the 2nd preimage resistance property. If that kind of security magic works, then it's great if we can express it in the URI. Regards, Martin. From duerst@it.aoyama.ac.jp Mon Oct 3 18:26:31 2011 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 F26AF21F8BEF for ; Mon, 3 Oct 2011 18:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.737 X-Spam-Level: X-Spam-Status: No, score=-99.737 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, 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 7JjeRJAnQ9mm for ; Mon, 3 Oct 2011 18:26:29 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 16ED921F8C4F for ; Mon, 3 Oct 2011 18:26:28 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id p941TWdU006413 for ; Tue, 4 Oct 2011 10:29:32 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 3105_1eae_4f8629b2_ee28_11e0_9c5f_001d096c566a; Tue, 04 Oct 2011 10:29:32 +0900 Received: from [IPv6:::1] ([133.2.210.1]:35239) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 4 Oct 2011 10:29:35 +0900 Message-ID: <4E8A6178.5090101@it.aoyama.ac.jp> Date: Tue, 04 Oct 2011 10:29:28 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <7bd9badd19e0e9296750117013a93aa0.squirrel@webmail.scss.tcd.ie> <7bb25df9c583e9553d4cf6b7b2c4d98c.squirrel@webmail.scss.tcd.ie> <4E896451.9080406@it.aoyama.ac.jp> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: websec Subject: Re: [websec] Digest URI scheme 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, 04 Oct 2011 01:26:31 -0000 On 2011/10/03 22:30, Phillip Hallam-Baker wrote: > On Mon, Oct 3, 2011 at 3:29 AM, "Martin J. Dürst" > wrote: >> On 2011/09/30 23:40, stephen.farrell@cs.tcd.ie answered Phillip >> Hallam-Baker: > One of the things I was thinking about was that for our case the > essence of the digest is really the digest part. The domain is really > just a location hint. Why stick at just one domain? If the same > content is present at foo.com and bar.com why not have an identifier > that can specify both: > > dig:sha-256:wkjfhskjhfskjdhkjdshfjksdkfjhsdkfjh$#=?loc=foo.com&loc=bar.com&ct=text/plain The example here is a bit more explicit (and doesn't use 'http' as a tag name), so I'm asking again: Why isn't this something like: dig:sha-256:wkjfhskjhfskjdhkjdshfjksdkfjhsdkfjh$#=?loc=http://foo.com/path/to/content.ext&loc=http://bar.com/path/to/content.ext&ct=text/plain (the slashes here should be %-encoded, but I left them as is for easy readability) > Now I know that we do not need this for our particular application, > but if we are going to come up with a common scheme with DECADE we > have to meet their use cases as well as out own. > > I have some other ideas that would be interesting in the DECADE > context. Right back in 1995 Rohit Khare and myself were fooling about > with identifiers that had decryption keys built in. > > > For their particular application, the ability to send a single > identifier that allows the content to be uniquely identified, > authenticated and located would be quite interesting I think. > > Adding a symmetric decryption key means that the set of people who can > read the plaintext is precisely the set of people with access to the > plaintext plus the people who can access the identifier. The host on > which confidential content resides is thus moved outside the zone > where security concerns apply. I think I get the idea, but wouldn't that be quite similar to URIs including passwords? That has been widely frowned upon since quite some time, to the extent that it has been kicked out from the generic URI syntax (although it can be quite convenient on occasion). >>>> I note that you have a content type, which I have but someone here was >>>> objecting to. I consider the content type to be essential meta-data >>>> for obvious security reasons. >>> Our use-case for that is for cases where the named object actually >>> arrives in some wrapped form (e.g. encrypted) and you need to know >>> the "inner" content type. However, I could see it being used otherwise >>> or being dropped as things progress. >> >> Just curious: Why would you need to know the inner content type? Wouldn't >> the wrapper contain that information? > > Probably so that they can perform negotiation. > > If the consumer is a video player, it wants to be able to select > content that it knows how to play. In most cases the player will be > grabbing the bits and negotiating the decryption capability in > parallel. Ok. I was assuming that the 'outer' content is what's hashed, but it looks like the outer wrapping (compression or so) is only used on transport, and it's the 'inner' content that's hashed. Then that makes sense (using a digest of the outer content but having the content type apply to the inner content would be quite weird in my opinion). > In my case the concern is that it should be possible to use the > generalized form of this identifier as a secure URL for referencing > static content from a secure Web page. > > So imagine that we have anybank.com that has its main pages on HTTPS > but has the images etc. on a separate server that really does not need > SSL for any purpose other than authenticating the source. > > It would be a trivial matter to write a script that could transform > such Web pages into Web pages with 'hardened' URLs of the digest form > being discussed here. This would in turn provide a long term answer to > the problem of efficiently supporting the strict security concerns we > discuss here without the overhead of SSL everywhere. So e.g. the Anybank logo is not a secret, so it can go over HTTP in the open, and we don't care about where it comes from (even from a bad guy) as long as it's the same logo, which we can check with the digest. > The only problem with that being that the content-type is actually a > security sensitive piece of meta-data and manipulation of > content-types is a major attack vector (probably the fastest growing > at the mo). So, just as a totally hypothetical example, the attacker sends exactly the same bits, but claims they are image/png instead of image/jpg, and the user sees something different (e.g. an 'okay' button instead of a 'cancel' button). For these cases of faking metadata, wouldn't it be better to have some general way of making the metadata part of the content that is hashed? Regards, Martin. From hallam@gmail.com Mon Oct 3 18:48:19 2011 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 CE7CA21F8E26 for ; Mon, 3 Oct 2011 18:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.04 X-Spam-Level: X-Spam-Status: No, score=-3.04 tagged_above=-999 required=5 tests=[AWL=-0.341, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, MIME_8BIT_HEADER=0.3, 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 9BLGgINA8YcF for ; Mon, 3 Oct 2011 18:48:18 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id BC86921F8E0E for ; Mon, 3 Oct 2011 18:48:18 -0700 (PDT) Received: by yxt33 with SMTP id 33so3178yxt.31 for ; Mon, 03 Oct 2011 18:51:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=0TWD8uGUP7EV7FTmqA2UQPFA/iVp1waydv3f/L/t+Fw=; b=xlskQsZwEyutIVPP3xqf7/P1sUYxWiTb3qlq4Juiu8nQutHrlyVc27ww7hT6orKmMa pl7V68N0xfxtlpP6GKAFUUK8CtTM9wT0ON2FRduGqIEFOUN4j7YOGHmsD91Zr8rqK3d8 XFqeYZGW55U2Q3t0dkf4VjnkzhbkXVWtJ8q6I= MIME-Version: 1.0 Received: by 10.101.218.6 with SMTP id v6mr494902anq.140.1317693081255; Mon, 03 Oct 2011 18:51:21 -0700 (PDT) Received: by 10.100.212.14 with HTTP; Mon, 3 Oct 2011 18:51:21 -0700 (PDT) In-Reply-To: <4E8A5C38.5030001@it.aoyama.ac.jp> References: <7bd9badd19e0e9296750117013a93aa0.squirrel@webmail.scss.tcd.ie> <7bb25df9c583e9553d4cf6b7b2c4d98c.squirrel@webmail.scss.tcd.ie> <4E896451.9080406@it.aoyama.ac.jp> <4E897679.8050100@gmx.de> <4E8A5C38.5030001@it.aoyama.ac.jp> Date: Mon, 3 Oct 2011 21:51:21 -0400 Message-ID: From: Phillip Hallam-Baker To: =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: websec Subject: Re: [websec] Digest URI scheme 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, 04 Oct 2011 01:48:19 -0000 On Mon, Oct 3, 2011 at 9:07 PM, "Martin J. D=FCrst" wrote: > On 2011/10/03 23:13, Phillip Hallam-Baker wrote: >> I suggest that we use Base 64 Encoding with URL and Filename Safe >> Alphabet: >> >> http://tools.ietf.org/html/rfc4648#page-7 > > Makes sense. Actually, http://tools.ietf.org/html/rfc4648#section-5 is a > better pointer. The other name for this scheme is 'filesafe'. While it is not particularly relevant to our current use cases, the ability to convert the stem portion of the URI into a filename directly is going to be very useful for DECADE and for many other purposes. >> This would mean using the characters - and _ for char codes 63 and 64 >> and dropping the padding completely. > > Yes. I wish RFC 4648 would say this upfront, and move the reasons why oth= er > characters such as '.' and '~' were not chosen later. And the character > numbers, in RFC 4648 terminology, are the 62:nd and 63:rd character. Yes, that is right. >> I am strongly tending towards: >> >> "digest:" algorithm ':' base64(content) ['?' tag '=3D' value [ '&' tag >> '=3D' value]* ] >> >> Where: >> >> algorithm - is from the IANA registry discussed earlier >> base64 - is the RFC 4648 file and url safe version >> content is the referenced content >> tag is taken from the URL encoding precedent >> value is taken from the URL encoding precedent >> >> >> If people need a locator then it would be formed from a tag/value pair >> as follows: >> >> tag =3D "http" >> value =3D domain name > > Can you explain why we need a domain name as a locator? Wouldn't We don't need it, but the DECADE folk need to have it in somewhere. There are two basic options: 1) Use the authority slot. This results in a URL with the form ni:///alg/di= gest 2) Use a parameter on the query slot. The advantage of 1 is mostly familiarity. The disadvantage is that it suggests that the 'authority' controlling the interpretation of the name is the domain and the whole point of the digest schemes is that the place you get the bits from becomes irrelevant. The advantage of 2 is that there can be multiple locators. I think we need comments from the DECADE folk on that to know what to do. > tag =3D "uri" > value =3D URI > > be much more general? Actually this is actually a very useful case that is worth calling out separately. Again this is something that I had thought about but not put in the draft because I did not want to add in functionality that went too far beyond what DECADE and WEBSEC might require. Larry Masinter suggested a URI scheme that was something like this but focused on just that use case. This creates a URI whose semantics are roughly speaking 'content retrieved from the URI=3Dfoo. It would be best paired with a date parameter. This does not remove the need for the locator however. For example, let us say that you want to create a link to the text of rfc 822 which you have retrieved on a particular date and pickled somewhere. The digest URI might look something like: di:sha-256:B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc? http=3Ddi.example.com&uri=3Dhttp://www.ietf.org/rfc/rfc822.txt&date=3D2= 011-10-3:21:00 This being a strong reference to the content that was downloaded from the uri specified on the date specified and a hint that it can be found in the specified content registry(s) >> The corresponding url would be formed as: >> >> "http://" + domain-name + "/.well-known/digest/" + algorithm + "/" + >> base64(content) >> >> This can then be transformed inside the Web Server as is necessary to >> support the constraints of the local file system. > > Sorry, but I'm much more an URI expert than a security expert. Can you > explain what all that is about? What would be at that location? Why all t= his > hard-coded stuff? The alternative would be to bloat the identifier used as the reference in documents and protocols with a second set of information to allow it to be retrieved from the specified repositories. > >> Other protocol tags can be specified to support alternative protocols. > > So it would be possible to use all the URI scheme names as tag names? Lik= e > tag =3D "https" > tag =3D "ftp" No, not unless there was an explicit mapping defined for that protocol. Now clearly, if an 'ftp' parameter tag was defined it should only be for something involving ftp as the transport. But there would have to be a document to specify the protocol mapping. >> For certain applications the full 256 bits of the content URL are >> unnecessary. > > Which 256 bits exactly? Sorry the content digest. >> The collision resistant digest identifier for the content is then formed >> as: >> >> digest + E ( digest, key ) >> >> "Ry_yKcfFmWj4cs9ucvm10Q" + AES ("Ry_yKcfFmWj4cs9ucvm10Q", >> "491X0pTnLkJHFN_AVctJUA") >> >> The result is an identifier of 256 bits that has 128 bits worth of >> authentication security, 128 bits worth of confidentiality security >> and 128 bits worth of birthday attack collision resistance. >> >> >> For the current WebSec use cases, only the digest is actually >> required. I am not entirely convinced, but I suspect that for our use >> cases the truncated identifier would be sufficient since we rely only >> on the 2nd preimage resistance property. > > If that kind of security magic works, then it's great if we can express i= t > in the URI. I think it should work. There are some corner issues to deal with like where to stick the IV (it can be prepended to the cipherstream). I have a rough cut in the draft. --=20 Website: http://hallambaker.com/ From Martin.Thomson@commscope.com Mon Oct 3 19:00:55 2011 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 D909C21F8E47; Mon, 3 Oct 2011 19:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.612 X-Spam-Level: X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[AWL=-0.013, 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 YjxV1IoLdNv8; Mon, 3 Oct 2011 19:00:55 -0700 (PDT) Received: from cdcsmgw01.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id 528E121F8E1B; Mon, 3 Oct 2011 19:00:55 -0700 (PDT) X-AuditID: 0a0404e8-b7c2eae000002297-56-4e8a698e2b63 Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id 6D.85.08855.E896A8E4; Mon, 3 Oct 2011 21:03:58 -0500 (CDT) Received: from CDCE10HC2.commscope.com (10.86.28.22) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.192.1; Mon, 3 Oct 2011 21:03:58 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by CDCE10HC2.commscope.com (10.86.28.22) with Microsoft SMTP Server (TLS) id 14.1.339.1; Mon, 3 Oct 2011 21:03:57 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 4 Oct 2011 10:03:47 +0800 From: "Thomson, Martin" To: Phillip Hallam-Baker , websec , "khare@alumni.caltech.edu" , "decade@ietf.org" Date: Tue, 4 Oct 2011 10:02:40 +0800 Thread-Topic: Digest Scheme URI: .well-known Thread-Index: AcyCDMz1YLW8mhYoSQGN6kly0Ph9mgAHCnmg Message-ID: <27AFD040F6F8AA4193E0614E2E3AF9C910D2F0CA53@SISPE7MB1.commscope.com> References: 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 X-Brightmail-Tracker: AAAAAA== Subject: [websec] Digest Scheme URI: .well-known 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, 04 Oct 2011 02:00:56 -0000 On 2011-10-04 at 07:40:56, Phillip Hallam-Baker wrote: > http://www.ietf.org/id/draft-hallambaker-digesturi-01.txt ... > * Scheme for specifying one or more locations for retrieval Please don't use /.well-known/ without some sort of extra qualification. M= y "mu" digest produces base-64 output that could collide with existing regi= strations in that space. It's just like a game of "battleship". I'm reall= y hoping to hit "host-meta" some day... What do you think of: di:sha-256:B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc?r=3Dhttps://di.exa= mple.com/r/ or di:sha-256:B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc?r=3Dhttps://di.exa= mple.com/r/{d} =09 ...where retrieval is performed using: https://di.example.com/r/B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc > * Scheme for decrypting encrypted stored content. I don't see the encryption and content type parameters as a necessity. If = the core goal of the document is to identify a resource, then providing res= ource metadata is, as a generic capability, very useful. However, the spec= ific subset of cases you have chosen exhibits a bias that might not fit wit= h all future uses. From hallam@gmail.com Mon Oct 3 19:50:50 2011 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 951C421F8EAC; Mon, 3 Oct 2011 19:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.488 X-Spam-Level: X-Spam-Status: No, score=-3.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, 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 vQ9xOKaFI1V6; Mon, 3 Oct 2011 19:50:50 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id D35A321F8EA9; Mon, 3 Oct 2011 19:50:49 -0700 (PDT) Received: by yxt33 with SMTP id 33so52897yxt.31 for ; Mon, 03 Oct 2011 19:53:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=mQUy8Khe97BKwiZBbPMbo+QXsSWBPN9XJhcl7ngOJPg=; b=Mhoc8QYIOdqgBrhbaUYI2fXG05gwvavMiixVIq6HFeMI0tvVUVN62eJfm6dcg4e5ZJ iOL9TfWXy1EgSzNhEuDT4Xn/e9ayhL/avzXHZWUGnzngPiGF154A5m1D6nJumriHKT6r /ua/0h407oxrETQtkmcGYcrlyeD2Fx2Q2KR+g= MIME-Version: 1.0 Received: by 10.100.82.6 with SMTP id f6mr558583anb.52.1317696833659; Mon, 03 Oct 2011 19:53:53 -0700 (PDT) Received: by 10.100.212.14 with HTTP; Mon, 3 Oct 2011 19:53:53 -0700 (PDT) In-Reply-To: <27AFD040F6F8AA4193E0614E2E3AF9C910D2F0CA53@SISPE7MB1.commscope.com> References: <27AFD040F6F8AA4193E0614E2E3AF9C910D2F0CA53@SISPE7MB1.commscope.com> Date: Mon, 3 Oct 2011 22:53:53 -0400 Message-ID: From: Phillip Hallam-Baker To: "Thomson, Martin" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "khare@alumni.caltech.edu" , "decade@ietf.org" , websec Subject: Re: [websec] Digest Scheme URI: .well-known 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, 04 Oct 2011 02:50:50 -0000 Ooops, that was an oversight in the draft, sorry. I did actually go so far as to specify the allocation of a di .well-known code point, I just forgot to use it! The URL was meant to be: https://di.example.com/.well-known/di/sha-256/B_K97zTtFuOhug... Sorry for the confusion. On Mon, Oct 3, 2011 at 10:02 PM, Thomson, Martin wrote: > On 2011-10-04 at 07:40:56, Phillip Hallam-Baker wrote: >> http://www.ietf.org/id/draft-hallambaker-digesturi-01.txt > ... >> * Scheme for specifying one or more locations for retrieval > > Please don't use /.well-known/ without some sort of extra qualification. = =A0My "mu" digest produces base-64 output that could collide with existing = registrations in that space. =A0It's just like a game of "battleship". =A0I= 'm really hoping to hit "host-meta" some day... > > What do you think of: > > =A0di:sha-256:B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc?r=3Dhttps://di.= example.com/r/ > or > =A0di:sha-256:B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQjy6fkc?r=3Dhttps://di.= example.com/r/{d} > > ...where retrieval is performed using: If we went this route I can't see why the digest would appear anywhere other than the end so why not just specify it as a prefix? The slippery slope there would be people looking to take parts of the digest and the algorithm in mix 'n match type approaches. Since this is a domain specified in a fairly tightly controlled URL, I don't see why collisions with other services can't be handled by people creating a new sub-domain specially for di content if required. I am not completely happy with .well-known, it is a yucky approach, but it is now sufficiently well established that it is probably OK. >> * Scheme for decrypting encrypted stored content. > > I don't see the encryption and content type parameters as a necessity. = =A0If the core goal of the document is to identify a resource, then providi= ng resource metadata is, as a generic capability, very useful. =A0However, = the specific subset of cases you have chosen exhibits a bias that might not= fit with all future uses. > True in the case of encryption, but I prefer to do stuff once if possible. The fact that there are parameters and the space is extensible means that there is room for other uses. The content type is essential meta-data if the digest is going to be used to create a strong reference to the specified content. Otherwise the attacker can repurpose an image/jpeg as application/script. This works much better than it should because most processors simply ignore content they don't understand and helpfully try to resynchronize. This creates attacks where the attacker can smuggle his malware into a photosharing site and then get links to it. It would create a new class of cross-site scripting attack if it was not present. --=20 Website: http://hallambaker.com/ From James.H.Manger@team.telstra.com Mon Oct 3 20:02:13 2011 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 8DA5A21F8E0E; Mon, 3 Oct 2011 20:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.223 X-Spam-Level: X-Spam-Status: No, score=-2.223 tagged_above=-999 required=5 tests=[AWL=-1.322, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, 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 fffary1hVsbq; Mon, 3 Oct 2011 20:02:13 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 934F221F862F; Mon, 3 Oct 2011 20:02:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.68,483,1312120800"; d="scan'208";a="47419232" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipoavi.tcif.telstra.com.au with ESMTP; 04 Oct 2011 14:05:15 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6488"; a="38383551" Received: from wsmsg3703.srv.dir.telstra.com ([172.49.40.171]) by ipcbvi.tcif.telstra.com.au with ESMTP; 04 Oct 2011 14:05:15 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3703.srv.dir.telstra.com ([172.49.40.171]) with mapi; Tue, 4 Oct 2011 14:05:14 +1100 From: "Manger, James H" To: "Thomson, Martin" , Phillip Hallam-Baker , websec , "decade@ietf.org" Date: Tue, 4 Oct 2011 14:05:12 +1100 Thread-Topic: Digest Scheme URI: .well-known Thread-Index: AcyCDMz1YLW8mhYoSQGN6kly0Ph9mgAHCnmgAAW9NsA= Message-ID: <255B9BB34FB7D647A506DC292726F6E112902B3047@WSMSG3153V.srv.dir.telstra.com> References: <27AFD040F6F8AA4193E0614E2E3AF9C910D2F0CA53@SISPE7MB1.commscope.com> In-Reply-To: <27AFD040F6F8AA4193E0614E2E3AF9C910D2F0CA53@SISPE7MB1.commscope.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [websec] Digest Scheme URI: .well-known 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, 04 Oct 2011 03:02:13 -0000 > Please don't use /.well-known/ without some sort of extra qualification. draft-hallambaker-digesturi-01.txt registers the "di" well-known suffix in = section 5.2. Presumably this suffix is supposed to be used in the well-known URIs in sec= tion 3.2.2.2 and 2.1.3, but was accidentally omitted. Example: http://di.example.com/.well-known/di/B_K97zTtFuOhug27fke4_Zgc4Myz4b_lZNgsQj= y6fkc -- James Manger From James.H.Manger@team.telstra.com Mon Oct 3 20:19:49 2011 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 DA60821F8EFA; Mon, 3 Oct 2011 20:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=-1.265, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, 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 K2XtyRAA2lGS; Mon, 3 Oct 2011 20:19:49 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id E219D21F8EF9; Mon, 3 Oct 2011 20:19:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.68,483,1312120800"; d="scan'208";a="51887461" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipoani.tcif.telstra.com.au with ESMTP; 04 Oct 2011 14:22:51 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6488"; a="38719659" Received: from wsmsg3705.srv.dir.telstra.com ([172.49.40.203]) by ipccni.tcif.telstra.com.au with ESMTP; 04 Oct 2011 14:22:51 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3705.srv.dir.telstra.com ([172.49.40.203]) with mapi; Tue, 4 Oct 2011 14:22:50 +1100 From: "Manger, James H" To: Phillip Hallam-Baker , websec , "khare@alumni.caltech.edu" , "decade@ietf.org" Date: Tue, 4 Oct 2011 14:22:49 +1100 Thread-Topic: [websec] Updated Digest Scheme URI: truncated digests Thread-Index: AcyCDMzQenVqQDCeSpGZiDDBiDI2pgANiFpA Message-ID: <255B9BB34FB7D647A506DC292726F6E112902B30B7@WSMSG3153V.srv.dir.telstra.com> References: In-Reply-To: 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [websec] Updated Digest Scheme URI: truncated digests 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, 04 Oct 2011 03:19:50 -0000 > di:sha-128:B_K97zTtFuOhug27fke4_Q?enc=3Daes-cbc:Fw3x20nEKfq6FDGzq7ttIQ Instead if defining new names for truncated digests, why not simply include= a truncated digest with the existing algorithm name? You can determine the= truncation (in bytes) from the length of the base64url-encoding so there i= s no ambiguity. di:sha-256:B_K97zTtFuOhug27fke4_Q The only downside I see is the risk of bad implementations accepting a dige= st truncated to, say, 1 byte (eg di:sha-256:Bw) instead of enforcing a mini= mum security level. -- James Manger From Martin.Thomson@commscope.com Mon Oct 3 21:44:08 2011 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 52D3A21F8F42; Mon, 3 Oct 2011 21:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.612 X-Spam-Level: X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[AWL=-0.013, 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 b+xVTP7z-Ixt; Mon, 3 Oct 2011 21:44:07 -0700 (PDT) Received: from cdcsmgw01.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id 522B221F8F41; Mon, 3 Oct 2011 21:44:06 -0700 (PDT) X-AuditID: 0a0404e8-b7c2eae000002297-1f-4e8a8fcefbe5 Received: from ACDCE7HC1.commscope.com ( [10.86.20.102]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id 23.17.08855.ECF8A8E4; Mon, 3 Oct 2011 23:47:10 -0500 (CDT) Received: from CDCE10HC1.commscope.com (10.86.28.21) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.192.1; Mon, 3 Oct 2011 23:47:10 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by CDCE10HC1.commscope.com (10.86.28.21) with Microsoft SMTP Server (TLS) id 14.1.339.1; Mon, 3 Oct 2011 23:47:09 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 4 Oct 2011 12:46:53 +0800 From: "Thomson, Martin" To: Phillip Hallam-Baker Date: Tue, 4 Oct 2011 12:46:49 +0800 Thread-Topic: Digest Scheme URI: .well-known Thread-Index: AcyCQNwp2CN2N48hS96Nc+vwmEe0dgAA2iPQ Message-ID: <27AFD040F6F8AA4193E0614E2E3AF9C910D2F0CA5D@SISPE7MB1.commscope.com> References: <27AFD040F6F8AA4193E0614E2E3AF9C910D2F0CA53@SISPE7MB1.commscope.com> 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 X-Brightmail-Tracker: AAAAAA== Cc: "khare@alumni.caltech.edu" , "decade@ietf.org" , websec Subject: Re: [websec] Digest Scheme URI: .well-known 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, 04 Oct 2011 04:44:08 -0000 On 2011-10-04 at 13:53:53, Phillip Hallam-Baker wrote: =20 > The URL was meant to be: >=20 > https://di.example.com/.well-known/di/sha-256/B_K97zTtFuOhug... ACK. =20 > If we went this route I can't see why the digest would appear anywhere=20 > other than the end so why not just specify it as a prefix? While this assumption is true for HTTP, can you say the same for other URI = schemes that support retrieval of the representation of a resource? To cit= e a (relatively bad) example: a 'pres:' URI supports retrieval using SIP (a= nd XMPP). Depending on circumstance, that looks like 'user@host' where use= r might filled with your digest bits. =20 > The slippery slope there would be people looking to take parts of the=20 > digest and the algorithm in mix 'n match type approaches. It might be better to ride the slope the whole way down. Include the whole= URI. You might also like to consider registering a Link relation (RFC 5988) for = "digest". > Since this is a domain specified in a fairly tightly controlled URL [...] That's a pretty big assumption, almost as much as I dislike the /.well-know= n/ use. > The content type is essential meta-data if the digest is going to be=20 > used to create a strong reference to the specified content. Otherwise=20 > the attacker can repurpose an image/jpeg as application/script. This=20 > works much better than it should because most processors simply ignore=20 > content they don't understand and helpfully try to resynchronize. You aren't making the world a less safe place if you leave the problem alon= e. Or have I missed something. What makes this scheme any worse for the a= ttack, other than its inherent opacity? Regarding de/encryption keys: Is it really the case that you need to decryp= t before calculating the digest? Excuse my ignorance, but for a file store= , I would have thought that encryption would want to come before storage. --MartinT From Martin.Thomson@commscope.com Mon Oct 3 21:50:22 2011 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 2407421F8F4F; Mon, 3 Oct 2011 21:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.612 X-Spam-Level: X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[AWL=-0.013, 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 IQ5n-jKify5j; Mon, 3 Oct 2011 21:50:21 -0700 (PDT) Received: from cdcsmgw02.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id 822E621F8F4E; Mon, 3 Oct 2011 21:50:21 -0700 (PDT) X-AuditID: 0a0404e9-b7cd4ae000004b3f-0f-4e8a91446f38 Received: from ACDCE7HC1.commscope.com ( [10.86.20.102]) by cdcsmgw02.commscope.com (Symantec Brightmail Gateway) with SMTP id 94.40.19263.4419A8E4; Mon, 3 Oct 2011 23:53:25 -0500 (CDT) Received: from CDCE10HC2.commscope.com (10.86.28.22) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.192.1; Mon, 3 Oct 2011 23:53:24 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by CDCE10HC2.commscope.com (10.86.28.22) with Microsoft SMTP Server (TLS) id 14.1.339.1; Mon, 3 Oct 2011 23:53:23 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 4 Oct 2011 12:53:19 +0800 From: "Thomson, Martin" To: "Manger, James H" , Phillip Hallam-Baker , websec , "khare@alumni.caltech.edu" , "decade@ietf.org" Date: Tue, 4 Oct 2011 12:53:18 +0800 Thread-Topic: [websec] Updated Digest Scheme URI: truncated digests Thread-Index: AcyCDMzQenVqQDCeSpGZiDDBiDI2pgANiFpAAAN3yLA= Message-ID: <27AFD040F6F8AA4193E0614E2E3AF9C910D2F0CA5E@SISPE7MB1.commscope.com> References: <255B9BB34FB7D647A506DC292726F6E112902B30B7@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112902B30B7@WSMSG3153V.srv.dir.telstra.com> 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 X-Brightmail-Tracker: AAAAAA== Subject: Re: [websec] Updated Digest Scheme URI: truncated digests 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, 04 Oct 2011 04:50:22 -0000 On 2011-10-04 at 14:22:49, Manger, James H wrote: > > di:sha-128:B_K97zTtFuOhug27fke4_Q?enc=3Daes-cbc:Fw3x20nEKfq6FDGzq7ttIQ >=20 > Instead if defining new names for truncated digests, why not simply=20 > include a truncated digest with the existing algorithm name? You can=20 > determine the truncation (in bytes) from the length of the base64url-=20 > encoding so there is no ambiguity. You would have to specify that the truncation is by the byte, rather than b= y 6-bit slices. I see that you carefully used 'Bw' instead of 'B_' :) I'll note that base16 avoids that particular problem. > The only downside I see is the risk of bad implementations accepting > a digest truncated to, say, 1 byte (eg di:sha-256:Bw) instead of > enforcing a minimum security level. It might be enough to say that truncation is possible, though it increases = the chances of collision. ...and that you should care about that. --Martin From julian.reschke@gmx.de Tue Oct 4 00:36:56 2011 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 23B5621F8B94 for ; Tue, 4 Oct 2011 00:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.309 X-Spam-Level: X-Spam-Status: No, score=-103.309 tagged_above=-999 required=5 tests=[AWL=-0.710, 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 QcEFgwNSpmg4 for ; Tue, 4 Oct 2011 00:36:55 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 081F621F8AE6 for ; Tue, 4 Oct 2011 00:36:54 -0700 (PDT) Received: (qmail invoked by alias); 04 Oct 2011 07:39:55 -0000 Received: from p5DCC8376.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.131.118] by mail.gmx.net (mp006) with SMTP; 04 Oct 2011 09:39:55 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18OU5wj5ogOi+F8p452heXTNR0q3R1JzaAs9lxlCI 8YduMbWDNJW+uS Message-ID: <4E8AB841.7050606@gmx.de> Date: Tue, 04 Oct 2011 09:39:45 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <7bd9badd19e0e9296750117013a93aa0.squirrel@webmail.scss.tcd.ie> <7bb25df9c583e9553d4cf6b7b2c4d98c.squirrel@webmail.scss.tcd.ie> <4E896451.9080406@it.aoyama.ac.jp> <4E897679.8050100@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: websec WG , Paul Hoffman Subject: Re: [websec] Digest URI scheme 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, 04 Oct 2011 07:36:56 -0000 On 2011-10-03 19:12, Phillip Hallam-Baker wrote: > On Mon, Oct 3, 2011 at 1:05 PM, Paul Hoffman wrote: >> On Oct 3, 2011, at 9:22 AM, Phillip Hallam-Baker wrote: >> >>> URLs are used in cases where hierarchy is assumed. >> >> I didn't see such use cases in your draft, nor in Stephen's. Maybe you'll put them in your next proposal. > > As Julian correctly pointed out, a generic URI will be used in > situations where the application will (correctly) assume that anything > in URI syntax that has a slash character in it will be hierarchical. > > Thus a URI scheme that does not intend to indicate hierarchy MUST NOT > include a slash character in that part of the identifier. > ... I wouldn't say "MUST NOT". It's just it's a source of confusion that can be avoided when defining new URI schemes. Best regards, Julian From hallam@gmail.com Tue Oct 4 04:53:13 2011 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 404D021F8BD5; Tue, 4 Oct 2011 04:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.488 X-Spam-Level: X-Spam-Status: No, score=-3.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, 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 rXGVIXhVopXZ; Tue, 4 Oct 2011 04:53:12 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id A7E8121F8B74; Tue, 4 Oct 2011 04:53:09 -0700 (PDT) Received: by gyd12 with SMTP id 12so483984gyd.31 for ; Tue, 04 Oct 2011 04:56:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=s2/e/PglRH3B09ApQPww7joh7rDj99wisjea7YNF2yc=; b=JeopN2CaMvDozFj2VQsXk1Y0KO7UH2RqV+Knnrfjxc0qWxdRcj3u5aeShleFF8DKAp w9hvTz1AealtM0RcPUpNVVrYa82HEgPxIyhxCr75XwhcV47J4gL3Id4w3KY9WeMQ4ZGu QE4XsGvbFHiMaAjcBDK6DNXO4OhljU4ZoyWvU= MIME-Version: 1.0 Received: by 10.100.82.6 with SMTP id f6mr902546anb.52.1317729374486; Tue, 04 Oct 2011 04:56:14 -0700 (PDT) Received: by 10.100.212.14 with HTTP; Tue, 4 Oct 2011 04:56:14 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112902B30B7@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E112902B30B7@WSMSG3153V.srv.dir.telstra.com> Date: Tue, 4 Oct 2011 07:56:14 -0400 Message-ID: From: Phillip Hallam-Baker To: "Manger, James H" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "decade@ietf.org" , websec Subject: Re: [websec] Updated Digest Scheme URI: truncated digests 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, 04 Oct 2011 11:53:13 -0000 On Mon, Oct 3, 2011 at 11:22 PM, Manger, James H wrote: >> di:sha-128:B_K97zTtFuOhug27fke4_Q?enc=3Daes-cbc:Fw3x20nEKfq6FDGzq7ttIQ > > Instead if defining new names for truncated digests, why not simply inclu= de a truncated digest with the existing algorithm name? You can determine t= he truncation (in bytes) from the length of the base64url-encoding so there= is no ambiguity. > > =A0di:sha-256:B_K97zTtFuOhug27fke4_Q > > The only downside I see is the risk of bad implementations accepting a di= gest truncated to, say, 1 byte (eg di:sha-256:Bw) instead of enforcing a mi= nimum security level. That is a risk that has been realized for HMACs in certain circumstances. A caveat is probably sufficient. --=20 Website: http://hallambaker.com/ From hallam@gmail.com Tue Oct 4 05:04:13 2011 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 BCBC521F8C71; Tue, 4 Oct 2011 05:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.489 X-Spam-Level: X-Spam-Status: No, score=-3.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, 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 Xovws281LeFF; Tue, 4 Oct 2011 05:04:13 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 00F0421F8C6F; Tue, 4 Oct 2011 05:04:12 -0700 (PDT) Received: by gyd12 with SMTP id 12so494621gyd.31 for ; Tue, 04 Oct 2011 05:07:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=PQ7Uk7d6RR0R999Hpmzkrp/2Z85xAKVP4t2L3Zxqr0s=; b=t8y7K+WDDslwqpbMUntaOSlCrVlSEIr85+IE+RjkbGdP0Ag0R7/FWv4ziL9OY8Q6FK g0L9VRjy4nTE7aEBk46QRad5QiJxuFiur3GbHSR10GDYzwHcm09TO7NUnIF8JOqZ5Ur6 iw2OCyUqNm5pa/9VLB2msNKXRX5lBAPUrl6qE= MIME-Version: 1.0 Received: by 10.101.218.6 with SMTP id v6mr877711anq.140.1317730037771; Tue, 04 Oct 2011 05:07:17 -0700 (PDT) Received: by 10.100.212.14 with HTTP; Tue, 4 Oct 2011 05:07:17 -0700 (PDT) In-Reply-To: <27AFD040F6F8AA4193E0614E2E3AF9C910D2F0CA5D@SISPE7MB1.commscope.com> References: <27AFD040F6F8AA4193E0614E2E3AF9C910D2F0CA53@SISPE7MB1.commscope.com> <27AFD040F6F8AA4193E0614E2E3AF9C910D2F0CA5D@SISPE7MB1.commscope.com> Date: Tue, 4 Oct 2011 08:07:17 -0400 Message-ID: From: Phillip Hallam-Baker To: "Thomson, Martin" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "khare@alumni.caltech.edu" , "decade@ietf.org" , websec Subject: Re: [websec] Digest Scheme URI: .well-known 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, 04 Oct 2011 12:04:13 -0000 On Tue, Oct 4, 2011 at 12:46 AM, Thomson, Martin wrote: > On 2011-10-04 at 13:53:53, Phillip Hallam-Baker wrote: >> The content type is essential meta-data if the digest is going to be >> used to create a strong reference to the specified content. Otherwise >> the attacker can repurpose an image/jpeg as application/script. This >> works much better than it should because most processors simply ignore >> content they don't understand and helpfully try to resynchronize. > > You aren't making the world a less safe place if you leave the problem al= one. =A0Or have I missed something. =A0What makes this scheme any worse for= the attack, other than its inherent opacity? The use case there is creating a strong reference from a https page to a plain http one. In that case there is an issue. It is a real attack and an increasingly serious one. But the issue is moot since DECADE requires the ability to select between locators so that it gets one with a content type it has a codec for. > Regarding de/encryption keys: Is it really the case that you need to decr= ypt before calculating the digest? =A0Excuse my ignorance, but for a file s= tore, I would have thought that encryption would want to come before storag= e. There are pros and cons for the order of operations wrt encryption and authentication. The ideal is actually authenticate (encrypt (content + authenticate (content))) For our application I think it is pretty clear that the digest would need to be of the plaintext. I don't like revealing any info on the plaintext. I will correct that. --=20 Website: http://hallambaker.com/ From hallam@gmail.com Tue Oct 4 05:17:41 2011 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 ACB4221F8B42 for ; Tue, 4 Oct 2011 05:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.49 X-Spam-Level: X-Spam-Status: No, score=-3.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, 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 iXb7D5FxszUl for ; Tue, 4 Oct 2011 05:17:41 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id E0DFC21F8B44 for ; Tue, 4 Oct 2011 05:17:40 -0700 (PDT) Received: by ggnk3 with SMTP id k3so210501ggn.31 for ; Tue, 04 Oct 2011 05:20:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=na03AMdQotiYR4VCWle7Mxs8+pMshrxDkhx5e3tKTLA=; b=rMMgPsq9TCD7hHNq/qYpiXfZpejG3HfRYWpklRc1b+MmvtzFnoTk7Y9chxeppLQmwZ cYIkOghreBVP3DorCmxmOQ0xROLpcJ36o1Nmf5AABKCF4PHTakMdpoIJAAS6j8bwRKzr uTz0sVlvMND6K3cbd7sJw8Eamy4DYQrGrmGMw= MIME-Version: 1.0 Received: by 10.100.18.21 with SMTP id 21mr897409anr.118.1317730845645; Tue, 04 Oct 2011 05:20:45 -0700 (PDT) Received: by 10.100.212.14 with HTTP; Tue, 4 Oct 2011 05:20:45 -0700 (PDT) In-Reply-To: <4E8AB841.7050606@gmx.de> References: <7bd9badd19e0e9296750117013a93aa0.squirrel@webmail.scss.tcd.ie> <7bb25df9c583e9553d4cf6b7b2c4d98c.squirrel@webmail.scss.tcd.ie> <4E896451.9080406@it.aoyama.ac.jp> <4E897679.8050100@gmx.de> <4E8AB841.7050606@gmx.de> Date: Tue, 4 Oct 2011 08:20:45 -0400 Message-ID: From: Phillip Hallam-Baker To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: websec WG , Paul Hoffman Subject: Re: [websec] Digest URI scheme 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, 04 Oct 2011 12:17:41 -0000 On Tue, Oct 4, 2011 at 3:39 AM, Julian Reschke wrot= e: > On 2011-10-03 19:12, Phillip Hallam-Baker wrote: >> >> On Mon, Oct 3, 2011 at 1:05 PM, Paul Hoffman >> =A0wrote: >>> >>> On Oct 3, 2011, at 9:22 AM, Phillip Hallam-Baker wrote: >>> >>>> URLs are used in cases where hierarchy is assumed. >>> >>> I didn't see such use cases in your draft, nor in Stephen's. Maybe you'= ll >>> put them in your next proposal. >> >> As Julian correctly pointed out, a generic URI will be used in >> situations where the application will (correctly) assume that anything >> in URI syntax that has a slash character in it will be hierarchical. >> >> Thus a URI scheme that does not intend to indicate hierarchy MUST NOT >> include a slash character in that part of the identifier. >> ... > > I wouldn't say "MUST NOT". It's just it's a source of confusion that can = be > avoided when defining new URI schemes. Ack, In private conversation someone just pointed out that the data: uri scheme has a semicolon that turns out to be necessary because parsers make unjustified assumptions. There is a SHOULD NOT in the URI spec and I think the onus is on folk to demonstrate that base64url would cause actual problems. The base64url scheme is used by Facebook so there is a huge amount of existing code that can manage the format. There is a page of implementations: https://github.com/ptarjan/base64url Using the base64url encoding makes use of an Apache server on UNIX much easier since the di digest can be used as the filename. I can't see that any of the purported conveniences of base64 outweigh that. Base16 means longer identifiers and introduces a case sensitivity issue. --=20 Website: http://hallambaker.com/ From hallam@gmail.com Tue Oct 4 10:51:29 2011 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 6CB3C21F8DCA; Tue, 4 Oct 2011 10:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.487 X-Spam-Level: X-Spam-Status: No, score=-3.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, 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 LIoFqDJt1Jja; Tue, 4 Oct 2011 10:51:28 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id A57C521F8D6F; Tue, 4 Oct 2011 10:51:28 -0700 (PDT) Received: by ywm3 with SMTP id 3so897461ywm.31 for ; Tue, 04 Oct 2011 10:54:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=V8wvVxl9XfJe/Qvs0Mp5Yngt6E9EAUYBKMxuMeCRZUI=; b=MrXRMmRB5RCQfol8chwn5zxmfOWa6ZXSJkShHhRi8kK6Rw7ydFaH3jM82ATppxNDDu mwGEae1AS8LdnBHOorj9jzUWL3wtZ4WewwYdA06EhlNiq1pQvP2CXszusgwjGs9cPeQj RrfOep4Eb/13BlG/N408XRWzf4OztKUGJ1dE0= MIME-Version: 1.0 Received: by 10.101.218.6 with SMTP id v6mr1237986anq.140.1317750874196; Tue, 04 Oct 2011 10:54:34 -0700 (PDT) Received: by 10.100.212.14 with HTTP; Tue, 4 Oct 2011 10:54:34 -0700 (PDT) Date: Tue, 4 Oct 2011 13:54:34 -0400 Message-ID: From: Phillip Hallam-Baker To: websec , decade@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [websec] Updated, updated DIGEST spec 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, 04 Oct 2011 17:51:29 -0000 In response to comments on and off list, I have revved the draft to produce a -02 * Have fixed the omission of the scheme and algorithm in /.well-known/di/sha-256 * Have changed the colon separating the algorithm and the digest to a semi-colon on advice that some parsers will choke otherwise * Have taken out the SHA-128 scheme and instead put in support for truncation on an arbitrary 32 bit boundary. [This needs a security consideration of course] I guess I should have added the acknowledgements section as well. Stephen and I have had discussions off list. If all goes well this should be the last version of this draft before we get to a merge. The outcome that seems to be most likely to suit people's needs would be to have two drafts. The first would just have the core syntax and security considerations for using digest identifiers. The second would have all the interesting stuff link locators and encryption and stuff. Content-type would likely be in the second. I am going off to write some code. -- Website: http://hallambaker.com/ From hallam@gmail.com Tue Oct 4 10:52:02 2011 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 A9D9421F8B24; Tue, 4 Oct 2011 10:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.488 X-Spam-Level: X-Spam-Status: No, score=-3.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, 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 guE9mqSed9EB; Tue, 4 Oct 2011 10:51:57 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0C721F8B0F; Tue, 4 Oct 2011 10:51:55 -0700 (PDT) Received: by mail-yw0-f44.google.com with SMTP id 3so897461ywm.31 for ; Tue, 04 Oct 2011 10:55:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=XZ1xnm3rCz3J2yzz6L3u9sebbY4O4W43qjWIqKXiNsg=; b=Y3uw+oQUEQIofnhL/XuSWGjrAHKjBqwU4dN1Y3vZN11EnGetSudNvpeYaoqC4NMmKD b5oD7A4q72Wyy49Myjqv1n6sUCyDA6GKezonchDlUaRWNRDURhCbcTknNMj9QPktdxlt cD6BAQeccxvYXjGdFSnyDc3knRHtpsKwF/XAM= MIME-Version: 1.0 Received: by 10.100.18.21 with SMTP id 21mr1245835anr.118.1317750901332; Tue, 04 Oct 2011 10:55:01 -0700 (PDT) Received: by 10.100.212.14 with HTTP; Tue, 4 Oct 2011 10:55:01 -0700 (PDT) In-Reply-To: References: Date: Tue, 4 Oct 2011 13:55:01 -0400 Message-ID: From: Phillip Hallam-Baker To: websec , decade@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [websec] Updated, updated DIGEST spec 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, 04 Oct 2011 17:52:02 -0000 And he left out the URL that the message was about. http://www.ietf.org/id/draft-hallambaker-digesturi-02.txt On Tue, Oct 4, 2011 at 1:54 PM, Phillip Hallam-Baker wrote: > In response to comments on and off list, I have revved the draft to > produce a -02 > > * Have fixed the omission of the scheme and algorithm in > /.well-known/di/sha-256 > * Have changed the colon separating the algorithm and the digest to a > semi-colon on advice that some parsers will choke otherwise > * Have taken out the SHA-128 scheme and instead put in support for > truncation on an arbitrary 32 bit boundary. [This needs a security > consideration of course] > > I guess I should have added the acknowledgements section as well. > > > Stephen and I have had discussions off list. If all goes well this > should be the last version of this draft before we get to a merge. The > outcome that seems to be most likely to suit people's needs would be > to have two drafts. The first would just have the core syntax and > security considerations for using digest identifiers. The second would > have all the interesting stuff link locators and encryption and stuff. > Content-type would likely be in the second. > > I am going off to write some code. > > -- > Website: http://hallambaker.com/ > -- Website: http://hallambaker.com/ From Akbar.Rahman@InterDigital.com Wed Oct 5 07:05:02 2011 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 944C921F8D92; Wed, 5 Oct 2011 07:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.397 X-Spam-Level: X-Spam-Status: No, score=-2.397 tagged_above=-999 required=5 tests=[AWL=0.202, 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 EUNEnM3lDh5H; Wed, 5 Oct 2011 07:04:58 -0700 (PDT) Received: from idcout.InterDigital.com (idcexmail.interdigital.com [12.32.197.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8664A21F8D56; Wed, 5 Oct 2011 07:04:58 -0700 (PDT) Received: from SAM.InterDigital.com ([10.30.2.12]) by idcout.InterDigital.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 Oct 2011 10:08:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Oct 2011 10:08:04 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-topic: [decade] Updated, updated DIGEST spec Thread-index: AcyCwNX3MxtHyzQRQSmsotAfXsMRrwApwn2g References: From: "Rahman, Akbar" To: "Phillip Hallam-Baker" X-OriginalArrivalTime: 05 Oct 2011 14:08:05.0960 (UTC) FILETIME=[3406CC80:01CC8368] X-Mailman-Approved-At: Wed, 05 Oct 2011 07:19:26 -0700 Cc: decade@ietf.org, websec Subject: Re: [websec] [decade] Updated, updated DIGEST spec 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, 05 Oct 2011 14:05:02 -0000 Hi Phillip, I read through your draft and it was quite interesting. For DECADE, are you proposing to use your scheme for the naming of DECADE objects or for some other purpose? Please excuse me if the question had already been discussed as I must have missed it. Akbar -----Original Message----- From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf Of Phillip Hallam-Baker Sent: Tuesday, October 04, 2011 1:55 PM To: websec; decade@ietf.org Subject: [decade] Updated, updated DIGEST spec In response to comments on and off list, I have revved the draft to produce a -02 * Have fixed the omission of the scheme and algorithm in /.well-known/di/sha-256 * Have changed the colon separating the algorithm and the digest to a semi-colon on advice that some parsers will choke otherwise * Have taken out the SHA-128 scheme and instead put in support for truncation on an arbitrary 32 bit boundary. [This needs a security consideration of course] I guess I should have added the acknowledgements section as well. Stephen and I have had discussions off list. If all goes well this should be the last version of this draft before we get to a merge. The outcome that seems to be most likely to suit people's needs would be to have two drafts. The first would just have the core syntax and security considerations for using digest identifiers. The second would have all the interesting stuff link locators and encryption and stuff. Content-type would likely be in the second. I am going off to write some code. --=20 Website: http://hallambaker.com/ _______________________________________________ decade mailing list decade@ietf.org https://www.ietf.org/mailman/listinfo/decade From julian.reschke@gmx.de Wed Oct 5 07:38:25 2011 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 A715D21F8D75 for ; Wed, 5 Oct 2011 07:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.326 X-Spam-Level: X-Spam-Status: No, score=-104.326 tagged_above=-999 required=5 tests=[AWL=-1.727, 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 nVQZMWJvELLI for ; Wed, 5 Oct 2011 07:38:25 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 8D7D521F8D6F for ; Wed, 5 Oct 2011 07:38:24 -0700 (PDT) Received: (qmail invoked by alias); 05 Oct 2011 14:41:31 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp008) with SMTP; 05 Oct 2011 16:41:31 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+9fzNcdsW919B6c5//XW1lMEevQ+ym8BrJHvmGPD PUqOw9eZ9rl1Nn Message-ID: <4E8C6C99.8000107@gmx.de> Date: Wed, 05 Oct 2011 16:41:29 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: websec References: <20110922223352.30413.93196.idtracker@ietfa.amsl.com> <4E7C3547.5070405@gmx.de> In-Reply-To: <4E7C3547.5070405@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: Re: [websec] I-D Action: draft-ietf-websec-origin-05.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: Wed, 05 Oct 2011 14:38:25 -0000 On 2011-09-23 09:29, Julian Reschke wrote: > ... >> 1. NOTE: Running this algorithm multiple times for the same URI >> can produce different values each time. Typically, user >> agents compute the origin of, for example, an HTML document >> once and use that origin for subsequent security checks >> rather than recomputing the origin for each security check. > > It seems the NOTE shouldn't be in a numbered list (same for item 4). > ... Draft -06 has another instance of this nit :-) > b) "null" in ABNF means case-insensitive; consider replacing with octet > sequence and putting the literal "null" into a comment. > ... You now have: origin-list-or-null = %x6E %x75 %x6C %x6C / origin-list You can make that origin-list-or-null = %x6E.75.6C.6C / origin-list and make it more readable by saying: null = %x6E.75.6C.6C ; "null", case-sensitive origin-list-or-null = null / origin-list Best regards, Julian From hallam@gmail.com Wed Oct 5 08:21:08 2011 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 68AE021F8D70; Wed, 5 Oct 2011 08:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.489 X-Spam-Level: X-Spam-Status: No, score=-3.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, 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 cUxpCkx-V3yQ; Wed, 5 Oct 2011 08:21:07 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 06B0E21F8D6F; Wed, 5 Oct 2011 08:21:04 -0700 (PDT) Received: by gyd12 with SMTP id 12so2038929gyd.31 for ; Wed, 05 Oct 2011 08:24:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=p1uWvZV+P1R8dPL9TWgmPhut15ozr96pEEGe/Af2fqc=; b=dqFwSZzXuFh01oW5FoGAXde7Opl33b1CbBF2l98EY9D8gSCLgrq0hiaFhA8cadHG1Z 0cLYJSAWOaHTWd0fptoZbV9uq3vRx2yUOOOwXgg8W/M084zzYj9eDjbm/Sf//D3CaMpW UJZJ+60HdVK2F8SWTv1cE1+TjRW6d31ngnm3w= MIME-Version: 1.0 Received: by 10.101.154.22 with SMTP id g22mr2139775ano.96.1317828252736; Wed, 05 Oct 2011 08:24:12 -0700 (PDT) Received: by 10.100.212.14 with HTTP; Wed, 5 Oct 2011 08:24:12 -0700 (PDT) In-Reply-To: References: Date: Wed, 5 Oct 2011 11:24:12 -0400 Message-ID: From: Phillip Hallam-Baker To: "Rahman, Akbar" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: decade@ietf.org, websec Subject: Re: [websec] [decade] Updated, updated DIGEST spec 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, 05 Oct 2011 15:21:08 -0000 Actually the proposal is to merge my proposal with the ni scheme made by Stephen et. al. I generally recon that if two independent proposals converge on essentially the same thing it probably means it is on the right track. At worst it is a necessary dead end that has to be explored:-) On Wed, Oct 5, 2011 at 10:08 AM, Rahman, Akbar wrote: > Hi Phillip, > > > I read through your draft and it was quite interesting. =A0For DECADE, ar= e > you proposing to use your scheme for the naming of DECADE objects or for > some other purpose? =A0Please excuse me if the question had already been > discussed as I must have missed it. > > > Akbar > > > > -----Original Message----- > From: decade-bounces@ietf.org [mailto:decade-bounces@ietf.org] On Behalf > Of Phillip Hallam-Baker > Sent: Tuesday, October 04, 2011 1:55 PM > To: websec; decade@ietf.org > Subject: [decade] Updated, updated DIGEST spec > > In response to comments on and off list, I have revved the draft to > produce a -02 > > * Have fixed the omission of the scheme and algorithm in > /.well-known/di/sha-256 > * Have changed the colon separating the algorithm and the digest to a > semi-colon on advice that some parsers will choke otherwise > * Have taken out the SHA-128 scheme and instead put in support for > truncation on an arbitrary 32 bit boundary. [This needs a security > consideration of course] > > I guess I should have added the acknowledgements section as well. > > > Stephen and I have had discussions off list. If all goes well this > should be the last version of this draft before we get to a merge. The > outcome that seems to be most likely to suit people's needs would be > to have two drafts. The first would just have the core syntax and > security considerations for using digest identifiers. The second would > have all the interesting stuff link locators and encryption and stuff. > Content-type would likely be in the second. > > I am going off to write some code. > > -- > Website: http://hallambaker.com/ > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade > --=20 Website: http://hallambaker.com/ From iesg-secretary@ietf.org Wed Oct 5 11:02:14 2011 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 48C0E11E80C2; Wed, 5 Oct 2011 11:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.511 X-Spam-Level: X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 MQmZ+W+Yi9VX; Wed, 5 Oct 2011 11:02:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7011411E80C6; Wed, 5 Oct 2011 11:02:13 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20111005180213.1858.93149.idtracker@ietfa.amsl.com> Date: Wed, 05 Oct 2011 11:02:13 -0700 Cc: websec mailing list , websec chair , RFC Editor Subject: [websec] Protocol Action: 'The Web Origin Concept' to Proposed Standard (draft-ietf-websec-origin-06.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: Wed, 05 Oct 2011 18:02:14 -0000 The IESG has approved the following document: - 'The Web Origin Concept' (draft-ietf-websec-origin-06.txt) as a Proposed Standard This document is the product of the Web Security Working Group. The IESG contact persons are Peter Saint-Andre and Pete Resnick. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-websec-origin/ Technical Summary This document defines the concept of an "origin", which is often used as the scope of authority or privilege by user agents. Typically, user agents isolate content retrieved from different origins to prevent malicious web site operators from interfering with the operation of benign web sites. In addition to outlining the principles that underlie the concept of origin, this document defines how to determine the origin of a URI, how to serialize an origin into a string, and an HTTP header, named "Origin", that indicates which origins are associated with an HTTP request. Working Group Summary There was nothing particularly worth noting about the WG process. Specifically there was no strong controversy about this document. The document received sufficient review from WG participants and individuals outside the WG. Furthermore, reviews also covered document versions before their adoption by the WG or even prior to the formation of the WebSec WG (i.e., draft-abarth-origin and draft-abarth-principles-of-origin). Document Quality The origin concept is widely used in the web browser and application environment to determine trusted sources. Still it may be noteworthy that some current implementations of the origin concept may differ in whether all three elements of the origin-tuple must be identical to constitute identity of origin (in some current browser implementations the scheme or port might receive less weight). The text regarding comparison of internationalized domain names benefited from extensive discussion with Patrik Faltstrom, Jeff Hodges, John Klensin, and Pete Resnick. From Jeff.Hodges@KingsMountain.com Thu Oct 6 16:20:47 2011 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 B7DFE21F8BFE for ; Thu, 6 Oct 2011 16:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.44 X-Spam-Level: X-Spam-Status: No, score=-100.44 tagged_above=-999 required=5 tests=[AWL=0.055, 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 VxyPOX+W3wl1 for ; Thu, 6 Oct 2011 16:20:45 -0700 (PDT) Received: from oproxy4-pub.bluehost.com (oproxy4.bluehost.com [IPv6:2605:dc00:100:2::a4]) by ietfa.amsl.com (Postfix) with SMTP id 8B9B421F8BEF for ; Thu, 6 Oct 2011 16:20:45 -0700 (PDT) Received: (qmail 20911 invoked by uid 0); 6 Oct 2011 23:23:57 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy1.bluehost.com with SMTP; 6 Oct 2011 23:23:57 -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=faIpdRHYBkAv4dKk9a2XN+QEK9OPeN6JpiFvQ2xTZhY=; b=p/DrM9loXgPEZfsl2mZBAswo5M8N1qWd3L1t5/I+xrnI/GOorf6kOp1YuIQEe/4j9l1qAnf8IdmdLJRmKvNyJ6as7BPNjF3QEcjEX7Rp3r7r/37TB8hXm2WdaHS7LNZB; Received: from c-24-4-122-173.hsd1.ca.comcast.net ([24.4.122.173] helo=[192.168.11.10]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1RBxIC-0003wg-Pn; Thu, 06 Oct 2011 17:23:56 -0600 Message-ID: <4E8E388B.8020202@KingsMountain.com> Date: Thu, 06 Oct 2011 16:23:55 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: "Ryan Sleevi" , 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] 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, 06 Oct 2011 23:20:47 -0000 Hi Ryan, thanks for the detailed feedback. > Following Julian Reschke's questions, I also had a few questions related > to the draft-02 syntax. I've been basing my understanding on RFC 5234, > which I understand to be the most current/relevant to understanding the > syntax. > > > First, maxAge and includeSubDomains both include value extension points, > defined as: > > maxAge = "max-age" OWS "=" OWS delta-seconds [ OWS v-ext ] > includeSubDomains = "includeSubDomains" [ OWS v-ext ] > v-ext = value ; STS extension value > > However, the rule for OWS is specified as: > > OWS = *( [ CRLF ] WSP ) > > As written, it would seem that the OWS between either delta-seconds or > "includeSubDomains" can legitimately be omitted before the v-ext. As best > I can tell, this would mean that the following values would still be > valid: > > max-age=123.456 > includeSubDomainsabc > > In the first case ".456" is the v-ext, while in the second, "abc" is. In > both cases, because the OWS is truly optional (valid to have 0 > occurrences), only the v-ext is present. yes, trying to use the OWS construction there is broken as you point out. > To remedy this, I believe some form of explicit delimiter between the > existing values and the v-ext should be defined for the existing headers. > If the intent was to have extension values whitespace separated, then > would the following modification to introduce required whitespace solve > it? > > maxAge = "max-age" OWS "=" OWS delta-seconds [ RWS v-ext ] > includeSubDomains = "includeSubDomains" [ RWS v-ext ] > v-ext = value ; STS extension value > OWS = *( [ CRLF ] WSP ) > RWS = 1*( [ CRLF ] WSP ) Yes, using a required whitespace (RWS) construction would seem to fix it. However, since we've migrated to base the ABNF on RFC2616 and not HTTPbis, we should perhaps whole-hog and use the former's LWS (linear whitespace) construct which has the "implied whitespace" notion, and get rid of the OWS stuff. > Alternatively, can/should the v-ext be dropped entirely, and extensions to > the STS header be accomplished via defining a new STS-d-ext? yes, that's a possibility. I put the v-ext thing in there with max-age for completeness without a good use case, and maybe it'll just cause more trouble than its worth. > Second, as currently specified, extension directives take the form of: > > STS-d = STS-d-cur / STS-d-ext > STS-d-ext = name ; STS extension directive > name = token > token = 1*tchar > tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" > / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" > / DIGIT / ALPHA > > As currently written, STS-d-ext doesn't seem to be able to contain name > "=" value pairs such as those used by Evans' and Palmer's pinning draft, > because "=" is not a valid token character. Likewise, it wouldn't be able > to contain "#rule" style lists, because comma is not a valid tchar. good catch. > Should STS-d-ext be defined as "value" instead, so that it contain a wider > range of characters? offhand, "value" seems the way to go to me. Again, thanks much for your review, I'm working on getting new rev out with repaired ABNF amongst other things. =JeffH From hallam@gmail.com Thu Oct 6 19:46:05 2011 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 E9AA521F8B34; Thu, 6 Oct 2011 19:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.489 X-Spam-Level: X-Spam-Status: No, score=-3.489 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 e2Oc5jyvaeB9; Thu, 6 Oct 2011 19:46:04 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 93E8521F8B31; Thu, 6 Oct 2011 19:46:04 -0700 (PDT) Received: by ywm3 with SMTP id 3so3936698ywm.31 for ; Thu, 06 Oct 2011 19:49:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=PhgkGzI2B2sbpCM/DIJiIhdzr0pnhGlXzM6b1BW47j8=; b=O3Z0zrCkRKL2tpb6E/gT2pVV6dSIIRCsD7EBdg1T4eizWt2w2KAXW75PBxhzoe2FNp omkKO6AjOMlf5mYRUiN98qQ/2GU6dLDKEpOfBwX+X8tpd5yDzNeDCu+XpevyBasBrdn0 qLgou2gjfg0518jkkyq35O2SMtKx7faqZMerU= MIME-Version: 1.0 Received: by 10.101.22.6 with SMTP id z6mr354801ani.140.1317955756751; Thu, 06 Oct 2011 19:49:16 -0700 (PDT) Received: by 10.100.212.14 with HTTP; Thu, 6 Oct 2011 19:49:16 -0700 (PDT) Date: Thu, 6 Oct 2011 22:49:16 -0400 Message-ID: From: Phillip Hallam-Baker To: websec , decade@ietf.org Content-Type: multipart/alternative; boundary=00504502957fb5fb5604aeac7c09 Subject: [websec] Digest: Adventures in encoding 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, 07 Oct 2011 02:46:06 -0000 --00504502957fb5fb5604aeac7c09 Content-Type: text/plain; charset=ISO-8859-1 Following on the base16/base64 discussion, I have written some code (see end) and have some ni digests in various flavors of encoding. My conclusion is that we should split the difference and do base32 instead. I think the arguments are actually quite compelling. This is only an encoding issue. So choosing an encoding that requires the least number of systems to be touched is my priority. Choosing base32 allows the resolution scheme to be supported by unmodified Apache and IIS. The additional code burden for ni/digest implementers to write base32 is trivial There is also the option of doing more than one encoding. But Base64 uris are only slightly shorter. *Base16* ni:sha-256;B77B635B2832BF95E8F2935963F134A41F4F11C0BEDD6CED2C5E551F288D9980 Problem - very long even without separators. *Base32:* ni:sha-256;W5AGGABIGKAJLAHSSNAGHABUUQAE6AGAX3AGZABMLZAB6AENTGAA Advantage: more compact than Base16 (somewhat), can be read out over a telephone or terminal room (try that with Base64). Can be printed as a static reference in a journal or equivalent. *Base32s:* ni:sha-256;W5AGGA-BIGKAJ-LAHSSNA-GHABUU-QAE6AGA-X3AGZA-BMLZAB-6AENTGAA This is my own invention, basically Base32 with separators added for readability. *Base64:* ni:sha-256;t3tjWygyv5Xo8pNZY/E0pB9PEcC+3WztLF5VHyiNmYA= This is the traditional base64 encoding. Process disadvantage: You know that someone is bound to challenge the forward slash just as the document gets to last call. I don't see an advantage to risk a discuss. Practical disadvantage: Gets messed up when converted to a well-known URL. Consider the following: ni:sha-256;t3tjWygyv5Xo8pNZY/E0pB9PEcC+3WztLF5VHyiNmYA=?http=example.com This would map to: http://example.com/.well-known/ni/sha-256/t3tjWygyv5Xo8pNZY/E0pB9PEcC+3WztLF5VHyiNmYA= The forward slash is not a hierarchy indicator which is bad. Worse still this would mean that support for ni digest objects requires a code plug in for Apache, IIS etc rather than just mapping .well-known/ni/sha-256 to the directory with the digest values. *Base64url:* ni:sha-256;t3tjWygyv5Xo8pNZY_E0pB9PEcC-3WztLF5VHyiNmYA This is essentially the same as base64 for size etc. The only disadvantage being that the encoder has to be scratch written. (Mine took 20 mins). The advantage over plain base64 is that there is no code required to support the .well-known version of the locator scheme on the server at all. Just some admin stuff. Also the URL is completely compatible with URI process lore. *Summary:* Arguments can be made for each one of these schemes. I think the argument for Base16 is the weakest since Base32 can do everything that Base16 can do. Neither is implemented as a standard library function on my platform. If we went for Base32, I would argue for allowing some form of readability separator. Base32s is much easier to transcribe than plain Base32. Base64/Base64url offer the best compression in a practical form. For most applications a truncated digest will be acceptable. The main disadvantage of the Base64 schemes is that they are case sensitive. This will play merry heck with case insensitive but case preserving file systems such as Windows. I think we should knock out base16 from consideration as base32 does it better. Since it is fairly easy to write a filter that strips out the separators, I would argue for allowing separators at any point in the identifier but that the canonical form is with the separators stripped out and this is what is used to create the URL form. So ni:sha-256;W5AGGA-BIGKAJ-LAHSSNA-GHABUU-QAE6AGA-X3AGZA-BMLZAB-6AENTGAA would map to http://example.com/.well-known/ni/sha-256/W5AGGABIGKAJLAHSSNAGHABUUQAE6AGAX3AGZABMLZAB6AENTGAA This preserves the criteria that Apache, IIS etc can be configured to resolve these identifiers without new code. Taking out Base 16 and base32 without separators, I see the following options: Base32s only Base64 only Base64url only Base32s + Base64url I can see pros and cons for the base32 encoding. To make it really readable it is necessary to put in the separators which is something of an overhead. So I can see an argument for both. But if we only pick one I would say take base32 with separators. It is not the most compact but it is good enough. It is fully URL compatible and has the readability benefit. Here is Base32 in C#: string ToBase32String(byte[] data, int Length) { string result = ""; int offset = 0; int a = 0; for (int i = 0; i < Length; i++) { a = (a << 8) | data[i]; offset += 8; while (offset >= 5) { offset -= 5; int n = a >> offset; result = result + BASE32[n]; a = a & (0x1f >> (5 - offset)); } } if (offset > 0) { result = result + BASE32[a]; } return result; } Here is base64url in C#: string ToBase64urlString(byte[] data, int Length) { string result = ""; int offset = 0; int a = 0; for (int i = 0; i < Length; i++) { a = (a << 8) | data[i]; offset += 8; //Console.WriteLine ("{0:x4}/{2:3} : {1}", a, result, offset); while (offset >= 6) { offset -= 6; int n = a >> offset; result = result + BASE64URL[n]; a = a & (0x3f >> (6 - offset)); } } if (offset > 0) { result = result + BASE64URL[a]; } return result; } -- Website: http://hallambaker.com/ --00504502957fb5fb5604aeac7c09 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Following on the base16/base64 discussion, I have written some code (see en= d) and have some ni digests in various flavors of encoding.

<= div>My conclusion is that we should split the difference and do base32 inst= ead. I think the arguments are actually quite compelling.

This is only an encoding issue. So choosing an encoding= that requires the least number of systems to be touched is my priority. Ch= oosing base32 allows the resolution scheme to be supported by unmodified Ap= ache and IIS.=A0

The additional code burden for ni/digest implementers t= o write base32 is trivial=A0


There = is also the option of doing more than one encoding. But Base64 uris are onl= y slightly shorter.


Base16
ni:sha-256;B77B635B2832BF95E8F2935963F134A41F= 4F11C0BEDD6CED2C5E551F288D9980

Problem - very long even without sepa= rators.


Base32:
ni:sha-256;W5AGGABIGKAJLAHSSNAGHABUUQA= E6AGAX3AGZABMLZAB6AENTGAA

Advantage: more compact than Base16 (somewhat), can be read out over a = telephone or terminal room (try that with Base64). Can be printed as a stat= ic reference in a journal or equivalent.


Base32s:
ni:sha-256;W5AGGA-BIGKAJ-LAHSSNA-GHABUU-QAE6AGA-X3AGZA-BMLZAB-6AENTGAA
<= br>This is my own invention, basically Base32 with separators added for rea= dability.


Base64:
ni:sha-256;t3tjWygyv5Xo8pNZY/E0pB9PE= cC+3WztLF5VHyiNmYA=3D

This is the traditional base64 encoding.

Process disadvantage: Y= ou know that someone is bound to challenge the forward slash just as the do= cument gets to last call. I don't see an advantage to risk a discuss.
Practical disadvantage: Gets messed up when converted to a well-known U= RL. Consider the following:

ni:sha-256;t3tjWygyv5Xo8pNZY/E0pB9PEcC+3= WztLF5VHyiNmYA=3D?http=3Dexample.com
=
This would map to:

http://example.com/.wel= l-known/ni/sha-256/t3tjWygyv5Xo8pNZY/E0pB9PEcC+3WztLF5VHyiNmYA=3D
The forward slash is not a hierarchy indicator which is bad. Worse still th= is would mean that support for ni digest objects requires a code plug in fo= r Apache, IIS etc rather than just mapping .well-known/ni/sha-256 to the di= rectory with the digest values.


Base64url:

ni:sha-256;t3tjWygyv5Xo8pNZY_E0pB9PEcC-3Wz= tLF5VHyiNmYA

This is essentially the same as base64 for size etc. Th= e only disadvantage being that the encoder has to be scratch written. (Mine= took 20 mins).

The advantage over plain base64 is that there is no code required to su= pport the .well-known version of the locator scheme on the server at all. J= ust some admin stuff. Also the URL is completely compatible with URI proces= s lore.


Summary:

Arguments can be made for each o= ne of these schemes. I think the argument for Base16 is the weakest since B= ase32 can do everything that Base16 can do. Neither is implemented as a sta= ndard library function on my platform.

If we went for Base32, I would argue for allowing some = form of readability separator. Base32s is much easier to transcribe than pl= ain Base32.

Base64/Base64url offer the best compre= ssion in a practical form. For most applications a truncated digest will be= acceptable. The main disadvantage of the Base64 schemes is that they are c= ase sensitive. This will play merry heck with case insensitive but case pre= serving file systems such as Windows.=A0

I think we should knock out base16 from consideration as base32 does it= better.

Since it is fairly easy to write a filter= that strips out the separators, I would argue for allowing separators at a= ny point in the identifier but that the canonical form is with the separato= rs stripped out and this is what is used to create the URL form. So

ni:sha-256;W5AGGA-BIGKAJ-LAHSSNA-GHABUU-QAE6AGA-X3AGZA-BMLZAB-6AEN= TGAA

would map to


This preserves the criteria that Apache, IIS etc can be= configured to resolve these identifiers without new code.=A0

Taking out Base 16 and base32 without separators= , I see the following options:

Base32s only
Base64 only
Base64url = only
Base32s + Base64url

I can see pros = and cons for the base32 encoding. To make it really readable it is necessar= y to put in the separators which is something of an overhead. So I can see = an argument for both.

But if we only pick one I would say take base32 with se= parators. It is not the most compact but it is good enough. It is fully URL= compatible and has the readability benefit.


Here is Base32 in C#:

=A0 =A0 =A0 = =A0 string ToBase32String(byte[] data, int Length) {
=A0 =A0 =A0 = =A0 =A0 =A0 string result =3D "";
=A0 =A0 =A0 =A0 =A0 = =A0 int offset =3D 0;
=A0 =A0 =A0 =A0 =A0 =A0 int a =3D 0;

=A0 =A0 =A0 =A0 =A0 =A0 for (int i =3D 0; i < Length= ; i++) {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 a =3D (a << 8) | d= ata[i];
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 offset +=3D 8;
=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 while (offset >=3D 5) {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 offset -=3D 5;

<= /div>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int n =3D a >> offs= et;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 result =3D result + B= ASE32[n];
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 a =3D a & (= 0x1f >> (5 - offset));
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 }

=A0 =A0 =A0 =A0 =A0 =A0 if (offs= et > 0) {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 result =3D result + = BASE32[a];
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
=A0 =A0 = =A0 =A0 =A0 =A0 return result;
=A0 =A0 =A0 =A0 =A0 =A0 }

Here is base64url in C#:

= =A0 =A0 =A0 =A0string ToBase64urlString(byte[] data, int Length) {
=A0 = =A0 =A0 =A0 =A0 =A0string result =3D "";
=A0 =A0 =A0 =A0 =A0 = =A0int offset =3D 0;
=A0 =A0 =A0 =A0 =A0 =A0int a =3D 0;

=A0 =A0 =A0 =A0 =A0 =A0for (int i =3D 0; i < Length; i++) {
=A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0a =3D (a << 8) | data[i];
=A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0offset +=3D 8;

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/= /Console.WriteLine ("{0:x4}/{2:3} : {1}", a, result, offset);

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0while (offset >=3D 6) {
=A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0offset -=3D 6;

=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0int n =3D a >> offset;
=A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0result =3D result + BASE64URL[n];
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0a =3D a & (0x3f >> (6 - offset));
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0}
=A0 =A0 =A0 =A0 =A0 =A0if (offset > 0) {
=A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0result =3D result + BASE64URL[a];
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0}
=A0 =A0 =A0 =A0 =A0 =A0return result;
=A0 =A0 =A0 =A0 = =A0 =A0}
--
Website: http://hall= ambaker.com/


--00504502957fb5fb5604aeac7c09-- From stephen.farrell@cs.tcd.ie Fri Oct 7 01:51:36 2011 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 0DD6F21F8B3D; Fri, 7 Oct 2011 01:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 UlWvuVow4Rpg; Fri, 7 Oct 2011 01:51:35 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id B1A1921F8B34; Fri, 7 Oct 2011 01:51:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id E90F4171C9B; Fri, 7 Oct 2011 09:54:41 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1317977681; bh=YTIY6uVdUuIR46 h7VY0nAHn2MGJrnG0s7kbqFSTGsf8=; b=uA4Yjrslhb2TbZOymV7juD45KLPnmB Li7XlkVUhYG/YZB2VKRgtEoJSDXBYGQ2X/3jlYrjl0Ofj9iOwBaLSPCEY6EfjYzE y6ToiWCI5Ab3EUEZbdQWWdK/Yo2h3DwwopOzYuPQHdlii+vCYUxSWfVhr8zZc9Tv UKVp+QsoGYsUUhVvtUvxYNr9ua+1GMU6ypko6bsDQTGeVAx5W5iklm+3OpjZwAEh Yvev7V2jRBZrWlXEQCSnhG9KpPt4MMWaMY72s4bzkjdd6ffkHOTmHxjTSqxVPEy/ ry53sMe9nNv60shjo4VSsuEIUHCexbK+8IY5zKOmgwwIoG+YKPCb1Y1Q== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id hM2bPlkPZajj; Fri, 7 Oct 2011 09:54:41 +0100 (IST) Received: from [10.87.48.3] (unknown [86.46.20.64]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 3E919171C2C; Fri, 7 Oct 2011 09:54:39 +0100 (IST) Message-ID: <4E8EBE4E.2040203@cs.tcd.ie> Date: Fri, 07 Oct 2011 09:54:38 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Phillip Hallam-Baker References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: decade@ietf.org, websec Subject: Re: [websec] [decade] Digest: Adventures in encoding 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, 07 Oct 2011 08:51:36 -0000 Hi Phill, Oauth [1] uses ""application/x-www-form-urlencoded" format as defined by [W3C.REC-html401-19991224]" all over the place to solve basically this problem but in the context of HTTP URLs which has to be worse than for a new URI scheme. Why not do the same here? S. [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-4.1.1 On 10/07/2011 03:49 AM, Phillip Hallam-Baker wrote: > Following on the base16/base64 discussion, I have written some code (see > end) and have some ni digests in various flavors of encoding. > > My conclusion is that we should split the difference and do base32 instead. > I think the arguments are actually quite compelling. > > This is only an encoding issue. So choosing an encoding that requires the > least number of systems to be touched is my priority. Choosing base32 allows > the resolution scheme to be supported by unmodified Apache and IIS. > > The additional code burden for ni/digest implementers to write base32 is > trivial > > > There is also the option of doing more than one encoding. But Base64 uris > are only slightly shorter. > > > *Base16* > ni:sha-256;B77B635B2832BF95E8F2935963F134A41F4F11C0BEDD6CED2C5E551F288D9980 > > Problem - very long even without separators. > > > *Base32:* > ni:sha-256;W5AGGABIGKAJLAHSSNAGHABUUQAE6AGAX3AGZABMLZAB6AENTGAA > > Advantage: more compact than Base16 (somewhat), can be read out over a > telephone or terminal room (try that with Base64). Can be printed as a > static reference in a journal or equivalent. > > > *Base32s:* > ni:sha-256;W5AGGA-BIGKAJ-LAHSSNA-GHABUU-QAE6AGA-X3AGZA-BMLZAB-6AENTGAA > > This is my own invention, basically Base32 with separators added for > readability. > > > *Base64:* > ni:sha-256;t3tjWygyv5Xo8pNZY/E0pB9PEcC+3WztLF5VHyiNmYA= > > This is the traditional base64 encoding. > > Process disadvantage: You know that someone is bound to challenge the > forward slash just as the document gets to last call. I don't see an > advantage to risk a discuss. > > Practical disadvantage: Gets messed up when converted to a well-known URL. > Consider the following: > > ni:sha-256;t3tjWygyv5Xo8pNZY/E0pB9PEcC+3WztLF5VHyiNmYA=?http=example.com > > This would map to: > > http://example.com/.well-known/ni/sha-256/t3tjWygyv5Xo8pNZY/E0pB9PEcC+3WztLF5VHyiNmYA= > > The forward slash is not a hierarchy indicator which is bad. Worse still > this would mean that support for ni digest objects requires a code plug in > for Apache, IIS etc rather than just mapping .well-known/ni/sha-256 to the > directory with the digest values. > > > *Base64url:* > > ni:sha-256;t3tjWygyv5Xo8pNZY_E0pB9PEcC-3WztLF5VHyiNmYA > > This is essentially the same as base64 for size etc. The only disadvantage > being that the encoder has to be scratch written. (Mine took 20 mins). > > The advantage over plain base64 is that there is no code required to support > the .well-known version of the locator scheme on the server at all. Just > some admin stuff. Also the URL is completely compatible with URI process > lore. > > > *Summary:* > > Arguments can be made for each one of these schemes. I think the argument > for Base16 is the weakest since Base32 can do everything that Base16 can do. > Neither is implemented as a standard library function on my platform. > > If we went for Base32, I would argue for allowing some form of readability > separator. Base32s is much easier to transcribe than plain Base32. > > Base64/Base64url offer the best compression in a practical form. For most > applications a truncated digest will be acceptable. The main disadvantage of > the Base64 schemes is that they are case sensitive. This will play merry > heck with case insensitive but case preserving file systems such as > Windows. > > I think we should knock out base16 from consideration as base32 does it > better. > > Since it is fairly easy to write a filter that strips out the separators, I > would argue for allowing separators at any point in the identifier but that > the canonical form is with the separators stripped out and this is what is > used to create the URL form. So > > ni:sha-256;W5AGGA-BIGKAJ-LAHSSNA-GHABUU-QAE6AGA-X3AGZA-BMLZAB-6AENTGAA > > would map to > > http://example.com/.well-known/ni/sha-256/W5AGGABIGKAJLAHSSNAGHABUUQAE6AGAX3AGZABMLZAB6AENTGAA > > This preserves the criteria that Apache, IIS etc can be configured to > resolve these identifiers without new code. > > > Taking out Base 16 and base32 without separators, I see the following > options: > > Base32s only > Base64 only > Base64url only > Base32s + Base64url > > I can see pros and cons for the base32 encoding. To make it really readable > it is necessary to put in the separators which is something of an overhead. > So I can see an argument for both. > > But if we only pick one I would say take base32 with separators. It is not > the most compact but it is good enough. It is fully URL compatible and has > the readability benefit. > > > Here is Base32 in C#: > > string ToBase32String(byte[] data, int Length) { > string result = ""; > int offset = 0; > int a = 0; > > for (int i = 0; i< Length; i++) { > a = (a<< 8) | data[i]; > offset += 8; > > while (offset>= 5) { > offset -= 5; > > int n = a>> offset; > result = result + BASE32[n]; > a = a& (0x1f>> (5 - offset)); > } > } > > if (offset> 0) { > result = result + BASE32[a]; > } > return result; > } > > Here is base64url in C#: > > string ToBase64urlString(byte[] data, int Length) { > string result = ""; > int offset = 0; > int a = 0; > > for (int i = 0; i< Length; i++) { > a = (a<< 8) | data[i]; > offset += 8; > > //Console.WriteLine ("{0:x4}/{2:3} : {1}", a, result, > offset); > > while (offset>= 6) { > offset -= 6; > > int n = a>> offset; > result = result + BASE64URL[n]; > a = a& (0x3f>> (6 - offset)); > } > } > if (offset> 0) { > result = result + BASE64URL[a]; > } > return result; > } > > > > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade From duerst@it.aoyama.ac.jp Fri Oct 7 04:19:59 2011 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 3DF0121F8B2B for ; Fri, 7 Oct 2011 04:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.741 X-Spam-Level: X-Spam-Status: No, score=-99.741 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, 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 EFDtl+neGSQq for ; Fri, 7 Oct 2011 04:19:58 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id E838321F8B1C for ; Fri, 7 Oct 2011 04:19:57 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id p97BN49V002403 for ; Fri, 7 Oct 2011 20:23:04 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 4b0e_95e2_b9132c30_f0d6_11e0_b67f_001d096c5782; Fri, 07 Oct 2011 20:23:03 +0900 Received: from [IPv6:::1] ([133.2.210.1]:51137) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 7 Oct 2011 20:23:06 +0900 Message-ID: <4E8EE110.9090502@it.aoyama.ac.jp> Date: Fri, 07 Oct 2011 20:22:56 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Stephen Farrell References: <4E8EBE4E.2040203@cs.tcd.ie> In-Reply-To: <4E8EBE4E.2040203@cs.tcd.ie> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: websec , decade@ietf.org Subject: Re: [websec] [decade] Digest: Adventures in encoding 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, 07 Oct 2011 11:19:59 -0000 Hello Stephen, On 2011/10/07 17:54, Stephen Farrell wrote: > > Hi Phill, > > Oauth [1] uses ""application/x-www-form-urlencoded" format as defined by > [W3C.REC-html401-19991224]" all over the place to solve basically > this problem but in the context of HTTP URLs which has to be worse > than for a new URI scheme. > > Why not do the same here? Are you thinking about this for escaping characters such as slashes? Or do you think we should take the binary hash, look at it as a series of 8-bit bytes, and escape each of these bytes with %-encoding? For the former, we already have the filesystem-safe version (passing a slash with %-encoding to a decent server might allow the server to use the slash *in* the filename, but that would confuse users and a whole lot of other software. For the later, this would essentially be base16 with a lot of '%' characters mixed in. As for Phil's original ideas, if there's a security issue with distinguishing upper- and lowercase filenames on Windows, then abandoning base64 may be a good idea. I wouldn't know of and couldn't imagine a structural security issue, but then I'm no security expert, but there's certainly some erosion, up to one bit per 6 bits if all of the characters are alphabetic. As for Base32, I don't like it too much because it seems to be totally new, and I prefer using existing stuff if it's good enough. This may show up in code. In scripting languages (think Perl, Ruby,...), Base64 and Base16 are simple pack operations, and Base64url is a pack and a tr, but Base32 needs handcoding. Also, Base32 aligns 8 characters to 5 bytes, Base64 4 characters to 3 bytes, and Base16 2 characters to 1 byte, and I somehow prefer a more regular alignment (although the reason for this may be that I never completely figured out how to handle the non-aligned stuff at the end). As for the Base32 with slashes, why not just leave the choice of having slashes or not to the creator, and require the consumer to take them out (as Phil proposed anyway). But with the "slashes being taken out" I don't understand Phil's argument about direct mapping to file names. On the other hand, I think allowing both Base32s and Base64url is a non-starter. Why have two if one is good enough? And then you can't map to URI paths because somebody could transform the digest from one version to another to squeeze it. Also, I don't understand Phil's length issues (Base32 is almost as good as Base64, so it's good, but Base16 is too long); he seems to have a specific upper length in mind for a specific use case, which I think is always a bad idea. (Others may have other limits that are a bit shorter or a bit longer.) What I still don't understand is where the pressure for having to have the digest and part of the URI path needing to be the same comes from. If I want to have a digest protection for a page directly at http://www.example.org/, shouldn't I be able to do so? I tried to ask about this previously, but I still didn't get the point, sorry. Regards, Martin. > S. > > [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-4.1.1 > > On 10/07/2011 03:49 AM, Phillip Hallam-Baker wrote: >> Following on the base16/base64 discussion, I have written some code (see >> end) and have some ni digests in various flavors of encoding. >> >> My conclusion is that we should split the difference and do base32 >> instead. >> I think the arguments are actually quite compelling. >> >> This is only an encoding issue. So choosing an encoding that requires the >> least number of systems to be touched is my priority. Choosing base32 >> allows >> the resolution scheme to be supported by unmodified Apache and IIS. >> >> The additional code burden for ni/digest implementers to write base32 is >> trivial >> >> >> There is also the option of doing more than one encoding. But Base64 uris >> are only slightly shorter. >> >> >> *Base16* >> ni:sha-256;B77B635B2832BF95E8F2935963F134A41F4F11C0BEDD6CED2C5E551F288D9980 >> >> >> Problem - very long even without separators. >> >> >> *Base32:* >> ni:sha-256;W5AGGABIGKAJLAHSSNAGHABUUQAE6AGAX3AGZABMLZAB6AENTGAA >> >> Advantage: more compact than Base16 (somewhat), can be read out over a >> telephone or terminal room (try that with Base64). Can be printed as a >> static reference in a journal or equivalent. >> >> >> *Base32s:* >> ni:sha-256;W5AGGA-BIGKAJ-LAHSSNA-GHABUU-QAE6AGA-X3AGZA-BMLZAB-6AENTGAA >> >> This is my own invention, basically Base32 with separators added for >> readability. >> >> >> *Base64:* >> ni:sha-256;t3tjWygyv5Xo8pNZY/E0pB9PEcC+3WztLF5VHyiNmYA= >> >> This is the traditional base64 encoding. >> >> Process disadvantage: You know that someone is bound to challenge the >> forward slash just as the document gets to last call. I don't see an >> advantage to risk a discuss. >> >> Practical disadvantage: Gets messed up when converted to a well-known >> URL. >> Consider the following: >> >> ni:sha-256;t3tjWygyv5Xo8pNZY/E0pB9PEcC+3WztLF5VHyiNmYA=?http=example.com >> >> This would map to: >> >> http://example.com/.well-known/ni/sha-256/t3tjWygyv5Xo8pNZY/E0pB9PEcC+3WztLF5VHyiNmYA= >> >> >> The forward slash is not a hierarchy indicator which is bad. Worse still >> this would mean that support for ni digest objects requires a code >> plug in >> for Apache, IIS etc rather than just mapping .well-known/ni/sha-256 to >> the >> directory with the digest values. >> >> >> *Base64url:* >> >> ni:sha-256;t3tjWygyv5Xo8pNZY_E0pB9PEcC-3WztLF5VHyiNmYA >> >> This is essentially the same as base64 for size etc. The only >> disadvantage >> being that the encoder has to be scratch written. (Mine took 20 mins). >> >> The advantage over plain base64 is that there is no code required to >> support >> the .well-known version of the locator scheme on the server at all. Just >> some admin stuff. Also the URL is completely compatible with URI process >> lore. >> >> >> *Summary:* >> >> Arguments can be made for each one of these schemes. I think the argument >> for Base16 is the weakest since Base32 can do everything that Base16 >> can do. >> Neither is implemented as a standard library function on my platform. >> >> If we went for Base32, I would argue for allowing some form of >> readability >> separator. Base32s is much easier to transcribe than plain Base32. >> >> Base64/Base64url offer the best compression in a practical form. For most >> applications a truncated digest will be acceptable. The main >> disadvantage of >> the Base64 schemes is that they are case sensitive. This will play merry >> heck with case insensitive but case preserving file systems such as >> Windows. >> >> I think we should knock out base16 from consideration as base32 does it >> better. >> >> Since it is fairly easy to write a filter that strips out the >> separators, I >> would argue for allowing separators at any point in the identifier but >> that >> the canonical form is with the separators stripped out and this is >> what is >> used to create the URL form. So >> >> ni:sha-256;W5AGGA-BIGKAJ-LAHSSNA-GHABUU-QAE6AGA-X3AGZA-BMLZAB-6AENTGAA >> >> would map to >> >> http://example.com/.well-known/ni/sha-256/W5AGGABIGKAJLAHSSNAGHABUUQAE6AGAX3AGZABMLZAB6AENTGAA >> >> >> This preserves the criteria that Apache, IIS etc can be configured to >> resolve these identifiers without new code. >> >> >> Taking out Base 16 and base32 without separators, I see the following >> options: >> >> Base32s only >> Base64 only >> Base64url only >> Base32s + Base64url >> >> I can see pros and cons for the base32 encoding. To make it really >> readable >> it is necessary to put in the separators which is something of an >> overhead. >> So I can see an argument for both. >> >> But if we only pick one I would say take base32 with separators. It is >> not >> the most compact but it is good enough. It is fully URL compatible and >> has >> the readability benefit. >> >> >> Here is Base32 in C#: >> >> string ToBase32String(byte[] data, int Length) { >> string result = ""; >> int offset = 0; >> int a = 0; >> >> for (int i = 0; i< Length; i++) { >> a = (a<< 8) | data[i]; >> offset += 8; >> >> while (offset>= 5) { >> offset -= 5; >> >> int n = a>> offset; >> result = result + BASE32[n]; >> a = a& (0x1f>> (5 - offset)); >> } >> } >> >> if (offset> 0) { >> result = result + BASE32[a]; >> } >> return result; >> } >> >> Here is base64url in C#: >> >> string ToBase64urlString(byte[] data, int Length) { >> string result = ""; >> int offset = 0; >> int a = 0; >> >> for (int i = 0; i< Length; i++) { >> a = (a<< 8) | data[i]; >> offset += 8; >> >> //Console.WriteLine ("{0:x4}/{2:3} : {1}", a, result, >> offset); >> >> while (offset>= 6) { >> offset -= 6; >> >> int n = a>> offset; >> result = result + BASE64URL[n]; >> a = a& (0x3f>> (6 - offset)); >> } >> } >> if (offset> 0) { >> result = result + BASE64URL[a]; >> } >> return result; >> } >> >> >> >> _______________________________________________ >> decade mailing list >> decade@ietf.org >> https://www.ietf.org/mailman/listinfo/decade > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > From stephen.farrell@cs.tcd.ie Fri Oct 7 04:46:07 2011 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 D960E21F8ADC; Fri, 7 Oct 2011 04:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.149 X-Spam-Level: X-Spam-Status: No, score=-106.149 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 XvKz1GcoGDhT; Fri, 7 Oct 2011 04:46:07 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1D84421F893C; Fri, 7 Oct 2011 04:46:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id C651C171C9B; Fri, 7 Oct 2011 12:49:15 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1317988155; bh=4fCIEuBE/GR0xh aFp8n+ehl2/TrbYl5uCqkU5ee3Gdk=; b=nmd/o0na46quSlhfXkSXx3ROIIJyTY o6rHFlayj9OcjatKcezGPsGh3lro7m9TaaFg70aGkDszDDRkJCZbQ/HbRAygcR4f fO/f0SCTMI2jQ1961FmjpRWQw8xk2PTMwQJ0Gx+BxRCkDEMaxyHR1Z8tICZ2UtFd uDWlXdTproNVcDcskzA1fnJDuFKBBCHLVnQqr8cnVx0smVEJhkMygz9YMPDsoJhI 7+dDn5S5/xP/BNoE4ev4NlEuW+jZCARC/zsgYvFlT9air77CxSbRgxfx7VrJvei3 dofj3SVgzjZZYvbKn1u953NpOml0YMzeb0Emp1bX+RZvso6TgqKXG9Yw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id SWrsxcqISJrG; Fri, 7 Oct 2011 12:49:15 +0100 (IST) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id B8B15171C43; Fri, 7 Oct 2011 12:49:13 +0100 (IST) Message-ID: <4E8EE72E.8070809@cs.tcd.ie> Date: Fri, 07 Oct 2011 12:49:02 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= References: <4E8EBE4E.2040203@cs.tcd.ie> <4E8EE110.9090502@it.aoyama.ac.jp> In-Reply-To: <4E8EE110.9090502@it.aoyama.ac.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: websec , decade@ietf.org Subject: Re: [websec] [decade] Digest: Adventures in encoding 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, 07 Oct 2011 11:46:08 -0000 On 10/07/2011 12:22 PM, "Martin J. Dürst" wrote: > Hello Stephen, > > On 2011/10/07 17:54, Stephen Farrell wrote: >> >> Hi Phill, >> >> Oauth [1] uses ""application/x-www-form-urlencoded" format as defined by >> [W3C.REC-html401-19991224]" all over the place to solve basically >> this problem but in the context of HTTP URLs which has to be worse >> than for a new URI scheme. >> >> Why not do the same here? > > Are you thinking about this for escaping characters such as slashes? Right. Sorry I should've been clearer. I meant use base64 like pretty much all other crypyo->text stuff and then do the application/x-www-form-urlencoded thing. > As for Phil's original ideas, if there's a security issue with > distinguishing upper- and lowercase filenames on Windows, then > abandoning base64 may be a good idea. I wouldn't know of and couldn't > imagine a structural security issue, but then I'm no security expert, > but there's certainly some erosion, up to one bit per 6 bits if all of > the characters are alphabetic. I don't know of a real use-case where windows case sensitive file names are a real issue. > What I still don't understand is where the pressure for having to have > the digest and part of the URI path needing to be the same comes from. > If I want to have a digest protection for a page directly at > http://www.example.org/, shouldn't I be able to do so? I tried to ask > about this previously, but I still didn't get the point, sorry. I'm not sure what you're asking;-) But, if we use b64+form encoding then does this question go away? S. From hallam@gmail.com Fri Oct 7 08:18:18 2011 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 9A6ED21F8ABE; Fri, 7 Oct 2011 08:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.489 X-Spam-Level: X-Spam-Status: No, score=-3.489 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Xr2rOveHq7TO; Fri, 7 Oct 2011 08:18:14 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFEB21F888A; Fri, 7 Oct 2011 08:18:14 -0700 (PDT) Received: by ggnk3 with SMTP id k3so3479514ggn.31 for ; Fri, 07 Oct 2011 08:21:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0WhVXQkOjRLcgFA7g4Z53t8VF0paqYtieJDVRe2Hu58=; b=CTF3aP/B6wHyda+ctnN8S6SRZQk+mvR0BXuIyhFyRQZNRP/nUl6bXGACduClAQiAmu OBOlr/+xz/D8nRKdwNK7hqKXpIzUaoPaEVsNxl3nWP41NQjdOo2FZJmHouV7YsCAqWkk sjvwIMbiz4sCj8jcYZIqYiy0t015CMSP5m1GY= MIME-Version: 1.0 Received: by 10.100.18.21 with SMTP id 21mr1560011anr.118.1318000888097; Fri, 07 Oct 2011 08:21:28 -0700 (PDT) Received: by 10.100.212.14 with HTTP; Fri, 7 Oct 2011 08:21:28 -0700 (PDT) In-Reply-To: <4E8EBE4E.2040203@cs.tcd.ie> References: <4E8EBE4E.2040203@cs.tcd.ie> Date: Fri, 7 Oct 2011 11:21:28 -0400 Message-ID: From: Phillip Hallam-Baker To: Stephen Farrell Content-Type: multipart/alternative; boundary=0016e6476472bfad5f04aeb6fe76 Cc: decade@ietf.org, websec Subject: Re: [websec] [decade] Digest: Adventures in encoding 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, 07 Oct 2011 15:18:18 -0000 --0016e6476472bfad5f04aeb6fe76 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 7, 2011 at 4:54 AM, Stephen Farrell wrote: > > Hi Phill, > > Oauth [1] uses ""application/x-www-form-**urlencoded" format as defined by > [W3C.REC-html401-19991224]" all over the place to solve basically > this problem but in the context of HTTP URLs which has to be worse > than for a new URI scheme. > > Why not do the same here? > > S. > > [1] http://tools.ietf.org/html/**draft-ietf-oauth-v2-22#**section-4.1.1 That works for me. It is easy enough to do in scripting. May even be possible to use the plain base64 in the ni form of the identifier and form encode it when using it to form a URL (or whatever else required in a protocol). -- Website: http://hallambaker.com/ --0016e6476472bfad5f04aeb6fe76 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Oct 7, 2011 at 4:54 AM, Stephen Farrell <= stephen.farrell@cs.tcd.ie&= gt; wrote:

Hi Phill,

Oauth [1] uses ""application/x-www-form-urlencoded" f= ormat as defined by
[W3C.REC-html401-19991224]" all over the place to solve basically
this problem but in the context of HTTP URLs which has to be worse
than for a new URI scheme.

Why not do the same here?

S.

[1] http://tools.ietf.org/html/draft-ietf-oauth-v= 2-22#section-4.1.1

That works fo= r me. It is easy enough to do in scripting.

May even be possible to use the plain base64 in t= he ni form of the identifier and form encode it when using it to form a URL= (or whatever else required in a protocol).


--
Website: http://hallambake= r.com/

--0016e6476472bfad5f04aeb6fe76-- From hallam@gmail.com Fri Oct 7 08:41:27 2011 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 2B18421F8C59; Fri, 7 Oct 2011 08:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=-0.967, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, SARE_OBFU_SPLIT_HR2=0.183] 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 TIPEGqQkCyCn; Fri, 7 Oct 2011 08:41:23 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id F386B21F8C58; Fri, 7 Oct 2011 08:41:22 -0700 (PDT) Received: by ggnk3 with SMTP id k3so3505908ggn.31 for ; Fri, 07 Oct 2011 08:44:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zZw8qKv4tUTebjVT2CACbL5O7FGrJoMOhp5keBYu8rI=; b=u1optjdr6Ikzm/gRutosMlGCzLDLiIa+QRPOHhNUiF8/DtIwjbyoQ3TOsXTAkCXBLX R8WR4Txz+Pg//2btfjnjmUOa1DVBfNuArbmS650Ad3wiR53Y5a02VvE6Ndm47TM6bjV/ 0VI2x3VnytKPtYxasldihY0JIJapTrq4Rrwiw= MIME-Version: 1.0 Received: by 10.101.169.16 with SMTP id w16mr368490ano.74.1318002276554; Fri, 07 Oct 2011 08:44:36 -0700 (PDT) Received: by 10.100.212.14 with HTTP; Fri, 7 Oct 2011 08:44:36 -0700 (PDT) In-Reply-To: <4E8EE110.9090502@it.aoyama.ac.jp> References: <4E8EBE4E.2040203@cs.tcd.ie> <4E8EE110.9090502@it.aoyama.ac.jp> Date: Fri, 7 Oct 2011 11:44:36 -0400 Message-ID: From: Phillip Hallam-Baker To: =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= Content-Type: multipart/alternative; boundary=001636c92c9881d74204aeb751c9 Cc: decade@ietf.org, websec Subject: Re: [websec] [decade] Digest: Adventures in encoding 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, 07 Oct 2011 15:41:27 -0000 --001636c92c9881d74204aeb751c9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Oct 7, 2011 at 7:22 AM, "Martin J. D=FCrst" wrote: > > As for Phil's original ideas, if there's a security issue with > distinguishing upper- and lowercase filenames on Windows, then abandoning > base64 may be a good idea. I wouldn't know of and couldn't imagine a > structural security issue, but then I'm no security expert, but there's > certainly some erosion, up to one bit per 6 bits if all of the characters > are alphabetic. > It may not be too much of an issue. Windows probably couldn't cope with 2^6= 4 files in one directory, let alone 2^128 so there would have to be some post-processing on the back end for those cases. > As for Base32, I don't like it too much because it seems to be totally ne= w, > and I prefer using existing stuff if it's good enough. This may show up i= n > code. In scripting languages (think Perl, Ruby,...), Base64 and Base16 ar= e > simple pack operations, and Base64url is a pack and a tr, but Base32 need= s > handcoding. Also, Base32 aligns 8 characters to 5 bytes, Base64 4 charact= ers > to 3 bytes, and Base16 2 characters to 1 byte, and I somehow prefer a mor= e > regular alignment (although the reason for this may be that I never > completely figured out how to handle the non-aligned stuff at the end). > It just drops out with zero bits padding the last chunk. The code is not complex, about 10 lines for the inner loop. > As for the Base32 with slashes, why not just leave the choice of having > slashes or not to the creator, and require the consumer to take them out = (as > Phil proposed anyway). But with the "slashes being taken out" I don't > understand Phil's argument about direct mapping to file names. > It is probably a separate use case to DECADE. I was thinking we might need it in WebSec - possibly. For example, imagine that we have an attack going on with Bank of Ethel and Ethel is asking me to push out a security policy in our AV system by telephone. I have tried reading Base64 over the telephone and it is not a pleasant thing to do. > On the other hand, I think allowing both Base32s and Base64url is a > non-starter. Why have two if one is good enough? And then you can't map t= o > URI paths because somebody could transform the digest from one version to > another to squeeze it. > Well the pragmatic issue is that I am holding up someone who is wanting to write code. So if I take a guess and it is wrong we end up with a legacy issue :-( We do have an escape hole though. The separator between the algorithm and the data. That can be used as an encoding switch. So we can use ; for one encoding, | for another and so on. For forwards compatibility we can require the interim stuff to accept both encodings and decode form encoding and to generate base64 by default but be capable of emitting base32 and formencode(base64)). > What I still don't understand is where the pressure for having to have th= e > digest and part of the URI path needing to be the same comes from. If I w= ant > to have a digest protection for a page directly at http://www.example.org= /, > shouldn't I be able to do so? I tried to ask about this previously, but I > still didn't get the point, sorry. > Ah the issue there is that if the browser has the necessary smarts it can look at: ">This is a strong link to static content And determine that the URL is a strong link and apply appropriate processin= g when in strict mode (or whatever). This link is 100% backwards compatible with existing browsers. all it does is to add in some extra semantics. So for the 'strong link' application, browsers would not need to support th= e ni: scheme at all and it would not be necessary to provide different conten= t according to whether the browser did or did not understand the content. > Regards, Martin. > > S. >> >> [1] http://tools.ietf.org/html/**draft-ietf-oauth-v2-22#**section-4.1.1<= http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-4.1.1> >> >> On 10/07/2011 03:49 AM, Phillip Hallam-Baker wrote: >> >>> Following on the base16/base64 discussion, I have written some code (se= e >>> end) and have some ni digests in various flavors of encoding. >>> >>> My conclusion is that we should split the difference and do base32 >>> instead. >>> I think the arguments are actually quite compelling. >>> >>> This is only an encoding issue. So choosing an encoding that requires t= he >>> least number of systems to be touched is my priority. Choosing base32 >>> allows >>> the resolution scheme to be supported by unmodified Apache and IIS. >>> >>> The additional code burden for ni/digest implementers to write base32 i= s >>> trivial >>> >>> >>> There is also the option of doing more than one encoding. But Base64 ur= is >>> are only slightly shorter. >>> >>> >>> *Base16* >>> ni:sha-256;**B77B635B2832BF95E8F2935963F134** >>> A41F4F11C0BEDD6CED2C5E551F288D**9980 >>> >>> >>> Problem - very long even without separators. >>> >>> >>> *Base32:* >>> ni:sha-256;**W5AGGABIGKAJLAHSSNAGHABUUQAE6A**GAX3AGZABMLZAB6AENTGAA >>> >>> Advantage: more compact than Base16 (somewhat), can be read out over a >>> telephone or terminal room (try that with Base64). Can be printed as a >>> static reference in a journal or equivalent. >>> >>> >>> *Base32s:* >>> ni:sha-256;W5AGGA-BIGKAJ-**LAHSSNA-GHABUU-QAE6AGA-X3AGZA-** >>> BMLZAB-6AENTGAA >>> >>> This is my own invention, basically Base32 with separators added for >>> readability. >>> >>> >>> *Base64:* >>> ni:sha-256;t3tjWygyv5Xo8pNZY/**E0pB9PEcC+3WztLF5VHyiNmYA=3D >>> >>> This is the traditional base64 encoding. >>> >>> Process disadvantage: You know that someone is bound to challenge the >>> forward slash just as the document gets to last call. I don't see an >>> advantage to risk a discuss. >>> >>> Practical disadvantage: Gets messed up when converted to a well-known >>> URL. >>> Consider the following: >>> >>> ni:sha-256;t3tjWygyv5Xo8pNZY/**E0pB9PEcC+3WztLF5VHyiNmYA=3D?**http=3D >>> example.com >>> >>> This would map to: >>> >>> http://example.com/.well-**known/ni/sha-256/** >>> t3tjWygyv5Xo8pNZY/E0pB9PEcC+**3WztLF5VHyiNmYA=3D >>> >>> >>> The forward slash is not a hierarchy indicator which is bad. Worse stil= l >>> this would mean that support for ni digest objects requires a code >>> plug in >>> for Apache, IIS etc rather than just mapping .well-known/ni/sha-256 to >>> the >>> directory with the digest values. >>> >>> >>> *Base64url:* >>> >>> ni:sha-256;t3tjWygyv5Xo8pNZY_**E0pB9PEcC-3WztLF5VHyiNmYA >>> >>> This is essentially the same as base64 for size etc. The only >>> disadvantage >>> being that the encoder has to be scratch written. (Mine took 20 mins). >>> >>> The advantage over plain base64 is that there is no code required to >>> support >>> the .well-known version of the locator scheme on the server at all. Jus= t >>> some admin stuff. Also the URL is completely compatible with URI proces= s >>> lore. >>> >>> >>> *Summary:* >>> >>> Arguments can be made for each one of these schemes. I think the argume= nt >>> for Base16 is the weakest since Base32 can do everything that Base16 >>> can do. >>> Neither is implemented as a standard library function on my platform. >>> >>> If we went for Base32, I would argue for allowing some form of >>> readability >>> separator. Base32s is much easier to transcribe than plain Base32. >>> >>> Base64/Base64url offer the best compression in a practical form. For mo= st >>> applications a truncated digest will be acceptable. The main >>> disadvantage of >>> the Base64 schemes is that they are case sensitive. This will play merr= y >>> heck with case insensitive but case preserving file systems such as >>> Windows. >>> >>> I think we should knock out base16 from consideration as base32 does it >>> better. >>> >>> Since it is fairly easy to write a filter that strips out the >>> separators, I >>> would argue for allowing separators at any point in the identifier but >>> that >>> the canonical form is with the separators stripped out and this is >>> what is >>> used to create the URL form. So >>> >>> ni:sha-256;W5AGGA-BIGKAJ-**LAHSSNA-GHABUU-QAE6AGA-X3AGZA-** >>> BMLZAB-6AENTGAA >>> >>> would map to >>> >>> http://example.com/.well-**known/ni/sha-256/** >>> W5AGGABIGKAJLAHSSNAGHABUUQAE6A**GAX3AGZABMLZAB6AENTGAA >>> >>> >>> This preserves the criteria that Apache, IIS etc can be configured to >>> resolve these identifiers without new code. >>> >>> >>> Taking out Base 16 and base32 without separators, I see the following >>> options: >>> >>> Base32s only >>> Base64 only >>> Base64url only >>> Base32s + Base64url >>> >>> I can see pros and cons for the base32 encoding. To make it really >>> readable >>> it is necessary to put in the separators which is something of an >>> overhead. >>> So I can see an argument for both. >>> >>> But if we only pick one I would say take base32 with separators. It is >>> not >>> the most compact but it is good enough. It is fully URL compatible and >>> has >>> the readability benefit. >>> >>> >>> Here is Base32 in C#: >>> >>> string ToBase32String(byte[] data, int Length) { >>> string result =3D ""; >>> int offset =3D 0; >>> int a =3D 0; >>> >>> for (int i =3D 0; i< Length; i++) { >>> a =3D (a<< 8) | data[i]; >>> offset +=3D 8; >>> >>> while (offset>=3D 5) { >>> offset -=3D 5; >>> >>> int n =3D a>> offset; >>> result =3D result + BASE32[n]; >>> a =3D a& (0x1f>> (5 - offset)); >>> } >>> } >>> >>> if (offset> 0) { >>> result =3D result + BASE32[a]; >>> } >>> return result; >>> } >>> >>> Here is base64url in C#: >>> >>> string ToBase64urlString(byte[] data, int Length) { >>> string result =3D ""; >>> int offset =3D 0; >>> int a =3D 0; >>> >>> for (int i =3D 0; i< Length; i++) { >>> a =3D (a<< 8) | data[i]; >>> offset +=3D 8; >>> >>> //Console.WriteLine ("{0:x4}/{2:3} : {1}", a, result, >>> offset); >>> >>> while (offset>=3D 6) { >>> offset -=3D 6; >>> >>> int n =3D a>> offset; >>> result =3D result + BASE64URL[n]; >>> a =3D a& (0x3f>> (6 - offset)); >>> } >>> } >>> if (offset> 0) { >>> result =3D result + BASE64URL[a]; >>> } >>> return result; >>> } >>> >>> >>> >>> ______________________________**_________________ >>> decade mailing list >>> decade@ietf.org >>> https://www.ietf.org/mailman/**listinfo/decade >>> >> ______________________________**_________________ >> websec mailing list >> websec@ietf.org >> https://www.ietf.org/mailman/**listinfo/websec >> >> --=20 Website: http://hallambaker.com/ --001636c92c9881d74204aeb751c9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Oct 7, 2011 at 7:22 AM, "Martin J. D=FCrst" <duerst@it.aoyama.ac.jp> wrote:

As for Phil's original ideas, if there's a security issue with dist= inguishing upper- and lowercase filenames on Windows, then abandoning base6= 4 may be a good idea. I wouldn't know of and couldn't imagine a str= uctural security issue, but then I'm no security expert, but there'= s certainly some erosion, up to one bit per 6 bits if all of the characters= are alphabetic.

It may not be too much of an issue. Window= s probably couldn't cope with 2^64 files in one directory, let alone 2^= 128 so there would have to be some post-processing on the back end for thos= e cases.

=A0
As for Base32, I don't like it too much because it seems to be totally = new, and I prefer using existing stuff if it's good enough. This may sh= ow up in code. In scripting languages (think Perl, Ruby,...), Base64 and Ba= se16 are simple pack operations, and Base64url is a pack and a tr, but Base= 32 needs handcoding. Also, Base32 aligns 8 characters to 5 bytes, Base64 4 = characters to 3 bytes, and Base16 2 characters to 1 byte, and I somehow pre= fer a more regular alignment (although the reason for this may be that I ne= ver completely figured out how to handle the non-aligned stuff at the end).=

It just drops out with zero bits padding t= he last chunk.

The code is not complex, about 10 l= ines for the inner loop.

=A0
As for the Base32 with slashes, why not just leave the choice of having sla= shes or not to the creator, and require the consumer to take them out (as P= hil proposed anyway). But with the "slashes being taken out" I do= n't understand Phil's argument about direct mapping to file names.<= br>

It is probably a separate use case to DECA= DE. I was thinking we might need it in WebSec - possibly.

For example, imagine that we have an attack going on with Bank of E= thel and Ethel is asking me to push out a security policy in our AV system = by telephone. I have tried reading Base64 over the telephone and it is not = a pleasant thing to do.

=A0
On the other hand, I think allowing both Base32s and Base64url is a non-sta= rter. Why have two if one is good enough? And then you can't map to URI= paths because somebody could transform the digest from one version to anot= her to squeeze it.

Well the pragmatic issue is that I am hold= ing up someone who is wanting to write code. So if I take a guess and it is= wrong we end up with a legacy issue :-(

We do hav= e an escape hole though. The separator between the algorithm and the data. = That can be used as an encoding switch.

So we can use ; for one encoding, | for another and so = on.


For forwards compatibility we c= an require the interim stuff to accept both encodings and decode form encod= ing and to generate base64 by default but be capable of emitting base32 and= formencode(base64)).=A0

=A0
What I still don't understand is where the pressure for having to have = the digest and part of the URI path needing to be the same comes from. If I= want to have a digest protection for a page directly at http://www.example.org/, shouldn= 9;t I be able to do so? I tried to ask about this previously, but I still d= idn't get the point, sorry.

Ah the issue there is that if the browser = has the necessary smarts it can look at:


And determine that the URL is a strong= link and apply appropriate processing when in strict mode (or whatever).


This link is 100% backwards compatible with existing= browsers. all it does is to add in some extra semantics.

So for the 'strong link' appli= cation, browsers would not need to support the ni: scheme at all and it wou= ld not be necessary to provide different content according to whether the b= rowser did or did not understand the content.

=A0
Regards, =A0 Martin.

S.

[1] http://tools.ietf.org/html/draft-ietf-oauth-v= 2-22#section-4.1.1

On 10/07/2011 03:49 AM, Phillip Hallam-Baker wrote:
Following on the base16/base64 discussion, I have written some code (see end) and have some ni digests in various flavors of encoding.

My conclusion is that we should split the difference and do base32
instead.
I think the arguments are actually quite compelling.

This is only an encoding issue. So choosing an encoding that requires the least number of systems to be touched is my priority. Choosing base32
allows
the resolution scheme to be supported by unmodified Apache and IIS.

The additional code burden for ni/digest implementers to write base32 is trivial


There is also the option of doing more than one encoding. But Base64 uris are only slightly shorter.


*Base16*
ni:sha-256;B77B635B2832BF95E8F2935963F134A41F4F11C0BEDD6CED2C= 5E551F288D9980


Problem - very long even without separators.


*Base32:*
ni:sha-256;W5AGGABIGKAJLAHSSNAGHABUUQAE6AGAX3AGZABMLZAB6AENTG= AA

Advantage: more compact than Base16 (somewhat), can be read out over a
telephone or terminal room (try that with Base64). Can be printed as a
static reference in a journal or equivalent.


*Base32s:*
ni:sha-256;W5AGGA-BIGKAJ-LAHSSNA-GHABUU-QAE6AGA-X3AGZA-BMLZAB= -6AENTGAA

This is my own invention, basically Base32 with separators added for
readability.


*Base64:*
ni:sha-256;t3tjWygyv5Xo8pNZY/E0pB9PEcC+3WztLF5VHyiNmYA=3D

This is the traditional base64 encoding.

Process disadvantage: You know that someone is bound to challenge the
forward slash just as the document gets to last call. I don't see an advantage to risk a discuss.

Practical disadvantage: Gets messed up when converted to a well-known
URL.
Consider the following:

ni:sha-256;t3tjWygyv5Xo8pNZY/E0pB9PEcC+3WztLF5VHyiNmYA=3D?htt= p=3Dexample.com

This would map to:

http://example.com/.well-known/ni/sha-256/t3tjWygyv5Xo8pNZY/E0pB9PEcC+3WztLF5VHyiNmYA= =3D


The forward slash is not a hierarchy indicator which is bad. Worse still this would mean that support for ni digest objects requires a code
plug in
for Apache, IIS etc rather than just mapping .well-known/ni/sha-256 to
the
directory with the digest values.


*Base64url:*

ni:sha-256;t3tjWygyv5Xo8pNZY_E0pB9PEcC-3WztLF5VHyiNmYA

This is essentially the same as base64 for size etc. The only
disadvantage
being that the encoder has to be scratch written. (Mine took 20 mins).

The advantage over plain base64 is that there is no code required to
support
the .well-known version of the locator scheme on the server at all. Just some admin stuff. Also the URL is completely compatible with URI process lore.


*Summary:*

Arguments can be made for each one of these schemes. I think the argument for Base16 is the weakest since Base32 can do everything that Base16
can do.
Neither is implemented as a standard library function on my platform.

If we went for Base32, I would argue for allowing some form of
readability
separator. Base32s is much easier to transcribe than plain Base32.

Base64/Base64url offer the best compression in a practical form. For most applications a truncated digest will be acceptable. The main
disadvantage of
the Base64 schemes is that they are case sensitive. This will play merry heck with case insensitive but case preserving file systems such as
Windows.

I think we should knock out base16 from consideration as base32 does it
better.

Since it is fairly easy to write a filter that strips out the
separators, I
would argue for allowing separators at any point in the identifier but
that
the canonical form is with the separators stripped out and this is
what is
used to create the URL form. So

ni:sha-256;W5AGGA-BIGKAJ-LAHSSNA-GHABUU-QAE6AGA-X3AGZA-BMLZAB= -6AENTGAA

would map to

http://example.com/.well-= known/ni/sha-256/W5AGGABIGKAJLAHSSNAGHABUUQAE6AGAX3AGZ= ABMLZAB6AENTGAA


This preserves the criteria that Apache, IIS etc can be configured to
resolve these identifiers without new code.


Taking out Base 16 and base32 without separators, I see the following
options:

Base32s only
Base64 only
Base64url only
Base32s + Base64url

I can see pros and cons for the base32 encoding. To make it really
readable
it is necessary to put in the separators which is something of an
overhead.
So I can see an argument for both.

But if we only pick one I would say take base32 with separators. It is
not
the most compact but it is good enough. It is fully URL compatible and
has
the readability benefit.


Here is Base32 in C#:

string ToBase32String(byte[] data, int Length) {
string result =3D "";
int offset =3D 0;
int a =3D 0;

for (int i =3D 0; i< Length; i++) {
a =3D (a<< 8) | data[i];
offset +=3D 8;

while (offset>=3D 5) {
offset -=3D 5;

int n =3D a>> offset;
result =3D result + BASE32[n];
a =3D a& (0x1f>> (5 - offset));
}
}

if (offset> 0) {
result =3D result + BASE32[a];
}
return result;
}

Here is base64url in C#:

string ToBase64urlString(byte[] data, int Length) {
string result =3D "";
int offset =3D 0;
int a =3D 0;

for (int i =3D 0; i< Length; i++) {
a =3D (a<< 8) | data[i];
offset +=3D 8;

//Console.WriteLine ("{0:x4}/{2:3} : {1}", a, result,
offset);

while (offset>=3D 6) {
offset -=3D 6;

int n =3D a>> offset;
result =3D result + BASE64URL[n];
a =3D a& (0x3f>> (6 - offset));
}
}
if (offset> 0) {
result =3D result + BASE64URL[a];
}
return result;
}



_______________________________________________
decade mailing list
decade@ietf.org = https://www.ietf.org/mailman/listinfo/decade
_______________________________________________
websec mailing list
websec@ietf.org = https://www.ietf.org/mailman/listinfo/websec




--
Website: http://hallambaker.com/

--001636c92c9881d74204aeb751c9-- From stephen.farrell@cs.tcd.ie Fri Oct 7 08:42:33 2011 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 3C5FB21F86D0; Fri, 7 Oct 2011 08:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.412 X-Spam-Level: X-Spam-Status: No, score=-106.412 tagged_above=-999 required=5 tests=[AWL=0.188, 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 wAM4oXGnJU7I; Fri, 7 Oct 2011 08:42:29 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4D93221F87D9; Fri, 7 Oct 2011 08:42:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id C9EA6171C9B; Fri, 7 Oct 2011 16:45:39 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1318002339; bh=0rc2SiQmV6Rw3a CJIcuBFNfo7z3FxDG12nqh3ZBitd8=; b=hXm+GHeOi4auP34VanbpmX3oVbrmao pX5swrhT6xaVAs2jEpvJxY0UzeyjYeENRMuqx3ofudKEjyLN3cgFFVG2uiVHDjnl tzIgN2Ck76CoNhP6isiS4YWQJvhL2dMiB+evqlGpxvnwgQ95MYKRDfmQmx8nADP1 XbTDrWfTBoiy1/N76hJsQkb8/l9stJAYgI2X0EivB6gDgMuM0bwGyNHA0yagkgcz NDRM8exNiWd+trS1qi7iqaYZ9wVBh5cKiMY+YcVL43anZSM7atKZhfuBs+3fdXn/ JwdSg2k2Df8HcUI0Udb2s6ZiJq2TfUv4PHDRY9GhcgYoBjS8GDt6VYdw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id KpDXnfow-8sr; Fri, 7 Oct 2011 16:45:39 +0100 (IST) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 6B4BD171C43; Fri, 7 Oct 2011 16:45:39 +0100 (IST) Message-ID: <4E8F1E92.8090700@cs.tcd.ie> Date: Fri, 07 Oct 2011 16:45:22 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <4E8EBE4E.2040203@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: decade@ietf.org, websec Subject: Re: [websec] [decade] Digest: Adventures in encoding 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, 07 Oct 2011 15:42:33 -0000 On 10/07/2011 04:21 PM, Phillip Hallam-Baker wrote: > On Fri, Oct 7, 2011 at 4:54 AM, Stephen Farrell > wrote: > >> >> Hi Phill, >> >> Oauth [1] uses ""application/x-www-form-**urlencoded" format as defined by >> [W3C.REC-html401-19991224]" all over the place to solve basically >> this problem but in the context of HTTP URLs which has to be worse >> than for a new URI scheme. >> >> Why not do the same here? >> >> S. >> >> [1] http://tools.ietf.org/html/**draft-ietf-oauth-v2-22#**section-4.1.1 > > > That works for me. It is easy enough to do in scripting. > > May even be possible to use the plain base64 in the ni form of the > identifier and form encode it when using it to form a URL (or whatever else > required in a protocol). Actually, you're right - that's better. Just use b64 here and note that protocols might have to urlencode. If it turns out to be a problem we can fix later. S. > > From hallam@gmail.com Fri Oct 7 09:37:58 2011 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 9629C21F8C1D; Fri, 7 Oct 2011 09:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.485 X-Spam-Level: X-Spam-Status: No, score=-3.485 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 UjwcfmRt0Zq3; Fri, 7 Oct 2011 09:37:57 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id B52A621F8BFB; Fri, 7 Oct 2011 09:37:57 -0700 (PDT) Received: by gyd12 with SMTP id 12so4595539gyd.31 for ; Fri, 07 Oct 2011 09:41:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lPeCwT5o29/UZ4M1/LSQCa+rEQy3Xm9Rl2O4gAfl4vg=; b=tz66cN9w7B23krPL8u0Zz1w+jBP04wn+xB3XoDCSuvi65Nm9OovE5Yg0cNRJDq+Yom rTvLQAoCTtbxkEj71ogtsnf5U6+kDG2+VWq5apM9jkzS3ToP/sTMB6sTIoYb838RWW7q 2gHKpK9jB8biQMUYq5Wof9gJ4jAwWNwlgzQIk= MIME-Version: 1.0 Received: by 10.100.18.21 with SMTP id 21mr1649451anr.118.1318005670463; Fri, 07 Oct 2011 09:41:10 -0700 (PDT) Received: by 10.100.212.14 with HTTP; Fri, 7 Oct 2011 09:41:10 -0700 (PDT) In-Reply-To: <4E8F1E92.8090700@cs.tcd.ie> References: <4E8EBE4E.2040203@cs.tcd.ie> <4E8F1E92.8090700@cs.tcd.ie> Date: Fri, 7 Oct 2011 12:41:10 -0400 Message-ID: From: Phillip Hallam-Baker To: Stephen Farrell Content-Type: multipart/alternative; boundary=0016e6476472ccca4904aeb81b8a Cc: decade@ietf.org, websec Subject: Re: [websec] [decade] Digest: Adventures in encoding 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, 07 Oct 2011 16:37:58 -0000 --0016e6476472ccca4904aeb81b8a Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 7, 2011 at 11:45 AM, Stephen Farrell wrote: > > > On 10/07/2011 04:21 PM, Phillip Hallam-Baker wrote: > >> On Fri, Oct 7, 2011 at 4:54 AM, Stephen Farrell >> **wrote: >> >> >>> Hi Phill, >>> >>> Oauth [1] uses ""application/x-www-form-****urlencoded" format as >>> defined by >>> [W3C.REC-html401-19991224]" all over the place to solve basically >>> this problem but in the context of HTTP URLs which has to be worse >>> than for a new URI scheme. >>> >>> Why not do the same here? >>> >>> S. >>> >>> [1] http://tools.ietf.org/html/****draft-ietf-oauth-v2-22#**** >>> section-4.1.1 >>> >>> > >>> >> >> >> That works for me. It is easy enough to do in scripting. >> >> May even be possible to use the plain base64 in the ni form of the >> identifier and form encode it when using it to form a URL (or whatever >> else >> required in a protocol). >> > > Actually, you're right - that's better. Just use b64 here and note > that protocols might have to urlencode. If it turns out to be a > problem we can fix later. > Given that the requirement is a SHOULD, a draft that demonstrates that the point was considered should be enough to avoid time in the DISCUSS penalty box. -- Website: http://hallambaker.com/ --0016e6476472ccca4904aeb81b8a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Oct 7, 2011 at 11:45 AM, Stephen= Farrell <stephen.farrell@cs.tcd.ie> wrote:


On 10/07/2011 04:21 PM, Phillip Hallam-Baker wrote:
On Fri, Oct 7, 2011 at 4:54 AM, Stephen Farrell
<stephen.= farrell@cs.tcd.ie>wrote:


Hi Phill,

Oauth [1] uses ""application/x-www-form-**urlencoded"= format as defined by
[W3C.REC-html401-19991224]" all over the place to solve basically
this problem but in the context of HTTP URLs which has to be worse
than for a new URI scheme.

Why not do the same here?

S.

[1] http://tools.ietf.org/html/**draft-ietf-o= auth-v2-22#**section-4.1.1<http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-4.1.1>


That works for me. It is easy enough to do in scripting.

May even be possible to use the plain base64 in the ni form of the
identifier and form encode it when using it to form a URL (or whatever else=
required in a protocol).

Actually, you're right - that's better. Just use b64 here and note<= br> that protocols might have to urlencode. If it turns out to be a
problem we can fix later.

Given that th= e requirement is a SHOULD, a draft that demonstrates that the point was con= sidered should be enough to avoid time in the DISCUSS penalty box.


--
Website: http://hallambaker.com/

--0016e6476472ccca4904aeb81b8a-- From julian.reschke@gmx.de Fri Oct 7 09:44:39 2011 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 2639621F8C9D for ; Fri, 7 Oct 2011 09:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.267 X-Spam-Level: X-Spam-Status: No, score=-104.267 tagged_above=-999 required=5 tests=[AWL=-1.668, 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 wGafWUqVttXP for ; Fri, 7 Oct 2011 09:44:38 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 13DEB21F8C5F for ; Fri, 7 Oct 2011 09:44:37 -0700 (PDT) Received: (qmail invoked by alias); 07 Oct 2011 16:47:51 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp043) with SMTP; 07 Oct 2011 18:47:51 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19OW3IkwoNO604qh8f2ELdvLBTttw0rIzEwAm6UVp Ns6VSXNGKkZ0/z Message-ID: <4E8F2D35.2060806@gmx.de> Date: Fri, 07 Oct 2011 18:47:49 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Stephen Farrell References: <4E8EBE4E.2040203@cs.tcd.ie> In-Reply-To: <4E8EBE4E.2040203@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: websec , decade@ietf.org Subject: Re: [websec] [decade] Digest: Adventures in encoding 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, 07 Oct 2011 16:44:39 -0000 On 2011-10-07 10:54, Stephen Farrell wrote: > > Hi Phill, > > Oauth [1] uses ""application/x-www-form-urlencoded" format as defined by > [W3C.REC-html401-19991224]" all over the place to solve basically > this problem but in the context of HTTP URLs which has to be worse > than for a new URI scheme. > > Why not do the same here? > ... ...because the definition is vague with respect to non-ASCII (that *is* a problem for OAuth, but might be ok here), and because it also leaks the special-casing of SP (encoded as "+") into new areas. If you like the encoding otherwise, then just refer to RFC 3986 for percent-encoding: . Best regards, Julian From g.maone@informaction.com Fri Oct 7 10:39:01 2011 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 8AC9921F8B35 for ; Fri, 7 Oct 2011 10:39:01 -0700 (PDT) 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 1wZbdCk7cVog for ; Fri, 7 Oct 2011 10:39:00 -0700 (PDT) Received: from mail2.informaction.com (mail2.informaction.com [82.103.137.214]) by ietfa.amsl.com (Postfix) with ESMTP id 6620C21F8B7F for ; Fri, 7 Oct 2011 10:39:00 -0700 (PDT) Received: (qmail 12765 invoked by uid 89); 7 Oct 2011 17:42:13 -0000 Received: by simscan 1.3.1 ppid: 12754, pid: 12760, t: 0.1214s scanners: attach: 1.3.1 clamav: 0.95.2/m: Received: from unknown (HELO ?192.168.1.32?) (g.maone@informaction.com@94.33.26.153) by mail2.informaction.com with ESMTPA; 7 Oct 2011 17:42:12 -0000 Message-ID: <4E8F39F4.2050106@informaction.com> Date: Fri, 07 Oct 2011 19:42:12 +0200 From: Giorgio Maone Organization: InformAction User-Agent: Mozilla/5.0 (Windows NT 5.2; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: websec@ietf.org References: <4E8EBE4E.2040203@cs.tcd.ie> <4E8F2D35.2060806@gmx.de> In-Reply-To: <4E8F2D35.2060806@gmx.de> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [websec] [decade] Digest: Adventures in encoding 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, 07 Oct 2011 17:39:01 -0000 I apologize if I'm late in the thread and someone else already pointed this out, or if this is a stupid idea for any other reason, but did you consider so called "base64url", which had been proposed with the very purpose of embedding base64 blobs inside URLs without further encoding? http://tools.ietf.org/html/rfc4648#page-7 Best -- G Julian Reschke wrote, On 07/10/2011 18.47: > On 2011-10-07 10:54, Stephen Farrell wrote: >> >> Hi Phill, >> >> Oauth [1] uses ""application/x-www-form-urlencoded" format as defined by >> [W3C.REC-html401-19991224]" all over the place to solve basically >> this problem but in the context of HTTP URLs which has to be worse >> than for a new URI scheme. >> >> Why not do the same here? >> ... > > ...because the definition is vague with respect to non-ASCII (that *is* a > problem for OAuth, but might be ok here), and because it also leaks the > special-casing of SP (encoded as "+") into new areas. > > If you like the encoding otherwise, then just refer to RFC 3986 for > percent-encoding: > . > > Best regards, Julian > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From hallam@gmail.com Fri Oct 7 17:51:08 2011 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 A3E6221F8B43 for ; Fri, 7 Oct 2011 17:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.485 X-Spam-Level: X-Spam-Status: No, score=-3.485 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 F1gjVEnfPiyI for ; Fri, 7 Oct 2011 17:51:07 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8F30621F88B7 for ; Fri, 7 Oct 2011 17:51:07 -0700 (PDT) Received: by ywm3 with SMTP id 3so5009829ywm.31 for ; Fri, 07 Oct 2011 17:54:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IN0mKqWwB1yPWam2g3SqSaTZkXmQCrkU2aCuCdCI5g8=; b=vtAxlGIa2hhss6en1ju1lAXYyMgr/yr60oblLjv8/MvK4aorkqW5gZ4EqbylARwvbo 14ZZn69NFOQPDhKt+4/WGYZI0iGN8Y861zUVR0nyeyK4KcrPHsPOBC831HHbJ4ZiifF3 X9MVJkRu2su1z2736bHLGelFOMTUuse1/0Mr4= MIME-Version: 1.0 Received: by 10.101.180.25 with SMTP id h25mr2009422anp.8.1318035262203; Fri, 07 Oct 2011 17:54:22 -0700 (PDT) Received: by 10.100.212.14 with HTTP; Fri, 7 Oct 2011 17:54:22 -0700 (PDT) In-Reply-To: <4E8F39F4.2050106@informaction.com> References: <4E8EBE4E.2040203@cs.tcd.ie> <4E8F2D35.2060806@gmx.de> <4E8F39F4.2050106@informaction.com> Date: Fri, 7 Oct 2011 20:54:22 -0400 Message-ID: From: Phillip Hallam-Baker To: Giorgio Maone Content-Type: multipart/alternative; boundary=001636c92b9c9ae88e04aebefffb Cc: websec@ietf.org Subject: Re: [websec] [decade] Digest: Adventures in encoding 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, 08 Oct 2011 00:51:08 -0000 --001636c92b9c9ae88e04aebefffb Content-Type: text/plain; charset=ISO-8859-1 That is one of the six options that I have implemented so far. The pros of base64url is that it is compact and fully compatible The cons are that it may require a modest amount of coding on some platforms, it is case sensitive and it is not suitable for reading over a telephone. My view being in the process of writing code here is that the coding required for the base64url encoding is trivial and that the additional corner case-age introduced by mucking with base64 encoding is much more hassle. But others have different views here. On Fri, Oct 7, 2011 at 1:42 PM, Giorgio Maone wrote: > I apologize if I'm late in the thread and someone else already pointed this > out, or if this is a stupid idea for any other reason, but did you consider > so > called "base64url", which had been proposed with the very purpose of > embedding > base64 blobs inside URLs without further encoding? > > http://tools.ietf.org/html/rfc4648#page-7 > > Best > -- G > > > Julian Reschke wrote, On 07/10/2011 18.47: > > On 2011-10-07 10:54, Stephen Farrell wrote: > >> > >> Hi Phill, > >> > >> Oauth [1] uses ""application/x-www-form-urlencoded" format as defined by > >> [W3C.REC-html401-19991224]" all over the place to solve basically > >> this problem but in the context of HTTP URLs which has to be worse > >> than for a new URI scheme. > >> > >> Why not do the same here? > >> ... > > > > ...because the definition is vague with respect to non-ASCII (that *is* a > > problem for OAuth, but might be ok here), and because it also leaks the > > special-casing of SP (encoded as "+") into new areas. > > > > If you like the encoding otherwise, then just refer to RFC 3986 for > > percent-encoding: > > . > > > > Best regards, Julian > > _______________________________________________ > > websec mailing list > > websec@ietf.org > > https://www.ietf.org/mailman/listinfo/websec > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > -- Website: http://hallambaker.com/ --001636c92b9c9ae88e04aebefffb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That is one of the six options that I have implemented so far.

The pros of base64url is that it is compact and fully compatible

The cons are that it may require a modest amount of c= oding on some platforms, it is case sensitive and it is not suitable for re= ading over a telephone.


My view being in the process of writing = code here is that the coding required for the base64url encoding is trivial= and that the additional corner case-age introduced by mucking with base64 = encoding is much more hassle. But others have different views here.


On Fri, Oct 7, 2011 at 1:42 PM, Gio= rgio Maone <g.maone@informaction.com> wrote:
I apologize if I'm late in the thread and someone else already pointed = this
out, or if this is a stupid idea for any other reason, but did you consider= so
called "base64url", which had been proposed with the very purpose= of embedding
base64 blobs inside URLs without further encoding?

htt= p://tools.ietf.org/html/rfc4648#page-7

Best
-- G


Julian Reschke wrote, On 07/10/2011 18.47:
> On 2011-10-07 10:54, Stephen Farrell= wrote:
>>
>> Hi Phill,
>>
>> Oauth [1] uses ""application/x-www-form-urlencoded"= format as defined by
>> [W3C.REC-html401-19991224]" all over the place to solve basic= ally
>> this problem but in the context of HTTP URLs which has to be worse=
>> than for a new URI scheme.
>>
>> Why not do the same here?
>> ...
>
> ...because the definition is vague with respect to non-ASCII (that *is= * a
> problem for OAuth, but might be ok here), and because it also leaks th= e
> special-casing of SP (encoded as "+") into new areas.
>
> If you like the encoding otherwise, then just refer to RFC 3986 for > percent-encoding:
> <http://greenbytes.de/tech/webdav/rfc3986.html#rfc= .section.2.1>.
>
> Best regards, Julian
> _______________________________________________
> websec mailing list
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec

_______________________________________________
websec mailing list
websec@ietf.org
= https://www.ietf.org/mailman/listinfo/websec



--
Website: http://hallambaker.com/

--001636c92b9c9ae88e04aebefffb-- From julian.reschke@gmx.de Sat Oct 8 11:19:20 2011 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 935CA21F8BA6 for ; Sat, 8 Oct 2011 11:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.082 X-Spam-Level: X-Spam-Status: No, score=-103.082 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 uOQX+2ltaoov for ; Sat, 8 Oct 2011 11:19:16 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 3256E21F8BD8 for ; Sat, 8 Oct 2011 11:19:15 -0700 (PDT) Received: (qmail invoked by alias); 08 Oct 2011 18:22:31 -0000 Received: from p5DCC80F9.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.128.249] by mail.gmx.net (mp070) with SMTP; 08 Oct 2011 20:22:31 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19iqXspMhNilfAyCkP7o7sokUcQwcx0ZR2AuBWGG6 Z2cR3AyPzsMF+x Message-ID: <4E9094E5.5070704@gmx.de> Date: Sat, 08 Oct 2011 20:22:29 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: =JeffH References: <4E8E388B.8020202@KingsMountain.com> In-Reply-To: <4E8E388B.8020202@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] 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, 08 Oct 2011 18:19:20 -0000 On 2011-10-07 01:23, =JeffH wrote: > ... Trying to summarize my concerns and proposals... (1) RFC2616-or-HTTPbis In a perfect world I could give you an exact time-of-arrival for HTTPbis. But the world is not perfect; and progress on HTTPbis mainly depends on the availability of the editors, and, more importantly, people showing up on the HTTPbis mailing list to help in closing issues and reviewing the existing text. So help *is* appreciated. -> (2) Multiple header instances Header fields can occur multiple times, even when they were intended not to. Examples: Location, Content-Length. When this happens, we usually see interop problems because some consumers pick the first, some pick the second, and some combine them using a comma, as described in HTTP spec. This can be dangerous when the repetition makes the message format ambiguous (Content-Length, for instance). It also means that it allows smuggling, relying on checkers/intermediaries only seeing one of the headers. Note that Chrome and FF have become very strict in checking for this for C-L, and FF does even more checks (syntax of C-L, also checks for Location and Content-Disposition). So *if* STS doesn't allow multiple header fields (which would require switching to a comma-separated syntax), the spec should be crystal clear what to do when multiple instances are encountered; in many cases the default should be "ignore the header field" or even "consider the message to be broken". Not sure what's best here. Also note that somebody else may be combining multiple fields into a single one, and the recipient will see those concatenated with commas as separators. Optimally the format is robust enough to detect things like that. (3) ABNF organization Any header field that is extensible needs to define the syntax for the extension point, so existing code can parse them. Don't make extensions different from the builtins with respect to syntax. It just makes the parser more complicated. So just define a single ABNF for STS directives in ABNF. For instance, using RFC 2616 ABNF and list syntax: Strict-Transport-Security = "Strict-Transport-Security" ":" 1#directive ...or when sticking to semicolon: Strict-Transport-Security = "Strict-Transport-Security" ":" directive *( ";" directive ) Then directive = token( "=" ( token / quoted-string ) ) In prose, add additional constrains, such as "MUST contain FOOBAR directive exactly once". Finally, for each builtin directive state the individual syntax of the param *value*, and do not make the ABNF vary based on the directive. Hope this helps. Also worth reading: Best regards, Julian From julian.reschke@gmx.de Sat Oct 8 11:20:39 2011 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 EFE1321F8BD8 for ; Sat, 8 Oct 2011 11:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.052 X-Spam-Level: X-Spam-Status: No, score=-103.052 tagged_above=-999 required=5 tests=[AWL=-0.453, 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 JvrGnxHQzZlD for ; Sat, 8 Oct 2011 11:20:39 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 0A77721F8BE9 for ; Sat, 8 Oct 2011 11:20:38 -0700 (PDT) Received: (qmail invoked by alias); 08 Oct 2011 18:23:53 -0000 Received: from p5DCC80F9.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.128.249] by mail.gmx.net (mp007) with SMTP; 08 Oct 2011 20:23:53 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+o/dtBLIWovUV5xm67yKitb8gqPOtm72x0u9j6Cs s/mY3b4YGLNUOx Message-ID: <4E909536.3090602@gmx.de> Date: Sat, 08 Oct 2011 20:23:50 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: =JeffH References: <4E8E388B.8020202@KingsMountain.com> <4E9094E5.5070704@gmx.de> In-Reply-To: <4E9094E5.5070704@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] 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, 08 Oct 2011 18:20:40 -0000 On 2011-10-08 20:22, Julian Reschke wrote: > ... > directive = token( "=" ( token / quoted-string ) ) > ... And this should have been...: directive = token [ "=" ( token / quoted-string ) ] Best regards, Julian From Jeff.Hodges@KingsMountain.com Fri Oct 14 15:05:02 2011 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 49A2721F8CF1 for ; Fri, 14 Oct 2011 15:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.406 X-Spam-Level: X-Spam-Status: No, score=-98.406 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_48=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 bOyUquV4iA5j for ; Fri, 14 Oct 2011 15:04:59 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6.bluehost.com [IPv6:2605:dc00:100:2::a6]) by ietfa.amsl.com (Postfix) with SMTP id 77FAA21F8CE1 for ; Fri, 14 Oct 2011 15:04:59 -0700 (PDT) Received: (qmail 5361 invoked by uid 0); 14 Oct 2011 22:04:57 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy3.bluehost.com with SMTP; 14 Oct 2011 22:04:56 -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=jwt1HYFRZfg/0LaJAw5X31tRPXsruUdpuKcy/2e9y3E=; b=yVUMTIn7cM3yc1Wqmv/84q8yyUpV25U20cAWPo73l0rV5O0wxhb1tPfvQzTxH1zkVi/TgiJQIXwWHNXDI7lNKmOTeBBuH3SOeMOfSUl8vSoWmYepat9ZyCrzz3AwPO6d; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.136.89]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1REps8-0002fX-Mi for websec@ietf.org; Fri, 14 Oct 2011 16:04:56 -0600 Message-ID: <4E98B208.7080201@KingsMountain.com> Date: Fri, 14 Oct 2011 15:04:56 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 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] Review of draft-evans-palmer-hsts-pinning-00 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, 14 Oct 2011 22:05:02 -0000 Here's my detailed review of https://tools.ietf.org/html/draft-evans-palmer-hsts-pinning-00 ( note that the latter rev in the repository is different/fresher than the -00 rev that'd been sent only to the mailing list the prior day ) Many thanks to ChrisP & ChrisE for writing this up, I think this is something the WebSec WG should further consider. This I-D is a really good start, although there's some fundamental design decisions to make, and it needs a fair bit of work to turn it into a polished spec. Below, I've listed my substantive comments with pointers down into the spec text. I interspersed editorial comments throughout the spec text. Hope this is helpful, =JeffH ------ substantive comments: 0. overall name -- what's pinned in this approach is public keys rather than certs (for specific reasons), so perhaps the mechanism should be called "public key pinning" rather than "certificate pinning". But in any case, the subtle distinction that the public key in certs is what is pinned, rather than the cert as a whole, should be clarified throughout, perhaps by using a term like "key/cert" rather than just "cert" in various places. 0.1. need to further tease appart security considerations and deployment/operational considerations. This is mentioned in various places below. 1. the "digest uri" I-D and thread(s) on websec@ietf.org are attempting to come up with a more general purpose means to reference something while suppling its hash as a part of the reference, with the aim being to have such an approach be used for things such as this pinning effort. see [1] below. probably ought to chime in on review of of those I-Ds from perspective of their suitability for this use case. 2. see [2] below -- wrt specifying the hash of the SubjectPublicKeyInfo 3. issues with breakv and breakc directive approach. See [3] below (multiple occurrences). This is something to explore in a specific separate email thread. 4. need to at least reference -websec-strict-transport-sec wrt details on domain name matching and noting a Pinned HSTS Host, and may need to appropriately "profile" it. See [4] below. 5. pin check machinery is up at the HTTP layer rather than down lower in or near the TLS layer ? See [5] below. 6. need a prose description of behavior, can use pseudo code as an example. See [6] below. 7. UA and server implementation features/optimizations that aren't a part of the protocol proper, e.g. section 2.2, should be placed in separate sections identified as such. See [7] below. 8. "current accepted practice" wrt TLS cert chain validation is not modified or obviated by this mechanism -- this is implicit in the spec but should be made explicit. See [8] below. 9. should tease apart the normative statements and "deployment considerations" aspects from "sec considerations" stuff in the present Section 3 "Risks of Pinning, and Mitigations". See [9] below. 10. need more fully described "deploying a backup pin" and it should be more accurately named, e.g. "deploying backup server cert and pin". See [10] below. 11. should perhaps have an explicit "scope" section with explicit declaration of things that are "in scope" and "out of scope". see [10] below (multiple occurrences). 12. The question of whether this "key/cert pinning" should be designed as an extension to the HSTS mechanism, or accomplished via its own header, is a good question and something to explore in a specific separate email thread. See [12] below. 13. The spec doesn't explicitly state that the response header MUST be received over error-free TLS connection in order to be "noted". Probably should be mentioned even when cast as HSTS extension, but must be mentioned if pins are conveyed in their own separate header field. ----- > Web Security C. Evans > Internet-Draft C. Palmer > Expires: March 24, 2012 Google, Inc. > September 21, 2011 > > > Certificate Pinning Extension for HSTS > draft-evans-palmer-hsts-pinning-00 > > Abstract > > This memo describes an extension to the HTTP Strict Transport > Security specification allowing web host operators to instruct UAs to s/UAs/user agents/ suggest introducing the UA acronym down in spec proper. > remember ("pin") hosts' cryptographic identities for a given period > of time. During that time, UAs will require that the host present a > certificate chain including at least one public key whose fingerprint > matches one or more of the pinned fingerprints for that host. By > effectively reducing the scope of authorities who can authenticate > the domain during the lifetime of the pin, we hope pinning reduces > the incidence of man-in-the-middle attacks due to compromised > Certification Authorities and other authentication errors and > attacks. > > Status of this Memo > > > > 1. Introduction > > We propose to extend the HSTS HTTP header to enable a web host to > express to UAs which certificate(s) UAs may expect to be present in > the host's certificate chain in future connections. We call this > "certificate pinning". [0] But the pins are to the public keys in the certs, and expressly so (as you mention elsewhere below) because sometimes a certificate will change but the embedded public key will not. So perhaps this mechanism should be named "public key pinning" ? > The Google Chrome/ium browser ships with a > static set of pins, and individual users can extend the set of pins. perhaps more generically restate: "At least one user agent has experimented with shipping with a user-extensible embeded set of pins (e.g. Google Chrome)." > Although effective, this does not scale. This proposal addresses the > scale problem. but not the bootstrap MITM problem when the initial pin is conveyed over protocol. > > Deploying certificate pinning safely will require operational and > organizational maturity due to the risk that HSTS Hosts may "brick" should use terms other than those based on "brick" (a colloquialism) -- suggest "render themselves unavailable" or "are rendered unavailable" depending upon enclosing sentence grammar. > themselves by pinning to a certificate that becomes invalid. We > discuss potential mitigations for those risks. We believe that, with > care, host operators can greatly reduce the risk of MITM attacks and > other false-authentication problems for their users without incurring > undue risk. > > This document extends the version of HSTS defined in [hsts-spec] and > follows that document's notational and naming conventions. > > This draft is being discussed on the WebSec Working Group mailing > list, websec@ietf.org. > > 1.1. About Notation > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC 2119. ^^^^^^^^^ did you use here? > > This document includes some pseudocode examples written in a Python- > like language, to clarify UA behavior. The examples assume that a > global data structure, hsts_metadata, exists and contains the HSTS > metadata that the UA has accumulated over time. It is indexable by > domain name and includes the usual HSTS parameters (maxAge, s/maxAge/max-age/g > includesSubDomains) as well as the new HSTS parameter, pins, that > this document introduces. It also assumes a hypothetical X.509 > datatype, denoted with a variable named "certificate", that includes > likely X.509 fields such as public_key (which would correspond to the > SubjectPublicKeyInfo field in a real X.509 certificate). pseudocode should be marked as non-normative and there should be a sufficiently rich prose description, in the present section 2, such that pseudo code isn't strictly necessary, incorporating the material from the para above. > > There are also some working code examples using the Python and Go > languages. > > The examples are intended to be illustrative, not necessarily precise > or using algorithms that a real, optimized UA would employ. these are good to point out, but I don't know if I'd term it "notation". > 2. Server and Client Behavior I suggest having separate sections for an overview of the pinning mechanism's semantics and effects, the syntax, and then the server processing model, and the user agent processing model. > > To set a pin, HSTS Hosts use a new STS extension directive (STS-d- > ext) in their HSTS response header field: pins. To enable pin > revocation (Section 2.3), hosts may also use the new breakv and > breakc directives. > > STS-d-ext-pin = "pins" OWS "=" OWS [fingerprints] > STS-d-ext-breakv = "breakv" OWS "=" OWS fp-type "/" base64-digits > STS-d-ext-breakc = "breakc" OWS "=" OWS base64-digits > > fingerprints = fingerprint > / fingerprint "," fingerprints > > fingerprint = fp-type "/" base64-digits > > fp-type = "sha1" > / "sha256" > > Figure 1 using "/" as a separator ? Base64 includes "/" in its encoding -- perhaps use another char for a separator such as ";" ? [1] see substantive comment (1) above wrt such fingerprint references and "digest uri" et al. note: STS-d-ext needs to be fixed in HTTPS spec to be a "value" so can have "=" in it, but that won't be a big deal if we do this pinning with a separate header field. need to reference RFC4648 for base64. I would put the examples in their own subsection... > Here is an example response header field using the pins extension > (folded for clarity): > > Strict-Transport-Security: max-age=500; includeSubDomains; > pins=sha1/4n972HfV354KP560yw4uqe/baXc=, > sha1/IvGeLsbqzPxdI0b0wuj2xVTdXgc= > > Figure 2 > > Here is an example response header field using both the pins and the > breakv extensions (folded for clarity): > > Strict-Transport-Security: max-age=500; includeSubDomains; > pins=sha1/4n972HfV354KP560yw4uqe/baXc=, > sha1/IvGeLsbqzPxdI0b0wuj2xVTdXgc=; > breakv=sha1/jUQEXH7Q2Ly+Xn/yFWJxAHT3fDc= > > Figure 3 > > The fingerprint is the SHA-1 (or SHA-256) hash of the raw > SubjectPublicKeyInfo field of the certificate, [2] above sentence needs to specify that it is the SubjectPublicKeyInfo (SPKI) from the ASN.1 DER-encoded cert representation that's hashed. Does the hash input include the DER tag and length for SubjectPublicKeyInfo itself, or just hash the DER value of SubjectPublicKeyInfo ? The latter is apparently the practice when crafting a keyIdentifier by hashing the subjectPublicKey (RFC5280) the Go program in Figure 6 (Appendix A) doesn't include the code for cert.RawSubjectPublicKeyInfo so one can't tell what actual portions of the SubjectPublicKeyInfo sequence are getting hashed and used to generate cert key fingerprints (ie are the SPKI's tag and length included in the hash?). probably should include the SubjectPublicKeyInfo definition here in this spec to provide context: SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier, subjectPublicKey BIT STRING } AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER, parameters ANY DEFINED BY algorithm OPTIONAL } -- contains a value of the type -- registered for use with the -- algorithm object identifier value > encoded in base-64 for > brevity. We pin public keys, rather than entire certificates, to > enable operators to generate new certificates containing old public > keys (see [why-fingerprint-key]). (Although host operators may do > this, certification authorities already do. Additionally, when UAs > check certificate chains, they do so by checking that each > certificate is signed by its parent's public key, making the public > key -- not the certificate -- the essential identifier.) perhaps the above para should be up above in a overall exposition section. > > See Appendix A for an example program that generates public key > fingerprints from SubjectPublicKeyInfo fields in certificates. see comment above wrt this example program. > > The breakv directive communicates to UAs a pin break verifier, and > the breakc directive communicates the pin break code. Hosts SHOULD > generate pin break codes and verifiers. When present, UAs MUST note > pin break verifiers and honor pin break codes. See Section 2.3 for a > discussion of verifiers and codes. [3] will comment on breakv and breakc directive approach in separate message. > 2.1. Noting and Validating Pins Noting a Known Pinned HSTS Host, and checking (nee validating) host pins should be separate subsections. If pinning becomes a separate stand-alone policy, then perhaps an appropriate term will be "Pinned Host". > Upon receipt of this header field, the UA will note the HSTS Host as > a Known Pinned HSTS Host. should have an explicit terminology section (above) and define Known Pinned HSTS Host. [4] probably need to reference I-D.ietf-websec-strict-transport-sec ( ) for the details wrt domain name matching and noting a Pinned HSTS Host. > When connecting to a Known Pinned HSTS > Host, the UA will compare the public key fingerprint(s) in the Host's > certificate chain to the pinned fingerprints, and will fail closed s/fail closed/terminate the TLS connection/ > unless at least one public key in the chain has a fingerprint > matching one of the pinned fingerprints. s/matching one/matching one of the set/ > (Following the HSTS > specification, TLS errors for HSTS hosts must be hard, with no chance > for the user to click through any warnings or errors. We treat > fingerprint mismatch in the same way.) so in the HSTS spec, we've moved the "no user recourse" stipulation to "user agent advice", which is non-normative, because it's a protocol spec. > Note that to validate pins, UAs must necessarily read the headers of > a response. [5] response = HTTP response? This implies that the pin check machinery is up at the HTTP layer rather than down lower in or near the TLS layer, which implies that the UA can make normal HTTP requests to a bogus Known Pinned Host, and send cookies, before realizing that the pin check has failed. This is a fundamental security issue. > In case of mismatch, UAs SHOULD NOT read the response > body as part of failing hard. So this is assuming that the pin check is inserted in the HTTP protocol machinery at the point of having read the HTTP header fields, but before processing the body, and making the body processing contingent on the outcome of the pin check (if the host is a Known Pinned Host). > This pseudocode illustrates how UAs validate the certificate chains > they receive from Known Pinned HSTS Hosts. > > def chain_is_pinned_valid(chain, pins): > for certificate in chain: > for fingerprint in pins: > if certificate.public_key.fingerprint == fingerprint: > return True > > return False > > # ... > if not chain_is_pinned_valid(request.tls_info.certificate_chain, > hsts_metadata[request.hostname].pins): > request.fail() > # ... > > Figure 4 [6] a prose description of the behavior described by the above pseudocode is needed. > The pin list appearing in an HSTS header MUST have at least one pin > matching one of the public key fingerprints in the chain that was > validated for the HTTPS connection. having this stipulation of "have _at least one_ pin matching one cert in cert chain from TLS handshake" is a critical nuance: it gives the web app provider (nee host operator) flexibility in terms of which key/cert(s) they pin to, e.g. end host key, intermediate keys, CA root keys. thus security consideration ramifications, and which should be more fully discussed in operational/deployment considerations. > This defends against HTTP header > injection attacks (see Section 3.4.1). it defends against other stuff too, eg TLS MITM via fraudulent cert, depending on which cert(s) in the cert chain one is pinned to. In any case, probably should not mention "defends against" stuff here, rather put it in security considerations (and perhaps mention in overview material) > > UAs MUST cache pins and pin break verifiers for Known Pinned HSTS > Hosts, and MIGHT AS WELL do so in the same manner as other HSTS > metadata. aboves needs to be more rigorous and precise. "MIGHT AS WELL" not recognized as proper spec language :) > If the maxAge directive is present in the HSTS response > header, the HSTS metadata -- including fingerprints in the pins > directive -- expire at that time. expiration time language not rigorous/precise enough. see -websec-strict-transport-sec Section 7. > > 2.2. Interactions With Built-in HSTS Lists > > UAs MAY choose to implement built-in certificate pins, alongside any > built-in HSTS opt-in list. UAs MUST allow users to override a > built-in pin list, including turning it off. [7] this section should be a part of non-normative UA advice > > Hosts can update built-in pin lists by using this extension. does this capture what you're trying to say: "Hosts can update UAs' built-in pin lists through the HSTS-basesd pin mechanism" ? if so should perhaps add some modest details wrt how that be accomplished. > Similarly, UAs can update their built-in pin lists with software > updates. the above is trying to say that UA software updates could convey new built-in pin lists ? > In either case, UAs MUST use the newest information -- > built-in or set via HSTS -- when validating certificate chains for > the host. This overall requirement should probably go somewhere above in a normative portion of Section 2.x. > > 2.3. Un-pinning [3] this section is about server-driven explicit unpinning, rather than, say, unpinning occuring due to cert expiration, yes? should more clearly explain (if this approach remains). will comment on breakv & breakc approach in separate message. > > Hosts can enable pin revocation for their previously-pinned key > fingerprints by setting pin break verifiers using the breakv > directive. Then, when hosts want to break pins, they set the pin > break code in their HSTS headers using the breakc directive. (This > idea is due to Perrin in [pin-break-codes].) > > Pin break codes are short random strings, kept secret until the host > operator wants to break the pins. Pin break verifiers are simply > hashes of the codes. Generating codes and verifiers, and verifying > that codes match a previously set verifier, is trivial. See > Figure 5. > > def make_pin_break(): > code = os.urandom(16) > verifier = hashlib.sha1(code).digest() > return base64.b64encode(code), base64.b64encode(verifier) > > def verify_code(code, verifier): > c = base64.b64decode(code) > v = hashlib.sha1(c).digest() > return verifier == base64.b64encode(v) > > > if __name__ == "__main__": > import sys > > if 1 == len(sys.argv): > print make_pin_break() > elif 3 == len(sys.argv): > print verify_code(sys.argv[1], sys.argv[2]) > > Figure 5 > > Hosts can request that UAs forget pinned fingerprints by issuing a > valid HSTS header containing the pin break code. UAs MUST forget all > pinned fingerprints associated with the matching pin break verifier, > and MUST NOT forget any pinned fingerprints not associated with that > verifier. > > In the event that a host sends an HSTS header containing a breakc do you mean a Known Pinned Host on a connection that has passed a pin check? > that does not match a breakv the UA has previously noted, the UA MUST > ignore that breakc and MUST process any pins or breakv directives as > normal. This is so that hosts can break old pins but still > successfully set new pins and verifiers in UAs that have not > previously (or recently) noted the host. > > Host operators SHOULD keep the pin break code secret, and SHOULD > generate codes that are computationally infeasible to guess (such as > by using their system's cryptographic random number generator; note > that a 128-bit security level suffices). > > 2.4. Pinning Self-Signed Leaf Certificates > > To the extent that UAs allow or enable hosts to authenticate > themselves with self-signed end entity certificates, they MAY also > allow hosts to pin the public keys in such certificates. The > usability and security implications of this practice are outside the > scope of this specification. [8] This (S 2.4) is an important nuance, as is the presently implicit requirement that UAs continue to perform "current accepted practice" cert chain validation. An explicit normative statement of the latter should be made somewhere in S 2, plus the self-signed stuff here in S 2.4 probably should be in another section, not sure exactly where right now, and deserves appropriate mention in Sec Considerations. > 3. Security Considerations [9] this section is overall intended to be operational/deployment considerations, yes? it'd been entitled "Risks of Pinning, and Mitigations" until this rev of the spec. Thus the operational/deployment considerations below should be teased apart from the proper sec cons stuff and placed appropriately in separate sections. There's also at least one normative stipulation below that needs to be in the appropriate normative section above. a brief intro sentence or two here would be good. > > 3.1. Deployment Guidance > > To recover from disasters of various types, as described below, we > recommend that HSTS Hosts follow these guidelines. the below items should probably be numbered subsections so they can be individually referenced. > > o Operators SHOULD have a safety net: they should generate a backup > key pair, get it signed by a different (root and/or intermediary) > CA than their live certificate(s), store it safely offline, and > set this backup pin in their pins directive. By "Set this backup pin" are you trying to say "set a pin to your backup key/cert" ? > * Having a backup certificate was always a good idea anyway. > > o It is most economical to have the backup certificate signed by a > completely different signature chain than the live certificate, to > maximize recoverability in the event of either root or > intermediary signer compromise. > > o Operators SHOULD periodically exercise their backup pin plan -- an > untested backup is no backup at all. > > o Operators SHOULD have a diverse certificate portfolio. They > should pin to a few different roots, owned by different companies > if possible. > > o Operators SHOULD start small. Operators SHOULD first deploy HSTS > certificate pinning by setting a maxAge of minutes or a few hours, > and gradually increase maxAge as they gain confidence in their > operational capability. s/maxAge/max-age/g Perhaps we should find a different term instead of "disaster" ? should include the below from : ...you mustn't pin to a cross-certifying root. For example, GoDaddy's root is signed by Valicert so that older clients, which don't recognise GoDaddy as a root, still trust those certificates. However, you wouldn't want to pin to Valicert because newer clients will stop their chain at GoDaddy. > > 3.2. Disasters Relating to Compromises of Certificates compromises of keys ? > > 3.2.1. The private key for the pinned leaf is stolen > > If a leaf certificate is compromised, the host is likely to have > experienced a complete compromise, in which case the problem is > greater than certificates and pins. See Section 3.4.2. meaning: if one is pinned to one's leaf public key, and the corresponding private key is compromised, then.... > > 3.2.2. The root or intermediary CA is compromised > > This disaster will affect many hosts (HSTS Hosts and other), and will > likely require a client software update (e.g. to revoke the signing > CA and/or the false certificates it issued). > > If the operator has a backup pin whose signature chain is still > valid, they should deploy it. s/backup pin/backup server cert/ ? [10] Should probably succinctly describe, perhaps in an individual section somewhere in "deployment considerations" the steps involved in what you're calling "deploying a backup pin" -- i.e. deploy the backup server cert that corresponds to the "backup pin" that they have (hopefully) been setting in their pins list. See S 3.1. Deployment Guidance, first bullet. > In this case, the host need not even > degrade from Known Pinned to Known. This notion perhaps needs to be more clearly explained. Also, if some given UA encountered the bogus cert before the backup server cert is deployed, it will unpin the host (aka the host degrades to Known HSTS Host from Known Pinned, for that UA). So there is sort of a race condition here. > > 3.3. Disasters Relating to Certificate Mismanagement > > 3.3.1. The leaf certificate expires > > Operators should deploy their backup pin. see comment on "deploy backup pin" above. > > Note that when evaluating a pinned certificate, the UA MUST un-pin > the fingerprint if the certificate has expired. If a pin list > becomes empty, the UA downgrades the host from Known Pinned HSTS Host > to Known HSTS Host. The usual HTTPS validation procedure now > applies. above entire para contains normative stipulations that need to be in the present Sec 2. > > Operators should get any CA to sign a new cert with updated expiry, > based on the existing, unchanged public key. > > o And/or, operators should deploy their backup pin and/or have a CA > sign an all-new key. > > o Operators should continue to set pins in their HSTS header, and > UAs will upgrade from Known HSTS Host to Known Pinned HSTS Host > when the fingerprint(s) refer(s) to valid certificate(s) again. > > > 3.3.2. The leaf certificate is lost how does one "lose" a leaf certificate ? would this be an example: server suffers disk crash, or other catastrophic failure, server cert and/or private key not available for whatever reason ? probably need more rigorous language here. > > Operators should deploy their backup pin. see comment on "deploy backup pin" above. if the server been previously issuing pins to this backup cert, then (a), else (b) .... also, is this presuming one pinned to one's leaf server cert ? i think so given next sentence: > Alternately, if they > pinned to a root or intermediary signer, they should get a new leaf > certificate signed by one of those signers. so these two cases need to be more clearly delineated. > > Operators SHOULD attempt to get the certificate revoked by whatever > means available (extant revocation mechanisms like CRL or OCSP, > blacklisting in the UA, or future revocation mechanisms). > > o We know that extant revocation mechanisms are unreliable. > Operators SHOULD NOT not depend on them. above probably needs more rigorous/accurate language. CRL/OCSP revocation advertisement mechs are via the CA. What should operators do instead of relying on extant revocation mechanisms? The implication is that this pinning mech is one way to supplant such reliance? > > 3.3.3. The CA is extorting the operator approaching renewal/expiry time > > If the backup pin chains to a different signer, the operator should > deploy it. (They should then get a new backup pin.) see comment on "deploy backup pin" above. > > The time running up to renewal can be used to serve additional HSTS > public key hashes, pinning to new root CAs. What is the difference between the above two sentences? > > o Hosts can also disable pinning altogether as described above. which section specifically? you mean via explicit unpinning in S 2.3 ? > > If the host is pinned to leaves or its own intermediary, operators > can simply get a different root CA to sign the existing public key. which public key? needs expanded description. > > If the operator fails to get new certs in time, and the host is > pinned only to the one root CA, the solution is simple; see > Section 3.3.1. > > > 3.4. Disasters Relating to Vulnerabilities in the Known HSTS Host > > 3.4.1. The host is vulnerable to HTTP header injection > > Note that header injection vulnerabilities are in general more severe > than merely disabling pinning for individual users. > > The attacker could set additional pins for certificates he controls, > or pin break verifiers for codes he controls, allowing him to > undetectably MITM clients. When or if the client is outside the > scope of the attacker's MITM attack, the result is DoS. > > The attacker could disable HSTS and pins. the above is a risk if SSL MITM is a possibility, eg via sslstrip et al, what's often termed a "network attacker", but those could be protected against by pinning to the end entity key/cert. probably need to establish more context in the above -- eg it isn't clear via what means you're anticipating that header injection is occuring. if the server host is owned, then we have bigger troubles. no remediation is noted here in S 3.4.1 ? (tho there's no easy ones or server-side detectable ones) > > 3.4.2. The host suffers full server-side compromise > > After setting up a new host, operators should deploy the backup pin. > Alternately, if the host is pinned to a root or intermediary signer, > the operator should get a new leaf certificate signed by one of those > signers. how is the latter different from the former ? in the former one already has a backup server cert & key pair, and the in the latter one doesn't ? see comment on "deploy backup pin" above. > > Operators SHOULD attempt to get the certificate containing the > compromised private key s/compromised private key/public key corresponding to the compromised private key/ > revoked by whatever means available (extant > revocation mechanisms like CRL or OCSP, blacklisting in the UA, or > future revocation mechanisms). > > o We know that extant revocation mechanisms are unreliable. Do not > depend on them. same comments here as on above similar revocation exhortation. > > 4. Usability Considerations User Agent Advice ? > > When pinning works to detect impostor Known Pinned HSTS Hosts, users > will experience denial of service. I wouldn't term this as DoS - rather, users are protected from using an imposter web app. > UAs SHOULD explain the reason why. agreed. > If it happens that true positives (actual attacks) outnumber > false positives (hosts bricking themselves by accident), the feature > will gain a positive reputation. Note that pinning has started life > with a good reputation because it provoked the discovery of the > DigiNotar CA compromise. (When DigiNotar signed a certificate for > *.google.com in August 2011, Chrome users discovered the attack due > to the pre-loaded pins for Google domains.) perhaps this above stuff should be noted somewhere, but maybe not here > We believe that, in general, DoS is a better failure mode than user > account/session compromise or other result of TLS compromise. s/DoS/rendering web applications unavailable/ needs better-composed rationalization of the tradeoffs from user perspective. > UAs MUST have a way for users to clear current pins that were set by > HSTS. UAs SHOULD have a way for users to query the current state of > Known (Pinned) HSTS Hosts. Can't make normative requirements for UA implementation advice in this spec. > 5. Economic Considerations > > If pinning becomes common, host operators might become incentivized > to choose CAs that get compromised less often, or respond better to > compromise. This will require information to flow into the market, > and for people to interpret no news post-compromise as bad news. > Pinning itself will provide some of that information, as will sources > like UA vendor communications, the EFF SSL Observatory, the Qualys > SSL survey, etc. am not sure above para belongs in this protocol spec. perhaps in a separate "rationale" document or other places. > > The disaster recovery plans described above all incur new costs for > host operators, and increase the size of the certificate market. > Arguably, well-run hosts had already absorbed these costs because > (e.g.) backup certificates from different CAs were necessary disaster > recovery mechanisms even before certificate pinning. Small sites -- > which although small might still need to provide good security -- may > not be able to afford the disaster recovery mechanisms we recommend. > (The cost of the backup certificate is not the issue; it is more the > operational costs in safely storing the backup and testing that it > works.) Thus, low-risk pinning may be available only to large sites; > small sites may have to choose no pinning or potentially bricking > their host (up to the maxAge window). This is not worse than the > status quo. perhaps the above should be recast as simply decisions any TLS-based web app provider will need to make -- i.e., whether to obtain backup server certs, whether to test them, etc, and what the ramifications are of (not) doing so. > 6. Ideas this section is for consideration of features/functionality to be possibly be incorporated into the spec proper ? I.e. this section will go away as the spec nears completion ? should probably explain here in a brief intro. > > 6.1. Requiring Backup Pins > > Because bricking risk mitigation requires a backup pin, UAs could > require that the pins directive have at least two fingerprints, at > least one of which does not match any of the public keys in any of > the certificates in the chain. (This idea due to Tom Sepez.) Not sure what such a UA-enforced config would accomplish. Does this imply that UAs would not pin hosts that advertise only one pin ? What is proposed that UAs should do when encountering a host that issues just one pin? this would exclude those that wish to perform a simple pin and assume the risks. Its not clear that the risks are greater for users, except if such a stringent UA behavior were to render some otherwise legit web apps unavailable. perhaps this is more appropriate as an expanded discussion on tradeoffs in deployment considerations. > > 6.2. Prepopulating Pin Lists suggest renaming this "Automatic Pin List Prepopulation" > > HSTS-based certificate pinning, unlike built-in pinning, suffers from > the bootstrap problem. To work around this, we could pre-populate a > built-in pin list with public keys as observed in the wild by one or > more global observers, such as Googlebot, the EFF SSL Observatory, > Convergence notaries, and so on. > > One problem with this approach is that it does not involve host > operators. It is best to get operator consent before signing them up > for a potentially risky new protocol such as this. Therefore we > leave this idea for work (including third-party UA extensions). perhaps this spec should have functional requirements section, noting as one requirement that such a mechanism as cert/key pinning should be driven by the web app provider (what you are calling "host operators"). [11] otherwise probably should remove 3.7.2 or place this "auto pre-population" notion in a (out-of-)scope section. > > 6.3. Tools to Assist Creation of Header > > It would be good to provide tools that read X.509 certificate chains > and generate example HSTS headers that operators can easily add to > their webs erver configurations. out of scope for spec proper, but could be perhaps be mentioned in "deployment considerations" section. > > 6.4. Pinning Subresources this section should be in some "operational considerations" section (which is nominally distinct from a "deployment consderations" section") > > Many hosts have pages that load subresources from domains not under > the control, or under only partial control, of the main host's > operators. add subresource example such as "" > For example, popular hosts often use CDNs, and CDN > customers may have only limited, if any, ability to influence the > configuration of the CDN's servers. (This long-standing problem is > independent of certificate pinning.) > > To a limited extent, the includeSubDomains HSTS directive can address > this: if the CDN host has a name that is a subdomain of the main host > (e.g. assets-from-cdn.example.com points to CDN-owned servers), and > if the main host's operators can guaranteeably keep up-to-date with guaranteeably? > the CDN's server certificate fingerprints -- perhaps as part of > example.com's contract with the CDN -- then the problem may be > solved. > > CDNs SHOULD also use certificate pinning independently of any of > their customers. suggest phrasing this worthy requirement somewhat differently: Web app providers should also assess from whence their various app resources are obtained, and if over TLS/SSL, examine whether pinning those sources is possible (this may involve both business and technical considerations). > > Although one can imagine an extension to this specification allowing > the main resource to set pins for subresources in other domains, it > is complex and fragile both from technical and business perspectives. > The UA would have to accept those pins for the subresource domains > ONLY when loading resources from the subdomains as part of a page > load of the main host. The independence of the two domains' > operations teams would still pose synchronization problems, and > potentially increase the bricking risk. > > Therefore, except in simple cases, this document leaves the cross- > domain subresource problem to future work. Operational experience > with HSTS-based certificate pinning should guide the development of a > plan to handle the problem. [11] add above paras to putative (out-of-)scope section/appendix. > > 6.5. Pinning Without Requiring HTTPS > > Some host operators would like to take advantage of certificate > pinning without requiring HTTPS, but having clients require pins in > the event that they do connect to the host with HTTPS. As specified > above, the current HSTS-based mechanism does not allow for this: > clients that receive the pins directive via HSTS will also therefore > require HTTPS -- that is the purpose of HSTS after all. To have an > additional directive, e.g. mode=optional, would not work because > older clients that support HSTS but not the mode extension would > effectively require HTTPS. > > Alternatives include (a) putting the pins directive in a new header > instead of extending HSTS; and (b) some kind of hack like setting > maxAge=0 and having an additional directive to keep the pins alive > (e.g. pinMaxAge). These alternatives seem ugly to us and we welcome > suggestions for a better way to support this deployment scenario. [12] this overall question is quite apropos. need to explore it on the mailing list (the topic's been opened already: Re: [websec] Pinning and beyond Was: Next rev of HSTS certificate pinning draft (Tobias Gondrom) https://www.ietf.org/mail-archive/web/websec/current/msg00593.html ) > 7. Acknowledgements > > Thanks to Jeff Hodges, Adam Langley, Nicolas Lidzborski, SM, and Yoav > Nir for suggestions and edits that clarified the text. Trevor Perrin > for providing the pin break codes mechanism. Adam Langley provided > the SPKI fingerprint generation code. > > > 8. What's Changed > > This is the first draft of this proposal submitted as an official > Internet Draft. > > > 9. References should have normative and informative references subsections. > > [hsts-spec] > Hodges, J., Jackson, C., and A. Barth, "HTTP Strict > Transport Security (HSTS)", August 2011, tools.ietf.org/html/ > draft-ietf-websec-strict-transport-sec-02>. will need various normative references, eg to RFC5246, RFC4648, there's an auto-generated I-D ref for this.. put this in " and then down in section put.. &I-D.ietf-websec-strict-transport-sec; ..but will need to be below refs are informative.. > > [why-fingerprint-key] > Langley, A., "Public Key Pinning", May 2011, > . > > [pin-break-codes] > Perrin, T., "Self-Asserted Key Pinning", September 2011, > . 2119 is normative ref... > [rfc-2119] > Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", March 1997, > . > > > Appendix A. Fingerprint Generation > > This Go program generates public key fingerprints, suitable for use > in pinning, from PEM-encoded certificates. > > package main > > import ( > "io/ioutil" > "os" > "crypto/sha1" > "crypto/x509" > "encoding/base64" > "encoding/pem" > "fmt" > ) > > func main() { > if len(os.Args) < 2 { > fmt.Printf("Usage: %s PEM-filename\n", os.Args[0]) > os.Exit(1) > } > pemBytes, err := ioutil.ReadFile(os.Args[1]) > if err != nil { > panic(err.String()) > } > block, _ := pem.Decode(pemBytes) > if block == nil { > panic("No PEM structure found") > } > derBytes := block.Bytes > certs, err := x509.ParseCertificates(derBytes) > if err != nil { > panic(err.String()) > } > cert := certs[0] > h := sha1.New() > h.Write(cert.RawSubjectPublicKeyInfo) > digest := h.Sum() > > fmt.Printf("Hex: %x\nBase64: %s\n", digest, > base64.StdEncoding.EncodeToString(digest)) > } > > Figure 6 > > > Authors' Addresses --- end From Jeff.Hodges@KingsMountain.com Fri Oct 14 15:05:10 2011 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 C1C2E21F8D0C for ; Fri, 14 Oct 2011 15:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.151 X-Spam-Level: X-Spam-Status: No, score=-99.151 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_53=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 T8Wonfk+pYxA for ; Fri, 14 Oct 2011 15:05:10 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6.bluehost.com [IPv6:2605:dc00:100:2::a6]) by ietfa.amsl.com (Postfix) with SMTP id 17DCB21F8CE1 for ; Fri, 14 Oct 2011 15:05:09 -0700 (PDT) Received: (qmail 5877 invoked by uid 0); 14 Oct 2011 22:05:09 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy3.bluehost.com with SMTP; 14 Oct 2011 22:05:09 -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=Re4Uzs/7MhHVFAmQroEVgy5Jq+8mxoXCxNujZHKGqhY=; b=M7gToga5IzmtizkWd3yM1gJn+Q9B198jzjjuKanhT+PilsJOKUPextZF0U2sHZCQGbmGVlEjlhXHQy3ehueuX2AU69zREtIfZ4yBqQWKwBfcA70I9hxqV2kJEs7zm6iQ; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.136.89]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1REpsL-0002vb-5n for websec@ietf.org; Fri, 14 Oct 2011 16:05:09 -0600 Message-ID: <4E98B215.6040700@KingsMountain.com> Date: Fri, 14 Oct 2011 15:05:09 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 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] wrt "breaking pins" aka "un-pinning" (breakv, breakc directives; draft-evans-palmer-hsts-pinning-00) 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, 14 Oct 2011 22:05:10 -0000 below is the text on "un-pinning" and the breakv & breakc directives from https://tools.ietf.org/html/draft-evans-palmer-hsts-pinning-00 discussion below this excerpt... > 2. Server and Client Behavior . . > The breakv directive communicates to UAs a pin break verifier, and > the breakc directive communicates the pin break code. Hosts SHOULD > generate pin break codes and verifiers. When present, UAs MUST note > pin break verifiers and honor pin break codes. See Section 2.3 for a > discussion of verifiers and codes. . . 2.1. Noting and Validating Pins . . > UAs MUST cache pins and pin break verifiers for Known Pinned HSTS > Hosts, and MIGHT AS WELL do so in the same manner as other HSTS > metadata. . . > 2.3. Un-pinning > > Hosts can enable pin revocation for their previously-pinned key > fingerprints by setting pin break verifiers using the breakv > directive. Then, when hosts want to break pins, they set the pin > break code in their HSTS headers using the breakc directive. (This > idea is due to Perrin in [pin-break-codes].) > > Pin break codes are short random strings, kept secret until the host > operator wants to break the pins. Pin break verifiers are simply > hashes of the codes. . . > Hosts can request that UAs forget pinned fingerprints by issuing a > valid HSTS header containing the pin break code. UAs MUST forget all > pinned fingerprints associated with the matching pin break verifier, > and MUST NOT forget any pinned fingerprints not associated with that > verifier. > > In the event that a host sends an HSTS header containing a breakc > that does not match a breakv the UA has previously noted, the UA MUST > ignore that breakc and MUST process any pins or breakv directives as > normal. This is so that hosts can break old pins but still > successfully set new pins and verifiers in UAs that have not > previously (or recently) noted the host. > > Host operators SHOULD keep the pin break code secret, and SHOULD > generate codes that are computationally infeasible to guess (such as > by using their system's cryptographic random number generator; note > that a 128-bit security level suffices). In order for this "un-pinning" pin-break-verifier-and-code mechanism to generally work, the UA still connects and and makes an HTTP request and reads response headers. See this paragraph from S 2.1... Note that to validate pins, UAs must necessarily read the headers of a response. In case of mismatch, UAs SHOULD NOT read the response body as part of failing hard. This appears to be necessary in order to receive a break code (breakc) invalidating the pin(s) of a Known Pinned Host that doesn't already have its present cert/key, i.e. that it's showing in the TLS handshake (for whatever reason), cached in UAs. This situation would render the Host unavailable to those UAs. So if a purported Known Pinned Host presents a cert chain in the TLS handshake lacking any keys on the UA's pinned key list, then it could be a bogus host (eg attacker), and if the UA does a HTTP GET and sends cookies (as well as receives a response and examines headers (e.g. the UA could be redirected further afield)) in any case, then this is a (non-trivial) vulnerability. In such a situation, the way the UA can tell it is connected to the intended host is if the host presents a break code that properly matches a previously noted verifier for that host. This property holds because the break code is a secret held by the host until needed. This prevents any host from being able to unpin other hosts, which is necessary when the pin check is located up in the HTTP layer. So we have a fundamental question here: Must the pinning mechanism provide the capability for a pinned host to dynamically recover from situations that otherwise render it unavailable (to those UAs that have noted the host as a Known Pinned Host)? In examining the various such situations (aka "disasters") outlined in Sec 3, it appears that essentially all of them are mitigated if the host operators allocated a backup server key/cert as advised, and have properly issued a pin to it, along with their pin to their present operational key/cert. In this situation, it appears that having the pin-break-verifier-and-code mechanism isn't strictly necessary. Rather, the pin-break-verifier-and-code mechanism is arguably useful only in the case where one doesn't have properly pinned backup server key/cert that chains to a different trust root than one's other key/cert(s). But it has the security issues noted above given its present design. It appears that we need to decide whether this pin-break-verifier-and-code mechanism is worth the complexity and its vulnerability. One argument is that if some web app provider is willing to take the risk of pinning itself without proper, carefully considered recovery means and plans, then that's their decision. Additionally, if UAs provide users the means to clear(and set) pins, then worst-case, they can contact their users with instructions for how to do so, and perhaps along with a new pin to enter. Providers wishing to avoid such situation will need to craft and implement proper, carefully considered recovery means and plans. If we took this approach, then we could eliminate the breakc and breakv directives and manage pins in the a fashion similar to how HSTS works -- the UA notes the freshest info from a Known HSTS Host if it is different than what is presently cached for that host, and a "max-age = 0" will clear the cached metadata for that host. ( this dovetails with a discussion of using a separate header for pinning, "separate pinning header" ) =JeffH ps: of course this discussion begs the question of conveying pinning information in the TLS channel, perhaps as data in an X.509 cert extension, as Adam L is doing for "DNSSEC authenticated HTTPS", or in some other fashion. From Jeff.Hodges@KingsMountain.com Fri Oct 14 15:05:14 2011 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 8839621F8D16 for ; Fri, 14 Oct 2011 15:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.523 X-Spam-Level: X-Spam-Status: No, score=-99.523 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_48=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 4t94QrlGHpGC for ; Fri, 14 Oct 2011 15:05:14 -0700 (PDT) Received: from oproxy3-pub.bluehost.com (oproxy3.bluehost.com [IPv6:2605:dc00:100:2::a3]) by ietfa.amsl.com (Postfix) with SMTP id 054D121F8CE1 for ; Fri, 14 Oct 2011 15:05:13 -0700 (PDT) Received: (qmail 22837 invoked by uid 0); 14 Oct 2011 22:05:13 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy3.bluehost.com with SMTP; 14 Oct 2011 22:05: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=ftMU2iN0ZqMWD9qrAJQFSb47cIE0i7k8YAkKMdxChbc=; b=wlB8P2qM7hetvVgk/SyAWSIen+rJnruTbDpw5MZszpAhh2qjx/ADnPSRUAcknHkvIioXpDB5ULuQ6qQ1bc8jp1y+ecfbDiQXv0FgpquXP5e1vh7Ti97OVccWCqzpNw67; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.136.89]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1REpsP-00030c-5p for websec@ietf.org; Fri, 14 Oct 2011 16:05:13 -0600 Message-ID: <4E98B219.2050609@KingsMountain.com> Date: Fri, 14 Oct 2011 15:05:13 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 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] separate pinning header (was: Pinning and beyond...) 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, 14 Oct 2011 22:05:14 -0000 from : > 6.5. Pinning Without Requiring HTTPS > > Some host operators would like to take advantage of certificate > pinning without requiring HTTPS, but having clients require pins in > the event that they do connect to the host with HTTPS. As specified > above, the current HSTS-based mechanism does not allow for this: > clients that receive the pins directive via HSTS will also therefore > require HTTPS -- that is the purpose of HSTS after all. To have an > additional directive, e.g. mode=optional, would not work because > older clients that support HSTS but not the mode extension would > effectively require HTTPS. > > Alternatives include (a) putting the pins directive in a new header > instead of extending HSTS; and (b) some kind of hack like setting > maxAge=0 and having an additional directive to keep the pins alive > (e.g. pinMaxAge). These alternatives seem ugly to us and we welcome > suggestions for a better way to support this deployment scenario. In this thread.. Re: [websec] Pinning and beyond Was: Next rev of HSTS certificate pinning draft (Tobias Gondrom) https://www.ietf.org/mail-archive/web/websec/current/msg00593.html ..several folks make the argument for option (a) putting the pins directive in a new header instead of extending HSTS, which I'm tending to agree with. It seems to be the cleanest approach overall. If we had a header that looks like.. PINS: max-age=n; pin=...; pin=...; ... ..and assuming we're not using the pin-break-verifier-and-code mechanism (as discussed in another thread ("breaking pins")), then a UA could manage pins using these steps: If UA connects (over TLS and without TLS errors/warnings) to previously-unpinned TLS host, and receives correct PIN header with max-age > 0, then UA notes host as Known Pinned Host. If UA validly connects to Known Pinned Host (over TLS) and any info in returned PIN header differs from noted info, and header's max-age > 0, it notes the newer info. This means that if a formerly asserted pin fingerprint no longer appears, the UA removes that unmentioned pin fingerprint from the Known Pinned Host's metadata. If a new one appears, it adds it. If UA validly connects to Known Pinned Host (over TLS) and the received PIN header's max-age = 0, it unnotes (i.e. forgets) the host as a Pinned Host. Thoughts? =JeffH From tom@ritter.vg Fri Oct 14 17:57:12 2011 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 A721521F8BBE for ; Fri, 14 Oct 2011 17:57:12 -0700 (PDT) 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 RkLCE5I4W4Wl for ; Fri, 14 Oct 2011 17:57:11 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id C85C721F8B9B for ; Fri, 14 Oct 2011 17:57:11 -0700 (PDT) Received: by iabn5 with SMTP id n5so3314671iab.31 for ; Fri, 14 Oct 2011 17:57:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=Rex2Y0WtbVxeuOh/2YJ6yO9ot5lg8+XGXMun3q+NFKs=; b=Q5Fh7cGkVT0Iqi90G0KZ/I29ucrNVdKZ7tAR42oBPfaMUH2XoWQhRui7wXg57iK/I2 C6Nztu7u0y68IqugPhqEpCWsUEfcOQXOq2HUdMTtCAv/Dn2wbSnt2ARINumXWvmBBuPq 7tUOTvChvZY8sJlrrKsMBN0pj065Azk077ZfI= Received: by 10.68.29.199 with SMTP id m7mr20032535pbh.112.1318640231098; Fri, 14 Oct 2011 17:57:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.245.1 with HTTP; Fri, 14 Oct 2011 17:56:51 -0700 (PDT) In-Reply-To: <4E98B219.2050609@KingsMountain.com> References: <4E98B219.2050609@KingsMountain.com> From: Tom Ritter Date: Fri, 14 Oct 2011 20:56:51 -0400 Message-ID: To: IETF WebSec WG Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [websec] separate pinning header (was: Pinning and beyond...) 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, 15 Oct 2011 00:57:12 -0000 On 14 October 2011 18:05, =JeffH wrote: > from : > > Thoughts? I agree. Separating it into a header may also enable it to find its way into other protocols that travel over TLS, and reuse some of the same parsing/validation code. -tom From tom@ritter.vg Fri Oct 14 18:04:40 2011 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 96EAF21F8CFA for ; Fri, 14 Oct 2011 18:04:40 -0700 (PDT) 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 II8vynNsXedj for ; Fri, 14 Oct 2011 18:04:39 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id C0DE621F8CE9 for ; Fri, 14 Oct 2011 18:04:39 -0700 (PDT) Received: by iabn5 with SMTP id n5so3321066iab.31 for ; Fri, 14 Oct 2011 18:04:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=EJVwnEzRcgXWz8UVphxzmAxth6xmEpID961dKSfrMf4=; b=gaUq+ii2ISP4wtSG2VzJLfYVnOtjyvQIpLbWBiopSFKUc/WokiettLtOiTnMZYWRXh uudrW3ZPz2yXPwK7KdI/dJga9ZOja+vf4wDh/BkPGzIcxOum8zwVG1XRgiYUCqIDG6cc ES9H/21LWMEu/HW4hxLDVxiIcwrLYn4h8YRN8= Received: by 10.68.29.199 with SMTP id m7mr20069601pbh.112.1318640679079; Fri, 14 Oct 2011 18:04:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.245.1 with HTTP; Fri, 14 Oct 2011 18:04:19 -0700 (PDT) In-Reply-To: <4E98B208.7080201@KingsMountain.com> References: <4E98B208.7080201@KingsMountain.com> From: Tom Ritter Date: Fri, 14 Oct 2011 21:04:19 -0400 Message-ID: To: IETF WebSec WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [websec] Review of draft-evans-palmer-hsts-pinning-00 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, 15 Oct 2011 01:04:40 -0000 I'm excited about this draft. > > Note that to validate pins, UAs must necessarily read the headers of > > a response. > [5] response =3D HTTP response? > This implies that the pin check machinery is up at the HTTP layer rather = than down lower in or near the TLS layer, which implies that the UA can mak= e normal HTTP requests to a bogus Known Pinned Host, and send cookies, befo= re realizing that the pin check has failed. > This is a fundamental security issue. I don't think this is worded correctly. If a site is a Known Pinned Host, the pin check should occur after recieving the certificate chain, but before the TLS session is wholly established. If this check does not pass, the connection is aborted.[1] If a pin check occured at the HTTP layer and does occur after a TLS session has been established, data was sent by the client, and the response received - I see only two things that could happen that would be 'new' to the User Agent. 1) 'Oh, this site supports pinning. I didn't know that. I'll note it down as a Known Pinned Host. Let me check the pins just to be sane.' This check wouldn't actually provide any security (that's what preloading is for) - if the pins didn't match, either the server is messed up or the attacker was incompetant because they could have changed the pins. 2) 'I just recieved an unpin directive for the certificate I just used to connect.' This is again a case of the server being messed up. [2] So I think the existing wording is wrong, and better wording would be something like: Upon receipt of this header field, the UA will note the HSTS Host as a Known Pinned HSTS Host if it was previously not. When connecting to a Known Pinned HSTS Host, the UA will compare the public key fingerprint(s) in the Host's certificate chain to the pinned fingerprints, and will fail closed before sending a HTTP request unless at least one public key in the chain has a fingerprint matching one of the pinned fingerprints. (Following the HSTS specification, TLS errors for HSTS hosts must be hard, with no chance for the user to click through any warnings or errors. We treat fingerprint mismatch in the same way.) Where I added - "..will note the HSTS Host as a Known Pinned HSTS Host IF IT WAS PREVIOUSLY NOT." - "...will fail closed BEFORE SENDING A HTTP REQUEST unless at least...". [1] From an engineering perspective, perhaps the connection IS established because that occurs in a modular library that does not know of pinning, but the HTTP request would not be sent, because the connection would be examined outside the library. [2] Do we handle the case where Alice connects to a Known Pinned Site, recieves a valid certificate, but the certificate is unpinned in the Pinning Header? I think this is an error case, because while the initial connection is valid, any subsequent connections in the TLS session were 'fruit of the poison tree' - made using an unpinned certificate. I also think behavior should be noted explictly. I have an additional comment: this header field could grow quite large. Site operators may wish to omit it in the response in several scenarios that indicate to them the client has recieved it already. I don't see a reason this would cause any issue, I'm just noting it. -tom From masinter@adobe.com Sat Oct 15 16:52:54 2011 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 3F0151F0C3C for ; Sat, 15 Oct 2011 16:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 NwtIXY2ns9s6 for ; Sat, 15 Oct 2011 16:52:53 -0700 (PDT) Received: from exprod6og113.obsmtp.com (exprod6og113.obsmtp.com [64.18.1.31]) by ietfa.amsl.com (Postfix) with ESMTP id 48AA31F0C35 for ; Sat, 15 Oct 2011 16:52:52 -0700 (PDT) Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob113.postini.com ([64.18.5.12]) with SMTP; Sat, 15 Oct 2011 16:52:53 PDT 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 p9FNolYE027167; Sat, 15 Oct 2011 16:50:48 -0700 (PDT) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id p9FNqL5R022568; Sat, 15 Oct 2011 16:52:21 -0700 (PDT) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas02.corp.adobe.com ([10.8.189.100]) with mapi; Sat, 15 Oct 2011 16:52:21 -0700 From: Larry Masinter To: Tobias Gondrom , "hallam@gmail.com" Date: Sat, 15 Oct 2011 16:52:18 -0700 Thread-Topic: Using IETF Tracker for issues on MIME sniffing? Thread-Index: AcyLlXX1A/JiAJk9RXiKwOYfGY7f6g== 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "websec@ietf.org" Subject: [websec] Using IETF Tracker for issues on MIME 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: Sat, 15 Oct 2011 23:52:54 -0000 Could we start using the IETF tracker to keep track of our conversation on = the issues on MIME sniffing? The interaction with a "nosniff" header should be one issue. The other three big issues that come to mind are * "scope" (do what situations does this apply) * "opt-in case-by-case" (whether one either sniffs ALWAYS or sniffs NEVER,= or whether it's more nuanced and based on expectation) * "normative algorithm vs. invariants for specifications". I'm willing to write up these issues and the sniffing ones from http://tool= s.ietf.org/html/draft-masinter-mime-web-info , and I hope we can capture Pe= te Resnick's issues as well as Alexey's. Larry -----Original Message----- From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On Behalf Of= Tobias Gondrom Sent: Sunday, October 02, 2011 2:44 PM To: hallam@gmail.com Cc: websec@ietf.org Subject: Re: [websec] I-D Action:draft-ietf-websec-mime-sniff-03.txt Importance: Low Whether browser will implement it, can't tell. Maybe we can learn more when= we progress further with the mime-sniff draft. I don't have a strong opinion on the nosniff header. Depending on where the mime-sniff debate will lead us, it might be a way to= mitigate concerns that in certain cases you really SHOULD NOT or MUST NOT = (RFC2119) sniff. Well and with such a header you could enforce exactly that= for your sources, without breaking other unknown things/sites - which is t= he main reason for many browser vendors to start do sniffing in the first p= lace. (in one way nosniff could even be a migration path to less sniffing....) Best regards, Tobias On 01/10/11 15:30, Phillip Hallam-Baker wrote: > On Sat, Oct 1, 2011 at 2:47 AM, Adam Barth wrote: >> On Fri, Sep 30, 2011 at 10:14 PM, "Martin J. D=FCrst" >> wrote: >>> On 2011/09/29 11:45, Adam Barth wrote: >>>> On Wed, Sep 28, 2011 at 5:44 PM, "Martin J. D=FCrst" >>>> wrote: >>>>> On 2011/09/29 8:26, Adam Barth wrote: >>>>>> As I recall, the nosniff directive is pretty controversial. >>>>> But then, as I recall, the whole business of sniffing is pretty=20 >>>>> controversial to start with. Are there differences between the=20 >>>>> controversiality of sniffing as such and the controversiality of=20 >>>>> the nosniff directive that explain why one is in the draft and the=20 >>>>> other is not? >>>> The reason why one is in and the other isn't is just historical. >>>> nosniff didn't exist at the time the document was originally written. >>> Your first answer sounded as if the nosniff directive was too=20 >>> controversial to be included in any draft, but your second answer=20 >>> seems to suggest that it was left out by (historical) accident, and=20 >>> that it might be worth to include it. >> The essential question isn't whether we should include it in the=20 >> draft. The essential question is whether folks want to implement it. >> If no one wants to implement it, putting it in the draft is a=20 >> negative. If folks want to implement, then we can deal with the=20 >> controversy. > +1 > > The controversy seems to be of the 'cut off nose to spite face' > variety. Sniffing is definitely terrible from a security perspective=20 > but people do it. Java and Java Script were terrible as well but=20 > people did them and then left the rest of us with a mess that had to=20 > be fixed slowly over then next ten years. > > Sure this is not something we should have to think about but the fact=20 > is that the browsers do it and it is better for the standards to=20 > describe what the browsers actually do than what people think they=20 > should do. > > _______________________________________________ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec From ietf@adambarth.com Sat Oct 15 16:55:32 2011 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 17C8111E8081 for ; Sat, 15 Oct 2011 16:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.522 X-Spam-Level: X-Spam-Status: No, score=-0.522 tagged_above=-999 required=5 tests=[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 O1alYfYtEhu2 for ; Sat, 15 Oct 2011 16:55:31 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 622E911E8080 for ; Sat, 15 Oct 2011 16:55:31 -0700 (PDT) Received: by iabn5 with SMTP id n5so4575506iab.31 for ; Sat, 15 Oct 2011 16:55:31 -0700 (PDT) Received: by 10.42.135.69 with SMTP id o5mr27511690ict.34.1318722930964; Sat, 15 Oct 2011 16:55:30 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id p16sm21700248ibk.6.2011.10.15.16.55.29 (version=SSLv3 cipher=OTHER); Sat, 15 Oct 2011 16:55:29 -0700 (PDT) Received: by iabn5 with SMTP id n5so4575481iab.31 for ; Sat, 15 Oct 2011 16:55:29 -0700 (PDT) Received: by 10.231.5.102 with SMTP id 38mr2324071ibu.98.1318722929219; Sat, 15 Oct 2011 16:55:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.205.144 with HTTP; Sat, 15 Oct 2011 16:54:59 -0700 (PDT) In-Reply-To: References: From: Adam Barth Date: Sat, 15 Oct 2011 16:54:59 -0700 Message-ID: To: Larry Masinter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "websec@ietf.org" Subject: Re: [websec] Using IETF Tracker for issues on MIME 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: Sat, 15 Oct 2011 23:55:32 -0000 Yeah, I think using the issue tracker would be very helpful for making progress. Ideally we'd break these issues down into small, manageable topics. For example, rather than having a single issue about scope, we'll probably be better off with separate issues about whether particular things are or are not in scope. Adam On Sat, Oct 15, 2011 at 4:52 PM, Larry Masinter wrote: > Could we start using the IETF tracker to keep track of our conversation o= n the issues on MIME sniffing? > > The interaction with a "nosniff" header should be one issue. > The other three big issues that come to mind are > > * =A0"scope" (do what situations does this apply) > =A0* "opt-in case-by-case" (whether one either sniffs ALWAYS or sniffs NE= VER, or whether it's more nuanced and based on expectation) > * "normative algorithm vs. invariants for specifications". > > > I'm willing to write up these issues and the sniffing ones from http://to= ols.ietf.org/html/draft-masinter-mime-web-info , and I hope we can capture = Pete Resnick's issues as well as Alexey's. > > Larry > > > -----Original Message----- > From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On Behalf = Of Tobias Gondrom > Sent: Sunday, October 02, 2011 2:44 PM > To: hallam@gmail.com > Cc: websec@ietf.org > Subject: Re: [websec] I-D Action:draft-ietf-websec-mime-sniff-03.txt > Importance: Low > > > Whether browser will implement it, can't tell. Maybe we can learn more wh= en we progress further with the mime-sniff draft. > > I don't have a strong opinion on the nosniff header. > Depending on where the mime-sniff debate will lead us, it might be a way = to mitigate concerns that in certain cases you really SHOULD NOT or MUST NO= T (RFC2119) sniff. Well and with such a header you could enforce exactly th= at for your sources, without breaking other unknown things/sites - which is= the main reason for many browser vendors to start do sniffing in the first= place. > (in one way nosniff could even be a migration path to less sniffing....) > > Best regards, Tobias > > > > On 01/10/11 15:30, Phillip Hallam-Baker wrote: >> On Sat, Oct 1, 2011 at 2:47 AM, Adam Barth =A0wrote: >>> On Fri, Sep 30, 2011 at 10:14 PM, "Martin J. D=FCrst" >>> =A0wrote: >>>> On 2011/09/29 11:45, Adam Barth wrote: >>>>> On Wed, Sep 28, 2011 at 5:44 PM, "Martin J. D=FCrst" >>>>> =A0 =A0wrote: >>>>>> On 2011/09/29 8:26, Adam Barth wrote: >>>>>>> As I recall, the nosniff directive is pretty controversial. >>>>>> But then, as I recall, the whole business of sniffing is pretty >>>>>> controversial to start with. Are there differences between the >>>>>> controversiality of sniffing as such and the controversiality of >>>>>> the nosniff directive that explain why one is in the draft and the >>>>>> other is not? >>>>> The reason why one is in and the other isn't is just historical. >>>>> nosniff didn't exist at the time the document was originally written. >>>> Your first answer sounded as if the nosniff directive was too >>>> controversial to be included in any draft, but your second answer >>>> seems to suggest that it was left out by (historical) accident, and >>>> that it might be worth to include it. >>> The essential question isn't whether we should include it in the >>> draft. =A0The essential question is whether folks want to implement it. >>> If no one wants to implement it, putting it in the draft is a >>> negative. =A0If folks want to implement, then we can deal with the >>> controversy. >> +1 >> >> The controversy seems to be of the 'cut off nose to spite face' >> variety. Sniffing is definitely terrible from a security perspective >> but people do it. Java and Java Script were terrible as well but >> people did them and then left the rest of us with a mess that had to >> be fixed slowly over then next ten years. >> >> Sure this is not something we should have to think about but the fact >> is that the browsers do it and it is better for the standards to >> describe what the browsers actually do than what people think they >> should do. >> >> > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > From hallam@gmail.com Sat Oct 15 18:22:33 2011 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 BBCEA21F85B1 for ; Sat, 15 Oct 2011 18:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 X62pd34H+5Qs for ; Sat, 15 Oct 2011 18:22:33 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id E877721F84CB for ; Sat, 15 Oct 2011 18:22:32 -0700 (PDT) Received: by gyh20 with SMTP id 20so2554023gyh.31 for ; Sat, 15 Oct 2011 18:22:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=493cuZYjtDPHQiC10vBOH5OHdaw9xeH4K363e+Wjbmk=; b=vKPysnLccgdCySF2+G/in0zDlDasO/2W8h595+w91ZvL9rNLKGm41RnTHxBCS2U6No RCGPEluDuipBzPt7LJmELFmqJqUDBdYpZz9/EagBSPtkoS2CAGgxTqre0hLe5V+S5yLn W577zw3go0iQS+445BPoAOx5NWLNqzmDTIGV8= MIME-Version: 1.0 Received: by 10.101.22.6 with SMTP id z6mr2920851ani.140.1318728151765; Sat, 15 Oct 2011 18:22:31 -0700 (PDT) Received: by 10.100.212.14 with HTTP; Sat, 15 Oct 2011 18:22:31 -0700 (PDT) In-Reply-To: References: <4E98B219.2050609@KingsMountain.com> Date: Sat, 15 Oct 2011 21:22:31 -0400 Message-ID: From: Phillip Hallam-Baker To: Tom Ritter Content-Type: multipart/alternative; boundary=00504502957f0a92b104af6053e4 Cc: IETF WebSec WG Subject: Re: [websec] separate pinning header (was: Pinning and beyond...) 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, 16 Oct 2011 01:22:33 -0000 --00504502957f0a92b104af6053e4 Content-Type: text/plain; charset=ISO-8859-1 A big use case that we want to support for our apps is to be able to push out security policy for domains that we know are being targeted. We can't push out security policy for every site on the Web into clients but we can easily cover the top 95% of targeted sites with a pretty short list of policy statements. And a huge sub case here would be to pull up security policy for an employer's site for a company machine. This is done today with real utility but its all proprietary. But that really should be agile across multiple protocols. So for example, HTTP, IMAP, POP3 On Fri, Oct 14, 2011 at 8:56 PM, Tom Ritter wrote: > On 14 October 2011 18:05, =JeffH wrote: > > from : > > > > Thoughts? > > I agree. Separating it into a header may also enable it to find its > way into other protocols that travel over TLS, and reuse some of the > same parsing/validation code. > > -tom > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > -- Website: http://hallambaker.com/ --00504502957f0a92b104af6053e4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable A big use case that we want to support for our apps is to be able to push o= ut security policy for domains that we know are being targeted.

We = can't push out security policy for every site on the Web into clients b= ut we can easily cover the top 95% of targeted sites with a pretty short li= st of policy statements.

And a huge sub case here would be to pull up security p= olicy for an employer's site for a company machine. This is done today = with real utility but its all proprietary.

But tha= t really should be agile across multiple protocols. So for example, HTTP, I= MAP, POP3


On Fri, Oct 14, 2011 at 8:56 PM, To= m Ritter <tom@ritter.= vg> wrote:
On 14 October 2011 18:05, =3DJeffH <Jeff.Hodges@kingsmountain.com> wrote:
> from <https://tools.ietf.org/html/draft-evans-pal= mer-hsts-pinning-00> :
>
> Thoughts?

I agree. =A0Separating it into a header may also enable it to find its
way into other protocols that travel over TLS, and reuse some of the
same parsing/validation code.

-tom
__________________________________= _____________
websec mailing list
websec@ietf.org
= https://www.ietf.org/mailman/listinfo/websec



--
= Website: http://hallambaker.com/
--00504502957f0a92b104af6053e4-- From trevp@trevp.net Sun Oct 16 20:09:23 2011 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 A0B7C21F84A1 for ; Sun, 16 Oct 2011 20:09:23 -0700 (PDT) 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 FrVaXtWOt6AH for ; Sun, 16 Oct 2011 20:09:23 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id B8EE121F849B for ; Sun, 16 Oct 2011 20:09:22 -0700 (PDT) Received: by eyg24 with SMTP id 24so2668804eyg.31 for ; Sun, 16 Oct 2011 20:09:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.13.3 with SMTP id a3mr1034848eea.23.1318820961747; Sun, 16 Oct 2011 20:09:21 -0700 (PDT) Received: by 10.14.127.134 with HTTP; Sun, 16 Oct 2011 20:09:21 -0700 (PDT) X-Originating-IP: [74.0.37.252] In-Reply-To: <4E98B215.6040700@KingsMountain.com> References: <4E98B215.6040700@KingsMountain.com> Date: Sun, 16 Oct 2011 20:09:21 -0700 Message-ID: From: Trevor Perrin To: "=JeffH" Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF WebSec WG Subject: Re: [websec] wrt "breaking pins" aka "un-pinning" (breakv, breakc directives; draft-evans-palmer-hsts-pinning-00) 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, 17 Oct 2011 03:09:23 -0000 Hi Jeff, In defense of pin-break codes! - On Fri, Oct 14, 2011 at 3:05 PM, =JeffH wrote: > So if a purported Known Pinned Host presents a cert chain in the TLS > handshake lacking any keys on the UA's pinned key list, then it could be a > bogus host (eg attacker), and if the UA does a HTTP GET and sends cookies > (as well as receives a response and examines headers (e.g. the UA could be > redirected further afield)) in any case, then this is a (non-trivial) > vulnerability. A better alternative might be to deliver pin-break codes as part of the TLS handshake (e.g. a TLS Extension). Then: * Pin-break codes would work regardless of how the pin-break verifiers are set, so pin-break codes could be used with pins set via HSTS header, browser hardcodes, Convergence, DNS, etc. * Pin-break codes would work with non-HTTP protocols like SMTP or POP. * Pin-break codes would be retrieved without an HTTP Request, removing the risk noted above. What do you think? > In examining the various such situations (aka "disasters") outlined in Sec > 3, it appears that essentially all of them are mitigated if the host > operators allocated a backup server key/cert as advised, and have properly > issued a pin to it, along with their pin to their present operational > key/cert. In this situation, it appears that having the > pin-break-verifier-and-code mechanism isn't strictly necessary. Both backup pins and pin-break codes let a site switch from its current cert chain to a different one, so they have similar "disaster mitigation" properties, and a site could choose one or the other. Pin-break codes might be preferred by site operators nervous about boxing themselves in with pinning, since pin-break codes let the site change its cert chain arbitrarily without being limited by backup pins or waiting for expiration. Trevor From tobias.gondrom@gondrom.org Mon Oct 17 00:03:47 2011 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 8790F21F8B26 for ; Mon, 17 Oct 2011 00:03:47 -0700 (PDT) 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 7vt2KuEvxAbw for ; Mon, 17 Oct 2011 00:03:47 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id 8A30021F8B27 for ; Mon, 17 Oct 2011 00:03:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=aPXu2lLa8a7K9kFQAbM4etOhMBi97wQja0AJBoeiPk095kem9fbATIOG/9sLfi68g00GlXLGyuIhezSyQpxTLRY3x3/0ySvH9fW6O/LoLJVzhjDs7BZvYAbI4gbJwgAZ; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; Received: (qmail 22526 invoked from network); 17 Oct 2011 09:02:59 +0200 Received: from unknown (HELO ?172.65.196.2?) (218.188.76.249) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 17 Oct 2011 09:02:58 +0200 Message-ID: <4E9BD31E.8060500@gondrom.org> Date: Mon, 17 Oct 2011 08:02:54 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110923 Thunderbird/7.0 MIME-Version: 1.0 To: websec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [websec] websec meeting in Taipei 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, 17 Oct 2011 07:03:47 -0000 Hello dear websec fellows, the websec meeting in Taipei has been scheduled for Wednesday Nov-16, Afternoon Session I 1300-1500 in Room Name: 201 ABC. Very much looking forward to seeing you all there! We have a lot of upcoming topics and I hope we can make great progress on a number of them: HSTS (Jeff), hsts pinning (Chris), mime sniffing (Adam, Larry), Digest URI Scheme (Stephen), ... As we are currently preparing the agenda for the websec meeting, please submit proposals for presentations and discussions to Alexey, Yoav and myself as soon as possible as we will have to prepare and close the agenda for websec soon. For all editors and authors: please keep in mind that the final submission cut-off for new versions for Internet Drafts is 2011-10-31 (Monday) by 17:00 PT (00:00 UTC). This cut-off is also important to allow enough time for all participants to read your drafts and be able to discuss them during the meeting. Kind regards, Tobias From stpeter@stpeter.im Mon Oct 17 12:36:56 2011 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 EA91021F85D1 for ; Mon, 17 Oct 2011 12:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.172 X-Spam-Level: X-Spam-Status: No, score=-102.172 tagged_above=-999 required=5 tests=[AWL=-2.027, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 FGqvxHqnyhRw for ; Mon, 17 Oct 2011 12:36:56 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3245921F85AA for ; Mon, 17 Oct 2011 12:36:56 -0700 (PDT) Received: from dhcp-64-101-72-193.cisco.com (unknown [64.101.72.193]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id F0DBB41E49; Mon, 17 Oct 2011 13:41:45 -0600 (MDT) Message-ID: <4E9C83D6.6050400@stpeter.im> Date: Mon, 17 Oct 2011 13:36:54 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Adam Barth References: In-Reply-To: X-Enigmail-Version: 1.3.2 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "websec@ietf.org" Subject: Re: [websec] Using IETF Tracker for issues on MIME 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, 17 Oct 2011 19:36:57 -0000 +1 to using the tracker so we can narrow the scope of disagreement and achieve closure. On 10/15/11 5:54 PM, Adam Barth wrote: > Yeah, I think using the issue tracker would be very helpful for making > progress. Ideally we'd break these issues down into small, manageable > topics. For example, rather than having a single issue about scope, > we'll probably be better off with separate issues about whether > particular things are or are not in scope. > > Adam > > > On Sat, Oct 15, 2011 at 4:52 PM, Larry Masinter wrote: >> Could we start using the IETF tracker to keep track of our conversation on the issues on MIME sniffing? >> >> The interaction with a "nosniff" header should be one issue. >> The other three big issues that come to mind are >> >> * "scope" (do what situations does this apply) >> * "opt-in case-by-case" (whether one either sniffs ALWAYS or sniffs NEVER, or whether it's more nuanced and based on expectation) >> * "normative algorithm vs. invariants for specifications". >> >> >> I'm willing to write up these issues and the sniffing ones from http://tools.ietf.org/html/draft-masinter-mime-web-info , and I hope we can capture Pete Resnick's issues as well as Alexey's. >> >> Larry >> >> >> -----Original Message----- >> From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On Behalf Of Tobias Gondrom >> Sent: Sunday, October 02, 2011 2:44 PM >> To: hallam@gmail.com >> Cc: websec@ietf.org >> Subject: Re: [websec] I-D Action:draft-ietf-websec-mime-sniff-03.txt >> Importance: Low >> >> >> Whether browser will implement it, can't tell. Maybe we can learn more when we progress further with the mime-sniff draft. >> >> I don't have a strong opinion on the nosniff header. >> Depending on where the mime-sniff debate will lead us, it might be a way to mitigate concerns that in certain cases you really SHOULD NOT or MUST NOT (RFC2119) sniff. Well and with such a header you could enforce exactly that for your sources, without breaking other unknown things/sites - which is the main reason for many browser vendors to start do sniffing in the first place. >> (in one way nosniff could even be a migration path to less sniffing....) >> >> Best regards, Tobias >> >> >> >> On 01/10/11 15:30, Phillip Hallam-Baker wrote: >>> On Sat, Oct 1, 2011 at 2:47 AM, Adam Barth wrote: >>>> On Fri, Sep 30, 2011 at 10:14 PM, "Martin J. Dürst" >>>> wrote: >>>>> On 2011/09/29 11:45, Adam Barth wrote: >>>>>> On Wed, Sep 28, 2011 at 5:44 PM, "Martin J. Dürst" >>>>>> wrote: >>>>>>> On 2011/09/29 8:26, Adam Barth wrote: >>>>>>>> As I recall, the nosniff directive is pretty controversial. >>>>>>> But then, as I recall, the whole business of sniffing is pretty >>>>>>> controversial to start with. Are there differences between the >>>>>>> controversiality of sniffing as such and the controversiality of >>>>>>> the nosniff directive that explain why one is in the draft and the >>>>>>> other is not? >>>>>> The reason why one is in and the other isn't is just historical. >>>>>> nosniff didn't exist at the time the document was originally written. >>>>> Your first answer sounded as if the nosniff directive was too >>>>> controversial to be included in any draft, but your second answer >>>>> seems to suggest that it was left out by (historical) accident, and >>>>> that it might be worth to include it. >>>> The essential question isn't whether we should include it in the >>>> draft. The essential question is whether folks want to implement it. >>>> If no one wants to implement it, putting it in the draft is a >>>> negative. If folks want to implement, then we can deal with the >>>> controversy. >>> +1 >>> >>> The controversy seems to be of the 'cut off nose to spite face' >>> variety. Sniffing is definitely terrible from a security perspective >>> but people do it. Java and Java Script were terrible as well but >>> people did them and then left the rest of us with a mess that had to >>> be fixed slowly over then next ten years. >>> >>> Sure this is not something we should have to think about but the fact >>> is that the browsers do it and it is better for the standards to >>> describe what the browsers actually do than what people think they >>> should do. >>> >>> From palmer@google.com Mon Oct 17 13:31:59 2011 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 0EFAC11E8088 for ; Mon, 17 Oct 2011 13:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 gPQtYcFUjLXG for ; Mon, 17 Oct 2011 13:31:57 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8D92D11E807F for ; Mon, 17 Oct 2011 13:31:57 -0700 (PDT) Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id p9HKVokk027583 for ; Mon, 17 Oct 2011 13:31:50 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1318883510; bh=vvHcd8y0GeIE4ZabCAvo+btR/34=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=OZG48EQZ8VxhI2sCXWGniPT+QhMTMGR2/0aau/4zTjkUxh8ubbDsF3f+51+U2fJ3X 5Q1cYuGjhh8t+il0FF71g== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=w2oG7ssAxMHbybndkICoT4nACK9Hp/7HDjv6n3s6PBriTw1er6SCRGgrproBxtJeT 2znjFu0oD0UIF6bmnFhGA== Received: from eye13 (eye13.prod.google.com [10.208.5.13]) by wpaz13.hot.corp.google.com with ESMTP id p9HKVfr5031497 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 17 Oct 2011 13:31:49 -0700 Received: by eye13 with SMTP id 13so1719344eye.1 for ; Mon, 17 Oct 2011 13:31:49 -0700 (PDT) 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:content-type:x-system-of-record; bh=bAYnZMjBmhWy3r2BIObWOJ1RYBwctcEDwwtDm3jANkw=; b=WA1C6/NDzupHNgOJKJ/JBQnMlOi1MKZMDToxcbDg1FKxoqjIZLG/TTl7pA7Itw/R36 JFkI+wraytNkZc34v3LQ== Received: by 10.216.135.31 with SMTP id t31mr280600wei.4.1318883509423; Mon, 17 Oct 2011 13:31:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.135.31 with SMTP id t31mr280591wei.4.1318883509245; Mon, 17 Oct 2011 13:31:49 -0700 (PDT) Received: by 10.216.216.205 with HTTP; Mon, 17 Oct 2011 13:31:49 -0700 (PDT) In-Reply-To: <4E98B215.6040700@KingsMountain.com> References: <4E98B215.6040700@KingsMountain.com> Date: Mon, 17 Oct 2011 13:31:49 -0700 Message-ID: From: Chris Palmer To: "=JeffH" Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: Chris Evans , IETF WebSec WG Subject: Re: [websec] wrt "breaking pins" aka "un-pinning" (breakv, breakc directives; draft-evans-palmer-hsts-pinning-00) 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, 17 Oct 2011 20:31:59 -0000 On Fri, Oct 14, 2011 at 3:05 PM, =JeffH wrote: > In order for this "un-pinning" pin-break-verifier-and-code mechanism to > generally work, the UA still connects and and makes an HTTP request and > reads response headers. Note that the TLS layer could still abort the connection if the connection doesn't pass the pinning test (i.e. if the connection was made with a server certificate that does not contain any previously pinned public keys). Thus, in order to successfully use a breakc, you would still have to serve it with a cert containing a public key you had pinned. (Including, perhaps, your backup pin.) However: > In examining the various such situations (aka "disasters") outlined in Sec > 3, it appears that essentially all of them are mitigated if the host > operators allocated a backup server key/cert as advised, and have properly > issued a pin to it, along with their pin to their present operational > key/cert. In this situation, it appears that having the > pin-break-verifier-and-code mechanism isn't strictly necessary. Chris E. and I now agree with this, and are probably going to remove breakc and breakv from the draft specification. Even if they stay, they probably won't appear in the first rev of the Chrome implementation. The thinking is now, "Get the simplest thing implemented, see how people like it, and implement breakc/v if there is demand." This would probably/almost certainly imply that pins expire when the server stops mentioning them in the pins directive (or when max-age expires, whichever is soonest). From trac+websec@trac.tools.ietf.org Mon Oct 17 14:26:57 2011 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 6947411E8095 for ; Mon, 17 Oct 2011 14:26:57 -0700 (PDT) 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 3OFkGmLt-PaI for ; Mon, 17 Oct 2011 14:26:56 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id DEADB11E808C for ; Mon, 17 Oct 2011 14:26:56 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1RFuhs-00067p-1i; Mon, 17 Oct 2011 17:26:48 -0400 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-mime-sniff@tools.ietf.org, masinter@adobe.com X-Trac-Project: websec Date: Mon, 17 Oct 2011 21:26:48 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/websec/trac/ticket/15 Message-ID: <059.82a0a252b10204d3f8231125c842792c@trac.tools.ietf.org> X-Trac-Ticket-ID: 15 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-websec-mime-sniff@tools.ietf.org, masinter@adobe.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: <20111017212656.DEADB11E808C@ietfa.amsl.com> Resent-Date: Mon, 17 Oct 2011 14:26:56 -0700 (PDT) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: [websec] #15: Clarify scope of web sniffing 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: Mon, 17 Oct 2011 21:26:57 -0000 #15: Clarify scope of web sniffing This issue may be broken down into several (is X in scope?) but this issue is meant to cover the overall question to start with. The introduction to the document cites the existence of mis-configured web content served via HTTP as the primary justification for "sniffing". However, the document itself covers many situations beyond misconfigured web content. * web sites where content-type values are syntactically correct but believed to be different from what was intended (because the content itself doesn't match) * situations where HTTP protocol content-type is syntactically incorrect, duplicate, malformed. * situations where no content-type is supplied at all via HTTP. * situations where the content is not being delivered via HTTP at all, but via other protocols. There are a number of these situations, including web accesible material delivered via ftp:, file: (on thumb drives?). The internet-draft is currently normatively required by a W3C recommendation on zip packaging, for example. So the basic question is: what is the scope? The "bug" in the specification is that the introduction and justification don't match the apparent intent of the scope of the body. -- ------------------------------+-------------------------------------------- Reporter: masinter@… | Owner: draft-ietf-websec-mime-sniff@… Type: defect | Status: new Priority: major | Milestone: Component: mime-sniff | Version: Severity: Active WG | Keywords: Document | ------------------------------+-------------------------------------------- Ticket URL: websec From trac+websec@trac.tools.ietf.org Mon Oct 17 14:27:38 2011 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 300E811E8098 for ; Mon, 17 Oct 2011 14:27:38 -0700 (PDT) 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 8wNOe4ZhLSkP for ; Mon, 17 Oct 2011 14:27:37 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 027DA1F0C41 for ; Mon, 17 Oct 2011 14:27:35 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1RFuia-0001FT-L7; Mon, 17 Oct 2011 17:27:32 -0400 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-mime-sniff@tools.ietf.org, masinter@adobe.com X-Trac-Project: websec Date: Mon, 17 Oct 2011 21:27:32 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/websec/trac/ticket/15#comment:1 Message-ID: <074.4200d5264acac630953b10e7223f3d29@trac.tools.ietf.org> References: <059.82a0a252b10204d3f8231125c842792c@trac.tools.ietf.org> X-Trac-Ticket-ID: 15 In-Reply-To: <059.82a0a252b10204d3f8231125c842792c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-websec-mime-sniff@tools.ietf.org, masinter@adobe.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: <20111017212735.027DA1F0C41@ietfa.amsl.com> Resent-Date: Mon, 17 Oct 2011 14:27:35 -0700 (PDT) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: Re: [websec] #15: Clarify scope of MIME sniffing (was: Clarify scope of web sniffing) 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: Mon, 17 Oct 2011 21:27:38 -0000 #15: Clarify scope of MIME sniffing -- -----------------------------+--------------------------------------------- Reporter: masinter@… | Owner: draft-ietf-websec-mime-sniff@… Type: defect | Status: new Priority: major | Milestone: Component: mime-sniff | Version: Severity: Active WG | Resolution: Document | Keywords: | -----------------------------+--------------------------------------------- Ticket URL: websec From palmer@google.com Mon Oct 17 14:36:14 2011 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 47C4D1F0C41 for ; Mon, 17 Oct 2011 14:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 gx3riF4jQtpi for ; Mon, 17 Oct 2011 14:36:13 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id A4F221F0C35 for ; Mon, 17 Oct 2011 14:36:13 -0700 (PDT) Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id p9HLaCO6009826 for ; Mon, 17 Oct 2011 14:36:13 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1318887373; bh=naZyjJqdw74AOSs0E0sxvpfsIgQ=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=ePWLDdTFaNOgCI93UfVogD0Kbqs0Vo+VgS8FyNNhVaTjBbkKleR/ngUd1ktg7msPq q00k6Wzy/BJSBC85WEf2A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=gp/XrbHq++IjStz6FvlkEaeh7n7sgZwTi9r7jRRmtqP4LvMwOKBImy8n6NJpjfoDa cG+A23zZNXGLidMR8dzuA== Received: from wwi18 (wwi18.prod.google.com [10.241.243.18]) by hpaq7.eem.corp.google.com with ESMTP id p9HLZCrx001636 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 17 Oct 2011 14:36:11 -0700 Received: by wwi18 with SMTP id 18so1749142wwi.11 for ; Mon, 17 Oct 2011 14:36:11 -0700 (PDT) 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:content-type:content-transfer-encoding:x-system-of-record; bh=Y5e4rbgMN7TV7JytYNYBqnHge+xxDGGogpgCOt/MbmU=; b=ictwA1nEsW7vd3mZVVN6MxCkJstSO9ROajbljntMypHSKVKW/gBYOILplRHiVUk/OD rSyY3JGZdvHUWktm4y6Q== Received: by 10.216.230.98 with SMTP id i76mr68136weq.19.1318887371362; Mon, 17 Oct 2011 14:36:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.230.98 with SMTP id i76mr68133weq.19.1318887371195; Mon, 17 Oct 2011 14:36:11 -0700 (PDT) Received: by 10.216.216.205 with HTTP; Mon, 17 Oct 2011 14:36:11 -0700 (PDT) In-Reply-To: References: <4E98B219.2050609@KingsMountain.com> Date: Mon, 17 Oct 2011 14:36:11 -0700 Message-ID: From: Chris Palmer To: Tom Ritter Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: Chris Evans , IETF WebSec WG Subject: Re: [websec] separate pinning header (was: Pinning and beyond...) 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, 17 Oct 2011 21:36:14 -0000 On Fri, Oct 14, 2011 at 5:56 PM, Tom Ritter wrote: > I agree. =C2=A0Separating it into a header may also enable it to find its > way into other protocols that travel over TLS, and reuse some of the > same parsing/validation code. Actually, there is nothing too HTTP-specific about HSTS as it exists now, so you could conceivably use it in other header-having protocols. I am ok with putting pins in their own header. I'll be rolling another rev of the document and will send it around! Thanks again, all. From Jeff.Hodges@KingsMountain.com Mon Oct 17 15:09:20 2011 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 3722811E8082 for ; Mon, 17 Oct 2011 15:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.947 X-Spam-Level: X-Spam-Status: No, score=-99.947 tagged_above=-999 required=5 tests=[AWL=0.548, 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 lYenhLym+3qI for ; Mon, 17 Oct 2011 15:09:19 -0700 (PDT) Received: from oproxy5-pub.bluehost.com (oproxy5.bluehost.com [IPv6:2605:dc00:100:2::a5]) by ietfa.amsl.com (Postfix) with SMTP id 9259B11E8073 for ; Mon, 17 Oct 2011 15:09:19 -0700 (PDT) Received: (qmail 23047 invoked by uid 0); 17 Oct 2011 22:09:17 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy2.bluehost.com with SMTP; 17 Oct 2011 22:09:17 -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:CC:To:MIME-Version:From:Date:Message-ID; bh=fP6k0SLfv5EejQ5j3ZnWs69fqDuDtpv6qkNKaORZL6w=; b=5YjYmm78uCPFYphIFpCqWU5NkUbPS6OSVruwg262jW/E5YWQk8Q1G9Za8JP+koR76JsVSdMPDbVNC3d1B6EfoNdB7uhZuaQ0XIu0i1SxFRqcIkFrKK/PTHmQml/a1eX2; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.137.201]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1RFvMy-0005AD-Qg; Mon, 17 Oct 2011 16:09:16 -0600 Message-ID: <4E9CA78C.5050805@KingsMountain.com> Date: Mon, 17 Oct 2011 15:09:16 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Trevor Perrin , Chris Palmer 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} Cc: IETF WebSec WG Subject: Re: [websec] wrt "breaking pins" aka "un-pinning" (breakv, breakc directives; draft-evans-palmer-hsts-pinning-00) 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, 17 Oct 2011 22:09:20 -0000 Hi Trevor & ChrisP, Trevor Perrin noted: > > In defense of pin-break codes! - > > On Fri, Oct 14, 2011 at 3:05 PM, =JeffH wrote: >> So if a purported Known Pinned Host presents a cert chain in the TLS >> handshake lacking any keys on the UA's pinned key list, then it could be a >> bogus host (eg attacker), and if the UA does a HTTP GET and sends cookies >> (as well as receives a response and examines headers (e.g. the UA could be >> redirected further afield)) in any case, then this is a (non-trivial) >> vulnerability. > > A better alternative might be to deliver pin-break codes as part of > the TLS handshake (e.g. a TLS Extension). Then: > * Pin-break codes would work regardless of how the pin-break > verifiers are set, so pin-break codes could be used with pins set via > HSTS header, browser hardcodes, Convergence, DNS, etc. > * Pin-break codes would work with non-HTTP protocols like SMTP or POP. > * Pin-break codes would be retrieved without an HTTP Request, > removing the risk noted above. > > What do you think? In general, I think we should think about conveying pinning/unpinning in the TLS channel in some fashion (which I'd noted at the very end of my original msg). And yes, the added benefit of working for other protocols layered on top of TLS, rather than just working for HTTP, would seem to be a win (for the longer term). Tho, getting TLS extensions actually implemented and deployed seems to take a few forevers. I wonder about hacking it (conveyance of pinning/unpinning info), for the nearer-term, into a cert extension. Then just modifying client apps (e.g. browsers) is what's necessary. > Pin-break codes might be preferred by site operators nervous about > boxing themselves in with pinning, since pin-break codes let the site > change its cert chain arbitrarily without being limited by backup pins > or waiting for expiration. Agreed, can see/understand that use case. Chris Palmer followed up.. > > Note that the TLS layer could still abort the connection if the > connection doesn't pass the pinning test (i.e. if the connection was > made with a server certificate that does not contain any previously > pinned public keys). agreed. > Thus, in order to successfully use a breakc, you would still have to > serve it with a cert containing a public key you had pinned. > (Including, perhaps, your backup pin.) yes, which has me wondering, as I hope I articulated somewhat clearly, about the overall utility of the pin-break-verifier-and-code mechanism, except in the particular case where a application server operator wishes to deploy only one key/cert and pin to that, cross their fingers, and then fall back on this pin breaking mechanism if needed. >> In examining the various such situations (aka "disasters") outlined in Sec >> 3, it appears that essentially all of them are mitigated if the host >> operators allocated a backup server key/cert as advised, and have properly >> issued a pin to it, along with their pin to their present operational >> key/cert. In this situation, it appears that having the >> pin-break-verifier-and-code mechanism isn't strictly necessary. > > Chris E. and I now agree with this, and are probably going to remove > breakc and breakv from the draft specification. Even if they stay, > they probably won't appear in the first rev of the Chrome > implementation. The thinking is now, "Get the simplest thing > implemented, see how people like it, and implement breakc/v if there > is demand." sounds fine to me. > This would probably/almost certainly imply that pins expire when the > server stops mentioning them in the pins directive (or when max-age > expires, whichever is soonest). Agreed. =JeffH From palmer@google.com Mon Oct 17 15:21:20 2011 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 EBF6511E8082 for ; Mon, 17 Oct 2011 15:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 TXyEvYO8Md4D for ; Mon, 17 Oct 2011 15:21:16 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id BF7DA1F0C42 for ; Mon, 17 Oct 2011 15:21:12 -0700 (PDT) Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id p9HMLAWq004843 for ; Mon, 17 Oct 2011 15:21:10 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1318890071; bh=Qr3CQlLdLNIXKCazxXYGza4vBxc=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=CfV9sjdnVB7GvtQWEzScD1emCe9sUhDDIt01nd2sbo87zhNV3gC0gmKoxsg2T6UyL rg9tnHzjMgjncW6XTfkOQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=hzR7d4AExwQK0sXd/Fp1+9/dDJmEdqYeTxXQsJnITO0blfvXUtEsVbSaPxx3iUvvi LFh00Em3IwTHnIA4diZLw== Received: from wwn22 (wwn22.prod.google.com [10.241.244.86]) by hpaq14.eem.corp.google.com with ESMTP id p9HMIKbg010806 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 17 Oct 2011 15:21:10 -0700 Received: by wwn22 with SMTP id 22so1695146wwn.5 for ; Mon, 17 Oct 2011 15:21:09 -0700 (PDT) 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:content-type:x-system-of-record; bh=5DuTpWMUDA5Wg8rRh2Yb26BBlBBKSl/KKJsZUv6Z9w0=; b=EP/wdCFrAYIwiA3O4VkzEvCJ+iyWit0PiRYRrnqC4QFcD/bsCEK8b/dCQ82Tf+uNyj zf2bNBt5cLLBkdHYm1kQ== Received: by 10.216.135.31 with SMTP id t31mr404617wei.4.1318890069792; Mon, 17 Oct 2011 15:21:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.135.31 with SMTP id t31mr404606wei.4.1318890069620; Mon, 17 Oct 2011 15:21:09 -0700 (PDT) Received: by 10.216.216.205 with HTTP; Mon, 17 Oct 2011 15:21:09 -0700 (PDT) In-Reply-To: <4E9CA78C.5050805@KingsMountain.com> References: <4E9CA78C.5050805@KingsMountain.com> Date: Mon, 17 Oct 2011 15:21:09 -0700 Message-ID: From: Chris Palmer To: "=JeffH" Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: Chris Evans , IETF WebSec WG Subject: Re: [websec] wrt "breaking pins" aka "un-pinning" (breakv, breakc directives; draft-evans-palmer-hsts-pinning-00) 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, 17 Oct 2011 22:21:20 -0000 On Mon, Oct 17, 2011 at 3:09 PM, =JeffH wrote: > Tho, getting TLS extensions actually implemented and deployed seems to take > a few forevers. Quite so. > I wonder about hacking it (conveyance of pinning/unpinning info), for the > nearer-term, into a cert extension. Then just modifying client apps (e.g. > browsers) is what's necessary. Your average sys admin is more comfortable telling Apache to send a particular header with particular text than wrangling openssl(1) to add various extensions to a certificate. I don't see a security problem with using the application layer (e.g. HTTP) to inform the transport layer (TLS), as long as the transport layer correctly uses the information to exercise policy on subsequent connections. That's easier said than done in UA implementation code, of course, but I'm willing to (try to) write that code. I'm not willing to make sys admins wrangle with X.509 and the openssl command line. (For example, can anyone here tell me the command line to add a custom certificate extension to an existing certificate?) It would be cleaner to have it all in the TLS layer, but ease-of-deployment concerns dominate. People have a hard enough time with X.509 as it is. From marsh@extendedsubset.com Mon Oct 17 15:53:56 2011 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 12D9C1F0C49 for ; Mon, 17 Oct 2011 15:53:56 -0700 (PDT) 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 QbnGDUGJUBiY for ; Mon, 17 Oct 2011 15:53:55 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id BB7161F0C43 for ; Mon, 17 Oct 2011 15:53:54 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1RFw4A-000PUa-9C; Mon, 17 Oct 2011 22:53:54 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id D20B263BF; Mon, 17 Oct 2011 22:53:52 +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: U2FsdGVkX19KXsQre9rTjZD8lKd1+Vg2hMB7PlLE/l8= Message-ID: <4E9CB1FF.5050407@extendedsubset.com> Date: Mon, 17 Oct 2011 17:53:51 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Chris Palmer References: <4E9CA78C.5050805@KingsMountain.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Chris Evans , IETF WebSec WG Subject: Re: [websec] wrt "breaking pins" aka "un-pinning" (breakv, breakc directives; draft-evans-palmer-hsts-pinning-00) 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, 17 Oct 2011 22:53:56 -0000 On 10/17/2011 05:21 PM, Chris Palmer wrote: > > Your average sys admin is more comfortable telling Apache to send a > particular header with particular text than wrangling openssl(1) to > add various extensions to a certificate. My understanding is that most people just generate their certs directly using their CA's web interface and download the result. On one hand this would suggest that admins will be ill-prepared to set custom x509 extensions. On the other, we may find that CAs are quite receptive to new features which support pinning customers to themselves. - Marsh From hallam@gmail.com Mon Oct 17 20:26:25 2011 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 138CD1F0C5A for ; Mon, 17 Oct 2011 20:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.666, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] 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 obFFuRoboV0o for ; Mon, 17 Oct 2011 20:26:24 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1F021F8515 for ; Mon, 17 Oct 2011 20:26:24 -0700 (PDT) Received: by gyh20 with SMTP id 20so189581gyh.31 for ; Mon, 17 Oct 2011 20:26:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IBPTIn/L/N6YH4rXvXZdodrsTMqcIe1Y0TotM8h42qk=; b=fFOM9qXS7gOQOgQKoxJfGuFDuSSklJYcg4+UXG0+z+UA0+zUUaTHnxaiVLnqGfbFJQ LaBCktRj/WNJy6QUmCBi9ddO4BQ1F1o0w3s4DGgLr/wHJNtoU/VAjKVQo3CmkQBSoGtj au5uJbBsNEbwBjwIR1HPGdZqkXItZylOAzhM0= MIME-Version: 1.0 Received: by 10.100.18.21 with SMTP id 21mr77519anr.118.1318908382040; Mon, 17 Oct 2011 20:26:22 -0700 (PDT) Received: by 10.100.212.14 with HTTP; Mon, 17 Oct 2011 20:26:21 -0700 (PDT) In-Reply-To: <4E9CB1FF.5050407@extendedsubset.com> References: <4E9CA78C.5050805@KingsMountain.com> <4E9CB1FF.5050407@extendedsubset.com> Date: Mon, 17 Oct 2011 23:26:21 -0400 Message-ID: From: Phillip Hallam-Baker To: Marsh Ray Content-Type: multipart/alternative; boundary=0016e64764729a542b04af8a4992 Cc: Chris Evans , IETF WebSec WG Subject: Re: [websec] wrt "breaking pins" aka "un-pinning" (breakv, breakc directives; draft-evans-palmer-hsts-pinning-00) 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, 18 Oct 2011 03:26:25 -0000 --0016e64764729a542b04af8a4992 Content-Type: text/plain; charset=ISO-8859-1 I think that the complexity of pinning and the consequences of getting it wrong are going to mean that this is something that should only be done by the very competent and knowledgable or those who hand over administration of their systems to such. This may be in the form of outsourced provision or code that does the right thing and makes it hard to do the wrong thing. I don't think the capabilities/ease of use of currently existing free DIY cert signer kits should be the criteria to measure against. If this is going to work people need to be using tools designed for the purpose of managing the whole thing end to end. Even if that is only a Perl front end on those fee tools, there is going to need to be something that walks the sysadmin through. Rather than look at the extent of the changes required, I prefer to look at the number of components in the system that need to be touched. I would rather make two separate modifications to the CA than one to the CA and another to the Web server. In general, every piece of the system that has to be touched costs when it comes to deployment. We are going to have to touch the CA/cert server system to make pinning work. (Even if only because the CAs are the people who explain to the typical admin how to make all of this work). So far we do not need to make changes to the Web server beyond adding static headers which is something most Web servers already support. Changing the TLS component of the Web server opens a box labelled 'code' and gets us into some really long product cycle delays. Like on IIS for example. On Mon, Oct 17, 2011 at 6:53 PM, Marsh Ray wrote: > On 10/17/2011 05:21 PM, Chris Palmer wrote: > >> >> Your average sys admin is more comfortable telling Apache to send a >> particular header with particular text than wrangling openssl(1) to >> add various extensions to a certificate. >> > > My understanding is that most people just generate their certs directly > using their CA's web interface and download the result. > > On one hand this would suggest that admins will be ill-prepared to set > custom x509 extensions. On the other, we may find that CAs are quite > receptive to new features which support pinning customers to > themselves. > > - Marsh > > ______________________________**_________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/**listinfo/websec > -- Website: http://hallambaker.com/ --0016e64764729a542b04af8a4992 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think that the complexity of pinning and the consequences of getting it w= rong are going to mean that this is something that should only be done by t= he very competent and knowledgable or those who hand over administration of= their systems to such. This may be in the form of outsourced provision or = code that does the right thing and makes it hard to do the wrong thing.
I don't think the capabilities/ease of use of currently = existing free DIY cert signer kits should be the criteria to measure agains= t. If this is going to work people need to be using tools designed for the = purpose of managing the whole thing end to end. Even if that is only a Perl= front end on those fee tools, there is going to need to be something that = walks the sysadmin through.


Rather than look at the extent of the ch= anges required, I prefer to look at the number of components in the system = that need to be touched. I would rather make two separate modifications to = the CA than one to the CA and another to the Web server. In general, every = piece of the system that has to be touched costs when it comes to deploymen= t.

We are going to have to touch the CA/cert server system= to make pinning work. (Even if only because the CAs are the people who exp= lain to the typical admin how to make all of this work). So far we do not n= eed to make changes to the Web server beyond adding static headers which is= something most Web servers already support.

Changing the TLS component of the Web server opens a box labelled = 'code' and gets us into some really long product cycle delays. Like= on IIS for example.=A0



On Mon, Oct 17, 2011 at 6:53 PM, Marsh Ray <marsh@extendedsubset.com> w= rote:
On 10/17/2011 05:21 PM, Chris Palmer wrote:

Your average sys admin is more comfortable telling Apache to send a
particular header with particular text than wrangling openssl(1) to
add various extensions to a certificate.

My understanding is that most people just generate their certs directly
using their CA's web interface and download the result.

On one hand this would suggest that admins will be ill-prepared to set
custom x509 extensions. On the other, we may find that CAs are quite recept= ive to new features which support pinning customers to
themselves.

- Marsh

_______________________________________________
websec mailing list
websec@ietf.org = https://www.ietf.org/mailman/listinfo/websec



--
= Website: http://hallambaker.com/
--0016e64764729a542b04af8a4992-- From tobias.gondrom@gondrom.org Tue Oct 18 03:00:15 2011 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 153AD21F8C86 for ; Tue, 18 Oct 2011 03:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.323 X-Spam-Level: X-Spam-Status: No, score=-94.323 tagged_above=-999 required=5 tests=[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 HDkun9aQKvVS for ; Tue, 18 Oct 2011 03:00:14 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id CED4E21F8C81 for ; Tue, 18 Oct 2011 03:00:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=o9F31JAfuPAuBOaUmigePl9iC/wHaLHRn+i4bynSpZ8sKLOpUX5UCZKkGlRXTNV9fxTfSaw9HEfvo0drZHB/I6cOUTBMXeQ2PjrDn0ohGtZFoTtLXe9cZyDXiyUAkL8c; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 9621 invoked from network); 18 Oct 2011 11:59:13 +0200 Received: from d1-231-46-143-118-on-nets.com (HELO ?118.143.46.231?) (118.143.46.231) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 18 Oct 2011 11:59:12 +0200 Message-ID: <4E9D4DEC.30800@gondrom.org> Date: Tue, 18 Oct 2011 10:59:08 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110923 Thunderbird/7.0 MIME-Version: 1.0 To: websec@ietf.org References: <4E9C83D6.6050400@stpeter.im> In-Reply-To: <4E9C83D6.6050400@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [websec] Using IETF Tracker for issues on MIME 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: Tue, 18 Oct 2011 10:00:15 -0000 Thank you Adam and Larry. Excellent. Yes, please we shall continue the discussion on mime-sniffing and the chairs strongly encourage to use the tracker for this draft, as it will enable us to focus the discussion and get better progress. Thank you and very much looking forward to discussing and getting ahead with this draft Tobias (websec chair) On 17/10/11 20:36, Peter Saint-Andre wrote: > +1 to using the tracker so we can narrow the scope of disagreement and > achieve closure. > > On 10/15/11 5:54 PM, Adam Barth wrote: >> Yeah, I think using the issue tracker would be very helpful for making >> progress. Ideally we'd break these issues down into small, manageable >> topics. For example, rather than having a single issue about scope, >> we'll probably be better off with separate issues about whether >> particular things are or are not in scope. >> >> Adam >> >> >> On Sat, Oct 15, 2011 at 4:52 PM, Larry Masinter wrote: >>> Could we start using the IETF tracker to keep track of our conversation on the issues on MIME sniffing? >>> >>> The interaction with a "nosniff" header should be one issue. >>> The other three big issues that come to mind are >>> >>> * "scope" (do what situations does this apply) >>> * "opt-in case-by-case" (whether one either sniffs ALWAYS or sniffs NEVER, or whether it's more nuanced and based on expectation) >>> * "normative algorithm vs. invariants for specifications". >>> >>> >>> I'm willing to write up these issues and the sniffing ones from http://tools.ietf.org/html/draft-masinter-mime-web-info , and I hope we can capture Pete Resnick's issues as well as Alexey's. >>> >>> Larry >>> >>> >>> -----Original Message----- >>> From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On Behalf Of Tobias Gondrom >>> Sent: Sunday, October 02, 2011 2:44 PM >>> To: hallam@gmail.com >>> Cc: websec@ietf.org >>> Subject: Re: [websec] I-D Action:draft-ietf-websec-mime-sniff-03.txt >>> Importance: Low >>> >>> >>> Whether browser will implement it, can't tell. Maybe we can learn more when we progress further with the mime-sniff draft. >>> >>> I don't have a strong opinion on the nosniff header. >>> Depending on where the mime-sniff debate will lead us, it might be a way to mitigate concerns that in certain cases you really SHOULD NOT or MUST NOT (RFC2119) sniff. Well and with such a header you could enforce exactly that for your sources, without breaking other unknown things/sites - which is the main reason for many browser vendors to start do sniffing in the first place. >>> (in one way nosniff could even be a migration path to less sniffing....) >>> >>> Best regards, Tobias >>> >>> >>> >>> On 01/10/11 15:30, Phillip Hallam-Baker wrote: >>>> On Sat, Oct 1, 2011 at 2:47 AM, Adam Barth wrote: >>>>> On Fri, Sep 30, 2011 at 10:14 PM, "Martin J. Dürst" >>>>> wrote: >>>>>> On 2011/09/29 11:45, Adam Barth wrote: >>>>>>> On Wed, Sep 28, 2011 at 5:44 PM, "Martin J. Dürst" >>>>>>> wrote: >>>>>>>> On 2011/09/29 8:26, Adam Barth wrote: >>>>>>>>> As I recall, the nosniff directive is pretty controversial. >>>>>>>> But then, as I recall, the whole business of sniffing is pretty >>>>>>>> controversial to start with. Are there differences between the >>>>>>>> controversiality of sniffing as such and the controversiality of >>>>>>>> the nosniff directive that explain why one is in the draft and the >>>>>>>> other is not? >>>>>>> The reason why one is in and the other isn't is just historical. >>>>>>> nosniff didn't exist at the time the document was originally written. >>>>>> Your first answer sounded as if the nosniff directive was too >>>>>> controversial to be included in any draft, but your second answer >>>>>> seems to suggest that it was left out by (historical) accident, and >>>>>> that it might be worth to include it. >>>>> The essential question isn't whether we should include it in the >>>>> draft. The essential question is whether folks want to implement it. >>>>> If no one wants to implement it, putting it in the draft is a >>>>> negative. If folks want to implement, then we can deal with the >>>>> controversy. >>>> +1 >>>> >>>> The controversy seems to be of the 'cut off nose to spite face' >>>> variety. Sniffing is definitely terrible from a security perspective >>>> but people do it. Java and Java Script were terrible as well but >>>> people did them and then left the rest of us with a mess that had to >>>> be fixed slowly over then next ten years. >>>> >>>> Sure this is not something we should have to think about but the fact >>>> is that the browsers do it and it is better for the standards to >>>> describe what the browsers actually do than what people think they >>>> should do. >>>> >>>> > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From tobias.gondrom@gondrom.org Wed Oct 19 02:45:51 2011 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 9766121F8770 for ; Wed, 19 Oct 2011 02:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.551 X-Spam-Level: X-Spam-Status: No, score=-95.551 tagged_above=-999 required=5 tests=[AWL=1.227, 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 vso9aWKi-yvB for ; Wed, 19 Oct 2011 02:45:51 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id 97F0921F8569 for ; Wed, 19 Oct 2011 02:45:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=uFMGuA4kfekMaXc7yxfndpftjS+sZH1xYhQNDjF8UreHEb4VIjzV55P3GXKK8CAZU7jUtXEXeh6tJpv5hYfBY/p72aJdzeJ3+V4OG+eNziD1ZKRXRjVSGV2ujpdzifDY; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 25632 invoked from network); 19 Oct 2011 11:39:08 +0200 Received: from d1-231-46-143-118-on-nets.com (HELO ?118.143.46.231?) (118.143.46.231) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 19 Oct 2011 11:39:07 +0200 Message-ID: <4E9E9AB8.6060506@gondrom.org> Date: Wed, 19 Oct 2011 10:39:04 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110923 Thunderbird/7.0 MIME-Version: 1.0 To: websec@ietf.org References: <059.82a0a252b10204d3f8231125c842792c@trac.tools.ietf.org> In-Reply-To: <059.82a0a252b10204d3f8231125c842792c@trac.tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [websec] #15: Clarify scope of web 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: Wed, 19 Oct 2011 09:45:51 -0000 personally I like the scope beyond "http-only". #1 The mis-configured header website part is in my view the main use case. But scenarios where no content-type can be transmitted in the header, like other protocols (e.g. ftp), filesystem, etc. seem to make sense too. So in general I would support a broader scope. Just my 5cents, Tobias On 17/10/11 22:26, websec issue tracker wrote: > #15: Clarify scope of web sniffing > > This issue may be broken down into several (is X in scope?) but this issue > is meant to cover the overall question to start with. > > The introduction to the document cites the existence of mis-configured web > content served via HTTP as the primary justification for "sniffing". > > However, the document itself covers many situations beyond misconfigured > web content. > > * web sites where content-type values are syntactically correct but > believed to be different from what was intended (because the content > itself doesn't match) > > * situations where HTTP protocol content-type is syntactically incorrect, > duplicate, malformed. > > * situations where no content-type is supplied at all via HTTP. > > * situations where the content is not being delivered via HTTP at all, but > via other protocols. > > There are a number of these situations, including web accesible material > delivered via ftp:, file: (on thumb drives?). The internet-draft is > currently normatively required by a W3C recommendation on zip packaging, > for example. > > So the basic question is: what is the scope? The "bug" in the > specification is that the introduction and justification don't match the > apparent intent of the scope of the body. > From trac+websec@trac.tools.ietf.org Wed Oct 19 02:56:22 2011 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 40D5321F89BA for ; Wed, 19 Oct 2011 02:56:22 -0700 (PDT) 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 m9sVJZDB6iei for ; Wed, 19 Oct 2011 02:56:21 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id B842121F86A0 for ; Wed, 19 Oct 2011 02:56:21 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1RGSsh-00045f-8s; Wed, 19 Oct 2011 05:56:15 -0400 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-mime-sniff@tools.ietf.org, tobias.gondrom@gondrom.org X-Trac-Project: websec Date: Wed, 19 Oct 2011 09:56:15 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/websec/trac/ticket/16 Message-ID: <067.0c626f20ba70069d5bffe870f0af308a@trac.tools.ietf.org> X-Trac-Ticket-ID: 16 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-websec-mime-sniff@tools.ietf.org, tobias.gondrom@gondrom.org, 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: <20111019095621.B842121F86A0@ietfa.amsl.com> Resent-Date: Wed, 19 Oct 2011 02:56:21 -0700 (PDT) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: [websec] #16: lack of explanatory text and no justifications for the normative language 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, 19 Oct 2011 09:56:22 -0000 #16: lack of explanatory text and no justifications for the normative language Filing this issue on behalf, as submitted by Pete Resnik: (no objection to progressing *a* MIME sniffing draft in the IETF as an RFC.) "He does have an objection to progressing this MIME sniffing draft in its current form. It has an algorithm with no explanatory text and no justifications for any of the normative language it gives. That's not a protocol. Surely the author and other folks who think this work is important know *why* the algorithm is written the way it is. All that I am asking is for that knowledge be written in the document to explain. Then, if someone is in an environment that is different from the one anticipated by the draft, be it more restrictive or less, they can figure out what the right thing to do is and the draft can be updated appropriately. The current form simply doesn't allow that." [Tobias] To discuss or to do: add some more justification and explanation text at RFC2119 statements? -- ------------------------------+-------------------------------------------- Reporter: tobias.gondrom@… | Owner: draft-ietf-websec-mime-sniff@… Type: defect | Status: new Priority: major | Milestone: Component: mime-sniff | Version: Severity: Active WG | Keywords: Document | ------------------------------+-------------------------------------------- Ticket URL: websec From palmer@google.com Fri Oct 21 16:26:15 2011 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 615CC21F8B10 for ; Fri, 21 Oct 2011 16:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 KctA2i5vIXnQ for ; Fri, 21 Oct 2011 16:26:14 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id A1CA021F8B0E for ; Fri, 21 Oct 2011 16:26:14 -0700 (PDT) Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id p9LNQ1Kx010606 for ; Fri, 21 Oct 2011 16:26:01 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1319239561; bh=Pve9XmC5zVyZtmUPeGF1/Vmjpbo=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=ClEZulwNWmedu58DKQdv+GFwL+7rzk0B52Dt6jyp+5skQ2GpuF6YxyT3HsrzL0yQr NxyLgkYCfK93JCSfZ2c6A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=eeW+AuSvL79ZImYzgNmsetabdyXfJXXyYJQkyfdhSMel3Z97kJwk3Eo84XhqkwZb6 5+KTv4+Rx07bkJivwcdqA== Received: from wyg36 (wyg36.prod.google.com [10.241.226.164]) by wpaz1.hot.corp.google.com with ESMTP id p9LNOlKx022329 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 21 Oct 2011 16:26:00 -0700 Received: by wyg36 with SMTP id 36so2402289wyg.1 for ; Fri, 21 Oct 2011 16:25:55 -0700 (PDT) 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:content-type:x-system-of-record; bh=cqh4ZdBRXq1RRt1CfzYZ6P5YlHIdGVPXg+dWxDkeQEw=; b=MsjQbpgvPFNKCYccy3Y8A6kP26PGuQipN3jJTJGkYljeygFRbrxzMiYh90mOOvh7rR eZ9x/PigikMrJz4W5/Zw== Received: by 10.216.135.31 with SMTP id t31mr537954wei.4.1319239555708; Fri, 21 Oct 2011 16:25:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.135.31 with SMTP id t31mr537946wei.4.1319239555575; Fri, 21 Oct 2011 16:25:55 -0700 (PDT) Received: by 10.216.216.205 with HTTP; Fri, 21 Oct 2011 16:25:55 -0700 (PDT) In-Reply-To: References: <4E98B208.7080201@KingsMountain.com> Date: Fri, 21 Oct 2011 16:25:55 -0700 Message-ID: From: Chris Palmer To: Tom Ritter , Chris Evans Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: IETF WebSec WG Subject: Re: [websec] Review of draft-evans-palmer-hsts-pinning-00 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, 21 Oct 2011 23:26:15 -0000 Sorry I've been so slow getting back to you all on this. I've started revising the doc and will submit a fresh -01 version next week. Thanks for all your feedback! From trac+websec@trac.tools.ietf.org Sat Oct 22 11:45:52 2011 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 DB6AD21F847F for ; Sat, 22 Oct 2011 11:45:52 -0700 (PDT) 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 lXAsBbcuMGeI for ; Sat, 22 Oct 2011 11:45:51 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id A046C21F847C for ; Sat, 22 Oct 2011 11:45:51 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1RHgZi-0000Oq-9q; Sat, 22 Oct 2011 14:45:42 -0400 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-mime-sniff@tools.ietf.org, ietf@adambarth.com, masinter@adobe.com X-Trac-Project: websec Date: Sat, 22 Oct 2011 18:45:42 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/15#comment:2 Message-ID: <074.ccb8fbdb22e8bd24daf60625fab30156@trac.tools.ietf.org> References: <059.82a0a252b10204d3f8231125c842792c@trac.tools.ietf.org> X-Trac-Ticket-ID: 15 In-Reply-To: <059.82a0a252b10204d3f8231125c842792c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-websec-mime-sniff@tools.ietf.org, ietf@adambarth.com, masinter@adobe.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: <20111022184551.A046C21F847C@ietfa.amsl.com> Resent-Date: Sat, 22 Oct 2011 11:45:51 -0700 (PDT) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: Re: [websec] #15: Clarify scope of MIME sniffing 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: Sat, 22 Oct 2011 18:45:53 -0000 #15: Clarify scope of MIME sniffing Comment (by ietf@…): > However, the document itself covers many situations beyond misconfigured web content. In my view, bullets 1 through 3 arise from misconfigured web servers. For bullet 1, there's lots of examples of servers supplying a syntactically correct but erroneous MIME type, where I judge the supplied MIME type to be erroneous because obeying the MIME type causes the site to behave in undesirable ways, e.g., having broken images because the site uses a resource as an image but the resource has a Content-Type that says text/plain. For bullet 2, a syntacticly invalid Content-Type header is manifestly caused by a misconfigured server. For bullet 3, a correctly configured web server will always supply the correct MIME type with a response, but that's just a matter of semantics. I'll agree that bullet 4 is a distinct use case and might be valuable to point out in the introduction. -- -----------------------------+--------------------------------------------- Reporter: masinter@… | Owner: draft-ietf-websec-mime-sniff@… Type: defect | Status: new Priority: major | Milestone: Component: mime-sniff | Version: Severity: Active WG | Resolution: Document | Keywords: | -----------------------------+--------------------------------------------- Ticket URL: websec From trac+websec@trac.tools.ietf.org Sat Oct 22 11:47:29 2011 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 E7EBD21F8485 for ; Sat, 22 Oct 2011 11:47:29 -0700 (PDT) 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 qcVzWeTR+D2b for ; Sat, 22 Oct 2011 11:47:29 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 43DDD21F847F for ; Sat, 22 Oct 2011 11:47:29 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1RHgbQ-0001Kr-Fh; Sat, 22 Oct 2011 14:47:28 -0400 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-mime-sniff@tools.ietf.org, ietf@adambarth.com X-Trac-Project: websec Date: Sat, 22 Oct 2011 18:47:28 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/16#comment:1 Message-ID: <082.069f7d2344511f067aa27b9de70dacc6@trac.tools.ietf.org> References: <067.0c626f20ba70069d5bffe870f0af308a@trac.tools.ietf.org> X-Trac-Ticket-ID: 16 In-Reply-To: <067.0c626f20ba70069d5bffe870f0af308a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-websec-mime-sniff@tools.ietf.org, ietf@adambarth.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: <20111022184729.43DDD21F847F@ietfa.amsl.com> Resent-Date: Sat, 22 Oct 2011 11:47:29 -0700 (PDT) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: Re: [websec] #16: lack of explanatory text and no justifications for the normative language 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: Sat, 22 Oct 2011 18:47:30 -0000 #16: lack of explanatory text and no justifications for the normative language Comment (by ietf@…): There's a lot of discussion of the rationale in this document: http://www.adambarth.com/papers/2009/barth-caballero-song.pdf I'm not opposed to importing that information into this document. -- -----------------------------+--------------------------------------------- Reporter: | Owner: draft-ietf-websec-mime-sniff@… tobias.gondrom@… | Status: new Type: defect | Milestone: Priority: major | Version: Component: mime-sniff | Resolution: Severity: Active WG | Document | Keywords: | -----------------------------+--------------------------------------------- Ticket URL: websec From ietf@adambarth.com Sat Oct 22 11:52:20 2011 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 8690121F89B8 for ; Sat, 22 Oct 2011 11:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.522 X-Spam-Level: X-Spam-Status: No, score=-0.522 tagged_above=-999 required=5 tests=[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 nmtDX4VqXtC5 for ; Sat, 22 Oct 2011 11:52:19 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id ACCF021F8677 for ; Sat, 22 Oct 2011 11:52:19 -0700 (PDT) Received: by iabn5 with SMTP id n5so6853886iab.31 for ; Sat, 22 Oct 2011 11:52:19 -0700 (PDT) Received: by 10.43.43.130 with SMTP id uc2mr19481467icb.35.1319309539223; Sat, 22 Oct 2011 11:52:19 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id l28sm44635219ibc.3.2011.10.22.11.52.18 (version=SSLv3 cipher=OTHER); Sat, 22 Oct 2011 11:52:18 -0700 (PDT) Received: by iabn5 with SMTP id n5so6853873iab.31 for ; Sat, 22 Oct 2011 11:52:18 -0700 (PDT) Received: by 10.42.155.201 with SMTP id v9mr31330558icw.38.1319309538097; Sat, 22 Oct 2011 11:52:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.205.144 with HTTP; Sat, 22 Oct 2011 11:51:48 -0700 (PDT) From: Adam Barth Date: Sat, 22 Oct 2011 11:51:48 -0700 Message-ID: To: Larry Masinter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "websec@ietf.org" Subject: [websec] Are all the issues filed? (was: Re: Using IETF Tracker for issues on MIME 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: Sat, 22 Oct 2011 18:52:20 -0000 Larry, Have you filed all the issues you'd like addressed? I went though the issue tracker and I only found two: http://wiki.tools.ietf.org/wg/websec/trac/ticket/15 http://wiki.tools.ietf.org/wg/websec/trac/ticket/16 Below you mention "nosniff", but I don't see that in the issue tracker. Please let me know when you've finished filing the issues you care about. Adam On Sat, Oct 15, 2011 at 4:52 PM, Larry Masinter wrote: > Could we start using the IETF tracker to keep track of our conversation o= n the issues on MIME sniffing? > > The interaction with a "nosniff" header should be one issue. > The other three big issues that come to mind are > > * =A0"scope" (do what situations does this apply) > =A0* "opt-in case-by-case" (whether one either sniffs ALWAYS or sniffs NE= VER, or whether it's more nuanced and based on expectation) > * "normative algorithm vs. invariants for specifications". > > > I'm willing to write up these issues and the sniffing ones from http://to= ols.ietf.org/html/draft-masinter-mime-web-info , and I hope we can capture = Pete Resnick's issues as well as Alexey's. > > Larry > > > -----Original Message----- > From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On Behalf = Of Tobias Gondrom > Sent: Sunday, October 02, 2011 2:44 PM > To: hallam@gmail.com > Cc: websec@ietf.org > Subject: Re: [websec] I-D Action:draft-ietf-websec-mime-sniff-03.txt > Importance: Low > > > Whether browser will implement it, can't tell. Maybe we can learn more wh= en we progress further with the mime-sniff draft. > > I don't have a strong opinion on the nosniff header. > Depending on where the mime-sniff debate will lead us, it might be a way = to mitigate concerns that in certain cases you really SHOULD NOT or MUST NO= T (RFC2119) sniff. Well and with such a header you could enforce exactly th= at for your sources, without breaking other unknown things/sites - which is= the main reason for many browser vendors to start do sniffing in the first= place. > (in one way nosniff could even be a migration path to less sniffing....) > > Best regards, Tobias > > > > On 01/10/11 15:30, Phillip Hallam-Baker wrote: >> On Sat, Oct 1, 2011 at 2:47 AM, Adam Barth =A0wrote: >>> On Fri, Sep 30, 2011 at 10:14 PM, "Martin J. D=FCrst" >>> =A0wrote: >>>> On 2011/09/29 11:45, Adam Barth wrote: >>>>> On Wed, Sep 28, 2011 at 5:44 PM, "Martin J. D=FCrst" >>>>> =A0 =A0wrote: >>>>>> On 2011/09/29 8:26, Adam Barth wrote: >>>>>>> As I recall, the nosniff directive is pretty controversial. >>>>>> But then, as I recall, the whole business of sniffing is pretty >>>>>> controversial to start with. Are there differences between the >>>>>> controversiality of sniffing as such and the controversiality of >>>>>> the nosniff directive that explain why one is in the draft and the >>>>>> other is not? >>>>> The reason why one is in and the other isn't is just historical. >>>>> nosniff didn't exist at the time the document was originally written. >>>> Your first answer sounded as if the nosniff directive was too >>>> controversial to be included in any draft, but your second answer >>>> seems to suggest that it was left out by (historical) accident, and >>>> that it might be worth to include it. >>> The essential question isn't whether we should include it in the >>> draft. =A0The essential question is whether folks want to implement it. >>> If no one wants to implement it, putting it in the draft is a >>> negative. =A0If folks want to implement, then we can deal with the >>> controversy. >> +1 >> >> The controversy seems to be of the 'cut off nose to spite face' >> variety. Sniffing is definitely terrible from a security perspective >> but people do it. Java and Java Script were terrible as well but >> people did them and then left the rest of us with a mess that had to >> be fixed slowly over then next ten years. >> >> Sure this is not something we should have to think about but the fact >> is that the browsers do it and it is better for the standards to >> describe what the browsers actually do than what people think they >> should do. >> >> > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > From trac+websec@trac.tools.ietf.org Sun Oct 23 16:37:51 2011 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 74A8721F8B61 for ; Sun, 23 Oct 2011 16:37:51 -0700 (PDT) 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 HCiAofJwvzRa for ; Sun, 23 Oct 2011 16:37:50 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 705B421F8B5E for ; Sun, 23 Oct 2011 16:37:50 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1RI7bq-0005tY-PZ; Sun, 23 Oct 2011 19:37:42 -0400 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-mime-sniff@tools.ietf.org, masinter@adobe.com X-Trac-Project: websec Date: Sun, 23 Oct 2011 23:37:42 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/17 Message-ID: <059.70846bca9f857812ac02d38043b050ef@trac.tools.ietf.org> X-Trac-Ticket-ID: 17 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-websec-mime-sniff@tools.ietf.org, masinter@adobe.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: <20111023233750.705B421F8B5E@ietfa.amsl.com> Resent-Date: Sun, 23 Oct 2011 16:37:50 -0700 (PDT) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: [websec] #17: Use the "magic numbers" in the media type IANA registry instead of an explicit table 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, 23 Oct 2011 23:37:51 -0000 #17: Use the "magic numbers" in the media type IANA registry instead of an explicit table The Internet Media Type IANA registry contains a field for "Magic Number" which is intended to represent how the type can be sniffed. The tables in this document and the IANA registry should be aligned, although perhaps the IANA registry should be expanded to annotate whether the "Magic Number" information in the IANA registry is suitable for sniffing. Otherwise, how could one ever sniff a new MIME type ? -- ------------------------+-------------------------------------------- Reporter: masinter@… | Owner: draft-ietf-websec-mime-sniff@… Type: defect | Status: new Priority: major | Milestone: Component: mime-sniff | Version: Severity: - | Keywords: ------------------------+-------------------------------------------- Ticket URL: websec From trac+websec@trac.tools.ietf.org Sun Oct 23 16:39:13 2011 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 283E121F8B5D for ; Sun, 23 Oct 2011 16:39:13 -0700 (PDT) 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 FbiO8HTDDEwU for ; Sun, 23 Oct 2011 16:39:12 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id AC3D621F8AD6 for ; Sun, 23 Oct 2011 16:39:12 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1RI7dG-0007cf-IQ; Sun, 23 Oct 2011 19:39:10 -0400 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-mime-sniff@tools.ietf.org, masinter@adobe.com X-Trac-Project: websec Date: Sun, 23 Oct 2011 23:39:10 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/18 Message-ID: <059.7716556ffa2683a89f63e858a6013663@trac.tools.ietf.org> X-Trac-Ticket-ID: 18 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-websec-mime-sniff@tools.ietf.org, masinter@adobe.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: <20111023233912.AC3D621F8AD6@ietfa.amsl.com> Resent-Date: Sun, 23 Oct 2011 16:39:12 -0700 (PDT) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: [websec] #18: Describe use of file extension in sniffing from "file:" and "ftp:" URIs 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, 23 Oct 2011 23:39:13 -0000 #18: Describe use of file extension in sniffing from "file:" and "ftp:" URIs while file extensions should not be used in sniffing data over http:, this isn't the case for ftp and file system access, I don't believe. -- ------------------------+-------------------------------------------- Reporter: masinter@… | Owner: draft-ietf-websec-mime-sniff@… Type: defect | Status: new Priority: major | Milestone: Component: mime-sniff | Version: Severity: - | Keywords: ------------------------+-------------------------------------------- Ticket URL: websec From trac+websec@trac.tools.ietf.org Sun Oct 23 16:43:40 2011 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 ED44F21F8B50 for ; Sun, 23 Oct 2011 16:43:40 -0700 (PDT) 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 F+SJputddOyA for ; Sun, 23 Oct 2011 16:43:39 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id D3A2E21F8B4F for ; Sun, 23 Oct 2011 16:43:39 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1RI7hX-0007lb-WA; Sun, 23 Oct 2011 19:43:36 -0400 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-mime-sniff@tools.ietf.org, masinter@adobe.com X-Trac-Project: websec Date: Sun, 23 Oct 2011 23:43:35 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/websec/trac/ticket/19 Message-ID: <059.38de41cc08d30327b007c754bc555885@trac.tools.ietf.org> X-Trac-Ticket-ID: 19 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-websec-mime-sniff@tools.ietf.org, masinter@adobe.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: <20111023234339.D3A2E21F8B4F@ietfa.amsl.com> Resent-Date: Sun, 23 Oct 2011 16:43:39 -0700 (PDT) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: [websec] #19: Do not sniff PDF 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, 23 Oct 2011 23:43:41 -0000 #19: Do not sniff PDF There should be a strong advice not to sniff PDF -- if the data is mislabeled as something else, then sending it to a PDF interpreter is likely just an error. -- ------------------------+-------------------------------------------- Reporter: masinter@… | Owner: draft-ietf-websec-mime-sniff@… Type: defect | Status: new Priority: minor | Milestone: Component: mime-sniff | Version: Severity: - | Keywords: ------------------------+-------------------------------------------- Ticket URL: websec From trac+websec@trac.tools.ietf.org Sun Oct 23 16:48:16 2011 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 C662921F8B5A for ; Sun, 23 Oct 2011 16:48:16 -0700 (PDT) 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 HaNlzRtP35I0 for ; Sun, 23 Oct 2011 16:48:16 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 5954521F8B2B for ; Sun, 23 Oct 2011 16:48:15 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1RI7ly-0001oc-EW; Sun, 23 Oct 2011 19:48:10 -0400 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-mime-sniff@tools.ietf.org, masinter@adobe.com X-Trac-Project: websec Date: Sun, 23 Oct 2011 23:48:10 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/20 Message-ID: <059.f4c24ea9835018ac54322b267fbda143@trac.tools.ietf.org> X-Trac-Ticket-ID: 20 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-websec-mime-sniff@tools.ietf.org, masinter@adobe.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: <20111023234816.5954521F8B2B@ietfa.amsl.com> Resent-Date: Sun, 23 Oct 2011 16:48:15 -0700 (PDT) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: [websec] #20: Sniffing should be "opt in" on a case-by-case basis 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, 23 Oct 2011 23:48:16 -0000 #20: Sniffing should be "opt in" on a case-by-case basis The way the document is written as a normative algorithm makes it hard to say this, but: Every implementation should be free to "opt out" of sniffing based on other information it has (previous experience with the site, information based on whether a correct MIME type was given vs. misconfigured, etc.) From the point of view of a web site, there's no additional security or danger from opting out on a case-by-case basis; it's the same as, on a case-by-case basis, choosing between two implementations, one of which always sniffs and the other never sniffs. -- ------------------------+-------------------------------------------- Reporter: masinter@… | Owner: draft-ietf-websec-mime-sniff@… Type: defect | Status: new Priority: major | Milestone: Component: mime-sniff | Version: Severity: - | Keywords: ------------------------+-------------------------------------------- Ticket URL: websec From trac+websec@trac.tools.ietf.org Sun Oct 23 16:52:38 2011 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 050B821F8B51 for ; Sun, 23 Oct 2011 16:52:38 -0700 (PDT) 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 VMx7jpzlUohZ for ; Sun, 23 Oct 2011 16:52:37 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 7A91321F8B2B for ; Sun, 23 Oct 2011 16:52:37 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1RI7qF-0005jd-4g; Sun, 23 Oct 2011 19:52:35 -0400 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-mime-sniff@tools.ietf.org, masinter@adobe.com X-Trac-Project: websec Date: Sun, 23 Oct 2011 23:52:35 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/21 Message-ID: <059.3516e8c3cdad2665b7817e8e50a003a8@trac.tools.ietf.org> X-Trac-Ticket-ID: 21 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-websec-mime-sniff@tools.ietf.org, masinter@adobe.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: <20111023235237.7A91321F8B2B@ietfa.amsl.com> Resent-Date: Sun, 23 Oct 2011 16:52:37 -0700 (PDT) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: [websec] #21: sniffing of text/html shouldn't override polyglot label of application/xhtml+xml 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, 23 Oct 2011 23:52:38 -0000 #21: sniffing of text/html shouldn't override polyglot label of application/xhtml+xml (I have to double check that this is true): In general, "sniffing" is dangerous in "polyglot" cases where the same content CAN be served with different media types, where the meaning is the same or related. For example, there are types for packaged formats that use ZIP and thus have the ZIP magic number but aren't served as ZIP, text/plain is sometimes used to deliver examples of otherwise mal-formed XML, etc. It would seem better to discourage sniffing in cases where the content is valid for the type that it's actually labeled, and to treat that as a special case. (One still might want to sniff text/html when the type is labeled text/plain, for example, but not for other polyglot cases.) -- ------------------------+-------------------------------------------- Reporter: masinter@… | Owner: draft-ietf-websec-mime-sniff@… Type: defect | Status: new Priority: major | Milestone: Component: mime-sniff | Version: Severity: - | Keywords: ------------------------+-------------------------------------------- Ticket URL: websec From trac+websec@trac.tools.ietf.org Sun Oct 23 16:55:09 2011 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 CC2D721F8B5E for ; Sun, 23 Oct 2011 16:55:09 -0700 (PDT) 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 ZK8+VhoGqHsL for ; Sun, 23 Oct 2011 16:55:09 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 87EE221F8B59 for ; Sun, 23 Oct 2011 16:55:06 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1RI7sd-0005lT-WB; Sun, 23 Oct 2011 19:55:04 -0400 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-mime-sniff@tools.ietf.org, masinter@adobe.com X-Trac-Project: websec Date: Sun, 23 Oct 2011 23:55:03 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/22 Message-ID: <059.f8bc48a3163d95d888ee3a23a2ca7fb9@trac.tools.ietf.org> X-Trac-Ticket-ID: 22 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-websec-mime-sniff@tools.ietf.org, masinter@adobe.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: <20111023235506.87EE221F8B59@ietfa.amsl.com> Resent-Date: Sun, 23 Oct 2011 16:55:06 -0700 (PDT) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: [websec] #22: content-type sniffing should include charset sniffing 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, 23 Oct 2011 23:55:10 -0000 #22: content-type sniffing should include charset sniffing the HTML5 spec contains some algorithms for sniffing charset, overriding labeled charset, etc. MIME parameters like charset are as much a part of the content-type as the base internet media type, and any sniffing of parameters and other metadata (overriding content-type or guessing where it is not supplied or wrong) should be included in this document, since the sniffing will happen at the same time. -- ------------------------+-------------------------------------------- Reporter: masinter@… | Owner: draft-ietf-websec-mime-sniff@… Type: defect | Status: new Priority: major | Milestone: Component: mime-sniff | Version: Severity: - | Keywords: ------------------------+-------------------------------------------- Ticket URL: websec From trac+websec@trac.tools.ietf.org Sun Oct 23 17:00:52 2011 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 C6C9A21F8B5E for ; Sun, 23 Oct 2011 17:00:52 -0700 (PDT) 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 ZFh4lVDbU+ny for ; Sun, 23 Oct 2011 17:00:52 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 312B221F8B59 for ; Sun, 23 Oct 2011 17:00:51 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1RI7yB-0000xP-55; Sun, 23 Oct 2011 20:00:47 -0400 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-mime-sniff@tools.ietf.org, masinter@adobe.com X-Trac-Project: websec Date: Mon, 24 Oct 2011 00:00:47 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/23 Message-ID: <059.7c4f6b2fc15a219384d7b8146f5332e2@trac.tools.ietf.org> X-Trac-Ticket-ID: 23 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-websec-mime-sniff@tools.ietf.org, masinter@adobe.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: <20111024000052.312B221F8B59@ietfa.amsl.com> Resent-Date: Sun, 23 Oct 2011 17:00:51 -0700 (PDT) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: [websec] #23: spec should mention proposed "nosniff" headers in HTTP even if not adopting them 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: Mon, 24 Oct 2011 00:00:52 -0000 #23: spec should mention proposed "nosniff" headers in HTTP even if not adopting them There have been some implementations which have attempted to add a header for saying "I really mean it" for the content-type. Even if this isn't supported by the standard sniffing algorithm, a reference and even an analysis of why it doesn't work belongs here (lest we repeat the discussion over and over.) -- ------------------------+-------------------------------------------- Reporter: masinter@… | Owner: draft-ietf-websec-mime-sniff@… Type: defect | Status: new Priority: minor | Milestone: Component: mime-sniff | Version: Severity: - | Keywords: ------------------------+-------------------------------------------- Ticket URL: websec From trac+websec@trac.tools.ietf.org Sun Oct 23 17:03:33 2011 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 BDE2C21F8B68 for ; Sun, 23 Oct 2011 17:03:33 -0700 (PDT) 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 sDaVBxrWE6j3 for ; Sun, 23 Oct 2011 17:03:33 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 21A1421F84DB for ; Sun, 23 Oct 2011 17:03:33 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1RI80o-00017O-Ur; Sun, 23 Oct 2011 20:03:30 -0400 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-mime-sniff@tools.ietf.org, masinter@adobe.com X-Trac-Project: websec Date: Mon, 24 Oct 2011 00:03:30 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/24 Message-ID: <059.dcfcab85455034d746cda42b79785446@trac.tools.ietf.org> X-Trac-Ticket-ID: 24 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-websec-mime-sniff@tools.ietf.org, masinter@adobe.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: <20111024000333.21A1421F84DB@ietfa.amsl.com> Resent-Date: Sun, 23 Oct 2011 17:03:33 -0700 (PDT) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: [websec] #24: ensure XML packaging is in scope 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: Mon, 24 Oct 2011 00:03:33 -0000 #24: ensure XML packaging is in scope http://www.w3.org/TR/widgets/ Widget Packaging and XML Configuration makes normative reference to (some version) of this document, as: [SNIFF]Media Type Sniffing. A. Barth and I. Hickson. IETF (Work in Progress). Make sure it is clear that the use case for XML packaging in ZIP files is in scope, and that the use case is justified (since misconfigured HTTP servers don't come into play at all.) -- ------------------------+-------------------------------------------- Reporter: masinter@… | Owner: draft-ietf-websec-mime-sniff@… Type: defect | Status: new Priority: minor | Milestone: Component: mime-sniff | Version: Severity: - | Keywords: ------------------------+-------------------------------------------- Ticket URL: websec From masinter@adobe.com Sun Oct 23 17:05:14 2011 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 C58DE21F8B79 for ; Sun, 23 Oct 2011 17:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.561 X-Spam-Level: X-Spam-Status: No, score=-106.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 iX1b6oZ7dhg5 for ; Sun, 23 Oct 2011 17:05:13 -0700 (PDT) Received: from exprod6og117.obsmtp.com (exprod6og117.obsmtp.com [64.18.1.39]) by ietfa.amsl.com (Postfix) with ESMTP id 41D1921F8B72 for ; Sun, 23 Oct 2011 17:05:13 -0700 (PDT) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob117.postini.com ([64.18.5.12]) with SMTP; Sun, 23 Oct 2011 17:05:13 PDT 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 p9O051Bb028241; Sun, 23 Oct 2011 17:05:02 -0700 (PDT) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id p9O050LV011521; Sun, 23 Oct 2011 17:05:00 -0700 (PDT) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas02.corp.adobe.com ([10.8.189.100]) with mapi; Sun, 23 Oct 2011 17:04:59 -0700 From: Larry Masinter To: Adam Barth Date: Sun, 23 Oct 2011 17:04:59 -0700 Thread-Topic: Are all the issues filed? (was: Re: [websec] Using IETF Tracker for issues on MIME sniffing?) Thread-Index: AcyQ7EbbOo3PTs1XSh+nc9oxrpLyqAA8x8dw Message-ID: References: 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: "websec@ietf.org" Subject: Re: [websec] Are all the issues filed? (was: Re: Using IETF Tracker for issues on MIME 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, 24 Oct 2011 00:05:14 -0000 I'd meant to do more careful write-ups of the issues I put into the tracker= , but I've put in the main issues left over from draft-masinter-mime-sniff.= =20 The document also contains several sections (on sniffing fonts, for example= ) which are left as TBD. I suppose each of those is a separate "issue" to f= ill out. Larry From tobias.gondrom@gondrom.org Sun Oct 23 20:03:58 2011 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 74B9F21F8BB2 for ; Sun, 23 Oct 2011 20:03:58 -0700 (PDT) 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 1uRq2ggZLahz for ; Sun, 23 Oct 2011 20:03:57 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id 7569021F8B4D for ; Sun, 23 Oct 2011 20:03:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=DcnJXVauk7Zll5EBBmZ4h7/pZMzrFFw5RvW8VbGcHedW7N+2lE4/wWegIDzSAKGmZIIAH/2Txk4VqiuzDLChZyXDLdpij4XJGF7VW/oYXBneUiMxr+nLM6QMasVW7JcS; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 23806 invoked from network); 24 Oct 2011 05:03:17 +0200 Received: from unknown (HELO ?10.5.5.61?) (61.8.220.69) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 24 Oct 2011 05:03:17 +0200 Message-ID: <4EA4D547.4030805@gondrom.org> Date: Mon, 24 Oct 2011 04:02:31 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110923 Thunderbird/7.0 MIME-Version: 1.0 To: websec@ietf.org References: <059.38de41cc08d30327b007c754bc555885@trac.tools.ietf.org> In-Reply-To: <059.38de41cc08d30327b007c754bc555885@trac.tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [websec] #19: Do not sniff PDF 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, 24 Oct 2011 03:03:58 -0000 Am not sure I understand this issue: - in which way is it more certain that there is no mislabeled PDF than a mislabeled jpg or mislabeled rtf? - what about scenarios in which there is no content-type (e.g. ftp, filesystem), should in this case sniffing not be done? Kind regards, Tobias On 24/10/11 00:43, websec issue tracker wrote: > #19: Do not sniff PDF > > There should be a strong advice not to sniff PDF -- if the data is > mislabeled as something else, then sending it to a PDF interpreter is > likely just an error. > From tobias.gondrom@gondrom.org Sun Oct 23 20:06:02 2011 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 B40ED21F84D7 for ; Sun, 23 Oct 2011 20:06:02 -0700 (PDT) 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 K+svXw96sqZR for ; Sun, 23 Oct 2011 20:06:02 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id D788421F84CD for ; Sun, 23 Oct 2011 20:05:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=hV7OQq4fULUrla9MGxoCbvVpSWUtWZB2k8GE5Sy56wMyQ4SCWhIkjq/R35ucRe6lLuMdqA1zwEf9s+C46j9ysLKl+pO1bSbPMI1w1E+XzEmp40bs3Rq6zm1ZN+3FaOv1; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 23835 invoked from network); 24 Oct 2011 05:05:59 +0200 Received: from unknown (HELO ?10.5.5.61?) (61.8.220.69) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 24 Oct 2011 05:05:58 +0200 Message-ID: <4EA4D616.4090304@gondrom.org> Date: Mon, 24 Oct 2011 04:05:58 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110923 Thunderbird/7.0 MIME-Version: 1.0 To: websec@ietf.org References: <059.f4c24ea9835018ac54322b267fbda143@trac.tools.ietf.org> In-Reply-To: <059.f4c24ea9835018ac54322b267fbda143@trac.tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [websec] #20: Sniffing should be "opt in" on a case-by-case basis 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, 24 Oct 2011 03:06:02 -0000 Agree with this one. With one addition: it must be clear, that if you "opt-in" for sniffing, than you MUST (SHOULD?) follow the mime-sniffing algorithm. Kind regards, Tobias On 24/10/11 00:48, websec issue tracker wrote: > #20: Sniffing should be "opt in" on a case-by-case basis > > The way the document is written as a normative algorithm makes it hard to > say this, but: > > Every implementation should be free to "opt out" of sniffing based on > other information it has (previous experience with the site, information > based on whether a correct MIME type was given vs. misconfigured, etc.) > > From the point of view of a web site, there's no additional security or > danger from opting out on a case-by-case basis; it's the same as, on a > case-by-case basis, choosing between two implementations, one of which > always sniffs and the other never sniffs. > From tobias.gondrom@gondrom.org Sun Oct 23 20:17:36 2011 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 964FD21F86A6 for ; Sun, 23 Oct 2011 20:17:36 -0700 (PDT) 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, HTML_MESSAGE=0.001, 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 URRhVjgjIegY for ; Sun, 23 Oct 2011 20:17:35 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id C156721F86A4 for ; Sun, 23 Oct 2011 20:17:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=sHP7CscvWsjaEyLoOjHiKLUG8Tvnfd36tDAJ5c9Xiy79IHvba9oISxi2bnF6lF/c29JZ6YcTMbcbvVqJESNMwvC5KWkHoZOpgy/WsPeU0DGWv8mNFNv3dmBdkLn9gk5k; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type; Received: (qmail 23895 invoked from network); 24 Oct 2011 05:17:14 +0200 Received: from unknown (HELO ?10.5.5.61?) (61.8.220.69) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 24 Oct 2011 05:17:13 +0200 Message-ID: <4EA4D8B8.7010108@gondrom.org> Date: Mon, 24 Oct 2011 04:17:12 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110923 Thunderbird/7.0 MIME-Version: 1.0 To: websec@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------010508010609090907080403" Subject: [websec] font sniffing - Re: Are all the issues filed? (was: Re: Using IETF Tracker for issues on MIME 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, 24 Oct 2011 03:17:36 -0000 This is a multi-part message in MIME format. --------------010508010609090907080403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 24/10/11 01:04, Larry Masinter wrote: > I'd meant to do more careful write-ups of the issues I put into the tracker, but I've put in the main issues left over from draft-masinter-mime-sniff. > > The document also contains several sections (on sniffing fonts, for example) which are left as TBD. I suppose each of those is a separate "issue" to fill out. > > Larry > Thank you Larry. I have a question regarding font sniffing: Besides the short discussion at the last meetings, I do not recall much interest for that on the mailing-list. So, I am not sure how much interests really exists for the working group to be addressing that? (i.e. adding content-types for fonts and adding them to the mime-sniff draft...) Am I mistaken? Kind regards, Tobias --------------010508010609090907080403 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 24/10/11 01:04, Larry Masinter wrote: 
I'd meant to do more careful write-ups of the issues I put into the tracker, but I've put in the main issues left over from draft-masinter-mime-sniff. 

The document also contains several sections (on sniffing fonts, for example) which are left as TBD. I suppose each of those is a separate "issue" to fill out.

Larry

Thank you Larry.

I have a question regarding font sniffing:
Besides the short discussion at the last meetings, I do not recall much interest for that on the mailing-list. So, I am not sure how much interests really exists for the working group to be addressing that?
(i.e. adding content-types for fonts and adding them to the mime-sniff draft...)
Am I mistaken?

Kind regards, Tobias


 --------------010508010609090907080403-- From masinter@adobe.com Sun Oct 23 20:21:53 2011 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 4E15721F8A80 for ; Sun, 23 Oct 2011 20:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.353 X-Spam-Level: X-Spam-Status: No, score=-106.353 tagged_above=-999 required=5 tests=[AWL=0.246, 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 IkUsEGagQPR5 for ; Sun, 23 Oct 2011 20:21:52 -0700 (PDT) Received: from exprod6og104.obsmtp.com (exprod6og104.obsmtp.com [64.18.1.187]) by ietfa.amsl.com (Postfix) with ESMTP id 828E521F8A55 for ; Sun, 23 Oct 2011 20:21:52 -0700 (PDT) Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob104.postini.com ([64.18.5.12]) with SMTP; Sun, 23 Oct 2011 20:21:52 PDT 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 p9O3KDYE021450; Sun, 23 Oct 2011 20:20:13 -0700 (PDT) Received: from nacas01.corp.adobe.com (nacas01.corp.adobe.com [10.8.189.99]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id p9O3Ln5R013909; Sun, 23 Oct 2011 20:21:49 -0700 (PDT) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas01.corp.adobe.com ([10.8.189.99]) with mapi; Sun, 23 Oct 2011 20:21:49 -0700 From: Larry Masinter To: Tobias Gondrom , "websec@ietf.org" Date: Sun, 23 Oct 2011 20:21:46 -0700 Thread-Topic: [websec] #19: Do not sniff PDF Thread-Index: AcyR+ZUJJ0KmDP/0T6eQ/fjxVUjYKwAAKQTg Message-ID: References: <059.38de41cc08d30327b007c754bc555885@trac.tools.ietf.org> <4EA4D547.4030805@gondrom.org> In-Reply-To: <4EA4D547.4030805@gondrom.org> 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: Re: [websec] #19: Do not sniff PDF 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, 24 Oct 2011 03:21:53 -0000 > - in which way is it more certain that there is no mislabeled PDF than a = mislabeled jpg or mislabeled rtf? I don't think this is relevant. There is likely mislabeled PDF. But I had s= pecific feedback from implementors of PDF readers that sniffing from other = content-type resulted in a worse situation than not sniffing. I don't have = any information on jpg or rtf. Sniffing should only be done when it is justified by an improved user exper= ience over not sniffing.=20 I think the obligation of evidence is "opt in": we should only sniff conten= t when there is evidence of mislabeled content for which sniffing actually = improves something, and the improvement outweighs other considerations. > - what about scenarios in which there is no content-type (e.g. ftp, files= ystem), should in this case sniffing not be done? I didn't get any feedback on that. I don't know any workflows where valid P= DF doesn't carry a file type label somehow (if only the file extension .pdf= ), so maybe sniffing based on file content itself doesn't matter. ((Maybe this is another issue? I just wonder if the algorithm for "no conte= nt-type" is the same, needs to be the same, as the algorithm for "content-t= ype via HTTP".) Larry From ietf@adambarth.com Sun Oct 23 20:22:49 2011 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 273F221F8AA8 for ; Sun, 23 Oct 2011 20:22:49 -0700 (PDT) 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, 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 X2QG2KjNDkbV for ; Sun, 23 Oct 2011 20:22:48 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 98F4D21F8A35 for ; Sun, 23 Oct 2011 20:22:48 -0700 (PDT) Received: by iabn5 with SMTP id n5so8483133iab.31 for ; Sun, 23 Oct 2011 20:22:48 -0700 (PDT) Received: by 10.43.44.199 with SMTP id uh7mr38850302icb.25.1319426568337; Sun, 23 Oct 2011 20:22:48 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id z10sm56202358ibv.9.2011.10.23.20.22.46 (version=SSLv3 cipher=OTHER); Sun, 23 Oct 2011 20:22:46 -0700 (PDT) Received: by iabn5 with SMTP id n5so8483093iab.31 for ; Sun, 23 Oct 2011 20:22:46 -0700 (PDT) Received: by 10.231.41.9 with SMTP id m9mr9024199ibe.96.1319426566079; Sun, 23 Oct 2011 20:22:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.205.144 with HTTP; Sun, 23 Oct 2011 20:22:16 -0700 (PDT) In-Reply-To: <4EA4D8B8.7010108@gondrom.org> References: <4EA4D8B8.7010108@gondrom.org> From: Adam Barth Date: Sun, 23 Oct 2011 20:22:16 -0700 Message-ID: To: Tobias Gondrom Content-Type: text/plain; charset=ISO-8859-1 Cc: websec@ietf.org Subject: Re: [websec] font sniffing - Re: Are all the issues filed? (was: Re: Using IETF Tracker for issues on MIME 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, 24 Oct 2011 03:22:49 -0000 On Sun, Oct 23, 2011 at 8:17 PM, Tobias Gondrom wrote: > On 24/10/11 01:04, Larry Masinter wrote: > > I'd meant to do more careful write-ups of the issues I put into the tracker, > but I've put in the main issues left over from draft-masinter-mime-sniff. > > The document also contains several sections (on sniffing fonts, for example) > which are left as TBD. I suppose each of those is a separate "issue" to fill > out. > > Larry > > > Thank you Larry. > > I have a question regarding font sniffing: > Besides the short discussion at the last meetings, I do not recall much > interest for that on the mailing-list. So, I am not sure how much interests > really exists for the working group to be addressing that? > (i.e. adding content-types for fonts and adding them to the mime-sniff > draft...) > Am I mistaken? I added to the TODOs to the spec at the request of Anne van Kesteren. I have some notes about how how font sniffing is supposed to work, but I haven't researched it thoroughly. I don't recall anyone else asking for it specifically. Adam From tobias.gondrom@gondrom.org Sun Oct 23 20:24:56 2011 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 18C3521F8BCD for ; Sun, 23 Oct 2011 20:24:56 -0700 (PDT) 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 wpS+6RnViBZ3 for ; Sun, 23 Oct 2011 20:24:55 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id 00C1021F8B51 for ; Sun, 23 Oct 2011 20:24:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=gAlF4/Sw41E7ZHPcTRaxfM2SSkYQFGUFt4SC4WmZjRmkxElobPgYwd0PmYXB9laZCIXjOysWK2YAq/b4HF9RYYdU601OuXkxIKh2+acp0YmfIexJ1Sse3XkilF6WMuVO; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 23959 invoked from network); 24 Oct 2011 05:24:24 +0200 Received: from unknown (HELO ?10.5.5.61?) (61.8.220.69) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 24 Oct 2011 05:24:24 +0200 Message-ID: <4EA4DA67.3000502@gondrom.org> Date: Mon, 24 Oct 2011 04:24:23 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110923 Thunderbird/7.0 MIME-Version: 1.0 To: websec@ietf.org References: <059.f8bc48a3163d95d888ee3a23a2ca7fb9@trac.tools.ietf.org> In-Reply-To: <059.f8bc48a3163d95d888ee3a23a2ca7fb9@trac.tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [websec] #22: content-type sniffing should include charset 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, 24 Oct 2011 03:24:56 -0000 I tend not to agree with that. The fact that charset sniffing might happen at the same time as mime-sniffing does not seem like a strong argument to include this in the draft. Furthermore I would rather have these issues separate: First you determine the content-type and then after that you may want to determine the charset used within that content-type (if you really have to sniff the charset). I can also imagine that charset sniffing algorithm might be depending on the application identified by the sniffed mime-type, which again would speak against throwing it in together with mime-sniffing.... Kind regards, Tobias On 24/10/11 00:55, websec issue tracker wrote: > #22: content-type sniffing should include charset sniffing > > the HTML5 spec contains some algorithms for sniffing charset, overriding > labeled charset, etc. > > MIME parameters like charset are as much a part of the content-type as the > base internet media type, and any sniffing of parameters and other > metadata (overriding content-type or guessing where it is not supplied or > wrong) should be included in this document, since the sniffing will happen > at the same time. > From ietf@adambarth.com Sun Oct 23 20:26:15 2011 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 73FC221F8B9A for ; Sun, 23 Oct 2011 20:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.931 X-Spam-Level: X-Spam-Status: No, score=-0.931 tagged_above=-999 required=5 tests=[AWL=-0.409, 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 ln50B14NFB6j for ; Sun, 23 Oct 2011 20:26:15 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id F1E3721F8B94 for ; Sun, 23 Oct 2011 20:26:14 -0700 (PDT) Received: by iabn5 with SMTP id n5so8486437iab.31 for ; Sun, 23 Oct 2011 20:26:14 -0700 (PDT) Received: by 10.42.117.71 with SMTP id s7mr26454019icq.37.1319426774762; Sun, 23 Oct 2011 20:26:14 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id p18sm8226951ibe.7.2011.10.23.20.26.13 (version=SSLv3 cipher=OTHER); Sun, 23 Oct 2011 20:26:13 -0700 (PDT) Received: by iabn5 with SMTP id n5so8486411iab.31 for ; Sun, 23 Oct 2011 20:26:13 -0700 (PDT) Received: by 10.231.41.9 with SMTP id m9mr9027547ibe.96.1319426773098; Sun, 23 Oct 2011 20:26:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.205.144 with HTTP; Sun, 23 Oct 2011 20:25:43 -0700 (PDT) In-Reply-To: References: <059.38de41cc08d30327b007c754bc555885@trac.tools.ietf.org> <4EA4D547.4030805@gondrom.org> From: Adam Barth Date: Sun, 23 Oct 2011 20:25:43 -0700 Message-ID: To: Larry Masinter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "websec@ietf.org" Subject: Re: [websec] #19: Do not sniff PDF 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, 24 Oct 2011 03:26:15 -0000 On Sun, Oct 23, 2011 at 8:21 PM, Larry Masinter wrote: >> - in which way is it more certain that there is no mislabeled PDF than a= mislabeled jpg or mislabeled rtf? > > I don't think this is relevant. There is likely mislabeled PDF. But I had= specific feedback from implementors of PDF readers that sniffing from othe= r content-type resulted in a worse situation than not sniffing. I don't hav= e any information on jpg or rtf. > > Sniffing should only be done when it is justified by an improved user exp= erience over not sniffing. That seems very anecdotal. Do you have data to back up these claims? Adam From masinter@adobe.com Sun Oct 23 20:26:47 2011 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 D9AE721F8507 for ; Sun, 23 Oct 2011 20:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.394 X-Spam-Level: X-Spam-Status: No, score=-106.394 tagged_above=-999 required=5 tests=[AWL=0.205, 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 AdIAARDx6r+4 for ; Sun, 23 Oct 2011 20:26:47 -0700 (PDT) Received: from exprod6og114.obsmtp.com (exprod6og114.obsmtp.com [64.18.1.33]) by ietfa.amsl.com (Postfix) with ESMTP id BBB5921F84D5 for ; Sun, 23 Oct 2011 20:26:46 -0700 (PDT) Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob114.postini.com ([64.18.5.12]) with SMTP; Sun, 23 Oct 2011 20:26:46 PDT 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 p9O3P8YE021662; Sun, 23 Oct 2011 20:25:08 -0700 (PDT) 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 p9O3Qi5R014633; Sun, 23 Oct 2011 20:26:44 -0700 (PDT) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nahub01.corp.adobe.com ([10.8.189.97]) with mapi; Sun, 23 Oct 2011 20:26:44 -0700 From: Larry Masinter To: Tobias Gondrom , "websec@ietf.org" Date: Sun, 23 Oct 2011 20:26:42 -0700 Thread-Topic: [websec] #20: Sniffing should be "opt in" on a case-by-case basis Thread-Index: AcyR+ih4nA0PEDr4RiSic7a4SwNz8gAAewVQ Message-ID: References: <059.f4c24ea9835018ac54322b267fbda143@trac.tools.ietf.org> <4EA4D616.4090304@gondrom.org> In-Reply-To: <4EA4D616.4090304@gondrom.org> 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: Re: [websec] #20: Sniffing should be "opt in" on a case-by-case basis 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, 24 Oct 2011 03:26:48 -0000 > Agree with this one. > With one addition: it must be clear, that if you "opt-in" for sniffing, t= han you MUST (SHOULD?) follow the mime-sniffing algorithm. I don't think that's possible. I think the crux of this issue is that I don= 't think the "mime-sniffing algorithm" is currently structured in a way tha= t lets the results be "opt-in" on a case-by-case basis. =20 For example, the algorithm starts with an analysis of existing content-type= headers, and winds up, in its state transition and communication paths, no= t letting later stages of the algorithm know whether the supplied content-t= ype was malformed, whether there were two rather than one, etc. So if you= follow the algorithm, you don't have any way (at least if you're just foll= owing this algorithm) of "opting" later in ways that want to distinguish. = =20 From ietf@adambarth.com Sun Oct 23 20:29:00 2011 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 0E03421F8BDC for ; Sun, 23 Oct 2011 20:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.056 X-Spam-Level: X-Spam-Status: No, score=-2.056 tagged_above=-999 required=5 tests=[AWL=0.921, 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 B8miA87TLwBg for ; Sun, 23 Oct 2011 20:28:59 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7F83521F8B9A for ; Sun, 23 Oct 2011 20:28:59 -0700 (PDT) Received: by iabn5 with SMTP id n5so8489056iab.31 for ; Sun, 23 Oct 2011 20:28:59 -0700 (PDT) Received: by 10.231.46.66 with SMTP id i2mr8988201ibf.0.1319426939237; Sun, 23 Oct 2011 20:28:59 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id n30sm56293206ibl.4.2011.10.23.20.28.58 (version=SSLv3 cipher=OTHER); Sun, 23 Oct 2011 20:28:58 -0700 (PDT) Received: by iabn5 with SMTP id n5so8489046iab.31 for ; Sun, 23 Oct 2011 20:28:58 -0700 (PDT) Received: by 10.231.5.102 with SMTP id 38mr8934213ibu.98.1319426938067; Sun, 23 Oct 2011 20:28:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.205.144 with HTTP; Sun, 23 Oct 2011 20:28:28 -0700 (PDT) In-Reply-To: <4EA4DA67.3000502@gondrom.org> References: <059.f8bc48a3163d95d888ee3a23a2ca7fb9@trac.tools.ietf.org> <4EA4DA67.3000502@gondrom.org> From: Adam Barth Date: Sun, 23 Oct 2011 20:28:28 -0700 Message-ID: To: Tobias Gondrom Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: websec@ietf.org Subject: Re: [websec] #22: content-type sniffing should include charset 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, 24 Oct 2011 03:29:00 -0000 The charset sniffing is also complicated by the fact that sometimes user agents need to parse some of the HTML to find a element. In some situations, user agents need to restart the parsing algorithm, which is quite delicate and better to describe in the same document as HTML parsing (at least for use by HTML processing engines). Adam On Sun, Oct 23, 2011 at 8:24 PM, Tobias Gondrom wrote: > > I tend not to agree with that. > > The fact that charset sniffing might happen at the same time as > mime-sniffing does not seem like a strong argument to include this in the > draft. > > Furthermore I would rather have these issues separate: > First you determine the content-type and then after that you may want to > determine the charset used within that content-type (if you really have t= o > sniff the charset). I can also imagine that charset sniffing algorithm mi= ght > be depending on the application identified by the sniffed mime-type, whic= h > again would speak against throwing it in together with mime-sniffing.... > > Kind regards, Tobias > > > > On 24/10/11 00:55, websec issue tracker wrote: >> >> #22: content-type sniffing should include charset sniffing >> >> =A0the HTML5 spec contains some algorithms for sniffing charset, overrid= ing >> =A0labeled charset, etc. >> >> =A0MIME parameters like charset are as much a part of the content-type a= s >> the >> =A0base internet media type, and any sniffing of parameters and other >> =A0metadata (overriding content-type or guessing where it is not supplie= d or >> =A0wrong) should be included in this document, since the sniffing will >> happen >> =A0at the same time. >> > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > From ietf@adambarth.com Sun Oct 23 20:29:50 2011 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 26B6721F8BE5 for ; Sun, 23 Oct 2011 20:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.013 X-Spam-Level: X-Spam-Status: No, score=-1.013 tagged_above=-999 required=5 tests=[AWL=-0.491, 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 L9CBoZFyUaL1 for ; Sun, 23 Oct 2011 20:29:49 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id A156921F8BDC for ; Sun, 23 Oct 2011 20:29:49 -0700 (PDT) Received: by iabn5 with SMTP id n5so8489741iab.31 for ; Sun, 23 Oct 2011 20:29:49 -0700 (PDT) Received: by 10.231.6.102 with SMTP id 38mr9044503iby.62.1319426989415; Sun, 23 Oct 2011 20:29:49 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id g16sm56256365ibs.8.2011.10.23.20.29.48 (version=SSLv3 cipher=OTHER); Sun, 23 Oct 2011 20:29:48 -0700 (PDT) Received: by iabn5 with SMTP id n5so8489723iab.31 for ; Sun, 23 Oct 2011 20:29:48 -0700 (PDT) Received: by 10.231.50.202 with SMTP id a10mr10024026ibg.39.1319426988086; Sun, 23 Oct 2011 20:29:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.205.144 with HTTP; Sun, 23 Oct 2011 20:29:18 -0700 (PDT) In-Reply-To: References: <059.f4c24ea9835018ac54322b267fbda143@trac.tools.ietf.org> <4EA4D616.4090304@gondrom.org> From: Adam Barth Date: Sun, 23 Oct 2011 20:29:18 -0700 Message-ID: To: Larry Masinter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "websec@ietf.org" Subject: Re: [websec] #20: Sniffing should be "opt in" on a case-by-case basis 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, 24 Oct 2011 03:29:50 -0000 On Sun, Oct 23, 2011 at 8:26 PM, Larry Masinter wrote: >> Agree with this one. >> With one addition: it must be clear, that if you "opt-in" for sniffing, = than you MUST (SHOULD?) follow the mime-sniffing algorithm. > > I don't think that's possible. I think the crux of this issue is that I d= on't think the "mime-sniffing algorithm" is currently structured in a way t= hat lets the results be "opt-in" on a case-by-case basis. > > For example, the algorithm starts with an analysis of existing content-ty= pe headers, and winds up, in its state transition and communication paths, = not letting later stages of the algorithm know whether the supplied content= -type was malformed, whether there were two rather than one, etc. =A0 So if= you follow the algorithm, you don't have any way (at least if you're just = following this algorithm) of "opting" later in ways that want to distinguis= h. Sure, but those are things we can fix. :) Adam From masinter@adobe.com Sun Oct 23 20:30:03 2011 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 0641721F8BDC for ; Sun, 23 Oct 2011 20:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.424 X-Spam-Level: X-Spam-Status: No, score=-106.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 q19ai1ze8408 for ; Sun, 23 Oct 2011 20:30:02 -0700 (PDT) Received: from exprod6og115.obsmtp.com (exprod6og115.obsmtp.com [64.18.1.35]) by ietfa.amsl.com (Postfix) with ESMTP id D898921F8BF8 for ; Sun, 23 Oct 2011 20:30:01 -0700 (PDT) Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob115.postini.com ([64.18.5.12]) with SMTP; Sun, 23 Oct 2011 20:30:02 PDT 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 p9O3SNYE021812; Sun, 23 Oct 2011 20:28:23 -0700 (PDT) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id p9O3Tx5R015178; Sun, 23 Oct 2011 20:29:59 -0700 (PDT) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas02.corp.adobe.com ([10.8.189.100]) with mapi; Sun, 23 Oct 2011 20:29:59 -0700 From: Larry Masinter To: Tobias Gondrom , "websec@ietf.org" Date: Sun, 23 Oct 2011 20:29:57 -0700 Thread-Topic: [websec] #22: content-type sniffing should include charset sniffing Thread-Index: AcyR/ITA/r5tX4YiSuSTTET/Li7V2QAAECZQ Message-ID: References: <059.f8bc48a3163d95d888ee3a23a2ca7fb9@trac.tools.ietf.org> <4EA4DA67.3000502@gondrom.org> In-Reply-To: <4EA4DA67.3000502@gondrom.org> 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: Re: [websec] #22: content-type sniffing should include charset 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, 24 Oct 2011 03:30:03 -0000 > First you determine the content-type and then after that you may want to = determine the charset used within that content-type That's wishful thinking that doesn't match what has to happen ... the mime-= sniffing document ALREADY is looking at the charset, by looking for byte-or= der-mark signatures to decide whether the content is text or binary. So we're already doing charset detection, just not calling it that or compl= etely specifying it. From ietf@adambarth.com Sun Oct 23 20:32:27 2011 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 1FC7721F8BAB for ; Sun, 23 Oct 2011 20:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.931 X-Spam-Level: X-Spam-Status: No, score=-0.931 tagged_above=-999 required=5 tests=[AWL=-0.409, 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 67cnz+r6KI5c for ; Sun, 23 Oct 2011 20:32:26 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id AD25921F8B8F for ; Sun, 23 Oct 2011 20:32:26 -0700 (PDT) Received: by iabn5 with SMTP id n5so8492312iab.31 for ; Sun, 23 Oct 2011 20:32:26 -0700 (PDT) Received: by 10.231.63.212 with SMTP id c20mr2919226ibi.52.1319427146468; Sun, 23 Oct 2011 20:32:26 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id jm11sm56340545ibb.1.2011.10.23.20.32.25 (version=SSLv3 cipher=OTHER); Sun, 23 Oct 2011 20:32:25 -0700 (PDT) Received: by iabn5 with SMTP id n5so8492289iab.31 for ; Sun, 23 Oct 2011 20:32:25 -0700 (PDT) Received: by 10.231.63.209 with SMTP id c17mr9897144ibi.65.1319427145115; Sun, 23 Oct 2011 20:32:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.205.144 with HTTP; Sun, 23 Oct 2011 20:31:55 -0700 (PDT) In-Reply-To: References: <059.f8bc48a3163d95d888ee3a23a2ca7fb9@trac.tools.ietf.org> <4EA4DA67.3000502@gondrom.org> From: Adam Barth Date: Sun, 23 Oct 2011 20:31:55 -0700 Message-ID: To: Larry Masinter Content-Type: text/plain; charset=ISO-8859-1 Cc: "websec@ietf.org" Subject: Re: [websec] #22: content-type sniffing should include charset 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, 24 Oct 2011 03:32:27 -0000 On Sun, Oct 23, 2011 at 8:29 PM, Larry Masinter wrote: >> First you determine the content-type and then after that you may want to determine the charset used within that content-type > > That's wishful thinking that doesn't match what has to happen ... the mime-sniffing document ALREADY is looking at the charset, by looking for byte-order-mark signatures to decide whether the content is text or binary. > So we're already doing charset detection, just not calling it that or completely specifying it. I mean, the full charset sniffing algorithm is significantly more complicated that that. For example, it also takes into account other frames being rendering by the user agent. Adam From masinter@adobe.com Sun Oct 23 20:32:59 2011 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 A0C2021F8BAB for ; Sun, 23 Oct 2011 20:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.569 X-Spam-Level: X-Spam-Status: No, score=-106.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 KYIriqqfyFcQ for ; Sun, 23 Oct 2011 20:32:58 -0700 (PDT) Received: from exprod6og112.obsmtp.com (exprod6og112.obsmtp.com [64.18.1.29]) by ietfa.amsl.com (Postfix) with ESMTP id 4C07021F8B8F for ; Sun, 23 Oct 2011 20:32:58 -0700 (PDT) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob112.postini.com ([64.18.5.12]) with SMTP; Sun, 23 Oct 2011 20:32:58 PDT 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 p9O3WsBb006323; Sun, 23 Oct 2011 20:32:54 -0700 (PDT) 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 p9O3WrLV004057; Sun, 23 Oct 2011 20:32:53 -0700 (PDT) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nahub02.corp.adobe.com ([10.8.189.98]) with mapi; Sun, 23 Oct 2011 20:32:53 -0700 From: Larry Masinter To: Adam Barth , Tobias Gondrom Date: Sun, 23 Oct 2011 20:32:51 -0700 Thread-Topic: [websec] #22: content-type sniffing should include charset sniffing Thread-Index: AcyR/RR8Hfu/lCr+RdC2FmQusFWh/wAACYmQ Message-ID: References: <059.f8bc48a3163d95d888ee3a23a2ca7fb9@trac.tools.ietf.org> <4EA4DA67.3000502@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "websec@ietf.org" Subject: Re: [websec] #22: content-type sniffing should include charset 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, 24 Oct 2011 03:32:59 -0000 I know it's complicated, but scanning text is necessarily part of determini= ng which application/something+xml you have. I think (but should really c= heck before saying this) that XML media type registrations describe what th= e DOCTYPE or XML namespace or root element are, and that, to properly "snif= f" them, you'd have to scan text. But before you scan text, you have to det= ermine charset. So if we're going to support sniffing of media types in general, I don't se= e how we can do that without also specifying charset determination. Larry ] -----Original Message----- From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On Behalf Of= Adam Barth Sent: Sunday, October 23, 2011 8:28 PM To: Tobias Gondrom Cc: websec@ietf.org Subject: Re: [websec] #22: content-type sniffing should include charset sni= ffing The charset sniffing is also complicated by the fact that sometimes user ag= ents need to parse some of the HTML to find a element. In some situations, user agents need to restart the parsing algorithm, whic= h is quite delicate and better to describe in the same document as HTML par= sing (at least for use by HTML processing engines). Adam On Sun, Oct 23, 2011 at 8:24 PM, Tobias Gondrom wrote: > > I tend not to agree with that. > > The fact that charset sniffing might happen at the same time as=20 > mime-sniffing does not seem like a strong argument to include this in=20 > the draft. > > Furthermore I would rather have these issues separate: > First you determine the content-type and then after that you may want=20 > to determine the charset used within that content-type (if you really=20 > have to sniff the charset). I can also imagine that charset sniffing=20 > algorithm might be depending on the application identified by the=20 > sniffed mime-type, which again would speak against throwing it in togethe= r with mime-sniffing.... > > Kind regards, Tobias > > > > On 24/10/11 00:55, websec issue tracker wrote: >> >> #22: content-type sniffing should include charset sniffing >> >> =A0the HTML5 spec contains some algorithms for sniffing charset,=20 >> overriding >> =A0labeled charset, etc. >> >> =A0MIME parameters like charset are as much a part of the content-type=20 >> as the >> =A0base internet media type, and any sniffing of parameters and other >> =A0metadata (overriding content-type or guessing where it is not=20 >> supplied or >> =A0wrong) should be included in this document, since the sniffing will=20 >> happen >> =A0at the same time. >> > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > _______________________________________________ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec From ietf@adambarth.com Sun Oct 23 20:37:59 2011 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 5B25821F8B66 for ; Sun, 23 Oct 2011 20:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.873 X-Spam-Level: X-Spam-Status: No, score=-0.873 tagged_above=-999 required=5 tests=[AWL=-0.351, 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 PBTddokIG07R for ; Sun, 23 Oct 2011 20:37:58 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id A3C8C21F8B56 for ; Sun, 23 Oct 2011 20:37:58 -0700 (PDT) Received: by iabn5 with SMTP id n5so8497701iab.31 for ; Sun, 23 Oct 2011 20:37:58 -0700 (PDT) Received: by 10.42.157.3 with SMTP id b3mr38701672icx.44.1319427478289; Sun, 23 Oct 2011 20:37:58 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id eh34sm56338941ibb.5.2011.10.23.20.37.57 (version=SSLv3 cipher=OTHER); Sun, 23 Oct 2011 20:37:57 -0700 (PDT) Received: by iabn5 with SMTP id n5so8497685iab.31 for ; Sun, 23 Oct 2011 20:37:57 -0700 (PDT) Received: by 10.231.5.102 with SMTP id 38mr8942068ibu.98.1319427477278; Sun, 23 Oct 2011 20:37:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.205.144 with HTTP; Sun, 23 Oct 2011 20:37:27 -0700 (PDT) In-Reply-To: References: <059.f8bc48a3163d95d888ee3a23a2ca7fb9@trac.tools.ietf.org> <4EA4DA67.3000502@gondrom.org> From: Adam Barth Date: Sun, 23 Oct 2011 20:37:27 -0700 Message-ID: To: Larry Masinter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "websec@ietf.org" Subject: Re: [websec] #22: content-type sniffing should include charset 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, 24 Oct 2011 03:37:59 -0000 I mean, that's how the code works, so it must be possible. :) Adam On Sun, Oct 23, 2011 at 8:32 PM, Larry Masinter wrote: > I know it's complicated, but scanning text is necessarily part of determi= ning which application/something+xml =A0you have. =A0I think (but should re= ally check before saying this) that XML media type registrations describe w= hat the DOCTYPE or XML namespace or root element are, and that, to properly= "sniff" them, you'd have to scan text. But before you scan text, you have = to determine charset. > > So if we're going to support sniffing of media types in general, I don't = see how we can do that without also specifying charset determination. > > > > Larry > ] > > -----Original Message----- > From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On Behalf = Of Adam Barth > Sent: Sunday, October 23, 2011 8:28 PM > To: Tobias Gondrom > Cc: websec@ietf.org > Subject: Re: [websec] #22: content-type sniffing should include charset s= niffing > > The charset sniffing is also complicated by the fact that sometimes user = agents need to parse some of the HTML to find a element. > In some situations, user agents need to restart the parsing algorithm, wh= ich is quite delicate and better to describe in the same document as HTML p= arsing (at least for use by HTML processing engines). > > Adam > > > On Sun, Oct 23, 2011 at 8:24 PM, Tobias Gondrom wrote: >> >> I tend not to agree with that. >> >> The fact that charset sniffing might happen at the same time as >> mime-sniffing does not seem like a strong argument to include this in >> the draft. >> >> Furthermore I would rather have these issues separate: >> First you determine the content-type and then after that you may want >> to determine the charset used within that content-type (if you really >> have to sniff the charset). I can also imagine that charset sniffing >> algorithm might be depending on the application identified by the >> sniffed mime-type, which again would speak against throwing it in togeth= er with mime-sniffing.... >> >> Kind regards, Tobias >> >> >> >> On 24/10/11 00:55, websec issue tracker wrote: >>> >>> #22: content-type sniffing should include charset sniffing >>> >>> =A0the HTML5 spec contains some algorithms for sniffing charset, >>> overriding >>> =A0labeled charset, etc. >>> >>> =A0MIME parameters like charset are as much a part of the content-type >>> as the >>> =A0base internet media type, and any sniffing of parameters and other >>> =A0metadata (overriding content-type or guessing where it is not >>> supplied or >>> =A0wrong) should be included in this document, since the sniffing will >>> happen >>> =A0at the same time. >>> >> >> _______________________________________________ >> websec mailing list >> websec@ietf.org >> https://www.ietf.org/mailman/listinfo/websec >> > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > From masinter@adobe.com Sun Oct 23 21:14:28 2011 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 AB7AC21F8B48 for ; Sun, 23 Oct 2011 21:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.218 X-Spam-Level: X-Spam-Status: No, score=-105.218 tagged_above=-999 required=5 tests=[AWL=-1.074, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 L4FcaBI437bZ for ; Sun, 23 Oct 2011 21:14:28 -0700 (PDT) Received: from exprod6og112.obsmtp.com (exprod6og112.obsmtp.com [64.18.1.29]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB7321F8AF2 for ; Sun, 23 Oct 2011 21:14:27 -0700 (PDT) Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob112.postini.com ([64.18.5.12]) with SMTP; Sun, 23 Oct 2011 21:14:27 PDT 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 p9O4ClYE024096; Sun, 23 Oct 2011 21:12:48 -0700 (PDT) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id p9O4EN5R022504; Sun, 23 Oct 2011 21:14:23 -0700 (PDT) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas02.corp.adobe.com ([10.8.189.100]) with mapi; Sun, 23 Oct 2011 21:14:23 -0700 From: Larry Masinter To: Adam Barth Date: Sun, 23 Oct 2011 21:14:21 -0700 Thread-Topic: [websec] #22: content-type sniffing should include charset sniffing Thread-Index: AcyR/lNNSWJtErEjTQObYeg99QPNFQAAzZ5g Message-ID: References: <059.f8bc48a3163d95d888ee3a23a2ca7fb9@trac.tools.ietf.org> <4EA4DA67.3000502@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "websec@ietf.org" Subject: Re: [websec] #22: content-type sniffing should include charset 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, 24 Oct 2011 04:14:28 -0000 I was talking about the necessary dependency of the specifications -- that = you couldn't specify media type sniffing completely without making at least= a normative reference to charset sniffing.=20 The fact that the code works that way is evidence, of course, but we're not= talking about possibility of implementation (where a single implementation= is evidence) but rather orthogonality of interfaces (where the question is= whether ALL implementations must follow this pattern.) Larry -----Original Message----- From: Adam Barth [mailto:ietf@adambarth.com]=20 Sent: Sunday, October 23, 2011 8:37 PM To: Larry Masinter Cc: Tobias Gondrom; websec@ietf.org Subject: Re: [websec] #22: content-type sniffing should include charset sni= ffing I mean, that's how the code works, so it must be possible. :) Adam On Sun, Oct 23, 2011 at 8:32 PM, Larry Masinter wrote: > I know it's complicated, but scanning text is necessarily part of determi= ning which application/something+xml =A0you have. =A0I think (but should re= ally check before saying this) that XML media type registrations describe w= hat the DOCTYPE or XML namespace or root element are, and that, to properly= "sniff" them, you'd have to scan text. But before you scan text, you have = to determine charset. > > So if we're going to support sniffing of media types in general, I don't = see how we can do that without also specifying charset determination. > > > > Larry > ] > > -----Original Message----- > From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On=20 > Behalf Of Adam Barth > Sent: Sunday, October 23, 2011 8:28 PM > To: Tobias Gondrom > Cc: websec@ietf.org > Subject: Re: [websec] #22: content-type sniffing should include=20 > charset sniffing > > The charset sniffing is also complicated by the fact that sometimes user = agents need to parse some of the HTML to find a element. > In some situations, user agents need to restart the parsing algorithm, wh= ich is quite delicate and better to describe in the same document as HTML p= arsing (at least for use by HTML processing engines). > > Adam > > > On Sun, Oct 23, 2011 at 8:24 PM, Tobias Gondrom wrote: >> >> I tend not to agree with that. >> >> The fact that charset sniffing might happen at the same time as=20 >> mime-sniffing does not seem like a strong argument to include this in=20 >> the draft. >> >> Furthermore I would rather have these issues separate: >> First you determine the content-type and then after that you may want=20 >> to determine the charset used within that content-type (if you really=20 >> have to sniff the charset). I can also imagine that charset sniffing=20 >> algorithm might be depending on the application identified by the=20 >> sniffed mime-type, which again would speak against throwing it in togeth= er with mime-sniffing.... >> >> Kind regards, Tobias >> >> >> >> On 24/10/11 00:55, websec issue tracker wrote: >>> >>> #22: content-type sniffing should include charset sniffing >>> >>> =A0the HTML5 spec contains some algorithms for sniffing charset,=20 >>> overriding >>> =A0labeled charset, etc. >>> >>> =A0MIME parameters like charset are as much a part of the content-type= =20 >>> as the >>> =A0base internet media type, and any sniffing of parameters and other >>> =A0metadata (overriding content-type or guessing where it is not=20 >>> supplied or >>> =A0wrong) should be included in this document, since the sniffing will= =20 >>> happen >>> =A0at the same time. >>> >> >> _______________________________________________ >> websec mailing list >> websec@ietf.org >> https://www.ietf.org/mailman/listinfo/websec >> > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > From ietf@adambarth.com Sun Oct 23 21:38:27 2011 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 89F6221F8BBF for ; Sun, 23 Oct 2011 21:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.829 X-Spam-Level: X-Spam-Status: No, score=-0.829 tagged_above=-999 required=5 tests=[AWL=-0.307, 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 EmRigddFUKqg for ; Sun, 23 Oct 2011 21:38:26 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA4821F8BBC for ; Sun, 23 Oct 2011 21:38:26 -0700 (PDT) Received: by yxi11 with SMTP id 11so1157423yxi.31 for ; Sun, 23 Oct 2011 21:38:26 -0700 (PDT) Received: by 10.42.147.65 with SMTP id m1mr39464526icv.27.1319431106046; Sun, 23 Oct 2011 21:38:26 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id jm11sm56784149ibb.1.2011.10.23.21.38.24 (version=SSLv3 cipher=OTHER); Sun, 23 Oct 2011 21:38:24 -0700 (PDT) Received: by iabn5 with SMTP id n5so8555900iab.31 for ; Sun, 23 Oct 2011 21:38:24 -0700 (PDT) Received: by 10.231.50.202 with SMTP id a10mr10099813ibg.39.1319431104154; Sun, 23 Oct 2011 21:38:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.205.144 with HTTP; Sun, 23 Oct 2011 21:37:54 -0700 (PDT) In-Reply-To: References: <059.f8bc48a3163d95d888ee3a23a2ca7fb9@trac.tools.ietf.org> <4EA4DA67.3000502@gondrom.org> From: Adam Barth Date: Sun, 23 Oct 2011 21:37:54 -0700 Message-ID: To: Larry Masinter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "websec@ietf.org" Subject: Re: [websec] #22: content-type sniffing should include charset 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, 24 Oct 2011 04:38:27 -0000 One way to look at the situation is that the sniffing algorithm operates on octets, not on characters, which is actually what the draft says. In that view, it's perfectly well-defined without reference to character sets. The fact that the octets happen to correspond to certain ASCII characters is somewhat beside the point. Adam On Sun, Oct 23, 2011 at 9:14 PM, Larry Masinter wrote: > I was talking about the necessary dependency of the specifications -- tha= t you couldn't specify media type sniffing completely without making at lea= st a normative reference to charset sniffing. > > The fact that the code works that way is evidence, of course, but we're n= ot talking about possibility of implementation (where a single implementati= on is evidence) but rather orthogonality of interfaces (where the question = is whether ALL implementations must follow this pattern.) > > Larry > > > > > -----Original Message----- > From: Adam Barth [mailto:ietf@adambarth.com] > Sent: Sunday, October 23, 2011 8:37 PM > To: Larry Masinter > Cc: Tobias Gondrom; websec@ietf.org > Subject: Re: [websec] #22: content-type sniffing should include charset s= niffing > > I mean, that's how the code works, so it must be possible. =A0:) > > Adam > > > On Sun, Oct 23, 2011 at 8:32 PM, Larry Masinter wrot= e: >> I know it's complicated, but scanning text is necessarily part of determ= ining which application/something+xml =A0you have. =A0I think (but should r= eally check before saying this) that XML media type registrations describe = what the DOCTYPE or XML namespace or root element are, and that, to properl= y "sniff" them, you'd have to scan text. But before you scan text, you have= to determine charset. >> >> So if we're going to support sniffing of media types in general, I don't= see how we can do that without also specifying charset determination. >> >> >> >> Larry >> ] >> >> -----Original Message----- >> From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On >> Behalf Of Adam Barth >> Sent: Sunday, October 23, 2011 8:28 PM >> To: Tobias Gondrom >> Cc: websec@ietf.org >> Subject: Re: [websec] #22: content-type sniffing should include >> charset sniffing >> >> The charset sniffing is also complicated by the fact that sometimes user= agents need to parse some of the HTML to find a element. >> In some situations, user agents need to restart the parsing algorithm, w= hich is quite delicate and better to describe in the same document as HTML = parsing (at least for use by HTML processing engines). >> >> Adam >> >> >> On Sun, Oct 23, 2011 at 8:24 PM, Tobias Gondrom wrote: >>> >>> I tend not to agree with that. >>> >>> The fact that charset sniffing might happen at the same time as >>> mime-sniffing does not seem like a strong argument to include this in >>> the draft. >>> >>> Furthermore I would rather have these issues separate: >>> First you determine the content-type and then after that you may want >>> to determine the charset used within that content-type (if you really >>> have to sniff the charset). I can also imagine that charset sniffing >>> algorithm might be depending on the application identified by the >>> sniffed mime-type, which again would speak against throwing it in toget= her with mime-sniffing.... >>> >>> Kind regards, Tobias >>> >>> >>> >>> On 24/10/11 00:55, websec issue tracker wrote: >>>> >>>> #22: content-type sniffing should include charset sniffing >>>> >>>> =A0the HTML5 spec contains some algorithms for sniffing charset, >>>> overriding >>>> =A0labeled charset, etc. >>>> >>>> =A0MIME parameters like charset are as much a part of the content-type >>>> as the >>>> =A0base internet media type, and any sniffing of parameters and other >>>> =A0metadata (overriding content-type or guessing where it is not >>>> supplied or >>>> =A0wrong) should be included in this document, since the sniffing will >>>> happen >>>> =A0at the same time. >>>> >>> >>> _______________________________________________ >>> websec mailing list >>> websec@ietf.org >>> https://www.ietf.org/mailman/listinfo/websec >>> >> _______________________________________________ >> websec mailing list >> websec@ietf.org >> https://www.ietf.org/mailman/listinfo/websec >> > From masinter@adobe.com Sun Oct 23 23:12:45 2011 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 596DE21F8C1F for ; Sun, 23 Oct 2011 23:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.574 X-Spam-Level: X-Spam-Status: No, score=-106.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 ZSUYXNZC5zlV for ; Sun, 23 Oct 2011 23:12:44 -0700 (PDT) Received: from exprod6og111.obsmtp.com (exprod6og111.obsmtp.com [64.18.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 0362F21F8AF2 for ; Sun, 23 Oct 2011 23:12:43 -0700 (PDT) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob111.postini.com ([64.18.5.12]) with SMTP; Sun, 23 Oct 2011 23:12:44 PDT 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 p9O6CeBb014778 for ; Sun, 23 Oct 2011 23:12:41 -0700 (PDT) Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id p9O6CdLV018451 for ; Sun, 23 Oct 2011 23:12:40 -0700 (PDT) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nahub01.corp.adobe.com ([10.8.189.97]) with mapi; Sun, 23 Oct 2011 23:12:39 -0700 From: Larry Masinter To: "websec@ietf.org" Date: Sun, 23 Oct 2011 23:12:37 -0700 Thread-Topic: MIME sniffing test suite? Is there one? Thread-Index: AcySE+2oqo4DdAroTrKwcrMRm2XPDQ== 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] MIME sniffing test suite? Is there one? 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, 24 Oct 2011 06:12:45 -0000 I think it would be really helpful to have a test suite for MIME sniffing w= here we can test out what browsers do and various cases where sniffing *sho= uld* improve the experience, as well as test cases where sniffing makes thi= ngs worse, if there are some. Probably focusing on the test suite would help resolve some of the issues. I'm willing to help populate the test suite but perhaps someone could to pu= t up the infrastructure? Larry From duerst@it.aoyama.ac.jp Sun Oct 23 23:37:30 2011 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 154F611E8073 for ; Sun, 23 Oct 2011 23:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.926 X-Spam-Level: X-Spam-Status: No, score=-97.926 tagged_above=-999 required=5 tests=[AWL=-0.591, BAYES_00=-2.599, FRT_ADOBE2=2.455, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, 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 69NwDx+U05FW for ; Sun, 23 Oct 2011 23:37:29 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id C272721F8BEB for ; Sun, 23 Oct 2011 23:37:25 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id p9O6bGeV007753 for ; Mon, 24 Oct 2011 15:37:16 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 6016_7072_9d8b7562_fe0a_11e0_a78b_001d096c5782; Mon, 24 Oct 2011 15:37:16 +0900 Received: from [IPv6:::1] ([133.2.210.1]:40243) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 24 Oct 2011 15:37:16 +0900 Message-ID: <4EA5079B.9050700@it.aoyama.ac.jp> Date: Mon, 24 Oct 2011 15:37:15 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Larry Masinter References: <059.f8bc48a3163d95d888ee3a23a2ca7fb9@trac.tools.ietf.org> <4EA4DA67.3000502@gondrom.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "websec@ietf.org" Subject: Re: [websec] #22: content-type sniffing should include charset 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, 24 Oct 2011 06:37:30 -0000 I agree with Adam and Tobias that we should not pull all of charset sniffing into this document. Many charset details depend on the mime type in the first place, and are carefully described in the respective specs. For some transfer protocols, the question of charset may be irrelevant (e.g. for text over Websocket, which prescribes and checks for UTF-8). Larry is right that in some cases, some preliminary charset sniffing is necessary to get at some information at the start of the document, but I think we should strictly limit this draft to these cases. Regards, Martin. On 2011/10/24 13:14, Larry Masinter wrote: > I was talking about the necessary dependency of the specifications -- that you couldn't specify media type sniffing completely without making at least a normative reference to charset sniffing. > > The fact that the code works that way is evidence, of course, but we're not talking about possibility of implementation (where a single implementation is evidence) but rather orthogonality of interfaces (where the question is whether ALL implementations must follow this pattern.) > > Larry > > > > > -----Original Message----- > From: Adam Barth [mailto:ietf@adambarth.com] > Sent: Sunday, October 23, 2011 8:37 PM > To: Larry Masinter > Cc: Tobias Gondrom; websec@ietf.org > Subject: Re: [websec] #22: content-type sniffing should include charset sniffing > > I mean, that's how the code works, so it must be possible. :) > > Adam > > > On Sun, Oct 23, 2011 at 8:32 PM, Larry Masinter wrote: >> I know it's complicated, but scanning text is necessarily part of determining which application/something+xml you have. I think (but should really check before saying this) that XML media type registrations describe what the DOCTYPE or XML namespace or root element are, and that, to properly "sniff" them, you'd have to scan text. But before you scan text, you have to determine charset. >> >> So if we're going to support sniffing of media types in general, I don't see how we can do that without also specifying charset determination. >> >> >> >> Larry >> ] >> >> -----Original Message----- >> From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On >> Behalf Of Adam Barth >> Sent: Sunday, October 23, 2011 8:28 PM >> To: Tobias Gondrom >> Cc: websec@ietf.org >> Subject: Re: [websec] #22: content-type sniffing should include >> charset sniffing >> >> The charset sniffing is also complicated by the fact that sometimes user agents need to parse some of the HTML to find a element. >> In some situations, user agents need to restart the parsing algorithm, which is quite delicate and better to describe in the same document as HTML parsing (at least for use by HTML processing engines). >> >> Adam >> >> >> On Sun, Oct 23, 2011 at 8:24 PM, Tobias Gondrom wrote: >>> >>> I tend not to agree with that. >>> >>> The fact that charset sniffing might happen at the same time as >>> mime-sniffing does not seem like a strong argument to include this in >>> the draft. >>> >>> Furthermore I would rather have these issues separate: >>> First you determine the content-type and then after that you may want >>> to determine the charset used within that content-type (if you really >>> have to sniff the charset). I can also imagine that charset sniffing >>> algorithm might be depending on the application identified by the >>> sniffed mime-type, which again would speak against throwing it in together with mime-sniffing.... >>> >>> Kind regards, Tobias >>> >>> >>> >>> On 24/10/11 00:55, websec issue tracker wrote: >>>> >>>> #22: content-type sniffing should include charset sniffing >>>> >>>> the HTML5 spec contains some algorithms for sniffing charset, >>>> overriding >>>> labeled charset, etc. >>>> >>>> MIME parameters like charset are as much a part of the content-type >>>> as the >>>> base internet media type, and any sniffing of parameters and other >>>> metadata (overriding content-type or guessing where it is not >>>> supplied or >>>> wrong) should be included in this document, since the sniffing will >>>> happen >>>> at the same time. >>>> >>> >>> _______________________________________________ >>> websec mailing list >>> websec@ietf.org >>> https://www.ietf.org/mailman/listinfo/websec >>> >> _______________________________________________ >> websec mailing list >> websec@ietf.org >> https://www.ietf.org/mailman/listinfo/websec >> > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > From masinter@adobe.com Sun Oct 23 23:48:17 2011 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 164FB21F8C04 for ; Sun, 23 Oct 2011 23:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.949 X-Spam-Level: X-Spam-Status: No, score=-104.949 tagged_above=-999 required=5 tests=[AWL=-1.105, BAYES_00=-2.599, FRT_ADOBE2=2.455, MIME_8BIT_HEADER=0.3, 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 5NbWue3RAi8j for ; Sun, 23 Oct 2011 23:48:16 -0700 (PDT) Received: from exprod6og105.obsmtp.com (exprod6og105.obsmtp.com [64.18.1.189]) by ietfa.amsl.com (Postfix) with ESMTP id B2F1121F8BF8 for ; Sun, 23 Oct 2011 23:48:15 -0700 (PDT) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob105.postini.com ([64.18.5.12]) with SMTP; Sun, 23 Oct 2011 23:48:15 PDT Received: from inner-relay-1.corp.adobe.com (inner-relay-1.corp.adobe.com [153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id p9O6lpBb016859; Sun, 23 Oct 2011 23:47:52 -0700 (PDT) Received: from nacas03.corp.adobe.com (nacas03.corp.adobe.com [10.8.189.121]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id p9O6lo5R019441; Sun, 23 Oct 2011 23:47:50 -0700 (PDT) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas03.corp.adobe.com ([10.8.189.121]) with mapi; Sun, 23 Oct 2011 23:47:50 -0700 From: Larry Masinter To: =?utf-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Date: Sun, 23 Oct 2011 23:47:46 -0700 Thread-Topic: [websec] #22: content-type sniffing should include charset sniffing Thread-Index: AcySF2EOf5U4n/OxQXu2hasq7Bh0gQAAO3Yg Message-ID: References: <059.f8bc48a3163d95d888ee3a23a2ca7fb9@trac.tools.ietf.org> <4EA4DA67.3000502@gondrom.org> <4EA5079B.9050700@it.aoyama.ac.jp> In-Reply-To: <4EA5079B.9050700@it.aoyama.ac.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "websec@ietf.org" Subject: Re: [websec] #22: content-type sniffing should include charset 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, 24 Oct 2011 06:48:17 -0000 VGhlIGNoYXJzZXQgc25pZmZpbmcgZG9jdW1lbnRhdGlvbiBpbiB0aGUgSFRNTDUgZG9jdW1lbnQg aXNuJ3QgYWxsIHRoYXQgY29tcGxpY2F0ZWQsIGFueXdheS4gDQoNCkFuZCBpdCBoYXMgdG8gYmUg c29tZXdoZXJlLiANCg0KV2hhdCdzIHRoZSBwb2ludCBvZiBzdGFuZGFyZGl6aW5nIHNuaWZmaW5n IG9mIHRoZSBpbnRlcm5ldCBtZWRpYSB0eXBlIHdpdGhvdXQgYWxzbyBzdGFuZGFyZGl6aW5nIHRo ZSBzbmlmZmluZyBvZiBhbGwgb2YgdGhlIHJlbGV2YW50IHBhcmFtZXRlcnMuLi4uIHRoZSBnb2Fs IGlzIHRvIHNuaWZmIHRoZSBjb250ZW50LXR5cGUsIHRoZSBtZWRpYSB0eXBlIGJ5IGl0c2VsZiBp c24ndCB3aGF0J3MgdXNlZC4NCkl0J3MganVzdCBmb3IgdGV4dCBhbmQgeG1sIHR5cGVzLCB0aGUg J2NoYXJzZXQnIHBhcmFtZXRlciBpcyBhbHJlYWR5IHRoZXJlLg0KDQpBbHNvLCB0aGUgYWxnb3Jp dGhtIGluIHRoZSBkb2N1bWVudCBjdXJyZW50bHkgaXMgaW5jb21wbGV0ZSBhbmQgaW5hcHByb3By aWF0ZSBpZiB5b3UncmUgZ29pbmcgdG8gc25pZmYgWE1MLWJhc2VkIG1lZGlhIHR5cGVzLCBzbyB0 aGUgZmFjdCB0aGF0IHRoZSBjdXJyZW50IGFsZ29yaXRobSBjYW4gZ2V0IGF3YXkgd2l0aCBoaWRp bmcgImNoYXJzZXQgZ3Vlc3NpbmciIGFzIGlmIGl0IHdlcmUganVzdCBvbiBvY3RldHMgYW5kIG5v dCB0aGUgY2hhcmFjdGVycyAtLSB3ZWxsLCB0aGF0J3MganVzdCBhIHN1cGVyZmljaWFsIHdvcmst YXJvdW5kLg0KDQpMYXJyeQ0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiAi TWFydGluIEouIETDvHJzdCIgW21haWx0bzpkdWVyc3RAaXQuYW95YW1hLmFjLmpwXSANClNlbnQ6 IFN1bmRheSwgT2N0b2JlciAyMywgMjAxMSAxMTozNyBQTQ0KVG86IExhcnJ5IE1hc2ludGVyDQpD YzogQWRhbSBCYXJ0aDsgd2Vic2VjQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3dlYnNlY10gIzIy OiBjb250ZW50LXR5cGUgc25pZmZpbmcgc2hvdWxkIGluY2x1ZGUgY2hhcnNldCBzbmlmZmluZw0K DQpJIGFncmVlIHdpdGggQWRhbSBhbmQgVG9iaWFzIHRoYXQgd2Ugc2hvdWxkIG5vdCBwdWxsIGFs bCBvZiBjaGFyc2V0IHNuaWZmaW5nIGludG8gdGhpcyBkb2N1bWVudC4gTWFueSBjaGFyc2V0IGRl dGFpbHMgZGVwZW5kIG9uIHRoZSBtaW1lIHR5cGUgaW4gdGhlIGZpcnN0IHBsYWNlLCBhbmQgYXJl IGNhcmVmdWxseSBkZXNjcmliZWQgaW4gdGhlIHJlc3BlY3RpdmUgc3BlY3MuIEZvciBzb21lIHRy YW5zZmVyIHByb3RvY29scywgdGhlIHF1ZXN0aW9uIG9mIGNoYXJzZXQgbWF5IGJlIGlycmVsZXZh bnQgKGUuZy4gZm9yIHRleHQgb3ZlciBXZWJzb2NrZXQsIHdoaWNoIHByZXNjcmliZXMgYW5kIGNo ZWNrcyBmb3IgVVRGLTgpLg0KDQpMYXJyeSBpcyByaWdodCB0aGF0IGluIHNvbWUgY2FzZXMsIHNv bWUgcHJlbGltaW5hcnkgY2hhcnNldCBzbmlmZmluZyBpcyBuZWNlc3NhcnkgdG8gZ2V0IGF0IHNv bWUgaW5mb3JtYXRpb24gYXQgdGhlIHN0YXJ0IG9mIHRoZSBkb2N1bWVudCwgYnV0IEkgdGhpbmsg d2Ugc2hvdWxkIHN0cmljdGx5IGxpbWl0IHRoaXMgZHJhZnQgdG8gdGhlc2UgY2FzZXMuDQoNClJl Z2FyZHMsICAgIE1hcnRpbi4NCg0KT24gMjAxMS8xMC8yNCAxMzoxNCwgTGFycnkgTWFzaW50ZXIg d3JvdGU6DQo+IEkgd2FzIHRhbGtpbmcgYWJvdXQgdGhlIG5lY2Vzc2FyeSBkZXBlbmRlbmN5IG9m IHRoZSBzcGVjaWZpY2F0aW9ucyAtLSB0aGF0IHlvdSBjb3VsZG4ndCBzcGVjaWZ5IG1lZGlhIHR5 cGUgc25pZmZpbmcgY29tcGxldGVseSB3aXRob3V0IG1ha2luZyBhdCBsZWFzdCBhIG5vcm1hdGl2 ZSByZWZlcmVuY2UgdG8gY2hhcnNldCBzbmlmZmluZy4NCj4NCj4gVGhlIGZhY3QgdGhhdCB0aGUg Y29kZSB3b3JrcyB0aGF0IHdheSBpcyBldmlkZW5jZSwgb2YgY291cnNlLCBidXQgDQo+IHdlJ3Jl IG5vdCB0YWxraW5nIGFib3V0IHBvc3NpYmlsaXR5IG9mIGltcGxlbWVudGF0aW9uICh3aGVyZSBh IHNpbmdsZSANCj4gaW1wbGVtZW50YXRpb24gaXMgZXZpZGVuY2UpIGJ1dCByYXRoZXIgb3J0aG9n b25hbGl0eSBvZiBpbnRlcmZhY2VzIA0KPiAod2hlcmUgdGhlIHF1ZXN0aW9uIGlzIHdoZXRoZXIg QUxMIGltcGxlbWVudGF0aW9ucyBtdXN0IGZvbGxvdyB0aGlzIA0KPiBwYXR0ZXJuLikNCj4NCj4g TGFycnkNCj4NCj4NCj4NCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog QWRhbSBCYXJ0aCBbbWFpbHRvOmlldGZAYWRhbWJhcnRoLmNvbV0NCj4gU2VudDogU3VuZGF5LCBP Y3RvYmVyIDIzLCAyMDExIDg6MzcgUE0NCj4gVG86IExhcnJ5IE1hc2ludGVyDQo+IENjOiBUb2Jp YXMgR29uZHJvbTsgd2Vic2VjQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbd2Vic2VjXSAjMjI6 IGNvbnRlbnQtdHlwZSBzbmlmZmluZyBzaG91bGQgaW5jbHVkZSANCj4gY2hhcnNldCBzbmlmZmlu Zw0KPg0KPiBJIG1lYW4sIHRoYXQncyBob3cgdGhlIGNvZGUgd29ya3MsIHNvIGl0IG11c3QgYmUg cG9zc2libGUuICA6KQ0KPg0KPiBBZGFtDQo+DQo+DQo+IE9uIFN1biwgT2N0IDIzLCAyMDExIGF0 IDg6MzIgUE0sIExhcnJ5IE1hc2ludGVyPG1hc2ludGVyQGFkb2JlLmNvbT4gIHdyb3RlOg0KPj4g SSBrbm93IGl0J3MgY29tcGxpY2F0ZWQsIGJ1dCBzY2FubmluZyB0ZXh0IGlzIG5lY2Vzc2FyaWx5 IHBhcnQgb2YgZGV0ZXJtaW5pbmcgd2hpY2ggYXBwbGljYXRpb24vc29tZXRoaW5nK3htbCAgeW91 IGhhdmUuICBJIHRoaW5rIChidXQgc2hvdWxkIHJlYWxseSBjaGVjayBiZWZvcmUgc2F5aW5nIHRo aXMpIHRoYXQgWE1MIG1lZGlhIHR5cGUgcmVnaXN0cmF0aW9ucyBkZXNjcmliZSB3aGF0IHRoZSBE T0NUWVBFIG9yIFhNTCBuYW1lc3BhY2Ugb3Igcm9vdCBlbGVtZW50IGFyZSwgYW5kIHRoYXQsIHRv IHByb3Blcmx5ICJzbmlmZiIgdGhlbSwgeW91J2QgaGF2ZSB0byBzY2FuIHRleHQuIEJ1dCBiZWZv cmUgeW91IHNjYW4gdGV4dCwgeW91IGhhdmUgdG8gZGV0ZXJtaW5lIGNoYXJzZXQuDQo+Pg0KPj4g U28gaWYgd2UncmUgZ29pbmcgdG8gc3VwcG9ydCBzbmlmZmluZyBvZiBtZWRpYSB0eXBlcyBpbiBn ZW5lcmFsLCBJIGRvbid0IHNlZSBob3cgd2UgY2FuIGRvIHRoYXQgd2l0aG91dCBhbHNvIHNwZWNp ZnlpbmcgY2hhcnNldCBkZXRlcm1pbmF0aW9uLg0KPj4NCj4+DQo+Pg0KPj4gTGFycnkNCj4+IF0N Cj4+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogd2Vic2VjLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzp3ZWJzZWMtYm91bmNlc0BpZXRmLm9yZ10gT24gDQo+PiBCZWhh bGYgT2YgQWRhbSBCYXJ0aA0KPj4gU2VudDogU3VuZGF5LCBPY3RvYmVyIDIzLCAyMDExIDg6Mjgg UE0NCj4+IFRvOiBUb2JpYXMgR29uZHJvbQ0KPj4gQ2M6IHdlYnNlY0BpZXRmLm9yZw0KPj4gU3Vi amVjdDogUmU6IFt3ZWJzZWNdICMyMjogY29udGVudC10eXBlIHNuaWZmaW5nIHNob3VsZCBpbmNs dWRlIA0KPj4gY2hhcnNldCBzbmlmZmluZw0KPj4NCj4+IFRoZSBjaGFyc2V0IHNuaWZmaW5nIGlz IGFsc28gY29tcGxpY2F0ZWQgYnkgdGhlIGZhY3QgdGhhdCBzb21ldGltZXMgdXNlciBhZ2VudHMg bmVlZCB0byBwYXJzZSBzb21lIG9mIHRoZSBIVE1MIHRvIGZpbmQgYTxtZXRhPiAgZWxlbWVudC4N Cj4+IEluIHNvbWUgc2l0dWF0aW9ucywgdXNlciBhZ2VudHMgbmVlZCB0byByZXN0YXJ0IHRoZSBw YXJzaW5nIGFsZ29yaXRobSwgd2hpY2ggaXMgcXVpdGUgZGVsaWNhdGUgYW5kIGJldHRlciB0byBk ZXNjcmliZSBpbiB0aGUgc2FtZSBkb2N1bWVudCBhcyBIVE1MIHBhcnNpbmcgKGF0IGxlYXN0IGZv ciB1c2UgYnkgSFRNTCBwcm9jZXNzaW5nIGVuZ2luZXMpLg0KPj4NCj4+IEFkYW0NCj4+DQo+Pg0K Pj4gT24gU3VuLCBPY3QgMjMsIDIwMTEgYXQgODoyNCBQTSwgVG9iaWFzIEdvbmRyb208dG9iaWFz LmdvbmRyb21AZ29uZHJvbS5vcmc+ICB3cm90ZToNCj4+PiA8aGF0PSJpbmRpdmlkdWFsIj4NCj4+ PiBJIHRlbmQgbm90IHRvIGFncmVlIHdpdGggdGhhdC4NCj4+Pg0KPj4+IFRoZSBmYWN0IHRoYXQg Y2hhcnNldCBzbmlmZmluZyBtaWdodCBoYXBwZW4gYXQgdGhlIHNhbWUgdGltZSBhcyANCj4+PiBt aW1lLXNuaWZmaW5nIGRvZXMgbm90IHNlZW0gbGlrZSBhIHN0cm9uZyBhcmd1bWVudCB0byBpbmNs dWRlIHRoaXMgDQo+Pj4gaW4gdGhlIGRyYWZ0Lg0KPj4+DQo+Pj4gRnVydGhlcm1vcmUgSSB3b3Vs ZCByYXRoZXIgaGF2ZSB0aGVzZSBpc3N1ZXMgc2VwYXJhdGU6DQo+Pj4gRmlyc3QgeW91IGRldGVy bWluZSB0aGUgY29udGVudC10eXBlIGFuZCB0aGVuIGFmdGVyIHRoYXQgeW91IG1heSANCj4+PiB3 YW50IHRvIGRldGVybWluZSB0aGUgY2hhcnNldCB1c2VkIHdpdGhpbiB0aGF0IGNvbnRlbnQtdHlw ZSAoaWYgeW91IA0KPj4+IHJlYWxseSBoYXZlIHRvIHNuaWZmIHRoZSBjaGFyc2V0KS4gSSBjYW4g YWxzbyBpbWFnaW5lIHRoYXQgY2hhcnNldCANCj4+PiBzbmlmZmluZyBhbGdvcml0aG0gbWlnaHQg YmUgZGVwZW5kaW5nIG9uIHRoZSBhcHBsaWNhdGlvbiBpZGVudGlmaWVkIA0KPj4+IGJ5IHRoZSBz bmlmZmVkIG1pbWUtdHlwZSwgd2hpY2ggYWdhaW4gd291bGQgc3BlYWsgYWdhaW5zdCB0aHJvd2lu ZyBpdCBpbiB0b2dldGhlciB3aXRoIG1pbWUtc25pZmZpbmcuLi4uDQo+Pj4NCj4+PiBLaW5kIHJl Z2FyZHMsIFRvYmlhcw0KPj4+DQo+Pj4NCj4+Pg0KPj4+IE9uIDI0LzEwLzExIDAwOjU1LCB3ZWJz ZWMgaXNzdWUgdHJhY2tlciB3cm90ZToNCj4+Pj4NCj4+Pj4gIzIyOiBjb250ZW50LXR5cGUgc25p ZmZpbmcgc2hvdWxkIGluY2x1ZGUgY2hhcnNldCBzbmlmZmluZw0KPj4+Pg0KPj4+PiAgIHRoZSBI VE1MNSBzcGVjIGNvbnRhaW5zIHNvbWUgYWxnb3JpdGhtcyBmb3Igc25pZmZpbmcgY2hhcnNldCwg DQo+Pj4+IG92ZXJyaWRpbmcNCj4+Pj4gICBsYWJlbGVkIGNoYXJzZXQsIGV0Yy4NCj4+Pj4NCj4+ Pj4gICBNSU1FIHBhcmFtZXRlcnMgbGlrZSBjaGFyc2V0IGFyZSBhcyBtdWNoIGEgcGFydCBvZiB0 aGUgDQo+Pj4+IGNvbnRlbnQtdHlwZSBhcyB0aGUNCj4+Pj4gICBiYXNlIGludGVybmV0IG1lZGlh IHR5cGUsIGFuZCBhbnkgc25pZmZpbmcgb2YgcGFyYW1ldGVycyBhbmQgb3RoZXINCj4+Pj4gICBt ZXRhZGF0YSAob3ZlcnJpZGluZyBjb250ZW50LXR5cGUgb3IgZ3Vlc3Npbmcgd2hlcmUgaXQgaXMg bm90IA0KPj4+PiBzdXBwbGllZCBvcg0KPj4+PiAgIHdyb25nKSBzaG91bGQgYmUgaW5jbHVkZWQg aW4gdGhpcyBkb2N1bWVudCwgc2luY2UgdGhlIHNuaWZmaW5nIA0KPj4+PiB3aWxsIGhhcHBlbg0K Pj4+PiAgIGF0IHRoZSBzYW1lIHRpbWUuDQo+Pj4+DQo+Pj4NCj4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IHdlYnNlYyBtYWlsaW5nIGxpc3QN Cj4+PiB3ZWJzZWNAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3dlYnNlYw0KPj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4gd2Vic2VjIG1haWxpbmcgbGlzdA0KPj4gd2Vic2VjQGlldGYub3Jn DQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3dlYnNlYw0KPj4NCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gd2Vic2Vj IG1haWxpbmcgbGlzdA0KPiB3ZWJzZWNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby93ZWJzZWMNCj4NCg== From tobias.gondrom@gondrom.org Mon Oct 24 00:08:06 2011 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 C24FD21F8B4F for ; Mon, 24 Oct 2011 00:08:06 -0700 (PDT) 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 1brX4BGuXnzF for ; Mon, 24 Oct 2011 00:08:05 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id 53AE521F877F for ; Mon, 24 Oct 2011 00:08:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=icFmAp/vHOigRvNVgfQYVgbni44csmaH08CZtsUngXv7wM+mKHJRP3nM4KR57YiIyGQdemjPVgdRmdDRyqeZib91/2w+LYyFLlKTxuTPbaxusR0gHFCn/SEl6IliavWy; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 26364 invoked from network); 24 Oct 2011 09:07:06 +0200 Received: from unknown (HELO ?10.5.5.61?) (61.8.220.69) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 24 Oct 2011 09:07:06 +0200 Message-ID: <4EA50E9A.60407@gondrom.org> Date: Mon, 24 Oct 2011 08:07:06 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110923 Thunderbird/7.0 MIME-Version: 1.0 To: websec@ietf.org References: <059.f8bc48a3163d95d888ee3a23a2ca7fb9@trac.tools.ietf.org> <4EA4DA67.3000502@gondrom.org> <4EA5079B.9050700@it.aoyama.ac.jp> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [websec] #22: content-type sniffing should include charset 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, 24 Oct 2011 07:08:06 -0000 Well, I don't feel that looking at the octets aka magic numbers is a "superficial work-around", rather find it a reasonable argument. Personally, I don't think we need to go into charset-sniffing in the draft, but if you can make it an uncomplicated sub-set of some of the content-types, it probably won't harm. However, I have some doubts that we can limit the extend of charset-sniffing to a small area in the draft as discussed and may not end up with a whole other set of additional problems.... - in which case I would rather like to see the content-type sniffed and talk about charset-sniffing in another draft - if we want to go there... just my 5cents, Tobias On 24/10/11 07:47, Larry Masinter wrote: > The charset sniffing documentation in the HTML5 document isn't all that complicated, anyway. > > And it has to be somewhere. > > What's the point of standardizing sniffing of the internet media type without also standardizing the sniffing of all of the relevant parameters.... the goal is to sniff the content-type, the media type by itself isn't what's used. > It's just for text and xml types, the 'charset' parameter is already there. > > Also, the algorithm in the document currently is incomplete and inappropriate if you're going to sniff XML-based media types, so the fact that the current algorithm can get away with hiding "charset guessing" as if it were just on octets and not the characters -- well, that's just a superficial work-around. > > Larry > > > -----Original Message----- > From: "Martin J. Dürst" [mailto:duerst@it.aoyama.ac.jp] > Sent: Sunday, October 23, 2011 11:37 PM > To: Larry Masinter > Cc: Adam Barth; websec@ietf.org > Subject: Re: [websec] #22: content-type sniffing should include charset sniffing > > I agree with Adam and Tobias that we should not pull all of charset sniffing into this document. Many charset details depend on the mime type in the first place, and are carefully described in the respective specs. For some transfer protocols, the question of charset may be irrelevant (e.g. for text over Websocket, which prescribes and checks for UTF-8). > > Larry is right that in some cases, some preliminary charset sniffing is necessary to get at some information at the start of the document, but I think we should strictly limit this draft to these cases. > > Regards, Martin. > > On 2011/10/24 13:14, Larry Masinter wrote: >> I was talking about the necessary dependency of the specifications -- that you couldn't specify media type sniffing completely without making at least a normative reference to charset sniffing. >> >> The fact that the code works that way is evidence, of course, but >> we're not talking about possibility of implementation (where a single >> implementation is evidence) but rather orthogonality of interfaces >> (where the question is whether ALL implementations must follow this >> pattern.) >> >> Larry >> >> >> >> >> -----Original Message----- >> From: Adam Barth [mailto:ietf@adambarth.com] >> Sent: Sunday, October 23, 2011 8:37 PM >> To: Larry Masinter >> Cc: Tobias Gondrom; websec@ietf.org >> Subject: Re: [websec] #22: content-type sniffing should include >> charset sniffing >> >> I mean, that's how the code works, so it must be possible. :) >> >> Adam >> >> >> On Sun, Oct 23, 2011 at 8:32 PM, Larry Masinter wrote: >>> I know it's complicated, but scanning text is necessarily part of determining which application/something+xml you have. I think (but should really check before saying this) that XML media type registrations describe what the DOCTYPE or XML namespace or root element are, and that, to properly "sniff" them, you'd have to scan text. But before you scan text, you have to determine charset. >>> >>> So if we're going to support sniffing of media types in general, I don't see how we can do that without also specifying charset determination. >>> >>> >>> >>> Larry >>> ] >>> >>> -----Original Message----- >>> From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On >>> Behalf Of Adam Barth >>> Sent: Sunday, October 23, 2011 8:28 PM >>> To: Tobias Gondrom >>> Cc: websec@ietf.org >>> Subject: Re: [websec] #22: content-type sniffing should include >>> charset sniffing >>> >>> The charset sniffing is also complicated by the fact that sometimes user agents need to parse some of the HTML to find a element. >>> In some situations, user agents need to restart the parsing algorithm, which is quite delicate and better to describe in the same document as HTML parsing (at least for use by HTML processing engines). >>> >>> Adam >>> >>> >>> On Sun, Oct 23, 2011 at 8:24 PM, Tobias Gondrom wrote: >>>> >>>> I tend not to agree with that. >>>> >>>> The fact that charset sniffing might happen at the same time as >>>> mime-sniffing does not seem like a strong argument to include this >>>> in the draft. >>>> >>>> Furthermore I would rather have these issues separate: >>>> First you determine the content-type and then after that you may >>>> want to determine the charset used within that content-type (if you >>>> really have to sniff the charset). I can also imagine that charset >>>> sniffing algorithm might be depending on the application identified >>>> by the sniffed mime-type, which again would speak against throwing it in together with mime-sniffing.... >>>> >>>> Kind regards, Tobias >>>> >>>> >>>> >>>> On 24/10/11 00:55, websec issue tracker wrote: >>>>> #22: content-type sniffing should include charset sniffing >>>>> >>>>> the HTML5 spec contains some algorithms for sniffing charset, >>>>> overriding >>>>> labeled charset, etc. >>>>> >>>>> MIME parameters like charset are as much a part of the >>>>> content-type as the >>>>> base internet media type, and any sniffing of parameters and other >>>>> metadata (overriding content-type or guessing where it is not >>>>> supplied or >>>>> wrong) should be included in this document, since the sniffing >>>>> will happen >>>>> at the same time. >>>>> >>>> _______________________________________________ >>>> websec mailing list >>>> websec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/websec >>>> >>> _______________________________________________ >>> websec mailing list >>> websec@ietf.org >>> https://www.ietf.org/mailman/listinfo/websec >>> >> _______________________________________________ >> websec mailing list >> websec@ietf.org >> https://www.ietf.org/mailman/listinfo/websec >> > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From tobias.gondrom@gondrom.org Mon Oct 24 01:18:27 2011 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 D528D21F8C07 for ; Mon, 24 Oct 2011 01:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.532 X-Spam-Level: X-Spam-Status: No, score=-96.532 tagged_above=-999 required=5 tests=[AWL=0.246, 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 cxw3qHDsiogE for ; Mon, 24 Oct 2011 01:18:27 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id 93D3321F8B1C for ; Mon, 24 Oct 2011 01:18:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=hKXXOmiKrcA/l6Ow0K8bnydcglWG8kRuJUDBhxwY2PbjEMUutBL1hoz3CPBoc5gk1osgoszVwK2l4L7mvN6mCg7+9WL1xi2AiMSbJ/xucqFVzU+ZHBng15k+UOGeaPNm; 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 26598 invoked from network); 24 Oct 2011 10:17:22 +0200 Received: from unknown (HELO ?10.5.5.61?) (61.8.220.69) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 24 Oct 2011 10:17:22 +0200 Message-ID: <4EA51F11.7090504@gondrom.org> Date: Mon, 24 Oct 2011 09:17:21 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110923 Thunderbird/7.0 MIME-Version: 1.0 To: masinter@adobe.com References: <059.38de41cc08d30327b007c754bc555885@trac.tools.ietf.org> <4EA4D547.4030805@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] #19: Do not sniff PDF 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, 24 Oct 2011 08:18:28 -0000 On 24/10/11 04:21, Larry Masinter wrote: >> - in which way is it more certain that there is no mislabeled PDF than a mislabeled jpg or mislabeled rtf? > I don't think this is relevant. There is likely mislabeled PDF. But I had specific feedback from implementors of PDF readers that sniffing from other content-type resulted in a worse situation than not sniffing. I don't have any information on jpg or rtf. > > Sniffing should only be done when it is justified by an improved user experience over not sniffing. Fine by me. The browsers and OS started sniffing for exactly that reason in the first place, to improve user experience. The reason why I am asking so specifically about the reasons for not doing PDF sniffing is the following: In general I can imagine a number of scenarios where sniffing is disadvantageous (i.e. leads to security risks) for certain file types. The main threat with sniffing is it leads to false-positives being thrown into the application. Yet, it seems the browser vendors do so anyway.... - Which led us do this draft in the first place. If we exclude one specific file-type from sniffing, there are two interesting points: 1. we should have a compelling explanation for the browsers/OS not to do so, so they will follow the RFC. 2. these reasons may likely also be true for other file-types. So looking at them, we might deduce that they hold true for other content-types as well. Which again would be very useful information. > > I think the obligation of evidence is "opt in": we should only sniff content when there is evidence of mislabeled content for which sniffing actually improves something, and the improvement outweighs other considerations. > >> - what about scenarios in which there is no content-type (e.g. ftp, filesystem), should in this case sniffing not be done? > I didn't get any feedback on that. I don't know any workflows where valid PDF doesn't carry a file type label somehow (if only the file extension .pdf), so maybe sniffing based on file content itself doesn't matter. > > ((Maybe this is another issue? I just wonder if the algorithm for "no content-type" is the same, needs to be the same, as the algorithm for "content-type via HTTP".) I can imagine that the cases "no content-type given" and "wrong content-type given" could be treated differently, but I am not sure about it. > > > > > Larry > From julian.reschke@gmx.de Mon Oct 24 01:24:50 2011 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 4291921F8C7C for ; Mon, 24 Oct 2011 01:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.759 X-Spam-Level: X-Spam-Status: No, score=-103.759 tagged_above=-999 required=5 tests=[AWL=-1.160, 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 eIJuBbW2LMNx for ; Mon, 24 Oct 2011 01:24:49 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 0725621F8C78 for ; Mon, 24 Oct 2011 01:24:48 -0700 (PDT) Received: (qmail invoked by alias); 24 Oct 2011 08:24:45 -0000 Received: from p5DCC3E65.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.62.101] by mail.gmx.net (mp020) with SMTP; 24 Oct 2011 10:24:45 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/zLbx90OTzCZFjE4EMJF0VewO8o1MdA71Kg8pHzh GwVpf+2ynVNEia Message-ID: <4EA520CA.9070700@gmx.de> Date: Mon, 24 Oct 2011 10:24:42 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Tobias Gondrom References: <059.38de41cc08d30327b007c754bc555885@trac.tools.ietf.org> <4EA4D547.4030805@gondrom.org> <4EA51F11.7090504@gondrom.org> In-Reply-To: <4EA51F11.7090504@gondrom.org> 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] #19: Do not sniff PDF 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, 24 Oct 2011 08:24:50 -0000 On 2011-10-24 10:17, Tobias Gondrom wrote: > ... >> ((Maybe this is another issue? I just wonder if the algorithm for "no >> content-type" is the same, needs to be the same, as the algorithm for >> "content-type via HTTP".) > > I can imagine that the cases "no content-type given" and "wrong > content-type given" could be treated differently, but I am not sure > about it. > ... If you can define "wrong content-type" :-) From tobias.gondrom@gondrom.org Mon Oct 24 02:00:42 2011 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 283D421F8CB4 for ; Mon, 24 Oct 2011 02:00:42 -0700 (PDT) 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 e1Ou9TGEd9dB for ; Mon, 24 Oct 2011 02:00:41 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id 0D53621F8CAB for ; Mon, 24 Oct 2011 02:00:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=HLOAh0L1zzCstYDrwomTi/GkAdKlOelwSsyv+lJIbbAvxi09jwcZnGtR5Bdy6/3O2QPAs+dwjD2pcJh2D0oyFXLXyw+5q6Qzp17QKTsOZtoLfGoYuXyEnIaDEVl8vYGj; 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 28141 invoked from network); 24 Oct 2011 10:59:40 +0200 Received: from unknown (HELO ?10.5.5.61?) (61.8.220.69) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 24 Oct 2011 10:59:40 +0200 Message-ID: <4EA528FB.7060307@gondrom.org> Date: Mon, 24 Oct 2011 09:59:39 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110923 Thunderbird/7.0 MIME-Version: 1.0 To: websec@ietf.org X-Priority: 4 (Low) References: <067.0c626f20ba70069d5bffe870f0af308a@trac.tools.ietf.org> <082.069f7d2344511f067aa27b9de70dacc6@trac.tools.ietf.org> In-Reply-To: <082.069f7d2344511f067aa27b9de70dacc6@trac.tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [websec] #16: lack of explanatory text and no justifications for the normative language 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, 24 Oct 2011 09:00:42 -0000 On 22/10/11 19:47, websec issue tracker wrote: > #16: lack of explanatory text and no justifications for the normative language > > > Comment (by ietf@…): > > There's a lot of discussion of the rationale in this document: > > http://www.adambarth.com/papers/2009/barth-caballero-song.pdf > > I'm not opposed to importing that information into this document. > good idea. - Tobias From annevk@opera.com Mon Oct 24 02:09:47 2011 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 2FABB21F8CC1 for ; Mon, 24 Oct 2011 02:09:47 -0700 (PDT) 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 E4jp3pq0g4kT for ; Mon, 24 Oct 2011 02:09:46 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 209C521F8CB8 for ; Mon, 24 Oct 2011 02:09:43 -0700 (PDT) Received: from annevk-macbookpro.local (EM114-48-14-90.pool.e-mobile.ne.jp [114.48.14.90]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p9O99WMg021956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 24 Oct 2011 09:09:39 GMT Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: websec@ietf.org, "Tobias Gondrom" References: <4EA4D8B8.7010108@gondrom.org> Date: Mon, 24 Oct 2011 18:09:34 +0900 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Anne van Kesteren" Organization: Opera Software Message-ID: In-Reply-To: <4EA4D8B8.7010108@gondrom.org> User-Agent: Opera Mail/11.51 (MacIntel) Subject: Re: [websec] font 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, 24 Oct 2011 09:09:47 -0000 On Mon, 24 Oct 2011 12:17:12 +0900, Tobias Gondrom wrote: > I have a question regarding font sniffing: > Besides the short discussion at the last meetings, I do not recall much > interest for that on the mailing-list. So, I am not sure how much > interests really exists for the working group to be addressing that? > (i.e. adding content-types for fonts and adding them to the mime-sniff > draft...) > Am I mistaken? It is not so much about interest I think. If implementations sniff for fonts, it should be defined how they are to go about that. -- Anne van Kesteren http://annevankesteren.nl/ From tobias.gondrom@gondrom.org Mon Oct 24 02:14:48 2011 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 B7ADE21F8C13 for ; Mon, 24 Oct 2011 02:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.602 X-Spam-Level: X-Spam-Status: No, score=-96.602 tagged_above=-999 required=5 tests=[AWL=0.175, 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, HTML_MESSAGE=0.001, 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 1R6ohv4Tov3I for ; Mon, 24 Oct 2011 02:14:48 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id EAE1A21F8AF2 for ; Mon, 24 Oct 2011 02:14:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=hvtEz1QSNqpOsBDQ6eXXhS/Rm6y9kL/4k7UkvN0tgIb8NbSyURLlrH+Gl4GBX0JIAE/9+2c7i0KDHSkcbTvOftQzYRXBvU+vUqcwO/sE+es703/4R47kkswf2XAFwJoy; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type; Received: (qmail 28303 invoked from network); 24 Oct 2011 11:13:46 +0200 Received: from unknown (HELO ?10.5.5.61?) (61.8.220.69) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 24 Oct 2011 11:13:46 +0200 Message-ID: <4EA52C49.1090308@gondrom.org> Date: Mon, 24 Oct 2011 10:13:45 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110923 Thunderbird/7.0 MIME-Version: 1.0 To: annevk@opera.com References: <4EA4D8B8.7010108@gondrom.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010604010702090508030700" Cc: websec@ietf.org Subject: Re: [websec] font 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, 24 Oct 2011 09:14:48 -0000 This is a multi-part message in MIME format. --------------010604010702090508030700 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 24/10/11 10:09, Anne van Kesteren wrote: > On Mon, 24 Oct 2011 12:17:12 +0900, Tobias Gondrom > wrote: >> I have a question regarding font sniffing: >> Besides the short discussion at the last meetings, I do not recall much >> interest for that on the mailing-list. So, I am not sure how much >> interests really exists for the working group to be addressing that? >> (i.e. adding content-types for fonts and adding them to the mime-sniff >> draft...) >> Am I mistaken? > > It is not so much about interest I think. If implementations sniff for > fonts, it should be defined how they are to go about that. > > Thanks for the reply. Well, AFAIK we don't even have a content-type for fonts in the IANA registry at the moment? So my - maybe naive - question would be, do implementations sniff for fonts and why did they not ask for a content-type? Tobias --------------010604010702090508030700 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit On 24/10/11 10:09, Anne van Kesteren wrote:
On Mon, 24 Oct 2011 12:17:12 +0900, Tobias Gondrom <tobias.gondrom@gondrom.org> wrote:
I have a question regarding font sniffing:
Besides the short discussion at the last meetings, I do not recall much
interest for that on the mailing-list. So, I am not sure how much
interests really exists for the working group to be addressing that?
(i.e. adding content-types for fonts and adding them to the mime-sniff
draft...)
Am I mistaken?

It is not so much about interest I think. If implementations sniff for fonts, it should be defined how they are to go about that.



Thanks for the reply.

Well, AFAIK we don't even have a content-type for fonts in the IANA registry at the moment?
So my - maybe naive - question would be, do implementations sniff for fonts and why did they not ask for a content-type?

Tobias
 --------------010604010702090508030700-- From annevk@opera.com Mon Oct 24 02:23:33 2011 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 9F32621F8C1F for ; Mon, 24 Oct 2011 02:23:33 -0700 (PDT) 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 WHObO3L+cyno for ; Mon, 24 Oct 2011 02:23:33 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 7464821F8C13 for ; Mon, 24 Oct 2011 02:23:32 -0700 (PDT) Received: from annevk-macbookpro.local (EM114-48-14-90.pool.e-mobile.ne.jp [114.48.14.90]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p9O9Mg5g025468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 24 Oct 2011 09:23:26 GMT Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Tobias Gondrom" References: <4EA4D8B8.7010108@gondrom.org> <4EA52C49.1090308@gondrom.org> Date: Mon, 24 Oct 2011 18:22:41 +0900 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Anne van Kesteren" Organization: Opera Software Message-ID: In-Reply-To: <4EA52C49.1090308@gondrom.org> User-Agent: Opera Mail/11.51 (MacIntel) Cc: websec@ietf.org Subject: Re: [websec] font 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, 24 Oct 2011 09:23:33 -0000 On Mon, 24 Oct 2011 18:13:45 +0900, Tobias Gondrom wrote: > Thanks for the reply. > > Well, AFAIK we don't even have a content-type for fonts in the IANA > registry at the moment? Could be. I have not checked recently. MIME types for fonts are pointless now. > So my - maybe naive - question would be, do implementations sniff for > fonts and why did they not ask for a content-type? Adding support for fonts to browsers went much quicker than getting font/* from the IETF (I and some others tried doing that, maybe not in the right way though), and once browsers shipped with font support I stopped caring, because we would have to sniff forever anyway. But who is at fault is not what we are interested in here I think. We are interested in defining when implementations have to sniff. They very much have to sniff for fonts. -- Anne van Kesteren http://annevankesteren.nl/ From annevk@opera.com Mon Oct 24 03:28:13 2011 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 513A921F8CDC for ; Mon, 24 Oct 2011 03:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.222 X-Spam-Level: X-Spam-Status: No, score=-5.222 tagged_above=-999 required=5 tests=[AWL=-1.378, BAYES_00=-2.599, FRT_ADOBE2=2.455, MIME_8BIT_HEADER=0.3, 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 LAW9RTHnulWn for ; Mon, 24 Oct 2011 03:28:12 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5531C21F8CDB for ; Mon, 24 Oct 2011 03:28:11 -0700 (PDT) Received: from annevk-macbookpro.local (EM114-48-14-90.pool.e-mobile.ne.jp [114.48.14.90]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p9OARxsB010439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 24 Oct 2011 10:28:05 GMT Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: =?utf-8?Q?Martin_J=2E_D=C3=BCrst?= , "Larry Masinter" References: <059.f8bc48a3163d95d888ee3a23a2ca7fb9@trac.tools.ietf.org> <4EA4DA67.3000502@gondrom.org> <4EA5079B.9050700@it.aoyama.ac.jp> Date: Mon, 24 Oct 2011 19:28:01 +0900 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Anne van Kesteren" Organization: Opera Software Message-ID: In-Reply-To: User-Agent: Opera Mail/11.51 (MacIntel) Cc: "websec@ietf.org" Subject: Re: [websec] #22: content-type sniffing should include charset 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, 24 Oct 2011 10:28:13 -0000 On Mon, 24 Oct 2011 15:47:46 +0900, Larry Masinter wrote: > The charset sniffing documentation in the HTML5 document isn't all that > complicated, anyway. You have to run the HTML parser for it. It is orders of magnitude more complicated than MIME type sniffing. Sniffing for an encoding always happens after you determine what the MIME type is though. So it depends on the outcome of the MIME type sniffing algorithm what kind of encoding sniffing you might want to do. E.g. you are not going to run XML encoding sniffing on a text/html resource. It is probably confusing to refer to MIME type sniffing as Content-Type sniffing, because that is not really what it does. -- Anne van Kesteren http://annevankesteren.nl/ From tobias.gondrom@gondrom.org Mon Oct 24 04:43:35 2011 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 358CE21F8D34 for ; Mon, 24 Oct 2011 04:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.624 X-Spam-Level: X-Spam-Status: No, score=-96.624 tagged_above=-999 required=5 tests=[AWL=0.153, 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, HTML_MESSAGE=0.001, 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 hUDPiGUX7MPY for ; Mon, 24 Oct 2011 04:43:34 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id CC47B21F8D31 for ; Mon, 24 Oct 2011 04:43:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=FJ/ykcGDwZ0M4g1dWp4C69JFCalGsb/HOmJIZK9VsaY1tIiUW7esXD+de/svhTUWvjjEiq0+/BgGSYdWOIqvgc0PtSb2ODxc1WdIkzikpefkgKsFOUc3rf2GB1E2G2zx; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type; Received: (qmail 30210 invoked from network); 24 Oct 2011 13:36:51 +0200 Received: from unknown (HELO ?10.5.5.61?) (61.8.220.69) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 24 Oct 2011 13:36:50 +0200 Message-ID: <4EA54DD2.4020305@gondrom.org> Date: Mon, 24 Oct 2011 12:36:50 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110923 Thunderbird/7.0 MIME-Version: 1.0 To: annevk@opera.com References: <4EA4D8B8.7010108@gondrom.org> <4EA52C49.1090308@gondrom.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000605060205040700000201" Cc: websec@ietf.org Subject: Re: [websec] font 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, 24 Oct 2011 11:43:35 -0000 This is a multi-part message in MIME format. --------------000605060205040700000201 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 24/10/11 10:22, Anne van Kesteren wrote: > On Mon, 24 Oct 2011 18:13:45 +0900, Tobias Gondrom > wrote: >> Thanks for the reply. >> >> Well, AFAIK we don't even have a content-type for fonts in the IANA >> registry at the moment? > > Could be. I have not checked recently. MIME types for fonts are > pointless now. > > >> So my - maybe naive - question would be, do implementations sniff for >> fonts and why did they not ask for a content-type? > > Adding support for fonts to browsers went much quicker than getting > font/* from the IETF (I and some others tried doing that, maybe not in > the right way though), and once browsers shipped with font support I > stopped caring, because we would have to sniff forever anyway. > > But who is at fault is not what we are interested in here I think. We > are interested in defining when implementations have to sniff. They > very much have to sniff for fonts. > > ic. - And don't care much about the "who is at fault" question either. But as the mime-sniff draft is considering using info in the IANA content-type registry for the mime-sniffing (i.e. magic numbers, ...), we would in that case also have to add the fonts mime-type to that registry eventually. Btw. though I admit the IETF jungle can sometimes be daunting, no worries, registering a Mime-type / Content-type is not that difficult. As a WG we just shouldn't go through this exercise if in the end nobody really wants content-types for fonts or sniffing of them anyway. So a specific use case for this could be helpful - and a volunteer to provide input on by which criteria exactly fonts should be sniffed and help with writing up the font mime-type for the registry (I can help with the latter). Kind regards, Tobias --------------000605060205040700000201 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit On 24/10/11 10:22, Anne van Kesteren wrote:
On Mon, 24 Oct 2011 18:13:45 +0900, Tobias Gondrom <tobias.gondrom@gondrom.org> wrote:
Thanks for the reply.

Well, AFAIK we don't even have a content-type for fonts in the IANA
registry at the moment?

Could be. I have not checked recently. MIME types for fonts are pointless now.


So my - maybe naive - question would be, do implementations sniff for
fonts and why did they not ask for a content-type?

Adding support for fonts to browsers went much quicker than getting font/* from the IETF (I and some others tried doing that, maybe not in the right way though), and once browsers shipped with font support I stopped caring, because we would have to sniff forever anyway.

But who is at fault is not what we are interested in here I think. We are interested in defining when implementations have to sniff. They very much have to sniff for fonts.



ic. - And don't care much about the "who is at fault" question either.
But as the mime-sniff draft is considering using info in the IANA content-type registry for the mime-sniffing (i.e. magic numbers, ...), we would in that case also have to add the fonts mime-type to that registry eventually.
Btw. though I admit the IETF jungle can sometimes be daunting, no worries, registering a Mime-type / Content-type is not that difficult. As a WG we just shouldn't go through this exercise if in the end nobody really wants content-types for fonts or sniffing of them anyway.

So a specific use case for this could be helpful - and a volunteer to provide input on by which criteria exactly fonts should be sniffed and help with writing up the font mime-type for the registry (I can help with the latter).

Kind regards, Tobias




 --------------000605060205040700000201-- From annevk@opera.com Mon Oct 24 04:43:59 2011 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 2A0FD21F8D3B for ; Mon, 24 Oct 2011 04:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.14 X-Spam-Level: X-Spam-Status: No, score=-6.14 tagged_above=-999 required=5 tests=[AWL=0.459, 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 hEXs2624kTUf for ; Mon, 24 Oct 2011 04:43:58 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 72D2A21F8BBE for ; Mon, 24 Oct 2011 04:43:57 -0700 (PDT) Received: from annevk-macbookpro.local (EM114-48-118-80.pool.e-mobile.ne.jp [114.48.118.80]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p9OBhiOw032278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 24 Oct 2011 11:43:51 GMT Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Tobias Gondrom" References: <4EA4D8B8.7010108@gondrom.org> <4EA52C49.1090308@gondrom.org> <4EA54DD2.4020305@gondrom.org> Date: Mon, 24 Oct 2011 20:43:45 +0900 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Anne van Kesteren" Organization: Opera Software Message-ID: In-Reply-To: <4EA54DD2.4020305@gondrom.org> User-Agent: Opera Mail/11.51 (MacIntel) Cc: websec@ietf.org Subject: Re: [websec] font 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, 24 Oct 2011 11:43:59 -0000 On Mon, 24 Oct 2011 20:36:50 +0900, Tobias Gondrom wrote: > So a specific use case for this could be helpful - and a volunteer to > provide input on by which criteria exactly fonts should be sniffed and > help with writing up the font mime-type for the registry (I can help > with the latter). The use case is @font-face, CSS' font linking feature. The criteria I have emailed to this list before: http://www.ietf.org/mail-archive/web/websec/current/msg00235.html -- Anne van Kesteren http://annevankesteren.nl/ From pgladsto@cisco.com Mon Oct 24 09:23:38 2011 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 0C2A321F8E27 for ; Mon, 24 Oct 2011 09:23:38 -0700 (PDT) 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 Ec0qHOlGbryl for ; Mon, 24 Oct 2011 09:23:37 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 16E6121F8E26 for ; Mon, 24 Oct 2011 09:23:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pgladsto@cisco.com; l=505; q=dns/txt; s=iport; t=1319473417; x=1320683017; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=ZhOsYjXFWgHU4ZPVXI6smARcWPJBvCs5GICXsssdHtw=; b=YJOn1GdEAs2y6TUuEGmzp4lLOAnjbY95+bZGgTNQytn3GujB/MaPIzCs lxYL4XVqaQMJLU8KLDMlq9AQXHkHwCu2jUDia57aKtirUnyy2NW+E9wlV paQyMeKlXZ4UuLU27DRcsca9XaXvausYkjSKY/mS5ncGyfup2EqWT7CfZ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqUHACSQpU6rRDoI/2dsb2JhbABDhHWVH4x1ggmBBYFuAQEBAQMSARAVQBELGAICBRYLAgIJAwIBAgFFEwgBAR6dSwGMRZFLgTCFfIEUBJQJhSyMSw X-IronPort-AV: E=Sophos;i="4.69,399,1315180800"; d="scan'208";a="9874412" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 24 Oct 2011 16:23:37 +0000 Received: from [161.44.106.139] (dhcp-161-44-106-139.cisco.com [161.44.106.139]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p9OGNaM0017735 for ; Mon, 24 Oct 2011 16:23:36 GMT Message-ID: <4EA59106.8020702@cisco.com> Date: Mon, 24 Oct 2011 12:23:34 -0400 From: Philip Gladstone User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: websec@ietf.org References: <059.3516e8c3cdad2665b7817e8e50a003a8@trac.tools.ietf.org> In-Reply-To: <059.3516e8c3cdad2665b7817e8e50a003a8@trac.tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [websec] #21: sniffing of text/html shouldn't override polyglot label of application/xhtml+xml 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, 24 Oct 2011 16:23:38 -0000 On 10/23/2011 7:52 PM, websec issue tracker wrote: > > (One still might want to sniff text/html when the type is labeled > text/plain, for example, but not for other polyglot cases.) This would be a disaster. For security reasons, a web server needs to know when a document will be "executed" rather than "displayed". Currently, using text/plain will display any document literally. Causing a document that looks like html to be executed will open lots of web sites to XSS. Philip From masinter@adobe.com Mon Oct 24 09:48:41 2011 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 D8C3021F8D07 for ; Mon, 24 Oct 2011 09:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.216 X-Spam-Level: X-Spam-Status: No, score=-106.216 tagged_above=-999 required=5 tests=[AWL=0.383, 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 mSm1a40WMxsT for ; Mon, 24 Oct 2011 09:48:41 -0700 (PDT) Received: from exprod6og112.obsmtp.com (exprod6og112.obsmtp.com [64.18.1.29]) by ietfa.amsl.com (Postfix) with ESMTP id 103A121F8CFB for ; Mon, 24 Oct 2011 09:48:40 -0700 (PDT) Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob112.postini.com ([64.18.5.12]) with SMTP; Mon, 24 Oct 2011 09:48:41 PDT 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 p9OGl1YE026944; Mon, 24 Oct 2011 09:47:02 -0700 (PDT) Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id p9OGma5R020851; Mon, 24 Oct 2011 09:48:36 -0700 (PDT) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nahub02.corp.adobe.com ([10.8.189.98]) with mapi; Mon, 24 Oct 2011 09:48:36 -0700 From: Larry Masinter To: Philip Gladstone , "websec@ietf.org" Date: Mon, 24 Oct 2011 09:48:35 -0700 Thread-Topic: [websec] #21: sniffing of text/html shouldn't override polyglot label of application/xhtml+xml Thread-Index: AcySadRMFPgFBBBXQYi+5uSflnxDSgAArEMw Message-ID: References: <059.3516e8c3cdad2665b7817e8e50a003a8@trac.tools.ietf.org> <4EA59106.8020702@cisco.com> In-Reply-To: <4EA59106.8020702@cisco.com> 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: Re: [websec] #21: sniffing of text/html shouldn't override polyglot label of application/xhtml+xml 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, 24 Oct 2011 16:48:41 -0000 I don't understand, Philip. A central case of this document involves taking= documents that look like text/html but are labeled as text/plain and "snif= fing" them to be text/html after all. It's claimed that this is necessary, part of most browsers today, regular p= ractice, etc. Are you opposed to specifying sniffing from text/plain to text/html? In any= case?=20 Larry -----Original Message----- From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On Behalf Of= Philip Gladstone Sent: Monday, October 24, 2011 9:24 AM To: websec@ietf.org Subject: Re: [websec] #21: sniffing of text/html shouldn't override polyglo= t label of application/xhtml+xml On 10/23/2011 7:52 PM, websec issue tracker wrote: > > (One still might want to sniff text/html when the type is labeled > text/plain, for example, but not for other polyglot cases.) This would be a disaster. For security reasons, a web server needs to know = when a document will be "executed" rather than "displayed".=20 Currently, using text/plain will display any document literally. Causing a = document that looks like html to be executed will open lots of web sites to= XSS. Philip _______________________________________________ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec From masinter@adobe.com Mon Oct 24 09:51:46 2011 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 654C821F8BCB for ; Mon, 24 Oct 2011 09:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.578 X-Spam-Level: X-Spam-Status: No, score=-106.578 tagged_above=-999 required=5 tests=[AWL=0.022, 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 FYR7pnBm2FBK for ; Mon, 24 Oct 2011 09:51:45 -0700 (PDT) Received: from exprod6og110.obsmtp.com (exprod6og110.obsmtp.com [64.18.1.25]) by ietfa.amsl.com (Postfix) with ESMTP id 58B1621F8D84 for ; Mon, 24 Oct 2011 09:51:45 -0700 (PDT) Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob110.postini.com ([64.18.5.12]) with SMTP; Mon, 24 Oct 2011 09:51:45 PDT 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 p9OGnuYE027303; Mon, 24 Oct 2011 09:49:57 -0700 (PDT) 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 p9OGpTLW006035; Mon, 24 Oct 2011 09:51:31 -0700 (PDT) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nahub02.corp.adobe.com ([10.8.189.98]) with mapi; Mon, 24 Oct 2011 09:51:29 -0700 From: Larry Masinter To: Anne van Kesteren , Tobias Gondrom Date: Mon, 24 Oct 2011 09:51:28 -0700 Thread-Topic: [websec] font sniffing Thread-Index: AcySQsrRIUcnwKMcS5W8LIwGVgfY1QAKjXWw Message-ID: References: <4EA4D8B8.7010108@gondrom.org> <4EA52C49.1090308@gondrom.org> <4EA54DD2.4020305@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: "websec@ietf.org" Subject: Re: [websec] font 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, 24 Oct 2011 16:51:46 -0000 It's been emphasized that there is no reason why third parties can't regist= er media types if they're wanted. So there should be no barrier to specifyi= ng content-type for fonts, if that's what is wanted. Why is it a "lost cause" when no one even tried? Larry -----Original Message----- From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On Behalf Of= Anne van Kesteren Sent: Monday, October 24, 2011 4:44 AM To: Tobias Gondrom Cc: websec@ietf.org Subject: Re: [websec] font sniffing On Mon, 24 Oct 2011 20:36:50 +0900, Tobias Gondrom wrote: > So a specific use case for this could be helpful - and a volunteer to=20 > provide input on by which criteria exactly fonts should be sniffed and=20 > help with writing up the font mime-type for the registry (I can help=20 > with the latter). The use case is @font-face, CSS' font linking feature. The criteria I have = emailed to this list before: http://www.ietf.org/mail-archive/web/websec/current/msg00235.html -- Anne van Kesteren http://annevankesteren.nl/ _______________________________________________ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec From pgladsto@cisco.com Mon Oct 24 10:15:34 2011 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 773831F0C44 for ; Mon, 24 Oct 2011 10:15:34 -0700 (PDT) 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 SQUQh6rZQqfi for ; Mon, 24 Oct 2011 10:15:33 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9B12121F8DB9 for ; Mon, 24 Oct 2011 10:15:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pgladsto@cisco.com; l=1307; q=dns/txt; s=iport; t=1319476532; x=1320686132; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=FLizzC47rQI5I8SCGmidq554z2E+PfIJAwFnSFoPypQ=; b=B20413wWV3rW6X9LXvVVUSRRTprgi1a7hrkFpjUxBQdMXI522GFJT32z NkMRveJGsCs2cajeHrdKF8ZcxWW+CtDBPhhJLG21q76sV31IQd/FR0M+0 3DDZpg77E/tGoKqb/w3ggFGw1nSPVsQQykeKrC8DfzU2TkU2sA1hrDgjn w=; X-IronPort-AV: E=Sophos;i="4.69,399,1315180800"; d="scan'208";a="9887985" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 24 Oct 2011 17:15:27 +0000 Received: from [161.44.106.139] (dhcp-161-44-106-139.cisco.com [161.44.106.139]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9OHFQPr006196; Mon, 24 Oct 2011 17:15:26 GMT Message-ID: <4EA59D2D.9050905@cisco.com> Date: Mon, 24 Oct 2011 13:15:25 -0400 From: Philip Gladstone User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Larry Masinter References: <059.3516e8c3cdad2665b7817e8e50a003a8@trac.tools.ietf.org> <4EA59106.8020702@cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "websec@ietf.org" Subject: Re: [websec] #21: sniffing of text/html shouldn't override polyglot label of application/xhtml+xml 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, 24 Oct 2011 17:15:34 -0000 On 10/24/2011 12:48 PM, Larry Masinter wrote: > I don't understand, Philip. A central case of this document involves taking documents that look like text/html but are labeled as text/plain and "sniffing" them to be text/html after all. > > It's claimed that this is necessary, part of most browsers today, regular practice, etc. > > Are you opposed to specifying sniffing from text/plain to text/html? In any case? If the web server explicitly says text/plain, then IMHO it should never be sniffed as text/html. Having dealt with security issues where a document was returned (without a mime type) and then interpreted as text/html, and then enabling a serious XSS, I am attuned to this issue. [In my case, this was with a web based ticketing system that allowed the submitter of a ticket to upload arbitrary files as supplementary information. It turned out that these files were then displayed without a content type, and *some* browsers chose to interpret any javascript that was embedded. Moving to an explicit text/plain type fixed that problem, and these files were displayed literally.] In the case of sniffing image types when the web server gets it wrong, I don't have any experience with what security vulnerabilities that would introduce (if any). Philip From ietf@adambarth.com Mon Oct 24 10:19:23 2011 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 735BD11E808D for ; Mon, 24 Oct 2011 10:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.795 X-Spam-Level: X-Spam-Status: No, score=-0.795 tagged_above=-999 required=5 tests=[AWL=-0.273, 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 eWQf85+sYwgC for ; Mon, 24 Oct 2011 10:19:23 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id D090C21F8DAD for ; Mon, 24 Oct 2011 10:19:22 -0700 (PDT) Received: by ywt2 with SMTP id 2so3003340ywt.31 for ; Mon, 24 Oct 2011 10:19:22 -0700 (PDT) Received: by 10.236.181.135 with SMTP id l7mr35742094yhm.85.1319476760544; Mon, 24 Oct 2011 10:19:20 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by mx.google.com with ESMTPS id u1sm33653221yhu.11.2011.10.24.10.19.19 (version=SSLv3 cipher=OTHER); Mon, 24 Oct 2011 10:19:19 -0700 (PDT) Received: by gyh20 with SMTP id 20so7236345gyh.31 for ; Mon, 24 Oct 2011 10:19:19 -0700 (PDT) Received: by 10.236.123.43 with SMTP id u31mr35030765yhh.97.1319476759158; Mon, 24 Oct 2011 10:19:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.103.37 with HTTP; Mon, 24 Oct 2011 10:18:49 -0700 (PDT) In-Reply-To: References: <059.3516e8c3cdad2665b7817e8e50a003a8@trac.tools.ietf.org> <4EA59106.8020702@cisco.com> From: Adam Barth Date: Mon, 24 Oct 2011 10:18:49 -0700 Message-ID: To: Larry Masinter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "websec@ietf.org" Subject: Re: [websec] #21: sniffing of text/html shouldn't override polyglot label of application/xhtml+xml 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, 24 Oct 2011 17:19:23 -0000 On Mon, Oct 24, 2011 at 9:48 AM, Larry Masinter wrote: > I don't understand, Philip. A central case of this document involves taki= ng documents that look like text/html but are labeled as text/plain and "sn= iffing" them to be text/html after all. Please read the document. This does not occur. > It's claimed that this is necessary, part of most browsers today, regular= practice, etc. That's not factual. > Are you opposed to specifying sniffing from text/plain to text/html? In a= ny case? As far as I know, everyone is opposed to that. Adam > -----Original Message----- > From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On Behalf = Of Philip Gladstone > Sent: Monday, October 24, 2011 9:24 AM > To: websec@ietf.org > Subject: Re: [websec] #21: sniffing of text/html shouldn't override polyg= lot label of application/xhtml+xml > > > > On 10/23/2011 7:52 PM, websec issue tracker wrote: >> >> =A0 (One still might want to sniff text/html when the type is labeled >> =A0 text/plain, for example, but not for other polyglot cases.) > This would be a disaster. For security reasons, a web server needs to kno= w when a document will be "executed" rather than "displayed". > Currently, using text/plain will display any document literally. Causing = a document that looks like html to be executed will open lots of web sites = to XSS. > > Philip > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > From duerst@it.aoyama.ac.jp Mon Oct 24 18:43:37 2011 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 DAF5811E822C for ; Mon, 24 Oct 2011 18:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.069 X-Spam-Level: X-Spam-Status: No, score=-99.069 tagged_above=-999 required=5 tests=[AWL=0.721, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, 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 VN-HZhyob2ho for ; Mon, 24 Oct 2011 18:43:37 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 27EB711E822B for ; Mon, 24 Oct 2011 18:43:36 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id p9P1hRHT027277 for ; Tue, 25 Oct 2011 10:43:27 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 2880_08c4_bc0f17fa_feaa_11e0_a743_001d096c566a; Tue, 25 Oct 2011 10:43:27 +0900 Received: from [IPv6:::1] ([133.2.210.1]:49957) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 25 Oct 2011 10:43:30 +0900 Message-ID: <4EA6143D.8060009@it.aoyama.ac.jp> Date: Tue, 25 Oct 2011 10:43:25 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Anne van Kesteren References: <4EA4D8B8.7010108@gondrom.org> <4EA52C49.1090308@gondrom.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: websec@ietf.org Subject: Re: [websec] font 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: Tue, 25 Oct 2011 01:43:38 -0000 Hello Anne, Tobias, others, On 2011/10/24 18:22, Anne van Kesteren wrote: > On Mon, 24 Oct 2011 18:13:45 +0900, Tobias Gondrom > wrote: >> So my - maybe naive - question would be, do implementations sniff for >> fonts and why did they not ask for a content-type? > > Adding support for fonts to browsers went much quicker than getting > font/* from the IETF (I and some others tried doing that, maybe not in > the right way though), and once browsers shipped with font support I > stopped caring, because we would have to sniff forever anyway. Yes, at some point in the mid-to-late 1990s (as far as I remember, but there is also http://tools.ietf.org/html/draft-singer-font-mime-00, so maybe this was in 2004, or there were several attempts), there was an attempt to create a top-level font/ type. At the time, this met with quite strong resistance from some Mime type experts who didn't want a proliferation of top level types. The question of what's the right top level type (font/ or application/) since then has discouraged registration (in addition to what Anne mentioned). > But who is at fault is not what we are interested in here I think. We > are interested in defining when implementations have to sniff. They very > much have to sniff for fonts. Yes. If somebody has enough energy, it would still make sense to register font types. Regards, Martin. From duerst@it.aoyama.ac.jp Mon Oct 24 18:44:58 2011 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 3C4C211E81DF for ; Mon, 24 Oct 2011 18:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.159 X-Spam-Level: X-Spam-Status: No, score=-99.159 tagged_above=-999 required=5 tests=[AWL=0.631, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, 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 Hj5ZD9Yo7lxh for ; Mon, 24 Oct 2011 18:44:57 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 659C511E822C for ; Mon, 24 Oct 2011 18:44:57 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id p9P1iukP028317 for ; Tue, 25 Oct 2011 10:44:56 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 288d_2b77_f14f0f2e_feaa_11e0_a743_001d096c566a; Tue, 25 Oct 2011 10:44:56 +0900 Received: from [IPv6:::1] ([133.2.210.1]:34411) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 25 Oct 2011 10:45:00 +0900 Message-ID: <4EA61497.5000705@it.aoyama.ac.jp> Date: Tue, 25 Oct 2011 10:44:55 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Larry Masinter References: <4EA4D8B8.7010108@gondrom.org> <4EA52C49.1090308@gondrom.org> <4EA54DD2.4020305@gondrom.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "websec@ietf.org" Subject: Re: [websec] font 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: Tue, 25 Oct 2011 01:44:58 -0000 Hello Larry, On 2011/10/25 1:51, Larry Masinter wrote: > It's been emphasized that there is no reason why third parties can't register media types if they're wanted. So there should be no barrier to specifying content-type for fonts, if that's what is wanted. > > Why is it a "lost cause" when no one even tried? My guess is that Adobe has a font type or two (I might be wrong; in that case, appologies). So why don't you give it a try; it wouldn't even be a third-party registration in that case. Regards, Martin. > -----Original Message----- > From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On Behalf Of Anne van Kesteren > Sent: Monday, October 24, 2011 4:44 AM > To: Tobias Gondrom > Cc: websec@ietf.org > Subject: Re: [websec] font sniffing > > On Mon, 24 Oct 2011 20:36:50 +0900, Tobias Gondrom wrote: >> So a specific use case for this could be helpful - and a volunteer to >> provide input on by which criteria exactly fonts should be sniffed and >> help with writing up the font mime-type for the registry (I can help >> with the latter). > > The use case is @font-face, CSS' font linking feature. The criteria I have emailed to this list before: > > http://www.ietf.org/mail-archive/web/websec/current/msg00235.html > > > -- > Anne van Kesteren > http://annevankesteren.nl/ > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > From ietf@adambarth.com Mon Oct 24 19:22:08 2011 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 3D3BC1F0C52 for ; Mon, 24 Oct 2011 19:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.995 X-Spam-Level: X-Spam-Status: No, score=-1.995 tagged_above=-999 required=5 tests=[AWL=0.982, 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 Qjnw4lPxNYpb for ; Mon, 24 Oct 2011 19:22:07 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4E37D1F0C3E for ; Mon, 24 Oct 2011 19:22:07 -0700 (PDT) Received: by ywt2 with SMTP id 2so25240ywt.31 for ; Mon, 24 Oct 2011 19:22:07 -0700 (PDT) Received: by 10.236.186.34 with SMTP id v22mr17995091yhm.89.1319509326936; Mon, 24 Oct 2011 19:22:06 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by mx.google.com with ESMTPS id g38sm68685967ann.4.2011.10.24.19.22.05 (version=SSLv3 cipher=OTHER); Mon, 24 Oct 2011 19:22:05 -0700 (PDT) Received: by gyh20 with SMTP id 20so21924gyh.31 for ; Mon, 24 Oct 2011 19:22:05 -0700 (PDT) Received: by 10.236.175.130 with SMTP id z2mr38844537yhl.12.1319509325064; Mon, 24 Oct 2011 19:22:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.103.37 with HTTP; Mon, 24 Oct 2011 19:21:35 -0700 (PDT) From: Adam Barth Date: Mon, 24 Oct 2011 19:21:35 -0700 Message-ID: To: websec Content-Type: text/plain; charset=ISO-8859-1 Subject: [websec] Issue 17: Registry for magic numbers 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, 25 Oct 2011 02:22:08 -0000 http://trac.tools.ietf.org/wg/websec/trac/ticket/17 refers to an IANA registry with magic numbers for various media types. I wanted to compare them to what's in the draft, but I couldn't find it. I found the media type registry, e.g., for images: http://www.iana.org/assignments/media-types/image/index.html but I don't see any magic numbers. Would someone be willing to point me in the right direction? Thanks, Adam From annevk@opera.com Mon Oct 24 19:32:33 2011 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 B3EAF11E80DD for ; Mon, 24 Oct 2011 19:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.691 X-Spam-Level: X-Spam-Status: No, score=-4.691 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, 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 pTrR023Rk1UW for ; Mon, 24 Oct 2011 19:32:33 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id A230C11E80B8 for ; Mon, 24 Oct 2011 19:32:32 -0700 (PDT) Received: from annevk-macbookpro.local (EM1-112-233-67.pool.e-mobile.ne.jp [1.112.233.67]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p9P2WLmv016995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 25 Oct 2011 02:32:27 GMT Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: websec , "Adam Barth" References: Date: Tue, 25 Oct 2011 11:32:20 +0900 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Anne van Kesteren" Organization: Opera Software Message-ID: In-Reply-To: User-Agent: Opera Mail/11.51 (MacIntel) Subject: Re: [websec] Issue 17: Registry for magic numbers 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, 25 Oct 2011 02:32:33 -0000 On Tue, 25 Oct 2011 11:21:35 +0900, Adam Barth wrote: > http://trac.tools.ietf.org/wg/websec/trac/ticket/17 refers to an IANA > registry with magic numbers for various media types. I wanted to > compare them to what's in the draft, but I couldn't find it. I found > the media type registry, e.g., for images: > > http://www.iana.org/assignments/media-types/image/index.html > > but I don't see any magic numbers. Would someone be willing to point > me in the right direction? I don't think using a registry is a good idea. When a new MIME type comes along it needs to be determined at that point whether or not we want to sniff for it. E.g. for image/svg+xml, a new image MIME type, we decided we would not sniff for it. I suppose we could somehow encode all that information in a registry, but I do not see it making things any better for implementors. -- Anne van Kesteren http://annevankesteren.nl/ From ietf@adambarth.com Mon Oct 24 19:34:50 2011 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 59EA911E80DD for ; Mon, 24 Oct 2011 19:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.084 X-Spam-Level: X-Spam-Status: No, score=-2.084 tagged_above=-999 required=5 tests=[AWL=0.893, 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 utZ6nIII5jI8 for ; Mon, 24 Oct 2011 19:34:49 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id C9BF011E80B8 for ; Mon, 24 Oct 2011 19:34:49 -0700 (PDT) Received: by gyh20 with SMTP id 20so31351gyh.31 for ; Mon, 24 Oct 2011 19:34:49 -0700 (PDT) Received: by 10.151.8.21 with SMTP id l21mr4103316ybi.100.1319510089368; Mon, 24 Oct 2011 19:34:49 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by mx.google.com with ESMTPS id e4sm68734773ani.12.2011.10.24.19.34.48 (version=SSLv3 cipher=OTHER); Mon, 24 Oct 2011 19:34:49 -0700 (PDT) Received: by gyh20 with SMTP id 20so31335gyh.31 for ; Mon, 24 Oct 2011 19:34:48 -0700 (PDT) Received: by 10.236.131.106 with SMTP id l70mr37602307yhi.29.1319510088101; Mon, 24 Oct 2011 19:34:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.103.37 with HTTP; Mon, 24 Oct 2011 19:34:18 -0700 (PDT) In-Reply-To: References: From: Adam Barth Date: Mon, 24 Oct 2011 19:34:18 -0700 Message-ID: To: Anne van Kesteren Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: websec Subject: Re: [websec] Issue 17: Registry for magic numbers 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, 25 Oct 2011 02:34:50 -0000 On Mon, Oct 24, 2011 at 7:32 PM, Anne van Kesteren wrote= : > On Tue, 25 Oct 2011 11:21:35 +0900, Adam Barth wrote= : >> >> http://trac.tools.ietf.org/wg/websec/trac/ticket/17 refers to an IANA >> registry with magic numbers for various media types. =A0I wanted to >> compare them to what's in the draft, but I couldn't find it. =A0I found >> the media type registry, e.g., for images: >> >> http://www.iana.org/assignments/media-types/image/index.html >> >> but I don't see any magic numbers. =A0Would someone be willing to point >> me in the right direction? > > I don't think using a registry is a good idea. When a new MIME type comes > along it needs to be determined at that point whether or not we want to > sniff for it. E.g. for image/svg+xml, a new image MIME type, we decided w= e > would not sniff for it. > > I suppose we could somehow encode all that information in a registry, but= I > do not see it making things any better for implementors. Yeah, I don't think a registry is a good idea either. Constructing these signatures is too subtle, but I wanted to give the idea a fair shake. Looking at the existing registry will give us a sense for its quality. Adam From annevk@opera.com Mon Oct 24 19:35:03 2011 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 C167C11E8125 for ; Mon, 24 Oct 2011 19:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.541 X-Spam-Level: X-Spam-Status: No, score=-4.541 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_ILLEGAL_IP=1.908, 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 eJVUqNkXCGSZ for ; Mon, 24 Oct 2011 19:35:03 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 06FA911E80B8 for ; Mon, 24 Oct 2011 19:35:02 -0700 (PDT) Received: from annevk-macbookpro.local (EM1-112-233-67.pool.e-mobile.ne.jp [1.112.233.67]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p9P2Ys77017151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 25 Oct 2011 02:34:59 GMT Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: =?utf-8?Q?Martin_J=2E_D=C3=BCrst?= References: <4EA4D8B8.7010108@gondrom.org> <4EA52C49.1090308@gondrom.org> <4EA6143D.8060009@it.aoyama.ac.jp> Date: Tue, 25 Oct 2011 11:34:52 +0900 MIME-Version: 1.0 Content-Transfer-Encoding: Quoted-Printable From: "Anne van Kesteren" Organization: Opera Software Message-ID: In-Reply-To: <4EA6143D.8060009@it.aoyama.ac.jp> User-Agent: Opera Mail/11.51 (MacIntel) Cc: websec@ietf.org Subject: Re: [websec] font 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: Tue, 25 Oct 2011 02:35:03 -0000 On Tue, 25 Oct 2011 10:43:25 +0900, Martin J. D=C3=BCrst = wrote: >> But who is at fault is not what we are interested in here I think. We= >> are interested in defining when implementations have to sniff. They v= ery >> much have to sniff for fonts. > > Yes. If somebody has enough energy, it would still make sense to = > register font types. Because..? -- = Anne van Kesteren http://annevankesteren.nl/ From duerst@it.aoyama.ac.jp Mon Oct 24 21:07:56 2011 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 882DE11E80C4 for ; Mon, 24 Oct 2011 21:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.23 X-Spam-Level: X-Spam-Status: No, score=-99.23 tagged_above=-999 required=5 tests=[AWL=0.560, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, 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 BYxrM1VW8eKU for ; Mon, 24 Oct 2011 21:07:56 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id AD6F811E80BC for ; Mon, 24 Oct 2011 21:07:54 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id p9P47f6u002482 for ; Tue, 25 Oct 2011 13:07:45 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 1890_59ec_e2897df8_febe_11e0_8338_001d096c5782; Tue, 25 Oct 2011 13:07:41 +0900 Received: from [IPv6:::1] ([133.2.210.1]:59518) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 25 Oct 2011 13:07:46 +0900 Message-ID: <4EA6360C.7070700@it.aoyama.ac.jp> Date: Tue, 25 Oct 2011 13:07:40 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Adam Barth References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: websec Subject: Re: [websec] Issue 17: Registry for magic numbers 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, 25 Oct 2011 04:07:56 -0000 Hello Adam, On 2011/10/25 11:21, Adam Barth wrote: > http://trac.tools.ietf.org/wg/websec/trac/ticket/17 refers to an IANA > registry with magic numbers for various media types. I wanted to > compare them to what's in the draft, but I couldn't find it. I found > the media type registry, e.g., for images: > > http://www.iana.org/assignments/media-types/image/index.html > > but I don't see any magic numbers. Would someone be willing to point > me in the right direction? They are in the templates. To get the template for a registration, start at the overview page (http://www.iana.org/assignments/media-types/index.html). Then go to the page that lists all the registration for a give top level, e.g. http://www.iana.org/assignments/media-types/image/index.html for images. Then look at each registration template (click on the link in the left column, or in the right column if the left one doesn't have a link and the right one is to an RFC). You may then find a magic number in the registration template. As an example, for image/jp2, the template is at http://www.iana.org/assignments/media-types/image/jp2. But it looks like earlier templates didn't have a field for a magic number, and this and the reasons Anne gave make this information helpful for cross-checking, but not much more. Regards, Martin. From tobias.gondrom@gondrom.org Mon Oct 24 21:10:46 2011 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 BD3DD21F8AD1 for ; Mon, 24 Oct 2011 21:10:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.641 X-Spam-Level: X-Spam-Status: No, score=-96.641 tagged_above=-999 required=5 tests=[AWL=0.137, 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 YsM0jFzV2wPY for ; Mon, 24 Oct 2011 21:10:46 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id 969B021F8ABE for ; Mon, 24 Oct 2011 21:10:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=LuTsDkFPceyawuQqLKhmBhhttHd5OfVJ7HiMS9rCrqvd2xfOKYc0Rod7zhnQpkJuIBWCg4x4p7PWh4P0pLO5ov1RnRBF6/stYjnXaJz62QU7QfiXytVdwPVKpQo83/uG; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 9242 invoked from network); 25 Oct 2011 06:10:11 +0200 Received: from unknown (HELO ?10.5.5.61?) (61.8.220.69) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 25 Oct 2011 06:10:11 +0200 Message-ID: <4EA636A3.7060102@gondrom.org> Date: Tue, 25 Oct 2011 05:10:11 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110923 Thunderbird/7.0 MIME-Version: 1.0 To: websec@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [websec] Issue 17: Registry for magic numbers 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, 25 Oct 2011 04:10:46 -0000 On 25/10/11 03:34, Adam Barth wrote: > On Mon, Oct 24, 2011 at 7:32 PM, Anne van Kesteren wrote: >> On Tue, 25 Oct 2011 11:21:35 +0900, Adam Barth wrote: >>> http://trac.tools.ietf.org/wg/websec/trac/ticket/17 refers to an IANA >>> registry with magic numbers for various media types. I wanted to >>> compare them to what's in the draft, but I couldn't find it. I found >>> the media type registry, e.g., for images: >>> >>> http://www.iana.org/assignments/media-types/image/index.html >>> >>> but I don't see any magic numbers. Would someone be willing to point >>> me in the right direction? >> I don't think using a registry is a good idea. When a new MIME type comes >> along it needs to be determined at that point whether or not we want to >> sniff for it. E.g. for image/svg+xml, a new image MIME type, we decided we >> would not sniff for it. >> >> I suppose we could somehow encode all that information in a registry, but I >> do not see it making things any better for implementors. > Yeah, I don't think a registry is a good idea either. Constructing > these signatures is too subtle, but I wanted to give the idea a fair > shake. Looking at the existing registry will give us a sense for its > quality. > > Adam > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec The existing registry is here: http://www.iana.org/assignments/media-types/index.html And if you want to see how things look like for one Mime-type: e.g. for html: http://events.linkedin.com/Ietf-82/pub/803707 (as you can see it is very short and easy to register a mime-type...) On a technical note: There might be a good reason for the registry over only by RFC: The RFC will remain static (though you can update it with another draft, this should not necessarily be the main intention from the get-go doing on a regular basis). A registry is dynamic, so you can add information easily later (by RFC or expert review, ...) - adding mime-types is easy and we could enrich the registration of mime-types by the information you need to decide on whether to sniff and how.... Kind regards, Tobias From ietf@adambarth.com Mon Oct 24 21:24:35 2011 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 7A02411E80D5 for ; Mon, 24 Oct 2011 21:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[AWL=0.668, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, 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 8cm0CuXvpu6X for ; Mon, 24 Oct 2011 21:24:34 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7ED11E80BC for ; Mon, 24 Oct 2011 21:24:34 -0700 (PDT) Received: by gyh20 with SMTP id 20so117853gyh.31 for ; Mon, 24 Oct 2011 21:24:30 -0700 (PDT) Received: by 10.151.87.19 with SMTP id p19mr2719183ybl.71.1319516670456; Mon, 24 Oct 2011 21:24:30 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id z15sm16588373anl.15.2011.10.24.21.24.29 (version=SSLv3 cipher=OTHER); Mon, 24 Oct 2011 21:24:29 -0700 (PDT) Received: by iabn5 with SMTP id n5so136457iab.31 for ; Mon, 24 Oct 2011 21:24:29 -0700 (PDT) Received: by 10.42.153.6 with SMTP id k6mr42216660icw.30.1319516669136; Mon, 24 Oct 2011 21:24:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.205.144 with HTTP; Mon, 24 Oct 2011 21:23:59 -0700 (PDT) In-Reply-To: <4EA6360C.7070700@it.aoyama.ac.jp> References: <4EA6360C.7070700@it.aoyama.ac.jp> From: Adam Barth Date: Mon, 24 Oct 2011 21:23:59 -0700 Message-ID: To: =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: websec Subject: Re: [websec] Issue 17: Registry for magic numbers 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, 25 Oct 2011 04:24:35 -0000 On Mon, Oct 24, 2011 at 9:07 PM, "Martin J. D=FCrst" wrote: > On 2011/10/25 11:21, Adam Barth wrote: >> http://trac.tools.ietf.org/wg/websec/trac/ticket/17 refers to an IANA >> registry with magic numbers for various media types. =A0I wanted to >> compare them to what's in the draft, but I couldn't find it. =A0I found >> the media type registry, e.g., for images: >> >> http://www.iana.org/assignments/media-types/image/index.html >> >> but I don't see any magic numbers. =A0Would someone be willing to point >> me in the right direction? > > They are in the templates. To get the template for a registration, start = at > the overview page (http://www.iana.org/assignments/media-types/index.html= ). > > Then go to the page that lists all the registration for a give top level, > e.g. http://www.iana.org/assignments/media-types/image/index.html for > images. > > Then look at each registration template (click on the link in the left > column, or in the right column if the left one doesn't have a link and th= e > right one is to an RFC). You may then find a magic number in the > registration template. As an example, for image/jp2, the template is at > http://www.iana.org/assignments/media-types/image/jp2. > > But it looks like earlier templates didn't have a field for a magic numbe= r, > and this and the reasons Anne gave make this information helpful for > cross-checking, but not much more. =3D=3D Images =3D=3D PNG has a registration template , but lacks a signature. JPEG doesn't have a template. GIF doesn't have a template. BMP isn't even registered. WEBP isn't even registered. ICO has a registration template and has the correct signature. Yay! =3D=3D Text =3D=3D HTML lacks a registration template. =3D=3D Application =3D=3D PDF doesn't have a template. Postscript doesn't have a template. OGG doesn't have a template. RAR isn't even registered. ZIP has a registration template , but lacks a signature. GZIP isn't even registered. RSS isn't even registered. Atom lacks a registration template. =3D=3D Audio =3D=3D WAV isn't even registered. =3D=3D Video =3D=3D MP4 lacks a registration template. WebM isn't even registered. This does not look like a promising approach. Note: I haven't even looked through all the registrations to see how many have signatures that we shouldn't be using. Adam From duerst@it.aoyama.ac.jp Mon Oct 24 23:30:04 2011 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 BB07221F8C32 for ; Mon, 24 Oct 2011 23:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.331 X-Spam-Level: X-Spam-Status: No, score=-99.331 tagged_above=-999 required=5 tests=[AWL=0.459, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, 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 offUzjlzqc8s for ; Mon, 24 Oct 2011 23:30:04 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 1BFD821F8B76 for ; Mon, 24 Oct 2011 23:30:02 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id p9P6U2Fl029617 for ; Tue, 25 Oct 2011 15:30:02 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 288d_56df_c4f48756_fed2_11e0_a743_001d096c566a; Tue, 25 Oct 2011 15:30:02 +0900 Received: from [IPv6:::1] ([133.2.210.1]:56598) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 25 Oct 2011 15:30:06 +0900 Message-ID: <4EA65768.60205@it.aoyama.ac.jp> Date: Tue, 25 Oct 2011 15:30:00 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Anne van Kesteren References: <4EA4D8B8.7010108@gondrom.org> <4EA52C49.1090308@gondrom.org> <4EA6143D.8060009@it.aoyama.ac.jp> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: websec@ietf.org Subject: Re: [websec] font 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: Tue, 25 Oct 2011 06:30:04 -0000 On 2011/10/25 11:34, Anne van Kesteren wrote: > On Tue, 25 Oct 2011 10:43:25 +0900, Martin J. Dürst > wrote: >>> But who is at fault is not what we are interested in here I think. We >>> are interested in defining when implementations have to sniff. They very >>> much have to sniff for fonts. >> >> Yes. If somebody has enough energy, it would still make sense to >> register font types. > > Because..? - Font formats, as well as other Mime types, are not only used by Web browsers. - There may be new formats, for which no sniffing is done yet. - Servers may prefer to declare what they are sending out rather than to be silent about it, even if not all clients use that information. - Once we have registered types, sniffing could in the long term maybe even go away. Regards, Martin. From tobias.gondrom@gondrom.org Mon Oct 24 23:43:30 2011 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 1B20211E80CF for ; Mon, 24 Oct 2011 23:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.655 X-Spam-Level: X-Spam-Status: No, score=-96.655 tagged_above=-999 required=5 tests=[AWL=0.122, 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, HTML_MESSAGE=0.001, 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 nI8-pRjuKNoo for ; Mon, 24 Oct 2011 23:43:29 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id EC91D11E8086 for ; Mon, 24 Oct 2011 23:43:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=TaDoX/TtU8DZWhYyGDj22AvH7ui4QvdUhX7DywEpA+dFa4dElFbKiVa3YDgNMijusBM/0Bn9/CwuEnIKU3ups5ai5Kblx3ODQVGLqr+plgbfGeV2sslTHjr0QaMgPLw4; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type; Received: (qmail 9661 invoked from network); 25 Oct 2011 08:42:34 +0200 Received: from unknown (HELO ?10.5.5.61?) (61.8.220.69) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 25 Oct 2011 08:42:34 +0200 Message-ID: <4EA65A59.6010005@gondrom.org> Date: Tue, 25 Oct 2011 07:42:33 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110923 Thunderbird/7.0 MIME-Version: 1.0 To: websec@ietf.org References: <4EA4D8B8.7010108@gondrom.org> <4EA52C49.1090308@gondrom.org> <4EA6143D.8060009@it.aoyama.ac.jp> <4EA65768.60205@it.aoyama.ac.jp> In-Reply-To: <4EA65768.60205@it.aoyama.ac.jp> Content-Type: multipart/alternative; boundary="------------050808030503020900080703" Subject: Re: [websec] font 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: Tue, 25 Oct 2011 06:43:30 -0000 This is a multi-part message in MIME format. --------------050808030503020900080703 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 25/10/11 07:30, "Martin J. Dürst" wrote: > On 2011/10/25 11:34, Anne van Kesteren wrote: >> On Tue, 25 Oct 2011 10:43:25 +0900, Martin J. Dürst >> wrote: >>>> But who is at fault is not what we are interested in here I think. We >>>> are interested in defining when implementations have to sniff. They >>>> very >>>> much have to sniff for fonts. >>> >>> Yes. If somebody has enough energy, it would still make sense to >>> register font types. >> >> Because..? > > - Font formats, as well as other Mime types, are not only used by Web > browsers. > - There may be new formats, for which no sniffing is done yet. > - Servers may prefer to declare what they are sending out rather than > to be silent about it, even if not all clients use that information. > - Once we have registered types, sniffing could in the long term maybe > even go away. > > Regards, Martin. +1 for that. Tobias --------------050808030503020900080703 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 25/10/11 07:30, "Martin J. Dürst" wrote:
On 2011/10/25 11:34, Anne van Kesteren wrote:
On Tue, 25 Oct 2011 10:43:25 +0900, Martin J. Dürst
<duerst@it.aoyama.ac.jp> wrote:
But who is at fault is not what we are interested in here I think. We
are interested in defining when implementations have to sniff. They very
much have to sniff for fonts.

Yes. If somebody has enough energy, it would still make sense to
register font types.

Because..?

- Font formats, as well as other Mime types, are not only used by Web browsers.
- There may be new formats, for which no sniffing is done yet.
- Servers may prefer to declare what they are sending out rather than to be silent about it, even if not all clients use that information.
- Once we have registered types, sniffing could in the long term maybe even go away.

Regards,   Martin.
+1 for that.
Tobias
 --------------050808030503020900080703-- From trac+websec@trac.tools.ietf.org Tue Oct 25 15:35:37 2011 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 C096011E8083 for ; Tue, 25 Oct 2011 15:35:37 -0700 (PDT) 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 ukwsxP72QiRe for ; Tue, 25 Oct 2011 15:35:37 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 4113411E807F for ; Tue, 25 Oct 2011 15:35:36 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1RIpaj-0001fB-Se; Tue, 25 Oct 2011 18:35:29 -0400 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-mime-sniff@tools.ietf.org, masinter@adobe.com X-Trac-Project: websec Date: Tue, 25 Oct 2011 22:35:29 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/websec/trac/ticket/25 Message-ID: <059.68b3829b8b302d37dcc16c589b51048e@trac.tools.ietf.org> X-Trac-Ticket-ID: 25 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-websec-mime-sniff@tools.ietf.org, masinter@adobe.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: <20111025223537.4113411E807F@ietfa.amsl.com> Resent-Date: Tue, 25 Oct 2011 15:35:36 -0700 (PDT) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: [websec] #25: what, if any, sniffing for fonts is required? 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, 25 Oct 2011 22:35:37 -0000 #25: what, if any, sniffing for fonts is required? The current spec has a stub for sniffing fonts. The use case for this was @font-face, CSS' font linking feature. The request came in http://www.ietf.org/mail- archive/web/websec/current/msg00235.html However, "That seems very anecdotal. Do you have data to back up these claims?" (in this case, "data" = "significant use cases where sniffing is necessary"). http://lists.w3.org/Archives/Public/public-webfonts-wg/2011Apr/0005.html http://lists.w3.org/Archives/Public/public-webfonts-wg/2011Apr/0012.html Reading those, it looks like there was some disagreement about what types ought to be registered. This seems like a case where there are multiple type definitions which can be distinguished by magic number or other usage patterns, and the question is whether to register them as separate types or to use a single type and disambiguate later in the process at the receiver. In any case, we need to resolve what font sniffing is necessary, what should be sniffed, etc. -- ------------------------+-------------------------------------------- Reporter: masinter@… | Owner: draft-ietf-websec-mime-sniff@… Type: defect | Status: new Priority: major | Milestone: Component: mime-sniff | Version: Severity: - | Keywords: ------------------------+-------------------------------------------- Ticket URL: websec From tobias.gondrom@gondrom.org Tue Oct 25 20:52:31 2011 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 BBEE021F8C00 for ; Tue, 25 Oct 2011 20:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.666 X-Spam-Level: X-Spam-Status: No, score=-96.666 tagged_above=-999 required=5 tests=[AWL=0.112, 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 EBIiBto2t7Pd for ; Tue, 25 Oct 2011 20:52:30 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id 7A43721F8BD5 for ; Tue, 25 Oct 2011 20:52:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=SFsfMsb8AxTnCI6U7wYjCQo38RLEwfdmmu4GdCF451APwkn3mjiJ3lfzvEydVvFw8r+9KiB8DnSs26S9LoeFdgQ2jHsukdPLNUWDHCLQm+TKbpf/WCAhTrkiRS9pFF55; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 21613 invoked from network); 26 Oct 2011 05:52:23 +0200 Received: from unknown (HELO ?10.5.5.61?) (61.8.220.69) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 26 Oct 2011 05:52:23 +0200 Message-ID: <4EA783F7.90609@gondrom.org> Date: Wed, 26 Oct 2011 04:52:23 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: websec@ietf.org References: <4EA6360C.7070700@it.aoyama.ac.jp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [websec] Issue 17: Registry for magic numbers 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, 26 Oct 2011 03:52:31 -0000 For me the point is, currently we have a table in the document, which inside an RFC is rather static and hard to extend. So it looks like a good case for a registry to allow for extendibility for new mime-types. (e.g. we keep the table in the document, create an IANA registry, copy the values to the registry and allow for future entries by expert review) That can either be added to the current Mime-type registry, or we create a new one (e.g. within the websec namespace) with only these elements. Just my 5cents. Tobias On 25/10/11 05:23, Adam Barth wrote: > On Mon, Oct 24, 2011 at 9:07 PM, "Martin J. Dürst" > wrote: >> On 2011/10/25 11:21, Adam Barth wrote: >>> http://trac.tools.ietf.org/wg/websec/trac/ticket/17 refers to an IANA >>> registry with magic numbers for various media types. I wanted to >>> compare them to what's in the draft, but I couldn't find it. I found >>> the media type registry, e.g., for images: >>> >>> http://www.iana.org/assignments/media-types/image/index.html >>> >>> but I don't see any magic numbers. Would someone be willing to point >>> me in the right direction? >> They are in the templates. To get the template for a registration, start at >> the overview page (http://www.iana.org/assignments/media-types/index.html). >> >> Then go to the page that lists all the registration for a give top level, >> e.g. http://www.iana.org/assignments/media-types/image/index.html for >> images. >> >> Then look at each registration template (click on the link in the left >> column, or in the right column if the left one doesn't have a link and the >> right one is to an RFC). You may then find a magic number in the >> registration template. As an example, for image/jp2, the template is at >> http://www.iana.org/assignments/media-types/image/jp2. >> >> But it looks like earlier templates didn't have a field for a magic number, >> and this and the reasons Anne gave make this information helpful for >> cross-checking, but not much more. > == Images == > > PNG has a registration template > , but lacks a > signature. > JPEG doesn't have a template. > GIF doesn't have a template. > BMP isn't even registered. > WEBP isn't even registered. > ICO has a registration template > > and has the correct signature. Yay! > > == Text == > > HTML lacks a registration template. > > == Application == > > PDF doesn't have a template. > Postscript doesn't have a template. > OGG doesn't have a template. > RAR isn't even registered. > ZIP has a registration template > , but > lacks a signature. > GZIP isn't even registered. > RSS isn't even registered. > Atom lacks a registration template. > > == Audio == > > WAV isn't even registered. > > == Video == > > MP4 lacks a registration template. > WebM isn't even registered. > > This does not look like a promising approach. Note: I haven't even > looked through all the registrations to see how many have signatures > that we shouldn't be using. > > Adam > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From ietf@adambarth.com Tue Oct 25 21:00:16 2011 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 B377221F8BE9 for ; Tue, 25 Oct 2011 21:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=0.767, 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 nok4GxOmzlRe for ; Tue, 25 Oct 2011 21:00:16 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id DD07E21F8BD5 for ; Tue, 25 Oct 2011 21:00:15 -0700 (PDT) Received: by iabn5 with SMTP id n5so1645066iab.31 for ; Tue, 25 Oct 2011 21:00:15 -0700 (PDT) Received: by 10.42.157.3 with SMTP id b3mr47520639icx.44.1319601615548; Tue, 25 Oct 2011 21:00:15 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id p18sm809152ibe.7.2011.10.25.21.00.14 (version=SSLv3 cipher=OTHER); Tue, 25 Oct 2011 21:00:14 -0700 (PDT) Received: by iabn5 with SMTP id n5so1645013iab.31 for ; Tue, 25 Oct 2011 21:00:14 -0700 (PDT) Received: by 10.231.50.202 with SMTP id a10mr1378261ibg.39.1319601614099; Tue, 25 Oct 2011 21:00:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.205.144 with HTTP; Tue, 25 Oct 2011 20:59:44 -0700 (PDT) In-Reply-To: <4EA783F7.90609@gondrom.org> References: <4EA6360C.7070700@it.aoyama.ac.jp> <4EA783F7.90609@gondrom.org> From: Adam Barth Date: Tue, 25 Oct 2011 20:59:44 -0700 Message-ID: To: Tobias Gondrom Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: websec@ietf.org Subject: Re: [websec] Issue 17: Registry for magic numbers 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, 26 Oct 2011 04:00:16 -0000 Yeah, I think we're much better off creating a new registry rather than using the MIME registry. The truth is that most MIME types that get registered don't need sniffing rules. The only ones that need it are the legacy ones and the ones browser vendor cause to need it because of the prisoner's dilemma in the browser market. Adam On Tue, Oct 25, 2011 at 8:52 PM, Tobias Gondrom wrote: > > For me the point is, currently we have a table in the document, which ins= ide > an RFC is rather static and hard to extend. > So it looks like a good case for a registry to allow for extendibility fo= r > new mime-types. (e.g. we keep the table in the document, create an IANA > registry, copy the values to the registry and allow for future entries by > expert review) > That can either be added to the current Mime-type registry, or we create = a > new one (e.g. within the websec namespace) with only these elements. > > Just my 5cents. > > Tobias > > > > On 25/10/11 05:23, Adam Barth wrote: >> >> On Mon, Oct 24, 2011 at 9:07 PM, "Martin J. D=FCrst" >> =A0wrote: >>> >>> On 2011/10/25 11:21, Adam Barth wrote: >>>> >>>> http://trac.tools.ietf.org/wg/websec/trac/ticket/17 refers to an IANA >>>> registry with magic numbers for various media types. =A0I wanted to >>>> compare them to what's in the draft, but I couldn't find it. =A0I foun= d >>>> the media type registry, e.g., for images: >>>> >>>> http://www.iana.org/assignments/media-types/image/index.html >>>> >>>> but I don't see any magic numbers. =A0Would someone be willing to poin= t >>>> me in the right direction? >>> >>> They are in the templates. To get the template for a registration, star= t >>> at >>> the overview page >>> (http://www.iana.org/assignments/media-types/index.html). >>> >>> Then go to the page that lists all the registration for a give top leve= l, >>> e.g. http://www.iana.org/assignments/media-types/image/index.html for >>> images. >>> >>> Then look at each registration template (click on the link in the left >>> column, or in the right column if the left one doesn't have a link and >>> the >>> right one is to an RFC). You may then find a magic number in the >>> registration template. As an example, for image/jp2, the template is at >>> http://www.iana.org/assignments/media-types/image/jp2. >>> >>> But it looks like earlier templates didn't have a field for a magic >>> number, >>> and this and the reasons Anne gave make this information helpful for >>> cross-checking, but not much more. >> >> =3D=3D Images =3D=3D >> >> PNG has a registration template >> , but lacks a >> signature. >> JPEG doesn't have a template. >> GIF doesn't have a template. >> BMP isn't even registered. >> WEBP isn't even registered. >> ICO has a registration template >> >> and has the correct signature. =A0Yay! >> >> =3D=3D Text =3D=3D >> >> HTML lacks a registration template. >> >> =3D=3D Application =3D=3D >> >> PDF doesn't have a template. >> Postscript doesn't have a template. >> OGG doesn't have a template. >> RAR isn't even registered. >> ZIP has a registration template >> , but >> lacks a signature. >> GZIP isn't even registered. >> RSS isn't even registered. >> Atom lacks a registration template. >> >> =3D=3D Audio =3D=3D >> >> WAV isn't even registered. >> >> =3D=3D Video =3D=3D >> >> MP4 lacks a registration template. >> WebM isn't even registered. >> >> This does not look like a promising approach. =A0Note: I haven't even >> looked through all the registrations to see how many have signatures >> that we shouldn't be using. >> >> Adam >> _______________________________________________ >> websec mailing list >> websec@ietf.org >> https://www.ietf.org/mailman/listinfo/websec > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > From masinter@adobe.com Tue Oct 25 23:32:12 2011 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 E1FB221F8B0D for ; Tue, 25 Oct 2011 23:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.58 X-Spam-Level: X-Spam-Status: No, score=-106.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 rm3ysDCtpmZl for ; Tue, 25 Oct 2011 23:32:11 -0700 (PDT) Received: from exprod6og110.obsmtp.com (exprod6og110.obsmtp.com [64.18.1.25]) by ietfa.amsl.com (Postfix) with ESMTP id E50E721F8B08 for ; Tue, 25 Oct 2011 23:32:10 -0700 (PDT) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob110.postini.com ([64.18.5.12]) with SMTP; Tue, 25 Oct 2011 23:32:11 PDT 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 p9Q6VxBb017082; Tue, 25 Oct 2011 23:31:59 -0700 (PDT) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id p9Q6VvLV019344; Tue, 25 Oct 2011 23:31:57 -0700 (PDT) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas02.corp.adobe.com ([10.8.189.100]) with mapi; Tue, 25 Oct 2011 23:31:56 -0700 From: Larry Masinter To: Adam Barth , Tobias Gondrom Date: Tue, 25 Oct 2011 23:31:54 -0700 Thread-Topic: [websec] Issue 17: Registry for magic numbers Thread-Index: AcyTk8djdhOI2tMJTluj+Mio55y0gQAFGfRg Message-ID: References: <4EA6360C.7070700@it.aoyama.ac.jp> <4EA783F7.90609@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "websec@ietf.org" Subject: Re: [websec] Issue 17: Registry for magic numbers 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, 26 Oct 2011 06:32:13 -0000 This gets back to the question of the scope of the document. Does it, or do= es it not, handle sniffing of arbitrary blobs of data that come in without = any content-type, blobs of data labeled application/octet-stream, and data = coming via ftp (through ftp URIs) or thumb drives or mounted NFS file syste= ms or whatever? Does it, or does it not, handle sniffing rules inside ZIP p= ackaged web applications? =20 If it does, then sniffing should cover everything that is sniffable, includ= ing almost all MIME types -- you say "most MIME types that get registered = don't need sniffing rules", I don't know what the percentage is, but after = all, don't you want to be able to discover file types?? =20 Of course, maybe that broad applicability of sniffing isn't appropriate, bu= t then ... where's are the boundaries? Which situations are in scope vs. no= t? And don't some of the "in-scope" situations need almost all MIME types t= o be sniffable? Larry -----Original Message----- From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On Behalf Of= Adam Barth Sent: Tuesday, October 25, 2011 9:00 PM To: Tobias Gondrom Cc: websec@ietf.org Subject: Re: [websec] Issue 17: Registry for magic numbers Yeah, I think we're much better off creating a new registry rather than usi= ng the MIME registry. The truth is that most MIME types that get registere= d don't need sniffing rules. The only ones that need it are the legacy one= s and the ones browser vendor cause to need it because of the prisoner's di= lemma in the browser market. Adam On Tue, Oct 25, 2011 at 8:52 PM, Tobias Gondrom wrote: > > For me the point is, currently we have a table in the document, which=20 > inside an RFC is rather static and hard to extend. > So it looks like a good case for a registry to allow for extendibility=20 > for new mime-types. (e.g. we keep the table in the document, create an=20 > IANA registry, copy the values to the registry and allow for future=20 > entries by expert review) That can either be added to the current=20 > Mime-type registry, or we create a new one (e.g. within the websec=20 > namespace) with only these elements. > > Just my 5cents. > > Tobias > > > > On 25/10/11 05:23, Adam Barth wrote: >> >> On Mon, Oct 24, 2011 at 9:07 PM, "Martin J. D=FCrst" >> =A0wrote: >>> >>> On 2011/10/25 11:21, Adam Barth wrote: >>>> >>>> http://trac.tools.ietf.org/wg/websec/trac/ticket/17 refers to an=20 >>>> IANA registry with magic numbers for various media types. =A0I wanted= =20 >>>> to compare them to what's in the draft, but I couldn't find it. =A0I=20 >>>> found the media type registry, e.g., for images: >>>> >>>> http://www.iana.org/assignments/media-types/image/index.html >>>> >>>> but I don't see any magic numbers. =A0Would someone be willing to=20 >>>> point me in the right direction? >>> >>> They are in the templates. To get the template for a registration,=20 >>> start at the overview page=20 >>> (http://www.iana.org/assignments/media-types/index.html). >>> >>> Then go to the page that lists all the registration for a give top=20 >>> level, e.g.=20 >>> http://www.iana.org/assignments/media-types/image/index.html for images= . >>> >>> Then look at each registration template (click on the link in the=20 >>> left column, or in the right column if the left one doesn't have a=20 >>> link and the right one is to an RFC). You may then find a magic=20 >>> number in the registration template. As an example, for image/jp2,=20 >>> the template is at=20 >>> http://www.iana.org/assignments/media-types/image/jp2. >>> >>> But it looks like earlier templates didn't have a field for a magic=20 >>> number, and this and the reasons Anne gave make this information=20 >>> helpful for cross-checking, but not much more. >> >> =3D=3D Images =3D=3D >> >> PNG has a registration template >> , but lacks a=20 >> signature. >> JPEG doesn't have a template. >> GIF doesn't have a template. >> BMP isn't even registered. >> WEBP isn't even registered. >> ICO has a registration template >> > > >> and has the correct signature. =A0Yay! >> >> =3D=3D Text =3D=3D >> >> HTML lacks a registration template. >> >> =3D=3D Application =3D=3D >> >> PDF doesn't have a template. >> Postscript doesn't have a template. >> OGG doesn't have a template. >> RAR isn't even registered. >> ZIP has a registration template >> , but=20 >> lacks a signature. >> GZIP isn't even registered. >> RSS isn't even registered. >> Atom lacks a registration template. >> >> =3D=3D Audio =3D=3D >> >> WAV isn't even registered. >> >> =3D=3D Video =3D=3D >> >> MP4 lacks a registration template. >> WebM isn't even registered. >> >> This does not look like a promising approach. =A0Note: I haven't even=20 >> looked through all the registrations to see how many have signatures=20 >> that we shouldn't be using. >> >> Adam >> _______________________________________________ >> websec mailing list >> websec@ietf.org >> https://www.ietf.org/mailman/listinfo/websec > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > _______________________________________________ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec From ietf@adambarth.com Tue Oct 25 23:45:46 2011 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 28BBB11E8082 for ; Tue, 25 Oct 2011 23:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.037 X-Spam-Level: X-Spam-Status: No, score=-2.037 tagged_above=-999 required=5 tests=[AWL=0.485, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, GB_I_LETTER=-2, 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 XMJFURlZk36s for ; Tue, 25 Oct 2011 23:45:45 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD9711E807F for ; Tue, 25 Oct 2011 23:45:39 -0700 (PDT) Received: by iabn5 with SMTP id n5so1800876iab.31 for ; Tue, 25 Oct 2011 23:45:38 -0700 (PDT) Received: by 10.42.136.196 with SMTP id v4mr48928231ict.3.1319611538913; Tue, 25 Oct 2011 23:45:38 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id ge16sm1527554ibb.2.2011.10.25.23.45.37 (version=SSLv3 cipher=OTHER); Tue, 25 Oct 2011 23:45:37 -0700 (PDT) Received: by iabn5 with SMTP id n5so1800850iab.31 for ; Tue, 25 Oct 2011 23:45:37 -0700 (PDT) Received: by 10.42.154.132 with SMTP id q4mr3309012icw.54.1319611537124; Tue, 25 Oct 2011 23:45:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.205.144 with HTTP; Tue, 25 Oct 2011 23:45:07 -0700 (PDT) In-Reply-To: References: <4EA6360C.7070700@it.aoyama.ac.jp> <4EA783F7.90609@gondrom.org> From: Adam Barth Date: Tue, 25 Oct 2011 23:45:07 -0700 Message-ID: To: Larry Masinter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "websec@ietf.org" Subject: Re: [websec] Issue 17: Registry for magic numbers 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, 26 Oct 2011 06:45:46 -0000 You've posed a large number of questions. I'll do my best to answer them. On Tue, Oct 25, 2011 at 11:31 PM, Larry Masinter wrote= : > This gets back to the question of the scope of the document. Does it, or = does it not, handle sniffing of arbitrary blobs of data that come in withou= t any content-type, User agents that implement sniffing are expected to sniff HTTP responses that lack a Content-Type header, yes. > blobs of data labeled application/octet-stream, User agents that implement sniffing are not expected to sniff HTTP responses that contain Content-Type header with the value application/octet-stream. > and data coming via ftp (through ftp URIs) Yes. > or thumb drives Yes. >or mounted NFS file systems or whatever? Yes. You can answer these questions by reading the document. For example, the document explicitly states the set of Content-Type header values that trigger sniffing. The document also explicitly calls out FTP as an example. > Does it, or does it not, handle sniffing rules inside ZIP packaged web ap= plications? Not as described by this document. However, I've been told that another document has re-used the algorithm for that purpose. > If it does, then sniffing should cover everything that is sniffable, incl= uding almost all MIME types Why is that? The document describes what is essentially the minimal amount of sniffing a user agent needs to perform in order to be competitive in the browser market. I don't think we should be encouraging sniffing beyond that. > -- you say "most MIME types that get registered don't need sniffing rules= ", I don't know what the percentage is, With the possible exception of fonts, I believe the document describes all the sniffing rules that are necessary today. You can compare with list of MIME types in the document with the list of registered MIME types if you wish to get a sense of what I mean when I say that "most" don't need sniffing rules. > but after all, don't you want to be able to discover file types?? I'm not sure what you mean by "discover file types". There's no discovery going on here. > Of course, maybe that broad applicability of sniffing isn't appropriate, = but then ... where's are the boundaries? The boundaries are exactly what's described in the document. There's been a great deal of research and implementation experience poured into the document to determine precisely where to draw the boundaries. As far as I can tell, the document describes the optimal point. If you have data that shows otherwise, I'd like to see it. > Which situations are in scope vs. not? The criteria I would use is the following one: "Given a diverse market of browser vendors, is this a sniffing algorithm that all browser vendors are mutually interested in converging upon." If the answer is "yes", then you've identified the correct scope and rules. If "no", then the spec needs to be improved. If there is no such set of rules, then this endeavor is a waste of time and any spec we create will be dead letter. > And don't some of the "in-scope" situations need almost all MIME types to= be sniffable? No. Adam > -----Original Message----- > From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On Behalf = Of Adam Barth > Sent: Tuesday, October 25, 2011 9:00 PM > To: Tobias Gondrom > Cc: websec@ietf.org > Subject: Re: [websec] Issue 17: Registry for magic numbers > > Yeah, I think we're much better off creating a new registry rather than u= sing the MIME registry. =A0The truth is that most MIME types that get regis= tered don't need sniffing rules. =A0The only ones that need it are the lega= cy ones and the ones browser vendor cause to need it because of the prisone= r's dilemma in the browser market. > > Adam > > > On Tue, Oct 25, 2011 at 8:52 PM, Tobias Gondrom wrote: >> >> For me the point is, currently we have a table in the document, which >> inside an RFC is rather static and hard to extend. >> So it looks like a good case for a registry to allow for extendibility >> for new mime-types. (e.g. we keep the table in the document, create an >> IANA registry, copy the values to the registry and allow for future >> entries by expert review) That can either be added to the current >> Mime-type registry, or we create a new one (e.g. within the websec >> namespace) with only these elements. >> >> Just my 5cents. >> >> Tobias >> >> >> >> On 25/10/11 05:23, Adam Barth wrote: >>> >>> On Mon, Oct 24, 2011 at 9:07 PM, "Martin J. D=FCrst" >>> =A0wrote: >>>> >>>> On 2011/10/25 11:21, Adam Barth wrote: >>>>> >>>>> http://trac.tools.ietf.org/wg/websec/trac/ticket/17 refers to an >>>>> IANA registry with magic numbers for various media types. =A0I wanted >>>>> to compare them to what's in the draft, but I couldn't find it. =A0I >>>>> found the media type registry, e.g., for images: >>>>> >>>>> http://www.iana.org/assignments/media-types/image/index.html >>>>> >>>>> but I don't see any magic numbers. =A0Would someone be willing to >>>>> point me in the right direction? >>>> >>>> They are in the templates. To get the template for a registration, >>>> start at the overview page >>>> (http://www.iana.org/assignments/media-types/index.html). >>>> >>>> Then go to the page that lists all the registration for a give top >>>> level, e.g. >>>> http://www.iana.org/assignments/media-types/image/index.html for image= s. >>>> >>>> Then look at each registration template (click on the link in the >>>> left column, or in the right column if the left one doesn't have a >>>> link and the right one is to an RFC). You may then find a magic >>>> number in the registration template. As an example, for image/jp2, >>>> the template is at >>>> http://www.iana.org/assignments/media-types/image/jp2. >>>> >>>> But it looks like earlier templates didn't have a field for a magic >>>> number, and this and the reasons Anne gave make this information >>>> helpful for cross-checking, but not much more. >>> >>> =3D=3D Images =3D=3D >>> >>> PNG has a registration template >>> , but lacks a >>> signature. >>> JPEG doesn't have a template. >>> GIF doesn't have a template. >>> BMP isn't even registered. >>> WEBP isn't even registered. >>> ICO has a registration template >>> >> > >>> and has the correct signature. =A0Yay! >>> >>> =3D=3D Text =3D=3D >>> >>> HTML lacks a registration template. >>> >>> =3D=3D Application =3D=3D >>> >>> PDF doesn't have a template. >>> Postscript doesn't have a template. >>> OGG doesn't have a template. >>> RAR isn't even registered. >>> ZIP has a registration template >>> , but >>> lacks a signature. >>> GZIP isn't even registered. >>> RSS isn't even registered. >>> Atom lacks a registration template. >>> >>> =3D=3D Audio =3D=3D >>> >>> WAV isn't even registered. >>> >>> =3D=3D Video =3D=3D >>> >>> MP4 lacks a registration template. >>> WebM isn't even registered. >>> >>> This does not look like a promising approach. =A0Note: I haven't even >>> looked through all the registrations to see how many have signatures >>> that we shouldn't be using. >>> >>> Adam >>> _______________________________________________ >>> websec mailing list >>> websec@ietf.org >>> https://www.ietf.org/mailman/listinfo/websec >> >> _______________________________________________ >> websec mailing list >> websec@ietf.org >> https://www.ietf.org/mailman/listinfo/websec >> > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > From masinter@adobe.com Wed Oct 26 01:38:22 2011 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 EFBBC21F84D2 for ; Wed, 26 Oct 2011 01:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.355 X-Spam-Level: X-Spam-Status: No, score=-106.355 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, FRT_ADOBE2=2.455, GB_I_LETTER=-2, 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 u26AgxjpWcPZ for ; Wed, 26 Oct 2011 01:38:22 -0700 (PDT) Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com [64.18.1.37]) by ietfa.amsl.com (Postfix) with ESMTP id 715D321F84CC for ; Wed, 26 Oct 2011 01:38:20 -0700 (PDT) Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob116.postini.com ([64.18.5.12]) with SMTP; Wed, 26 Oct 2011 01:38:21 PDT 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 p9Q8aTYE004089; Wed, 26 Oct 2011 01:36:30 -0700 (PDT) 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 p9Q8c0LW003218; Wed, 26 Oct 2011 01:38:04 -0700 (PDT) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas01.corp.adobe.com ([10.8.189.99]) with mapi; Wed, 26 Oct 2011 01:38:03 -0700 From: Larry Masinter To: Adam Barth Date: Wed, 26 Oct 2011 01:38:00 -0700 Thread-Topic: [websec] Issue 17: Registry for magic numbers Thread-Index: AcyTquHWBNIMkzUkSQu3HYvOq8c2/QADiNJA Message-ID: References: <4EA6360C.7070700@it.aoyama.ac.jp> <4EA783F7.90609@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "websec@ietf.org" Subject: Re: [websec] Issue 17: Registry for magic numbers 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, 26 Oct 2011 08:38:23 -0000 A standards specification should meet the requirements of the use cases tha= t are in scope for the specification.=20 If you only evaluate adequacy against a narrow set of requirements, then t= he scope should be limited to those situations where those requirements are= adequate. If you're evaluating against what "a user agent needs to perform in order = to be competitive in the browser market" then the only use cases you're va= lidating against are "popular web browsers in 2012", which is a very narrow= scope. If, on the other hand, you expect the standard to have value over the long = term, you need a longer-term and broader set of requirements and use cases,= which will add additional complexity to meet requirements. Larry -----Original Message----- From: Adam Barth [mailto:ietf@adambarth.com]=20 Sent: Tuesday, October 25, 2011 11:45 PM To: Larry Masinter Cc: Tobias Gondrom; websec@ietf.org Subject: Re: [websec] Issue 17: Registry for magic numbers You've posed a large number of questions. I'll do my best to answer them. On Tue, Oct 25, 2011 at 11:31 PM, Larry Masinter wrote= : > This gets back to the question of the scope of the document. Does it,=20 > or does it not, handle sniffing of arbitrary blobs of data that come=20 > in without any content-type, User agents that implement sniffing are expected to sniff HTTP responses th= at lack a Content-Type header, yes. > blobs of data labeled application/octet-stream, User agents that implement sniffing are not expected to sniff HTTP response= s that contain Content-Type header with the value application/octet-stream. > and data coming via ftp (through ftp URIs) Yes. > or thumb drives Yes. >or mounted NFS file systems or whatever? Yes. You can answer these questions by reading the document. For example, the d= ocument explicitly states the set of Content-Type header values that trigge= r sniffing. The document also explicitly calls out FTP as an example. > Does it, or does it not, handle sniffing rules inside ZIP packaged web ap= plications? Not as described by this document. However, I've been told that another do= cument has re-used the algorithm for that purpose. > If it does, then sniffing should cover everything that is sniffable,=20 > including almost all MIME types Why is that? The document describes what is essentially the minimal amount= of sniffing a user agent needs to perform in order to be competitive in th= e browser market. I don't think we should be encouraging sniffing beyond t= hat. > -- you say "most MIME types that get registered don't need sniffing=20 > rules", I don't know what the percentage is, With the possible exception of fonts, I believe the document describes all = the sniffing rules that are necessary today. You can compare with list of = MIME types in the document with the list of registered MIME types if you wi= sh to get a sense of what I mean when I say that "most" don't need sniffing rules. > but after all, don't you want to be able to discover file types?? I'm not sure what you mean by "discover file types". There's no discovery = going on here. > Of course, maybe that broad applicability of sniffing isn't appropriate, = but then ... where's are the boundaries? The boundaries are exactly what's described in the document. There's been = a great deal of research and implementation experience poured into the docu= ment to determine precisely where to draw the boundaries. As far as I can tell, the document describes the optimal point. If you ha= ve data that shows otherwise, I'd like to see it. > Which situations are in scope vs. not? The criteria I would use is the following one: "Given a diverse market of browser vendors, is this a sniffing algorithm th= at all browser vendors are mutually interested in converging upon." If the answer is "yes", then you've identified the correct scope and rules.= If "no", then the spec needs to be improved. If there is no such set of = rules, then this endeavor is a waste of time and any spec we create will be= dead letter. > And don't some of the "in-scope" situations need almost all MIME types to= be sniffable? No. Adam > -----Original Message----- > From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On=20 > Behalf Of Adam Barth > Sent: Tuesday, October 25, 2011 9:00 PM > To: Tobias Gondrom > Cc: websec@ietf.org > Subject: Re: [websec] Issue 17: Registry for magic numbers > > Yeah, I think we're much better off creating a new registry rather than u= sing the MIME registry. =A0The truth is that most MIME types that get regis= tered don't need sniffing rules. =A0The only ones that need it are the lega= cy ones and the ones browser vendor cause to need it because of the prisone= r's dilemma in the browser market. > > Adam > > > On Tue, Oct 25, 2011 at 8:52 PM, Tobias Gondrom wrote: >> >> For me the point is, currently we have a table in the document, which=20 >> inside an RFC is rather static and hard to extend. >> So it looks like a good case for a registry to allow for=20 >> extendibility for new mime-types. (e.g. we keep the table in the=20 >> document, create an IANA registry, copy the values to the registry=20 >> and allow for future entries by expert review) That can either be=20 >> added to the current Mime-type registry, or we create a new one (e.g.=20 >> within the websec >> namespace) with only these elements. >> >> Just my 5cents. >> >> Tobias >> >> >> >> On 25/10/11 05:23, Adam Barth wrote: >>> >>> On Mon, Oct 24, 2011 at 9:07 PM, "Martin J. D=FCrst" >>> =A0wrote: >>>> >>>> On 2011/10/25 11:21, Adam Barth wrote: >>>>> >>>>> http://trac.tools.ietf.org/wg/websec/trac/ticket/17 refers to an=20 >>>>> IANA registry with magic numbers for various media types. =A0I=20 >>>>> wanted to compare them to what's in the draft, but I couldn't find=20 >>>>> it. =A0I found the media type registry, e.g., for images: >>>>> >>>>> http://www.iana.org/assignments/media-types/image/index.html >>>>> >>>>> but I don't see any magic numbers. =A0Would someone be willing to=20 >>>>> point me in the right direction? >>>> >>>> They are in the templates. To get the template for a registration,=20 >>>> start at the overview page=20 >>>> (http://www.iana.org/assignments/media-types/index.html). >>>> >>>> Then go to the page that lists all the registration for a give top=20 >>>> level, e.g. >>>> http://www.iana.org/assignments/media-types/image/index.html for image= s. >>>> >>>> Then look at each registration template (click on the link in the=20 >>>> left column, or in the right column if the left one doesn't have a=20 >>>> link and the right one is to an RFC). You may then find a magic=20 >>>> number in the registration template. As an example, for image/jp2,=20 >>>> the template is at=20 >>>> http://www.iana.org/assignments/media-types/image/jp2. >>>> >>>> But it looks like earlier templates didn't have a field for a magic=20 >>>> number, and this and the reasons Anne gave make this information=20 >>>> helpful for cross-checking, but not much more. >>> >>> =3D=3D Images =3D=3D >>> >>> PNG has a registration template >>> , but lacks a=20 >>> signature. >>> JPEG doesn't have a template. >>> GIF doesn't have a template. >>> BMP isn't even registered. >>> WEBP isn't even registered. >>> ICO has a registration template >>> >> n >>> > >>> and has the correct signature. =A0Yay! >>> >>> =3D=3D Text =3D=3D >>> >>> HTML lacks a registration template. >>> >>> =3D=3D Application =3D=3D >>> >>> PDF doesn't have a template. >>> Postscript doesn't have a template. >>> OGG doesn't have a template. >>> RAR isn't even registered. >>> ZIP has a registration template >>> , but=20 >>> lacks a signature. >>> GZIP isn't even registered. >>> RSS isn't even registered. >>> Atom lacks a registration template. >>> >>> =3D=3D Audio =3D=3D >>> >>> WAV isn't even registered. >>> >>> =3D=3D Video =3D=3D >>> >>> MP4 lacks a registration template. >>> WebM isn't even registered. >>> >>> This does not look like a promising approach. =A0Note: I haven't even=20 >>> looked through all the registrations to see how many have signatures=20 >>> that we shouldn't be using. >>> >>> Adam >>> _______________________________________________ >>> websec mailing list >>> websec@ietf.org >>> https://www.ietf.org/mailman/listinfo/websec >> >> _______________________________________________ >> websec mailing list >> websec@ietf.org >> https://www.ietf.org/mailman/listinfo/websec >> > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > From ietf@adambarth.com Wed Oct 26 01:56:34 2011 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 9BA6921F8AEE for ; Wed, 26 Oct 2011 01:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.07 X-Spam-Level: X-Spam-Status: No, score=-2.07 tagged_above=-999 required=5 tests=[AWL=0.452, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, GB_I_LETTER=-2, 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 xtlesaWvFNEm for ; Wed, 26 Oct 2011 01:56:33 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 73B1721F8493 for ; Wed, 26 Oct 2011 01:56:33 -0700 (PDT) Received: by iabn5 with SMTP id n5so1939975iab.31 for ; Wed, 26 Oct 2011 01:56:33 -0700 (PDT) Received: by 10.42.108.136 with SMTP id h8mr49405068icp.43.1319619392677; Wed, 26 Oct 2011 01:56:32 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id p16sm2069829ibk.6.2011.10.26.01.56.31 (version=SSLv3 cipher=OTHER); Wed, 26 Oct 2011 01:56:31 -0700 (PDT) Received: by iabn5 with SMTP id n5so1939948iab.31 for ; Wed, 26 Oct 2011 01:56:31 -0700 (PDT) Received: by 10.231.20.147 with SMTP id f19mr1705904ibb.13.1319619391118; Wed, 26 Oct 2011 01:56:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.205.144 with HTTP; Wed, 26 Oct 2011 01:56:01 -0700 (PDT) In-Reply-To: References: <4EA6360C.7070700@it.aoyama.ac.jp> <4EA783F7.90609@gondrom.org> From: Adam Barth Date: Wed, 26 Oct 2011 01:56:01 -0700 Message-ID: To: Larry Masinter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "websec@ietf.org" Subject: Re: [websec] Issue 17: Registry for magic numbers 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, 26 Oct 2011 08:56:34 -0000 It might be narrow in your view, but it's the use case I'm interested in addressing. Adam On Wed, Oct 26, 2011 at 1:38 AM, Larry Masinter wrote: > A standards specification should meet the requirements of the use cases t= hat are in scope for the specification. > > If you only evaluate adequacy against =A0a narrow set of requirements, th= en the scope should be limited to those situations where those requirements= are adequate. > > If you're evaluating against what "a =A0user agent needs to perform in or= der to be competitive in the browser market" =A0then the only use cases you= 're validating against are "popular web browsers in 2012", which is a very = narrow scope. > > If, on the other hand, you expect the standard to have value over the lon= g term, you need a longer-term and broader set of requirements and use case= s, which will add additional complexity to meet requirements. > > Larry > > > -----Original Message----- > From: Adam Barth [mailto:ietf@adambarth.com] > Sent: Tuesday, October 25, 2011 11:45 PM > To: Larry Masinter > Cc: Tobias Gondrom; websec@ietf.org > Subject: Re: [websec] Issue 17: Registry for magic numbers > > You've posed a large number of questions. =A0I'll do my best to answer th= em. > > On Tue, Oct 25, 2011 at 11:31 PM, Larry Masinter wro= te: >> This gets back to the question of the scope of the document. Does it, >> or does it not, handle sniffing of arbitrary blobs of data that come >> in without any content-type, > > User agents that implement sniffing are expected to sniff HTTP responses = that lack a Content-Type header, yes. > >> blobs of data labeled application/octet-stream, > > User agents that implement sniffing are not expected to sniff HTTP respon= ses that contain Content-Type header with the value application/octet-strea= m. > >> and data coming via ftp (through ftp URIs) > > Yes. > >> or thumb drives > > Yes. > >>or mounted NFS file systems or whatever? > > Yes. > > You can answer these questions by reading the document. =A0For example, t= he document explicitly states the set of Content-Type header values that tr= igger sniffing. =A0The document also explicitly calls out FTP as an example= . > >> Does it, or does it not, handle sniffing rules inside ZIP packaged web a= pplications? > > Not as described by this document. =A0However, I've been told that anothe= r document has re-used the algorithm for that purpose. > >> If it does, then sniffing should cover everything that is sniffable, >> including almost all MIME types > > Why is that? =A0The document describes what is essentially the minimal am= ount of sniffing a user agent needs to perform in order to be competitive i= n the browser market. =A0I don't think we should be encouraging sniffing be= yond that. > >> -- you say "most MIME types that get registered don't need sniffing >> rules", I don't know what the percentage is, > > With the possible exception of fonts, I believe the document describes al= l the sniffing rules that are necessary today. =A0You can compare with list= of MIME types in the document with the list of registered MIME types if yo= u wish to get a sense of what I mean when I say that "most" > don't need sniffing rules. > >> but after all, don't you want to be able to discover file types?? > > I'm not sure what you mean by "discover file types". =A0There's no discov= ery going on here. > >> Of course, maybe that broad applicability of sniffing isn't appropriate,= but then ... where's are the boundaries? > > The boundaries are exactly what's described in the document. =A0There's b= een a great deal of research and implementation experience poured into the = document to determine precisely where to draw the boundaries. > =A0As far as I can tell, the document describes the optimal point. =A0If = you have data that shows otherwise, I'd like to see it. > >> Which situations are in scope vs. not? > > The criteria I would use is the following one: > > "Given a diverse market of browser vendors, is this a sniffing algorithm = that all browser vendors are mutually interested in converging upon." > > If the answer is "yes", then you've identified the correct scope and rule= s. =A0If "no", then the spec needs to be improved. =A0If there is no such s= et of rules, then this endeavor is a waste of time and any spec we create w= ill be dead letter. > >> And don't some of the "in-scope" situations need almost all MIME types t= o be sniffable? > > No. > > Adam > > >> -----Original Message----- >> From: websec-bounces@ietf.org [mailto:websec-bounces@ietf.org] On >> Behalf Of Adam Barth >> Sent: Tuesday, October 25, 2011 9:00 PM >> To: Tobias Gondrom >> Cc: websec@ietf.org >> Subject: Re: [websec] Issue 17: Registry for magic numbers >> >> Yeah, I think we're much better off creating a new registry rather than = using the MIME registry. =A0The truth is that most MIME types that get regi= stered don't need sniffing rules. =A0The only ones that need it are the leg= acy ones and the ones browser vendor cause to need it because of the prison= er's dilemma in the browser market. >> >> Adam >> >> >> On Tue, Oct 25, 2011 at 8:52 PM, Tobias Gondrom wrote: >>> >>> For me the point is, currently we have a table in the document, which >>> inside an RFC is rather static and hard to extend. >>> So it looks like a good case for a registry to allow for >>> extendibility for new mime-types. (e.g. we keep the table in the >>> document, create an IANA registry, copy the values to the registry >>> and allow for future entries by expert review) That can either be >>> added to the current Mime-type registry, or we create a new one (e.g. >>> within the websec >>> namespace) with only these elements. >>> >>> Just my 5cents. >>> >>> Tobias >>> >>> >>> >>> On 25/10/11 05:23, Adam Barth wrote: >>>> >>>> On Mon, Oct 24, 2011 at 9:07 PM, "Martin J. D=FCrst" >>>> =A0wrote: >>>>> >>>>> On 2011/10/25 11:21, Adam Barth wrote: >>>>>> >>>>>> http://trac.tools.ietf.org/wg/websec/trac/ticket/17 refers to an >>>>>> IANA registry with magic numbers for various media types. =A0I >>>>>> wanted to compare them to what's in the draft, but I couldn't find >>>>>> it. =A0I found the media type registry, e.g., for images: >>>>>> >>>>>> http://www.iana.org/assignments/media-types/image/index.html >>>>>> >>>>>> but I don't see any magic numbers. =A0Would someone be willing to >>>>>> point me in the right direction? >>>>> >>>>> They are in the templates. To get the template for a registration, >>>>> start at the overview page >>>>> (http://www.iana.org/assignments/media-types/index.html). >>>>> >>>>> Then go to the page that lists all the registration for a give top >>>>> level, e.g. >>>>> http://www.iana.org/assignments/media-types/image/index.html for imag= es. >>>>> >>>>> Then look at each registration template (click on the link in the >>>>> left column, or in the right column if the left one doesn't have a >>>>> link and the right one is to an RFC). You may then find a magic >>>>> number in the registration template. As an example, for image/jp2, >>>>> the template is at >>>>> http://www.iana.org/assignments/media-types/image/jp2. >>>>> >>>>> But it looks like earlier templates didn't have a field for a magic >>>>> number, and this and the reasons Anne gave make this information >>>>> helpful for cross-checking, but not much more. >>>> >>>> =3D=3D Images =3D=3D >>>> >>>> PNG has a registration template >>>> , but lacks a >>>> signature. >>>> JPEG doesn't have a template. >>>> GIF doesn't have a template. >>>> BMP isn't even registered. >>>> WEBP isn't even registered. >>>> ICO has a registration template >>>> >>> n >>>> > >>>> and has the correct signature. =A0Yay! >>>> >>>> =3D=3D Text =3D=3D >>>> >>>> HTML lacks a registration template. >>>> >>>> =3D=3D Application =3D=3D >>>> >>>> PDF doesn't have a template. >>>> Postscript doesn't have a template. >>>> OGG doesn't have a template. >>>> RAR isn't even registered. >>>> ZIP has a registration template >>>> , but >>>> lacks a signature. >>>> GZIP isn't even registered. >>>> RSS isn't even registered. >>>> Atom lacks a registration template. >>>> >>>> =3D=3D Audio =3D=3D >>>> >>>> WAV isn't even registered. >>>> >>>> =3D=3D Video =3D=3D >>>> >>>> MP4 lacks a registration template. >>>> WebM isn't even registered. >>>> >>>> This does not look like a promising approach. =A0Note: I haven't even >>>> looked through all the registrations to see how many have signatures >>>> that we shouldn't be using. >>>> >>>> Adam >>>> _______________________________________________ >>>> websec mailing list >>>> websec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/websec >>> >>> _______________________________________________ >>> websec mailing list >>> websec@ietf.org >>> https://www.ietf.org/mailman/listinfo/websec >>> >> _______________________________________________ >> websec mailing list >> websec@ietf.org >> https://www.ietf.org/mailman/listinfo/websec >> > From hallam@gmail.com Wed Oct 26 07:03:49 2011 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 E3A4121F8906; Wed, 26 Oct 2011 07:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.39 X-Spam-Level: X-Spam-Status: No, score=-3.39 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Kh43hGJ45nOz; Wed, 26 Oct 2011 07:03:48 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 55EDA21F87C2; Wed, 26 Oct 2011 07:03:48 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so1743810vcb.31 for ; Wed, 26 Oct 2011 07:03:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JHSSZAjJ7eHZuvjMs+p5uRopCY2J9Rc0Oa41oPS18dU=; b=ZPSijw12Z6PsckxvlbI/0XD1yeq64K+3DGJ8InXB8U8Wx1iONvWrzkXOSLcHkL+w0x cUNybyHAKwn4T7RrtoaMmWeDL2kD4r2G0eUzRwnHGsd3SRiUy5EN0sZrwhakw9o+YIrf 92KKZuyMI7csZFzlJQscx72van0mjyRgD6MkU= MIME-Version: 1.0 Received: by 10.182.49.1 with SMTP id q1mr1083603obn.48.1319637827478; Wed, 26 Oct 2011 07:03:47 -0700 (PDT) Received: by 10.182.42.99 with HTTP; Wed, 26 Oct 2011 07:03:47 -0700 (PDT) In-Reply-To: <82AB329A76E2484D934BBCA77E9F524924B74434@PALLENE.office.hd> References: <82AB329A76E2484D934BBCA77E9F524924B74297@PALLENE.office.hd> <1CA25301D2219F40B3AA37201F0EACD1136C0EEC@PACDCEXMB05.cable.comcast.com> <82AB329A76E2484D934BBCA77E9F524924B74434@PALLENE.office.hd> Date: Wed, 26 Oct 2011 10:03:47 -0400 Message-ID: From: Phillip Hallam-Baker To: Dirk Kutscher , websec Content-Type: multipart/alternative; boundary=f46d0447850bf0640504b0341f82 Cc: "decade@ietf.org" , "Woundy, Richard" , "cdannewitz@uni-paderborn.de" , "rob.stradling@comodo.com" , "philliph@comodo.com" Subject: Re: [websec] [decade] URIs for DECADE -- Named Information URI Scheme 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, 26 Oct 2011 14:03:50 -0000 --f46d0447850bf0640504b0341f82 Content-Type: text/plain; charset=ISO-8859-1 I think that is the best approach as well. The WebSec use is purely to create a strong reference. I think that if we can get convergence on the core spec quickly, the WebSec use should be orthogonal. The aim here is merely to ensure that we end up with one mechanism for specifying digests of referenced objects rather than having slightly different versions in different groups. There are many interesting things that can be done with digest URIs. Some of which will probably solve problems WebSEC faces. But DECADE is clearly the best place to discuss those at the moment. All that WebSEC will be using for the time being is the ability to refer to securely a blob of security policy related data in a fashion that packages all the crypto gubbins into one string of text. DECADE is rather different because it is in effect describing a new and very different form of URL. A traditional URL is a procedural content link, the content is defined by the means of retrieval. An ni URI is also a locator in that it MAY give one (or more) means of locating the data. But the data itself is specified in a functional style. Any method of function evaluation that produces the expected result is equally valid (but not necessarily equally efficient). I do have some proposals for using the digest URI that maybe fall outside both WG charters. This is a notary technology that I think we need. But this is something that simply has to be built on top of DECADE so that it can have the acronym DECADE-Notary Technology, or DECADENT. On Wed, Oct 26, 2011 at 9:34 AM, Dirk Kutscher wrote: > Rich, > > yes, I agree that we should decide that. > > Our recommendation would be to do the base spec in DECADE. > > Best regards, > > Dirk > > > > > > -----Original Message----- > > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > > Sent: Mittwoch, 26. Oktober 2011 15:22 > > To: Dirk Kutscher; 'decade@ietf.org' > > Cc: 'cdannewitz@uni-paderborn.de'; 'rob.stradling@comodo.com'; > > 'philliph@comodo.com'; Woundy, Richard > > Subject: Re: [decade] URIs for DECADE -- Named Information URI Scheme > > > > Now that we have established that websec and decade are at least > > interested in the named information uri scheme, do we know what group is > > expected to own the base specification? That might be a good topic to > > discuss with the relevant ADs in email now and at IETF 82 in person (app > and > > tsv at least). > > > > ----- Original Message ----- > > From: Dirk Kutscher [mailto:Dirk.Kutscher@neclab.eu] > > Sent: Wednesday, October 26, 2011 09:06 AM > > To: decade ietf > > Cc: Christian Dannewitz (cdannewitz@uni-paderborn.de) > > paderborn.de>; Rob Stradling (rob.stradling@comodo.com) > > ; philliph@comodo.com > > > > Subject: [decade] URIs for DECADE -- Named Information URI Scheme > > > > Dear all, > > > > We have updated the Named Information URI scheme that we presented at > > IETF-81. > > > > It turned out that the WEBSEC folks (Phillip Hallam-Baker and colleagues) > had > > started a parallel effort on a very similar approach, and -- fortunately > -- we > > have been able to combine our efforts and have advanced the spec so that > it > > would be useful for DECADE, WEBSEC and potentially other applications. > > > > We still think that DECADE could benefit most at this time, so we > submitted > > this (as an individual submission) to DECADE now. > > > > We found a, IMO, nice way to have a concise base specification without > > excluding extensions for future application requirements. Basically, > there is > > an extension mechanism that allows applications to specify additional > > parameters. > > > > To make this manageable, we have split the specification into two pieces: > > > > The base spec: > > > > http://tools.ietf.org/html/draft-farrell-decade-ni-00 > > > > This document defines a URI-based name form that identifies a named > > object via hash-based binding. The URI name form defined is intended > for > > use in applications that need to uniquely identify resources in a > location- > > independent way such as accessing in-network storage (DECADE), > > information-centric networking and more generally. The format is > designed > > to support a strong link to the referenced object such that the > referenced > > object may be authenticated to the same degree as the reference to it. > > > > The base spec has a set of useful general features (in addition to the > actual > > syntax definition), such as processing rules (testing for equality), and > an > > algorithm that can be used to map NI URIs to HTTP(S) automatically -- > which I > > believe could be useful for DECADE, too. The base spec also defines the > > fundamentals of the extension mechanism. > > > > > > A spec that defines a set of extension parameters and their semantics: > > > > http://tools.ietf.org/html/draft-hallambaker-decade-ni-params-00 > > This document specifies some optional algorithms and parameters that may > > be used in the query string of ni URIs. > > > > One of the parameters that we have introduced here would allow you to > > specify additional locators for resources -- again, that is expected to > be useful > > for DECADE. > > > > Looking forward, we envision that DECADE protocols may need additional > > parameters. Investigating this and specifying the parameters could be > done > > in DECADE (should we decide to re-charter for that). > > > > Please note that these two are individual submissions only -- i.e., > merely > > proposals that the group of authors are offering at this point. > > > > Nevertheless, we would be happy for any feedback. > > > > Best regards, > > > > Dirk > > > > > > > > > > _______________________________________________ > > decade mailing list > > decade@ietf.org > > https://www.ietf.org/mailman/listinfo/decade > _______________________________________________ > decade mailing list > decade@ietf.org > https://www.ietf.org/mailman/listinfo/decade > -- Website: http://hallambaker.com/ --f46d0447850bf0640504b0341f82 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think that is the best approach as well.

The WebSec us= e is purely to create a strong reference. I think that if we can get conver= gence on the core spec quickly, the WebSec use should be orthogonal.

The aim here is merely to ensure that we end up with on= e mechanism for specifying digests of referenced objects rather than having= slightly different versions in different groups.


There are many interesting things that can be done with dige= st URIs. Some of which will probably solve problems WebSEC faces. But DECAD= E is clearly the best place to discuss those at the moment.

All that WebSEC will be using for the time being is the ability = to refer to securely a blob of security policy related data in a fashion th= at packages all the crypto gubbins into one string of text.

DECADE is rather different because it is in effect describing a = new and very different form of URL. A traditional URL is a procedural conte= nt link, the content is defined by the means of retrieval. An ni URI is als= o a locator in that it MAY give one (or more) means of locating the data. B= ut the data itself is specified in a functional style. Any method of functi= on evaluation that produces the expected result is equally valid (but not n= ecessarily equally efficient).


I do have some proposals for using the d= igest URI that maybe fall outside both WG charters. This is a notary techno= logy that I think we need. But this is something that simply has to be buil= t on top of DECADE so that it can have the acronym DECADE-Notary Technology= , or DECADENT.

On Wed, Oct 26, 2011 at 9:34 AM, Dirk K= utscher <Di= rk.Kutscher@neclab.eu> wrote:
Rich,

yes, I agree that we should decide that.

Our recommendation would be to do the base spec in DECADE.

Best regards,

Dirk




> -----Original Message-----
> From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com]
> Sent: Mittwoch, 26. Oktober 2011 15:22
> To: Dirk Kutscher; 'decade@ietf= .org'
> Cc: 'cdannewitz@uni= -paderborn.de'; 'ro= b.stradling@comodo.com';
> 'philliph@comodo.com= 9;; Woundy, Richard
> Subject: Re: [decade] URIs for DECADE -- Named Information URI Scheme<= br>
>
> Now that we have established that websec and decade are at least
> interested in the named information uri scheme, do we know what group = is
> expected to own the base specification? That might be a good topic to<= br> > discuss with the relevant ADs in email now and at IETF 82 in person (a= pp and
> tsv at least).
>
> ----- Original Message -----
> From: Dirk Kutscher [mailto:Dirk.Kutscher@neclab.eu]
> Sent: Wednesday, October 26, 2011 09:06 AM
> To: decade ietf <decade@ietf.org= >
> Cc: Christian Dannewitz =A0 =A0 =A0 (cdannewitz@uni-paderborn.de) <cdannewitz@uni-
> paderborn.de>= ; Rob Stradling (rob.stradling@= comodo.com)
> <rob.stradling@comodo.c= om>; philliph@comodo.com<= br> > <philliph@comodo.com>=
> Subject: [decade] URIs for DECADE -- Named Information URI Scheme
>
> Dear all,
>
> We have updated the Named Information URI scheme that we presented at<= br> > IETF-81.
>
> It turned out that the WEBSEC folks (Phillip Hallam-Baker and colleagu= es) had
> started a parallel effort on a very similar approach, and -- fortunate= ly -- we
> have been able to combine our efforts and have advanced the spec so th= at it
> would be useful for DECADE, WEBSEC and potentially other applications.=
>
> We still think that DECADE could benefit most at this time, so we subm= itted
> this (as an individual submission) to DECADE now.
>
> We found a, IMO, nice way to have a concise base specification without=
> excluding extensions for future application requirements. Basically, t= here is
> an extension mechanism that allows applications to specify additional<= br> > parameters.
>
> To make this manageable, we have split the specification into two piec= es:
>
> The base spec:
>
> http://tools.ietf.org/html/draft-farrell-decade-ni-00
>
> This document defines a URI-based name form that identifies a named > object via hash-based binding. =A0The URI name form defined is intende= d =A0for
> use in applications that need to uniquely identify resources in a =A0l= ocation-
> independent way such as accessing in-network storage =A0(DECADE),
> information-centric networking and more generally. =A0The format is de= signed
> to support a strong link to the referenced object =A0such that the ref= erenced
> object may be authenticated to the same =A0degree as the reference to = it.
>
> The base spec has a set of useful general features (in addition to the= actual
> syntax definition), such as processing rules (testing for equality), a= nd an
> algorithm that can be used to map NI URIs to HTTP(S) automatically -- = which I
> believe could be useful for DECADE, too. The base spec also defines th= e
> fundamentals of the extension mechanism.
>
>
> A spec that defines a set of extension parameters and their semantics:=
>
> http://tools.ietf.org/html/draft-hallambaker-decad= e-ni-params-00
> This document specifies some optional algorithms and parameters that m= ay
> be used in the query string of ni URIs.
>
> One of the parameters that we have introduced here would allow you to<= br> > specify additional locators for resources -- again, that is expected t= o be useful
> for DECADE.
>
> Looking forward, we envision that DECADE protocols may need additional=
> parameters. Investigating this and specifying the parameters could be = done
> in DECADE (should we decide to re-charter for that).
>
> Please note that these two are individual submissions only -- i.e., me= rely
> proposals that the group of authors are offering at this point.
>
> Nevertheless, we would be happy for any feedback.
>
> Best regards,
>
> Dirk
>
>
>
>
> _______________________________________________
> decade mailing list
> decade@ietf.org
> https://www.ietf.org/mailman/listinfo/decade
_______________________________________________
decade mailing list
decade@ietf.org
= https://www.ietf.org/mailman/listinfo/decade



--
= Website: http://hallambaker.com/
--f46d0447850bf0640504b0341f82-- From stpeter@stpeter.im Wed Oct 26 13:06:07 2011 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 B3A481F0C3D for ; Wed, 26 Oct 2011 13:06:07 -0700 (PDT) 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 GWZrTfGoOCAT for ; Wed, 26 Oct 2011 13:06:07 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 01BF51F0C3B for ; Wed, 26 Oct 2011 13:06:07 -0700 (PDT) Received: from leavealone.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id F0B18404FF for ; Wed, 26 Oct 2011 14:11:22 -0600 (MDT) Message-ID: <4EA8682C.6030408@stpeter.im> Date: Wed, 26 Oct 2011 14:06:04 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: websec@ietf.org References: <059.68b3829b8b302d37dcc16c589b51048e@trac.tools.ietf.org> In-Reply-To: <059.68b3829b8b302d37dcc16c589b51048e@trac.tools.ietf.org> X-Enigmail-Version: 1.3.2 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [websec] #25: what, if any, sniffing for fonts is required? 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, 26 Oct 2011 20:06:07 -0000 On 10/25/11 4:35 PM, websec issue tracker wrote: > #25: what, if any, sniffing for fonts is required? > > The current spec has a stub for sniffing fonts. > The use case for this was @font-face, CSS' font linking feature. > The request came in http://www.ietf.org/mail- > archive/web/websec/current/msg00235.html > > However, "That seems very anecdotal. Do you have data to back up these > claims?" (in this case, "data" = "significant use cases where sniffing is > necessary"). > > > http://lists.w3.org/Archives/Public/public-webfonts-wg/2011Apr/0005.html > http://lists.w3.org/Archives/Public/public-webfonts-wg/2011Apr/0012.html > > Reading those, it looks like there was some disagreement about what types > ought to be registered. This seems like a case where there are multiple > type definitions which can be distinguished by magic number or other usage > patterns, and the question is whether to register them as separate types > or to use a single type and disambiguate later in the process at the > receiver. > > In any case, we need to resolve what font sniffing is necessary, what > should be sniffed, etc. > I will bring this up during next Monday's joint meeting of the WebFonts, WebAppSec and CSS WGs at the W3C plenary. Peter -- Peter Saint-Andre https://stpeter.im/ From Jeff.Hodges@KingsMountain.com Thu Oct 27 11:03:42 2011 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 73F2021F8B06 for ; Thu, 27 Oct 2011 11:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.495 X-Spam-Level: X-Spam-Status: No, score=-100.495 tagged_above=-999 required=5 tests=[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 y3CIUQRNEKg7 for ; Thu, 27 Oct 2011 11:03:41 -0700 (PDT) Received: from oproxy5-pub.bluehost.com (oproxy5.bluehost.com [IPv6:2605:dc00:100:2::a5]) by ietfa.amsl.com (Postfix) with SMTP id C79DC21F88A0 for ; Thu, 27 Oct 2011 11:03:41 -0700 (PDT) Received: (qmail 26010 invoked by uid 0); 27 Oct 2011 18:03:41 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy2.bluehost.com with SMTP; 27 Oct 2011 18:03:41 -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=WBfB0bC0ackUqwbsDXBWdqdMJ9pru9J3h5Kw3I2Ot2o=; b=irjLqUVNEZjmOhOIWOUI8HM7Pv1C70Ajtw63vkvcACK2R0gNJtI+oOXUSyNkIEQBmvL9EOoj+fmMlcpISQDGWgS8eQKrQcuzSjxwD6jR2V8n9aTuztaPxApkJYgERjx1; 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 1RJUIn-0000kE-6d; Thu, 27 Oct 2011 12:03:41 -0600 Message-ID: <4EA99CFB.30801@KingsMountain.com> Date: Thu, 27 Oct 2011 11:03:39 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Julian Reschke , "Ryan Sleevi" , 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] 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, 27 Oct 2011 18:03:42 -0000 I've been working with Julian on simplifying the STS header field syntax. Here's where it's presently at -- thoughts? thanks again to Julian and Ryan for their earlier feedback. =JeffH ### 5.1. Strict-Transport-Security HTTP Response Header Field The Strict-Transport-Security HTTP response header field indicates to a UA that it MUST enforce the HSTS Policy in regards to the host emitting the response message containing this header field. Note: this specification uses the augmented BNF (ABNF) notation from Section 2 of [RFC2616], including its rules for "implied linear whitespace (LWS)", and case-insensitivity of quoted-string literals. The ABNF syntax for the Strict-Transport-Security (STS) HTTP Response Header field is: Strict-Transport-Security = "Strict-Transport-Security" ":" directive *( ";" [ directive ] ) STS directives: directive = max-age | includeSubDomains | STS-d-ext max-age = "max-age" "=" delta-seconds includeSubDomains = "includeSubDomains" The max-age directive MUST appear once in the Strict-Transport-Security header field value. The includeSubDomains directive MAY appear once. The order of appearance of directives in the Strict-Transport-Security header field value is not significant. Additional directives extending the the semantic functionality of the Strict-Transport-Security header field may be defined in other specifications, using the STS directive extension point (STS-d-ext) syntax: STS-d-ext = token [ "=" ( token | quoted-string ) ] Defined in [RFC2616]: delta-seconds = <1*DIGIT, defined in [RFC2616], Section 3.3.2> token = quoted-string = ### From julian.reschke@gmx.de Thu Oct 27 12:27:42 2011 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 A6E1611E807F for ; Thu, 27 Oct 2011 12:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.304 X-Spam-Level: X-Spam-Status: No, score=-104.304 tagged_above=-999 required=5 tests=[AWL=-1.705, 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 rJfLHCYSCQ99 for ; Thu, 27 Oct 2011 12:27:42 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id E8EE911E8089 for ; Thu, 27 Oct 2011 12:27:37 -0700 (PDT) Received: (qmail invoked by alias); 27 Oct 2011 19:27:31 -0000 Received: from p5DCC2E74.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.46.116] by mail.gmx.net (mp010) with SMTP; 27 Oct 2011 21:27:31 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19MdkMyHr9MordgZdKhfjhLj9Jj/z9/LTEPn3uNWU qUt3DIIEPzSJjr Message-ID: <4EA9B09E.9030001@gmx.de> Date: Thu, 27 Oct 2011 21:27:26 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: =JeffH References: <4EA99CFB.30801@KingsMountain.com> In-Reply-To: <4EA99CFB.30801@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] 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, 27 Oct 2011 19:27:42 -0000 On 2011-10-27 20:03, =JeffH wrote: > I've been working with Julian on simplifying the STS header field > syntax. Here's where it's presently at -- thoughts? > > thanks again to Julian and Ryan for their earlier feedback. > > =JeffH That looks much better to me. More inline. > ### > > 5.1. Strict-Transport-Security HTTP Response Header Field > > The Strict-Transport-Security HTTP response header field indicates to > a UA that it MUST enforce the HSTS Policy in regards to the host > emitting the response message containing this header field. > > Note: this specification uses the augmented BNF (ABNF) notation from > Section 2 of [RFC2616], including its rules for "implied linear > whitespace (LWS)", and case-insensitivity of quoted-string literals. > > The ABNF syntax for the Strict-Transport-Security (STS) HTTP Response > Header field is: > > > Strict-Transport-Security = "Strict-Transport-Security" ":" > directive *( ";" [ directive ] ) > > STS directives: > > directive = max-age | includeSubDomains | STS-d-ext > > max-age = "max-age" "=" delta-seconds What happens with max-age="1" ? Do you expect all recipients to reject this? Depending on the parsing API they use they might not even know that the value was quoted on the wire. > includeSubDomains = "includeSubDomains" There's a tiny risk that some implementations will handle value-less parameters the same way as parameters with empty values, such as includeSubDomains= or includeSubDomains="" but maybe I'm over-engineering here. (To get this right an API will need to distinguish between "parameter missing", "parameter present and valueless" and "parameter present and having a zero-length value". Also, identifiers "max-age" and "includeSubDomains" are case-insensitive, right? This follows from the ABNF, but might be worth saying again in prose; in particular because it also needs to be the case for all future extensions. > The max-age directive MUST appear once in the Strict-Transport-Security > header field value. The includeSubDomains directive MAY appear once. > The order of appearance of directives in the Strict-Transport-Security > header field value is not significant. > > Additional directives extending the the semantic functionality of > the Strict-Transport-Security header field may be defined in other > specifications, using the STS directive extension point (STS-d-ext) > syntax: > > STS-d-ext = token [ "=" ( token | quoted-string ) ] > > > Defined in [RFC2616]: > > delta-seconds = <1*DIGIT, defined in [RFC2616], Section 3.3.2> > token = > quoted-string = > > > ### Best regards, Julian From ietf@adambarth.com Thu Oct 27 23:47:58 2011 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 99F571F0C42 for ; Thu, 27 Oct 2011 23:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.325 X-Spam-Level: X-Spam-Status: No, score=-2.325 tagged_above=-999 required=5 tests=[AWL=0.652, 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 tgggbwrNLLbJ for ; Thu, 27 Oct 2011 23:47:58 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 091671F0C54 for ; Thu, 27 Oct 2011 23:47:57 -0700 (PDT) Received: by gyh20 with SMTP id 20so4033173gyh.31 for ; Thu, 27 Oct 2011 23:47:57 -0700 (PDT) Received: by 10.101.65.12 with SMTP id s12mr213165ank.88.1319784477528; Thu, 27 Oct 2011 23:47:57 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by mx.google.com with ESMTPS id z15sm22109868anl.15.2011.10.27.23.47.53 (version=SSLv3 cipher=OTHER); Thu, 27 Oct 2011 23:47:53 -0700 (PDT) Received: by ywt2 with SMTP id 2so4014532ywt.31 for ; Thu, 27 Oct 2011 23:47:53 -0700 (PDT) Received: by 10.236.131.106 with SMTP id l70mr1410840yhi.29.1319784473386; Thu, 27 Oct 2011 23:47:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.103.37 with HTTP; Thu, 27 Oct 2011 23:47:22 -0700 (PDT) In-Reply-To: <4EA99CFB.30801@KingsMountain.com> References: <4EA99CFB.30801@KingsMountain.com> From: Adam Barth Date: Thu, 27 Oct 2011 23:47:22 -0700 Message-ID: To: "=JeffH" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: Fri, 28 Oct 2011 06:47:58 -0000 On Thu, Oct 27, 2011 at 11:03 AM, =3DJeffH = wrote: > I've been working with Julian on simplifying the STS header field syntax. > Here's where it's presently at -- thoughts? > > thanks again to Julian and Ryan for their earlier feedback. > > =3DJeffH > > > ### > > 5.1. Strict-Transport-Security HTTP Response Header Field > > =A0 The Strict-Transport-Security HTTP response header field indicates to > =A0 a UA that it MUST enforce the HSTS Policy in regards to the host > =A0 emitting the response message containing this header field. > > =A0 Note: this specification uses the augmented BNF (ABNF) notation from > =A0 Section 2 of [RFC2616], including its rules for "implied linear > =A0 whitespace (LWS)", and case-insensitivity of quoted-string literals. > > =A0 The ABNF syntax for the Strict-Transport-Security (STS) HTTP Response > =A0 Header field is: > > > =A0 =A0Strict-Transport-Security =3D "Strict-Transport-Security" ":" > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0directive = *( ";" [ directive ] ) > > > =A0 STS directives: > > =A0 =A0directive =A0 =A0 =A0 =A0 =3D max-age | includeSubDomains | STS-d-= ext > > =A0 =A0max-age =A0 =A0 =A0 =A0 =A0 =3D "max-age" "=3D" delta-seconds > > =A0 =A0includeSubDomains =3D "includeSubDomains" > > > =A0 The max-age directive MUST appear once in the Strict-Transport-Securi= ty > =A0 header field value. The includeSubDomains directive MAY appear once. > =A0 The order of appearance of directives in the Strict-Transport-Securit= y > =A0 header field value is not significant. > > =A0 Additional directives extending the the semantic functionality of > =A0 the Strict-Transport-Security header field may be defined in other MAY or might ? > =A0 specifications, using the STS directive extension point (STS-d-ext) > =A0 syntax: > > =A0 =A0STS-d-ext =A0 =A0 =3D token [ "=3D" ( token | quoted-string ) ] > > > =A0 Defined in [RFC2616]: > > =A0 =A0delta-seconds =3D <1*DIGIT, defined in [RFC2616], Section 3.3.2> > =A0 =A0token =A0 =A0 =A0 =A0 =3D > =A0 =A0quoted-string =3D > > > ### > > > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > From tobias.gondrom@gondrom.org Fri Oct 28 00:56:17 2011 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 95C0121F84D8 for ; Fri, 28 Oct 2011 00:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.676 X-Spam-Level: X-Spam-Status: No, score=-96.676 tagged_above=-999 required=5 tests=[AWL=0.102, 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 qbN8dxq6APT6 for ; Fri, 28 Oct 2011 00:56:17 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id 7D69221F84D7 for ; Fri, 28 Oct 2011 00:56:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=O/dpvpfDyiFvzelSAJSgNOFI1CfVZcbISRYYOrFV0coDGnzrB8o0lCsDjfKBIqM9r2dlZZ1UalVbqIGIxEb9OdwcE/TXfqyC6NA/AJS6J5HIobf5ZnUc2FyEv/NNQ/Tl; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Priority:Content-Type:Content-Transfer-Encoding; Received: (qmail 21917 invoked from network); 28 Oct 2011 09:56:07 +0200 Received: from unknown (HELO ?10.5.5.61?) (61.8.220.69) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 28 Oct 2011 09:56:06 +0200 Message-ID: <4EAA6013.7040008@gondrom.org> Date: Fri, 28 Oct 2011 08:56:03 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: websec@ietf.org X-Priority: 4 (Low) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [websec] reminder: Internet Draft final submission cut-off by 2011-10-31 (Monday) at 17:00 PT 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, 28 Oct 2011 07:56:17 -0000 Hi guys, just a quick reminder in case some of your are still working on updates of current drafts: The cut-off date for I-D updates is on Monday (Oct-31, 17:00 PT) Kind regards and looking forward to seeing you all in Taipei! Tobias (websec chair) From masinter@adobe.com Fri Oct 28 01:28:21 2011 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 CD2CE21F8AF4 for ; Fri, 28 Oct 2011 01:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.044 X-Spam-Level: X-Spam-Status: No, score=-105.044 tagged_above=-999 required=5 tests=[AWL=-0.859, BAYES_40=-0.185, 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 vlfqKHf+Zmz1 for ; Fri, 28 Oct 2011 01:28:20 -0700 (PDT) Received: from exprod6ob110.obsmtp.com (exprod6ob110.obsmtp.com [64.18.1.24]) by ietfa.amsl.com (Postfix) with ESMTP id B0C8D21F8AF0 for ; Fri, 28 Oct 2011 01:28:20 -0700 (PDT) Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob110.postini.com ([64.18.5.12]) with SMTP; Fri, 28 Oct 2011 01:28:20 PDT 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 p9S8QUGh017882 for ; Fri, 28 Oct 2011 01:26:31 -0700 (PDT) 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 p9S8S75R014652 for ; Fri, 28 Oct 2011 01:28:07 -0700 (PDT) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nahub01.corp.adobe.com ([10.8.189.97]) with mapi; Fri, 28 Oct 2011 01:28:07 -0700 From: Larry Masinter To: "websec@ietf.org" Date: Fri, 28 Oct 2011 01:28:02 -0700 Thread-Topic: Sniffing test suite? Thread-Index: AcyVS4Iscl/3uai0T1SYbJiRYJ+zgw== 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] Sniffing test suite? 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, 28 Oct 2011 08:28:21 -0000 http://greenbytes.de/tech/tc/httpcontenttype/ might be a model for building up a sniffing test suite for HTTP (the sniff= ing test suite for ftp and file -- and others -- would have to be coordinat= ed.) From Jeff.Hodges@KingsMountain.com Fri Oct 28 19:36:39 2011 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 A294811E8089 for ; Fri, 28 Oct 2011 19:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.084 X-Spam-Level: X-Spam-Status: No, score=-100.084 tagged_above=-999 required=5 tests=[AWL=0.411, 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 bRVkK-Td1kXh for ; Fri, 28 Oct 2011 19:36:39 -0700 (PDT) Received: from oproxy4-pub.bluehost.com (oproxy4.bluehost.com [IPv6:2605:dc00:100:2::a4]) by ietfa.amsl.com (Postfix) with SMTP id 63AB621F84B1 for ; Fri, 28 Oct 2011 19:36:38 -0700 (PDT) Received: (qmail 3031 invoked by uid 0); 29 Oct 2011 02:36:37 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy1.bluehost.com with SMTP; 29 Oct 2011 02:36: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=7KUeFo5iWbreTaqDhGLR6hepI3nYYT9NaXwnZVdhsdI=; b=Su7rMnFLOh+J9YNtiFNHgoM94Yi+1jTCXnS/CNVzfVkHD8cUjZjG7tPefXskyq8UBP1p4P6bDpSgQEPuwvmTr6+jPjNeQrhqeDnWJ+xRzxwrx2Agv2VvZhReoI92Qoai; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.136.242]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1RJymj-0000Wl-JJ; Fri, 28 Oct 2011 20:36:37 -0600 Message-ID: <4EAB66B3.4090404@KingsMountain.com> Date: Fri, 28 Oct 2011 19:36:35 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Julian Reschke , Ryan Sleevi , 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] 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, 29 Oct 2011 02:36:39 -0000 >> Strict-Transport-Security = "Strict-Transport-Security" ":" >> directive *( ";" [ directive ] ) >> >> STS directives: >> >> directive = max-age | includeSubDomains | STS-d-ext >> >> max-age = "max-age" "=" delta-seconds > > What happens with > > max-age="1" > > ? > > Do you expect all recipients to reject this? Depending on the parsing > API they use they might not even know that the value was quoted on the wire. Offhand, I'm not super sure, but after thinking about it while researching/writing the below, I'm thinking "yes", max-age="1" is invalid according to the ABNF and we should do whatever we do in error cases (which is a separate open question). But implementors' parsing API and its problems are out-of-scope for a spec such as this. This obviously isn't the first HTTP response header field with such a syntax and thus these potential issues (this one with a delta-seconds value, and the issue you note below wrt "includeSubDomains"), yes? In doing a quick grep on RFCs for delta-seconds, I note that some of the specs using it (I didn't look at them all) appear to not directly address the case above. Except for RFC6265, which in the algorithm for parsing "Max-Age=", it algorithmically provides for ignoring a value that doesn't match the effective value ABNF of.. ["-"]*DIGIT ..which would catch the max-age="1" case, but doesn't seem to explicitly address.. max-age= But in any case, perhaps (additional) browser implementor folk could chime in here -- do we really need to address such detail-level issues (both of the examples above and below) in the syntax/grammar we specify in specs such as these? Or is the new ABNF proposed in the original message in this thread sufficient? > > includeSubDomains = "includeSubDomains" > > There's a tiny risk that some implementations will handle value-less > parameters the same way as parameters with empty values, such as > > includeSubDomains= > > or > > includeSubDomains="" > > but maybe I'm over-engineering here. Yes, I'm wondering if this might be over-engineering -- I note that in RFC 6266 you didn't distinguish/address this sort of case for "inline" or "attachment" -- are you feeling now that you should have, and thus we ought to do so going forward? > Also, identifiers "max-age" and "includeSubDomains" are > case-insensitive, right? This follows from the ABNF, yes, and yes. > but might be worth > saying again in prose; in particular because it also needs to be the > case for all future extensions. Agreed. I see how you did it in RFC 6266 and will endeavor to do similarly. thanks again, =JeffH From Jeff.Hodges@KingsMountain.com Fri Oct 28 19:42:21 2011 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 560F821F846D for ; Fri, 28 Oct 2011 19:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.166 X-Spam-Level: X-Spam-Status: No, score=-100.166 tagged_above=-999 required=5 tests=[AWL=0.329, 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 tvn+UFIgBSkP for ; Fri, 28 Oct 2011 19:42:20 -0700 (PDT) Received: from oproxy8-pub.bluehost.com (oproxy8.bluehost.com [IPv6:2605:dc00:100:2::a8]) by ietfa.amsl.com (Postfix) with SMTP id BF87221F8467 for ; Fri, 28 Oct 2011 19:42:20 -0700 (PDT) Received: (qmail 1706 invoked by uid 0); 29 Oct 2011 02:42:19 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy8.bluehost.com with SMTP; 29 Oct 2011 02:42:19 -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=MEHr3o5AUgq4tOp3DQat0xjSiUzEJRTa1Lpg4cjFg5A=; b=E4EPMUpuWj+MqVWMW3O7rxu2nCX9N4f0U2COwMSDydDGPK6Wb9TK4/uXoC0ygorGhw6VCmFLtCtmHjJMhRE4a7IHGd5KKe2v7xJxbkTHj6b+avi0+s0M/LS1kGy2nqoM; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.136.242]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1RJysF-0005MJ-2V; Fri, 28 Oct 2011 20:42:19 -0600 Message-ID: <4EAB6808.7030006@KingsMountain.com> Date: Fri, 28 Oct 2011 19:42:16 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Julian Reschke , Ryan Sleevi , 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 216.113.168.128 authed with jeff.hodges+kingsmountain.com} 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: Sat, 29 Oct 2011 02:42:21 -0000 >> The max-age directive MUST appear once in the Strict-Transport-Security >> header field value. The includeSubDomains directive MAY appear once. >> The order of appearance of directives in the Strict-Transport-Security >> header field value is not significant. >> >> Additional directives extending the the semantic functionality of >> the Strict-Transport-Security header field may be defined in other > > MAY or might ? yes, a good question. I believe that there's examples in other RFCs of the use of the lower-case "may" in situations similar to this (I've seen it discussed many times over the years). I.e., not all instances of "may" in any given RFC are capitalized "MAY"s. In this case, "MAY" isn't appropriate IIRC. And yes, a way to avoid that question/issue is to use a different word such as "might" or "can", which i can do. I just thought a "may" has more correct connotations (but I /knew/ it'd come up as a question :) thanks, =JeffH From ietf@adambarth.com Fri Oct 28 20:09:09 2011 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 D599A1F0C3D for ; Fri, 28 Oct 2011 20:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.364 X-Spam-Level: X-Spam-Status: No, score=-2.364 tagged_above=-999 required=5 tests=[AWL=0.613, 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 rroy8LnD1vRw for ; Fri, 28 Oct 2011 20:09:09 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 01C9F1F0C35 for ; Fri, 28 Oct 2011 20:09:08 -0700 (PDT) Received: by iabn5 with SMTP id n5so5944337iab.31 for ; Fri, 28 Oct 2011 20:09:08 -0700 (PDT) Received: by 10.231.82.12 with SMTP id z12mr1841518ibk.36.1319857747483; Fri, 28 Oct 2011 20:09:07 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id dd36sm8165933ibb.7.2011.10.28.20.09.05 (version=SSLv3 cipher=OTHER); Fri, 28 Oct 2011 20:09:05 -0700 (PDT) Received: by iabn5 with SMTP id n5so5944283iab.31 for ; Fri, 28 Oct 2011 20:09:05 -0700 (PDT) Received: by 10.231.47.206 with SMTP id o14mr1834960ibf.18.1319857745061; Fri, 28 Oct 2011 20:09:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.205.195 with HTTP; Fri, 28 Oct 2011 20:08:34 -0700 (PDT) In-Reply-To: <4EAB66B3.4090404@KingsMountain.com> References: <4EAB66B3.4090404@KingsMountain.com> From: Adam Barth Date: Fri, 28 Oct 2011 20:08:34 -0700 Message-ID: To: "=JeffH" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: Sat, 29 Oct 2011 03:09:10 -0000 On Fri, Oct 28, 2011 at 7:36 PM, =3DJeffH w= rote: >>> Strict-Transport-Security =3D "Strict-Transport-Security" ":" >>> directive *( ";" [ directive ] ) >>> >>> STS directives: >>> >>> directive =3D max-age | includeSubDomains | STS-d-ext >>> >>> max-age =3D "max-age" "=3D" delta-seconds >> >> What happens with >> >> =A0 =A0max-age=3D"1" >> >> ? >> >> Do you expect all recipients to reject this? Depending on the parsing >> API they use they might not even know that the value was quoted on the >> wire. > > Offhand, I'm not super sure, but after thinking about it while > researching/writing the below, I'm thinking "yes", max-age=3D"1" is inval= id > according to the ABNF and we should do whatever we do in error cases (whi= ch > is a separate open question). But implementors' parsing API and its probl= ems > are out-of-scope for a spec such as this. > > This obviously isn't the first HTTP response header field with such a syn= tax > and thus these potential issues (this one with a delta-seconds value, and > the issue you note below wrt "includeSubDomains"), yes? > > In doing a quick grep on RFCs for delta-seconds, I note that some of the > specs using it (I didn't look at them all) appear to not directly address > the case above. > > Except for RFC6265, which in the algorithm for parsing "Max-Age=3D", it > algorithmically provides for ignoring a value that doesn't match the > effective value ABNF of.. > > =A0["-"]*DIGIT > > ..which would catch the max-age=3D"1" case, but doesn't seem to explicitl= y > address.. > > =A0max-age=3D That's handled by some more general processing rules in the spec. The net result is that it's ignored. > But in any case, perhaps (additional) browser implementor folk could chim= e > in here -- do we really need to address such detail-level issues (both of > the examples above and below) in the syntax/grammar we specify in specs s= uch > as these? Or is the new ABNF proposed in the original message in this thr= ead > sufficient? Generally, we prefer to be instructed exactly how to behave for every possible input (even illegal ones). There's a long history of quoted-string not being implemented correctly by browsers. I spec this as just splitting the string on ; and then processing each substring separately, ignoring bogus/future ones. I know Julian has a dream that all HTTP headers will be parsed the same, but quoted-string is sufficiently ill-defined w.r.t. error handling that I prefer to avoid it. >> > includeSubDomains =3D "includeSubDomains" >> >> There's a tiny risk that some implementations will handle value-less >> parameters the same way as parameters with empty values, such as >> >> =A0 =A0includeSubDomains=3D >> >> or >> >> =A0 =A0includeSubDomains=3D"" >> >> but maybe I'm over-engineering here. > > Yes, I'm wondering if this might be over-engineering -- I note that in > RFC 6266 you didn't distinguish/address this sort of case for "inline" or > "attachment" -- are you feeling now that you should have, and thus we oug= ht > to do so going forward? > > >> Also, identifiers "max-age" and "includeSubDomains" are >> case-insensitive, right? This follows from the ABNF, > > yes, and yes. > >> but might be worth >> saying again in prose; in particular because it also needs to be the >> case for all future extensions. > > Agreed. I see how you did it in RFC 6266 and will endeavor to do similarl= y. > > thanks again, > > =3DJeffH > > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > From julian.reschke@gmx.de Fri Oct 28 23:59:08 2011 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 C1AAD21F84AE for ; Fri, 28 Oct 2011 23:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.401 X-Spam-Level: X-Spam-Status: No, score=-104.401 tagged_above=-999 required=5 tests=[AWL=-1.802, 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 khue4Why7rtp for ; Fri, 28 Oct 2011 23:59:08 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 2697F21F84AD for ; Fri, 28 Oct 2011 23:59:03 -0700 (PDT) Received: (qmail invoked by alias); 29 Oct 2011 06:59:01 -0000 Received: from p5DCC93A7.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.147.167] by mail.gmx.net (mp046) with SMTP; 29 Oct 2011 08:59:01 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/XULIRWC3XALAFJl+fq/NUn6PMxQndRv0s2zieJa 9vNwg1zf+XSFjj Message-ID: <4EABA42F.2070900@gmx.de> Date: Sat, 29 Oct 2011 08:58:55 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: =JeffH References: <4EAB6808.7030006@KingsMountain.com> In-Reply-To: <4EAB6808.7030006@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] 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, 29 Oct 2011 06:59:08 -0000 On 2011-10-29 04:42, =JeffH wrote: > >> The max-age directive MUST appear once in the Strict-Transport-Security > >> header field value. The includeSubDomains directive MAY appear once. > >> The order of appearance of directives in the Strict-Transport-Security > >> header field value is not significant. > >> > >> Additional directives extending the the semantic functionality of > >> the Strict-Transport-Security header field may be defined in other > > > > MAY or might ? > > yes, a good question. > > I believe that there's examples in other RFCs of the use of the > lower-case "may" in situations similar to this (I've seen it discussed > many times over the years). I.e., not all instances of "may" in any > given RFC are capitalized "MAY"s. In this case, "MAY" isn't appropriate > IIRC. > > And yes, a way to avoid that question/issue is to use a different word > such as "might" or "can", which i can do. I just thought a "may" has > more correct connotations (but I /knew/ it'd come up as a question :) > > thanks, +1 to "can" From julian.reschke@gmx.de Sat Oct 29 00:59:36 2011 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 E77DA21F8495 for ; Sat, 29 Oct 2011 00:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.358 X-Spam-Level: X-Spam-Status: No, score=-104.358 tagged_above=-999 required=5 tests=[AWL=-1.759, 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 6tRZcwbzridZ for ; Sat, 29 Oct 2011 00:59:36 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 93BD121F8493 for ; Sat, 29 Oct 2011 00:59:35 -0700 (PDT) Received: (qmail invoked by alias); 29 Oct 2011 07:59:33 -0000 Received: from p5DCC93A7.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.147.167] by mail.gmx.net (mp001) with SMTP; 29 Oct 2011 09:59:33 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+8DD5pSHW8+D1P3Z1LyX3swU0J2UhOShrKNJy/FM /ajP/mo5paWcM5 Message-ID: <4EABB25E.9000900@gmx.de> Date: Sat, 29 Oct 2011 09:59:26 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: =JeffH References: <4EAB66B3.4090404@KingsMountain.com> In-Reply-To: <4EAB66B3.4090404@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] 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, 29 Oct 2011 07:59:37 -0000 On 2011-10-29 04:36, =JeffH wrote: > >> Strict-Transport-Security = "Strict-Transport-Security" ":" > >> directive *( ";" [ directive ] ) > >> > >> STS directives: > >> > >> directive = max-age | includeSubDomains | STS-d-ext > >> > >> max-age = "max-age" "=" delta-seconds > > > > What happens with > > > > max-age="1" > > > > ? > > > > Do you expect all recipients to reject this? Depending on the parsing > > API they use they might not even know that the value was quoted on > the wire. > > Offhand, I'm not super sure, but after thinking about it while > researching/writing the below, I'm thinking "yes", max-age="1" is > invalid according to the ABNF and we should do whatever we do in error > cases (which is a separate open question). But implementors' parsing API > and its problems are out-of-scope for a spec such as this. They are out-of-scope in that we don't specify them. But we still should consider what's likely to be implemented, and the cost of not being able to re-use a generic parser. > This obviously isn't the first HTTP response header field with such a > syntax and thus these potential issues (this one with a delta-seconds > value, and the issue you note below wrt "includeSubDomains"), yes? Indeed. It's just I've been paying more attention to these kinds of issues recently :-) > > > includeSubDomains = "includeSubDomains" > > > > There's a tiny risk that some implementations will handle value-less > > parameters the same way as parameters with empty values, such as > > > > includeSubDomains= > > > > or > > > > includeSubDomains="" > > > > but maybe I'm over-engineering here. > > Yes, I'm wondering if this might be over-engineering -- I note that in > RFC 6266 you didn't distinguish/address this sort of case for "inline" > or "attachment" -- are you feeling now that you should have, and thus we > ought to do so going forward? > ... That case is a bit different as this is a stand-alone token, and there do not seem to be any header fields that are similar to C-D but allow a quoted-string in the first position. Also see -- some recipients reject it, some don't. This is not a big issue per se, unless those you reject it are forced to follow suite because senders start to rely on it. > ... Best regards, Julian From julian.reschke@gmx.de Sat Oct 29 01:07:36 2011 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 6DAF121F86C1 for ; Sat, 29 Oct 2011 01:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.316 X-Spam-Level: X-Spam-Status: No, score=-104.316 tagged_above=-999 required=5 tests=[AWL=-1.717, 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 CgmpraPuux+u for ; Sat, 29 Oct 2011 01:07:36 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 8337021F86AA for ; Sat, 29 Oct 2011 01:07:35 -0700 (PDT) Received: (qmail invoked by alias); 29 Oct 2011 08:07:34 -0000 Received: from p5DCC93A7.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.147.167] by mail.gmx.net (mp065) with SMTP; 29 Oct 2011 10:07:34 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/8HNxCXQX8ZJ1PXBsL/mflag4/w4rsT9RM5X2lhG G9K6ffyb5alE4x Message-ID: <4EABB440.1030906@gmx.de> Date: Sat, 29 Oct 2011 10:07:28 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Adam Barth References: <4EAB66B3.4090404@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] 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, 29 Oct 2011 08:07:36 -0000 On 2011-10-29 05:08, Adam Barth wrote: > ... >> Except for RFC6265, which in the algorithm for parsing "Max-Age=", it >> algorithmically provides for ignoring a value that doesn't match the >> effective value ABNF of.. >> >> ["-"]*DIGIT >> >> ..which would catch the max-age="1" case, but doesn't seem to explicitly >> address.. >> >> max-age= > > That's handled by some more general processing rules in the spec. The > net result is that it's ignored. > >> But in any case, perhaps (additional) browser implementor folk could chime >> in here -- do we really need to address such detail-level issues (both of >> the examples above and below) in the syntax/grammar we specify in specs such >> as these? Or is the new ABNF proposed in the original message in this thread >> sufficient? > > Generally, we prefer to be instructed exactly how to behave for every > possible input (even illegal ones). There's a long history of > quoted-string not being implemented correctly by browsers. I spec > this as just splitting the string on ; and then processing each > substring separately, ignoring bogus/future ones. I know Julian has a > dream that all HTTP headers will be parsed the same, but quoted-string > is sufficiently ill-defined w.r.t. error handling that I prefer to > avoid it. > ... - when discussing generic parsing, we need to distinguish between legacy cases like cookies, and new headers, where we can do better - standardizing handling of broken headers is one thing (and in general I prefer not to), but that doesn't mean that when defining a new header field we shouldn't minimize the things a sender can get wrong; if we know that some recipients will accept both token and quoted-string anyway, then it seems like a good thing to simply allow them both, reducing the number of special-cases in parsing - not sure what you mean by "ill-defined w.r.t. error handling"; it's defined just like most other syntax elements in HTTP -- is there something *specific* to quoted-string you have in mind? Best regards, Julian From ietf@adambarth.com Sat Oct 29 01:11:03 2011 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 2728521F86C1 for ; Sat, 29 Oct 2011 01:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.579, 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 kt2s3Sw+QbBT for ; Sat, 29 Oct 2011 01:11:02 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5B121F85A4 for ; Sat, 29 Oct 2011 01:11:02 -0700 (PDT) Received: by iabn5 with SMTP id n5so6210405iab.31 for ; Sat, 29 Oct 2011 01:11:02 -0700 (PDT) Received: by 10.231.68.136 with SMTP id v8mr2064976ibi.51.1319875862020; Sat, 29 Oct 2011 01:11:02 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id n30sm16091522ibl.4.2011.10.29.01.11.00 (version=SSLv3 cipher=OTHER); Sat, 29 Oct 2011 01:11:00 -0700 (PDT) Received: by iabn5 with SMTP id n5so6210354iab.31 for ; Sat, 29 Oct 2011 01:11:00 -0700 (PDT) Received: by 10.231.6.129 with SMTP id 1mr2064771ibz.31.1319875860144; Sat, 29 Oct 2011 01:11:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.205.195 with HTTP; Sat, 29 Oct 2011 01:10:30 -0700 (PDT) In-Reply-To: <4EABB440.1030906@gmx.de> References: <4EAB66B3.4090404@KingsMountain.com> <4EABB440.1030906@gmx.de> From: Adam Barth Date: Sat, 29 Oct 2011 01:10:30 -0700 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] 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, 29 Oct 2011 08:11:03 -0000 On Sat, Oct 29, 2011 at 1:07 AM, Julian Reschke wro= te: > On 2011-10-29 05:08, Adam Barth wrote: >> >> ... >>> >>> Except for RFC6265, which in the algorithm for parsing "Max-Age=3D", it >>> algorithmically provides for ignoring a value that doesn't match the >>> effective value ABNF of.. >>> >>> =A0["-"]*DIGIT >>> >>> ..which would catch the max-age=3D"1" case, but doesn't seem to explici= tly >>> address.. >>> >>> =A0max-age=3D >> >> That's handled by some more general processing rules in the spec. =A0The >> net result is that it's ignored. >> >>> But in any case, perhaps (additional) browser implementor folk could >>> chime >>> in here -- do we really need to address such detail-level issues (both = of >>> the examples above and below) in the syntax/grammar we specify in specs >>> such >>> as these? Or is the new ABNF proposed in the original message in this >>> thread >>> sufficient? >> >> Generally, we prefer to be instructed exactly how to behave for every >> possible input (even illegal ones). =A0There's a long history of >> quoted-string not being implemented correctly by browsers. =A0I spec >> this as just splitting the string on ; and then processing each >> substring separately, ignoring bogus/future ones. =A0I know Julian has a >> dream that all HTTP headers will be parsed the same, but quoted-string >> is sufficiently ill-defined w.r.t. error handling that I prefer to >> avoid it. >> ... > > - when discussing generic parsing, we need to distinguish between legacy > cases like cookies, and new headers, where we can do better > > - standardizing handling of broken headers is one thing (and in general I > prefer not to), but that doesn't mean that when defining a new header fie= ld > we shouldn't minimize the things a sender can get wrong; if we know that > some recipients will accept both token and quoted-string anyway, then it > seems like a good thing to simply allow them both, reducing the number of > special-cases in parsing > > - not sure what you mean by "ill-defined w.r.t. error handling"; it's > defined just like most other syntax elements in HTTP -- is there somethin= g > *specific* to quoted-string you have in mind? Most of HTTP is ill-defined w.r.t. error handling. We muddle through with reverse engineering. Adam From julian.reschke@gmx.de Sat Oct 29 01:19:43 2011 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 AE45021F84CC for ; Sat, 29 Oct 2011 01:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.276 X-Spam-Level: X-Spam-Status: No, score=-104.276 tagged_above=-999 required=5 tests=[AWL=-1.677, 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 kR88CrtOX+lH for ; Sat, 29 Oct 2011 01:19:43 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id BBDE521F84CB for ; Sat, 29 Oct 2011 01:19:42 -0700 (PDT) Received: (qmail invoked by alias); 29 Oct 2011 08:19:36 -0000 Received: from p5DCC93A7.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.147.167] by mail.gmx.net (mp054) with SMTP; 29 Oct 2011 10:19:36 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+ae2ZX1zuaxzCOhL8uB1Lps4RzyYdx+VhPwCqayw ekTz8zKVfXSOk2 Message-ID: <4EABB712.5000002@gmx.de> Date: Sat, 29 Oct 2011 10:19:30 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Adam Barth References: <4EAB66B3.4090404@KingsMountain.com> <4EABB440.1030906@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] 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, 29 Oct 2011 08:19:43 -0000 On 2011-10-29 10:10, Adam Barth wrote: > On Sat, Oct 29, 2011 at 1:07 AM, Julian Reschke wrote: >> On 2011-10-29 05:08, Adam Barth wrote: >>> >>> ... >>>> >>>> Except for RFC6265, which in the algorithm for parsing "Max-Age=", it >>>> algorithmically provides for ignoring a value that doesn't match the >>>> effective value ABNF of.. >>>> >>>> ["-"]*DIGIT >>>> >>>> ..which would catch the max-age="1" case, but doesn't seem to explicitly >>>> address.. >>>> >>>> max-age= >>> >>> That's handled by some more general processing rules in the spec. The >>> net result is that it's ignored. >>> >>>> But in any case, perhaps (additional) browser implementor folk could >>>> chime >>>> in here -- do we really need to address such detail-level issues (both of >>>> the examples above and below) in the syntax/grammar we specify in specs >>>> such >>>> as these? Or is the new ABNF proposed in the original message in this >>>> thread >>>> sufficient? >>> >>> Generally, we prefer to be instructed exactly how to behave for every >>> possible input (even illegal ones). There's a long history of >>> quoted-string not being implemented correctly by browsers. I spec >>> this as just splitting the string on ; and then processing each >>> substring separately, ignoring bogus/future ones. I know Julian has a >>> dream that all HTTP headers will be parsed the same, but quoted-string >>> is sufficiently ill-defined w.r.t. error handling that I prefer to >>> avoid it. >>> ... >> >> - when discussing generic parsing, we need to distinguish between legacy >> cases like cookies, and new headers, where we can do better >> >> - standardizing handling of broken headers is one thing (and in general I >> prefer not to), but that doesn't mean that when defining a new header field >> we shouldn't minimize the things a sender can get wrong; if we know that >> some recipients will accept both token and quoted-string anyway, then it >> seems like a good thing to simply allow them both, reducing the number of >> special-cases in parsing >> >> - not sure what you mean by "ill-defined w.r.t. error handling"; it's >> defined just like most other syntax elements in HTTP -- is there something >> *specific* to quoted-string you have in mind? > > Most of HTTP is ill-defined w.r.t. error handling. We muddle through > with reverse engineering. > ... It's not ill-defined, but undefined (by design) - see . What I was trying to understand whether there's something special with respect to quoted-string? Best regards, Julian From ietf@adambarth.com Sat Oct 29 01:22:05 2011 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 62E2221F84CC for ; Sat, 29 Oct 2011 01:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.549, 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 GME3RxKPcRqW for ; Sat, 29 Oct 2011 01:22:04 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id BEA0021F8888 for ; Sat, 29 Oct 2011 01:22:04 -0700 (PDT) Received: by iabn5 with SMTP id n5so6220220iab.31 for ; Sat, 29 Oct 2011 01:22:04 -0700 (PDT) Received: by 10.42.144.198 with SMTP id c6mr8882691icv.45.1319876524357; Sat, 29 Oct 2011 01:22:04 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id fu10sm6087951igc.6.2011.10.29.01.22.03 (version=SSLv3 cipher=OTHER); Sat, 29 Oct 2011 01:22:03 -0700 (PDT) Received: by iabn5 with SMTP id n5so6220201iab.31 for ; Sat, 29 Oct 2011 01:22:03 -0700 (PDT) Received: by 10.231.6.129 with SMTP id 1mr2073339ibz.31.1319876523136; Sat, 29 Oct 2011 01:22:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.205.195 with HTTP; Sat, 29 Oct 2011 01:21:32 -0700 (PDT) In-Reply-To: <4EABB712.5000002@gmx.de> References: <4EAB66B3.4090404@KingsMountain.com> <4EABB440.1030906@gmx.de> <4EABB712.5000002@gmx.de> From: Adam Barth Date: Sat, 29 Oct 2011 01:21:32 -0700 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] 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, 29 Oct 2011 08:22:05 -0000 On Sat, Oct 29, 2011 at 1:19 AM, Julian Reschke wro= te: > On 2011-10-29 10:10, Adam Barth wrote: >> >> On Sat, Oct 29, 2011 at 1:07 AM, Julian Reschke >> =A0wrote: >>> >>> On 2011-10-29 05:08, Adam Barth wrote: >>>> >>>> ... >>>>> >>>>> Except for RFC6265, which in the algorithm for parsing "Max-Age=3D", = it >>>>> algorithmically provides for ignoring a value that doesn't match the >>>>> effective value ABNF of.. >>>>> >>>>> =A0["-"]*DIGIT >>>>> >>>>> ..which would catch the max-age=3D"1" case, but doesn't seem to >>>>> explicitly >>>>> address.. >>>>> >>>>> =A0max-age=3D >>>> >>>> That's handled by some more general processing rules in the spec. =A0T= he >>>> net result is that it's ignored. >>>> >>>>> But in any case, perhaps (additional) browser implementor folk could >>>>> chime >>>>> in here -- do we really need to address such detail-level issues (bot= h >>>>> of >>>>> the examples above and below) in the syntax/grammar we specify in spe= cs >>>>> such >>>>> as these? Or is the new ABNF proposed in the original message in this >>>>> thread >>>>> sufficient? >>>> >>>> Generally, we prefer to be instructed exactly how to behave for every >>>> possible input (even illegal ones). =A0There's a long history of >>>> quoted-string not being implemented correctly by browsers. =A0I spec >>>> this as just splitting the string on ; and then processing each >>>> substring separately, ignoring bogus/future ones. =A0I know Julian has= a >>>> dream that all HTTP headers will be parsed the same, but quoted-string >>>> is sufficiently ill-defined w.r.t. error handling that I prefer to >>>> avoid it. >>>> ... >>> >>> - when discussing generic parsing, we need to distinguish between legac= y >>> cases like cookies, and new headers, where we can do better >>> >>> - standardizing handling of broken headers is one thing (and in general= I >>> prefer not to), but that doesn't mean that when defining a new header >>> field >>> we shouldn't minimize the things a sender can get wrong; if we know tha= t >>> some recipients will accept both token and quoted-string anyway, then i= t >>> seems like a good thing to simply allow them both, reducing the number = of >>> special-cases in parsing >>> >>> - not sure what you mean by "ill-defined w.r.t. error handling"; it's >>> defined just like most other syntax elements in HTTP -- is there >>> something >>> *specific* to quoted-string you have in mind? >> >> Most of HTTP is ill-defined w.r.t. error handling. =A0We muddle through >> with reverse engineering. >> ... > > It's not ill-defined, but undefined (by design) - see > . > > What I was trying to understand whether there's something special with > respect to quoted-string? Quoted string is particularly bad because it's hard to know what to do with unbalanced quotation marks. Anyway, I'm resigned to lose this argument in this forum. It just means we'll need to clean up the mess later in another forum. Adam From julian.reschke@gmx.de Sat Oct 29 02:06:50 2011 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 EE5D621F8ACE for ; Sat, 29 Oct 2011 02:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.238 X-Spam-Level: X-Spam-Status: No, score=-104.238 tagged_above=-999 required=5 tests=[AWL=-1.639, 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 RrmBIuTW+xhG for ; Sat, 29 Oct 2011 02:06:50 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 1060221F8ACC for ; Sat, 29 Oct 2011 02:06:49 -0700 (PDT) Received: (qmail invoked by alias); 29 Oct 2011 09:06:47 -0000 Received: from p5DCC93A7.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.147.167] by mail.gmx.net (mp012) with SMTP; 29 Oct 2011 11:06:47 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18UIjdXchEUtttu0y06mB35KsMaD+fGG9pf2BB+Yn H9S4tHvqCnyp8n Message-ID: <4EABC221.2080200@gmx.de> Date: Sat, 29 Oct 2011 11:06:41 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Adam Barth References: <4EAB66B3.4090404@KingsMountain.com> <4EABB440.1030906@gmx.de> <4EABB712.5000002@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] 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, 29 Oct 2011 09:06:51 -0000 On 2011-10-29 10:21, Adam Barth wrote: > ... >> What I was trying to understand whether there's something special with >> respect to quoted-string? > > Quoted string is particularly bad because it's hard to know what to do > with unbalanced quotation marks. > ... So your points were about quoted-string in general, not the question of allowing them for max-age, right? I'm asking because due the possible presence of extension parameters, recipients need to deal with quoted-string anyway, no matter whether they are allowed for max-age. Best regards, Julian From hallam@gmail.com Sat Oct 29 09:47:03 2011 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 6D0EF21F8A67 for ; Sat, 29 Oct 2011 09:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.47 X-Spam-Level: X-Spam-Status: No, score=-3.47 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 LjauWuwQ8xyx for ; Sat, 29 Oct 2011 09:47:02 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4DFE821F8A56 for ; Sat, 29 Oct 2011 09:47:02 -0700 (PDT) Received: by ggnv1 with SMTP id v1so5455019ggn.31 for ; Sat, 29 Oct 2011 09:47:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=hEr4BGR24X7/vCHMLiNu5ir7cN/dTvrZ7WMbuXyHcm0=; b=Oa4IZ19RQTMMdDqXKBM74E4qFW31Iq0WfQM5Mom9hSnB39U2efbkM17WWvP6tT/LLD 4HyKin2JcEym3vjpz60kbSninGOGLYT4+wAOVJ4ihrym2IRwBHwk3l9oDQvS1GG46dGy nyz0AMNLBRuYxTcYTwL4mSvoT/p/cwXZpQYbE= MIME-Version: 1.0 Received: by 10.182.226.33 with SMTP id rp1mr1584679obc.18.1319906821541; Sat, 29 Oct 2011 09:47:01 -0700 (PDT) Received: by 10.182.42.99 with HTTP; Sat, 29 Oct 2011 09:47:01 -0700 (PDT) Date: Sat, 29 Oct 2011 12:47:01 -0400 Message-ID: From: Phillip Hallam-Baker To: websec Content-Type: multipart/alternative; boundary=f46d04446b553c0fd504b072c1b3 Subject: [websec] An alternative approach to Security Policy 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, 29 Oct 2011 16:47:03 -0000 --f46d04446b553c0fd504b072c1b3 Content-Type: text/plain; charset=ISO-8859-1 I submitted a version of this document last week but wanted to get some additional examples in using the new ni URI proposal before raising it on the list. This has now been done: http://www.ietf.org/id/draft-hallambaker-securitypolicy-01.txt This is related to the 'Must use TLS', CA-Pinning and Strict Security work here but separates the security policy framework from the mode of distribution completely. We have been discussing security policy in IETF for quite some time. There seem to be two major technical issues that cause problems: 1) Choice of distribution mechanism 2) False positives due to badly administered systems I think I have found the solution to the first: It does not need to be a choice. There are advantages and disadvantages to each approach. DNS is the authoritative source for statements on the DNS but DNSSEC will not be ready for prime time for many, many years. HTTP headers are expedient but only give security after first contact. And DNS and HTTP headers both suffer from the problem of what to do when the attacker blocks access to the online confirmation mechanism completely. Meanwhile pushing out blocklists of 'hot sites' provides effective security but does not scale' Why choose? Each approach has advantages and disadvantages. So why not have a single language for policy statements that is strictly limited to restrictive statements that can be used to create statements that can be carried over any available transport? The false positives problem is a much bigger problem conceptually than in practice. In theory DKIM policy should be causing all sorts of legitimate mail to be refused delivery. What saves the system is the fact that DKIM statements are only one input into anti-spam filters and is only given the weight the data justifies. I see security policy being applied in HTTP and similar cases in the same way. Statements made by domain name owners will in the first instance serve as advice to companies that provide Internet safety products who will combine the data in the security policy statements with data from other sources to arrive at security decisions. Every attack has a human intelligence in there somewhere. Expecting to have effective security without any human intelligence in the defense is probably a mistake. The second approach to overcoming the 'false positives' issue is to observe that reporting a policy violation has much more value than blocking sites. Blocking sites only protects the users who have the security policy capability configured and enabled. Reporting a policy violation enables remediation that can protect the whole Internet community. Next Steps: This particular draft is intentionally targeted at use in a static interchange format. This would be used for defining local security policies (e.g. configuring all the web browsers at bigcorp.com to impose a particular policy for corporate servers) and to be used for emergency, data-driven response. Clearly this should converge with the Google Policy proposal for HTTP. I don't think that there are major differences and would be astonished if this was incompatible. But a general purpose format designed to support more protocols than HTTP will look a little different to one that is designed to tackle the problem at a higher level. -- Website: http://hallambaker.com/ --f46d04446b553c0fd504b072c1b3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I submitted a version of this document last week but wanted to get some add= itional examples in using the new ni URI proposal before raising it on the = list. This has now been done:


This is related to the 'Must use TLS', CA-Pinni= ng and Strict Security work here but separates the security policy framewor= k from the mode of distribution completely.


We have been discussing security policy in IETF for quite some t= ime. There seem to be two major technical issues that cause problems:
=

1) Choice of distribution mechanism
2) False = positives due to badly administered systems


I think I have found the solution to the= first: It does not need to be a choice. There are advantages and disadvant= ages to each approach. DNS is the authoritative source for statements on th= e DNS but DNSSEC will not be ready for prime time for many, many years. HTT= P headers are expedient but only give security after first contact. And DNS= and HTTP headers both suffer from the problem of what to do when the attac= ker blocks access to the online confirmation mechanism completely. Meanwhil= e pushing out blocklists of 'hot sites' provides effective security= but does not scale'

Why choose? Each approach has advantages and disadvanta= ges. So why not have a single language for policy statements that is strict= ly limited to restrictive statements that can be used to create statements = that can be carried over any available transport?


The false positives problem is a much bi= gger problem conceptually than in practice. In theory DKIM policy should be= causing all sorts of legitimate mail to be refused delivery. What saves th= e system is the fact that DKIM statements are only one input into anti-spam= filters and is only given the weight the data justifies.

I see security policy being applied in HTTP and similar= cases in the same way. Statements made by domain name owners will in the f= irst instance serve as advice to companies that provide Internet safety pro= ducts who will combine the data in the security policy statements with data= from other sources to arrive at security decisions.=A0

Every attack has a human intelligence in there somewher= e. Expecting to have effective security without any human intelligence in t= he defense is probably a mistake.


The second approach to overcoming the 'false positives' issue is to= observe that reporting a policy violation has much more value than blockin= g sites. Blocking sites only protects the users who have the security polic= y capability configured and enabled. Reporting a policy violation enables r= emediation that can protect the whole Internet community.


Next Steps:

Thi= s particular draft is intentionally targeted at use in a static interchange= format. This would be used for defining local security policies (e.g. conf= iguring all the web browsers at bigcorp.com<= /a> to impose a particular policy for corporate servers) and to be used for= emergency, data-driven response.

Clearly this should converge with the Google Policy pro= posal for HTTP. I don't think that there are major differences and woul= d be astonished if this was incompatible. But a general purpose format desi= gned to support more protocols than HTTP will look a little different to on= e that is designed to tackle the problem at a higher level.=A0

--
Website: http://h= allambaker.com/

--f46d04446b553c0fd504b072c1b3-- From hallam@gmail.com Sat Oct 29 11:27:52 2011 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 87C6621F85B1 for ; Sat, 29 Oct 2011 11:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.646 X-Spam-Level: X-Spam-Status: No, score=-2.646 tagged_above=-999 required=5 tests=[AWL=-0.714, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] 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 FR1-7JKEb2Hj for ; Sat, 29 Oct 2011 11:27:51 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id ADF3E21F85A8 for ; Sat, 29 Oct 2011 11:27:51 -0700 (PDT) Received: by ggnv1 with SMTP id v1so5520300ggn.31 for ; Sat, 29 Oct 2011 11:27:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Wsg1QJxFaZSDMDft9mYwZ4Ts0BPUKfVAFFuT94M3lA8=; b=uFZh+NqtC6WTH6+ptwz+JIOfbjLP22FgkhF386nqTnqejxC7Bgz4TJodcN4krIRwq9 wyEYjxJBCfCD0xTRCMAynq/JX+IZE2pRTewTObw9M9CHuTN+8fz6LhcVkVdQp79gGWbG Vckl2bDKra8wKtLHvRrwZdhYGX3WpluX3YlfE= MIME-Version: 1.0 Received: by 10.182.17.103 with SMTP id n7mr1606668obd.68.1319912870387; Sat, 29 Oct 2011 11:27:50 -0700 (PDT) Received: by 10.182.42.99 with HTTP; Sat, 29 Oct 2011 11:27:50 -0700 (PDT) In-Reply-To: <4EABA42F.2070900@gmx.de> References: <4EAB6808.7030006@KingsMountain.com> <4EABA42F.2070900@gmx.de> Date: Sat, 29 Oct 2011 14:27:50 -0400 Message-ID: From: Phillip Hallam-Baker To: Julian Reschke Content-Type: multipart/alternative; boundary=f46d04447429c620ea04b0742986 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: Sat, 29 Oct 2011 18:27:52 -0000 --f46d04447429c620ea04b0742986 Content-Type: text/plain; charset=ISO-8859-1 Use of lowercase may is certainly allowed. But it causes so much hassle as people (1) keep asking if it should be MAY and (2) 'correct' the draft to use upper case. It is easier to try using other words instead. Which is not easy since it tends to crop up all the time in non-normative text. Probably the best long term solution would be to have an XML2RFC tag that declared a section as non-normative so that the nits checker can then catch unintentional uppercasing. On Sat, Oct 29, 2011 at 2:58 AM, Julian Reschke wrote: > On 2011-10-29 04:42, =JeffH wrote: > >> >> The max-age directive MUST appear once in the >> Strict-Transport-Security >> >> header field value. The includeSubDomains directive MAY appear once. >> >> The order of appearance of directives in the Strict-Transport-Security >> >> header field value is not significant. >> >> >> >> Additional directives extending the the semantic functionality of >> >> the Strict-Transport-Security header field may be defined in other >> > >> > MAY or might ? >> >> yes, a good question. >> >> I believe that there's examples in other RFCs of the use of the >> lower-case "may" in situations similar to this (I've seen it discussed >> many times over the years). I.e., not all instances of "may" in any >> given RFC are capitalized "MAY"s. In this case, "MAY" isn't appropriate >> IIRC. >> >> And yes, a way to avoid that question/issue is to use a different word >> such as "might" or "can", which i can do. I just thought a "may" has >> more correct connotations (but I /knew/ it'd come up as a question :) >> >> thanks, >> > > +1 to "can" > > ______________________________**_________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/**listinfo/websec > -- Website: http://hallambaker.com/ --f46d04447429c620ea04b0742986 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Use of lowercase may is certainly allowed.

But it causes= so much hassle as people (1) keep asking if it should be MAY and (2) '= correct' the draft to use upper case.

It is ea= sier to try using other words instead. Which is not easy since it tends to = crop up all the time in non-normative text.


Probably the best long term solution wou= ld be to have an XML2RFC tag that declared a section as non-normative so th= at the nits checker can then catch unintentional uppercasing.


On Sat, Oct 29, 2011 at 2:58 AM, Julian = Reschke <juli= an.reschke@gmx.de> wrote:
On 2011-10-29 04:42, =3DJeffH wrote:
=A0>> The max-age directive MUST appear once in the Strict-Transport-= Security
=A0>> header field value. The includeSubDomains directive MAY appear = once.
=A0>> The order of appearance of directives in the Strict-Transport-S= ecurity
=A0>> header field value is not significant.
=A0>>
=A0>> Additional directives extending the the semantic functionality = of
=A0>> the Strict-Transport-Security header field may be defined in ot= her
=A0>
=A0> MAY or might ?

yes, a good question.

I believe that there's examples in other RFCs of the use of the
lower-case "may" in situations similar to this (I've seen it = discussed
many times over the years). I.e., not all instances of "may" in a= ny
given RFC are capitalized "MAY"s. In this case, "MAY" i= sn't appropriate
IIRC.

And yes, a way to avoid that question/issue is to use a different word
such as "might" or "can", which i can do. I just though= t a "may" has
more correct connotations (but I /knew/ it'd come up as a question :)
thanks,

+1 to "can"

_______________________________________________
websec mailing list
websec@ietf.org = https://www.ietf.org/mailman/listinfo/websec



--
= Website: http://hallambaker.com/
--f46d04447429c620ea04b0742986-- From ietf@adambarth.com Sat Oct 29 11:50:50 2011 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 68B0D21F8573 for ; Sat, 29 Oct 2011 11:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.521, 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 V1iMk+PZ3gBu for ; Sat, 29 Oct 2011 11:50:49 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id B329121F84CB for ; Sat, 29 Oct 2011 11:50:49 -0700 (PDT) Received: by iabn5 with SMTP id n5so6765385iab.31 for ; Sat, 29 Oct 2011 11:50:49 -0700 (PDT) Received: by 10.231.6.102 with SMTP id 38mr2699765iby.62.1319914249339; Sat, 29 Oct 2011 11:50:49 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id g16sm18137975ibs.8.2011.10.29.11.50.47 (version=SSLv3 cipher=OTHER); Sat, 29 Oct 2011 11:50:47 -0700 (PDT) Received: by iabn5 with SMTP id n5so6765354iab.31 for ; Sat, 29 Oct 2011 11:50:47 -0700 (PDT) Received: by 10.231.48.142 with SMTP id r14mr2779420ibf.5.1319914247063; Sat, 29 Oct 2011 11:50:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.205.195 with HTTP; Sat, 29 Oct 2011 11:50:16 -0700 (PDT) In-Reply-To: <4EABC221.2080200@gmx.de> References: <4EAB66B3.4090404@KingsMountain.com> <4EABB440.1030906@gmx.de> <4EABB712.5000002@gmx.de> <4EABC221.2080200@gmx.de> From: Adam Barth Date: Sat, 29 Oct 2011 11:50:16 -0700 Message-ID: To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-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: Sat, 29 Oct 2011 18:50:50 -0000 On Sat, Oct 29, 2011 at 2:06 AM, Julian Reschke wrote: > On 2011-10-29 10:21, Adam Barth wrote: >> ... >>> >>> What I was trying to understand whether there's something special with >>> respect to quoted-string? >> >> Quoted string is particularly bad because it's hard to know what to do >> with unbalanced quotation marks. >> ... > > So your points were about quoted-string in general, not the question of > allowing them for max-age, right? > > I'm asking because due the possible presence of extension parameters, > recipients need to deal with quoted-string anyway, no matter whether they > are allowed for max-age. I'm saying we shouldn't use quoted-string anywhere in the grammar because it makes the error-handling ill-defined. Here's the code I wrote to parse the header: http://src.chromium.org/viewvc/chrome/trunk/src/net/base/transport_security_state.cc?revision=106333&view=markup TransportSecurityState::ParseHeader I'm happy to change that code to allow the parameters to appear in any order and to allow other semi-colin separated fields. Here's the parsing algorithm I'm willing to implement: 1) Split the header field value on ";". 2) Process each substring in sequence: a) Remove leading and trailing LWS from the substring. b) If the substring is a case-insensitive match for "includeSubDomains", set the include-subdomains flag and continue to the next substring. c) If the substring contains at least one "=", let the characters before the first "=" be the parameter-name and let the characters after the first "=" be the parameter-value: i) Strip leading and trailing LWS from both the parameter-name and the parameter-value. ii) If the parameter-name is a case insensitive match for "max-age" and the parameter-value is non-empty and consists entirely of digits: A) Let the max-age be the number represented by the digits and continue to the next substring. d) Continue to the next substring. Notice that this algorithm defines behavior for all inputs and doesn't balance quotation marks in extension parameters. Here's a representation of that algorithm in ABNF: value = paramater *(";" parameter) paramater = "includeSubDomains" / "max-age" "=" 1*DIGIT *LWS / extension extension = If you want the specification to match the code, you need to take into account the desires of implementors. In particular, you need to take into account the fact that implementations need to do something for every possible input and that browser implementors wish to be instructed how to handle every possible input. The net-net of this discussion is that's what the code is going to do. If you'd like the specification to match the code, I'd recommend against adding aspirational quoted-strings to the grammar. Adam From ietf@adambarth.com Sat Oct 29 11:51:41 2011 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 77AC221F85D1 for ; Sat, 29 Oct 2011 11:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.496, 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 3bQA3SpgQLnR for ; Sat, 29 Oct 2011 11:51:40 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id AC5DF21F84CB for ; Sat, 29 Oct 2011 11:51:40 -0700 (PDT) Received: by iabn5 with SMTP id n5so6766186iab.31 for ; Sat, 29 Oct 2011 11:51:40 -0700 (PDT) Received: by 10.231.8.143 with SMTP id h15mr2649048ibh.94.1319914300311; Sat, 29 Oct 2011 11:51:40 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by mx.google.com with ESMTPS id e2sm18196105ibe.0.2011.10.29.11.51.38 (version=SSLv3 cipher=OTHER); Sat, 29 Oct 2011 11:51:39 -0700 (PDT) Received: by iabn5 with SMTP id n5so6766155iab.31 for ; Sat, 29 Oct 2011 11:51:38 -0700 (PDT) Received: by 10.231.6.129 with SMTP id 1mr2770089ibz.31.1319914298606; Sat, 29 Oct 2011 11:51:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.205.195 with HTTP; Sat, 29 Oct 2011 11:51:07 -0700 (PDT) In-Reply-To: References: <4EAB66B3.4090404@KingsMountain.com> <4EABB440.1030906@gmx.de> <4EABB712.5000002@gmx.de> <4EABC221.2080200@gmx.de> From: Adam Barth Date: Sat, 29 Oct 2011 11:51:07 -0700 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] 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, 29 Oct 2011 18:51:41 -0000 On Sat, Oct 29, 2011 at 11:50 AM, Adam Barth wrote: > On Sat, Oct 29, 2011 at 2:06 AM, Julian Reschke w= rote: >> On 2011-10-29 10:21, Adam Barth wrote: >>> ... >>>> >>>> What I was trying to understand whether there's something special with >>>> respect to quoted-string? >>> >>> Quoted string is particularly bad because it's hard to know what to do >>> with unbalanced quotation marks. >>> ... >> >> So your points were about quoted-string in general, not the question of >> allowing them for max-age, right? >> >> I'm asking because due the possible presence of extension parameters, >> recipients need to deal with quoted-string anyway, no matter whether the= y >> are allowed for max-age. > > I'm saying we shouldn't use quoted-string anywhere in the grammar > because it makes the error-handling ill-defined. > > Here's the code I wrote to parse the header: > > http://src.chromium.org/viewvc/chrome/trunk/src/net/base/transport_securi= ty_state.cc?revision=3D106333&view=3Dmarkup > > TransportSecurityState::ParseHeader > > I'm happy to change that code to allow the parameters to appear in any > order and to allow other semi-colin separated fields. =A0Here's the > parsing algorithm I'm willing to implement: > > 1) Split the header field value on ";". > 2) Process each substring in sequence: > =A0a) Remove leading and trailing LWS from the substring. > =A0b) If the substring is a case-insensitive match for > "includeSubDomains", set the include-subdomains flag and continue to > the next substring. > =A0c) If the substring contains at least one "=3D", let the characters > before the first "=3D" be the parameter-name and let the characters > after the first "=3D" be the parameter-value: > =A0 =A0i) Strip leading and trailing LWS from both the parameter-name and > the parameter-value. > =A0 =A0ii) If the parameter-name is a case insensitive match for > "max-age" and the parameter-value is non-empty and consists entirely > of digits: > =A0 =A0 =A0A) Let the max-age be the number represented by the digits and > continue to the next substring. > =A0d) Continue to the next substring. > > Notice that this algorithm defines behavior for all inputs and doesn't > balance quotation marks in extension parameters. =A0Here's a > representation of that algorithm in ABNF: > > value =3D paramater *(";" parameter) > paramater =3D "includeSubDomains" / "max-age" "=3D" 1*DIGIT *LWS / extens= ion > extension =3D Sorry, extension =3D * of course. > If you want the specification to match the code, you need to take into > account the desires of implementors. =A0In particular, you need to take > into account the fact that implementations need to do something for > every possible input and that browser implementors wish to be > instructed how to handle every possible input. > > The net-net of this discussion is that's what the code is going to do. > =A0If you'd like the specification to match the code, I'd recommend > against adding aspirational quoted-strings to the grammar. > > Adam > From derhoermi@gmx.net Sat Oct 29 12:02:34 2011 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 078BD21F869E for ; Sat, 29 Oct 2011 12:02:34 -0700 (PDT) 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 SZ+kEuAWIoyr for ; Sat, 29 Oct 2011 12:02:33 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id A896821F8677 for ; Sat, 29 Oct 2011 12:02:32 -0700 (PDT) Received: (qmail invoked by alias); 29 Oct 2011 19:02:28 -0000 Received: from dslb-094-222-141-108.pools.arcor-ip.net (EHLO HIVE) [94.222.141.108] by mail.gmx.net (mp038) with SMTP; 29 Oct 2011 21:02:28 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1+nXHUKcxOnyFKf30XVYugG7Vf3ST/Y1Fc2sJb/BZ LNsx+ZAwHkO4MI From: Bjoern Hoehrmann To: Julian Reschke Date: Sat, 29 Oct 2011 21:02:39 +0200 Message-ID: References: <4EA99CFB.30801@KingsMountain.com> <4EA9B09E.9030001@gmx.de> In-Reply-To: <4EA9B09E.9030001@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: 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: Sat, 29 Oct 2011 19:02:34 -0000 * Julian Reschke wrote: >> Strict-Transport-Security = "Strict-Transport-Security" ":" >> directive *( ";" [ directive ] ) >> >> STS directives: >> >> directive = max-age | includeSubDomains | STS-d-ext >> >> max-age = "max-age" "=" delta-seconds > >What happens with > > max-age="1" > >? > >Do you expect all recipients to reject this? Depending on the parsing >API they use they might not even know that the value was quoted on the wire. That doesn't matter much really, if you include relevant edge cases in the specification along with the expected behavior, you are virtually guaranteed that such issues are discovered quickly as implementers and testers will start with what is in the specification to find problems, and it's much less likely that APIs make it very difficult to implement the right behavior at least compared to telling the difference between and in an XML document using some XML parser API, as far as my experience with HTTP APIs goes anyway. -- 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 hallam@gmail.com Sun Oct 30 05:31:38 2011 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 387D021F86A4 for ; Sun, 30 Oct 2011 05:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.431 X-Spam-Level: X-Spam-Status: No, score=-3.431 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 MvsaOuWIfMnf for ; Sun, 30 Oct 2011 05:31:37 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB4221F8888 for ; Sun, 30 Oct 2011 05:31:36 -0700 (PDT) Received: by ggnv1 with SMTP id v1so5973219ggn.31 for ; Sun, 30 Oct 2011 05:31:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hoNelf4v99q+tGOOGZQRzP9YLERMXYRmn4nToPhRYcg=; b=mmQtkhyg6TsaFJScwIpERBO2x2owgrWi4/9T2Gq9ugI6idWTx+4TeK1z8XAMIYkGdd 8wc48SaNN99AZwfYVG/txQcguT63IV/tr6qsK/w1v6OKyLaVGfAPZ40TCfCCDV4v098h olZkgf2Qh8X2L1KVhz48rXJzxxB3XB1J7IWqg= MIME-Version: 1.0 Received: by 10.182.115.40 with SMTP id jl8mr2093693obb.8.1319977896396; Sun, 30 Oct 2011 05:31:36 -0700 (PDT) Received: by 10.182.42.99 with HTTP; Sun, 30 Oct 2011 05:31:36 -0700 (PDT) In-Reply-To: References: <4EAB66B3.4090404@KingsMountain.com> <4EABB440.1030906@gmx.de> <4EABB712.5000002@gmx.de> <4EABC221.2080200@gmx.de> Date: Sun, 30 Oct 2011 08:31:36 -0400 Message-ID: From: Phillip Hallam-Baker To: Adam Barth Content-Type: multipart/alternative; boundary=f46d0444808ba0474104b0834dfa 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: Sun, 30 Oct 2011 12:31:38 -0000 --f46d0444808ba0474104b0834dfa Content-Type: text/plain; charset=ISO-8859-1 I think that the field is going to match the requirements of the HTTP spec: http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2 message-header = field-name ":" [ field-value ] field-name = token field-value = *( field-content | LWS ) field-content = That takes precedence over the desire to scrape together naive parsers in my view. Most people writing code are going to want to skip the need to write a parser altogether by using existing parser methods built in to their platform. This is a standards based specification and so it has to match the format already defined by the HTTP specification and aspirational or not, any code that fails to match quoted string is likely to break in future spec versions. On Sat, Oct 29, 2011 at 2:50 PM, Adam Barth wrote: > On Sat, Oct 29, 2011 at 2:06 AM, Julian Reschke > wrote: > > On 2011-10-29 10:21, Adam Barth wrote: > >> ... > >>> > >>> What I was trying to understand whether there's something special with > >>> respect to quoted-string? > >> > >> Quoted string is particularly bad because it's hard to know what to do > >> with unbalanced quotation marks. > >> ... > > > > So your points were about quoted-string in general, not the question of > > allowing them for max-age, right? > > > > I'm asking because due the possible presence of extension parameters, > > recipients need to deal with quoted-string anyway, no matter whether they > > are allowed for max-age. > > I'm saying we shouldn't use quoted-string anywhere in the grammar > because it makes the error-handling ill-defined. > > Here's the code I wrote to parse the header: > > > http://src.chromium.org/viewvc/chrome/trunk/src/net/base/transport_security_state.cc?revision=106333&view=markup > > TransportSecurityState::ParseHeader > > I'm happy to change that code to allow the parameters to appear in any > order and to allow other semi-colin separated fields. Here's the > parsing algorithm I'm willing to implement: > > 1) Split the header field value on ";". > 2) Process each substring in sequence: > a) Remove leading and trailing LWS from the substring. > b) If the substring is a case-insensitive match for > "includeSubDomains", set the include-subdomains flag and continue to > the next substring. > c) If the substring contains at least one "=", let the characters > before the first "=" be the parameter-name and let the characters > after the first "=" be the parameter-value: > i) Strip leading and trailing LWS from both the parameter-name and > the parameter-value. > ii) If the parameter-name is a case insensitive match for > "max-age" and the parameter-value is non-empty and consists entirely > of digits: > A) Let the max-age be the number represented by the digits and > continue to the next substring. > d) Continue to the next substring. > > Notice that this algorithm defines behavior for all inputs and doesn't > balance quotation marks in extension parameters. Here's a > representation of that algorithm in ABNF: > > value = paramater *(";" parameter) > paramater = "includeSubDomains" / "max-age" "=" 1*DIGIT *LWS / extension > extension = > > If you want the specification to match the code, you need to take into > account the desires of implementors. In particular, you need to take > into account the fact that implementations need to do something for > every possible input and that browser implementors wish to be > instructed how to handle every possible input. > > The net-net of this discussion is that's what the code is going to do. > If you'd like the specification to match the code, I'd recommend > against adding aspirational quoted-strings to the grammar. > > Adam > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > -- Website: http://hallambaker.com/ --f46d0444808ba0474104b0834dfa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think that the field is going to match the requirements of the HTTP spec:= 
http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2

       message-header =3D field-name ":" [ field-value ]
       field-name     =3D token
       field-value    =3D *( field-content | LWS )
       field-content  =3D <the OCTETs making up the field-value
                        and consisting of either *TEXT or combinations
                        of token, separators, and quoted-string>

That takes precedence over the desire to scrape together = naive parsers in my view.

Most people writing code= are going to want to skip the need to write a parser altogether by using e= xisting parser methods built in to their platform.

This is a standards based specification and so it has t= o match the format already defined by the HTTP specification and aspiration= al or not, any code that fails to match quoted string is likely to break in= future spec versions.


On Sat, Oct 29, 2011 at = 2:50 PM, Adam Barth <ietf@adambarth.com> wrote:
On Sat, Oct 29, 2011 at 2:06 AM, Julian Reschke <julian.reschke@gmx.de> wrote: > On 2011-10-29 10:21, Adam Barth wrote:
>> ...
>>>
>>> What I was trying to understand whether there's something = special with
>>> respect to quoted-string?
>>
>> Quoted string is particularly bad because it's hard to know wh= at to do
>> with unbalanced quotation marks.
>> ...
>
> So your points were about quoted-string in general, not the question o= f
> allowing them for max-age, right?
>
> I'm asking because due the possible presence of extension paramete= rs,
> recipients need to deal with quoted-string anyway, no matter whether t= hey
> are allowed for max-age.

I'm saying we shouldn't use quoted-string anywhere in the gra= mmar
because it makes the error-handling ill-defined.

Here's the code I wrote to parse the header:

http://src.chromium.org/viewvc/chrome/trunk/src/net/base/transport_securit= y_state.cc?revision=3D106333&view=3Dmarkup

TransportSecurityState::ParseHeader

I'm happy to change that code to allow the parameters to appear in any<= br> order and to allow other semi-colin separated fields. =A0Here's the
parsing algorithm I'm willing to implement:

1) Split the header field value on ";".
2) Process each substring in sequence:
=A0a) Remove leading and trailing LWS from the substring.
=A0b) If the substring is a case-insensitive match for
"includeSubDomains", set the include-subdomains flag and continue= to
the next substring.
=A0c) If the substring contains at least one "=3D", let the char= acters
before the first "=3D" be the parameter-name and let the characte= rs
after the first "=3D" be the parameter-value:
=A0 =A0i) Strip leading and trailing LWS from both the parameter-name and<= br> the parameter-value.
=A0 =A0ii) If the parameter-name is a case insensitive match for
"max-age" and the parameter-value is non-empty and consists entir= ely
of digits:
=A0 =A0 =A0A) Let the max-age be the number represented by the digits and<= br> continue to the next substring.
=A0d) Continue to the next substring.

Notice that this algorithm defines behavior for all inputs and doesn't<= br> balance quotation marks in extension parameters. =A0Here's a
representation of that algorithm in ABNF:

value =3D paramater *(";" parameter)
paramater =3D "includeSubDomains" / "max-age" "=3D= " 1*DIGIT *LWS / extension
extension =3D <any character aside from ";">

If you want the specification to match the code, you need to take into
account the desires of implementors. =A0In particular, you need to take
into account the fact that implementations need to do something for
every possible input and that browser implementors wish to be
instructed how to handle every possible input.

The net-net of this discussion is that's what the code is going to do.<= br> =A0If you'd like the specification to match the code, I'd recommend=
against adding aspirational quoted-strings to the grammar.

Adam
__________________________________= _____________
websec mailing list
websec@ietf.org
= https://www.ietf.org/mailman/listinfo/websec



--
= Website: http://hallambaker.com/
--f46d0444808ba0474104b0834dfa-- From internet-drafts@ietf.org Mon Oct 31 00:43:27 2011 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 8648A21F8C82; Mon, 31 Oct 2011 00:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 09xRVUEt+t44; Mon, 31 Oct 2011 00:43:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27AEB21F8C5B; Mon, 31 Oct 2011 00:43:27 -0700 (PDT) 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.62 Message-ID: <20111031074327.17734.80022.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 00:43:27 -0700 Cc: websec@ietf.org Subject: [websec] I-D Action: draft-ietf-websec-strict-transport-sec-03.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: Mon, 31 Oct 2011 07:43:27 -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-03.txt Pages : 36 Date : 2011-10-31 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, e.g. user agent configuration. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-websec-strict-transport-sec-= 03.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= 3.txt From Jeff.Hodges@KingsMountain.com Mon Oct 31 01:04:26 2011 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 4A04E21F8B3A for ; Mon, 31 Oct 2011 01:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.495 X-Spam-Level: X-Spam-Status: No, score=-100.495 tagged_above=-999 required=5 tests=[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 LmvC1M9wwQ7K for ; Mon, 31 Oct 2011 01:04:25 -0700 (PDT) Received: from oproxy3-pub.bluehost.com (oproxy3.bluehost.com [IPv6:2605:dc00:100:2::a3]) by ietfa.amsl.com (Postfix) with SMTP id A5B7121F8B35 for ; Mon, 31 Oct 2011 01:04:25 -0700 (PDT) Received: (qmail 5229 invoked by uid 0); 31 Oct 2011 08:04:25 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy3.bluehost.com with SMTP; 31 Oct 2011 08:04:25 -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=rXDUwvACNsZ6vNhh4fVQOd5Gm4s28+UElpAC1SMYT+M=; b=qkjW/yKL9zVuGrUDqPYZKGX6puW1KK2BAkJYbkdIjzsqU4KvtdydGNa+62/dy0vHt/RoTDgqaBjgnmG5wADFRoEhNkIkStewkBijJTp2xFZfzLgAvxJNgxTsG5evhyv/; 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 1RKmr3-000709-45 for websec@ietf.org; Mon, 31 Oct 2011 02:04:25 -0600 Message-ID: <4EAE5687.1020606@KingsMountain.com> Date: Mon, 31 Oct 2011 01:04:23 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 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] fyi: draft-ietf-websec-strict-transport-sec-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: Mon, 31 Oct 2011 08:04:26 -0000 -03 is submitted. It isn't as polished as I'd like, but I wanted to make the deadline for Taipei. There's some outstanding issues from the websec@ list, plus a few other detail-level issues that have been related to me privately. So imho I should try to sweep all that up into a more-polished -04 before we try to goto WGLC. I have a couple other I-Ds i want/need to work on here before Taipei, so don't know whether i'll be able to get -04 done by the time we meet there. =JeffH -- New Version Notification - draft-ietf-websec-strict-transport-sec-03.txt internet-drafts@ietf.org [internet-drafts@ietf.org] Sent: Monday, October 31, 2011 12:43 AM New version (-03) has been submitted for draft-ietf-websec-strict-transport-sec-03.txt. http://www.ietf.org/internet-drafts/draft-ietf-websec-strict-transport-sec-03.txt Diff from previous version: http://tools.ietf.org/rfcdiff?url2=draft-ietf-websec-strict-transport-sec-03 IETF Secretariat.