On Sat, Jul 5, 2025 at 4:23 PM Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote:
> > Hiya, > > (For clarity, I'm not trying to change the spec at this stage but rather > to understand it better...) > That's helpful to know. On 05/07/2025 15:19, Eric Rescorla wrote: > > On Fri, Jul 4, 2025 at 11:53 AM Stephen Farrell < > stephen.farr...@cs.tcd.ie> > > wrote: > > > >> > >> Hiya, > >> > >> It looks like the following text was added in draft-18: > >> > >> " > >> In split mode, a client-facing server which receives a ClientHello > >> with ECHClientHello.type of inner MUST abort with an > >> "illegal_parameter" alert. Similarly, in split mode, a backend > >> server which receives a ClientHello with ECHClientHello.type of > outer > >> MUST abort with an "illegal_parameter" alert. > >> > >> In shared mode, a server plays both roles, first decrypting the > >> ClientHelloOuter and then using the contents of the > ClientHelloInner. > >> A shared mode server which receives a ClientHello with > >> ECHClientHello.type of inner MUST abort with an "illegal_parameter" > >> alert, because such a ClientHello should never be received directly > >> from the network. > >> " > >> > >> That's not something I included in the implementation I'm trying to > >> upstream to OpenSSL. > >> > >> Two questions: > >> > >> a) does someone recall why these "MUST abort" statements are needed? > >> > > > > As stated in the text, these are illegal conditions so you should be > > rejecting > > them. I don't see a problem with requiring that. > > That's not really responsive as to why these conditions are considered > bad/illegal;-) > Well, the second clause explicitly states why for shared mode. The situation is similar for split mode: the client-facing server only gets connections that have ECH.type == outer and then forwards them to the back-end server with ECH.type == inner, and so the other value won't happen in a conformant setting (modulo your proposed backend/client-facing combination). > > b) have we really got this right? ISTM server code may be processing > >> both inner or outer ClientHello messages and forcing the kinds of > >> distinction envisaged above might be unwieldy > >> > > > > I haven't looked at your code, but ISTM that when processing a CH you > > need to know what kind of CH it is. Otherwise, you end up in weird > > states where you might have multiple layers of nested ECHs. > > Knowing 'what kind' is simple. The problem with reacting as stated in > the quoted text is e.g. that'd require new configuration of servers > that might operate as a backend, when that's not really needed, and > thus create a barrier to deployment. (These conditions change a code > update to a code and config update.) > I'm confused. Backend servers already know they are backend servers, as in S 7.2. The only new code here is that they must reject anything with ECH.type == outer. Another issue is that assuming that "a server" is only one of client- > facing or backend, seems over simplified. > I think that's a reasonable restriction, and in any case, I thought we agreed above we weren't changing the spec. -Ekr
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
