Re: [Pearg] IRTF Chair review of draft-irtf-pearg-censorship-06

[Colin Perkins <[e-mail]>]

Hi Mallory,


On 15 Dec 2022, at 17:40, Mallory Knodel wrote:

> Hi Colin and all,
>
> I made some changes in the new version thusly:
>
> On 12/2/22 12:29 PM, Colin Perkins wrote:
>> RFC 5743 compliance: The draft does not follow the guidelines in RFC 5743
> Fixed.

Thanks - but I think a little more is needed. The draft doesn’t state the breadth of review undertaken by the RG, and doesn’t include an explicit statement that the draft is not an IETF product and is not a standard.

>> There are two places where specific censorship products are mentioned, along with citations of their use (SmartFilter in §3 and §4.2.1, NetSweeper in §4.2.1). Given that the set of such products changes over time, and is likely to become rapidly obsolete, I wonder if the draft might better just list the classes of products and leave the specifics to the cited sources?
> Agree-- and since those sections included enough description of those technologies it was easy to remove them. However I did have to change the citation for NarusInsight because the former citation (directly to the EFF blog post about the AT&T lawsuit) didn't mention it. I use the Wikipedia article about the lawsuit instead, which gives a better overview of the techniques in question.

This is good, thanks.

>> §4.2.3: “Note that TLS 1.3 acts as a security component of QUIC” – do the differences in the way TLS integrates with QUIC affect censorship as described in this draft?
>
> My interpretation of the intention of this sentence is to point out that various parts of TLS 1.3 are used for blocking, but that each of these parts then can be used to block QUIC in the same way. So rather than having a QUIC subsection, they are combined. I checked the subsequent sections and have confirmed that the subsections where relevant indicate where QUIC can be blocked or where QUIC cannot be blocked with the same method given that it is, still, different from TLS.

I was asking a slightly different question that was maybe not well phrased.

TLS when used over TCP formats the TLS handshake in a particular way onto the TCP connection and exposes certain information in the clear (the SNI, for example). QUIC does this differently, sending the TLS handshake in CRYPTO frames as part of Initial packets that have some limited protection applied to them. Do these differences change the information that’s exposed in a way that affects the censorship described in this draft?

> Additional note! Another major change that I should note here is that I've now added some text throughout about image hash matching. Essentially anywhere keyword or URL blocklist is mentioned in a way that is adjacent to content filtering, I felt it appropriate to note the way that images and videos can also be detected and actioned with removal. The very brief text is cited to an excellent description of Apple's proposed NeuralHash scheme written up by ekr, and can be found under 3.0. Technical prescription and 4.2.4. Instrumenting Content Distributors.

These changes are fine with me, provided the RG agrees.

Colin