Subject: [tcpinc] Prelimanry minutes

From: Tero Kivinen <[email-masked]>
Date: Sat, 15 Nov 2014 05:47:34 +0200

Here is the preliminary minutes from the Paul Wouters. There are some
names and things missing etc, so send corrections to me, and I will
put them in.

----------------------------------------------------------------------
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]

-- 
[email-masked]