Write Internet drafts for one or two TLS features to improve its traffic-analysis resistance

From org/sponsors/SponsorF/Year2: "16. research: Internet drafts for one or two TLS features to improve its traffic-analysis resistance. In particular, TLS needs better support for link padding, and for a mode where it does not send its record headers as plaintext. (Yes, TLS implementation moves bog-slow, but if we can get extensions in place, or something into TLS 1.x, we can do a lot of good here.)"

When talking to Nick about this deliverable last December, we agreed that there's not much that I can do in terms of coordinating with other Tor people or defining internal milestones and that I'm just going to ask every now and then how it's going.

Still, having a rough schedule for the substeps to be taken until November would be cool. Nick, can I ask you to make up such a schedule and post both the schedule and updates how it's going here?

added SponsorF20121101 component::metrics/analysis owner::nickm priority::medium resolution::implemented status::closed type::project labels

So here's what I think the stages are:

1. Sketch out some initial designs.
2. Show these to the people I know who are involved with the TLS working group, and see if they think I'm fundamentally insane. Iterate until the basic designs seem right.
3. Write up the deisgns in internet-draft form. Get help from others as I do so.
4. Submit them.
5. receive comments, revise as needed, iterate.

I fully suspect that one or both of these ideas might get shot down at some point in the process, especially at step 4. But that's why we committed to internet drafts, not to RFCs.

Now, as for the timeline on these steps, obviously we should get to stage 5 as soon as we can for maximal utility, but I believe that only stage 3 or 4 is what we promised for November.

Hm. I think I could do stage 1 and start stage 2 in April. I don't know, after that point, how long stage 2 and stage 3 will take, but perhaps I can have a better sense then?

Replying to nickm:

Now, as for the timeline on these steps, obviously we should get to stage 5 as soon as we can for maximal utility, but I believe that only stage 3 or 4 is what we promised for November.

I think the goal is to get the draft(s) submitted, so that would be step 4. Is step 4 going to take long once step 3 is done? And I agree, we didn't promise 5.

Hm. I think I could do stage 1 and start stage 2 in April. I don't know, after that point, how long stage 2 and stage 3 will take, but perhaps I can have a better sense then?

Sure, that works as an initial schedule. I just created #5494 (moved) for step 1. Will follow up with you after April 30 to see how step 1 went and to get dates for the next steps. Thanks!

WRT TLS link padding, GnuTLS has been doing it for a while: https://www.gnu.org/software/gnutls/manual/html_node/On-Record-Padding.html

WRT hiding record headers, I'm wondering how feasible it is and whether it's worth it. You probably won't be able to hide (encrypt?) record headers before the the key exchange happens (or before the session is resumed). After that, I'm not sure how much you gain by hiding record headers. For example, hidden record headers would make renegotiation harder to detect, and would also hide some alerts, but I can't think of other use cases.

Adding George to Cc, so that he doesn't have to follow this project sekritly anymore.

Trac:
Cc: N/A to asn

Marsh Ray appeared in #tor-dev today to tell us that the IETF TLS working group is worrying that Google's TLS NextProto proposal will increase the blocking surface of TLS, since it advertises the transport layer protocol in plaintext (in the TLS extensions in the Hello records).

He told us that it's a good chance to influence the future of TLS to be more traffic-resistant. Here is the relevant mailing list thread:

https://www.ietf.org/mail-archive/web/tls/current/msg08685.html

Marsh pointed out that my description of the NextProto protocol above is not entirely accurate, since the client transfers her choice of transport layer protocol encrypted after the ChangeCipherSpec:

If, and only if, the server included a "next_protocol_negotiation" extension in its ServerHello message, the client MUST send a "NextProtocol" message after its "ChangeCipherSpec" and before its "Finished" message.

For our records, Marsh is lobbying for replacing the plaintext NPN that Google currently uses with a DH handshake as part of ClientHello and ServerHello. The server would use the DH key to encrypt the cert chain for the client in the ServerHello reply itself. IUC, the client would then put the NPN bits as part of its Finished message, also encrypted with the key.

So they seem to be totally open to redoing the TLS handshake to provide less data on the wire for blocking. I think the server cert chain will be a major issue for us, unless we want to do gymnastics like providing fake unused certs, so the plan seems like a step in the right direction to me...

For the record, I was mostly just thinking out loud. I do think something along those lines might be really useful.

But mainly I would like to offer help in whatever way is needed, rather than "lobbying" for any specific protocol change at this point.

• Marsh

It seems that Marsh not only wrote a draft for his idea, but the draft was also quite well received by the TLS community: https://www.ietf.org/mail-archive/web/tls/current/msg08722.html

He proposes two schemes: One scheme, where the ClientHello is transferred in plaintext, the rest of the discussion is encrypted, and the number of round trips is the same as in classic TLS. And another scheme, where a dummy ClientHello is initially transferred, all the discussion is encrypted (including the actual ClientHello that carries extensions etc.), but the number of round trips is increased by one.

If this proposal gets accepted and implemented, the browser/httpd vendors will decide which of the two schemes to use, and this will decide which scheme we will have to use.

In the last section, there is:

   o  It cannot be repeated often enough that the early encryption
      negotiated by the EH extension *only* provides protection from
      passive eavesdropper.  It *can not* resist a man-in-the-middle
      type active attacker who wishes to steal a sample of the plaintext
      the client and server intended to exchange (doing so will break
      the handshake however). Like TLS without EH, full protection from
      an active attacker only begins after the Finished messages are
      received and validated by each side.

since the proposal does not protect against MITM or active-probing-like attacks.

I wonder if there is anything smart that can be done to add protection against MITM.

For example, adding a post-Finished phase where parties could exchange metadata would help against MITMs, but it would also add another round trip. Furthermore, if such a phase was client-initiated and optional, we would be able to use it only if everyone else did so too, otherwise we would stand out against a passive adversary (lame plaintext TLS record headers).

I suppose I am now "lobbying for a specific protocol change". :-) I don't know that this change helps Tor directly, but I suppose anything that makes common net protocols leak less plaintext helps everyone indirectly.

• Marsh

Switching from using milestones to keywords for sponsor deliverables. See #6365 (moved) for details.

Trac:
Keywords: N/A deleted, SponsorF20121101 added
Milestone: Sponsor F: November 1, 2012 to N/A

Roger asked me to braindump on the status here so he can manage internal and external explanations.

Marsh wrote a pretty awesome internet-draft that looks as though it'll expire on November 3; I'm trying to contact him to see whether he's got anything in mind for the next steps, and what he thinks the next steps are there. If it could get implemented and widely used, it would sure help Tor a lot.

On a more radical note, the real way for encryption protocols to become unfingerprintable is by demanding of encryption protocols that they send bytes that aren't distinguishable from randomness. Zack, Dan and company made one of those as part of the chopper part of Stegotorus; I am writing it up in a spec form to try to get it more attention.

In other news, the CRIME attack by Rizzo and Duong has gotten some people interested in TLS padding for entirely the wrong reasons. I'm writing up what I hope will be a more realistic draft to extend the capabilities of TLS padding, while (more educationally) explaining what padding can and can't do, why you'd want to use it, and offering API suggestions.

The latter two I'm writing for "internet draft" standards, but right now the conversations about CRIME and other stuff seem to be in a state where putting forth a draft right now before we educate folks would be counterproductive.

I talked to Vinod, and we don't have to formally submit anything just because our schedule says we should -- we should do the right thing (the thing that's best for Tor) rather than do the scheduled thing if they conflict.

We have preliminary drafts here and here that are sufficient for the deliverable. These drafts are not final versions, but preliminary drafts currently receiving feedback. Any further feedback or revisions should happen in another ticket than this sponsor F year 2 project ticket. Closing. Thanks!

Trac:
Status: new to closed
Resolution: N/A to implemented

closed

mentioned in issue #5494 (moved)

mentioned in issue #7277 (closed)