IETF Logo Mail Archive

Re: [websec] Strict-Transport-Security syntax redux

Marsh Ray <marsh@extendedsubset.com> Mon, 16 January 2012 05:38 UTC

Return-Path: <marsh@extendedsubset.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8B221F8545 for <websec@ietfa.amsl.com>; Sun, 15 Jan 2012 21:38:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.524
X-Spam-Level:
X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1wz-Xjx1zX7 for <websec@ietfa.amsl.com>; Sun, 15 Jan 2012 21:38:13 -0800 (PST)
Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA1121F846C for <websec@ietf.org>; Sun, 15 Jan 2012 21:38:13 -0800 (PST)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from <marsh@extendedsubset.com>) id 1RmfGm-000Nvy-St; Mon, 16 Jan 2012 05:38:12 +0000
Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id C09226067; Mon, 16 Jan 2012 05:38:11 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX18erCAnhMovnFeyqrjsupzfwpNGWRXjV1c=
Message-ID: <4F13B7C2.5010603@extendedsubset.com>
Date: Sun, 15 Jan 2012 23:38:10 -0600
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16
MIME-Version: 1.0
To: Anne van Kesteren <annevk@opera.com>
References: <4EAB66B3.4090404@KingsMountain.com> <4EABB25E.9000900@gmx.de> <4EFC5F7B.7050304@gmx.de> <CAJE5ia_HhenArVey=5-ttLqh4-vbBE01TFZKuzAmAtHQJQJ3kQ@mail.gmail.com> <4EFCD7E4.5060507@gmx.de> <CAJE5ia-w47HHhnTBAE_PMApAAdCu=6PJexaaoJO0MZ23Ae-vcw@mail.gmail.com> <4EFCDA9C.90308@gmx.de> <CAJE5ia-E1nhN1YGV6uy3uEq4oboQowDm4FboKbWV1kunHQmXPw@mail.gmail.com> <4EFCDDD5.6040005@gmx.de> <CAJE5ia8CL9ozRJgRNCdu6XwVT0paVuVUreB12f-BiMvH+wiq6A@mail.gmail.com> <4EFD73E6.1060506@gmx.de> <CAJE5ia8RBa8iCd_9TjXyzG54VASa6qqGomsO9gL-qQ2ia=BKLg@mail.gmail.com> <4EFD7C09.9050702@gmx.de> <CAJE5ia8aN_MKUX_7ehp6siw=CY7nC4aSRPoPcsaDX8+emwaFVw@mail.gmail.com> <4EFD8BCE.7010909@gmx.de> <CAJE5ia9cziSx-xb6nCEFXJkbu2Ls_ZQmYHpfrC7UK3ig3ZmM2g@mail.gmail.com> <4F052D2E.5050200@gondrom.org> <op.v7lqsdyu64w2qv@annevk-macbookpro.local> <4F056553.9030409@gmx.de> <553F526C-4433-489B-80B5-4C29E5FB0DC4@vpnc.org> <op.v7mg5ns564w2qv@annevk-macbookpro.local>
In-Reply-To: <op.v7mg5ns564w2qv@annevk-macbookpro.local>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: websec@ietf.org
Subject: Re: [websec] Strict-Transport-Security syntax redux
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Jan 2012 05:38:15 -0000

On 01/05/2012 11:50 AM, Anne van Kesteren wrote:
> On Thu, 05 Jan 2012 16:59:58 +0100, Paul Hoffman <paul.hoffman@vpnc.org>
> wrote:
>>
>> "We invented a header that your message-producing software must
>> special-case" is not a good way to get security.
>
> If the header-consuming software works that way, it might be the only
> way. What the right way to go here is kind of depends on how header
> field values are typically implemented in practice. I suspect it to be
> rather messy.

How about: servers generating the header MUST use quoted-string whenever 
quoted-string is necessary, otherwise they SHOULD use the token 
production on Mondays, Wednesdays, and Fridays and they SHOULD use 
quoted-string on Tuesday, Thursday, Saturday, and Sunday.

Yes, I'm joking. But only half-way. I have a deep suspicion that 
something like that might actually yield the best interoperability 
overall. One thing worse than having arbitrarily-chosen redundant code 
paths is having protocol grammar that's never ever used - until it's needed.

Meredith Patterson, Sergey Bratus, et al. have been talking about the 
deep logical connections between lanugage expressive power, 
generator/parser differences, and ... working exploits.
http://www.cs.dartmouth.edu/~sergey/langsec/

28c3: The Science of Insecurity
http://www.youtube.com/watch?v=3kEfedtQVOY
Worth watching.

And of course: Occupy Babel!
http://www.cs.dartmouth.edu/~sergey/langsec/occupy/

:-)

- Marsh

v2.23.0 | Report a Bug | By Email