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

Takeshi Yoshino <> Tue, 30 June 2015 08:43 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1F4D81A1B92 for <>; Tue, 30 Jun 2015 01:43:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.388
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3LtoV-lLPRxr for <>; Tue, 30 Jun 2015 01:43:14 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1A1031A1BA4 for <>; Tue, 30 Jun 2015 01:43:06 -0700 (PDT)
Received: by oigx81 with SMTP id x81so2271861oig.1 for <>; Tue, 30 Jun 2015 01:43:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=rcAjctmZeQ6vYsz3epaMSfVDADd3Wcgo6zFNaB1p0ko=; b=DgPmGDyXMCo+9FYIpLlnVDDwlILVqs9KvGhCNGP0vCWcq7u2dhRDFkMkSmhO4t6/dw c9+9ff9gy5TYI8RWfiRdPRjnlXoRQqSThvpqenAZzK245Fk5lQ4/nXIglMOWnbnnwLO5 Pf21npY2hWqiDMrXbneag8+jDKPmkVEsLwwpPBVPtneF0OyiDIgvS2GfSaRF/YTvoVEL Iu73csDQzkfhvNxRxc1B2QCr9thWC5+N6B08Kd7+5DA/viwGmNFUG4VdYUhBJPlR8BcQ mY+rQEwiBjz709DWAtQ8pdvL8eN9uKaKxEBeuu0+q9wK3dkzRSrkt3vLETtIx+2NmVvl uzag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=rcAjctmZeQ6vYsz3epaMSfVDADd3Wcgo6zFNaB1p0ko=; b=BCB4biWHJZJQiv2as8wvPQpt6QiMkDss/1BunCqf9BJYv2jv1vehnGyzmsCEhPkizH +jgOInlpOKN7Swn995d+oQ2WzKpHnqTrQ++xI1ObgztgmPwoxWDpKGzBoFazyshP0+Aw 3G164nSPkfQFSpxgkdEuXjSWxXqso/a+g7qU0OgjmYsaZKOg2OjZrJy/HiObiPT1RTa1 LrnT7elotxIuutaOtAnLviXUcxenOkqz1ZTaOwg8M/CeRBtCfmrv4DSsbRs+vvY4JbX6 4VNdoDjDQv9zV8u9kQV+uZniSomCvPlKZCft+/9eJxW5gC1vHkYROnCt2wKIeE7TioB7 vXuQ==
X-Gm-Message-State: ALoCoQmzOU2NAx6IUXLlYFyITXX0g8hmGAGGjfnx7wvSkW3mbXdBQa/HraT6tBDP3ASJIP6tWnbR
X-Received: by with SMTP id g131mr16283728oia.122.1435653785557; Tue, 30 Jun 2015 01:43:05 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 30 Jun 2015 01:42:45 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Takeshi Yoshino <>
Date: Tue, 30 Jun 2015 17:42:45 +0900
Message-ID: <>
To: Robert Sparks <>
Content-Type: multipart/alternative; boundary="001a113cee2ae8c9670519b831b7"
Archived-At: <>
X-Mailman-Approved-At: Tue, 30 Jun 2015 02:01:21 -0700
Cc: "" <>,, "" <>, "" <>
Subject: Re: [secdir] Secdir review of draft-ietf-hybi-permessage-compression-22
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 30 Jun 2015 08:43:16 -0000

Thank you for review, Robert.

On Thu, Jun 25, 2015 at 6:18 AM, Robert Sparks <> 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

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]?