Subject: [hybi] Masking Straw Man, and anticipating non-wg reviews

From: Bjoern Hoehrmann <[email-masked]>
Date: Sun, 26 Dec 2010 20:24:26 +0100

Hi,

  Salvatore asked us to discuss approaches to masking, and looking at
John's proposal we should perhaps start with something very simple and
go from there, so I am going to propose an instance of the straw man I
suggested two weeks ago. The idea is to have a record of the problems
we are trying to address and the trade-offs we are making, so we can
document them in the specification and point reviewers who have not
followed the working group's proceedings to it.

As with John's proposal the assumption is that the handshake has com-
pleted successfully. The protocol would be as follows:

Endpoints exchange masked frames. Masked frames consist of a Key of a
fixed length followed by an encoded frame. An encoded frame is a frame
as they are currently specified in our latest draft xor'd by the Key
(repeated/truncated to cover the whole frame as needed). Endpoints
choose keys as they see fit with no dependencies on anything. So,

  masked-frame = <key> <actual-frame `xor` repeated-key>

This is roughly the most simplistic protocol design involving masking.
There have been a number of suggestions to modify this design, Maciej
for instance would like the client to send a CONNECT talisman ahead of
anything else, Greg would, as I understand it, involve Hello frames
here past the HTTP-level handshake, some object to optional masking
(this masking is optional in that you can choose zero as key if you
feel like doing so), there are suggestions to pull in additional keys
and apply digest algorithms instead of simply using the repeated-key,
some would rather not mask the frame header, and so on.

We should anticipate that someone from outside the working group will
argue, for instance, that we could make the key eight bytes long, and
then it would take millions of years to go through all suitable keys
over a typical uplink as available today, so all those suggestions
make the protocol neither more robust nor more efficient, unless you
mean to trade, say, masked-frame size for CPU cycles or vice versa.

Similarily: John's proposal isn't clear whether servers would even
send any masked-frames or just send the frames directly. Some might
argue that the layout should be the same for simplicity. Others might
argue that making the frame layout different, or involving nonces ex-
changed during the handshake in the masking process makes some simple
applications too inefficient (consider a voice or video chat where the
"server" does nothing but pass frames along to overcome firewalls that
prevent direct connections; that would be trivial with the straw man,
but would require transcoding masked frames otherwise).

We need to have some replies to such objections ready, but so far the
discussion did not offer much in that regard. So how do You think this
straw man must be modified to meet your requirements (which are what?)
and why?

regards,
-- 
Björn Höhrmann · mailto:[email-masked] · 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: Adam Barth <[email-masked]>
Date: Sun, 26 Dec 2010 16:09:49 -0800

We already discussed why this masking design is insufficient.  Please
refer to the earlier discussion if you're unsure of the reasons.  I
don't see a big need to re-hash these issues at this time.

Adam

On Sun, Dec 26, 2010 at 11:24 AM, Bjoern Hoehrmann <[email-masked]> wrote:
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 27 Dec 2010 09:34:20 +0100

>don't see a big need to re-hash these issues at this time.

Thank you for illustrating my point. As Adam demonstrates, if someone
brings these issues up again, we could hand them a TOFU "RTFM" response,
but advancing our deliverables would be much easier if we would offer
them a summary and pointers to relevant technical information instead.
-- 
Björn Höhrmann · mailto:[email-masked] · 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/