Re: [hybi] Call for interest: multiplexing dedicated for WebSocket

Roberto Peon <fenix@google.com> Thu, 30 May 2013 20:16 UTC

Return-Path: <fenix@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C451421F88AC for <hybi@ietfa.amsl.com>; Thu, 30 May 2013 13:16:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.144
X-Spam-Level:
X-Spam-Status: No, score=-1.144 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, 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 EMUWQLI6nDNU for <hybi@ietfa.amsl.com>; Thu, 30 May 2013 13:16:37 -0700 (PDT)
Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id EF83021F8617 for <hybi@ietf.org>; Thu, 30 May 2013 13:16:36 -0700 (PDT)
Received: by mail-la0-f51.google.com with SMTP id lx15so686035lab.10 for <hybi@ietf.org>; Thu, 30 May 2013 13:16:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=V50oYYKlit9FyeBwT/K3tVgv16UF3z8G1l3uF6PHmG4=; b=YVvPJdOFplecpkXefDL66vExmLJdH76Hg/tdQe6g7NAqG5rf9y8nF1Qdijfr9C8GrZ rn/XYprCaABXDhWr16hdvrTy56XEMECscWDmdwC7n5+hxFEHo3evJxfakBu1UaKwi0rB fWIkv4JcFw2uh2abnTMScvhAvho8GTMAVAsTFElIWraCWzcfj8V9fy8RAziW3N+i2ER1 3UG84mva9j+M1lhHvHC/Rl/awBQPgDeJPGBVZP9QtwLWxsBhOXO53i0WHRvPdv7p99FK zT5EjycTJzPDKt3UgZcYWkditf2eEd3TY6u7rbDXbf6ylJ+4rCKmBfOiuAllHGqf+H6j dhMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=V50oYYKlit9FyeBwT/K3tVgv16UF3z8G1l3uF6PHmG4=; b=Z4MNn5Rxjl7DmE0y2nY0svH7CydpKipvHSn4voZ0claWfjd2dNJZrx/BPz9QovwJNx 9Z2BGknDvPOdU21OpDVgESV5FF8JO6P3ygS49QrjzPjSz9cD5Ryfx0YtPCq7rjJMA9RM L1wrlcn8bTQD97rrHBZXkaxRyLH44t0hvIFO34FCVGHp6bTWCTe9OvWospdZJLOEqNLx 7arOx4EUR2Ohr00rAeVNgBeYeXG2JQBjtLlkrtUgetxWqxXQYtoghHCKbZ+/ixCcXT9Z cIHcGYxj/MyT7GtOBuzOB6nswJ5JqNZbmBA1jKfZy8ne8FgU/eum8wBJZlWpzIamCtKA tyhQ==
MIME-Version: 1.0
X-Received: by 10.112.148.104 with SMTP id tr8mr4568498lbb.56.1369944995606; Thu, 30 May 2013 13:16:35 -0700 (PDT)
Received: by 10.112.76.231 with HTTP; Thu, 30 May 2013 13:16:35 -0700 (PDT)
In-Reply-To: <51A79DF0.5060901@tavendo.de>
References: <CAH9hSJZxr+aG7GZa4f-dUOTGj4bnJ+3XxivUX4jei5CMyqN4LQ@mail.gmail.com> <634914A010D0B943A035D226786325D4422C319646@EXVMBX020-12.exch020.serverdata.net> <CAH9hSJYrrbSM3TTSKCQ=AMcwCfE4zqNAa1kuAvecrXZTLqy2gQ@mail.gmail.com> <634914A010D0B943A035D226786325D4422C3DA774@EXVMBX020-12.exch020.serverdata.net> <CAHixhFrTk79A07BjQCgvep_+bmA4rGG1ZvqmoS6gsQYNPyPoZA@mail.gmail.com> <CAH9hSJYFa+bqN=e7x87W+Xvq-st70nbzUXniQaPme2fzspCjWA@mail.gmail.com> <51A70DF9.5010601@tavendo.de> <CAGzyod6daSOvAVHU6B=Qr0xDqNca_8iXrFYr0gTGdqZPryFFpA@mail.gmail.com> <51A79DF0.5060901@tavendo.de>
Date: Thu, 30 May 2013 13:16:35 -0700
Message-ID: <CAGzyod4zX8fpJZBuOx=9CVFR1y0nNMqenzTVXuEx1ayFOdK0BQ@mail.gmail.com>
From: Roberto Peon <fenix@google.com>
To: Tobias Oberstein <tobias.oberstein@tavendo.de>
Content-Type: multipart/alternative; boundary=047d7b3a8300d345c004ddf52cd3
X-Gm-Message-State: ALoCoQn3TPHcucA9GWByrjMQBq74SG5aQyfgree2PEf5xg1QUriTS/GJH+TqrcFbeg94/q6ECmc4WtV3fQ06aAvVs+NfuQhwKkWSMdEssHPD/AHuFRyQaH9fOOiglYba8Z86VzaLgFnn/qZbxlOO+v8Och7AlIB1BQhEVODRYTVJmoC0GIt/eIWar6CCveu+cml9DtWR/FRo
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] Call for interest: multiplexing dedicated for WebSocket
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 May 2013 20:16:38 -0000

inline


On Thu, May 30, 2013 at 11:44 AM, Tobias Oberstein <
tobias.oberstein@tavendo.de> wrote:

> Am 30.05.2013 20:28, schrieb Roberto Peon:
>
>  Different schemas have nothing to do with the CRIME attack.
>> A pure HTTPS or WSS scheme could still be attacked with CRIME, with its
>> success depending on the way the compression mechanism works.
>> With the current HTTP/2 proposals it would be pretty difficult to attack
>> using the techniques in the CRIME attack.
>>
>> The way CRIME works is to have a 3rd party include links to the
>> site-to-attack. Thus it doesn't matter if the schemes are http, https,
>> ws, wss, whatever.
>> So, a restriction against muxing ws and wss together makes no sense as
>> it provides no security benefit for CRIME.
>>
>
> What about the other issues listed?
>
> Example:
>
> An app first connect to a ws: address. Then the app opens a 2nd connection
> over wss: to the same target (IP:port) sending some sensitive information
> (either in cookies or in payload) relying on the presumed
> privacy/encryption provided by wss:.
>
> An implementation of MUX might run the 2nd wss: connection as a logical WS
> connection over an _unencrypted_ physical ws: that was established in the
> first place upon the app opening the 1st ws: connection.
>
> So at least the implementation must not mux logical wss: over physical ws:.
>

Agreed. That would invalidate the security guarantee of wss.


>
> Transporting logical ws: over physical wss: seems less problematic.
>

Yup!
-=R


>
>
>  -=R
>>
>>
>> On Thu, May 30, 2013 at 1:29 AM, Tobias Oberstein
>> <tobias.oberstein@tavendo.de <mailto:tobias.oberstein@**tavendo.de<tobias.oberstein@tavendo.de>>>
>> wrote:
>>
>>     Am 30.05.2013 09:28, schrieb Takeshi Yoshino:
>>
>>>     On Thu, May 30, 2013 at 1:12 PM, Adam Rice <ricea@google.com
>>>     <mailto:ricea@google.com>> wrote:
>>>
>>>             So d) - f) cannot be multiplexed over the same physical WS
>>>             as a) - c)?
>>>
>>>             Or can an implementation just "silently" transport a)-c)
>>>             also over wss, and hence multiplex all of a) - f) over 1
>>>             physical WS?
>>>
>>>
>>>         The handshake does not currently include the schema, so there
>>>         would be no way to communicate to the server that a)-c) were
>>>         supposed to be ws:, not wss:.
>>>
>>>
>>>     Right. I missed that point.
>>>
>>>         Even if this was amended, both client and server would have to
>>>         be careful that no ambient authority leaked from the wss:
>>>         channels to the ws: channels. For example: the client would
>>>         have to be careful not to send "secure" cookies with the ws:
>>>         handshakes, and the server would have to be careful not to
>>>         apply any authority contained in a client TLS certificate to
>>>         the ws: logical channels.
>>>
>>>         For this reason, I think it would be easiest not to attempt to
>>>         multiplex ws: and wss: onto a single TCP/IP connection.
>>>
>>>
>>>     Compression contexts, etc. also need to be isolated carefully to
>>>     protect it from attack like CRIME.
>>>
>>
>>     I also agree with Adam. To summarize, given the possible "issues" of
>>
>>     - client cert based auth
>>     - "secure" cookies / ambient authority
>>     - compression contexts / CRIME
>>
>>     (plus complexities like: what if an app opens ws://domain.com, and
>>     then _later_ opens wss://domain.com? Upgrade to TLS not possible
>>     anymore .. cannot TLS handshake in the middle of an already
>>     established non-TLS TCP where some traffic already traveled .. the
>>     WS handshake at least.)
>>
>>     I think it would be good to include explicit text into the MUX
>>     draft, e.g.
>>
>>     """
>>     An implementation MUST NOT multiplex multiple logical channels to
>>     WebSocket addresses with different schemes (ws: versus wss:) on a
>>     single physical WebSocket connection.
>>
>>     For example, two WebSocket connections to ws://domain.com and
>>     wss://domain.com must not be shared on a single physical WebSocket
>>     connection to domain.com <http://domain.com>.
>>
>>     """
>>
>>     I also think it would be helpful to include explicit text describing
>>     what WebSocket addresses are eligible for sharing, e.g.
>>
>>     """
>>     An implementation MAY multiplex multiple logical channels to
>>     different WebSocket addresses if and only if the WebSocket addresses
>>     share the same WebSocket scheme, the hostname resolves to the same
>>     IP address and the same port.
>>
>>     For example, connections to all of the following WebSocket addresses
>>     may be multiplexed over a single physical WebSocket connection
>>     (assum domain.com <http://domain.com>, domain2.com
>>     <http://domain2.com> and sub1.domain.com <http://sub1.domain.com>
>>
>>     all resolve to the same IP address):
>>
>>     ws://domain.com
>>     ws://domain.com:80
>>     ws://domain.com/foo
>>     ws://domain.com:80/foo
>>     ws://domain.com/bar
>>     ws://domain2.com
>>     ws://sub1.domain.com
>>     ws://sub1.domain.com:80
>>     ws://sub1.domain.com:80/bar
>>
>>     Note: When a WS address does not specify an explicit port, the port
>>     is the default port for the given WS scheme (ws: = 80 and wss: = 443).
>>     """
>>
>>
>>
>>
>>     /Tobias
>>
>>
>>     ______________________________**_________________
>>     hybi mailing list
>>     hybi@ietf.org <mailto:hybi@ietf.org>
>>     https://www.ietf.org/mailman/**listinfo/hybi<https://www.ietf.org/mailman/listinfo/hybi>
>>
>>
>>
>