Re: [quicwg/base-drafts] Packet number encryption (#1079)

[Christian Huitema <[e-mail]>]

On 4/18/2018 9:22 AM, ekr wrote:

> On Tue, Apr 17, 2018 at 7:13 AM, Antoine Delignat-Lavaud <
> [e-mail]> wrote:
>
> > We have been discussing this PR at Microsoft with Cedric Fournet and
> Nick
> > Banks and have some comments on the current proposal:
> >
> > 1.
> >
> > As pointed out in the other reviews of this PR, there is a lot of
> > ambiguity regarding whether the packet number length is or isn’t
> encrypted.
> > In the current PR, the formula to compute the sample_offset only makes
> > sense if the packet number is a “varint”. However, the proposed
> change does
> > not alter the short packet header, and the PN length is indicated by the
> > last 3 bits of the flags byte, and restricted to be one of 8, 16, or 32
> > bits. Under this assumption, the sample_offset can be redefined as the
> > length of the packet header - we think it is reasonable to keep the PN
> > length public, and avoid having a fuzzy limit between packet header and
> > contents, which could be a source of side channels in the processing
> of the
> > packet after PN decryption, in particular considering point 2 below.
> > 2.
> >
> > Given that packet numbers in short packets are only a few bytes and
> > get encrypted without authentication, they are extremely vulnerable to
> > malleability, and using a XOR mask encryption (such as CTR mode or
> ChaCha20
> > keystream) compounds the problem even further, because an adversary can
> > selectively flip the few bits of interests for him (the low weight
> ones) to
> > find out using side channels what position the reader is at in the
> stream
> > (as discussed in the PR comments). We are concerned that some
> > implementations may try to perform optimizations based on the
> decrypted PN
> > without first first decrypting the packet (for instance, an
> implementation
> > may chose not to decrypt the packet if the decrypted SN has been
> acked, or
> > above some threshold). Any such optimization is a side channel that
> can be
> > extremely efficiently used to recover the PN. We think it is a
> weakness of
> > the PN encryption scheme to allow implementations to fall into this
> trap.
> > Using a 32-bit permutation cipher rather than AES-CTR or ChaCha20 would
> > make such attacks less effective. A cipher such as Speck with 32 bit
> blocks
> > could be well suited for this purpose, and also much faster.
> >
> >
> Note that if we're willing to bake in a permutation, we can just go
> back to
> Kazuho's original proposal of AES-ECBing the PN + <X bytes of ciphertext>
> in place.

I am not sure that I understand Cedric's proposal to use Speck. Would
that be a variant of #1079 in which the only change is the use of a
block cipher like Speck instead of a stream cipher like AES-CTR?

Clearly, using a block cipher with exactly the same length as the PN
will have some advantages in term of implementation. But it is not a
straight win:

* Malleability is still there. Since the permutation only affects the
low bits of the sequence number, there are still reasonable chances that
decrypting a random number results in an acceptable sequence number. The
risk goes down from 100% with a stream cipher to at most 50% with a
permutation cipher.

* The current proposal has baked-in crypto agility, because it uses the
same stream cipher for content encryption and for PN encryption, and
thus negotiates it at the same time. We would need to specify which
permutation cipher is associated with each of the content encryption
methods. AES-ECB is indeed an option when using AES for content, but
what about ChaCha20?

* As for the AES-ECB proposal, the effect on hardware acceleration is
probably even more drastic than the current design, since some bits
would have to be decrypted twice.

Cedric is "concerned that some implementations may try to perform
optimizations based on the decrypted PN without first first decrypting
the packet", and that would provide a "side channel that can be
extremely efficiently used to recover the PN". But then, what he
describes is not just an optimization. It is a standard defense against
denial of service attacks, filtering out implausible sequence numbers
and avoiding the CPU cost of decrypting the forged packets. I am not
sure about the trade-off there, between "maybe helping recover the PN"
and "further exposure to DOS".

-- Christian Huitema



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1079#issuecomment-382459179