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

[Michael Richardson <[e-mail]>]

Eric Rescorla <[e-mail]> wrote:
    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?

No, I do mean 1.3.   Many enterprises still think that they can stop it.
Are they winning? probably not.

    >> 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.

okay.

    >> 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

Such as DSL would have to limit the number of cycles it is allowed to
consume, otherwise the middle box might have to solve the halting problem :-)
BPF could be another model.



--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide