Subject: [Tcpcrypt] New version of the charter text

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 23 Apr 2014 09:02:10 +0200

Hi,

Thanks for the lively discussion on the charter text.
I attach a new version of the charter trying to include the received 
comments.
I have tried to be carefull using the should and the must, so please 
look into those.
I tried to reflect the different levels of requirements for the 
resulting protocol.
As usual comments are welcome.

TCP Increased Security (TCP Inc.)

The TCP Inc. WG will develop the TCP extensions to provide unauthenticated
encryption and integrity protection of TCP streams. The WG will define the
TCP extensions to perform an unauthenticated key exchange resulting in 
encryption
without authentication.  This is better than plain-text because it thwarts
passive eavesdropping, but is weaker than using authenticated keys, 
because it
is vulnerable to man-in-the-middle attacks.  This work is part of the IETF
effort to harness the Internet architecture given the latest events of 
pervasive
monitoring (see draft-farrell-perpass-attack).

The working group is looking to produce experimental documents 
specifying the
required TCP extensions and any additional informational documents needed.

The high-level requirements for the protocol for providing TCP 
unauthenticated
encryption and integrity protection are:

- Deployable and usable without significant changes to existing Internet
   infrastructure, in particular it must be compatible with NATs (at the
   very minimum with the NATs that comply with BEHAVE requirements as 
documented
   in RFC4787, RFC5382 and RFC5508);

- The protocol must be usable by unmodified applications.  This effort 
is complementary
   to other security protocols developed in the IETF (such as TLS) as it 
protects
   those applications and protocols that are difficult to change or may 
even not
   be changed in a backward compatible way.  It also provides some 
protection in
   scenarios where people are unwilling to do any change just for the 
sake of
   security (e.g., like configure encryption in an application).

- When encryption is enabled, it must at least provide protection against
   passive eavesdropping by default,

- Must gracefully fall-back to TCP if the remote peer does not support the
   proposed extensions

- When encryption is enabled, it must always provide forward secrecy.

- When encryption is enabled, it must always provide integrity 
protection of the
   payload data (it is open for discussion for the WG if the TCP header 
should or
   not be protected)

- When encryption is enabled, it must always provide payload encryption.

- Should attempt to use the least amount of TCP option space.

- Must not require any authentication or configuration from
   applications or users.  However, hooks for external authentication 
must be
   made available.  The WG will not work on new authentication mechanisms.

- The protocol must have acceptable performance.  For example, the 
protocol may
   try to re-use existing cryptographic material for future 
communication between the
   same endpoints to avoid expensive public key operations on connection 
set up.

- Hooks for allowing upper layers to disable encryption must be made 
available.
   The protocol may try to avoid redundant encryption when it is 
possible e.g.
   by detecting encryption performed by upper layers (notably, when TLS 
is used).

- No extra linkability: when encryption is enabled the TCP traffic 
should not
   give a third party observer any extra way to associate those packets 
with the
   specific peers beyond information that would have been present in a 
cleartext session.

- Client fingerprinting: some clients may want to avoid appearing as the 
same
   client when connecting to a remote peer on subsequent occasions.  
This should either
   be the default (clients cannot be "fingerprinted" by the server based 
on shared state)
   or some mechanism should be available for clients to drop or ignore 
shared state to avoid
   being fingerprintable.

Security features at the TCP-level can benefit other TCP extensions.  For
example, both Multipath TCP and TCP Fast Open require proof that some 
connections are
related.  Session resumption and Message Authentication Codes (MACs) can 
provide
this evidence.  The working group should identify synergies and design the
security protocol in such a way that other TCP efforts can benefit from 
it.  Of
course, TCP extensions that break must be identified too, and kept to a 
minimum.

The working group will produce the following documents:

- A framework for unauthenticated encryption and integrity protection of 
TCP connections.
This document will describe basic design considerations, including the 
motivation and the
applicability of the proposed mechanism, the interaction with other 
security mechanisms in
different layers of the stack, the interaction with external 
authentication mechanisms, the
expected protection, privacy considerations and residual threats.

- Extensions to current TCP to support unauthenticated key exchange and 
encryption and
integrity protection. This covers all the protocol changes required. 
This will be a
experimental document.

- An extended API describing how applications can obtain further 
benefits of the
proposed extensions. In particular, the hooks for supporting external 
authentication
will be defined in this document and the hooks for disabling encryption.
This will be an informational document.

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Wed, 23 Apr 2014 11:55:11 +0000

> I have tried to be carefull using the should and the must, so please

Would draft-paddon-tcposp-01 be within the proposed charter?

Michael

---

From: Joe Touch <[email-masked]>
Date: Wed, 23 Apr 2014 09:54:52 -0700

Hi, all,

Comments below...

Joe

On 4/23/2014 12:02 AM, marcelo bagnulo braun wrote:
...
> TCP Increased Security (TCP Inc.)

I like the title, FWIW.

> encryption and integrity protection of TCP streams.

OK so far...

 > The WG will define the
> without authentication.

This implies in-band. I don't think in-band key exchange is viable; 
there's no way to protect the SYNs, and it might sufficiently increase 
SYN processing and server state to make a much larger attack surface.

I would optimally prefer out-of-band exchange, perhaps that could be 
bootstrapped with an initial in-band exchange. Less optimal would be to 
leave this issue open for the WG to discuss, but I definitely don't 
agree with mandating only in-band key exchange.

I would thus prefer:

   The WG will define the
   TCP extensions to utilize unauthenticated keys, resulting
   in encryption and integrity protection without authentication.

 > This is better than plain-text because it thwarts

It also leverages the original principle of BTNS, FWIW.

> - Should attempt to use the least amount of TCP option space.

...especially in SYN segments.

>    by detecting encryption performed by upper layers (notably, when TLS

When TLS is used, this defeats TCP-INC's ability to protect the TCP header.

It's OK to allow hooks to turn this off, but a better use case should be 
provided as motivation.

>    client when connecting to a remote peer on subsequent occasions. This
> should either

This should also include "any more than would be present for a cleartext 
session".

> _______________________________________________
> Tcpcrypt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpcrypt

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 23 Apr 2014 19:04:45 +0200

El 23/04/14 18:54, Joe Touch escribió:
> This implies in-band. 

Yes, the idea here is to provide a fully automatic mechanism, that 
people simply install and dont need to configure keys or anything. I 
think this is a fundamental feature. I am ok with allowing the use of 
other keys if they are available, but i strongly believe key exchange is 
a core part of this.

Regards, marcelo

> I don't think in-band key exchange is viable; there's no way to 
> protect the SYNs, and it might sufficiently increase SYN processing 
> and server state to make a much larger attack surface.
>
> bootstrapped with an initial in-band exchange. Less optimal would be 
> to leave this issue open for the WG to discuss, but I definitely don't 
> It's OK to allow hooks to turn this off, but a better use case should 
> be provided as motivation.
>
> This should also include "any more than would be present for a 
> cleartext session".
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 23 Apr 2014 19:05:47 +0200

Sorry, didnt finish the previous email.
I am fine with all the other comments. Will add them in the next version.

---

From: Joe Touch <[email-masked]>
Date: Wed, 23 Apr 2014 10:18:53 -0700

On 4/23/2014 10:04 AM, marcelo bagnulo braun wrote:
...
> people simply install and dont need to configure keys or anything.

That is orthogonal as to whether the key exchange is in-band.

Yes, a key exchange mechanism needs to be defined as part of the system, 
but not necessarily inside the connection being protected.

Joe

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 23 Apr 2014 19:54:38 +0200

El 23/04/14 19:18, Joe Touch escribió:
> Yes, a key exchange mechanism needs to be defined as part of the 
> system, but not necessarily inside the connection being protected.

mmm, havent considered that.
So the key exchange mechanism would be part of the work of the WG, correct?

How do you envision doing it other than inside the connection? like 
having a control connection to negotiate these things?
(something like 
https://tools.ietf.org/id/draft-paasch-mptcp-control-stream-00.txt maybe?)

Regards, marcelo

---

From: John-Mark Gurney <[email-masked]>
Date: Wed, 23 Apr 2014 11:00:18 -0700

> How do you envision doing it other than inside the connection? like 

Yes, this would be nice to know...

> https://tools.ietf.org/id/draft-paasch-mptcp-control-stream-00.txt maybe?)

This should be entirely in kernel, as requiring a daemon to pass non-TCP
traffic before any encrypted TCP traffic can be sent it a bad idea...

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."

---

From: Joe Touch <[email-masked]>
Date: Wed, 23 Apr 2014 11:37:06 -0700

> Yes, this would be nice to know...

In-band in a previous connection or completely out-of-band in a 
different protocol (like IKE is to IPsec). You could even do it inside 
the data of a TCP connection and use it on subsequent connections if you 
wanted to keep it "TCP".

> traffic before any encrypted TCP traffic can be sent it a bad idea...

It should be integrated and automatic. How that is achieved is 
implementation-dependent, and we shouldn't care other than integrated 
and automatic.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 23 Apr 2014 11:38:25 -0700

> So the key exchange mechanism would be part of the work of the WG, correct?

Yes.

> https://tools.ietf.org/id/draft-paasch-mptcp-control-stream-00.txt maybe?)

Sure- that's one possible way (i.e., that's what I meant by "in the data 
of a previous TCP connection").

I don't think we should pick in advance, though - let's see what people 
suggest first.

Joe

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 23 Apr 2014 21:01:16 +0200

El 23/04/14 20:38, Joe Touch escribió:
> Sure- that's one possible way (i.e., that's what I meant by "in the 
> data of a previous TCP connection").
>
> I don't think we should pick in advance, though - let's see what 
> people suggest first.
>

Ok, so the WG will decide whether it is in band or else.
I will change the text in the charter to reflect this in the next version.

Regards, marcelo

---

From: Wesley Eddy <[email-masked]>
Date: Thu, 24 Apr 2014 00:21:53 -0400

> monitoring (see draft-farrell-perpass-attack).

I'm probably just very bad at locating this in all the discussion, but
I have a sort of fundamental question ... why are we trying to do this
inside TCP rather than just running TCP over IPsec w/ BTNS (over UDP,
if NAT is the concern), or over DTLS?

I know it's more fun to do it inside TCP, of course, but I wonder a
little bit whether building a security sub-layer inside TCP (which
is already hella complex and full of edge cases) is really a good
idea when there are already a couple of reasonably decent security
protocols designed to be layered over.

Sorry for such a silly question, but it seems like it will come up
during chartering and should be clearly motivated, as reading the
requirements later on in the draft charter, it looks like you could
cook up something with BTNS or DTLS under normal TCP to do all that,
and it would protect the SYNs (which Joe mentioned is a challenge
for TCP-based approaches).

I think the charter should speak to this, at least very briefly.

-- 
Wes Eddy
MTI Systems

---

From: Joe Touch <[email-masked]>
Date: Wed, 23 Apr 2014 22:43:47 -0700

...
> if NAT is the concern), or over DTLS?

I'll take a shot, because the reasons are very similar to the reason 
TCP-AO is needed vs. IPsec or TLS

- can easily use per-connection keys, unlike IPsec
	IPsec keys would be costly to setup per-connection (e.g.,
	IKE per connection), and would require pinning both
	source and dest ports; TCP has more state
	that can make deriving per-connection keys from
	IPsec-like aggregate keys feasible and more efficient
	(e.g., as was done in TCP-AO)

- can allow key rollover without TCP impact, unlike IPsec
	IPsec key rollover would result in losses that would
	impact TCP's congestion control. TCP-AO show show
	key rollover can be supported without impacting
	TCP, and even using TCP itself to coordinate the
	key rollover

I haven't considered the impact of running TCP over DTLS and whether it 
could support the above. The overhead would certainly be higher, but 
that alone might not be worth creating a new solution.

However, at a minimum, a TCP-based solution might at least traverse 
stateful firewalls in ways that a UDP-based layering might not.

> protocols designed to be layered over.

See TCP-AO. It wasn't sufficient to layer that over IPsec. We didn't 
consider a DTLS-based approach at the time because TCP-AO predates DTLS. 
But see above for reasons a TCP solution might still be useful.

I'm also not aware as to whether DTLS has an unauthenticated 
(BTNS-style) mode.

> I think the charter should speak to this, at least very briefly.

I agree.

Joe

---

From: Wesley Eddy <[email-masked]>
Date: Thu, 24 Apr 2014 08:41:32 -0400

>     (e.g., as was done in TCP-AO)

This was the one I thought of too, but wasn't sure if there might
be some IKE extensions possible to get a similar effect that might
be lower-impact (like done in user-space, and maybe valuable for other
flows than just TCP).

>     TCP, and even using TCP itself to coordinate the

This part is interesting and I hadn't thought of it; thanks.

> that alone might not be worth creating a new solution.

Yeah, and I hesitated to suggest that too, because it winds up looking
like an RTCWEB towering Jenga stack of protocols.

> But see above for reasons a TCP solution might still be useful.

Yes, I know AO just a little since I was co-chair of the working group
for it :).

At the time AO was done, some of the criticisms of IPsec were captured
in:
http://tools.ietf.org/html/draft-bellovin-tcpsec-01

I could summarize those as:
- no good API for protecting an individual TCP connection
- NAT traversal issues
- masking fields used for QoS or TE

I don't think "TCP in IPsec in UDP" was considered at the time.

> I'm also not aware as to whether DTLS has an unauthenticated

Nor am I, but adding it (if needed) would *seem to me* simpler than
the equivalent TCP modifications, plus be deployable and upgradeable
in userland.  I'm sure there are dozens of people who know better
though.

-- 
Wes Eddy
MTI Systems

---

From: John-Mark Gurney <[email-masked]>
Date: Thu, 24 Apr 2014 08:55:33 -0700

> if NAT is the concern), or over DTLS?

Have you read the original tcpcrypt paper?

> I think the charter should speak to this, at least very briefly.

It does very briefly:
- The protocol must be usable by unmodified applications.

All the things you mentioned seems like it would require agreement
between systems and management by a sysadmin, but this is targeted to
end users system (like smart phones) too...  If TCP is the only
protocol allowed through a firewall, how are any of your other solutions
going to work?

The goal is to make it very easy for everyone to deploy...  Configuring
IPSEC is a pain, and as Joe mentions, most implementations don't handle
key roll over properly (even though apparently, you're allowed to keep
both the old key and the new key around for the transition period to
handle this case)...

---

From: Wesley Eddy <[email-masked]>
Date: Thu, 24 Apr 2014 14:52:42 -0400

On 4/24/2014 11:55 AM, John-Mark Gurney wrote:
>>> The TCP Inc. WG will develop the TCP extensions to provide
>>> unauthenticated encryption and integrity protection of TCP
>>> streams. The WG will define the TCP extensions to perform an
>>> unauthenticated key exchange resulting in encryption without
>>> authentication.  This is better than plain-text because it
>>> thwarts passive eavesdropping, but is weaker than using
>>> authenticated keys, because it is vulnerable to man-in-the-middle
>>> attacks.  This work is part of the IETF effort to harness the
>>> Internet architecture given the latest events of pervasive 
>> I'm probably just very bad at locating this in all the discussion,
>> but I have a sort of fundamental question ... why are we trying to
>> do this inside TCP rather than just running TCP over IPsec w/ BTNS
>> (over UDP, if NAT is the concern), or over DTLS?
> 

Yes (assuming you mean USENIX 2010).

> It does very briefly: - The protocol must be usable by unmodified
> applications.
> 
> between systems and management by a sysadmin, but this is targeted
> to end users system (like smart phones) too...  If TCP is the only 
> protocol allowed through a firewall, how are any of your other
> solutions going to work?

Automation only requires a little imagination, so I guess while I know
the claims about configuration and management are based on some reality,
I don't find them very compelling.

TCP being the only way through a particular firewall does indeed sound
like a good scenario to motivate this work over other options though.
Thanks for that example.

Personally, I think applicability for MPTCP and TFO is another good
motivation, and might even find those as more compelling than the
the data encryption functionality.  Marcelo's draft already nicely
mentions those, and I'm fine with what he has written there.  Using
some odd layering of DTLS or IPsec+UDP would seem less easy to apply to
the MPTCP and TFO problems than a tcpcrypt-like approach.

-- 
Wes Eddy
MTI Systems

---

From: ianG <[email-masked]>
Date: Sun, 27 Apr 2014 21:07:09 +0100

Hi Marcelo

> I have tried to be carefull using the should and the must, so please

As this is a charter, I'm not sure MUST is appropriate with every thing
we want.

> required TCP extensions and any additional informational documents needed.

It would be nice to have something about goals here.  Something like:

We are looking for the designs that find the sweet spot between
conflicting requirements:  to provide reasonable security for the
majority of connections.  Because we are dealing with unprotected
connections, we are more focussed on improving from baseline of no
security than achieving the high standard of security that is already
available to users of TLS.

>   passive eavesdropping by default,

So, in the above, we see the "When encryption is enabled," which is
repeated through out.  I would suggest this immediate above para be
swapped with the below para, as then the flowchart is more clear.  Then,
that phrase be dropped because it is an implementation detail.

Like this:

- If encryption cannot be achieved, must gracefully fall-back to TCP.

- Elsewise, must at least provide protection against passive
eavesdropping by default,

- must ...

> - Should attempt to use the least amount of TCP option space.

All of those above, and some below, are the sort of thing that any
protocol is going to aim for anyway.  They could be simply collapsed
into something like:

- should provide the best mix possible of the following features:
   - forward and backward secrecy
   - encryption and integrity protection over the payload
   - most efficient use of the TCP option space
   - efficient performance, including restart using previously exchanged
keys
   - minimise scope for linkability and fingerprinting
   - synergies with other aspects such as multipath and fast open.

Otherwise you're sort of teaching grandma to suck eggs, which is right
to do in a WG but not in the charter... ;)

>   try to re-use existing cryptographic material for future communication
> between the
>   The protocol may try to avoid redundant encryption when it is possible
> e.g.

Disagree.  The protocol may have it in there (sad!), and devs will have
this in their code for development phase, but mandating it is just
opening a can of worms.  Especially in the charter.

> This will be an informational document.

some thoughts.

iang

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sun, 27 Apr 2014 22:43:30 +0200

thanks for the comments, replies below...

> As this is a charter, I'm not sure MUST is appropriate with every thing

I dont follow.
It is perfectly appropriate to have musts in the charter.
> available to users of TLS.
sounds good to me

> eavesdropping by default,

In the first version of the charter it was not explict that these things 
were required when encryption is enabled, and i received several 
comments about it, so i made it explicit. I think it is more imprtnat 
for the charter to be clear than to read nicely, so i think we should 
keep it.

>     - synergies with other aspects such as multipath and fast open.

mmm, but the problem si that you are not making distinctions between 
thing we want to be mandatory (encryption) and other things that we 
would like but it is not clear how much we will achieve (like efficient 
use of option space ). To make a very silly example, if we dont do 
encryption, we do a very optimal use of the option space, but that is 
not what we want.

> opening a can of worms.  Especially in the charter.

You think this should be a should?

Regards, marcelo

---

From: ianG <[email-masked]>
Date: Sun, 27 Apr 2014 22:01:18 +0100

On 27/04/2014 21:43 pm, marcelo bagnulo braun wrote:

>> - Elsewise,

Perhaps here, insert:

Elsewise, all the following apply:

>> must at least provide protection against passive

Well, the point of putting the fall-back first is that there are two
modes of operation:  passthru and ENCRYPTED.  On starting up, the
protocol can enter either of these two states, but not transition
between them.  This choice dominates all to follow [0].

Then, for ENCRYPTED mode, all of the additional points apply.  For
passthru mode, none of the additional points apply.  So it's easier to
have the passthru mode listed first, then disposed of as far as further
writing is concerned.

>> to do in a WG but not in the charter... ;)

This bit above!  If we need to remind someone doing a mandatory
encryption in a security protocol, then we've got another problem and we
shouldn't be in the job :)

Hence the early objections to the kill switch.

...
>>> possible

Well.  I think the RFC should list it as a MAY so that people who read
it can be alerted to the fact that they had better figure out how this
happens and make sure it never happens on their watch.

I don't think it should be a SHOULD because I've yet to see a valid
reason for it.  All of the reasons so far presented have been handwavy,
very edge-case or development only.

And I don't see its place in the Charter.  It seems like cursing the
baby before its been born.

iang

[0] I am assuming these two exlusive modes.  This could be challenged.

---

From: Tony Arcieri <[email-masked]>
Date: Sun, 27 Apr 2014 14:07:30 -0700

> baby before its been born.

I'm not even sure why it's being considered for the charter. This is not a
feature offered by, say, full disk encryption software, even though people
may wind up double encrypting files. It's also proven not to be a problem
in practice, even though the need to decrypt bypasses things like DMA.

It seems even less important for ubiquitous network encryption, where the
network is far more likely to be the bottleneck.

-- 
Tony Arcieri

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 27 Apr 2014 22:29:32 +0100

Hi Marcelo,

>    by detecting encryption performed by upper layers (notably, when TLS

Based on all the discussion on this so far, I'd also suggest
deleting this bit. I agree with Ian that the reasons for
including this stated so far are arm-wavy. And "detecting"
that higher layers are encrypting vs. compressing seems unlikely
in the general case too. If something is using TLS then the
TLS code (which normally calls the socket API I think) can
presumably determine if TCP Inc. would be on by default and
do the right thing so there's no need for TCP Inc. to do
anything for that case even if someone concludes that double
wrapping isn't what they want.

So count me as another -1 on inclusion of the above.

That said, I think that the argument for null ciphers could
still be made later (which might be one way to deal with the
wish expressed above), and I'm sure someone will inevitably
make the argument for that for debugging purposes so since
we know it'll happen we don't really need to argue about
whether that's ok or not now:-) As I've also said before,
I'd need to be convinced that those are worthwhile myself
so as of now I'd say not defining 'em is the right thing.

S.

---

From: ianG <[email-masked]>
Date: Sun, 27 Apr 2014 22:33:54 +0100

On 27/04/2014 22:07 pm, Tony Arcieri wrote:
> On Sun, Apr 27, 2014 at 2:01 PM, ianG <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> I'm not even sure why it's being considered for the charter.

I don't understand it either.  But if you look at the tcp-crypt draft,
it's firmly in there.

http://tcpcrypt.org/draft-bittau-tcp-crypt.txt

This may be a cultural thing.  Us user folk might just not want it, but
in the WG world it might be something they can't conceive of not
mandating.  I await with interest the reasons...

However, what I'm more concerned about is that in the draft, it does the
old "cipher suite negotiation" thing.  I would have thought that was so
obviously unrequired, but apparently not.  If we have cipher suite
negotiation in there, talking about the universal kill switch is rather
moot because someone will slip in some bad ciphers.

Interesting debates ahead I suspect.  Keep your powder dry.

iang

> This is not
> a feature offered by, say, full disk encryption software, even though
> people may wind up double encrypting files. It's also proven not to be a
> problem in practice, even though the need to decrypt bypasses things
> like DMA.
> 
> It seems even less important for ubiquitous network encryption, where
> the network is far more likely to be the bottleneck. 
> 
> -- 
> Tony Arcieri

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 28 Apr 2014 07:31:50 +0200

> So count me as another -1 on inclusion of the above.

mmm, I guess i misread the previous discussion or i didnt managed to 
explain what i had in mind.

Let me try to explain myself (not trying to push for this, just want to 
clarify).

What i had in mind was _not_ about allowing the upper layer to disable 
the encryption in the middle of a connection.
What i had in mind was to allow the upper layer to say: "please for this 
connection, dont use TCP-INC, just use plain old TCP". This is because 
the upperlayer may knwo better, for instance, it is building its onw 
security.

If we dont provide this hook, then it is always encrypted if both ends 
support and there is nothing the upper layer can do in order to avoid it.

Please also note that this does not allow for the peer to downgrade the 
connection or terminate encryption, as this has no impact in the wire, 
it is only at the begining of the connection.

Does this clarify things? What do you think?

That being said, I am perfectly fine with removing it from the charter.

Regards, marcelo

---

From: ianG <[email-masked]>
Date: Mon, 28 Apr 2014 11:42:21 +0100

> the encryption in the middle of a connection.

Well, yes, I don't think anyone had that in mind.

> connection, dont use TCP-INC, just use plain old TCP".

This is understood.  I believe this will exist in implementations,
regardless, for development purposes.  I also believe the smart
implementors will realise they don't need it, and nor do their users,
and that they will solve some problems by getting rid of it (which
realisation will also infect thinking about ciphersuites).

> This is because

If the upper layer truly knew better, it wouldn't be using TCP.

Or, you might be saying, the upper layer is TLS.  In which case the
developers are going to be really annoyed by the dual layers basically
duplicating the same thing (if tcp-crypt is any guide) and is thus shear
waste.  But the users won't know any different?

And why can't the developers spend that time turning it off (with
uncertain knowledge of whether the implementation is even there) by
instead working with the TCP-crypt layer instead of against it?

> support and there is nothing the upper layer can do in order to avoid it.

Yes.  But what is the problem with that?

Obviously performance spring to mind, but many claim that is no longer
an issue.  Without getting dragged into mindless academic foodfights
about citations, the point is here that performance isn't the reason it
was in 1994, when they broke HTTPS and put half the website in the
clear.  I can't recall the last time I had to tweak SSH to use a faster
cipher for huge backups, it was probably late 1990s.

Latency could be an issue with say TLS over TCP-crypt over TCP-startup.

Secondly, you bring up dual security.  Now, the nature of security is
that a security layer cannot interfere with the data being transported,
and indeed that's reflected in the charter.  So it is not as if there
are going to be artifacts of interference in a proper implementation.

Finally, it might be worth noting that it is a general NSA
recommendation that systems should be dual-encrypted where the systems
are sufficiently independent of each other.  e.g., IPSec at the
point-to-point and PGP or SSH above that.  FWIW.

Point being, there is no clear MUST nor SHOULD here, this again is a
property that can and will emerge from the experimentation.

> That being said, I am perfectly fine with removing it from the charter.

That's what is being asked.

iang

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 28 Apr 2014 14:16:54 +0200

ok, given that we are talking about the same thing, i guess it is clear 
that there is no clear consensus to keep this in, so i will remove it 
from the charter and leave it for WG discussion

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 28 Apr 2014 15:30:11 +0300

> both the old key and the new key around for the transition period to

Of course there can be buggy IPsec implementations which do not follow
the rules set in the RFCs and which loose some packets when doing
rekeying, but same applies to any protocol.

The current IPsec specifications (IKEv2, RFC5996) do specify how rekey
happens and it is specified so that no packets are lost: i.e. first
create new Child SA proactively, i.e. before the old Child SA expires;
then wait for traffic to move to this new SA (i.e. when you see
packets on new Child SA, you know that other end has installed it);
and only then remove old Child SA.

See section 2.8 of RFC 5996.

In the IKEv1 (from 1998, obsoleted in 2005) the rekeying was not
specified properly and there quite often was problems with
implementations which caused them to loose some packets while
rekeying. Usually those old implementations did work properly against
themselves, but when talking to someone else which implemented things
differently they might have lost few packets. 
-- 
[email-masked]

---

From: Joe Touch <[email-masked]>
Date: Mon, 28 Apr 2014 08:21:12 -0700

> and only then remove old Child SA.

You can't ensure that no packets are lost that way. Once you transition 
to a new SA - even if you coordinate that handoff - there may be 
out-of-order packets that arrive after that coordination.

Those packets would be dropped, and presumably TCP would retransmit them 
using the new SA, but the receiver would still see a gap in received 
packets that might affect its congestion control.

TCP is the only one who can know when there is no outstanding gap after 
a key change, and thus when it can remove an old key without impact to 
its congestion control.

Joe

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 30 Apr 2014 16:51:36 +0300

> out-of-order packets that arrive after that coordination.

The timer to delete the old SA after the new is up (and we are seeing
traffic on the new SA) are usually in order of 5-10 seconds or
something like that, just to take care of the old packets.

If the out-of-order packet is delayed by more than 5-10 seconds before
it finally arrive to the other peer, it might already be dropped by
the replay window checks (depending how big window you are using), and
it would most likely already been considered as being lost by the
upper layers.

Note, also that after the rekey has been finished, and we have see
packets on the new SA, and when we start deleting the old SA, we still
accept packets on the old SA, because the delete is two way. I.e. we
send delete notification saying we are not going to send data our
outgoing old SA, and only when we get response back from the other
where it tells he will not be sending data on his old outgoing SA (i.e
our incoming SA), we actually delete the inbound SA.

I.e. in normal case there is no lost packets. 
-- 
[email-masked]

---

From: Joe Touch <[email-masked]>
Date: Wed, 30 Apr 2014 08:09:13 -0700

> it would most likely already been considered as being lost by the

But in that case the replay prevention would be dropping packets that 
could be valid (i.e., they're only replayed if the particular byte range 
overlaps, but merely if it's "earlier than expected".

...
> I.e. in normal case there is no lost packets.

You just said that replay would drop them - that's a drop TCP would see 
too.

Joe