On Thursday, 12 December 2019 21:55:42 CET, Nick Harper wrote:
On Thu, Dec 12, 2019 at 8:27 AM Hubert Kario <hka...@redhat.com> wrote:
On Thursday, 12 December 2019 16:50:45 CET, David Benjamin wrote:
On Thu, Dec 12, 2019 at 6:51 AM Hubert Kario <hka...@redhat.com> wrote:
...
so because Google decided one thing, everybody has to bow down to it?
and, sorry, but I consider the privacy angle a red herring,
nobody is doing
proper AppData padding, so the connections leak privacy information in TLS
1.3
like a sieve too
Privacy isn't a red herring.
it is in discussion about signature mechanisms supported by legacy hardware
There's a big difference between leaking
ciphertext lengths vs leaking the user's name, email address, and other PII
present in a client cert when the client cert is sent in the clear.
which can be workarounded by doing client authentication in renegotiation
handshake, the feature is there in the protocol, it's not IETF fault that
some people decided to remove support for it
...
An HTTP/2 client speaks as soon as the handshake completes
and does not ...
know
whether the server is going to do this.
if privacy was so important why nobody worked on it with HTTP/2? It's not
like
much has changed in the last 4 years on that front.
HTTP/2 couldn't fix the issue with TLS 1.2 client certs being sent in the
clear,
again, renegotiation
but that problem was solved in TLS 1.3. Many of the problems not
solved by H2 are being worked on in QUIC. It takes time to develop and
deploy these protocols.
and which part of QUIC addresses length hiding? Because either privacy is
important, and it should be addressed by it, or mentioning privacy here is
a red
herring.
Don't let perfect be the enemy of good.
no, it's not a question of "perfect" or "good", it's a question of putting
legacy stuff in modern protocol or keeping it in legacy protocol, where its
use is obvious and easy to audit.
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
