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 <rs...@akamai.com> wrote: > *>*Hmm. TLS has gotten too complex. > > > > What makes you say that? Please be specific about what you think should > be taken out. > > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
