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 protected]
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
