Re: [websec] Forwarded review of draft-williams-websec-session-continue-prob-00

Yoav Nir <> Fri, 18 January 2013 06:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 63B2921F888B for <>; Thu, 17 Jan 2013 22:18:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.51
X-Spam-Status: No, score=-10.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SOLqqgaZK5N0 for <>; Thu, 17 Jan 2013 22:18:45 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8F36721F8888 for <>; Thu, 17 Jan 2013 22:18:44 -0800 (PST)
Received: from ([]) by (8.13.8/8.13.8) with ESMTP id r0I6Icj4016784; Fri, 18 Jan 2013 08:18:39 +0200
X-CheckPoint: {50F8E6A1-0-1B221DC2-2FFFF}
Received: from ([]) by ([fe80::80df:1c2c:3d29:3748%11]) with mapi id 14.02.0328.009; Fri, 18 Jan 2013 08:18:38 +0200
From: Yoav Nir <>
To: Nico Williams <>
Thread-Topic: [websec] Forwarded review of draft-williams-websec-session-continue-prob-00
Thread-Index: AQHN9M5PbT3V1iRo0E6FSyqDNFm8H5hOfCgA
Date: Fri, 18 Jan 2013 06:18:38 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "<>" <>
Subject: Re: [websec] Forwarded review of draft-williams-websec-session-continue-prob-00
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, 18 Jan 2013 06:18:46 -0000

On Jan 17, 2013, at 6:18 PM, Nico Williams <> wrote:

> On Mon, Jan 14, 2013 at 17:05, Yoav Nir <> wrote:
>> I've shown this draft to a co-worker of mine (not on this list), and asked for a review. Here's some comments:
>> - Overall, this is an interesting problem.
> There's been quite a few proposals now to solve it all before we
> identified this as worth treating as a problem separate from others:
> - draft-hammer-oauth-v2-mac-token
> - draft-hallambaker-httpintegrity
> - draft-williams-http-rest-auth
> - and several others

Yes, but those are not all solving the same issue. Some are for user authentication while others are for per-request MAC. You might be able to delegate either or both of these functions to the TLS layer (if present), so there's a lot of variation here.

> There's also been a number of recent mentions of this in the context
> of CRIME in the HTTPbis WG list.
>> - The document is missing a list of deficiencies with using Cookies
> Well, for me CRIME is enough :)  But sure, I'll flesh that out a bit.
> FWIW, I was under a hard deadline when i submitted the -00.

OK. Next deadline is 25-Feb.

>> - Section 2.1 says that TLS protects against replay. Really?  How? It doesn't have a protected counter like IPsec.
> If you try to replay a handshake it won't work: the server will almost
> certainly pick different nonces and, if relevant, DH keys, so the
> Finished message exchange will fail.
> If you try to replay a TLS record layer message... TLS will detect
> that too because of its use of sequence numbers.  See RFC5246, search
> for "sequence"; see section 6.2.3 in particular.  Search also for
> "replay".  This is also true of DTLS.
> If you can neither replay handshakes, entire connections, nor
> individual records then it's got replay protection :)

You're right. I forgot about the seq_num field.

>> - Will the resulting protocol support a transition from authenticated session to authenticated session for purposes such as re-authenticating after a specified time, or moving from weak authentication to strong authentication for high-value transactions.
> If we can make that work securely, then yes.

I think it can be done. You can have a key for the unauthenticated session, that's either secure (D-H or TLS extractor without a MitM) or insecure (server assigns a key). Then you can mix in the key with the calculation of the key to the authenticated session. In the insecure case, an attacker could authenticate and continue someone else's session, but they can only do it once, since calculating a new key would invalidate the old key. So someone could hijack your shopping cart right before the checkout. Come to think of it, this attack could be mounted physically at a supermarket, but in either case, it's pretty low-value.

>> Nit: HTTP is HyperText **Transfer** Protocol, not **Transport*.  This one is already fixed in Nico's repository.
> There were some instances of one and some of the other.  It was just
> me being sloppy as I hurried to meet a hard deadline.
> Thanks!
> Nico
> --
> _______________________________________________
> websec mailing list
> Email secured by Check Point