Subject: Re: [quicwg/base-drafts] Reconsider the use of FNV-1a for "cleartext" integrity (#554)

From: ianswett <[email-masked]>
Date: Thu, 08 Jun 2017 14:55:55 -0700

While we're reconsidering this, @martinduke and I were talking again about the idea of encrypting using AES-GCM with a version specific key.  That re-convinced me it was a good idea.

1) AES-GCM hardware offload is a common feature, and being able to use it as much as possible is nice.
2) Forces middleboxes that want to do TLS inspection to stay up to date with the latest versions, otherwise they won't be able in inspect SNI.  This makes future changes to TLS less likely to ossify, since middleboxes that aren't frequently updated won't be able to see the new version of TLS.

Given recent deployment issues with TLS 1.3, I think point 2 is more valuable than I previously believed.

-- 
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/issues/554#issuecomment-307238514

---

From: martinduke <[email-masked]>
Date: Thu, 08 Jun 2017 16:02:10 -0700

Furthermore, as I brought up in Chicago, this greatly simplifies the code
path as well if you do crypto offload. Currently, iincoming encrypted
packets are decrypted asynchronously while handshake packets are handled
immediately. So it's a little complicated to think through when it's OK to
free the packet, enough that I very well might of messed it up in a way
that will emerge as a memory leak someday.

There has to be similar logic when sending the packet.

It would greatly simplify the permutations if packets were always
encrypted, and it was just a matter of switching from an insecure key to a
secure one.

On Thu, Jun 8, 2017 at 11:55 PM, ianswett <[email-masked]> wrote:

> While we're reconsidering this, @martinduke
> <https://github.com/martinduke> and I were talking again about the idea
> of encrypting using AES-GCM with a version specific key. That re-convinced
> me it was a good idea.
>
>    1. AES-GCM hardware offload is a common feature, and being able to use
>    it as much as possible is nice.
>    2. Forces middleboxes that want to do TLS inspection to stay up to
>    date with the latest versions, otherwise they won't be able in inspect SNI.
>    This makes future changes to TLS less likely to ossify, since middleboxes
>    that aren't frequently updated won't be able to see the new version of TLS.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/554#issuecomment-307238514>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AXRMEUo8YKHQXnbvoZ-TXzdewZNus0dCks5sCG3rgaJpZM4NjENJ>
> .
>

-- 
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/issues/554#issuecomment-307250469

---

From: MikkelFJ <[email-masked]>
Date: Thu, 08 Jun 2017 23:05:04 -0700

While not against the idea, 

does not hold when encryption is not necssarily AES-GCM after handshake or in a new version. Further, some low-end IoT devices do not have AES accelleration, and will not have, and may want to use ChaCha20 instead. Such devices could use a generic implementation since it is only for handshake, but it does kill the simplicity argument.

I have previously in a private mail to some authors suggested signing the cleartext headers uses a CMAC algorithm with a version specific key. This is much simpler than AES-GCM and better suited for non-version specific implementation. CMAC will not encrypt, but AES can still be used for that, if the concern is ossification.

Regarding ossification - isn't there a risk that middleboxes will only work if they understand the protocol, and thus will reject newer QUIC versions with a key they don't have? This could make the problem worse. I'm just speculating as I have no experience with these issues.

-- 
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/issues/554#issuecomment-307303447

---

From: MikkelFJ <[email-masked]>
Date: Thu, 08 Jun 2017 23:27:56 -0700

For reference here is the CMAC proposal from March 15 I sent:

> The approach discussed below can be extended to unauthenticated headers:
> 
> Each protocol version publishes a fixed AES-128 key (several versions may use the same key) and protects the header with a two byte tag as for protected packets. This serves the dual purpose of providing protocol magic bytes and a header hash.
> 
> This helps separate traffic from other UDP protocols and to an extent middle box manipulation of unprotected headers.
> 
> It may possibly also help mitigate DoS attacks on the TLS handshake. I have not studied what the handshake does internally, but it can prevent starting the TLS machinery in the first place.
> 
> There is a risk that middle boxes hardcodes the key, making the protocol version difficult to change. For this reason the key should not necessarily be tied to a specific protocol version.
> 
> Proprietary deployments such as in-house database connections may configure a random fixed custom key for the header tag. This is not intended to be strong encryption but it prevents random external communication (early rejection before TLS) and the key cannot be trivially guessed from just the 16 tag bits. It is not sufficient to provide non-idempotent 0-RTT transactions.
> 
> I’m sure you have already considered something along the following lines, but for completeness:
> 
> I have not yet studied 0-RTT in detail, but it appears to me that a simple 64-bit counter along with the stored crypto context would be enough to prevent some replay attacks. In this case the public tag key could be replaced with a CMAC that includes a 64-bit counter that is stored with the crypto context at client and server. Because of the counter field as extra information in addition to the header, a full CMAC and not just a single AES encryption may be required, or the counter could be placed in the high part of the implicit 64-bit packet number. Because the tag is only two bytes this is still insufficient to handle idempotent 0-RTT transactions but it allows early rejection (before TLS engine) of replays. The tag could be extended to more than two bytes, but it is probably better to also include the counter in the full 0-RTT handshake protocol and include it in some tag there.
> 
> The counter must be larger than any previous connection attempt by at most a small amount (small enough to retry different counters). The counter is not (necessarily) included in the header other than in hashed form because it would leak information about how many connection attempts have been made, and it is not strictly needed. The counter adds complexity to a server clusters because the counter must be synchronized, but so must the crypto context. Allowing some variation in next counter value should handle both sync delays and interrupted connection attempts. For unstable connections and delayed server sync the fallback is then 1-RTT. If the counter is not explicit in the header, a DoS attack might force many CMAC counter increment attempts, which is why it must be a small increment.
> 

-- 
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/issues/554#issuecomment-307306820