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

[Ben Schwartz <[e-mail]>]

We do scramble the first byte.  We don't scramble the first bit​.

Keeping the 0x80 bit set to zero on the wire seems pretty important.  Otherwise, the proxy has no reliable way to distinguish scrambled packets from Long Header packets, with which they share a port.  Maybe it could use trial decryption with the Initial Keys, but that seems wasteful (and is not a QUIC Invariant).

An alternative would be to steal the Fixed Bit (0x40) for this purpose, but that bit is only fixed in QUICv1.

Regardless, as Antoine said, padding in Forwarded Mode is such an extremely weak defense that I don't think it's worth pursuing [1].  I would be happy to work with anyone who's interesting in trying to design an HTTP transport that offers a real defense against traffic analysis, but I think Forwarded Mode would not be the starting point.

--Ben Schwartz

[1] https://github.com/ietf-wg-masque/draft-ietf-masque-quic-proxy/issues/92#issuecomment-1875677434


________________________________
From: Masque <[e-mail]> on behalf of Martin Thomson <[e-mail]>
Sent: Thursday, January 25, 2024 10:09 PM
To: David Schinazi <[e-mail]>; Tommy Pauly <tpauly=[e-mail]>
Cc: MASQUE <[e-mail]>
Subject: Re: [Masque] Design team PR for QUIC-aware forwarding

!-------------------------------------------------------------------|
  This Message Is From an External Sender

|-------------------------------------------------------------------!

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/99
>> 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