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 <[email protected]>
Sent: Thursday, October 24, 2024 11:29 AM
To: Barry Leiba <[email protected]>
Cc: [email protected] <[email protected]>; [email protected] 
<[email protected]>; [email protected] 
<[email protected]>; [email protected] <[email protected]>
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 
<[email protected]<mailto:[email protected]>> 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 -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to 
[email protected]<mailto:[email protected]>
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to