Re: [OPSAWG] [TLS] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls

[Michael Richardson <[e-mail]>]

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  [ 
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [