Re: [Pearg] I-D Action: draft-irtf-pearg-censorship-04.txt

[Joseph Lorenzo Hall <[e-mail]>]

Heya, I’ve placed your feedback below in the following github issue in our repository for tracking:

https://github.com/IRTF-PEARG/rfc-censorship-tech/issues/82

Comments inline.

On Jul 21, 2020, at 11:21 AM, Stephane Bortzmeyer <[e-mail]<mailto:[e-mail]>> wrote:

On Mon, Jul 13, 2020 at 06:51:19PM +0000,
Joseph Lorenzo Hall <[e-mail]<mailto:[e-mail]>> wrote
a message of 238 lines which said:

       Title           : A Survey of Worldwide Censorship Techniques
       Filename        : draft-irtf-pearg-censorship-04.txt

A general issue with drafts dealing with current techniques is that it
is hard to stay up-to-date (a reason to publish rapidly).

For instance:

For example, a censor could block the default HTTPS port, port 443,
thereby forcing most users to fall back to HTTP.

Is it still true today? With HSTS (RFC 6797) and many Web sites
redirecting unconditionnaly from http: to https: I wonder if it could
still be used.


I suspect it depends on where you are; certainly I believe it is still the case that Iranian networks throttle or block 443 for exactly this purpose (there is a reference in the draft to this). If there is data showing this would be highly unlikely most places, happy to change.

Also:

When in-window sequencing is allowed, it is trivial to conduct a
Blind RST Injection:

Trivial may be too strong, if RFC 5961 is used. Referring to RFC 5961,
section 5.1 may be a good idea (the draft mentions a fixed number of
possible windows, which does not seem true).


Would you recommend “it is possible”? And to what extent do we know that people implement what RFC 5961 describes?

while the term "blind" injection implies the censor doesn't know any
sensitive (encrypted)

? "blind" refers to being off-path, it has nothing to do with
encryption.


Good point, will drop the parenthetical.

authoritative resolvers

There is no such thing as an authoritative resolver. Either it is a
resolver, or it is an authoritative name server. (Source: RFC 8499,
section 6)


Ah yes, will change that.

Editorial:

This in-window recommendation is important, as if it is implemented
it allows for successful Blind RST Injection attacks [Netsec-2011].

Not clear.

Due to the RFC 5961 comment above? Do you want us to put in a “(Note that if [a network? a server?] implements the protections against blind TCP injections in RFC 5961 [it is much harder to accomplish]” or something?


[Bortzmayer-2015]
            Bortzmayer, S., "DNS Censorship (DNS Lies) As Seen By RIPE
            Atlas", 2015,

It's Bortzmeyer :-)

Dang, very sorry about that! Will change.


[Zmijewski-2014]
            Zmijewski, E., "Turkish Internet Censorship Takes a New
            Turn", 2014, <http://www.renesys.com/2014/03/turkish-
            internet-censorship/>.

Moved (without a redirect) with all the Renesys content, after being
bought by Oracle. It is now
<https://blogs.oracle.com/internetintelligence/turkish-internet-censorship-takes-a-new-turn>

Thanks, I’ll update this and the others you noted.

best and thank you, Joe

--
Joseph Lorenzo Hall, Senior Vice President, Strong Internet
[e-mail]<mailto:[e-mail]> | [phone]
internetsociety.org<http://internetsociety.org> | @internetsociety
pgp: https://josephhall.org/gpg-key
3CA28D7B9F6DDBD34B1016075F86698740A9A871