On Sat, Sep 19, 2020 at 3:07 PM Michael Richardson <mcr+i...@sandelman.ca>
wrote:

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

Can you say more about this? While during previous transitions clients
would "fall back" to lower versions of TLS, both Chrome and Firefox (and I
imagine Edge and Safari but I have less information) do not do so. As a
result any middlebox which blocks 1.3 will effectively cause failures on
any site which offers 1.3, which seems like it would cause a lot of
problems.


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

Agreed. I know BPF less well but my understanding is that it has gotten
quite powerful.

-Ekr
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Reply via email to