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

[Kazuho Oku <[e-mail]>]

2018年12月16日(日) 11:49 Kazuho Oku <[e-mail]>:
>
> Hi Eric,
>
> Thank you for your comments. My responses below.
>
> 2018年12月16日(日) 3:50 Eric Rescorla <[e-mail]>:
> >
> > 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,
>
> I agree about the deployment model and the threat model. Models help a
> lot; thank you for clarifying them.
>
> > 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]
> >
> >
> >
> > 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'.
>
> Thank you for pointing out the attack vector. I do not know why I
> missed that even though we knew the existence of it in #2076.
>
> IMO, the most straightforward defense would be to require clients to
> derive the initial DCID from the value of ClientHello, for example by
> using a hash function (i.e. DCID = Hash(ClientHello)).
>
> Then, we can ensure by design that each Initial carrying a different
> ClientHello would be considered as a different connection
> establishment attempt. QUIC-AH already requires implementations to
> check the tag after processing ClientHello, therefore additionally
> requiring to check the value of the DCID field is fine.
>
> To handle Retry that changes the server CID, we need to add ODCID
> field to the Initial packet. A client that receives a Retry that
> updates the server CID will set the DCID field of the resent Initial
> to the updated value, and set the original value to the ODCID field. A
> server that receives an Initial containing a token that it does not
> understand would process the packet as if the token was missing and as
> if the value of the ODCID field was present in the DCID field.
>
> > 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.
> >
> >
> > 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.
>
> I acknowledge that the attack vector exists.

Sorry for the confusion, but I am starting to wonder if the attack
vector really exists.

The attacker cannot create CInitial' that contains the same ESNI
extension as CInitial, because the Initial packets are authenticated
by the ESNI shared secret. Therefore, we can be certain CInitial' that
triggers a SInitialX would be based on a different by a different ESNI
shared secret, which in turn means that SInitialX would never be
accepted by the client. Am I missing something?

>
> I think the easiest way to mitigate the attack is to mix ClientHello
> (or a value derived from ClientHello) into the HMAC key used for
> authenticating the Initial packets. Then, we would not be required to
> rekey during the exchange of Initial packets.
>
>     hmac_key = HKDF-Expand-Label(
>         Zx,
>         "quic initial auth",
>         Hash(ESNIContents) || ODCID, // ODCID == Hash(ClientHello)
>         digest_size
>     )
>
> >
> > 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.
> >
> >
> > 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).
>
> I am not sure if rekeying is necessary, because client is sending a
> value that is only known by the server in it's Initial and the server
> is authenticating it's responses using that.
>
> I do not think it is possible for an attacker to spoof the Initial
> packets sent by the server.
>
> > 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).
>
> I am not sure if we need to consider that.
>
> My understanding is that ESNI expects the server to process the ESNI
> extension of the first ClientHello, even when it responds with an HRR.
> Because HRR is something that a hidden server (in the split-server
> model) might send. And though I admit that the a non-split server can
> delay the processing of ESNI extension until it receives the second
> ClientHello, I do not think we need that in QUIC, because we have
> Retry.
>
> > 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.
> >
> >
> > 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).
>
> I do not think that the attack vector exists. Downgrade protection of
> QUIC v1 would prevent that.
>
> It's just that the `supported_versions` field of the QUIC_ESNI
> extension replaces the role of the Version Negotiation packet. Neither
> of them are protected. However, an attacker spoofing the value gets
> detected at the end of the handshake.
>
> > 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.
> >
> >
> > [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.
> >
> >
> >
> > On Thu, Dec 13, 2018 at 6:34 PM Kazuho Oku <[e-mail]> wrote:
> >>
> >> TL;DR: Christian and I have submitted an I-D that proposes a flavor of
> >> QUIC v1 that uses the Encrypted SNI key to authenticate Initial
> >> packets. Initial packets are no longer vulnerable to man-on-the-side
> >> attacks; the entire handshake process becomes tamper-proof.
> >>
> >> https://datatracker.ietf.org/doc/draft-kazuho-quic-authenticated-handshake/
> >>
> >> ## Background
> >>
> >> So far, we have spent multiple efforts to make QUIC resistant to
> >> man-on-the-side attacks. Among them, mitigating injection attacks of
> >> Initial packets has been the biggest head-ache.
> >>
> >> There have been various proposals (including #2045, #2053, #2076), but
> >> the question has always been if it's worth the effort, because there
> >> are so many attack vectors (e.g. injection of a packet carrying a
> >> corrupt header, invalid or unknown frames, ACKs with unsent PNs,
> >> crafted TLS Hellos, HelloRetryRequests, crafted Version Negotiation or
> >> Retry packets) and it is doubtful if having mitigations for just one
> >> or few types of attacks are meaningful. We want to close all the
> >> attack vectors, however it is like building house of cards.
> >>
> >> ## The Proposed Approach
> >>
> >> The draft introduces a different approach. It relies on the Encrypted
> >> SNI [1]. For people not familiar with Encrypted SNI, it is an
> >> extension of TLS 1.3 that uses a public key distributed using DNS to
> >> encrypt the SNI. Encrypted SNI is currently a TLS WG draft, has
> >> multiple implementations, and it is already deployed by Cloudflare and
> >> Mozilla.
> >>
> >> The approach proposed by the draft is to use a shared secret that is
> >> derived from the Encrypted SNI key to authenticate the Initial
> >> packets, using HMAC. Because the shared key can only be calculated by
> >> the endpoints, an attacker cannot spoof the Initial packets. Spoofed
> >> packets will be detected by HMAC and will be to dropped.
> >>
> >> The draft disables Version Negotiation (because the DNS record of
> >> Encrypted SNI can carry a list of QUIC versions supported by the
> >> server), a different client-side behavior for handling Retry packets,
> >> and also introduces a CONNECTION_CLOSE packet to communicate handshake
> >> failures without affecting the transport state.
> >>
> >> And of course, it also uses a different QUIC version number in the
> >> long packet header field so that the Initial packets of QUIC v1 and
> >> the authenticated Initial packets of the proposal can be handled
> >> differently.
> >>
> >> Other than that, the protocol is identical to QUIC v1, including the
> >> handling of 0-RTT, Handshake, 1-RTT packets and the frames being
> >> contained by them. IMO, the differences are small and isolated well
> >> enough that QUIC v1 stacks can easily add support for the flavor
> >> proposed by the I-D.
> >>
> >> There are other benefits too. We have always hoped to have multiple
> >> versions of QUIC being deployed from early days in order to prevent
> >> ossification. The proposal makes that happen. Besides, one interesting
> >> aspect of the proposed protection of Initial packets is that MITM
> >> boxes (with root certificates) would not be possible to terminate the
> >> connection _unless_ they also block the distribution of Encrypted SNI
> >> DNS records, and that even then, the existence of such MITM boxes is
> >> detectable. Raising the bar of implementing and deploying MITM boxes
> >> as well as detecting them is beneficial for the evolution of the
> >> protocol.
> >>
> >> The downside of the proposal is that it only protects QUIC connections
> >> going to servers that provide the Encrypted SNI DNS records. But
> >> considering our failing attempts to address the Initial packet
> >> injection attacks, and considering the amount of interest we have seen
> >> for Encrypted SNI, I think that the proposed approach is the way
> >> forward.
> >>
> >> Please let us know what you think. Thank you in advance.
> >>
> >> PS. The GitHub repository of the I-D is:
> >> https://github.com/kazuho/draft-kazuho-quic-authenticated-handshake
> >>
> >> ---------- Forwarded message ---------
> >> From: <[e-mail]>
> >> Date: 2018年12月14日(金) 11:30
> >> Subject: New Version Notification for
> >> draft-kazuho-quic-authenticated-handshake-00.txt
> >> To: Kazuho Oku <[e-mail]>, Christian Huitema <[e-mail]>
> >>
> >>
> >>
> >> A new version of I-D, draft-kazuho-quic-authenticated-handshake-00.txt
> >> has been successfully submitted by Kazuho Oku and posted to the
> >> IETF repository.
> >>
> >> Name:           draft-kazuho-quic-authenticated-handshake
> >> Revision:       00
> >> Title:          Authenticated Handshake for QUIC
> >> Document date:  2018-12-14
> >> Group:          Individual Submission
> >> Pages:          9
> >> URL:
> >> https://www.ietf.org/internet-drafts/draft-kazuho-quic-authenticated-handshake-00.txt
> >> Status:
> >> https://datatracker.ietf.org/doc/draft-kazuho-quic-authenticated-handshake/
> >> Htmlized:
> >> https://tools.ietf.org/html/draft-kazuho-quic-authenticated-handshake-00
> >> Htmlized:
> >> https://datatracker.ietf.org/doc/html/draft-kazuho-quic-authenticated-handshake
> >>
> >>
> >> Abstract:
> >>    This document explains a variant of QUIC protocol version 1 that uses
> >>    the ESNI Keys to authenticate the Initial packets thereby making the
> >>    entire handshake tamper-proof.
> >>
> >>
> >>
> >>
> >> Please note that it may take a couple of minutes from the time of submission
> >> until the htmlized version and diff are available at tools.ietf.org.
> >>
> >> The IETF Secretariat
> >>
> >>
> >>
> >> --
> >> Kazuho Oku
> >>
>
>
> --
> Kazuho Oku



-- 
Kazuho Oku