Subject: Re: [quicwg/base-drafts] Authenticating connection IDs (#3439)

From: Martin Thomson <[email-masked]>
Date: Tue, 03 Mar 2020 20:30:40 -0800

In the interests of both providing defense in depth and for simplifying the analysis of the protocol, I believe that we should consider the ways in which connection IDs are negotiated and the ways in which that negotiation might be more strongly protected.

## Problem Statement

We currently do not validate any choice of any connection ID that is chosen during the handshake, with the exception of the Destination Connection ID the client chooses when a Retry was used.

The [paper above](https://eprint.iacr.org/2020/114) describes an attack on earlier versions of header protection that relied on the variable position of the packet number length field, the lack of an authenticated length of the connection ID, and the malleability of the encryption used in header protection.  We have since fixed the position of the packet number length, which invalidates that attack.  The effect of the attack was not severe, but I would rather not have any weaknesses.  Note also that two of these weaknesses remain and we only really fixed this problem by accident.

The attack described required that a server generate a Retry.  The attacker rewrites the Source Connection ID field from that message into a value that the server would then subsequently reuse.  This seems to be in tension with the requirement that connection IDs be unpredictable, but I believe the theory is that the requirement only applies to the question of linkability.  As long as an attacker is unable to generate another valid connection ID or link valid connection IDs to this original value, a server could reuse the client's choice.  Of course, in this case the value is chosen by the attacker, not the client.

A server could authenticate the value it includes in a Retry packet by including it in the token, but let's assume for now that it does not do that.  Whether or not there is a concrete attack out of this, this demonstrates that an attacker can choose a connection ID.  That's not a great position to be in with respect to analysis of the protocol.

Right now the values that are negotiated using the Source Connection ID field are not authenticated.  It is true that these are ultimately authenticated when they are included in the AAD of a 1-RTT packet, but that is rather circuitous. You might also say that Handshake packets also cover these, but that relies on even more convoluted logic. What I heard at QUIPS and what I learned from TLS is that formalizing proofs based on such indirect authentication can be extremely challenging.  I realize that this is theoretical, but we made concessions in TLS for simplified analysis and as long as the complexity cost is low, the same might be done here.

## Proposal

A relatively simple way to authenticate these connection IDs would be to include a `handshake_connection_id` transport parameter that includes the value that the endpoint includes in the Source Connection ID field of Initial or Handshake packets.  Endpoints then validate this value before declaring the handshake complete.  In terms of transport parameter construction, this is simple: endpoints make a choice and stick with it.  The only real cost is the extra 21 bytes this takes.

That isn't quite enough though.  The server gets to choose new connection IDs twice during the handshake if a Retry packet is sent.  Authenticating a single connection ID could not authenticate the Source Connection ID from the Retry packet.  That's might be OK on the basis that the value from the Retry won't be used after the handshake completes.

Not authenticating the choice from Retry is less OK if the server adopts the value that the client uses in its Destination Connection ID field.  Now the attacker just chose a connection ID.  As this was the specific attack that was used, that needs to be addressed too.

Rather than authenticate the Retry also, my suggestion there is to forbid the server from copying the client's Destination Connection ID when it generates its first Initial packet.  That is, the server needs to pick a completely new connection ID.  We already do that for Retry packets.  Then the attacker has no input into connection ID selection.

We could limit the requirement to change connection ID to only the cases where Retry is used.  That is require a change if there is a token in the Initial packet.  It seems easier to require the change always.

-- 
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/3439#issuecomment-594320754

---

From: ianswett <[email-masked]>
Date: Wed, 04 Mar 2020 08:46:51 -0800

> **Rather than authenticate the Retry also, my suggestion there is to forbid the server from copying the client's Destination Connection ID when it generates its first Initial packet.**

My first intuition is that this requirement could be difficult for some people(it certainly requires a change for us).  However, given Retry and NEW_CONNECTION_ID both have similar requirements, I think requiring this is fine, at least for us.

-- 
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/3439#issuecomment-594653925

---

From: Marten Seemann <[email-masked]>
Date: Wed, 04 Mar 2020 18:52:21 -0800

I'm not convinced that we need a transport parameter here. As explained by @martinthomson, a transport parameter would only protect the connection IDs used after the Retry, i.e. CIDs that are used *after* a connection has been accepted and an endpoint has created state for this connection.

At this point, we could require endpoints to keep track of the SCID that they used, and discard incoming packets that arrive at this connection where the DCID doesn't match the SCID they chose. If I'm not mistaken, this would thwart the attack (and as a bonus, it would do so earlier than the TP proposed here, since the TP would only be validated after the handshake completes).

-- 
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/3439#issuecomment-595001383

---

From: Martin Thomson <[email-masked]>
Date: Wed, 04 Mar 2020 19:01:48 -0800

@DavidSchinazi suggests that allowing the server to copy the client's ODCID when it is not sending a Retry would speed Google deployment.  I think that is a reasonable request, but it does complicate things.  I'd like to hear about that.

@marten-seemann suggests that forcing a change of connection ID at the server (always? only when there is no Retry?) would be sufficient because all an endpoint needs to do is ensure that the choice they made is retained.  I would like to see what @ad-l thinks of that.

(I will also take this to the list, but here I get to at-mention people :)

-- 
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/3439#issuecomment-595003696

---

From: Marten Seemann <[email-masked]>
Date: Wed, 04 Mar 2020 19:24:54 -0800

> @DavidSchinazi suggests that allowing the server to copy the client's ODCID when it is not sending a Retry would speed Google deployment. I think that is a reasonable request, but it does complicat…

It would be nice to avoid any unnecessary complication. @DavidSchinazi, is this a Google-specific problem, or would this also apply to other deployments?

-- 
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/3439#issuecomment-595008830

---

From: Christian Huitema <[email-masked]>
Date: Wed, 04 Mar 2020 21:49:26 -0800

What are the required attackers capabilities in order to mount this attack? Clearly, it can be mounted by a MITM, but MITM can do a lot of creative damage during the initial handshake. Can it be mounted by a Man-on-the-side?

In QUIC V1, we understand that authentication only starts when keys are exchanged. The connection-id attack appears to cause the connection to fail because connection IDs are authenticated in 1-RTT packets. That's bad, but there are many ways for MITM to interfere with the connection set up and cause the connection to fail at 1RTT. Do we really want to do something specific about the connection ID? Isn't that an example of piecemeal solutions that make the design complex without blocking all the holes?

We know the general outline of a stronger solution. It is presented in the authenticated handshake draft: derive a secret from the ESNI key of the server, use that secret to authenticate all initial packets. Doing that will suppress not just the connection ID attack, but also the whole class of "attacks by messing up with initial packets". I would much rather authenticate the handshake that pile up piecemeal solutions.

The working group has decided to push the authenticated handshake work to V2, and to accept that there may be DOS attacks during the initial handshake. Is the connection ID attack so special that we need to delay V1 for it?

-- 
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/3439#issuecomment-595041061

---

From: David Schinazi <[email-masked]>
Date: Wed, 04 Mar 2020 22:14:56 -0800

In the design of Google QUIC, the client picks a random connection ID, and the server uses that. (BTW that's why it's called a connection ID, it's a unique identifier that has a one-to-one mapping with one connection...) What that means in practice is that the client uses randomness to generate the connection ID, the load balancer maps that to a given server, and using the same connection ID for the duration of the connection makes sure that all packets reach the same server. So far we've kept this design for our implementation of IETF drafts. We understand that some server deployments may want to have the server pick its connection ID, but so far we don't see the value in that outweighing the added complexity. Today we do not yet have a good mechanism for a server to ask the load balancer for more connection IDs that will map to it. We have some hacks that we can perform, but I don't think those hacks will work for the first connection that a server receives. So if this becomes required, we'll have to build the load balancer protocol before we can deploy the new draft.

-- 
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/3439#issuecomment-595047944

---

From: Martin Thomson <[email-masked]>
Date: Wed, 04 Mar 2020 22:31:59 -0800

@DavidSchinazi,

> I'm not sure we should be discouraging servers from using client-generated connection IDs. We've been doing that for years and I'm not sure there is a credible attack here.

The problem is not with what you are doing, but a consequence of adding Retry to the protocol. In addressing the problems arising from that we can ask servers to make a small sacrifice in terms of requiring them to generate a new connection ID, something they need to know how to do anyway. Or, we can ask clients to conditionally validate server behaviour.

I appreciate that if you have no need to send Retry, this might be an imposition on the server, but from the outside it seems totally doable. I would like to understand less about the strength of your reluctance to offer a new connection ID and more about why it might be difficult to do so.

Is this expensive because you have to consult with load balancers?

-- 
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/3439#issuecomment-595052750

---

From: Martin Thomson <[email-masked]>
Date: Wed, 04 Mar 2020 22:38:11 -0800

@huitema, Though we tolerate denial of service prior to handshake completion, we don't tolerate attacks that alter connection properties. This results in the attacker choosing a connection ID that the client will use after the handshake completes.

-- 
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/3439#issuecomment-595054363

---

From: MikkelFJ <[email-masked]>
Date: Thu, 05 Mar 2020 01:13:54 -0800

There is also an aspect of downgrade attacks to this: If part of a server farm has a flawed deployment, an attacker could use the SCID to route traffic to that part of the server farm and take advantage of that until the entire fleet has been upgraded.

-- 
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/3439#issuecomment-595114781

---

From: MikkelFJ <[email-masked]>
Date: Thu, 05 Mar 2020 01:24:17 -0800

@DavidSchinazi you did not mention how the Google LB does the CID mapping, but if is hashed based rather than stateful, an attacker might be able to overload a single server og subset of servers, no? And if it is stateful, you have a lot of coordination with fail-overs and offloads?

-- 
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/3439#issuecomment-595119980

---

From: MikkelFJ <[email-masked]>
Date: Thu, 05 Mar 2020 01:32:20 -0800

@martinthomson quote " Or, we can ask clients to conditionally validate server behaviour."
I don't think we can rely on clients validating server chosen CIDs . My intuition tells me that rogue or careless clients might compromise server infrastructure.

@marten-seemann I like the idea of keeping the state in the handshake and avoid a TP for that. However, I suspect that a server choosing a new CID from a Retry might move traffic to a separate server in choosing that CID so you cannot remember if the resulting server was indeed the intended server. I'm a bit vague on this, so I might be mistaken.

-- 
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/3439#issuecomment-595124046

---

From: Christian Huitema <[email-masked]>
Date: Thu, 05 Mar 2020 08:36:14 -0800

If we are to fix this, my choice would be to document the issue and observe that servers can fix it by tying the retry token to their proposed CID. That would implicitly solve Google's issue.

-- 
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/3439#issuecomment-595324141

---

From: martinduke <[email-masked]>
Date: Thu, 05 Mar 2020 09:17:20 -0800

While I'm inclined to support @huitema's statements on this, note that dictating the Initial DCID also dictates the Initial Keys, whether or not the server subsequenty changes. This could reduce the cost of sniffing Initial packets, for what it's worth.

-- 
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/3439#issuecomment-595345456

---

From: Antoine Delignat-Lavaud <[email-masked]>
Date: Thu, 05 Mar 2020 09:46:52 -0800

> @marten-seemann suggests that forcing a change of connection ID at the server (always? only when there is no Retry?) would be sufficient because all an endpoint needs to do is ensure that the choic…

It seems a bit brittle to me, for instance it doesn't prevent post-retry adversarial forwarding to a different server with the same token key, which could be used for downgrade as @mikkelfj pointed out. It would play out like this:

```
C->S1 INIT[dcid=X]
S1->A RETRY[token=T,scid=X']
A->S2 INIT[dcid=X]
S2->A RETRY[token=T',scid=Y]
A->C RETRY[token=T, scid=Y]
C->S1 INIT[dcid=Y, token=T] ...
```
That's not a very strong attack by any means but still makes me somewhat uncomfortable.

> If we are to fix this, my choice would be to document the issue and observe that servers can fix it by tying the retry token to their proposed CID. That would implicitly solve Google's issue.

That is also kind of OK but difficult to specify as a requirement - how would implementers interpret something like "you must bind the retry token to the proposed CID"? In practice, they should do something like use the CID as part of the nonce of the ticket encryption, or store it in the stateful token database. Unsurprisingly, I much prefer a mechanism that cryptographically guarantees that the CID is authentic because there is no way for a honest and compliant client to know if the server implements the correct check (the same argument as for the use of the client 1-RTT key before checking the client finished)

-- 
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/3439#issuecomment-595358978

---

From: martinduke <[email-masked]>
Date: Thu, 05 Mar 2020 09:55:41 -0800

After skimming the paper and reading MT's justification a few times, I guess I am still unclear on the threat model:

1) Attacker rewrites the SCID of a Retry Packet. This affects the Initial Keys and can't be protected by the TP. Server acceptance of the provided CID is a pretty good indication it doesn't much care, in which case, meh. If someone picking a CID will take your site down, change the CID!

If we must do something here, perhaps we should just say "servers MUST change their CID if they are sending an ODCID TP?" -- this would make it easier for Google and minimize the change otherwise.

But really the answer is to put in the token. It's the only way to definitively kill the connection if a MITM is messing with us, and solves the Initial-Key problem.

2) Attacker rewrites the SCID of server initial. Doesn't Section 5.2 mean that the server would simply discard the remaining Client packets? Doesn't this obviate the need for the TP? I guess the MITM could successfully rewrite to the original client-chosen DCID, but presumably servers are written to limit the ability of clients or MITMs to just ignore the new CID?

-- 
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/3439#issuecomment-595362807

---

From: David Schinazi <[email-masked]>
Date: Thu, 05 Mar 2020 10:37:28 -0800

Speaking in terms of design principles, [the triple handshake attack](https://mitls.org/downloads/tlsauth.pdf) has taught us that pretty much anything that doesn't land in the key schedule can be abused by an attacker that makes each endpoint think it has a different value. Specifically to QUIC, everything going on in the CRYPTO stream lands in the transcript thanks to TLS 1.3, but there are QUIC-specific fields that don't: in particular the connection IDs and version from long headers. To protect the version, we have [draft-ietf-quic-version-negotiation](https://tools.ietf.org/html/draft-ietf-quic-version-negotiation), but we don't have anything for the Source CID. Therefore I'm supportive of adding a transport parameter that makes sure that it lands in the transcript.

On the other hand, requiring the server to always replace the client-chosen initial destination CID does not provide any security benefits in and of itself. There's nothing preventing the server from determining its replacement CID deterministically from the client-chosen one, for example.

This change would be non-trivial for the Google deployment because, unlike migration, it needs to happen synchronously when establishing the connection. If your communication with load balancers is asynchronous, you can delay sending NEW_CONNECTION_ID frames for migration until you've received enough connection IDs from your load balancer, but delaying the response to a client's initial has a performance cost that we're not willing to pay.

-- 
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/3439#issuecomment-595382011

---

From: Martin Thomson <[email-masked]>
Date: Thu, 05 Mar 2020 13:00:14 -0800

@DavidSchinazi, from this I infer that pre-caching values is not feasible.  Perhaps your load balancers integrate the client address in their decisions.  Is that right?

An alternative is to alter the ODCID transport parameter to integrate the SCID from the Retry.  Another would be to require that the server perform a check based on the Retry token (as mentioned).

-- 
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/3439#issuecomment-595444044

---

From: Christian Huitema <[email-masked]>
Date: Thu, 05 Mar 2020 13:39:02 -0800

I am trying to wrap my head around the "transport parameters" proposal. I am looking at the sequence of the attack:

1) Client sends an Initial packet with a specific DCID (later referred to as ODCID)
2) Server sends a retry packet in which the DCID copies the original SCID of the client, and the SCID is set to the value that the server wants the client to use as the next DCID -- calling this Retry-CID
3) Attacker intercepts the retry packet, replaces the DCID by A-CID.
4) Client starts a new connection with DCID = A-CID instead of the expected Retry-CID, which possibly opens the possibility of attacks against the server, such as paying games with the load balancer.
5) Client includes some new transport parameters in Initial packets
6) Attacker possibly intercepts the client packet and messes with the transport parameters.

At that point, we have different outcomes based on the defenses implemented by the server:

a) If the server has tied the Retry-CID and the ODCID to the token, the server finds that the incoming client Initial does not meet expectations, and closes the connection with an adequate error code.

b) If the server did not do (a), the server will start establishing the connection, sending the server transport parameters as part of the encrypted extensions, in Handshake packets. The transport parameters include the ODCID. If I understand the proposal correctly, the transport parameters would also include the Retry-CID. The client would then receive these parameters, find out that something is amiss, and close the connection.

Given these two choices, it seems that option (a) is much better. The Retry mechanism is designed for use under attack. In these scenarios, it is important to minimize the amount of work at the server. If the server has tied Retry-CID to the token, the session is terminated upon the first initial packet, which seems like the desired result. If not doing that, the server will expand resource to compute session keys, signatures, etc., which means that the DOS attack is more effective.

I also think that the server should not rely on the client for protection. The ODCID transport parameter and the proposed Retry-CID parameter allow the client to verify that things are as expected. But suppose for a moment that the attacker is the client itself, and that the goal of the attack is to overwhelm a specific server in the farm by using well chosen DCID. The "attacker-client" will certainly not terminate the connection on Retry-CID mismatch!

Then, I also wonder how servers would implement the Retry-CID transport parameter. It seems that currently many servers implement the ODCID requirement by encoding the ODCID in the token. I assume that server will implement the Retry-CID either by using algorithmic derivation of Retry-CID from ODCID, or by adding the Retry-CID to the token. In both cases, they can implement option (a). 

So in practice, there is little incremental work for a server if it wants to do (a) rather than (b), and there are sizable benefits in terms of reduced DoS surface. The recommendation ought to be, do (a). Now, if servers actually do (a), they will have no problem also sending a Retry-CID transport parameter in the "all clear" case. But that will not be very useful.

-- 
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/3439#issuecomment-595460613

---

From: Martin Thomson <[email-masked]>
Date: Thu, 05 Mar 2020 15:42:52 -0800

The problem is not having a server protect itself, that's fine.  The client has a stake in this also.  It remains ignorant of whether the server has these protections.

-- 
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/3439#issuecomment-595469280

---

From: Christian Huitema <[email-masked]>
Date: Thu, 05 Mar 2020 16:13:15 -0800

@martinthomson it seems that we have agreement on two points a bit of discussion on the third:

1) The spec should describe the "munged retry" attack. It can be used to play games with server farms, either by attackers in the middle, or by attackers as client. It can produce a DOS attack of some sort despite the "retry" protection mechanisms.

2) The spec should describe how servers can protect themselves by tying the "Retry-CID" to the retry token, and in fact recommend that they do that.

3) Adding "retry-CID" as a transport parameter would give assurance to clients that the server is protected against the attack, and allow clients to detect attacks if the server is not protected.

I am not sure that (3) is really needed. I do not really understand the client stake there, except in the general terms of defeating attackers in the middle and encouraging good server implementations. OTOH, if the server does (2), it is not very onerous to also do (3).

But then, what prevents servers that do not care from taking shortcuts, not verify the token, and copy any incoming post-retry DCID in the transport parameter?

-- 
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/3439#issuecomment-595508210

---

From: Martin Thomson <[email-masked]>
Date: Thu, 05 Mar 2020 16:43:13 -0800

I am similarly unconvinced by having that in a transport parameter.  That's why the PR currently doesn't include that.  As you say, it's pretty easy to game.  That's why I prefer the changing connection ID.  That at least has a hope of being enforced.

-- 
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/3439#issuecomment-595518051

---

From: MikkelFJ <[email-masked]>
Date: Thu, 05 Mar 2020 23:46:45 -0800

I think @huitema makes a lot of good points. However, tying ODCID to retry-CID could make the production DCID longer than is desirable.

Another option might be to have an additional authentication tag (AAT) in the handshake packets that is carried along similar to TP, but not necessarily inside the TP machinery. The server or LB could check the AAT at high DoS load without forcing the CID to be long and it could cover other critical parameters as well.

If the client needs similar assurances it cannot use th AAT directly to do its own checking, but philosophically, the server decides the CIDs going towards the server, and it is the servers responsible to design and check those CIDs with reasonable security bounds for the given deployment. If a server does not check for retry attack CIDs, there are many other things that it might also not check making the connection flawed in some way.

-- 
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/3439#issuecomment-595644526

---

From: Antoine Delignat-Lavaud <[email-masked]>
Date: Fri, 06 Mar 2020 02:21:51 -0800

> If the client needs similar assurances it cannot use th AAT directly to do its own checking, but philosophically, the server decides the CIDs going towards the server, and it is the servers respons…

I disagree, there are not many other things that the client and server can disagree on after the end of the TLS handshake. The idea to consider connection IDs as an unauthenticated connection parameter (just like the IP address and UDP port) that can be used by networking middlebox for DoS/routing is fine, and it's a possible way to close this discussion, but I urge you to carefully consider the privacy impact for the client. It is somewhat pointless to write a formal proof of packet number encryption if it turns out that an active adversary can inject a 20-byte long unique identifier that appears in the cleartext of every packet - imagine if China starts doing that to tag incoming QUIC connections to users, if many servers allow them to (expecting their own middleboxes to do the same thing for legitimate reasons). Of course it is already possible to do that with TCP, but QUIC CIDs are much longer than TCP ports and can be use for pervasive monitoring at a fine granularity. If CIDs are truly negotiated between the client and server, the client has the guarantee that the server CID really comes from the server, and knows that no tracking CID has been inserted on the way. 

-- 
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/3439#issuecomment-595702363

---

From: martinduke <[email-masked]>
Date: Fri, 06 Mar 2020 10:44:33 -0800

I am still wondering why "servers MUST propose a new connection ID in the server Initial if they are going to include an ODCID TP" is insufficient.

I believe it solves the Retry case and doesn't create problems for Google. If the MITM is rewriting SCID on server Initials, doesn't this break the connection anyway?

-- 
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/3439#issuecomment-595905744

---

From: MikkelFJ <[email-masked]>
Date: Fri, 06 Mar 2020 12:53:38 -0800

It's been a while, but I'm wondering if this issue relates to old issue regarding 0-RTT DCID attacks that was moved to quicv2: https://github.com/quicwg/base-drafts/issues/2398

-- 
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/3439#issuecomment-595960758