TCP Increased Security (tcpinc) WG 2014-11-14 09:00-11:30 Agenda bashing Four Drafts - draft-bittau-tcpinc-tcpcrypt (See slides) - does header protection if we want to do that - draft-rescorla-tcpinc-tls-option (see slides) - draft-thomson-tcpinc-dtls - nothing to report - draft-touch-tcp-ao-encrypt - new version this week ekr: is that really 128 but? tero: yes, i didn't read the draft. might mean ecdh? -- Protect or not the TCP header fields tero: the more we protect, the more middleboxes will break us Header Fields - ip and ports - seq numbers tero: we could protect but what could an attacker really do? RST would be nice, but... - flags tero: like IKEv2, errors are ignored. at most send liveness to peer to see if its still there - URG pointer, RCV Window tero: all requires active attacks. no interest from monitor point of view. Options 1. protect only payload tero: we want replay potection, can be done without protection. data stream protected, not headers 2. protect payload plus some fields tero: if we do, where to put MAC Consensus on the list - 6 authors selected option 1 bob briscoe: related to the RST, there is an echo cookie proposed so we can do syn cookies, which would be mandatory for -- Inner Space presentation by bob briscoe -draft-brisco-tcpm-inner-space-01 Opportunistic encryption. tcpm we are to provide more option space. better middlebox traversal 1. No handshake latecy 2. Middlebox not a downgrade 3. How? Inner Space protocol 4. Authentication coverage insights Opportunistic delay - slides suggests slowness will make people turn off privacy Tcpcrypt latency & Inner Space (see slide) bob: this shows how to remove 1 or 1.5 rounds from initial startup of tcpcrypt bob: removes helo state and tcpcomp(?) state from tcpcrypt bob: same technique as False Start. bob: it decouples tcpcrypt from TCP state machine bob: msg boundaries within the segment Dacheng: the server sends data first? bob: if server has something to send, it is the right side (of slide) Dacheng: if I use innerspace, the client couldn't david mzieres: [missed what he said] Tcpcrypt latency session resume bob: jump forward one round trip time bob: cannot see command, one form of protection Dacheng: the tfo is encrypted? bob: yes with previous play ekr: is there a replay mechanism there? bob: there is a cookie ekr: you need server maintain connection state, record, so you cannot replay bob: let me put in context, you may not be able to use TFO, only applicable if application is omnipontent ekr: that's sad Jana iyengar: [something about tfo] Middleboxes detect and downgrade - not good enough bob: could start TLS negotiation when you do TCP negotiation bob: can't gain on resume ekr: same [mumble] bob: started remove latency out of tcpcrypt. started to get through middleboxes bob: it will be useless against well funded adversaries. Maybe 10% are going to downgrade it bob: so much noise of downgrades, you might miss real downgrade attack dkg: I agree with concern of stripping. in general, people are not expected to serve this to user at all. presenting this is a distraction. while true, middleboxes can strip it, yes anyone controlling the path can strip it. does not mean the default is good. I'm all for stopping passive surveilance tero (not as chair): my tcp connection usually with same host. I know my middle boxes. bob: most people are mobile, nothing is constant bob: I'm trying to be ambitious. Middleboxes domination strategy bob: if a middlebox starts messing around, the middlebox should break my service. instead of us breaking our own service. we want to get through middle boxes and authenticate it. then if someone sells a middlebox then their product will be seen as broken. bob: want to get middleware boxes to shoot themselves in the foot Inner space(s) - TCP segment structure bob: stealth tcp options. avoid outer tcp option as the flag which could be stripped bob: shared fate principle. both share same faith. (stripping would cause different views) bob: robuest to resegmentation, inner otions not prone to stripping, reliable ordered delivery Rekey message on an unreliable unordered segment Transformation of data stream bob: [wand turns into rabbit] Message authentocation coverage bob: if you want to mac the tcp header and options you could do it in payload covering both. bob: preserves one to one mac to payload bob: does not break the mac just because resegmentation bob: except tcp header and outer options, which you dont need to use with this bob: gothca: mac consumes sequence spaec on pure ack. got solution working on unordered options(?) bob: you can mac based on consistent behaviour. paulh: you keep saying can? saying this is good? or possible? no one responded. bob: lot of people say dont do it. can easilly make it work, then more people will want to use it Encapsulation model(s) bob: some things still in outer. working on putting everything in the inner options Summary dkg: it seems the diff between this and defacto-tcp is you have payload in your sync and starts with a magic number. it worries me there has been no path testing. the claim of the presentation is this gets us through middle boxes. I don't know bob: neither do i. we are working on data Jana: that is true. you can remember it failed, continue later with inner space after the syn dkg: doesn't reduce latency Jana: we got more options. we try to reduce latency [someone talks at mic] [many people talk] Jana: there might be more middleboxes that..... we still want fallback mechanism ekr: sure. the uhm. yeah. [Tim Shepard]: I'm a real fan of this inner option space. but the decision to do it is at a higher level then this working group operates. should this wg wait for the higher level decision. Of all of option space extension proposals, this is just one. wanted it in mptcp(?) ekr: one thing, more data on the first flight in syn. second piece is moving data around so it has better interaction with middle boxes. if we believe in first not second, then for now we assume we cannot put data there and put it in second flight and [too fast] move forward would be nice in the hope things get better in the future bob: you can do this now in userspace because it is all in the application data, apart from handshake in the start. ekr: concerned about standarization mechanism bob: I'm decomposing tcpcrypt Jana: key not with options because data acks. data instead data means you can have a deadlock. similar concern here. working on solving in draft. Jana: you do want to seperate which protocols are getting standarised Jana: which proposal will actually work ? choise depends on which ones actually work dkg: tcpcrypt is all in userspace. we do no want application needing modification. bob: i did not mean that. If you want to test it you can do it without mucking with the kernel tero: can use solution like socksify (used for proxy/SOCKS) ted hardie: big difference userland and kernel. many applications trying very hard to be too clever they believe they know something about mtu. doing userland modification that changes effective mtu that applicatin sees can cause problems. we need to do testing to see which one of these work. bob: segment structure is if you like advisory. it can be broken in different segments. can be done my kernel and pmtud, etc. ted: true, but there are cases (esp in telephony world) because they believe they understand pmtu, (als with ipsec envelope) caused problems in the past. be careful. applications infer things about the network. bob: if done in kernel no particular change ???: unaware applications will cause problems andrew mcgregor: i dont see a real need for this to run at [high speed]? bob: don't understand Q andrew: the argument TSO/GRO offloaders isn't affecting things much now. things have changed bob: can be put in the data and be put in segment offload Jana: this particular mechanism for extending is a good one? Is that conversation we are having now? tero: we have lots of time. do we want to protect the headers or not? part of this discussion Martin Stiemerling (AD): it is ok to discuss. tero: is it going to be tcp option or tls framing? just a name ekr: combination Q: multiple proposals how to hack option space bigger. is that going to resolve any time soon? room says "no". ekr says "sad". dkg: lets not lock on waiting for that tero: yes bob: not trying to say stop doing thing. saying you can do this in parallel and do it later jana: I agree. dependencies is not without reason, but is just dependancy. tcpcrypt could push tcpm to move faster tim: i shouted out no about tcpm option space. this optimistically sorted out in a few IETFs. having more room for options is probably important for tcpcrypt. ekr: agreeing with that. david: can already do what we want to do tim: more options would make you happier. tcpm scratched themselves for a decade. many proposals that work but just takes more time to pick one. This group can just move ahead, we got running code. let's just charge ahead and write/publish the documents. great. however, wht about deployment, which is what we really want to achieve. and we get deployment with outer options. and that one happens to be supported/implemented forever. and the new way with inner options. now you have to implement both for a very long time. there is opportunity here , related to cookie option, you want to say any new option needs to support this cookie option to ensure everyone modern can expect the right options. would be nice if that can be done before this group finishes, so we dont have to implement both forever. i hope you dont charge ahead. things have to happen elsewhere for this to work well. bob: if tcpinc were deployed before this it would mean you have to deploy two things. this being deployed afterwards you can move options from outside to inside. tim: if one end is upgraded you cannot. Pasi Sarolahti: reason why this could be done in tcpm, about reducing latency, APIs. we should not be rushing too hastilly paulh: i want to echo what tim said, waiting is better. especially if this wg says finish until there are inner/outer options and it should wait. and put pressure on tcpm. This does allow experiments and i am worried about middle boxes. early experiments are good. this is easier then ipsec and tls. worst, we deploy and guessed wrong about middleboxes. Brendom williams akamai: some discssion more appropriate in tcpm than here. we keep getting distracted. do we want all the control/framing in the tcp options themselves or belong in datastream to the decryption point. if what we're focused on is a session layer with framing, the Q of whether tcpm accepts this or extended option space might be irrelevant. this might be a good approach, regardless whether tcpm thinks this good as general way to increase option space. perhaps refocus some discussion whether it really belongs in option space in per-packet thing, or whether it belongs in data stream itself as guarantee it gets to the other end of the encrypted stream. David Stanford: everyone could benefit of increased option space. I hear tim. I want to push back to tcpm folks, you should think about embedding entire external options to inside options. there should be a general default way of doing that. The proposal for this later they must implement conversion from innerspace or other options methods to the new method. Just write drafts so it requires moving options to inner options. Jana: don't want two different wire formats David: you will have that anyway. rather than put burden on tcpinc, burden should be on tcp option space [ more back and forth re-stating the same different positions by people] ekr: not too worried about transition. if we have a time where we have a dip of 15% in opportunistic. It does not break the web. it is not a disaster. dkg: I second that. Waiting causes us to lose more encryption The AD: tpcinc wants to go fast but needs to fit in. we are crying tcpm is too slow. that is unfair. help those people out to make it move. if you want to travel fast, go alone. If you want o travel safe, go together. dkg: tcpm people telling us they wanted more options for 10 years. and it only just started? the AD: the log jam just broke. we have 3 proposals now. bob: it broke now because it is really needed now.. and joe touch's statement broke people open too Jana: we should move fast. ???: not product of technology but product of method followed. process could move forward tero: what to do with protecting tcp headers. do we need to protect the headers? main goal is passive attacker protection, and these are not very useful to passive attackers paulh: what do you mean by protect? if mac fails what? drop the segment? if someone messes with the header, do we really want to drop the packet? user is aware because it fails to communicate. tero: good point. charter says do cleartext fallback at start. we didnt think about what if it changes in the middle? paulh: sounds like mac of the header fields is only useful if it happens only once. not useful against active attacker. sounds like a lot of cruft, and for active attacker it is easier to stop the flow. so we should not bother with the header at all. No value other than we will shut down connectin. david stanford: would be a shame to go through all this work only to leave out active attacks at the last moment. It's not about header or not header. some bits are important. there is a fairly low bar for option to check RST packet. RST attacks are out in the wild. might not want to turn it on always, but a sysctl option would be useful. high value and low cost for such an option as it would not be on by default. [more examples] tero: protecting ack, seqnum. I dont see value because it is protected by data. david: protect seqnum (mean offset into the stream) is critical otherwise you have no integrity tero: seqnum are not offset in the stream. you have to protect that of integrity. agree david: why do i need to know the other side received the data? which allow you to remove data from memory for isntance during rekey to remove old key for forward secrecy purpose. Dont want attacker to trigger applications behaviour. Mucking with ACKs make you read short reads, etc, changing semantics even though authentication happened. so removing value of auth So I am in favour of ACK/SACK/RST bit, urgent bit, more nuanced fields header protection ekr: if all you do is protect payload and not the [flow] attacker can cause termination. ekr: these on-path attackers already have other options. not saying there is any value, but.... ekr: active attacker on path just disables all of tcpinc. not too enthousiastic about header protection david: think about wireless attacker scenarios [missed name] is a WG chair: [...] we dont need to distinguish data and payload too much [...] bob: paulh' point what to do when it fails. how likely this is headers would fail authentication The case i dont like is moving mobile and new middle box stops things from working. you cannot ignore things but have to restart. I would like to make this as secure as possible including header so we can build things on top of it. if that fails a lot i woudl rather have something than nothing. In the outer headers, dont cover the option space because possibility of not working. inner headers, just do it. greg maxwell: global passive observer using optical taps, doing traffic sampling. seeing a ton of traffic, they could easilly send a single packet (not on path) using cell modem. blind TCP RST attacks. we need to solve false resets which we have already seen. Does not mean authenticated headers, but try to cover this case ted: what greg said. by protecting headers or looking at something else in the data. if we can protect some headers now, and later protect all headers, that would be nice. Jana: protecting it makes sense. in favour of doing selective protection. dkg: in favour of protecting RST as well. answer to PaulH: if some header protection is false. on-path attacker out of scope. but there is authentication modes part of charter. what do we do if part of the headers fail to authnticate. no logner expose authentication modes? Treat as state change assuming you haven't used them yet ekr: yeah. if we're only concerned about DOS, yeah. Is that really the onyl thing [headers protect against] paulh: we are not "protecting" if the fallback is shutting down the stream or knowing something. Brandom Williams: mostly focused on deployability. Adding header protection makes this less deployable Middleboxes will just break it. If we want to cover pervasive monitoring out, skip this. David: I disagree. It depends on which header bits. Simply ignoring RST packets is not going to hurt deployability. I agree some header fields should not be protected Brandom: thinking of very specific type of middleware boxes such as those splitting TCP connection. I dont think we get those boxes to work David: again lets scope discussion to particular header fields [ repeated heated discussion of same ] David: [talks about things tcpcrypd can do my making changes to it] Tero: lots of discussion on active attacks, but main focus is passive attacks [room suggests to humm for each header bit :)] AD: dont make sense to humm now. Would like to see more discussion on the list. Some of it now seems like shooting from the hip. Tero: dont want to tell authors to write both versions of with(out) header protection bob: discussion here is not grounded in moving towards consensus. moving to mailing list will be the same ekr: we dont have consensus today. do an analyses like you did at the microphone. integrity protection and confidentiality protection. seems only inner space people want to do confidentiality Maybe useful would be a draft to determine which are useful/useless to protect, which ones in practise cannot be protected, get some sort of assessment. Tero: we already did that. Points to slide summary of Marcelo 2014-10-06 [various people including chair unclear how to proceed] David: tcpcrypt people would like more feedback about out of order authentication ekr: what are the threats? DOS or other? Should become more clear what we want/need to protect Jana to David: please please please do. [Jana received a Minion from EKR] [EKR took Minion back for his kid] Richard Barnes: keep middlebox in mind. policies based on IP/ports are very fundamental. typical security vs monitoring we have a choice of protecting everything and not getting anything versus getting some protection in. Tero: anyone who wants a header bit protected (or actually the service provided by the bit), sent email to the list with reasoning. Tero: and if someone messes the bit up, what should we do. [ seems people are in favour of out of order support]