Re: New Version Notification for draft-kazuho-quic-authenticated-handshake-00.txt

[Christian Huitema <[e-mail]>]

Quoting the whole message, because it is a nice analysis.

On 12/15/2018 10:50 AM, Eric Rescorla wrote:
> Kazuho,
>
> Thanks for sending this. I think it's a very interesting direction. I have
> some comments below.
>
> DEPLOYMENT MODEL
> It seems to me that there are two models to consider here. In the
> first, the server *only* supports authenticated handshakes (AH) and in
> the second, it supports both authenticated and unauthenticated
> handshakes. In general, I think the second case is far more likely,
> because in general we can't assume that clients can receive the
> ESNIKeys records, and that means that some clients will not use AH.
>
>
> THREAT MODEL
> This leads us directly to the question of the threat model. I assume
> that we have what I termed a Class (3) attacker, which can inject
> packets and will always win the race but cannot delete packets.
> With that, you get the following pattern:
>
>
> Client                  Attacker                Server
>
> CInitial ->
>                         CInitial' ->
>                         CInitial  ->
>                                            <- SInitial
>                         <- SInitial'
>                         <- SInitial
>
> CHandshake ->
>                         CHandshake ->
>                        
> Our objective is to have the handshake survive this treatment. In an
> ideal world, we would cause the server and client to reject X' and
> process X but this isn't possible, with the design you suggest,
> because the attacker can always take CInitial, replace the CRYPTO
> frames with his own and then send it to the server, computing
> a new MAC based on *his* Zx. Note that this won't necessarily have
> the right ESNI but that doesn't matter, because it will have
> the same [SC]CID, and so will cause cause CInitial to be discarded
> when it is received. As far as I can tell, your current design
> does not prevent this. If I'm missing something here, let me
> know [0]


Agreed.

>
>
>
> FIRST CLIENT INITIAL
> It seems like the obvious defense is the one you suggest in S 3.2.2,
> namely to treat each distinct CInitial as its own handshake and create
> separate state on the server for each one. Then this will cause the
> server to send two SInitials, one in response to CInitial and one
> in response to CInitial'. This gives us the diagram below.
>
> Client                  Attacker                Server
>
> CInitial ->
>                         CInitial' ->
>                                            <- SInitialX   //
> Corresponds to CInitial'
>                                            
>                         <- SInitialX'
>                         <- SInitialX
>                                           
>                         CInitial  ->
>                                             <- Sinitial   //
> Corresponds to CInitial
>                         <- Sinitial'
>                         <- SInitial 
>
> CHandshake ->
>                         CHandshake ->
>
> Note that the attacker can duplicate and tamper with any message
> either side sends so because the server sends two SInitials, the
> attacker ends up potentially sending 4.

The suggestion is S 3.2.2. is basically the same as PR 2706: create a
separate server context for each separate CH. Like Kazuho, I think it is
pretty much required for any good defense.

>
>
> SERVER INITIAL FLIGHT
> So, what we need at this point is to ensure that the client rejects
> (a) SInitial', SInitialX' and (b) SInitialX, and accepts SInitial (I'm
> ignoring subsequent Initial packets from the Client at this point),
> but I'll get there shortly. Rejecting SInitial' happens automatically
> in your design. The attacker doesn't have Zx and so SInitial' will not
> deprotect correctly.
>
> Rejecting SInitialX is harder, but I think can be fixed by mixing
> CInitial1
> into the the key schedule. I.e., the initial key would be something
> like:
>
>   IS = HKDF-Extract(0xef4fb0abb47470c41befcf8031334fae485e09a0,
>                     Zx)
>  
>   initial_secret = HKDF-Extract(HKDF-Expand(IS, ...),
>                                 F(CInitial))
>
> Where F(CInitial is some sanitized version of CInitial, that is
> invariant under retransmission, perhaps the payload + the CIDs.
> The result of this is that SInitialX and SInitial will be encrypted
> with separate keys (with only the one for SInitial being the one
> that the client expects) and the client will discard SInitialX
> after it fails to decrypt.

We tried to not have rekeying at the client, i.e. keep the same hmac key
throughout the session. The assumption is that the data incorporated in
the "hmac_key" contains something that client and server know, but the
attacker cannot guess. The structure "ClientESNIInner" has that
property, as long as the nonce really is unguessable. Caveats about
random number generation seem to apply. Now it may well be that our
draft refers to "ESNIContents" when in fact it should refer to
"ClientESNIInner". That would be a simple fix.

>
>
> SUBSEQUENT CLIENT INITIALS
> The diagram looks like this
>
> Client                  Attacker                Server
>
> CInitial ->
>                         CInitial' ->
>                                            <- SInitialX   //
> Corresponds to SInitial'
>                         CInitial  ->
>                                             <- Sinitial
>
>                         <- SInitialX'
>                         <- SInitialX
>                         <- SInitial
>                         <- Sinitial'
>
> CInitial2 ->
>                         CInitial2' ->
>                         CInitial2 ->
>
> There are actually two types of subsequent client Initials
>
>
> 1. Those after SH that contain ACKs (and the like) for server
>    Initial.
> 2. Those after HRR
>
> With case (1), we should just rekey off of Initial secret. The server
> can sort out which keys to use based on trial decryption or perhaps
> some extra flag in the packet (probably the second is better).

This gets better if the client switches to using the server chosen SCID
instead of the ICID in the subsequent initials. If we do that, then
there is no ambiguity: Clinitial2 arrives with the SCID chosen by the
server when sending SInitial, and is authenticated using the HMAC key
derived from CInitial.

If we insist that all Initial packets shall have Dest=ICID, then we do
indeed have a problem, and we need to put a unique token somewhere in
the payload. Hash(CInitial) would work.

>
> Case (2) (HRR) is more complicated. Trying to use data in the ESNI
> extension when you're not going to use g^x is tricky (though maybe
> possible), so we could potentially handle this as in case (1). Another
> alternative is to use the same general strategy we used for the
> first Initial and bucket the CInitial1/CInitial2 pairs. This is
> easiest done
> if we force each CInitial2 to commit to a specific CInitial1 (thus
> avoiding
> the need to do combinatoric explosion on the server). You could
> do this by including a hash of CInitial1 in CInitial2. The attacker
> can obviously bind CInitial2' to any CInitial he wants, but he has
> to transmit one message for each, so the result is the same as
> sending N CInitial1s.

That, or sending the messages with dest=SCID instead of dest=ICID.

I think we went back and forth with that idea. I don't quite remember
why we nixed it. Is there a potential deployment issue?


> VERSION NEGOTIATION
> In your design you move version negotiation to the client and forbid
> VN:
>
>    A client MUST ignore Version Negotiation packets.  When the client
>    gives up of establishing a connection, it MAY report the failure
>    differently based on the receipt of (or lack of) Version Negotiation
>    packets.
>
> More concerning, this moves the QUIC version negotiation to the ESNI
> record, which permits downgrade attacks by that server (or anyone who
> controls DNS). We've generally avoided this in TLS ESNI. It could
> be solved by having the true origin sign the ESNIKeys structure
> (as we have discussed for semi-static).
>
> It's worth noting that this is a consequence of QUIC's VN design. With
> the simplified VN design I suggested in PR #2113, you wouldn't have
> this problem: the server would commit to its *minimum* version (this
> is implicit in ESNIKeys already, as it requires TLS 1.3) and then you
> could upward negotiate as expected.

And maybe we should specify that. After all, we are creating a new QUIC
version, so we can just as well have a couple of extra transport parameters.


> [0] Another possibility with your current design is for the attacker
> to tamper with CH, for instance by adding a dummy extension, because
> the ESNI extension doesn't protect all of CH, just g^x. This will
> cause the server's Handshake messages to deprotect incorrectly. One
> could imagine a fix for this if the ESNI extensions covered more
> of the CH.

If the attacker did that, wouldn't the HMAC fail at the server? Also,
isn't that just a variant of CInitial' ?

-- Christian Huitema