Re: [Masque] Design team PR for QUIC-aware forwarding

[Antoine FRESSANCOURT <[e-mail]>]

Hello,

We discussed padding quite a lot during the design team's work. One of the reasons why padding was not explicitly added in the forwarded mode of operation is that padding alone is not enough to mitigate elaborated deanonymization attacks, in which packet timing patterns are a strong enough signal to correlate ingoing and outgoing flows while looking at a given proxy. Besides, we discussed the method used to pad, and either a completely naïve padding strategy seemed to be a waste of resources (i.e. padding every packet to the MTU) or seemed complex to implement (i.e. padding to match a given traffic pattern). 

Note that padding is not explicitly ruled out, and personally I think padding is an essential element in protecting privacy with QUIC. In the proposed draft changes, there is room to define other scrambling protocols than the one that is currently presented, and I think this is where more elaborated proposals including padding or packet timing might be presented and studied.

In the hope that I didn't describe the design team's intentions wrong,

Antoine

-----Original Message-----
From: Masque <[e-mail]> On Behalf Of Martin Thomson
Sent: vendredi 26 janvier 2024 04:10
To: David Schinazi <[e-mail]>; Tommy Pauly <tpauly=[e-mail]>
Cc: MASQUE <[e-mail]>
Subject: Re: [Masque] Design team PR for QUIC-aware forwarding

So you don't scramble the first byte and you don't pad.

You know... there is a way to achieve both with minimal additional complexity and no additional overhead aside from any added padding:

If you encrypt the first byte, you can also use 0x80 to signal whether padding is present.  Then you can use a zero pad sequence terminated by a non-zero byte at either end of the packet (suggestion: the end).

On Fri, Jan 26, 2024, at 12:13, David Schinazi wrote:
> Thanks Tommy!
>
> In case it's helpful to others, here's a rendered diff between this 
> branch and main:
> https://author-tools.ietf.org/diff?url_1=https://ietf-wg-masque.github
> .io/draft-ietf-masque-quic-proxy/draft-ietf-masque-quic-proxy.txt&url_
> 2=https://ietf-wg-masque.github.io/draft-ietf-masque-quic-proxy/design
> -team/draft-ietf-masque-quic-proxy.txt
>
> David
>
> On Thu, Jan 25, 2024 at 2:23 PM Tommy Pauly 
> <tpauly=[e-mail]> wrote:
>> Hi MASQUErs,
>> 
>> On behalf of the design team for draft-ietf-masque-quic-proxy that was tasked on adding a proposal to add encryption on the forwarding path, I’d like to share the pull request to the document that represents the proposal of the team. This is largely what was presented at the last IETF meeting, adding support for negotiating protocol transforms, and defining the “scramble” transform.
>> 
>> Here is the PR against the base document: 
>> https://github.com/ietf-wg-masque/draft-ietf-masque-quic-proxy/pull/9
>> 9 Here is the rendered version: 
>> https://ietf-wg-masque.github.io/draft-ietf-masque-quic-proxy/design-
>> team/draft-ietf-masque-quic-proxy.html
>> 
>> Please take a look and feel free to add comments to the PR or the mailing list!
>> 
>> Thanks,
>> Tommy (& David, Ben, Eric, Mirja, Antoine, & Tiru)
>> --
>> Masque mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/masque
> --
> Masque mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/masque

--
Masque mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/masque