Re: [TLS] Enforcing Protocol Invariants

[Ryan Carboni <[e-mail]>]

I think I have implied that ClientHello is unneccesary to an extent, it can
be replaced by a DNS TXT record.

I think I implied that self-signed certificates are acceptable given the
precedent of Let’s Encrypt and the use of DNSSEC (has there been evidence
of DNS spoofing attacks against a CA?).

I think my suggestion has the implication that protocol negotiation is
unnecessary, although it can be kept.

I think my suggestion would have automatic backwards compatibility. A TLS
1.2-only client (likely to be found in regulated sectors that requires
middlebox inspection and decryption) would attempt to connect using port
443, while my proposed protocol would attempt to look up using DNS first to
obtain DNS records relevant. By using separate ports for each new protocol,
it maintains a greater level of cross-compatibility and allows for future
development.

These compounded extensions make the protocol less secure by making it
harder to implement, particularly given the recent spate of attacks against
unintuitively implemented state machines for key negotiation.

The entire protocol should be removed and replaced by something far simpler.

Is this sufficiently specific?

I hope in the future, the IETF TLS working group will reach out to
middlebox designers to understand what they are exactly doing to TLS so
that these things won’t be unexpected.

I must also say that CBC isn’t bad, as long as the padding is considered to
be part of the message to be authenticated.

On Thursday, November 8, 2018, Salz, Rich <[e-mail]> wrote:

> *>*Hmm. TLS has gotten too complex.
>
>
>
> What makes you say that?  Please be specific about what you think should
> be taken out.
>
>
>