I was looking at the TLS Working Group Charter. I noticed that confidentiality and integrity of messages for those who desire it are not goals for the group.

Naively, I believe confidentiality and integrity are probably the predominant use cases. There are even folks who [incorrectly] state you get "end-to-end" security with them. Authentication-only (i.e., eNULL) and Encryption-only (i.e., aNULL) are likely not as popular.

Why do the goals lack confidentiality and integrity requirements for parties who want them?

Here's the context: Encryption of TLS 1.3 content type. In the thread, an argument was made to avoid changes that break middleware boxes. Effectively, I think that means don't break interception proxies, don't hinder traffic analysis, and facilitate other methods of attack (cynicism by me).

I thought, boy, that can't be the case. Surely the charter states confidentiality and integrity are security goals, and designing a protocol that subverts them would be a violation of the charter.

  • Do you think this question is on topic? Looks to me like the question isn't about cryptography, but the reasons behind the WG's goals. Anyway, doesn't the "privacy implications" bullet point imply integrity and confidentiality, even if you ignore that those should be the whole purpose of TLS. – otus Jul 28 '14 at 15:34
  • Otus - you're right. I should have taken this to the Security SE. My bad. I've asked a moderator to migrate it. And no, I don't believe the bullet point clearly spells out the goal. Its more of an afterthought. – user29925 Jul 28 '14 at 15:35
  • 1
    jww, you realize that this is an argument about metadata that is not encrypted in current versions of TLS, not attackers decrypting the content, don't you? – Matt Nordhoff Jul 28 '14 at 20:58
  • @Matt - I'm actually not concerned over what and why in this case. I was surprised confidentiality and integrity are not security goals. I was kind of amused that the cited reason, though. – user29925 Jul 28 '14 at 21:07

That "charter" is rather down-to-earth; it does not specify that "TLS should provide confidentiality and integrity" because this is taken to be obvious; instead, the charter is a roadmap to the future TLS 1.3 and thus documents the desirable changes from TLS 1.2.

As for the mailing-list messages you are pointing to, I think you are over-interpreting them. The kind of "middleware boxes" can be, for instance, a load-balancer system that needs to inspect ClientHello messages so that it redirects session resumption attempts to the server which last handled that session. Or a RADIUS server using EAP-TLS as authentication protocol: in EAP-TLS, the EAP layer must recognize the record boundaries in order to wrap them into EAP messages. These are very legitimate, non-evil reasons for systems residing in-between the TLS client and server to inspect the packets and actually understand the unencrypted parts of the protocol.

The dialogue in the mailing-list goes mostly the following way:

  • We must encrypt all the things ! Our Charter demands it ! Let's change the record header format.

  • This will break systems which rely on the record format; this may break compatibility with middleware boxes (that I will allude to only in the vaguest terms). Is it really required ? Or is it a Gratuitous Change, that is explicitly forbidden by Our Charter ?

  • This is needed because content-type field in the header allows for evil traffic analysis attacks (that I won't describe because I don't actually know of such an attack). Traffic Analysis is Very Serious ! Encrypt all the things !

  • But Our Charter does not talk about Traffic Analysis ! And Traffic Analysis is much harder to defeat than simply encrypting the record content-type headers. Traffic Analysis is Out Of Scope !

and so on, ad nauseam. Interspersed in the exchange are actual bits of information, from which we can conclude that the WG members do not seem to have reached (yet) a consensus as to the level of backward compatibility that TLS 1.3 should have with previous protocol versions. Especially since that compatibility is defined relative to existing, deployed system that interact with the on-the-wire format in various way that are not necessarily well-documented.

However, reading these emails as if the WG was trying to promote some generalized NSA-like spying would be erroneous. This is a classic case of "committee reasoning" when the actual goals and constraints have been insufficiently specified. It can be predicted that the definition of TLS 1.3 will take some time (years) to come to fruition.

|improve this answer|||||
  • "...it does not specify that 'TLS should provide confidentiality and integrity' because this is taken to be obvious" - I kind of disagree with you here. I agree that it should be obvious. However, its not stated, and that breeds ambiguity. Also notice how privacy has taken a back seat: "...balancing with other requirements...". To me (perhaps I'm wrong), privacy goals are held in similar esteem to C/I/A goals. – user29925 Jul 28 '14 at 19:55
  • "...The kind of "middleware boxes" can be, for instance, a load-balancer system..." - this is really the crux of the problem. We can't teach developers to differentiate between the "good" bad guys and the "bad" bad guys. That means we give the "bad" bad guys a toehold because of the "good" bad guys. – user29925 Jul 28 '14 at 19:56
  • 1
    @jww Actually you can teach developers to differentiate between good and bad guys. The middleware boxes are typically sanctioned by the institution where the application is going to be deployed. However uncomfortable this may be, the overall user is the good guy (their machines behind that middleware box and the box itself): whoever is in charge of that network should be able to configure the application to trust that box's CA cert. Developers should generally let users choose which CA certs they trust. To differentiate from the bad guys, developers must not bypass certificate verification. – Bruno Jul 28 '14 at 23:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy