Subject: [hrpc] Review of draft-hall-censorship-tech-04

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 24 Jul 2016 21:40:06 +0200

Summary: I really would like to see this document published (and
quickly because it contains information which will become obsolete)
becasue it is really useful but, IMHO, there are still a few problems
to solve.

I copy the HRPC research group because the draft, unlike many drafts,
does not indicate a discussion venue. HRPC ? A security area mailing
list?

One of your TODOs:

"talk about content inference through things like TLS
fingerprinting?)" Probably yes, otherwise people may get the
impression that encryption hides perfectly everything. I would add,
after 3.2.5, a section "Identification with metadata" with something
like:

"A lot of information, leading to identification of something to
censor, can be deduced from metadata, such as the size of the
exchanged packets. TLS does nothing by default to hide this size and
it has been demonstrated it is exploitable (reference: "Peek-a-Boo, I
Still See You: Why Efficient Traffic Analysis Countermeasures Fail" by
Kevin P. Dyer, Scott E. Coull, Thomas Ristenpart, Thomas Shrimpton
<http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumber=6234422>).

Encryption alone does not work against this sort of inferences. There
are several additional ways to make inference more difficult, but they
are not obvious to use properly. One such way is padding, adding
gratuitous data (see for instance RFC 7830)."

Another one:

"organize this section into layers just like identification above.
Alternatively, the whole document can be organized in a layer
structure and do identification and interference at the same time for
each layer?  That seems wise.)" May be but it is a lot of work and I
would prefer to see the RFC published. Because it contains a lot of
information that could become outdated in a few years, a version -2
could be made afterwards, with updated content and this
reorganisation.

Technical :

3.2.1 "an HTTP method field is necessary to do anything useful" I
don't understand. AFAIK, you cannot send a HTTP request without
indicating a method (RFC 7230, section 3.1.1).

4.3 "Sequence number is the hardest to get correct" RFC 5961 should be
mentioned, since it describes the solutions to make it harder for the
attacker to guest, thus preventing RST injection.

4.4 As I said (this is noted in the draft), the term "cache poisoning"
has a very specific meaning for the DNS. The reference given
<http://viewdns.info/research/dns-cache-poisoning-in-the-peoples-republic-of-china/>
describes something which exists but is not a cache poisoning at all
(no cache is involved and the example is specially wrong because it
clearly says the cache has the correct information). Yes, for the
user, it is the same result in the end but, in a IETF document, we
must certainly be precise.

Cache poisoning could be done for censorship but, as I said, I'm not
aware of documented cases.

Editorial :

s/operator of a resursive resolver/operator of a recursive resolver/

s/Bortzmayer/Bortzmeyer/g

s/Boarder Gateway Protocol/Border Gateway Protocol/

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Mon, 25 Jul 2016 13:13:03 +0200

(I'm on vacation this week, but will turn to edits quickly when I return.)

On Sunday, July 24, 2016, Stephane Bortzmeyer <[email-masked]> wrote:

> <
> http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumber=6234422
> >).
>
> <
> http://viewdns.info/research/dns-cache-poisoning-in-the-peoples-republic-of-china/
> >
> _______________________________________________
> hrpc mailing list
> [email-masked] <javascript:;>
> https://www.irtf.org/mailman/listinfo/hrpc
>

-- 
Joseph Lorenzo Hall
Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
1401 K ST NW STE 200, Washington DC 20005-3497
e: [email-masked], p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871