Thanks for noticing the example.net error. Fixed! [1]. I think we made that a SHOULD for contrast with the requirement that the server prove authority for public_name. If the server isn't authoritative for public_name, the connection will fail completely, so that's a MUST. If the server has the wrong TLS version, the client will degrade gracefully to a non-ECH connection mode, which is arguably tolerable.
--Ben [1] https://github.com/tlswg/draft-ietf-tls-svcb-ech/commit/4c70e781eb3bb9f05354f54fa1337131f823b96e ________________________________ From: Eric Rescorla <e...@rtfm.com> Sent: Thursday, October 24, 2024 11:29 AM To: Barry Leiba <barryle...@computer.org> Cc: a...@ietf.org <a...@ietf.org>; draft-ietf-tls-svcb-ech....@ietf.org <draft-ietf-tls-svcb-ech....@ietf.org>; last-c...@ietf.org <last-c...@ietf.org>; tls@ietf.org <tls@ietf.org> Subject: Re: [Last-Call] Artart last call review of draft-ietf-tls-svcb-ech-06 I don't think a MUST would be totally inappropriate but it's possible to get into a state where you have a mismatch due to DNS latency or partial rollback, so this MUST will be violated in practice in some cases (though as you indicate, I don't think a MUST would be totally inappropriate but it's possible to get into a state where you have a mismatch due to DNS latency or partial rollback, so this MUST will be violated in practice in some cases (though as you indicate, that's not good). ECH has a way to recover from these conditions, -Ekr On Wed, Oct 23, 2024 at 9:45 AM Barry Leiba via Datatracker <nore...@ietf.org<mailto:nore...@ietf.org>> wrote: Reviewer: Barry Leiba Review result: Ready with Nits Just two small comments on this straightforward document: — Section 3 — Figure 1: ECH SvcParam with a public_name of "ech-sites.example.com<https://urldefense.com/v3/__http://ech-sites.example.com__;!!Bt8RZUm9aw!7N3lwQCYnfSSk25u72uXiwlbbRvzEaIwwcmhT9pKQX44NsjwAPcLMZTmY0E-jhxpYqGH$>" The example actually encodes example.net<https://urldefense.com/v3/__http://example.net__;!!Bt8RZUm9aw!7N3lwQCYnfSSk25u72uXiwlbbRvzEaIwwcmhT9pKQX44NsjwAPcLMZTmY0E-jrK7WVYr$>, not example.com<https://urldefense.com/v3/__http://example.com__;!!Bt8RZUm9aw!7N3lwQCYnfSSk25u72uXiwlbbRvzEaIwwcmhT9pKQX44NsjwAPcLMZTmY0E-jjW9okIA$> [This was a test to see if we check these things, right? :-) ] — Section 4 — These servers SHOULD support a protocol version that is compatible with ECH. Why is this not a MUST? What might be a reason to publish an ECH record for a server that doesn’t support ECH? -- last-call mailing list -- last-c...@ietf.org<mailto:last-c...@ietf.org> To unsubscribe send an email to last-call-le...@ietf.org<mailto:last-call-le...@ietf.org>
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
