I'm going to briefly respond, but as this is a public holiday and I have no real desire to work too much, please forgive any radio silence that follows.
On Fri, Apr 2, 2021, at 05:56, David Benjamin wrote: > This was a previous attempt at this, but it seems to have been confusing. > > I do agree that having ClientHelloInner vs ClientHelloOuter differences > that result in different HelloRetryRequest acceptance criteria is a bad > plan: in general, I think a client implementation should be judicious > about which difference it exposes because each difference needs special > logic to make sure it's using the right set as you evaluate the > handshake. > > At the same time, I worry that *mandating* it in the extension will > make this decision process tricky to navigate and get us in a rough > corner. PR #316 was trying to capture exactly this, but it seems we > didn't get on the same page. (Maybe we can now?) See this discussion: > https://github.com/tlswg/draft-ietf-tls-esni/pull/316#discussion_r509880007 My claim (to be verified) is that mandating something is possible. It might not require a simple rule (cannot be different); it might instead require that each extension be analyzed and have its own rules instead. I'm confident that for the 4 or so extensions that can change in response to HRR, we can make that work. > > The draft currently allows inner and outer ClientHello to have different > > types of key share. The way it handles this is terrible: it recommends > > breaking the transcript. To me, that seems like it would only serve to > > open the protocol up to downgrade attack. > > I'm not sure I follow this point. Do you mean the draft as-is, or the > PR? I don't believe the draft as-is does, and I don't think the PR does > anything to the transcript that draft as-is doesn't already do. The > transcript behaviors are largely forced by a combination of backwards > compatibility for ClientHelloOuter and split mode for ClientHelloInner. I refer to this, which I would propose be cut: > Note: if ClientHelloOuter and ClientHelloInner use different groups for their > key shares or differ in some other way, then the HelloRetryRequest may > actually be invalid for one or the other ClientHello, in which case a fresh > ClientHello MUST be generated, ignoring the instructions in > HelloRetryRequest. -- https://tlswg.org/draft-ietf-tls-esni/draft-ietf-tls-esni.html#section-6.1.4-4 > I think you may have misunderstood #333. That or I'm misunderstanding > your response. Imagine a client-facing server that wants to support HRR > statelessly. When that client-facing server accepts ECH and gets an HRR > from the backend server to forward, it has no opportunity to inject its > own cookie. Yeah, I missed that distinction. Let's not support that. If the client-facing server wants to forward AND use the cookie to route the second ClientHello without maintaining state, let it coordinate with the hidden server. > In terms of sticking out, Ben Schwartz also pointed out another issue > with the current situation. It's not just that, where HelloRetryRequest > occurs naturally, this quirk reveals GREASE. A forged HelloRetryRequest > also reveals GREASE. This PR resolves this by authenticating the ECH > acceptance signal in HelloRetryRequest. Yeah, that leaks that grease happened. We can thank those who were overzealous in their interpretation of the rules in RFC 8446. Either way, this style of attack doesn't really bother me that much as it is very obvious and requires active interception. > I'd be very interested to understand the architectural constraints > here. This didn't seem likely to be particularly challenging to > implement, but I only know our own stack and certainly could have > mispredicted. As I said in the meeting. HRR only has limited battle testing in practice, this would be even less tested, but far more complex. Anything we can do to limit complexity, even at the cost of more complex analysis, is worth doing in my opinion. There is only one analysis we need to do for the specification, but (hopefully) multiple implementations. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
