Browsers are not a concern as they already have their own comp/decomp
codes. HTTP/1 can compress content (Content-encoding and
transfer-encoding) and HTTP2 has additional header compression.
Regards,
Roland
Am 02.10.2015 um 15:08 schrieb takamichi saito:
Do we know how many protocols currently suffer from CRIME?
Maybe a best practice could be suggested by UTA for the implementation of TLS
in software, to disable compression if vulnerable. And for the others, to
implement a way to enable/disable compression in case one day a vulnerability
is found.
I agree.
Again,
1) We know CRIME threat, but it can not be risk for everyone.
e.g., CVSS v2 Base Score: 2.6 (LOW)
2) If we need to have comp/decomp in an application layer,
clients such like browser need their own comp/decomp codes.
3) If there is no comp in tls1.3, some people may continue to use tls1.2.
Which one is safer, "tls1.2" v.s. "tls1.3 with comp/decomp" ?
That's why we explore the way to keep compression in TLSv1.3.
How about making an option only in server-side?
The spec has the compression but default is off, and also provides the
suggestion.
--
Julien ÉLIE
« La vraie valeur d'un homme se mesure lorsqu'il a tout perdu. »
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
;; takamixhi saito
c2xhYWlidHNvcw
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
