[gnutls-devel] removing compression

[Peter Williams]

Ssl record layer has no notion of trusted and trusted payloads.

The cipher suite controlling which security services are applied to which payload is given an implied security label , which implicitely tags the resultant bytes. The label is a function of the labels within the end point certs (and their chains).

This has not changed since ssl v3, and its fortezza support (fortezza certs has securty labels in the public key byte block).

In a military datacenter that strips the tls at a front end processor, the (recomputed) tag (from the coearyext handshake) indicates which vlan (segmented trust level) the payloads may travel, now as TCP fragment.

On the vlan, per vlan security services are applied including the mac-layer equivalent of ipsec packet tagging of the security label. Per vlan encryption and compression may be applied.

The stuff about compression is a red herring.

That security services bundled as assurance classes of cipher suites  must be properly be tied to their intended operating theatre (web vs the stuff above) is obvious.



Sent from my iPhone

> On Jun 7, 2017, at 7:36 AM, Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:
> 
>> On Tue 2017-06-06 18:21:24 +0200, Nikos Mavrogiannopoulos wrote:
>> As I dig into TLS 1.3 support where compression is no longer
>> supported, I realized that keeping compression for TLS 1.2 or earlier
>> would only cause problems by making complex code even more
>> complicated. As TLS compression is already considered insecure, I
>> would like to drop that support completely (an MR is at [0]), unless
>> there are serious objections. If none, I'll merge that removal by the
>> end of this month.
> 
> I support this change.  Application protocols that want to compress can
> do it in the application layer, where they have some hope of avoiding
> compression that mixes untrusted data with trusted data (see the recent
> work on improving NNTP over TLS).  Uniform compression over the entire
> stream just doesn't make sense from a security standpoint, and it makes
> for a security toolkit to put that kind of footgun out of reach of
> casual users.
> 
> Thanks for making this change,
> 
>         --dkg
> _______________________________________________
> Gnutls-devel mailing list
> Gnutls-devel at lists.gnutls.org
> http://lists.gnupg.org/mailman/listinfo/gnutls-devel