Subject: Gen-ART and OPS-Dir review of draft-ietf-httpbis-header-compression-10

From: "Black, David" <[email-masked]>
Date: Tue, 13 Jan 2015 02:13:50 +0000

This is a combined Gen-ART and OPS-Dir review.  Boilerplate for both follows ...

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at:

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These comments
were written primarily for the benefit of the operational area directors.
Document editors and WG chairs should treat these comments just like any other
last call comments.

Document: draft-ietf-httpbis-header-compression-10
Reviewer: David Black
Review Date: Jan 12, 2015
IETF LC End Date: Jan 14, 2015
IESG Telechat date: Jan 22, 2014

Summary: This draft is on the right track, but has open issues
 		described in the review.

The draft describes a new compression format for HTTP, HPACK.
The draft is generally well-written although not the easiest read
due to the amount of detail necessary to specify this compression
format.  I did not check the examples in Appendix C in detail.

I found a couple of major issues, and a bunch of minor one,
plus the usual crop of nits.

The first major issue involves the dense packing of static and
dynamic table indices, and what appears to be an inability to
ever change this  and HPACK in general (if that's a "feature,"
an explanation of why is in order). 

The second major issue is that I can't find the list of fields
that are required to use the never-indexed syntax for security
reasons.

All of the minor issues should be straightforward to resolve.

For the OPS-Dir review, most of the operational considerations are
for the HTTP version 2 protocol that uses this compression format,
and hence belong in the HTTP version 2 draft, and not here.

Major issues:

-1- Section 2.3.3

   Indices between 1 and the length of the static table (inclusive)
   refer to elements in the static table (see Section 2.3.1).

   Indices strictly greater than the length of the static table refer to
   elements in the dynamic table (see Section 2.3.2).

Having the dynamic table indices start immediately after the static
table indices is asking for problems if the static table is ever
extended.  This dense use of table indices looks like it was done to
pack as much as possible into the index range 1-127, which has an
efficient 1-byte representation in HPACK, but the static table can
never be changed without going to a completely new HPACK format.

I think the real concern here is what the intentions are for revising
HPACK in the future, including expansion of the static table, and how
the resulting multiple versions of HPACK would be signaled.  My sense
from this draft is that HPACK cannot be changed, ever, period - I'm
not sure whether that's a wise design choice - it definitely needs
to be explained.

-2- Where is the list of fields to which the never indexed representation
MUST be applied for security reasons?

Minor issues:

-A- Section 1.3:

   Dynamic Table:  The dynamic table (see Section 2.3.2) is a header
      table used to associate stored header fields to index values.
      This table is dynamic and specific to an encoding or decoding
      context.

Need to define "header table" before using it in this definition, or
point to the discussion of the term in Section 1.

-B- Section 4.2

This paragraph is unclear on what has to be communicated:

   Multiple updates to the maximum table size can occur between the
   sending of two header blocks.  In the case that the value of this
   parameter is changed more than once, if any changed value is smaller
   than the new maximum size, the smallest value for the parameter MUST
   be sent in an encoding context update.  The altered maximum size is
   always sent, resulting in at most two encoding context updates.  This
   ensures that the decoder is able to perform eviction based on the
   decoder table size (see Section 4.3).

I suggest:

   Multiple updates to the maximum table size can occur between the
   sending of two header blocks.  In the case that this size
   is changed more than once in this interval, the smallest
   maximum table size that occurs in that interval MUST 
   be sent in an encoding context update.  The final maximum size is
   always sent, resulting in at most two encoding context updates.  This
   ensures that the decoder is able to perform eviction based on
   reductions in decoder table size (see Section 4.3).

-C- Section 4.4:

This paragraph is unclear on whether eviction occurs before or after
adding an entry:

   Whenever a new entry is to be added to the dynamic table, entries are
   evicted from the end of the dynamic table until the size of the
   dynamic table is less than or equal to (maximum size - new entry
   size), or until the table is empty.

I suggest inserting "(before the new entry is added)" after
"until the size of the dynamic table"

-D- Section 4.4:

   If the representation of the added entry references the name of an
   entry in the dynamic table, the referenced name is cached prior to
   performing eviction to avoid having the name inadvertently evicted.

Cached where and how?  Please explain.

-E- Section 5.1

N is supposed to be the number of bits in the prefix, which makes the
use of N in "Value (N)" incorrect in Figure 2.  I think just deleting
"(N)" in the figure will fix this.

-F- Section 7.1.3

This section applies only to intermediaries that are aware of HPACK
(and presumably use it).  That should be stated, along with a reminder
that an HPACK-unaware intermediary that does HPACK-unaware compression
may create vulnerabilities to attacks like CRIME.

Nits/editorial comments:

-- Section 1:

   As
   Web pages have grown to include dozens to hundreds of requests,

"include dozens to hundreds of requests" ->
	"require dozens to hundreds of requests to retrieve"

-- Section 1.3:

   Header Field:  A name-value pair.  Both the name and value are
      treated as opaque sequences of octets.

Indicate what header or headers these fields come from.

   Static Table:  The static table (see Section 2.3.1) is a header table
      used to associate static header fields to index values.

"associate static header fields" ->
	"statically associate commonly used header fields"

-- Section 2.2:

   To decompress header blocks, a decoder only needs to maintain a
   dynamic table (see Section 2.3.2) as a decoding context.  No other
   state is needed.

"state is needed" -> "dynamic state is needed"
The static table is part of decoding state, it just doesn't change.

-- Section 2.4:

The rationale for the additional format that forbids ever encoding a
field should be repeated here (it's stated in Section 2.3).

-- Section 3.1:

   Once a header field is decoded and added to the reconstructed header
   list, it cannot be removed from it.

"it cannot be removed from it" -> "the field cannot be removed"

-- Section 5.1:

I found this text hard to read because the figures come before the text
that explains them.  At a minimum add "as shown in Figure X" to the
paragraphs after both figures 2 and 3 (for X=2 and X=3).

idnits complained that it couldn't find an IANA Considerations
section.  Please add an empty one (stating that there are no IANA
Considerations) if/when the draft is revised.

--- Selected RFC 5706 Appendix A Q&A for OPS-Dir review ---

A.1.  Operational Considerations

These are almost completely missing.  They should be in the main HTTP
version 2 draft, which I have not reviewed as part of this review.

The HPACK format appears to have been designed to never be changed.
I hope that's a well-thought out choice - see major issue -1-.

A.2.  Management Considerations

These are N/A - they would apply to the main HTTP version 2 protocol
which discusses use of HPACK.

A.3. Documentation

Obviously, the HTTP version 2 protocol will have a major operational
impact on the Internet, but that's a matter for the HTTP version 2
draft, not this one.

The shepherd writeup refers obliquely to interop events, so I infer
that this compression format has been implemented and at least
"smoke-tested."

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: Martin Thomson <[email-masked]>
Date: Tue, 20 Jan 2015 00:22:03 -0800

In the absence of answers from the editors, I can provide an
explanation for the choices you have identified as being issues.

I've also turned your comments into a pull request.

https://github.com/http2/http2-spec/pull/693

You can review that; but the editors will likely have some more to say
about this.

(Note: I dropped opsdir from this reply, there was no substance there.
I look forward to a review of HTTP/2 proper.)

> an explanation of why is in order).

That is entirely intentional.  The same question has been raised
several times, and the answer from the working group has been
consistent:

This compression scheme will not be the fastest, or give the best
compression ratios.  It will have those limitations, but it will be
easy to understand, implement and get correct and it will provide good
enough compression performance.

It will also be completely inflexible, but if that turns out to be a
problem, we will fix it in HTTP/3, even if that means that HTTP/3 is
almost entirely identical to HTTP/2.

A few people objected to this on the grounds that this flies in the
face of a body of accepted wisdom on extensibility in protocols.  But
that flexibility turns out to be contrary to the aforementioned goals.
Ultimately, this choice was very clearly and consistently the
consensus of the working group.

I'm going to propose the following text be added:

   The HPACK format is intentionally simple and inflexible.  Both
   characteristics reduce the risk of interoperability or security
   issues based by implementation error.  No extensibility mechanisms
   are defined; changes to the format are only possible by defining a
   complete replacement.

> that are required to use the never-indexed syntax for security

That list doesn't exist, because the need to avoid indexing is highly
contextual.  Like padding, I don't expect this feature to be widely
used, because it requires specific knowledge, but it is necessary to
avoid low-entropy secrets from being exposed to CRIME-like attacks.

I'll note that the combination of "low-entropy" and "secret"
immediately makes this a scenario into which only the very careful and
knowledgeable should venture.  But apparently some do and those few
(along with the paranoid) need the mechanism.  The rest of us can just
use more entropy on our secrets.

I can't confirm, but I think we're using it in Firefox for short
cookies (over which we have little control, but still wish to
protect).

[snip]
> point to the discussion of the term in Section 1.

Or you could not use "header table":

   Dynamic Table:  The dynamic table (see Section 2.3.2) is a table that
      associates stored header fields with index values.  This table is
      dynamic and specific to an encoding or decoding context.

> This paragraph is unclear on what has to be communicated:
[snip]
>    reductions in decoder table size (see Section 4.3).

LGTM (I apologize, that was my text).

> "until the size of the dynamic table"

How about this instead:

s/Whenever a new entry is to be added.../Before a new entry is added.../

> Cached where and how?  Please explain.

I don't find this unclear, would "saved" cause less confusion than "cached"?

> "(N)" in the figure will fix this.

I think that's a fair point; I think removing the "(7)" from Figure 3
is necessary though.

>         "require dozens to hundreds of requests to retrieve"

"to retrieve" is too specific.

> Indicate what header or headers these fields come from.

?

>         "statically associate commonly used header fields"

I'm going to avoid the "commonly used" value judgment.  Whether they
are commonly used or not isn't pertinent.  I'll let the editors decide
if they would prefer your text.

> field should be repeated here (it's stated in Section 2.3).

With the forward reference to 6.2.3, which contains an explanation, I
think that this is adequately covered already.

> -- Section 5.1:

I think moving the figures and related text is better.

> Considerations) if/when the draft is revised.

I tend to think that absence of "IANA Considerations" and a section
with "This document has no IANA actions." should be treated as
precisely equivalent.  But I guess that ship sailed already.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 20 Jan 2015 10:14:40 +0100

On 2015-01-20 09:22, Martin Thomson wrote:
> ...
> ...

Having no "IANA Considerations" causes additional work because multiple 
parties will have to check whether there's indeed nothing to consider, 
or whether the authors just forgot to think about these. It causes 
unneeded friction and delays.

Best regards, Julian

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 20 Jan 2015 13:06:22 +0100

On 01/20/2015 10:14 AM, Julian Reschke wrote:
> Having no "IANA Considerations" causes additional work because 
> multiple parties will have to check whether there's indeed nothing to 
> consider, or whether the authors just forgot to think about these. It 
> causes unneeded friction and delays.
>
> Best regards, Julian
>
This was a long debate approx. 10 years ago (as far as I remember).

The information about whether or not there are IANA considerations has 
to be easily available to IANA as part of IESG review.

The two places where it was reasonable to have it were (again, according 
to memory) in the I-D and in a cover page for the package - letting IANA 
read through the document in detail trying to figure out whether or not 
any IANA action was requested (the previous approac) was not thought 
workable any more.

Since we didn't have well defined cover page at the time, the arguments 
for putting the info in the I-D won out over the arguments for defining 
and managing a cover page.

It's been part of the I-D specification (and, as noted, idnits).
Please just do it this way until we have a decision to change it.

Harald

---

From: RUELLAN Herve <[email-masked]>
Date: Tue, 20 Jan 2015 18:48:50 +0000

Thanks for all these edits, Martin.

I did a few additional ones in:
https://github.com/http2/http2-spec/pull/694

See below for my comments.

Hervé.
________________________________________
> From: Martin Thomson <[email-masked]>
> Sent: Tuesday, January 20, 2015 09:22
> To: Black, David
> Cc: [email-masked]; RUELLAN Herve; General Area Review Team ([email-masked]); [email-masked]; [email-masked]
> Subject: Re: [Gen-art] Gen-ART and OPS-Dir review of draft-ietf-httpbis-header-compression-10
> 

I think that this paragraph is too implementation oriented. In particular, the "cached" is implementation-dependent. I propose changing it to:

                    A new entry can reference the name of an entry in the
                    dynamic table that will be evicted when adding this new
                    entry into the dynamic table. Implementations have to take
                    care not deleting the referenced name from memory while
                    evicting the referenced entry from the dynamic table.

> I think that's a fair point; I think removing the "(7)" from Figure 3

The "(N)" in the figure was supposed to indicate the size of the value in bits. But I'm OK with removing it.

> if they would prefer your text.

I also prefer to avoid "commonly used". 

> think that this is adequately covered already.

I added it here, because it is somewhat hidden in 6.2.3 (or at least less visible).

> precisely equivalent.  But I guess that ship sailed already.

I added this "IANA Considerations" section.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 20 Jan 2015 10:52:15 -0800

> https://github.com/http2/http2-spec/pull/694

LGTM, I suggested a reword of one of the sentences.

---

From: Hervé Ruellan <[email-masked]>
Date: Thu, 22 Jan 2015 18:47:35 +0100

David,

Some responses below.

On 01/20/2015 08:22 PM, Black, David wrote:
> Herve and Martin,
>
> -2-
>
> For major issue -2- regarding when to use the never-indexed format in order
> to avoid attacks like the CRIME attack on DEFLATE, I disagree with the
> discussion:
>
> Designing a mechanism to resist an attack but failing to provide guidance
> (either here or in the main HTTP v2 draft) on how to use it to resist that
> attack does not solve the actual problem, no matter how clever the
> mechanism.
>
> I hope the Security ADs notice this discussion, because the current
> situation looks like a security flaw from here (likely to result
> in insecure implementations, even though the implementations contain
> the mechanism needed to fix the security problem).
>
> If a list of specific fields is not reasonable, some specific guidance on
> where and why this mechanism needs to be applied is in order, as (IMHO)
> it is unreasonable to expect the entire global implementer community
> to have a detailed working command of the CRIME attack and its HPACK
> implications wrt specific pieces of information exchanged in the HTTP v2
> protocol.
>
> I expect HPACK to be implemented as part of HTTP v2 in systems whose
> implementation teams have far less security talent & insight by complarison
> to the major browser vendors, so while I appreciate the Firefox example,
> I don't consider it to be typical of many of the groups that are likely
> to  implement HTTP v2.

We started building HPACK when CRIME showed that using DEFLATE for 
compressing headers was not a secure solution.

The security review done when HPACK started to stabilize raise the issue 
that HPACK indexing table could still be used as an oracle for finding 
some header field values.

With the original HPACK, there were already several possible mitigation 
to prevent an attacker to take advantage of this oracle:
- The value space to search should be large enough to make the attack 
impractical.
- If this is not sufficient, a deployment of HPACK can select not to 
index sensitive header field values, or even not to index any header field.

To go further, it was decided to add a specific op-code for signalling 
to an intermediary that a header field was not indexed because it was 
deemed sensitive and should not be indexed further down the path.

The WG added this mechanism to make HPACK robust against foreseen 
possible attacks. However, security is a moving target, and I think that 
a list of header fields that should use it is difficult to build: this 
depends on the application/deployment, and this will evolve with time.

So I think we can offer guidance on how to use the "never indexed 
literals" mechanism but not much more. Section 7.1 already goes into 
details on how to protect header fields from unwanted probing. The last 
paragraph of section 7.1.2 and the whole section 7.1.3 targets in 
particular the "never indexed literals" mechanism. If you find these 
section insufficient or not clear enough, I can try to improve them.

>
> -- Everything beyond here is an editorial nit --
>
>>>> -- Section 1:
>>>>
>>>>     As
> How about "to access"?  If not, I guess the text is ok.

I think I like Martin's version:
    require dozens to hundreds of requests,
> For HPACK, these fields are from the HTTP v2 header, right?

Yes.

> How about "statically associate header fields that occur frequently in practice" ?
>
> The intent of the suggested edit it to provide some insight into why the static
> fields exist.

I understand your intent and I'm going to incorporate your suggestion.

> Thanks,
> --David
>
>
>> -----Original Message-----
>> From: RUELLAN Herve [mailto:[email-masked]]
>> Sent: Tuesday, January 20, 2015 1:49 PM
>> To: Martin Thomson; Black, David
>> Cc: [email-masked]; General Area Review Team ([email-masked]);
>> [email-masked]; [email-masked]
>> Subject: RE: [Gen-art] Gen-ART and OPS-Dir review of draft-ietf-httpbis-
>> header-compression-10
>>
>>> Cc: [email-masked]; RUELLAN Herve; General Area Review Team (gen-
>> [email-masked]); [email-masked]; [email-masked]
>> I think that this paragraph is too implementation oriented. In particular, the
>> "cached" is implementation-dependent. I propose changing it to:
>>

---

From: Hervé Ruellan <[email-masked]>
Date: Thu, 22 Jan 2015 18:55:34 +0100

Jari,

On 01/22/2015 01:22 PM, Jari Arkko wrote:
> I am sympathetic to David’s point here, although it is not necessarily clear
> to me that such information needs to be a part of this specific draft; it could
> be defined elsewhere as well.
>
> For what it is worth, I’m doing a review of this document along with Gen-ART
> review comments, and I think where I have ended up is that the above issue
> is a Comment from my perspective (and not a blocking Discuss).
>
> But I’d like to hear some feedback on this point though, or has that
> discussion already happened in the WG in the past? Also, for my
> education, are the standardised header fields that would clearly end
> up on the list, if it existed, or is this only for other
> or future header fields?

To complement my previous response to David, I think that there are no 
existing header fields that would clearly end up on the list. Some of 
them are good candidates for using the "never indexed literals" 
mechanism, but it mostly depends on how they are used. As Martin 
reported from Firefox implementation, a short cookie should probably be 
protected by this mechanism. But it's a rule of thumb: this cookie could 
convey some uninteresting data or your badly encrypted bank password.

Hervé.

> Jari

---

From: Martin Thomson <[email-masked]>
Date: Thu, 22 Jan 2015 18:12:26 -0800

I definitely want to avoid making prescriptive statements about what to
protect, even couched as suggestions. However, I think that a more generic
statement that describes the characteristics of a header that might need
protection is definitely a good idea.

If Herve doesn't get there first, I can purpose text that concentrates on
the coincidence of secret and small/easy-to-guess..
On Jan 22, 2015 3:17 PM, "Jari Arkko" <[email-masked]> wrote:

> Thanks for the response. I think this may slightly enhance the feeling
> that the list may not be needed.
>
> Jari
>
>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 23 Jan 2015 12:21:25 +0000

> the coincidence of secret and small/easy-to-guess..

Yep, that'd be a good addition I'd say, so long as you
couch those characteristics as being the ones we know
about today that contraindicate compression. Who knows
what new attacks folks might find in future now that
attention has been drawn to this.

Cheers,
S.

---

From: Hervé Ruellan <[email-masked]>
Date: Fri, 23 Jan 2015 16:25:18 +0100

> attention has been drawn to this.

I made a proposal at https://github.com/http2/http2-spec/pull/704

Hervé.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 23 Jan 2015 15:45:18 +0000

On 23/01/15 15:35, Jari Arkko wrote:
> 
>> I made a proposal at
>> https://github.com/http2/http2-spec/pull/704
> 
> Looked reasonable to me.

Me too. Quibbling, I'd suggest:

OLD:

 The decision on whether a header field is sensitive or
 not is highly dependent on the context. As a generic
 guidance, header fields used for conveying highly valued
 information, such as the Authorization or Cookie header
 fields, can be considered to be on the more sensitive
 side. In addition, a header field with a short value
 has potentially a smaller entropy and can be more at
 risk.

NEW:

 The decision on whether a header field is ok to
 compress or
 not is highly dependent on the context. As a generic
 guidance, header fields used for conveying highly valued
 information, such as the Authorization or Cookie header
 fields, can be considered to be on the more sensitive
 side. In addition, a header field with a short value
 has potentially a smaller entropy and can be more at
 risk. We know that compressing low-entropy sensitive
 header fields can create vulnerabilities so such
 cases are most likely the ones to not compress today.
 Note though that the criteria to apply here may evolve
 over time as we gain knowledge of new attacks.

Cheers,
S.

> jari

---

From: Roberto Peon <[email-masked]>
Date: Fri, 23 Jan 2015 09:59:24 -0800

What Herve had so far LGTM.
I think we should also have some blurb in there about the
3rd-party-request-origin stuff, since it isn't the most obvious attack
vector.
As a reminder, this attack is:
Allow the client to successfully create a connection and send a request
which should populate a secret.
Now, with the intercepting agent, kill any packets sent to the client from
the server, but send acks to the client, observing sizes of the packets the
client is sending.
The 3rd party site to which the client is connected (which is colluding
with the intercepting agent) then instructs the client to make many
requests (until the flow control window is exhausted) to test its many
hypothesis, none of which are visible to the server.

Using the never-index bit when a request is originates with a 3rd party
helps to mitigate this in many cases, and some mention of this use-case
would be useful, I suspect.
-=R

On Fri, Jan 23, 2015 at 8:51 AM, Black, David <[email-masked]> wrote:

> This sort of guidance will definitely be a useful addition.   A little
> more wordsmithing on Stephen's proposed text follows:
>
> OLD
>   We know that compressing low-entropy sensitive
> NEW
>   We currently know that compressing low-entropy sensitive
>   header fields can create vulnerabilities so compression
>   of such fields ought to be avoided.
>   This guidance may evolve
> > From: Stephen Farrell [mailto:[email-masked]]
> > Sent: Friday, January 23, 2015 10:45 AM
> > To: Jari Arkko; Hervé Ruellan
> > Cc: Martin Thomson; Black, David; [email-masked]; General Area Review
> Team
> > ([email-masked]); [email-masked]; [email-masked]
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> >
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1
> >
> > iQEcBAEBAgAGBQJUwmyOAAoJEC88hzaAX42iJKkIAJtbLdBsQe12+yyg47yupU9x
> > xbJJ8WZj7vN9Owc9DbzPUczcejjxPUETWwiJ4gzGEnqOTgkH4Ljbt3DnZO1OrdwL
> > J5sdie+/x85WuimEgz8GLeOvHe3vyKAJzRIGuX4c4PFgxQ2EBQTJwMM9/qBx9Wp4
> > gLNSMmvd0DT8mfozQokju4H4SsxEgFWIERpDO1Has/3ska0u0qhCrJgIdSSWWn08
> > yvsjoPDfp+SPEJOa+vWoWqP971QXaGsm5lnhPDLTJ+u06cWpzeQerOEmS3dMYX4A
> > 0gcR73olUgS9gqVQ/HIYDKLxsOX3DXH0QSJhHOgYrE6GNPUX2bz7npN0PP7+x0s=
> > =Txbn
> > -----END PGP SIGNATURE-----
>

---

From: Hervé Ruellan <[email-masked]>
Date: Mon, 26 Jan 2015 18:29:19 +0100

I tried to integrate all these comments, as well as those of Martin on 
GitHub into: https://github.com/http2/http2-spec/pull/704

Hervé.

On 01/23/2015 05:51 PM, Black, David wrote:
>> Cc: Martin Thomson; Black, David; [email-masked]; General Area Review Team

---

From: Hervé Ruellan <[email-masked]>
Date: Mon, 26 Jan 2015 18:31:55 +0100

Roberto,

Section 7.1.2 Mitigation has already some text about 3rd parties. Do you 
find it sufficient, or would you prefer having a new paragraph in 7.1.3 
saying that an encoder might choose to use the never-index bit for 3rd 
party header fields?

Hervé.

On 01/23/2015 06:59 PM, Roberto Peon wrote:
> Now, with the intercepting agent, kill any packets sent to the client
> from the server, but send acks to the client, observing sizes of the
> packets the client is sending.
> On Fri, Jan 23, 2015 at 8:51 AM, Black, David <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     > From: Stephen Farrell [mailto:[email-masked] <mailto:[email-masked]>]
>     > Cc: Martin Thomson; Black, David;[email-masked] <mailto:[email-masked]>; General Area Review Team
>     > ([email-masked] <mailto:[email-masked]>); [email-masked]
>     <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>

---

From: Roberto Peon <[email-masked]>
Date: Mon, 26 Jan 2015 13:49:21 -0800

s/decided/decide/

I'm sure it can be further massaged before it is document ready
-=R

On Mon, Jan 26, 2015 at 1:48 PM, Roberto Peon <[email-masked]> wrote:

> Herve--
> I'm not sure that the text in 7.1.2 is explicit enough to be understood--
> I'd be hard-pressed to define "guess" reliably. The bit that is missing,
> imho, is that the provenance of the request is from a 3rd party, which is
> reason to be suspicious.
>
> An alternate wording:
> An encoder seeing many 3rd party requests which contain keys whose values
> never match may decided to ensure that such keys are never indexed when
> going to that site, as this effectively prevents probing of the compression
> context, and, if not malicious, would likely offer no benefit from indexing
> anyway.
>
> -=R
>
>
>
> On Mon, Jan 26, 2015 at 9:29 AM, Hervé Ruellan <[email-masked]
> > wrote:
>

---

From: Roberto Peon <[email-masked]>
Date: Mon, 26 Jan 2015 13:48:44 -0800

Herve--

An alternate wording:

-=R