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 <ekr@xxxxxxxx>
Sent: Thursday, October 24, 2024 11:29 AM To: Barry Leiba <barryleiba@xxxxxxxxxxxx> Cc: art@xxxxxxxx <art@xxxxxxxx>; draft-ietf-tls-svcb-ech.all@xxxxxxxx <draft-ietf-tls-svcb-ech.all@xxxxxxxx>; last-call@xxxxxxxx <last-call@xxxxxxxx>; tls@xxxxxxxx <tls@xxxxxxxx> 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, 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 <noreply@xxxxxxxx> wrote:
Reviewer: Barry Leiba |
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx