Bit more text on nominal backend processing

[sftcd]

A description of handling this case seemed to be missing as I read through the draft. (It may be stated later, not sure, if so I'll close this.)

This does raise the knotty issue of protecting the ClientHelloInner between the client-facing server and backend, but I guess the best can say for now is just that we're not defining protocol for that here/now.

[davidben]

I think it's already in here, but the draft certainly could do with an editorial pass to make this clearer. (I made an attempt to clean up some of the client earlier, but I didn't get to the server.) The text is kinda scattered all over the place. Here's my read:

• If you're a server, the Server Behavior section applies to you
• If you see type inner, that section says to jump to the Backend Server section
• That section says you do the accept_confirmation thingy, but otherwise doesn't modify the handshake.

It is likely the case that, as you say, you got something from a client-facing server. Although it's also possible the client decided to send you the extension for no particularly coherent reason. Folks wanted Split Mode to work without direct client-facing/backend coordination, so... okay we all that. :-)

[sftcd]

Yeah, I'll just close this if it turns out not needed but in a linear reading, it seemed missing.

WRT seeing inner as a backend (or ech_is_inner in my draft-10 code) - for the split mode backend I ended up making it a configuration setting as to whether the server will barf on that or assume it's come from a client-facing server so that'd kinda mean such server instances need to run on their own port maybe, just for tidiness. But I'm not sure what a misbehaving client might win from directly connecting to a backend and pretending to be a client-facing server. One for the security analysis to cover maybe.

[davidben]

By "barf on that", do you mean report an error? I don't believe that is supported by any text in the specification. If you want to make acting as a backend server configurable, the extension should be ignored when off, as is the default with any TLS extension.

[sftcd]

Hiya,

On 05/08/2021 20:26, David Benjamin wrote:

By "barf on that", do you mean report an error?

Would have to look TBH, but I think so, some sort of malformed extensions error or something.

I don't believe that is supported by any text in the specification. If you want to make acting as a backend server configurable, the extension should be ignored when off.

Generally, it is.

But, again for draft-10, I think I generate an error when I encounter ech_is_inner in an outer CH, except if the server is explicitly configured as a split-mode backend. (And I do similarly for outer_extensions when not expected.)

I'd likely do the same for draft-13, generating an error on ECH.type==inner if not configured as a split-mode backend.

But if there's a good reason to accept such, that'd be ok too I think, even if it ought not happen. Is there such a reason?

(I don't think Postel's principle applies when one does know the semantics of an extension and you encounter it when you ought not.)

Cheers, S.

[chris-wood]

I'm not sure this is needed, partly for the reasons @davidben points out. If the backend server doesn't recognize the extension, because it simply doesn't have ECH support or if it's not been enabled, the default posture should probably be to ignore the extension and carry on.

[ekr]

I agree with @chris-wood: "what to do if an extension isn't enabled" is just basic TLS extension semantics.

[chris-wood]

@sftcd given the above, I propose we close that out, unless there's still additional clarification needed or wanted?

[sftcd]

Everyone else seems happy this was covered, so that's fine.