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

From: Martin Thomson <[email-masked]>
Date: Wed, 04 Apr 2018 06:02:24 +0000 (UTC)

@martinthomson pushed 1 commit.

922234f  merge master in rather than rebase

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1079/files/3386bf7cf304ec5e5e447c71a8ace929091016e2..922234ffba4239797b6b7da576a25e200920ac38

---

From: Martin Thomson <[email-masked]>
Date: Wed, 04 Apr 2018 06:09:43 +0000 (UTC)

d7cd4ad  Revert unnecessary change

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1079/files/922234ffba4239797b6b7da576a25e200920ac38..d7cd4ad0edca509859278da69b106521401a6a93

---

From: MikkelFJ <[email-masked]>
Date: Mon, 09 Apr 2018 15:55:38 -0700

If we assume packet numbers are variable length and the PNE scheme is modified to attach the PN at the end as I proposed earlier, then the following extension could handle the length encoding AND provide a fast sanity check of packet validity.

Given the cleartext PN in a 32-bit word (assuming we never encode more than that), the length is given as a 2 bit number. This length can be stored in the last octet of the packet, after the encrypted PN. The remaining 6 bits are used as follows:

C std lib has fast low quality PRNG:

int rand() {
  return (((holdrand = holdrand * 214013L + 2531011L) >> 16) & 0x7fff);
}
we modify this algorithm to

PN_checksum = (((PN * 214013L + 2531011L) >> 22) & 0xfc) | (PN_len - 1)
where PN_len is length in 1 to 4 octets.

The exact details may vary, but the point is a single fast 32-bit multiplication.

The length of the packet number can now be immediately decoded from the tail octet.
The packet number checksum can be verified immediately after decrypting the packet number.
If it fails there is roughly (and biased) a 1 / 64 chance that a packet with random content will have matching PN checksum. This can weed out trial decryption of the entire packet very fast. This in turn, can be used as a fast packet filter - even without having the full traffic key but just the less sensitive PN key.

Note that exposing the PN length can contribute to connection linkage since it says something about the connection data volume or age.

Also note that a fast packet rejection can be used with a timing attack to conclude whether a packet number is likely valid - this must be balanced against DoS risk.

-- 
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-379919079

---

From: Mike Bishop <[email-masked]>
Date: Sun, 15 Apr 2018 16:52:46 +0000 (UTC)

MikeBishop commented on this pull request.

> @@ -908,6 +918,80 @@ the connection that is hosted on stream 0.  This sequence number is not visible
 to QUIC.

+## Packet Number Protection {#pn-encrypt}
+
+QUIC packets are protected using a key that is derived from the current set of
+secrets.  The key derived using the "pn" label is used to protect the packet
+number from casual observation.  The packet number protection algorithm depends
+on the negotiated AEAD.
+
+Packet number protection is applied after packet protection is applied (see
+{{aead}}).  The ciphertext of the packet is sampled and used as input to an
+encryption algorithm.
+
+For packets with a long header, the ciphertext starting
+immediately after the packet number is used (that is, octet 17 onwards).

Immediately after the packet number is now the payload length; this needs to be updated.

-- 
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#pullrequestreview-112244292

---

From: MikkelFJ <[email-masked]>
Date: Mon, 16 Apr 2018 10:24:08 -0700

@MikeBishop asked me to clarify placement of PN in my proprosed modification:

To to simplify the dicussion I have mostly, but not exclusively referred to placing PN last since that is simpler in software, but it is a concern for HW streaming. Pleacing it first also has some issues with invariants.

The PN can be placed anywhere as long as it is not included in neither Authenticated data and Encrypted data. Specifically, it can be placed in-between the two, just about where it is today, give or take.

By excluding PN from AEAD but keeping it roughly where it is, encryption happens by xor'ing as the current proposal. Decryption can happen without modifying the packet buffer because decrypted PN is not needed to verify or decrypt content, only to seed the IV.

Placing PN early does require modfying the packet buffer, but so does the packet length.

-- 
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-381682788

---

From: Antoine Delignat-Lavaud <[email-masked]>
Date: Tue, 17 Apr 2018 07:13:41 -0700

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.

3.	The current design for PN encryption is trying to avoid opening the AEAD abstraction used for the packet content encryption (at the cost of doing a brittle, custom construction on top of it). It is also inefficient (because it needs to expand 2 separate keys) and non-uniform (as it uses CTR with block ciphers, but stream ciphers directly). It is possible to do a much more efficient construction by opening the AEAD “box”, and extending it to something akin to “authenticated stream of unreliable encrypted data with authentication”, and use the same key to encrypt the packet headers and contents. This is a straightforward extension of AEAD – inside the AEAD construction, the cipher function is used as a PRF with a special value in its domain to compute the mask (i.e. constant coefficient) of the Wegman-Carter-Shoup polynomial MAC. It is possible to refine this domain to also use the PRF to generate a packet number encryption mask. For instance, in AES-GCM, the PRF is AES(IV||counter) with the special counter value of 0 being used for the MAC. Since packets are much smaller than 2^28 bytes it is possible to use AES(IV||0xFF||X) as a disjoint PRF to generate packet number encryption tags. For instance, AES(IV||0xFF||header_flags||sample) would work well for this purpose. (The reason the QUIC header flags byte is included is because it determines the length of the packet number, and this implicitly authenticates it.) Note that even hardware implementations of AES-GCM would be capable of computing this, as it would be computed for some extremely long plaintext with a block counter of 0xFF||header_flags||sample – however, this is not typically part of the interface of AEAD implementations. The cryptographic argument that justifies the safety of this extended construction is the same as for the masking of the WCS tag – separation of the PRF domain.

-- 
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-382007477

---

From: ekr <[email-masked]>
Date: Wed, 18 Apr 2018 16:22:12 +0000 (UTC)

On Tue, Apr 17, 2018 at 7:13 AM, Antoine Delignat-Lavaud <
[email-masked]> 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.

-- 
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-382445631

---

From: Christian Huitema <[email-masked]>
Date: Wed, 18 Apr 2018 10:06:24 -0700

> Kazuho's original proposal of AES-ECBing the PN + <X bytes of ciphertext>

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

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 19 Apr 2018 02:58:52 +0000 (UTC)

@ad-l 
> 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). 

Personally, I have no objection against forbidding the "use" of PN before decrypting the payload, considering the fact that decryption (when done in multi-core, with special CPU instructions) is much faster than the wire speed.

As a side note, in "explicit nonce" approach being discussed in https://github.com/quicwg/base-drafts/wiki/Summary-of-the-PN-encryption-issues-and-alternatives it is impossible to use PN before decrypting the payload.

@huitema 
> 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.

That could be true, though it is hard to estimate what could be done in the hardware that exist today and in the future.

OTOH, the positive side of the AES-ECB approach compared to short block cipher alternatives is that it does not require rekey for every 2<sup>N</sup> packets, where _N_ is the number of bits used express the PN on wire.

-- 
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-382594350

---

From: Christian Huitema <[email-masked]>
Date: Thu, 19 Apr 2018 03:45:05 +0000 (UTC)

On 4/18/2018 7:58 PM, Kazuho Oku wrote:

> OTOH, the positive side of the AES-ECB approach compared to short
> block cipher alternatives is that it does not require rekey for every
> 2^N packets, where /N/ is the number of bits used express the PN on wire.

Yes, AES-ECB on 4 PN bytes + 12 encrypted bytes is in practice as robust
as AES-CTR on 4 PN bytes with 16 encrypted bytes used as nonce. But it
is not more robust. The only advantage is non-malleability. And the
downside is that it is a bit harder to do in hardware.

-- 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-382601172

---

From: Antoine Delignat-Lavaud <[email-masked]>
Date: Thu, 19 Apr 2018 09:57:39 +0000 (UTC)

While I agree that @huitema's proposal of using ECB is an improvement in term of malleability, I don't agree with @kazuho's belief that a requirement not to do any processing between decrypting the PN and decrypting the packet contents will be followed. Without PN encryption, implementations have the option to discard packets without even decrypting them based on the PN. As @huitema observes, this can be somewhat useful to slightly mitigate brutal DoS attacks, such as spamming large random packets with randomized source addresses, or if connection IDs are short enough to be brute forced. Asking implementations to always perform the large AEAD decryption of the packet contents just to authenticate a PN that it knows cannot be valid is going to be very unappealing and it's very likely that "smart" implementations just won't bother with the check, considering that it only matters to maintain PN confidentiality which is very flimsy at best (the apparent order of packets essentially leaks most of this information anyway, so proving a formal statement about the security of PN encryption is going to be very though).

Because of these concerns, we too have some doubts about the security/performance trade-off of the current PN encryption proposal - it has a high performance cost but provides little useful security outside of the important multi-path unlinkability scenario. We see two approaches for improving the trade-off:
- either improve the efficiency and security of the PN encryption by extending the AEAD construction to provide a 2-step (PN decryption + full packet authentication) followed by optional packet content decryption, using the same key for both operations
- or, decide that the only scenario worth protecting is unlinkability across different connection ID, and use a non-cryptographically secure obfuscation of PN within the same connection ID. We think it is possible to do much better than the current gap system, by essentially deriving a random offset for each connection ID from the current QUIC secret and using the offset to mask the packet header PN. I believe the WinQuic team plans to submit a proposal along these lines.

-- 
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-382679173

---

From: MikkelFJ <[email-masked]>
Date: Thu, 19 Apr 2018 03:59:02 -0700

In my comments to PR 1079 I suggested adding a small 6 bit checksum to the
packet number if adding a variable length field.
One could also always add an 8 bit checksum. It is not a strong proof, but
it does provide fast DoS rejection without assuming anything about valid
packet numbers before the packets AEAD tag has been verified.

This could be included in any PN encryption scheme and the cost is a single
32-bit multiplication.

Kind Regards,
Mikkel Fahnøe Jørgensen

On 19 April 2018 at 11.57.37, Antoine Delignat-Lavaud (
[email-masked]) wrote:

While I agree that @huitema <https://github.com/huitema>'s proposal of
using ECB is an improvement in term of malleability, I don't agree with
@kazuho <https://github.com/kazuho>'s belief that a requirement not to do
any processing between decrypting the PN and decrypting the packet contents
will be followed. Without PN encryption, implementations have the option to
discard packets without even decrypting them based on the PN. As @huitema
<https://github.com/huitema> observes, this can be somewhat useful to
slightly mitigate brutal DoS attacks, such as spamming large random packets
with randomized source addresses, or if connection IDs are short enough to
be brute forced. Asking implementations to always perform the large AEAD
decryption of the packet contents just to authenticate a PN that it knows
cannot be valid is going to be very unappealing and it's very likely that
"smart" implementations just won't bother with the check, considering that
it only matters to maintain PN confidentiality which is very flimsy at best
(the apparent order of packets essentially leaks most of this information
anyway, so proving a formal statement about the security of PN encryption
is going to be very though).

Because of these concerns, we too have some doubts about the
security/performance trade-off of the current PN encryption proposal - it
has a high performance cost but provides little useful security outside of
the important multi-path unlinkability scenario. We see two approaches for
improving the trade-off:

   - either improve the efficiency and security of the PN encryption by
   extending the AEAD construction to provide a 2-step (PN decryption + full
   packet authentication) followed by optional packet content decryption,
   using the same key for both operations
   - or, decide that the only scenario worth protecting is unlinkability
   across different connection ID, and use a non-cryptographically secure
   obfuscation of PN within the same connection ID. We think it is possible to
   do much better than the current gap system, by essentially deriving a
   random offset for each connection ID from the current QUIC secret and using
   the offset to mask the packet header PN. I believe the WinQuic team plans
   to submit a proposal along these lines.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<https://github.com/quicwg/base-drafts/pull/1079#issuecomment-382679173>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AALzNyxvd0Ssi-6s9aD2nYQNXZ8KsoJUks5tqF-QgaJpZM4RwGdT>
.

-- 
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-382694338

---

From: Nick Banks <[email-masked]>
Date: Thu, 19 Apr 2018 21:33:07 +0000 (UTC)

As @ad-l mentioned I was going to do, I just created a PR (#1307) to modify the existing packet number gap solution to provide a solution to the privacy/linkability problem. Separate from that, we can then solve the greasing/ossification problem with a different, non-cryptographic solution (shuffle for instance).

-- 
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-382887625

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 19 Apr 2018 21:01:28 -0700

@ad-l 
> either improve the efficiency and security of the PN encryption by extending the AEAD construction to provide a 2-step (PN decryption + full packet authentication) followed by optional packet content decryption, using the same key for both operations

Isn't the only difference being if you use a single secret or two secrets? To me it seems that even in such a construction you can still easily decrypt the PN without actually validating the tag of the packet.

Am I missing something?

-- 
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-382967776

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 20 Apr 2018 21:08:49 -0700

PS. aside from the fact that I do not understand why using the same secret solves the use-of-PN-without-verification issue, I think that it is a very good idea to use the same secret for PN encryption and payload encryption as you describe. I agree that it makes PNE more hardware-friendly while retaining crypto-agility.

-- 
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-383266139

---

From: MikkelFJ <[email-masked]>
Date: Fri, 20 Apr 2018 22:10:07 -0700

@kazuho As far as I can tell any PN scheme where you try to use the encrypted PN as IV cannot be both secret and short because it must be a permutation and a secure encryption would require repeating values based on a longer key. Anything shorter can be trivially brute forced. The question is if that bruteforce is sufficient since middleware won't have time to do it online.

As to the PN verification I believe you either have to check the entire AEAD packet, or add a short checksum. I suggest a short checksum because it can reject DoS attacks quickly and without access to the full traffic key.

In any case, privacy is not contained in any short AEAD independent scheme as it is too easy to crack, at least if you want encrypted PN as IV. Therefore the separate discussion of privacy without encryption / shuffle.

-- 
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-383268416

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 22 Apr 2018 19:38:44 -0700

@mikkelfj 
> As to the PN verification I believe you either have to check the entire AEAD packet, or add a short checksum.

Yeah. As far as I understand, any PNE scheme without accompanying checksum is fragile to side-channel attacks, because the probability of the receiver dropping the packet without decrypting the payload is proportional to the value of the decrypted PN field. An attacker that has access to side-channel information can use that information to guess the value of the PN field.

8-bit PN is fragile, because it is trivial to brute-force, regardless of the PNE scheme being used.

For 16-bit PN, an attacker can determine when the PN overflows by periodically injecting random packets and observing when the probability of early drops switches from almost 1 to almost 0.

For 32-bit (and longer) PN, it's becomes harder to use overflow as an attack vector. However, it would still be possible to use the probability of early drops to roughly estimate the PN.

> I suggest a short checksum because it can reject DoS attacks quickly and without access to the full traffic key.

The requirement for such a checksum would be that the checksum becomes available to the receiver at the same time the PN is decrypted. For block ciphers it is trivial to meet such a requirement. You can say that the PN field to be encrypted is constructed as a series of zero octets and the PN. The receiver will decrypt the encrypted PN field, and the checksum (i.e. will always be a series of zero octets) becomes available at the same moment the PN is decrypted. I am not sure if such a construct is available for a stream cipher.

-- 
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-383438404

---

From: MikkelFJ <[email-masked]>
Date: Mon, 23 Apr 2018 06:22:52 +0000 (UTC)

@kazuho 

I'm not sure what you mean by stream cipher on the PN contect? You cannot have the next PN depend on the previous due to packet loss.

As to a possible checksum - see my earlier comment in this PR - essentially any reasonable multiplication + shift could do:
https://github.com/quicwg/base-drafts/pull/1079#issuecomment-379919079

-- 
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-383467171

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 23 Apr 2018 08:00:36 +0000 (UTC)

@mikkelfj 
> I'm not sure what you mean by stream cipher in the PN context? You cannot have the next PN depend on the previous due to packet loss.

Because PN leak is a privacy concern, you need to guarantee that PN checksum is secure in cryptographical sense. Using several octets of a block cipher for the purpose (as explained in https://github.com/quicwg/base-drafts/pull/1079#issuecomment-383438404) is secure in sense that the probability of collision depends on the block cipher.

The downside of using a block cipher is that so far none of the proposal using block ciphers provide crypto-agility. The only proposal that has agility is the one proposed in this PR. However, it relies on a stream cipher (i.e. AES-CTR or Chacha20).

The issue with stream ciphers is that it is extremely fragile to side-channel attacks as @ad-l has pointed out. I can think of several ways to shuffle the bits in a secure and somewhat efficient way (e.g. determine the bit order using the output of the stream cipher and use bmi2 instruction for shuffling), but I do not think that it would be easy enough for us to define as a standard.

> https://github.com/quicwg/base-drafts/pull/1079#issuecomment-379919079

As stated above, the checksum needs to be cryptographically secure, assuming that we want to prevent side channel attacks. I do not think the proposal meets that goal.

-- 
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-383488261

---

From: MikkelFJ <[email-masked]>
Date: Mon, 23 Apr 2018 02:31:17 -0700

> As stated above, the checksum needs to be cryptographically secure, assuming that we want to prevent side channel attacks. I do not think the proposal meets that goal.

I don't think it needs to be that strong, but PN's then need to be segregated per path. But otherwise yes, I share those concerns, I also mentioned similar concerns in my comment. However, side channel attacks are near impossible to avoid to some degree when you need to have DoS protection.

-- 
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-383513688

---

From: Martin Thomson <[email-masked]>
Date: Wed, 25 Apr 2018 10:33:08 +0000 (UTC)

a1c4d41  Grammar boobo

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1079/files/d6d9837d685d3de4d035a78fa7c99bc03e99e8ba..a1c4d41f7110eedb5536bab02b1d927cc01b68c8

---

From: Dmitri Tikhonov <[email-masked]>
Date: Wed, 25 Apr 2018 05:51:33 -0700

dtikhonov commented on this pull request.

> @@ -346,7 +346,7 @@ Packet Number:
 
 : The Packet Number is a 32-bit field that follows the two connection IDs.
   {{packet-numbers}} describes the use of packet numbers.  Packet numbers are
-  protected separate to the packet payload.
+  protected separately to the packet payload.

I think this should read "Packet numbers are protected separately _from_  the packet payload."

-- 
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#pullrequestreview-115160363

---

From: Martin Thomson <[email-masked]>
Date: Sun, 29 Apr 2018 20:41:48 -0700

@kazuho

> As far as I understand, any PNE scheme without accompanying checksum is fragile to side-channel attacks, because the probability of the receiver dropping the packet without decrypting the payload is proportional to the value of the decrypted PN field. An attacker that has access to side-channel information can use that information to guess the value of the PN field.

The PR mandates that receivers not do that (though I concede that that could easily turn into a 6919 "MUST (BUT WE KNOW YOU WON'T)").  In short, the checksum you are looking for is the integrity check that is integrated into the AEAD.

-- 
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-385308134