s/to use/to the use/ ?

potato, potahto. Either is OK, but the "the" is probably a more precise form. I'll fix it.

"unknown properties with respect to these properties"?

Suggest:

...that are not known to conform to these requirements.

Clients do not process received application data until the handshake has been completed, even with False Start, so the "Note that" sentence is unnecessary. An HTTP-level INADEQUATE_SECURITY is actually more secure than a TLS-level alert that cancels the handshake w.r.t. downgrade prevention.

OTOH, if the client is the one generating the INADEQUATE_SECURITY and then falling back (which I think no clients should do), then it MUST NOT send the INADEQUATE_SECURITY message until the handshake has completed. That is, don't false start if you detect INADEQUATE_SECURITY.

That second point is the one I wanted to capture. In most cases I'm aware of, it's the client who needs to send the INADEQUATE_SECURITY. It's a pretty screwed up case if the server is generating it.

Well, there's nothing wrong with generating the INADEQUATE_SECURITY, it's the falling back that's the issue here.

Good point. There are actually THREE different things to consider: How the INADEQUATE_SECURITY condition is detected, how INADEQUATE_SECURITY is sent, and whether fallback is done. I agree that false start isn't a factor for when it is safe to send INADEQUATE_SECURITY. However, it is a factor in the detection step, which precedes the sending step. That is, you don't want to detect/save the inadequate security bit for a server unless/until the full handshake has completed; otherwise, you would use that saved bit during your next (fallback) attempt.

To put it more concretely, in the case of NSS, it is OK to save the INADEQUATE_SECURITY bit for a server in the handshake callback, but not in the false start callback or the protocol negotiation callback. OTOH, hopefully you would never get to the handshake callback in the first place, because you really should have killed the connection earlier.

The side-effect of this is that, if one wants to do fallback, one MUST complete the handshake when inadaquate security is detected, instead of terminating the TLS handshake earlier, even though terminating the TLS handshake earlier is the superior thing to do otherwise. That's another reason why explicitly allowing the fallback to HTTP/1.1 here is bad.

I do not think we should offer this style of fallback. It is this line that makes the handshake fragile. This PR now provides a mechanism for fallback in the line 3657. We should not bend over backwards to support weak ciphers - specially if they make the handshake fragile