Re: [Masque] Encrypting between client and proxy

On Tue, Nov 15, 2022 at 8:57 PM Ben Schwartz <bemasc=
40google.com@dmarc.ietf.org> wrote:

> On Tue, Nov 15, 2022 at 6:44 PM Martin Thomson <mt@lowentropy.net> wrote:
> ...
>
>> The protected payload is high entropy, being comprised of ciphertext and
>> is anywhere from 20 to 65506 bytes.  This payload can be split into two,
>> with a 12 byte sample being used as a nonce for AES-CTR.  The remainder of
>> the payload, plus part of the first byte, could then be protecting using
>> AES-CTR.  The remaining 8+ bytes could again be sampled again as a nonce to
>> protect the first sample.
>>
>
> The thing you are looking for is called a Pseudo-Random Permutation [1].
> I would encourage you to use HCTR2 [2].  (I learned a bit about these while
> working on [3].)
>
> [1] https://en.wikipedia.org/wiki/Pseudorandom_permutation
> [2] https://github.com/google/hctr2
> [3] https://datatracker.ietf.org/doc/draft-cpbs-pseudorandom-ctls/
>
> ...
>
>> [1] A few people have noted that timing tends to be a dead giveaway here,
>> as does packet size.  I have some ideas about how that might be managed,
>> but let's start with the basics.
>>
> I think enough of our threat model has to consider side-channels like
packet size as out of scope (although I believe we do have the opportunity
to add chaff to less-than-MTU packets); we can certainly do something about
timing analysis. I would expect most interesting deployments of such a
proxy to be very high throughput which would mean some amount of artificial
queuing and mixing would go a long way towards increasing the search space
for correlation.

>
> Personally, I think this is probably fatal, so the encryption is not
> really buying you anything.   However, I would still support adding
> encryption here, at least optionally, for the sake of making the attacker's
> job a bit harder.  It's not the easiest thing to specify in a threat model,
> but there is a real difference between "instant undeniable confirmation"
> and "strong statistical inference" for an attacker.
>
I am similarly in favor of trying to protect the packet further, but my
understanding from the presentation at the session was that a lot of the
CPU wins came from NIC offloads. If we end up hitting the host CPU to do
the decryption, we should compare the implementation to the full
CONNECT-UDP tunneling mode and see if it's worthwhile.

>
> ...
> --
> Masque mailing list
> Masque@ietf.org
> https://www.ietf.org/mailman/listinfo/masque
>