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. 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. -Ekr > Thanks, > S. > > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
