On Fri, Sep 18, 2020 at 3:12 PM Michael Richardson <mcr+i...@sandelman.ca> wrote:
> > 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?) > There are actually two things here: 1. Changing the version system -- this was done mostly to accommodate broken servers. 2. Compatibility mode (hiding the HRR, fake CCS, etc.) -- this was designed to work around broken middleboxes. We can call them stupid, or we can try to understand their point of view, > and > try to help them be less stupid. > I don't believe that my note calls them stupid. In any case, ISTM that the design principle that both 1.3 and QUIC have converged on is to opaque-ify as much of the handshake as possible, thus discouraging passive protocol enforcement of this kind. 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? > I think it's quite likely that that language would have to be Turing-complete. I note that the current language is already very complicated and yet insufficiently rich. > 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. > Perhaps you mean some hypothetical TLS 1.4? There is already very widespread deployment of TLS 1.3 for HTTPS and blocking it would cause breakage of a large number of sites. Perhaps you could safely do it for non-443 ports... > 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. Sorry, yes. I meant "client" in the sense that the client tells the middlebox what rules to use. Whether it does so directly or by reference to the manufacturer doesn't seem to matter too much for these purposes. > The idea of having a WASM file is an > interesting one, but being an executable of a sort, it has other security > problems. > Well, one always has to worry about the security of processing data one receives from the network, but I'm not sure that the distinction between the kind of DSL we're talking about here and an executable is really that sharp. The argument for WASM or something like it is that there has already been enormous investment in building sandboxed interpreters for it, so one gets to inherit all of that effort. This is not, of course, to say that the WASM sandbox will never have vulnerabilities,but one can generally not say that about any software. -Ekr
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
