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

From: Martin Thomson <[email-masked]>
Date: Sun, 28 Jan 2018 22:01:03 -0800

This is a little rough, but I think that the bones are here.  I'm not all that proud of my analysis of the security of this hack, but I couldn't think of a way of disclaiming its value without also having it seem like we were throwing unlinkability for connection migrations under the bus.

I know that we discussed removing short packet types in favor of putting the lengths under encryption.  I will do that separately, just to keep the size of this changeset to something more manageable.

Closes #1043, #1048, #850, #990.

IMPORTANT: don't merge this without pointing it first at `master`.  I've based this on the changes in #1077/`key-schedule-cleanup`, so it will land there if it is merged without changing the target.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/1079

-- Commit Summary --

  * Initial cut at packet number encryption

-- File Changes --

    M draft-ietf-quic-tls.md (156)
    M draft-ietf-quic-transport.md (133)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/1079.patch
https://github.com/quicwg/base-drafts/pull/1079.diff

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

---

From: Martin Thomson <[email-masked]>
Date: Sun, 28 Jan 2018 22:12:17 -0800

@martinthomson pushed 1 commit.

509afe9  Constant time

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

---

From: Martin Thomson <[email-masked]>
Date: Sun, 28 Jan 2018 23:26:16 -0800

f94ef09  That was a little unclear on a re-read

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

---

From: Martin Thomson <[email-masked]>
Date: Sun, 28 Jan 2018 23:28:02 -0800

67cfded  That was a little unclear on a re-read, again

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

---

From: MikkelFJ <[email-masked]>
Date: Mon, 29 Jan 2018 10:11:51 +0000 (UTC)

mikkelfj commented on this pull request.

> +or modified packet number can only be detected once the packet protection is
+removed.
+
+An attacker can guess values for packet numbers and have an endpoint confirm
+guesses through timing side channels.  If the recipient of a packet discards
+duplicate packets without attempting to remove packet protection they will
+reveal through timing side-channels that the packet number matches a received
+packet.  For authentication to be free from side-channels, the entire process of
+packet number protection removal, packet number recovery, and packet protection
+removal MUST be applied together without timing and other side-channels.
+
+For the sending of packets, construction and protection of packet payloads and
+packet numbers MUST be free from side-channels that would reveal the packet
+number or its encoded size.
+
+
 # Error Codes {#errors}

I am not convinced this timing attack protection is worthwhile. There is no argument on how an attacker might do the timing. There is no immediately observable reply, and an ACK would not happen just because the packet was guessed. It could affect ACK of a valid packet and a powerful attack could delay valid packets to measure timing. But this must be balanced against the value of guessing the packet number. The value can lead to tracking a migration, but so can tons of other fingerprints.

In conclusion, requiring that a full AEAD validation is performed on essentially all invalid packet headers seems to be unreasonable. However, if it isi important, I would MUCH rather prefer a short 16-bit header validation tag that can quickly reject any invalid header in case of a flood attack.

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

---

From: MikkelFJ <[email-masked]>
Date: Mon, 29 Jan 2018 10:21:04 +0000 (UTC)

> +## 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).  For
+packets with a short header, the packet number length is not known, so it is
+assumed to be its largest possible length (4 octets).  Thus, for a short header,
+the sampled ciphertext starts at either octet 5 when the connection ID is
+omitted, or octet 13 when the connection is present.
+

If packet number protection (for good reasons) is only applied after handshake, this prevents connection migration from looking like a new handshake unless there are special rules for packet numbering during a handshake. Hence, perhaps protetected packet numbers should have a separate numbering space.

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

---

From: Mike Bishop <[email-masked]>
Date: Mon, 29 Jan 2018 11:11:23 -0800

MikeBishop commented on this pull request.

Looks fine.

> +Packet number protection relies on the randomness of the AEAD output, which is a
+property that AEAD algorithms do not guarantee.  Therefore, no strong assurances
+about the general security of this mechanism can be proven.
+
+Use of the same key and nonce for encryption for encryption can weaken
+encryption.  For the schemes described, protecting two packet numbers with the
+same key and nonce would reveal the packet number.  For packet number protection
+to be effective, the output of the packet protection AEAD needs to be
+effectively random.
+
+All the AEAD functions used meet indistinguishability under (adaptive) chosen
+plaintext attack (IND-CPA, IND-CPA2) goals and produce minimal expansion of the
+plaintext, adding only an authentication tag.  Therefore, this document assumes
+that each bit of sampled AEAD output contains one bit of entropy and that an
+attacker is unable to reduce this without knowledge of the key.  Based on this
+assumption, the odds of two samples of ciphertext approach the birthday bound

It feels like you're missing a word here, but I'm not sure what it should be.

> +All the AEAD functions used meet indistinguishability under (adaptive) chosen
+plaintext attack (IND-CPA, IND-CPA2) goals and produce minimal expansion of the
+plaintext, adding only an authentication tag.  Therefore, this document assumes
+that each bit of sampled AEAD output contains one bit of entropy and that an
+attacker is unable to reduce this without knowledge of the key.  Based on this
+assumption, the odds of two samples of ciphertext approach the birthday bound
+for the size of the sample (that is, two to the negative power of half the
+number of sampled bits).
+
+Note:
+
+: In some cases, inputs shorter than the full size required by the packet
+  protection algorithm might be used.
+
+To prevent an attacker from modifying packet numbers, values of packet numbers
+are transitively authenticated using the packet number protection.  A falsified

I thought it was authenticated using the AD from the packet protection, not the packet number protection?

+removed.
+

I'll second this.  You can't tell from the network that a packet has been discarded, and opening yourself up to the attack of being forced to decrypt something you already know is either junk or useless doesn't seem worth it.

> @@ -582,9 +584,9 @@ unless it has received a packet from the server.  If the client has received a
 packet from the server, the connection ID field uses the value provided by the
 server.
 
-The first Initial packet that is sent by a client contains a randomized packet
-number.  All subsequent packets contain a packet number that is incremented by
-one, see ({{packet-numbers}}).
+The first Initial packet that is sent by a client contains a packet number of 0.
+All subsequent packets contain a packet number that is incremented by one, see

I think elsewhere we've said "at least one" in order to allow for skipping the occasional packet number.

> @@ -401,7 +401,8 @@ Version:
 Packet Number:
 
 : Octets 13 to 16 contain the packet number.  {{packet-numbers}} describes the
-  use of packet numbers.
+  use of packet numbers.  Packet numbers are protected separate to the packet

You use "separately from" on 679, which feels more natural.  (Again, possible dialect difference.)  Same on line 486-487.

> @@ -709,8 +714,8 @@ packets MUST use connection ID selected by the client.
 The packet number is an integer in the range 0 to 2^62-1. The value is used in
 determining the cryptographic nonce for packet encryption.  Each endpoint
 maintains a separate packet number for sending and receiving.  The packet number
-for sending MUST increase by at least one after sending any packet, unless
-otherwise specified (see {{initial-packet-number}}).
+for sending MUST starts at zero for the first packet set and MUST increase by at

s/starts/start/

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

---

From: ianswett <[email-masked]>
Date: Mon, 29 Jan 2018 20:50:57 +0000 (UTC)

ianswett commented on this pull request.

+

As it stands now, connection migration in no way looks like a new connection, because no long form handshake packets are used on the new path.

-- 
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#discussion_r164559776

---

From: ianswett <[email-masked]>
Date: Mon, 29 Jan 2018 21:08:40 +0000 (UTC)

Q: If we encode the packet number length inside the encryption, which seems nice, does the decrypter have to assume the longest possible packet number length, then check the first byte after decryption to determine the actual length?

 Packet Number:

Agreed, separately from feels more natural

and s/set/sent

> @@ -866,6 +867,85 @@ the connection that is hosted on stream 0.  This sequence number is not visible
 to QUIC.

If we move to varint packet numbers inside encryption, determining the length of the varint with this approach seems not completely obvious.  If we stick with this approach instead of the overlapping crypto operations, it would be good to add small section on removing packet number 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#pullrequestreview-92352720

---

From: MikkelFJ <[email-masked]>
Date: Mon, 29 Jan 2018 21:58:23 +0000 (UTC)

to QUIC.

> Q: If we encode the packet number length inside the encryption, which seems nice, does the decrypter have to assume the longest possible packet number length, then check the first byte after decryp…

Since the encryption is XOR based, it suffice to decrypt the first byte with XOR to decide the length, or, just the first two bits, actually. In praxis it might be simpler/faster to XOR with the maximum length, then read as necessary. Escpecially if the packet is guaranteed to be long enought and when fast unaligned 8 byte reads are available.

-- 
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#discussion_r164577707

---

From: MikkelFJ <[email-masked]>
Date: Mon, 29 Jan 2018 22:00:00 +0000 (UTC)

+

> As it stands now,

I was thinking a bit ahead - considering the open issue(s?) on the topic.

-- 
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#discussion_r164578145

---

From: Mike Bishop <[email-masked]>
Date: Mon, 29 Jan 2018 22:24:02 +0000 (UTC)

+

Perhaps a client-initiated PATH_CHALLENGE/PATH_RESPONSE should be long header packets?  But that's totally orthogonal to this PR, I think.  So long as the packet number is obscured in both header types, an observer can't tell whether a connection is restarting from zero or not.

-- 
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#discussion_r164584157

---

From: MikkelFJ <[email-masked]>
Date: Mon, 29 Jan 2018 22:28:05 +0000 (UTC)

+

The initial handshake needs to negotiate encryption and hence cannot encrypt those packets.

Perhaps the packet numbers ought to be encrypted with a version specific non-negotiably algorithm, but that hurts devices that doesn't speak AES natively. This is why I suggest each handshake and migration sequence uses unencrypted, from 0, packet numbers, unique to each connection ID.

-- 
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#discussion_r164585113

---

From: Martin Thomson <[email-masked]>
Date: Mon, 29 Jan 2018 14:43:23 -0800

martinthomson commented on this pull request.

+removed.
+

I knew that this would raise eyebrows :)

Early discard doesn't give any better protection against denial of service.  The space of valid packet numbers is >= 50% of the total expressible space, which - with the type outside of protection as it currently is - can be 2^32.  That number doesn't go down with guesses.  That means that an attacker can always force the receiver to do a full AEAD.  Given that, the cost of full side-channel resistance is marginal.

As for observing the timing of a discarded packet, I agree that it is hard.  Of course, there is always the next packet.

-- 
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#discussion_r164588705

---

From: Martin Thomson <[email-masked]>
Date: Mon, 29 Jan 2018 22:52:34 +0000 (UTC)

Thanks for the quick response.

 to QUIC.

What @mikkelfj says.  Say we choose an encoding with a 4 octet maximum length, then you copy 4 octets out, XOR those, then decode from that buffer.  You then know the length and can discard the excess.

+

The biggest problem for having migration appear to be a new connection is that the packets won't decrypt with the handshake keys.  This doesn't change any of that.  @mikkelfj separately suggested that we use 0-RTT, and that could work, but it's a pretty big lift.

Yeah, you are right.  Got used to typing packet *number* protection.

Wow, epic fail :)

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 29 Jan 2018 14:52:57 -0800

@martinthomson pushed 2 commits.

6712847  More tweaking (I have to stop this)
bc4d944  Some fairly obvious errors

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 29 Jan 2018 17:45:32 -0800

7cf2f6c  Don't mess with ChaCha20, use it directly

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 30 Jan 2018 03:21:21 +0000 (UTC)

8320755  Fix off-by-one error

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

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 30 Jan 2018 04:45:09 +0000 (UTC)

kazuho commented on this pull request.

+
+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).  For
+packets with a short header, the packet number length is not known, so it is
+assumed to be its largest possible length (4 octets).  Thus, for a short header,
+the sampled ciphertext starts at either octet 5 when the connection ID is
+omitted, or octet 13 when the connection is present.
+
+The protected packet might not have produced enough input for the negotiated
+packet protection algorithm.  This might happen if a packet with a short header
+contains minimal data and uses a packet number encoding that is shorter than 4
+octets.  Additional zero octets are added to the end of the sequence to reach
+the required amount of data.

It might make sense to use the last N bytes of the packet as IV. 

By doing so, I think that we can remove the zero-padding rule introduced in this paragraph, since it is guaranteed (at least for the algorithms being defined here) that the length of the AEAD tag is longer than that required for the IV.

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 29 Jan 2018 21:42:03 -0800

+

I considered this, and it does have that advantage.  However, I have been told that reading that far ahead is problematic for some implementations, performance-wise.

The odds of actually having a short packet are tiny.  For a 1 octet packet number, you need to have <3 octets of payload.  For a 2 octet packet number, then you need <2 octets of payload.  And right now only PADDING is one octet.  PING will eventually go back to 1 octet as well.  That's for a 2^-56 bound.  At 2^-60, STREAM, BLOCKED, and STREAM_ID_BLOCKED can be 2 octets.  MAX_DATA also, if you believe that <64 octets is ever something you would see on the 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#discussion_r164645220

---

From: MikkelFJ <[email-masked]>
Date: Tue, 30 Jan 2018 06:27:52 +0000 (UTC)

+removed.
+

It is also about being able to reject retransmissions of valid packets early, if you suddenly get a burst of such packets. Not sure how likely that is.

-- 
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#discussion_r164650689

---

From: MikkelFJ <[email-masked]>
Date: Tue, 30 Jan 2018 06:31:33 +0000 (UTC)

+

Yes that is true - in 0-RTT the packet numbers could be encrypted.

BTW: if 0-RTT doesn't actively take measures to avoid fingerprinting, that would be an excellent way to track users. This somewhat relates to the replay thing.

-- 
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#discussion_r164651106

---

From: MikkelFJ <[email-masked]>
Date: Tue, 30 Jan 2018 07:17:10 +0000 (UTC)

+

Instead of zero padding, the input could sampled from protected packet content including cipher text and, for short cipher text, also the authentication tag.

But

I don't like that it is not possible to do AEAD verification in-place without modifying the packet content. Thus AEAD should cover the encrypted packet number, not the plain text packet number. However, then it does not work to use the cipher nor the tag as input. 

-- 
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#discussion_r164657047

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 30 Jan 2018 09:11:58 +0000 (UTC)

+

@martinthomson Thank you for elaborating the issue behind the design decision. That makes sense to me.

@mikkelfj
> Instead of zero padding, the input could sampled from protected packet content including cipher text and, for short cipher text, also the authentication tag.

The issue is that it is impossible to tell where the ciphertext or the authentication tag begins, assuming that the length of the packet number field will become part of the protected packet number.

Consider the case where we have protected packet number (1 octet), ciphertext (1 octet), tag (16 octets). 

The length of the packet number is encoded within the protected packet number. We need to find entropy from the octets that are guaranteed to be not part of the protected packet number.

The text in the PR proposes to take from the fifth octet of the encrypted triplet (i.e. protected packet number, ciphertext, tag). That would mean that the minimum length of the entropy would be 14 bytes.

> I don't like that it is not possible to do AEAD verification in-place without modifying the packet content.

My assumption was that we would nevertheless be required to modify the packet header before feeding it as AAD to AEAD, assuming that we would either have greasing (in the packet header) or at least one spin bit. Is that no longer the case?

-- 
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#discussion_r164678318

---

From: MikkelFJ <[email-masked]>
Date: Tue, 30 Jan 2018 01:53:49 -0800

+

> The issue is that it is impossible to tell where the ciphertext or the authentication tag begins

I see. But I don't think it would be a big deal to expose the length bits in clear text. But then again, zero padding is also fine.

> My assumption was that we would nevertheless be required to modify the packet header 

I would assume you could apply AEAD after spin bits etc.. However, packet numbers are different because they are the IV for the AEAD itself and because their encryption is derived from the same 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#discussion_r164689500

---

From: Christian Huitema <[email-masked]>
Date: Tue, 30 Jan 2018 20:05:16 -0800

huitema commented on this pull request.

 to QUIC.

How about something like:
1) Set a barrier at the start of the chosen ciphertext input.
2) If the barrier is further than 8 bytes from the beginning of the packet number, XOR 8 bytes from beginning of packet number, 
3) If the barrier is closer than that, XOR up to the barrier.

-- 
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#discussion_r164949119

---

From: Christian Huitema <[email-masked]>
Date: Wed, 31 Jan 2018 04:08:42 +0000 (UTC)

+

See my "barrier" comment above. The only requirement is that one does not re-encrypt the bytes used for the IV, because that would lead to trouble. So, set a barrier before these bytes, and never XOR bytes after that barrier. 

-- 
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#discussion_r164949400

---

From: Christian Huitema <[email-masked]>
Date: Tue, 30 Jan 2018 20:10:51 -0800

> @@ -1519,6 +1584,51 @@ SHOULD track redundant packets and treat excessive volumes of any non-productive
 packets as indicative of an attack.

+## Packet Number Protection Analysis {#pn-encrypt-analysis}
+

for encryption twice?

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 31 Jan 2018 04:15:56 +0000 (UTC)

+

I'm not sure what your proposal is there.  What I have described takes at least 14 octets always.  I think that's enough, even with the birthday bound on 112 bits being pretty low: with AES you have to re-key long before you hit that many packets, and I'd say that you'd want to do the same with ChaCha even if it remains cryptographically sound for far longer.

-- 
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#discussion_r164949920

---

From: Martin Thomson <[email-masked]>
Date: Wed, 31 Jan 2018 04:16:57 +0000 (UTC)

Should I say two "different" packet numbers?  Basically, this is the standard admonition against reuse of key and nonce.

-- 
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#discussion_r164949989

---

From: Martin Thomson <[email-masked]>
Date: Tue, 30 Jan 2018 20:20:54 -0800

1b57997  Two *different* packet numbers

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

---

From: Christian Huitema <[email-masked]>
Date: Wed, 31 Jan 2018 19:50:49 +0000 (UTC)

> +algorithms for AEAD_AES_128_GCM, AEAD_AES_128_CCM, AEAD_AES_256_GCM,
+AEAD_AES_256_CCM (all AES AEADs are defined in {{!RFC5116}}), and
+AEAD_CHACHA20_POLY1305 ({{!CHACHA=RFC7539}}).
+
+
+### AES-Based Packet Number Protection
+
+This section defines the packet protection algorithm for AEAD_AES_128_GCM,
+AEAD_AES_128_CCM, AEAD_AES_256_GCM, and AEAD_AES_256_CCM. AEAD_AES_128_GCM and
+AEAD_AES_128_CCM use 128-bit AES {{!AES=DOI.10.6028/NIST.FIPS.197}} in ECB mode.
+AEAD_AES_256_GCM, and AEAD_AES_256_CCM use 256-bit AES in ECB mode.
+
+This algorithm samples 16 octets from the packet ciphertext.  This input is used
+as the AES initialization vector (IV).  This value is input to AES that is keyed
+using the current packet protection key.
+

So is this 16 or 14?

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

---

From: Christian Huitema <[email-masked]>
Date: Wed, 31 Jan 2018 20:08:24 +0000 (UTC)

+

What I have in mind is the following:

1) Assume that after encryption but before packet number encryption the packet is composed of encrypted payload (ccc...ccc), packet number (pp), and other header bytes (h)
~~~
    hhhhhhppppccccccc...ccc
~~~
After packet number encryption the "p" bytes will be encrypted (P). Some of the leading bytes in the ciphertext may also be re-encrypted (C):
~~~
    hhhhhhPPPPCCCCccc...ccc
~~~
This only works if the receiver can find out whether the "cipher text input" starts, without knowing the exact length of the packet encoding. At that point it only knows the position of the first packet number byte, and the length of the packet. I would like a way to specify the length of the "PN encryption" and the offset of the ciphertext sample without requiring the receiver to exactly know the packet number length.

My proposition is to set the "offset" value to MIN(pn_start + 8, packet_length-16), and to encrypt the bytes between "pn_start" and "offset".

-- 
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#discussion_r165172205

---

From: Rui Paulo <[email-masked]>
Date: Wed, 31 Jan 2018 16:50:24 -0800

rpaulo commented on this pull request.

> @@ -1519,6 +1584,52 @@ SHOULD track redundant packets and treat excessive volumes of any non-productive

"for encryption" twice

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 31 Jan 2018 17:01:11 -0800

810ae7f  Remove repetition

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