Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

[Jacob Appelbaum <[e-mail]>]

Dear Bryan,

On 11/30/15, Bryan A Ford <[e-mail]> wrote:
> Thanks Bill for the feedback.
>
> On 11/29/15 6:11 PM, Bill Cox wrote:
>> Thanks for the detailed description of why we might want to obfuscate
>> TLS record lengths.  From a security point of view, the only potential
>> attack vector this might create is that the attacker will know in many
>> cases the plain text of the first 5 bytes.  A weakness in the stream
>> cipher might be more easily exploited in this case.  IIUC, we feel
>> pretty good about the latest AEAD ciphers, and guessing the clear text
>> of many bytes in the record already is not too hard.  Is that right?
>> So, from my fairly uninformed point of view, this seems like a
>> reasonable upgrade.
>
> Just a nitpicky semantic correction: my proposal doesn't "create" the
> attack vector you describe (that the attacker will know the plaintext of
> the 5-byte header).  That weakness is already there in TLS 1.3 as
> currently specified, because the TLS header is unencrypted so the
> attacker will *definitely* know the 5-byte header. :)  This is merely an
> existing weakness that is not fixed by my proposal.

That is my read as well. I think your proposal sounds pretty interesting.

>> I have one concern.  These same boxes that hide record lengths by
>> merging and breaking up packets arbitrarily likely would deliver the
>> packets not well aligned to record boundaries.  Is this already the
>> case?
>
> It's already the case that middleboxes of various kinds re-segment
> (merge and break up along different boundaries) TCP streams for various
> reasons, often as an unintentional side-effect of interposing on the
> stream by "accepting" the TCP connection (pretending to be an endpoint)
> on one of the middlebox's interfaces and opening a new outgoing
> connection on the other interface, and just forwarding the traffic
> between them. In fact, Performance Enhancing Proxies (PEPs) are one
> class of middlebox that often do this intentionally, so they can get
> better control over and fiddle with the way congestion control works
> over "troublesome" types of links like high-bandwidth-delay-product
> (e.g., satellite) links.
>
>> If these boxes currently inspect packets when breaking them up to
>> split packets along record boundaries, encrypting the lengths will
>> defeat this efficiency hack.  We might cause an increase in network
>> latency in this case.  Do any of the routers out there currently use the
>> record length field when splitting up packets?
>
> If I understand your question correctly, you're asking if encrypting TLS
> record lengths might break middleboxes that currently want to track TLS
> records for some reason, e.g., perhaps to re-segment the TCP stream to
> correspond to TLS records (which might "fix" or "revert" the effect of
> another middlebox in the path that re-segments TCP in a TLS-oblivious
> fashion).  I don't know of any middleboxes that do precisely this, but
> it's not inconceivable that they could exist.

Why would that concern anyone other than to help an attacker?

If my ISP requires me to use such a box, I should use it as a proxy or
configure it manually. If they use it on me without my consent, it is
an attack. I want TLS to break and to do so in a way that fails
closed. If another ISP, backbone ISP, or XKeyscore would have a harder
job, I fail to see why we should care at all.

They're the adversary, we should not give them anything. We should
make their job as difficult as possible technically as well as in most
other ways as well. I have no sympathy for the
what-about-poor-NSAT&T's-big-networks of the world.

> More generally, since basically all manner of evil/broken middleboxes do
> exist, it's entirely possible that most any change to TLS's wire
> encoding *could* disagree with some middleboxes.  That's not specific to
> the change I'm proposing; any wire-visible change could trigger unknown
> middlebox badness.  The only solution to this I'm aware of is empirical:
> try the change, deploy it experimentally at first, and see what the pain
> level is, i.e., see if we find any middleboxes that complain and if so
> how prevalent they are.  But since TLS 1.3 is already changing a lot of
> other prominently wire-visible stuff with respect to prior versions of
> TLS that might equally well break middleboxes, it's not clear that my
> proposed change in particular is more likely to cause pain than any of
> the other changes already made, and in general I don't think we should
> let a few broken/evil middleboxes prevent meaningful evolution of the
> TLS protocol.
>

Agreed entirely. TLS should also be able to be composed with anonymity
networks in a way that we solve complementary problems, as you've
said. The less a hostile Tor exit can learn about a person's TLS 1.3
flow, the better. One could even imagine a key setup over one Tor
circuit and then a seemingly unrelated connection using the negotiated
key over another Tor circuit.

In an ideal world, we'd have two basic phases...

setup/keyex/etc:
  which is distinguishable

transfer of data/tear down:
  which if done correctly, should almost all look the same unless we
have a full network view with reassembly.

It would be nice if the biggest problem for traffic analysis was then
TCP/IP related, though we're far from that point with TLS 1.3 or any
other general purpose protocol.

It is true that to beat traffic analysis, we need to tackle that
problem directly and I very much agree with you that we still should
make these positive changes. Your suggested changes will also assist
others who are dealing with those problems directly.

All the best,
Jacob