Eric Rescorla <e...@rtfm.com> 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 <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
