IETF Logo Mail Archive

Re: [websec] Smart Cookies

Trevor Perrin <trevp@trevp.net> Tue, 23 July 2013 05:37 UTC

Return-Path: <trevp@trevp.net>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 323B411E8140 for <websec@ietfa.amsl.com>; Mon, 22 Jul 2013 22:37:00 -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 UEtDQCxS3WWS for <websec@ietfa.amsl.com>; Mon, 22 Jul 2013 22:36:56 -0700 (PDT)
Received: from mail-vb0-f51.google.com (mail-vb0-f51.google.com [209.85.212.51]) by ietfa.amsl.com (Postfix) with ESMTP id E307811E8138 for <websec@ietf.org>; Mon, 22 Jul 2013 22:36:55 -0700 (PDT)
Received: by mail-vb0-f51.google.com with SMTP id x17so5226172vbf.10 for <websec@ietf.org>; Mon, 22 Jul 2013 22:36:53 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=9cpH0U9Qi4IGs5nS609OlmM6J+XsZagbcZqRwbygGoE=; b=H6iQxthml2I/vU8AqZQPZaA9yUX1xlOr+RQH/iHURayxDy/HzdhF7OiRdBwHXlINmV dN1zuOpawvcGSkHriDEtqGSB4i65kTNxMY6a7/I2MLZrJXs/mlgVGdc8juTUkG6YZdHb TYREjNSkn40EiSI3ebDFq+Ry8epdmMrG0NoyPg/JNlCsLYy+PJ2KLTh1KRRu4koCDpw4 RLfQ67sjdfjwdrtMdirdVDap5FD21d66SGW/j8rSE9rgibUf2GMpO3pmbUeowWDudhRS vVCUB7NxVoKPlA3VUgvTzc3ZTp8b0o5NK0BPctr/G8RBYz3jT3CjqQFCCqyxd9bYADy+ l9lA==
MIME-Version: 1.0
X-Received: by 10.52.188.73 with SMTP id fy9mr8989365vdc.53.1374557812678; Mon, 22 Jul 2013 22:36:52 -0700 (PDT)
Received: by 10.220.216.2 with HTTP; Mon, 22 Jul 2013 22:36:52 -0700 (PDT)
X-Originating-IP: [12.178.131.2]
In-Reply-To: <51EDF82F.9080503@gondrom.org>
References: <CAGZ8ZG1-dQescF-dpS+dYVd8yNA9VySBZ+HZO=8iuG68taqkDg@mail.gmail.com> <51ECF36D.4010902@gondrom.org> <CAGZ8ZG3ka40pOq+MGCn9B4_okGNNo2bbAkmzbV79F2m2W9YbiQ@mail.gmail.com> <CAOe4UikMq76hxYwxJmJ+5LQR5aWDoGR8sCra4y1KQTWXkgi-6Q@mail.gmail.com> <CAGZ8ZG3B5rs_1a2ufMGesTDgNXNua=mn+Vn2YCvMf3A9o7NDjQ@mail.gmail.com> <CAOe4Uin-iTQch-no-exCHPpW+AOdCtE7sSC02VeT8vXBoAjH3Q@mail.gmail.com> <CAGZ8ZG3yD8Jc8ozKqWwW7UPLr5BkTQC4im=yrZgytoh5W4RkNg@mail.gmail.com> <51EDF82F.9080503@gondrom.org>
Date: Mon, 22 Jul 2013 22:36:52 -0700
Message-ID: <CAGZ8ZG3sXUr4eUjccs58GPCqg+QFDQS7aGoCeRfX1N7XvP+y0A@mail.gmail.com>
From: Trevor Perrin <trevp@trevp.net>
To: Tobias Gondrom <tobias.gondrom@gondrom.org>
Content-Type: text/plain; charset="ISO-8859-1"
X-Gm-Message-State: ALoCoQkId3nOLhDYlH+1A96K71MkcB9bjHGQPzW+0USWIU2jnI/TARIujSARDBYwEbiNb7zdR5Ol
Cc: IETF WebSec WG <websec@ietf.org>
Subject: Re: [websec] Smart Cookies
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: Tue, 23 Jul 2013 05:37:00 -0000

On Mon, Jul 22, 2013 at 8:27 PM, Tobias Gondrom
<tobias.gondrom@gondrom.org> wrote:
> Ok. Thanks for the explanation. I can see how this could help data
> leakage against sub-domains.
>
> As far as I understand the best solution would be HSTS incl subdomains
> plus "secure" cookie. But if that is not feasible for some subdomains
> for some reason, the smart cookie would allow to compensate?

"includeSubdomains" is often infeasible.  As a data point: Chrome has
preloaded HSTS for ~180 non-Google hostnames, but only ~100 use
"includeSubdomains" [1].

With key pinning, "includeSubdomains" will probably be used even less,
since subdomains and parent domains are likely to have different keys,
and even different CAs (hosting a subdomain on a CDN, for example).

And even if HSTS includeSubdomains and "secure" cookies are used, they
don't stop cookie forcing (an attacker logs you in to her session).
And they don't make stolen cookies unusable (like ChannelID's
channel-bound cookies, or smart cookies).

--

I think the best easy solution is probably just "Origin Cookies" [2].
This solves all the cookie-scoping problems, and brings cookies in
line with the "same-origin policy".

If we had that, then cookies would not be stealable unless there was
some TLS flaw, or some failure in cookie handling.  Adding
channel-bound cookies or smart cookies gives the additional assurance
that stolen cookies would be unusable, but that's more of a
"defense-in-depth" approach.

Anyways.  Are "Origin Cookies" in scope for this WG?


Trevor


[1] http://src.chromium.org/viewvc/chrome/trunk/src/net/http/transport_security_state_static.json

[2]
http://w2spconf.com/2011/papers/session-integrity.pdf
http://tools.ietf.org/html/draft-abarth-cake-01

v2.23.0 | Report a Bug | By Email