On Tue, Oct 15, 2024 at 7:15 PM Paul Wouters <p...@nohats.ca> wrote:
> On Fri, 11 Oct 2024, Eric Rescorla wrote: > > > Thanks you for your review. I have created a PR that addresses a number > of these. > > > > https://github.com/tlswg/draft-ietf-tls-esni/pull/632 > > That looks fine, other than the accidental typo introduction I pointed out. > > [ deleted agreements, thanks for proposed changes ] > > > > Section 4.2 > > > > > > See Appendix A for guidance on which types of extensions are > appropriate for this structure. > > > > > > If this is guidance, then it probably does not belong in an appendix, > but in its own real Section ? > > > Also, since Appendix A is a single paragraph, why not just fold it in > right here? > > > > I think this is a taste issue, so I'm comfortable leaving it where it > > is, but if you insist, I will change it. > > I won't insist, but it does seem better. Both to avoid one-paragraph > appendix sections, as well as spending a whole sentence to point to > a meagre one appendix paragraph. But not my hill. > Thanks. I'll take another look before I publish the next version and see if there is something I think is worth doing. > > Section 10 > > > > > > Downgrade resistance - makes me think of the tls-dnssec pin discussion > :-) > > > > > > If the HPKE private key is lost and replaced, and the ECH DNS entries > are being > > > updated, there is a time period (depending on TTL and cache) where the > tls client > > > connecting to the client-facing TLS server will not be able to > distinguish the > > > connection from an attack, and thus not downgrade to try without ECH. > This is an > > > outage. Unfortunately, DoH has no way of asking a "refreshed DNS > record" to get > > > its DoH server to drop the cached record. I guess the SVCB/HTTPS > record could > > > introduce a syntax with a prefix on the old keyid or something with an > explicit > > > signal that points to the updated (uncached because it only exists > when such an > > > outage appears). But this might be a bit complicated for a failure > case. It is probably > > > best to postpone such work until it shows to be needed in practice. > > > > I don't think I follow the scenario you have in mind here. > > > > Suppose that the server was using key A and publishes an appropriate > > record. It then loses the key and starts using B. If a client comes > > in using key A, the server is supposed to follow the ECH configuration > > correction procedure in S 6.1.6 and provide a retry configuration with > > key B. The client will then retry with B. This isn't an outage, though > > it has a negative performance impact, which is why it's best to have > > keys overlap. > > I am confused how this can happen "securely" if the only way to prove > this is not a malicious attack is to use the private key that was lost? > > I guess I am confused about: > > If the server provided "retry_configs" and if at least one of the > values contains a version supported by the client, the client > can regard the ECH keys as securely replaced by the server. It > SHOULD retry the handshake with a new transport connection, > using the retry configurations supplied by the server. > > The retry_configs contain ECHConfigList. The ECHConfigList contains > ECHConfig structures which it clains "allows a server to support multiple > versions of ECH and multiple sets of ECH parameters". > > But either these are confirmed by key A, which was lost, or these are > indistinguishable from an attacker pretending to have lost key A and > accepted? I must be missing something here? > I think so, but probably because the technical situation is confusing and the document is doing a bad job of explaining it. The way that recovery works in ECH is that the "public name" in the ECH corresponds to a domain name that the client-facing server controls and has a certificate for. So, if the server has forgotten HPKE key A it completes the handshake using the key corresponding to the public name and then inside that handshake provides the new ECHConfig with key B. So it's true that an attacker can pretend to have lost key A but what they can't do is complete the handshake with the public name. It's of course true that an attacker who controls DNS could provide their own ECHConfig with their own public name, but in that case they could also provide their own HPKE key. Does that help? Assuming you believe this works technically, I can see if I can make the writing clearer. OTOH, if you think this doesn't work technically then let's talk about that :) > > > > > > Section 10.10.2 > > > > > > I do not understand this section. I think it is trying to say "dont > share > > > the secrets with too many operators", and not "don't share this secret > > > with many servers/domain under the same administrative control" ? But > > > it reads like it is recommending that an operator uses multiple smaller > > > ECH groups preferably over less but bigger groups? > > > > I am also struggling with this text. Maybe some other author can help > > explain what this is trying to say? > > I feel a little better now :) > > > > How does a client know which public names the server does not respond > to? > > > > The client doesn't know. It ignores these configurations > > I think the context was that the client is told it should use an invalid > public name, one it "knows" the server isn't authoritative for. But > to know what it is not authoritative for, it needs to know what it is > authoritative for, or it needs to use a clearly invalid name. If it > picks a random valid syntax domain (to avoid needing to get a list of > all authoritative domains here), eg "sfkjgldsagakdga.com", it cannot know > if server1.cloudflare.com happens to be also authoritative for that. It > is unlikely, but not guaranteed. It could instead pick something like > sfkjgldsagakdga.invalid, which is guaranteed to not be a real DNS name > as per RFC2606. > > My point was to perhaps give good advise about how to create such > invalid domains. > I think this is a good idea, but I want to note that the server is responsible for creating these names, not the client, so the server hopefully knows what it doesn't respond to. -Ekr >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
