Re: [hybi] Masking only Payload/Extension Data

Andy Green <andy@warmcat.com> Wed, 09 March 2011 08:44 UTC

Return-Path: <andy.warmcat.com@googlemail.com>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C1E13A68B0 for <hybi@core3.amsl.com>; Wed, 9 Mar 2011 00:44:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.628
X-Spam-Level:
X-Spam-Status: No, score=-3.628 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oK4SrQkmV-y0 for <hybi@core3.amsl.com>; Wed, 9 Mar 2011 00:44:11 -0800 (PST)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id DA7DF3A68AA for <hybi@ietf.org>; Wed, 9 Mar 2011 00:44:10 -0800 (PST)
Received: by wwa36 with SMTP id 36so221274wwa.13 for <hybi@ietf.org>; Wed, 09 Mar 2011 00:45:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=dqtkrCS0QRhMqCnxEH3hvyVOF6mIo+xg3S9kM3b0CGU=; b=cz+O0y6yAkeeH45Q87952DIGyM+1lrNCPzLWyvIsqG+RupOX7yZ5Z7izLiACyJgJmr IuU51yzV3pOwsEUlFyi5QDCfpQXrjj6RSRzwF+nn54ZoCBZvFsuXx0qwDOfA9+frmeCV CM5QVaPk9WZgx82UCGwxMx+wQ6znrvEThmIYA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=QkMhGvSR4SrtAMzPm2L7ZIxlcLMmuy1co1PGuT5F3K8kWWrG1vhApVbCeeuez9/Z+m a4dFYMGYu/0zfqub30Jx+HWIEuohIqYfA4IrcpR4RzV80tQBXH7C52Sse99KeESSY167 Bsv98hU7YttFGONCZvfFmQVg8UK3SlxbMwvbk=
Received: by 10.227.201.130 with SMTP id fa2mr5410723wbb.172.1299660326400; Wed, 09 Mar 2011 00:45:26 -0800 (PST)
Received: from otae.warmcat.com (cpc1-nrte21-2-0-cust677.8-4.cable.virginmedia.com [81.111.78.166]) by mx.google.com with ESMTPS id u9sm1284126wbg.0.2011.03.09.00.45.24 (version=SSLv3 cipher=OTHER); Wed, 09 Mar 2011 00:45:25 -0800 (PST)
Sender: Andy Green <andy.warmcat.com@googlemail.com>
Message-ID: <4D773E24.7080104@warmcat.com>
Date: Wed, 09 Mar 2011 08:45:24 +0000
From: Andy Green <andy@warmcat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110302 Fedora/3.1.8-3.fc16 Thunderbird/3.1.8
MIME-Version: 1.0
To: ifette@google.com
References: <AANLkTim7js6hPBMoEgmzr3gH-NuRYkEZ-pAePkgo=Q=L@mail.gmail.com> <AANLkTimcTUYRMBA7XfYpbUNX26eup+oq2C3cL-q8+gf-@mail.gmail.com>
In-Reply-To: <AANLkTimcTUYRMBA7XfYpbUNX26eup+oq2C3cL-q8+gf-@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Hybi <hybi@ietf.org>
Subject: Re: [hybi] Masking only Payload/Extension Data
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Wed, 09 Mar 2011 08:44:12 -0000

On 03/09/2011 08:27 AM, Somebody in the thread at some point said:

Hi -

> Can someone please explain to me why this matters? Given that we went
> with a 32-bit mask included in the frame, and it's just xor, I'm really

It's not driven by complaints about the masking complexity.

> not sympathetic to arguments about "it's hard to unmask" etc. The only
> thing that I've heard that resonates at all is that you have to know
> which direction the connection is going, e.g. which is the client and
> which is the server, that said it seems like any proxy doing anything
> interesting would probably already know this?

Because it's a streamed protocol, one problem it creates is a snooper 
trying to perform frame sync on stuff coming out of a client can find a 
pathological situation as it is, it's literally a randomized stream with 
no structure at all that may not have any framing relationship to packet 
boundaries.  It's four random bytes then everything xor'd with random 
without let-up, there's nothing to grab hold of once it has started.

If the framing is left standing proud of the mask action, there is at 
least always framing structure in the stream to sync on.

Also although I am grateful for the choice you made of simply 4-byte 
mask compared to AES and other castles in the air, actually sticking a 
fixed 4-bytes on the front in one direction is kind of a hack protocol-wise.

If the framing is definitely the boss in this protocol, and not 
subordinate to the masking, then it will be possible to negotiate 
different masking schemes at handshake-time if that becomes desirable 
without changing intermediaries that don't care about payload but must 
watch the streams for control packets or whatever: the intermediaries 
can just obey framing rules even with no masking negotiated or ROT13 or 
whatever negotiated that they don't understand or care about, but now 
won't break on.

As mentioned one specific case of wanting to do the above is Toni 
Ruottu's where the browser emits server frames.  He can solve his 
quandry with just an extension then, changing masking rules without 
upsetting the framing rules and so allowing things that don't understand 
to not break.

-Andy