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

[Kazuho Oku <[e-mail]>]

2018年12月16日(日) 9:45 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.

Yeah. As I suggested in my response to EKR, it might be worth
considering going one step further; i.e. derive DCID from ClientHello.

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

Agreed. I think that that would be a nice property to have (for
simplicity). And IMO there's no downside in doing that, because an
attacker cannot generate a spoofed packet that would be processed by
either of the endpoints, assuming that we address the issue of server
not rejecting spoofed Initial packets carrying legitimate a ESNI
extension (discussed above).

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

Zx is the shared secret between the client and server, therefore
hmac_key cannot be calculated by an attacker.

Hash(ESNIContents) is the equivalent of AAD. Therefore I am not sure
if ClientESNIInner is the correct thing to do. Instead we should
expand that to cover the entire ClientHello, to ensure that HMAC key
would be unique to ClientHello.

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

I think deriving DCID from Hash(ClientHello) would also fix the issue.

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



-- 
Kazuho Oku