Re: [secdir] Secdir review of draft-ietf-hybi-permessage-compression-22

Takeshi Yoshino <tyoshino@google.com> Wed, 22 July 2015 11:51 UTC

Return-Path: <tyoshino@google.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9901B2EEF for <secdir@ietfa.amsl.com>; Wed, 22 Jul 2015 04:51:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level:
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NoxWQaPzF2R for <secdir@ietfa.amsl.com>; Wed, 22 Jul 2015 04:51:52 -0700 (PDT)
Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A52F71B2F90 for <secdir@ietf.org>; Wed, 22 Jul 2015 04:51:35 -0700 (PDT)
Received: by oihq81 with SMTP id q81so142005090oih.2 for <secdir@ietf.org>; Wed, 22 Jul 2015 04:51: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:from:date:message-id:subject:to :cc:content-type; bh=eGLRaCucGfcLJTrb2pY/EfghQC+95y1tf/NvnbrXXRk=; b=lLS2FY7qk4dKsGoIaaDkoTwcDh9zD8kAAOtZzOmYgHwEMU5YgQWznVyNHZVBTX1TTu uAzYyVjDyop7tkq0gCtHGyflAJwsFsWNc25Y+utF2pxFSp5ascMP+qEnMYoQY6Gr060u Y4XSF3HhOAJi1FZdabcl/SSCiXYNrldK9M7NN2z2807LdXAucmQgYqBSd4oKcdSYCGwE NAqbhzJs+Qr4+RgDRAsSA32jddevyioOL4jTl1qnG0hB0dvd6JRq3ycddANubTMBY5Ur pmcOtWtf8vugeQ5NEciFC0jTZmPz6iJQBSo75ihKC1DbEonNAzARdddgjiGUXJgWLUEe XiVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=eGLRaCucGfcLJTrb2pY/EfghQC+95y1tf/NvnbrXXRk=; b=Afa486JK2df/s2Qy9b8QQjYdnCRO9419PtvV1t7ah2GQQypdnlAC8Eifbvowpz7Gfv 8K582QTUpB6YCl6+gjliKZ2p2P0finw+JIqYVflsFQMf8vpYn9JIpX9bFTEyV8fmo9Wf CHfZJFLO6HiC/p10cfjk4sy0eX+oXslUeXSKFrK95Q/Zw2h7QmLQwumwlnj30zUjkqgv KduhACfBFiTNtJh+agFuWr0PliW7dMVK86zI2rT7Aok628ML4s3Va+FUPUGKSUCwAuYx GIMIbbHP4FQgId2piaKBiyvDj41KiPUxIkkU1CEfZzZ7VnBwgrUIwzmI0HADoffOiBt+ TJaw==
X-Gm-Message-State: ALoCoQmUQF3Y+u3IqzwQeQ7lhnMi/Gx+9RuyiAsO37+zPHGSH4PmhU0iWHtac6bY3loSHDC+DUBi
X-Received: by 10.182.199.103 with SMTP id jj7mr1982759obc.49.1437565895138; Wed, 22 Jul 2015 04:51:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.202.66.130 with HTTP; Wed, 22 Jul 2015 04:51:15 -0700 (PDT)
In-Reply-To: <CAH9hSJZtXdEMhOyBW3+w9sjnemfDcUUh+VzPoNaH=UtnbW6wzQ@mail.gmail.com>
References: <558B1E9C.8080505@nostrum.com> <CAH9hSJYdb95V48jvuGAg5ymjhaaAbcYcuv=+OiTFnJ+PRyRNuQ@mail.gmail.com> <559AA6B2.3@nostrum.com> <CAH9hSJZtXdEMhOyBW3+w9sjnemfDcUUh+VzPoNaH=UtnbW6wzQ@mail.gmail.com>
From: Takeshi Yoshino <tyoshino@google.com>
Date: Wed, 22 Jul 2015 20:51:15 +0900
Message-ID: <CAH9hSJbVOGV9ASC1CQNUwKgD8GJ82TCDqMBSPvRMoEzUBFw3Ow@mail.gmail.com>
To: Robert Sparks <rjsparks@nostrum.com>
Content-Type: multipart/alternative; boundary=e89a8ff1c9ec85962c051b756409
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/gRnUfEJX0zXsj0nT41bQhSxql1g>
Cc: draft-ietf-hybi-permessage-compression.all@ietf.org, "hybi@ietf.org" <hybi@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] Secdir review of draft-ietf-hybi-permessage-compression-22
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jul 2015 11:51:55 -0000

HyBi people,

Please respond to this thread if you want to keep the section as-is (or
with some improvement. texts welcome).

I plan to revise it by replacing with a warning (saying "don't change the
compression unless you don't know it") unless anyone objects to it.

Takeshi

On Tue, Jul 14, 2015 at 5:32 PM, Takeshi Yoshino <tyoshino@google.com>
wrote:

> On Tue, Jul 7, 2015 at 1:02 AM, Robert Sparks <rjsparks@nostrum.com>
> wrote:
>
>>  (adding the hybi list)
>>
>
> Hi Robert,
>
> Sorry for delay.
>
>
>>
>> It seems to me that this effectively adding an actor (the intermediary) ,
>> and defining (not as explicitly as I think it needs to be) protocol
>> mechanics for that actor in ways that the base specification did not
>> anticipate.
>>
>>
> Done more archaeology...
>
> This text originates from the intermediaries section introduced on update
> between
> draft-tyoshino-hybi-websocket-perframe-deflate-06 and
> draft-ietf-hybi-websocket-perframe-compression-00
>
> I couldn't find the original proposal which led to this text from my mail
> box. I thought someone made one on HyBi, but only found my comment on
> publish of -00.
>
> As far as I remember, we initially didn't intend to add any requirement,
> expectation, etc. to the main (RFC 6455) spec by this spec. The text now
> looks like an additional requirements to complement the main spec just
> unexpectedly (unexpectedly at least for me). I added this text just to note
> a fact that when one wants to change compression, handshake should be also
> altered appropriately, otherwise, it doesn't work. Maybe the following
> texts in RFC 6455 have a similar role.
>
>    o  As control frames cannot be fragmented, an intermediary MUST NOT ...
>
>    o  An intermediary MUST NOT change the fragmentation of a message if ...
>
>    o  An intermediary MUST NOT change the fragmentation of any message ...
>
>
>> I'm not comfortable that the consequences of these new mechanics
>> (specifically - that the intermediary can directly participate in the
>> extension negotiations, and change the results) are well understood.
>>
>
> Did you mean "not well understood"?
>
>
>> The additions to the text you propose will certainly help point out that
>> there might be some, and the message that the endpoint won't have insight
>> into how its messages are handled beyond the intermediary needs to be
>> prominent.
>>
>
> Yeah. But now I'm wondering if it's in the scope of protocol
> standardization or not. Seems the text should be changed to look like a
> warning (don't do this or your stack won't work) as discussed above.
>
>
>>
>> But I wonder if the mechanics of an intermediary _changing the protocol
>> signalling_ is something the working group should explicitly work on
>> writing down?
>>
>>
> I've been viewing the PMCE from the view point of a browser developer.
> Like fragmentation, permessage-deflate is also just a transport-level thing
> which is invisible/transparent to the final user of the communication (e.g.
> JavaScript using the WebSocket API). My comments are based on this idea.
> But with your comment, I just noticed that it's not trivial.
>
> Actually, the extensions under use is exposed to the user of the protocol
> via _Extensions in Use_. We should have been aware of that.
>
>
>> RjS
>>
>>
>> On 6/30/15 3:42 AM, Takeshi Yoshino wrote:
>>
>>  Thank you for review, Robert.
>>
>>  On Thu, Jun 25, 2015 at 6:18 AM, Robert Sparks <rjsparks@nostrum.com>
>> wrote:
>>
>>>  I have reviewed this document as part of the security directorate's
>>> ongoing effort to review all IETF documents being processed by the
>>> IESG.  These comments were written primarily for the benefit of the
>>> security area directors.  Document editors and WG chairs should treat
>>> these comments just like any other last call comments.
>>>
>>> Summary: Ready with issues
>>>
>>> (fwiw, I also reviewed up through version -24).
>>>
>>> Section 7 (Intermediaries) should be more explicit that it's talking about an intermediary doing compression on one side and not (or doing different compression) on the other.
>>> (If that's not what it's trying to set up, please clarify).
>>>
>>>  OK. So, I'd like to change the text as follows:
>>
>>  When an intermediary proxies ... Per-message Compression of messages
>> received from one peer, and then forward the messages to the other peer, if
>> the intermediary ...
>>
>>
>>>  It's not clear from reading RFC6455 that the idea of intermediaries changing the contents of the websocket extension negotiation mechanism was considered - have I missed the text in that RFC that discusses that?
>>> Are there other extensions that suggest similar behavior? It's not immediately clear that the protocol mechanics do the right thing when the different negotiations on each side of the proxy fail differently.
>>>
>>>  It's not well discussed in RFC6455. Right. AFAIK, there's no such
>> extension defined, yet.
>>
>>  I understand that this text (intermediary section in the I-D) works
>> just not to disallow change of compression but there's nothing in RFC6455
>> that guarantees that such transformation doesn't cause any issue with other
>> infrastructure of the WebSocket protocol.
>>
>>  I believe that unless any extension that interferes with the other
>> negotiated extensions (e.g. counting the number of negotiated extensions,
>> relying on PMCE, etc.), the core WebSocket protocol (things defined in
>> RFC6455) should work. If such an extension is introduced, it would be just
>> considered to be incompatible with PMCEs, or that extension should describe
>> how to coordinate with change on PMCE in the intermediaries section of its
>> RFC.
>>
>>  I think this is more reasonable than prohibiting change on Per-message
>> Compression by intermediaries.
>>
>>>  This also seems to put an endpoint in a position where it has no say on what an intermediary does with the traffic on the other side of it. Is that worth discussing in the document?
>>>
>>>  Ah, right. Maybe some text like:
>>
>>  "It's not guaranteed that the PMCE which an endpoint has negotiated in
>> the opening handshake is preserved in the whole path to the peer endpoint."
>>
>>
>>>  It would be good to point to, or provide, a discussion of how the extension negotiation mechanism in WebSockets is meant to be protected.
>>>
>>>
>>  As a general discussion to cover other extensions (if they want. by
>> referring to this to-be-RFC) like the section defining terms to complement
>> RFC6455 [1]?
>>
>>  [1]
>> https://tools.ietf.org/html/draft-ietf-hybi-permessage-compression-24#section-3
>>
>>
>>
>>
>