IETF-90 Toronto - tcpinc WG Minutes =================================== Time: 2014-07-24 15:20-17:20 -- 15:23 Review agenda; no changes 15:24 Introduction to the working group (Tero) - Quote from charter - What the chairs want: one solution, sooner not later, starting point may change significantly, implementations also sooner - ADs and technical advisor comments List of presentations: TCPCrypt, TLS, DTLS, TCP-AO -- 15:27 TCPCrypt (Andrea Bittau) - Goal: most traffic encrypted - Summarize tcpcrypt -- baked into TCP handshake - Overview of flow - Overview of features (Yoav Nir) This assumes that middlebox is close to client. If it's a load balancer close to server, you might fail. (Andrea) If I turn this on, I better make sure the path to me is clean. My firewall needs to let it through. (Brian Trammell) Lots of work on path transparency that you should look at. Is this the intention to have check server in the long term? (Andrea) Interim thing now, while we study it. (Brian) Be careful hardcoding names into this. (Steve Kent) MP-TCP have done much work on middleboxes. Look into what they've documented. (David Mazieres) We discussed that in London. We have to care more because failure mode is worse. (Wes Eddy) Behavior depends on port number. Not going to see ALG behavior here. Not a very extensive test. (Andrea) Have to balance our tests. Need to figure out what tests should look like. This is a starting point. (Yoshifumi Nishida) You've considered when paths have changed? (Andrea) Right, and the middlebox starts dropping packets. Problem with other protocols too, not a good answer. (Nishida-san) Can't fall back to TCP? (Andrea) Don't want to downgrade halfway through. We have to think about this, try to measure it first. (Lars Eggert) Application has to re-establish the connection. Same with plain TCP, not any worse. (Paul Hoffman) Chairs, API is a separate discussion? Or do you expect APIs from all proposals. (Tero) Charter doesn't specify when. (Paul) Is it your intention to pull APIs out after we pick a solution? (Tero) No one else has APIs now. We'll see if these are usable. (Paul) Some large firewall vendors survey their customers and publish the results. Good way to find test vectors. (Joe Touch) Are you still squatting on TCP option codes? (Andrea) What's the alternative? Yes. Experimental ones add overhead. (Tim Shepherd) Yes, there are experimental option codes, but if we hope to get deployment and have it grow, the experimental options don't work: no good way for transition. (Michael Tuexen) How do I get a new socket option? (Andrea) API call tcpcrypt_getsockopt gets session ID from tcpcrypt daemon. Smart enough to determine whether you're running kernel or user space version. -- 15:54 TCP Use TLS Option (EKR) - How to get client and server to both know they're using TLS? - Looks at existing ways for coordination; none are good for opportunistic deployment - Overview of flow using TLS option (Lars Eggert) Is it the application or shim layer that starts TLS handshake? (EKR) Two implementation options; will get to it later (Steve Kent) Could you use port fields and TCP addresses for tiebreaking? (EKR) Could. Concern is about wasting space in initial options field, and waste space in SYN ACK where it doesn't matter. (Keith Moore) Both ends need to realize they did simultaneous TLS open. Most applications don't care who is client and who is server. (Brian Trammell) There's a third case you're missing, where both sides don't support TLS option. - Overview of DOS vectors (Wes Eddy) I agree if goal is to improve app security. This is better for that against some DOS; it's compatible with SYN cookies. (Keith Moore) What advantage is gained for this over recognising client hello? (EKR) Applications are dumb, and can't do that. (Tero) Charter requires us not to modify applications. - Strawman proposal: use TCP-AO (Joe Touch) AO doesn't allow change in level of protection (EKR) That's a matter of updating that doc, not technical problem with TCP (Stephen Farrell) Did you think through the case where one side is using the TLS profile and the other is full TLS? (EKR) You have to do double TLS, or have the app tell the kernel not to use TLS on this. Client has to be configured properly. Every TLS stack allows you to configure all the relevant stuff. (Keith Moore) There are devices in the net that strip TCP options. They become a downgrade attack, and they won't go away any time soon. So in-band signaling is better than an option. What's needed is a way to insist that the opportunistic encryption be there. (EKR) Need an out of band signal to trigger opportunistic security. And then you'd start with TLS without the option. (Keith) Desirable end state is that everything has privacy, and this is a start. Need to think about the next step. (DKG) I like the simplicity here. This doesn't look like any TLS that's on the net today. Will middleboxes freak out? (EKR) Hadn't thought that through. Can cheat: offer ECDHE with self-signed certs. Can impersonate something that people actually do. There will be middleboxes that choke on this. Hope they give an error. (Steve Kent) Disadvantage of tcpcrypt is that it looks like TCP to DPI; this looks like TLS, so no confusion. Might run TLS on TLS, but also might run TLS on tcpcrypt, so why worry? (EKR) Side would have to agree on how many levels of TLS there are. (David Mazieres) Can sort that out OK. (Martin Thomson) Negotiate non-anonymous mode, someone looking in from outside isn't sure whether they can break in. (EKR) Feature or bug, depending on perspective. -- 16:25 Securing TCP (Martin Thomson) (Tim Shepherd) You said optionally protect the addresses. We want this to work through NATs. How can you do that? (Martin) I put it in there with a comment. Read draft. (Tim) Thanks for mentioning Minion and COBS. It has the wonderful feature that it's completely deployable on any TCP system today. I hope this WG at least thinks about not breaking that. (Martin) To fix that, you have a parallel option. (Diego Lopez) We will keep all well-known machinery for fine-grained authentication. OK to protect privacy, but with all the TLS machinery we can do finer grained access control, etc, for the same price. (Martin) It comes down to how much of the header you care about. That's what the WG should be focusing on: what those options are. (Diego) Yes, we need analysis of the impacts. -- 16:35 TCP Extended Data Offset Option (Joe Touch - remote presentation) - Extends TCP-AO to encrypt as well as authenticate (Martin Thompson) Re: need to authenticate... if you want integrity protection for headers, how do you avoid the situation where you have something you think is valuable? (Joe) I'm not authenticating SYN exchange that had the DH key. Authenticating everything after that. You don't know who they are, so it's not real authentication. (Martin) DH in the options: 1024 bit doesn't cut it today. With 128-byte option space, how do we deal with more than 2048 bits? (Joe) Have to use extended SYN, with out of band segment. So long as that gets through your NAT box, there's plenty of room for a large DH key. If not, have to take a second exchange. (EKR) I can send arbitrary crap in the initial packet? (Joe) You send another packet with no SYN, no ACK, and it extends the option field. Document that describes that. (EKR) We should look at that in the other protocols. (Joe) 4 proposals in TCPM to do this. Active discussion. (EKR) Min DH size is moving well above 1024, 2048 for MG DH. For EC 32 octets. So 32 to 256 octets. (Joe) We have another extension in TCPM, using simple "I can do this" mechanism, then extends option space for regular packets. There is the problem that when you go through a proxy that rewrites segments, it can screw things up if it doesn't understand the option. No real solution for that. If you have a problem traversing NAT boxes, we may just need to use tunnels. -- 16:52 Way forward, and discussion (Chairs) (Marcelo) We need to understand where the WG stands. Express what you think of the proposals. (Martin) A lot of this hinges on what we actually want to do, and that hasn't been clear. Is EKR's draft a contender? Need to answer those sorts of questions first. (Marcelo) Protecting TCP headers is open for WG discussion. (David Mazieres) Lots of things sound good, but they don't work in practice. A lot of details come up and you have to rework protocols. (Paul Hoffman) This should not be gated on new work in TCPM. They do good stuff, takes a long time. Learn from TCP-AO, not make same mistakes. (PHB) Potential here to make this worse. #1 cause of security vulnerabilities is buffer overruns, because of parsers. (Brian Trammell) To think about: How stop-gap a solution are we looking for? Quickly deployable. How OK are we with something that will run for a decade and we throw away? Or are we looking for permanence? A lot making assumptions about middleboxes without a lot of data. We need to evaluate these proposals based on how transparent we are to changes to the headers. (Lars Eggert) We can profile TLS down -- why haven't we done it yet? It sounds like a long road ahead. I favour the TCP stuff. There are properties of a TCP solution that I can more easily deploy. We need to discuss all this first, not forget better solutions because we have running code for others. (Joe Touch) How weird a NAT or rewriter do we have to tolerate? (Martin Thomson) Yes, how much do we have to let NATs mess with? (Marcelo) We have some text in the charter. NATs must be supported. (Martin) It's in the areas where middleboxes operate that we have this lack of clarity. (Steve Kent) Premature to toss out proposals now. Make clear what isn't required. This will remain for a long time. These are not at same levels of maturity. There are issues that take time to show up. We need to know for pro (Eric Burger) If this is supposed to be opportunistic, once we start hacking the application, the application can be hacked to just use TLS. So, anything that *requires* hacking the application is a non-starter. I think that knocks out tcpcrypt. It's OK for a TLS-aware application to have a specific "don't do opportunistic encryption because I will" bit in setsockopt(3). (Marcelo) Changes to applications are out of scope in the charter. (Brian Weis) Title is improving, not making perfect. TLS is a fine gold standard, and what we want is an opportunistic way to get there, so we don't need to protect TCP headers. I'm worried about middleboxes. So much out there that we don't understand. Lowest risk solution looks like a TLS packet, so that boxes that understand TLS will be happy. (Richard Barnes) General principle: you'd have to make a strong case to not reuse existing primitives for establishing secure connections. Fact that we have existing widely deployed case that's well vetted... better not to add another layer of untested security code. Reusing code is good. See how we can get handshake as part of establishment process. (Keith Moore) Not changing applications makes the whole WG out of scope. Apps have higher req'ts than this will provide. We don't want multiple layers of encryption. Very important: I like the idea of this, but you have to get from there to a higher layer of encryption than "authenticated". (Tero) Can't *require* changes, but can have new APIs as options. Must be a *mode* that allows unchanged apps. (Keith) You require app changes whether you think you do or not, because apps won't work *well*. (Brandon Williams) Middlebox support: We've talked about middleboxes that might break this. NAT devices... But think about cooperative middleboxes, that want to support this. Security proxies, transport layer optimization proxies. Might be broken by encryption. Make it so they can participate here. (David Mazieres) Confidentiality and TCP header encryption are two separate things. Charter says there must be app hooks for stronger security. Can't deal with APIs separate from protocols -- they interact. (Stephen Farrell) Tricky choice. TLS handshake is better understood. But diversity on the Internet: if we put another layer of encryption that's the same thing, putting more eggs into the same basket. Should factor that in. (Brian Trammell) Deployment horizon: This is a reaction to a current state of the network. Very rough consensus is probably OK, and we'll continue working on this problem. (Martin Thomson) Only so many soldiers to guard us, will spread them too thin. Do we have a problem with the APIs the tcpcrypt guys are proposing? I'd like to hear the concerns. (EKR) Profiling TLS is not a big deal, doing it in TLS 1.3. Echo David's request for clarity on what's required. Clarify: (1) Important to have header protection? (2) What are we looking for in an API? (Yoshifumi Nishida) Important to protect TCP header. How to sync this WG with MPTCP? (Marcelo) My take is that what we do here would be nice if it could be used in MPTCP. (Sharon Liu) Can this problem be resolved in a different way? Why isn't IPsec used more widely? -- 17:21 Wrapup (Chairs) Will start discussion on the mailing list, then continue with proposals.