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

[Eric Rescorla <[e-mail]>]

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