ekr> Taking a step back from details, ISTM that the whole design of this ekr> document is antithetical to extensibility:
I agree. It was my first reaction as well. I then had another thought: there are dozens of entities out there that want to do this regardless, enough that it broke the TLS version system requiring the hack. (Does that hack have a name?) We can call them stupid, or we can try to understand their point of view, and try to help them be less stupid. ekr> TLS is a protocol with a number of extension points. What this document ekr> does is allow an endpoint to restrict its use of a certain set of ekr> extension points. However, the language provided here is insufficiently ekr> rich to allow the client to properly describe the use of those ekr> points. assuming that some language could be provided that was sufficiently rich, would your objection continue to stand? ekr> As a concrete example: for extensions the model knows about ekr> (e.g., supported_versions) you can indicate the contents of the ekr> extension, but for extensions the model does not know about (e.g., ECH) ekr> you cannot. That means that you're either stuck with allowing anything ekr> in those extensions (which means that your filtering effectiveness is ekr> reduced) or you don't allow those extensions, in which case you create ossification. ekr> As a thought example, consider a hypothetical TLS 1.4 which decided to ekr> adopt QUIC-style obfuscation of the CH and SH, putting the obfuscated ekr> CH/SH in extensions in a stereotyped outer CH/SH. The system described ekr> here would be unable to do anything useful with that, which creates ekr> pressure to block TLS 1.4 entirely, which obviously is not awesome. I believe that without a mechanism described in this document, many enterprises may conclude that they need to block TLS 1.3. ekr> If we want to pursue this kind of idea -- and I'm not at all sure we ekr> should -- ISTM that rather than trying to invent some new DSL for ekr> filtering TLS we allow the client (who by hypothesis is trusted as to ekr> what it will generate) to provide a general program that the middlebox ekr> can interpret that will describe what it will do. For instance, you ekr> could provide a WASM file which gets fed the CH and just says "this is ekr> me" or "this doesn't look like me". That way we don't need to continue ekr> extending the language here whenever TLS evolves. Note that that doesn't ekr> prohibit having a language like this as a programming convenience, but ekr> it wouldn't restrict the semantics of what you could say about the ekr> connection. We don't have to have the client provide it, it can be encoded by the manufacturer in the MUD file, assuming that it depends upon the model, not some local decision in the client. The idea of having a WASM file is an interesting one, but being an executable of a sort, it has other security problems. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
