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

[Colin Perkins <[e-mail]>]

Okay – thanks Ekr!

Colin



On 18 Dec 2022, at 0:54, Eric Rescorla wrote:

> On Sat, Dec 17, 2022 at 12:03 PM Colin Perkins <[e-mail]> 
> wrote:
>
>> 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?
>>
>
> I don't believe it meaningfully does. Although it is encrypted, it 
> uses a
> deterministic key that can be computed from the data in the packet. 
> You
> really need ECH if you want to conceal this information.
>
> -Ekr