Subject: [Tcpcrypt] Draft charter text

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 02 Apr 2014 17:59:14 +0200

Hi,

It seems a good time to start talking about the charter.
Please find an initial draft on a possible charter.
Comments would be appreciated.

TCP anonymous encryption (TAE)

Anonymous encryption is an anonymous 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 TAE WG will define mechanisms for anonymous encryption of TCP 
connections.
The WG will define the TCP extensions needed to provide privacy and 
integrity
protection of TCP connections. The working group is
looking to produce experimental documents specifying the required TCP 
extensions
for anonymous encryption and any additional informational documents needed.

The high-level requirements for the TCP anonymous encryption protocol are:

- Deployable and usable without significant changes to existing Internet
   infrastructure;

- 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 higher-level 
authentication must be
   made available.  The WG will not work on new authentication mechanisms.

- The protocol must have acceptable performance.  For example, session 
caching
   should be used to avoid expensive public key operations on connection 
set up.

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 anonimous encryption for 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 higher layer authentication 
mechanisms, the
expected protection and residual threats.

- Extensions to current TCP to support anonimous encryption. This covers 
all the
   protocol changes to support anonimous encryption. 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 higher 
layer authentication
will be defined in this document. This will be an informational document.

Regards, marcelo

---

From: Derek Fawcus <[email-masked]>
Date: Fri, 4 Apr 2014 13:37:30 -0700

On Wed, Apr 02, 2014 at 05:59:14PM +0200, marcelo bagnulo braun wrote:
> - 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)

I'd suggest that the TCP header should also be protected;
otherwise one can't easily detect the situation where a MitM spoofs
FIN or RST to force a connection closed.

As I recall (it's been a while since I last read it),  the current tcpcrypt
draft does provide such protection.

So do you mean discuss wrt to if the charter should cover this,  or keep charter
as above and discuss within context of protocol discussions?

.pdf

---

From: Brandon Williams <[email-masked]>
Date: Fri, 04 Apr 2014 16:48:06 -0400

I read this to indicate discussion within the context of the protocol 
discussions. I think this requires some discussion and a resolution to 
the question shouldn't be required for approving the charter.

--Brandon

On 04/04/2014 04:37 PM, Derek Fawcus wrote:
> _______________________________________________
> Tcpcrypt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpcrypt
>

-- 
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 05 Apr 2014 08:49:55 +0200

Yes, this is what the current text means to say.

---

From: Paul Lambert <[email-masked]>
Date: Tue, 8 Apr 2014 14:52:05 -0700

On 4/2/14, 8:59 AM, "marcelo bagnulo braun" <[email-masked]> wrote:

>without authentication.

Is the key discovered used at all in a ³sticky² manner?

That is, does the ³anonymous" connection maintain the discovered key and
associated state to ensure that subsequent connections to the same site
use the same key?

Hopefully yes Š  if not, this activity is a hazard.

Paul

>This is better than plain-text because it thwarts

---

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

Yes, i agree, we should add this as a requirement and also to understand 
the security implications of that approach (i.e. once fooled, fooled for 
ever)

I think we may want to include a directionality restriction on the re 
use of the keys i.e. a host can only re use the keys it obtained when 
establishing a tcpcrypt as a client only in connections that it is 
actively opening and not for the oens it is serving as a server.

I think the reuse requirement shoudl be included in the charter in a 
mild way and leave how much it shold be limited for discussion in the WG?

---

From: Derek Fawcus <[email-masked]>
Date: Wed, 9 Apr 2014 01:44:23 -0700

On Tue, Apr 08, 2014 at 02:52:05PM -0700, Paul Lambert wrote:
> Is the key discovered used at all in a "sticky" manner?
> 
> That is, does the "anonymous" connection maintain the discovered key and
> Hopefully yes -  if not, this activity is a hazard.

I take it in the above you're referring to the public key discovered?

i.e. similar behaviour to how openssh records an  public key for an
unknown location in its known_hosts file,  and checks for a change
upon reconnect.

(I initially read the above as session state caching ala SSL)

.pdf

---

From: Sandeep Kumar <[email-masked]>
Date: Wed, 9 Apr 2014 11:42:05 +0200

Maybe off topic but will there be a similar effort for UDP?

regards
Sandeep

On Wed, Apr 2, 2014 at 5:59 PM, marcelo bagnulo braun <[email-masked]>wrote:

>   scenarios where people are unwilling to do any change just for the sake
> of
>   applications or users.  However, hooks for higher-level authentication
> must be
> - A framework for anonimous encryption for TCP connections. This document
> will
> of the proposed mechanism, the interaction with other security mechanisms
> in different
> - An extended API describing how applications can obtain further benefits
> of the
> proposed extensions. In particular, the hooks for supporting higher layer
> authentication

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 09 Apr 2014 14:44:28 +0200

> (I initially read the above as session state caching ala SSL)

well, yes, you could even record more crypto material, so you can 
automatically generate a new session key for new connections. again, i 
guess this is to be discussed while working out the actual protocol

regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 09 Apr 2014 14:45:28 +0200

mmm, it was not envisioned to include this in this effort.

El 09/04/14 11:42, Sandeep Kumar escribió:
> On Wed, Apr 2, 2014 at 5:59 PM, marcelo bagnulo braun 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     passive eavesdropping, but is weaker than using authenticated
>     keys, because it
>     effort to harness the Internet architecture given the latest
>     events of pervasive
>     The WG will define the TCP extensions needed to provide privacy
>     and integrity
>     looking to produce experimental documents specifying the required
>     TCP extensions
>       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
>       scenarios where people are unwilling to do any change just for
>     the sake of
>     - The protocol must have acceptable performance.  For example,
>     session caching
>       should be used to avoid expensive public key operations on
>     connection set up.
>
>     example, both Multipath TCP and TCP Fast Open require proof that
>     some connections are
>     related.  Session resumption and Message Authentication Codes
>     (MACs) can provide
>     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.
>
>     describe basic design considerations, including the motivation and
>     the applicability
>     layers of the stack, the interaction with higher layer
>     authentication mechanisms, the
>     - Extensions to current TCP to support anonimous encryption. This
>     covers all the
>     proposed extensions. In particular, the hooks for supporting
>     higher layer authentication
>     [email-masked] <mailto:[email-masked]>

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 09 Apr 2014 09:23:50 -0400

> Is the key discovered used at all in a ³sticky² manner?

afaict, the proposed charter doesn't mention any sort of persistent
keying at all, and its scope could be met by an entirely ephemeral
approach.  The "hooks for higher-level authentication" can be met by
exporting a derived value that would be a shared secret both parties to
the transaction should know.

That said, i can imagine some schemes that use persistent keys as well,
and the charter doesn't seem to rule out one scheme or the other.

> associated state to ensure that subsequent connections to the same site

by "site" i think you mean host+port.  is that correct?

What are you proposing the TCP stack should do if it sees that the
discovered key for the peer's host+port has changed?

Should it refuse to complete the connection?  should it fallback to
plain (cleartext) TCP?  Should it send an alert to somewhere higher in
the stack and allow the connection to proceed otherwise?

Should it have the same behaviors when acting as both client (connect())
and server (accept())?

So, assuming the proposed scheme will offer persistent keying, and if
you're advocating connection refusal, then you need to provide a
plausible story about what to do in the event of legitimate re-keying
for any long-term key material.

The recent fun and games with heartbleed make it clear that there are
legitimate scenarios for the rotation of persistent keys.  Any scheme
that would cause connection failures in the face of such a legitimate
key rotation smells dangerous to me, and it seems likely that naturally
conservative system administrators would not want to deploy such a
scheme for fear of locking out their users when they do ultimately need
to rotate keys.

> Hopefully yes Š  if not, this activity is a hazard.

Do you still consider this a hazard if the architecture we end up at
does not require any persistent keying at all?

Regards,

	--dkg

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 09 Apr 2014 14:31:32 +0100

>> Maybe off topic but will there be a similar effort for UDP?

The only worked-out thing I've see was QUIC which was
presented at IETF-88 [1] but which is just a company
internal thing as far as I know. There are probably
other similar proposals about as well of course.

I guess one could argue that a lot of the same issues
might arise for potential solutions over TCP and UDP
but I'm not sure if it'd be wise to extend the scope
so much, at least at the start. OTOH, now is I guess
the right time for considering that kind of thing,
so good question!

S.

[1] http://www.ietf.org/proceedings/88/slides/slides-88-tsvarea-10.pdf

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 09 Apr 2014 15:57:11 +0200

El 09/04/14 15:31, Stephen Farrell escribió:
> so much, at least at the start.

I agree

> OTOH, now is I guess

---

From: Erik Nygren <[email-masked]>
Date: Wed, 9 Apr 2014 10:47:39 -0400

Do we explicitly need to call out that the solution should work across NAT,
or is that covered by "Deployable and usable without significant changes to
existing Internet infrastructure"?  It seems likely that this (and other
similar use-cases) will come into conflict with header protections.

      Erik

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 09 Apr 2014 16:54:59 +0200

I am not sure i understand your point: do you disagree with the 
requirement that the solution should work across nats or you just think 
it is redundant with the deployability requirement?

El 09/04/14 16:47, Erik Nygren escribió:
> Do we explicitly need to call out that the solution should work across 
> NAT, or is that covered by "Deployable and usable without significant 
> changes to existing Internet infrastructure"?  It seems likely that 
> this (and other similar use-cases) will come into conflict with header 
> protections.
>
>       Erik
>
>
> On Fri, Apr 4, 2014 at 4:37 PM, Derek Fawcus 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 09 Apr 2014 11:39:12 -0400

> TCP anonymous encryption (TAE)

While the proposed outline does start as anonymous encryption, the
requirement for hooks for higher-level authentication doesn't feel like
anonymous encryption to me.  I wonder if this choice of name will cause
people to think that authentication is supposed to be impossible with
this scheme, rather than supported-but-not-baked-in.

>   caching should be used to avoid expensive public key operations on
>   connection set up.

I'm not sure that we want the term "session caching" in the charter,
mainly because:

 a) it's not clear what a "session" is without a clearer specification
of the protocol, and

 b) it seems to rule out any architecture that doesn't permit something
that could be called "session caching", even if we come up with an
session-less architecture that is more performant.

> - A framework for anonimous encryption for TCP connections. 

spelling nitpick: i think you mean "anonymous" here (and three other
places in the text)

> (it is open for discussion for the WG if the TCP header should or
> not be protected) 

If the TCP header is protected, how will this interoperate with
widespread packet-mangling mechanisms like NAT?

I would love to see NAT die a quiet death, but it doesn't seem likely to
happen any time soon.  if we design a spec that breaks when used across
NAT, i doubt it will see much useful deployment :(

Privacy Considerations
----------------------

This charter makes no mention of any privacy considerations as
first-order concerns.  Two immediate considerations spring to mind:

 0) can a passive eavesdropper link two distinct sessions with each
other using whatever extension information is present in the packets?
Consider Alice checking her e-mail from a laptop.  If the exposed data
are not unlinkable, a network observer who watches traffic at the
mailserver can tell which network locations Alice connects from, at what
times.

 1) can the server link two subsequent connections from a given client?
 in some cases, a client will want to provide some proof of continuity
to a server (e.g. maintaining an authenticated session across a series
of TCP connections).  In other cases, the client will want to be able to
mask the fact that it is the same client to the server (e.g. when
connecting to widely-used advertising servers, analytics sites, or CDNs,
clients that want to avoid leaking their browsing history to the backend
might prefer to keep these connections unlinkable).  What mechanisms
would such a spec provide to be able to accomodate both cases?

Do we want the group to consider these privacy considerations (i do)?
if so, should they be included in the charter?

Regards,

	--dkg

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 09 Apr 2014 16:44:53 +0100

On 04/09/2014 04:39 PM, Daniel Kahn Gillmor wrote:
> requirement for hooks for higher-level authentication doesn't feel
> like anonymous encryption to me.  I wonder if this choice of name
> will cause people to think that authentication is supposed to be
> impossible with this scheme, rather than
> supported-but-not-baked-in.
> 

There's an ongoing debate on saag that seems to be closing
in on defining the term "opportunistic security" for this
kind of thing. I'd say debating terminology here is probably
not needed (debating the details of what security you do get
is needed of course here and/or in a wg) but this charter text
and that activity on terminology can sync up when the time's
right.

Cheers,
S.

---

From: John-Mark Gurney <[email-masked]>
Date: Wed, 9 Apr 2014 09:02:50 -0700

> widespread packet-mangling mechanisms like NAT?

The original tcpcrypt paper talks about nat traversal and includes a
link to a paper talking about that....  It isn't just nat traversal
that we have to worry about.. There are some transparent proxies that
will munge sequence numbers too...

This is why the tcpcrypt protocol integrated a relative sequence number
and not the absolute, so that the sequence numbers could be munged...

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

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

---

From: John-Mark Gurney <[email-masked]>
Date: Wed, 9 Apr 2014 09:07:26 -0700

> the stack and allow the connection to proceed otherwise?

I was thinking about this...  It should always use the new key material,
any other solution would defeate the point of the protocol..

Now an interesting question is, what happens when the authentication
layer fails to authenticate the remote host, and there are other
unauthenticated connections to the remote host?  Could it be that the
auth failed because the credentials just didn't match?  Should there
be an option to "kill" the other connections to the remote host because
you happen to know that there is an active MITM attack?

But clearly this will need to be discussed as part of the WG, but
from what I read, (besides the minor nit picks others have pointed
out), it looks like it will scope the problem well...

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 09 Apr 2014 12:21:57 -0400

On 04/09/2014 11:44 AM, Stephen Farrell wrote:
> kind of thing.

I'm aware of that saag saga, and look forward to its conclusion.

> I'd say debating terminology here is probably

that sounds fine to me.  i just wouldn't want us to have to wait on the
conclusion of that debate in order to move forward with tcpcrypt.

if we can move forward calling it TAE and then  just quickly rename it
to TOS (or whatever the outcome of the saag mishegas is) when the time
comes, that would be ok.

I hope people will respond to the substantive questions raised in this
exchange (in particular, the Privacy Considerations) and not the
terminology wrangling.

	--dkg

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 09 Apr 2014 17:25:45 +0100

On 04/09/2014 05:21 PM, Daniel Kahn Gillmor wrote:
>> There's an ongoing debate on saag that seems to be closing in on
>> defining the term "opportunistic security" for this kind of
>> thing.
> 
>> I'd say debating terminology here is probably not needed
>> (debating the details of what security you do get is needed of
>> course here and/or in a wg) but this charter text and that
>> activity on terminology can sync up when the time's right.
> 
> that sounds fine to me.  i just wouldn't want us to have to wait on
> the conclusion of that debate in order to move forward with
> tcpcrypt.
> 
> if we can move forward calling it TAE and then  just quickly rename
> it to TOS (or whatever the outcome of the saag mishegas is) when
> the time comes, that would be ok.

Yep. We won't block on that.

> 
> I hope people will respond to the substantive questions raised in
> this exchange (in particular, the Privacy Considerations) and not
> the terminology wrangling.

And yep:-)

S.

> 
> --dkg
> 
> 
> 
> _______________________________________________ Tcpcrypt mailing
> list [email-masked]

---

From: Paul Lambert <[email-masked]>
Date: Wed, 9 Apr 2014 10:22:48 -0700

>I take it in the above you're referring to the public key discovered?
Yes.  

>unknown location in its known_hosts file,  and checks for a change
Also yes.

This is a very important difference from not every checking the public key
that is being used.

We should NOT mix the ³sticky² mode and ³don¹t care what key² mode of
operations without clear indication to the user.

I would strongly prefer only the ³sticky mode² where clear indications
(akin to SSH) of state changes are given for:
 - new key for new peer
 - warning on new key for existing peer/key

Paul

---

From: MARCELO BAGNULO BRAUN <[email-masked]>
Date: Thu, 10 Apr 2014 08:50:34 +0200

> this scheme, rather than supported-but-not-baked-in.

what stephen said.
We initially called it transport level oportunistic encryption, but we 
didnt wanted to end un in a terminology discussion here so we called it 
anonymous encryption, but i agree the name is at odds with the higher 
layer authentication add on

we should wait for saag to finish their discussion or if you have a 
better name suggestion, please go ahead

> session-less architecture that is more performant.

agree
we should probably call it crypto material re use, or something along 
those lines, similar to what we are discussing with Paul Lambert in the 
other thread. Actually i should have brought this up in that context...

> spelling nitpick: i think you mean "anonymous" here (and three other

right, thanks

> NAT, i doubt it will see much useful deployment :(

right, but it is up for discussion in the WG, so we can figure it out 
later. besides it is not an all or nothing disucssion, right? We can 
decide to protect those fields that are less changed by middle boxes.

I guess as you say, that doesnt make sense to aim to protect the 
addresses and port fields, as it would be incompatible with nats.

One discussion is whether we aim to protect the seq number and the ack 
number. This wouldnt break with nats but with other middle boxes.

This is also related with where to carry the crypto information (like 
the hmac for the payload). If we want to protect some of the tcp header 
fields, then we should carry the hmac in tcp options, as it becomes 
harder to send the hmac in the payload, as ack many times dont carry 
data, so you may end up consumin seq number space when sending empty 
acks... so in a nutshell, this seems like a long discussion that is 
central to the solution design, that is why we propose to have it once 
the wg is formed, makes sense?

> Privacy Considerations

yes and yes

do you mind if i ask you to suggest the text you would like to see 
included in the charter?
do you think we need a specific deliverable in security (both security 
and privacy aspects?)

Regards, marcelo

-- 
----
MARCELO BAGNULO BRAUN
WebCartero
Universidad Carlos III de Madrid

---

From: Joe Touch <[email-masked]>
Date: Fri, 11 Apr 2014 13:37:33 -0700

On 4/9/2014 11:50 PM, MARCELO BAGNULO BRAUN wrote:
>> anonymous encryption to me.

Or me either; anonymous encryption is useful independent of whether 
higher-level hooks are provided or not.

(IMO that was a mistake made when BTNS was being worked; the original 
concept of AE was IMO warped into necessarily including channel binding 
and connection latching, which severely limits the benefit of AE --- 
CB/CL just move the need for key distribution to a different layer, 
whereas true AE can avoid it with lesser benefit).

> better name suggestion, please go ahead

SAAG is trying to redefine widely-cited terminology; that seems like a 
bad idea.

Further, there's a difference between anonymous and 'keyless'. Anonymous 
implies lack of traceability, which is harder to prove.

Most of the time I've seen "anonymous" it means "keyless", as in 
unsigned Diffie-Hellman.

On the SAAG list, I offered a few alternatives (all of which were 
dismissed, of course), depending on what's being described:

	zero-key

	zero-ID

These play off of "zero-configuration" and "zero-touch" network 
management, and IMO still might be useful if you're interested in a 
descriptive term (rather than trying to redefine a long-cited one).

...
> addresses and port fields, as it would be incompatible with nats.

FWIW, that has its merits (NATs are an attack that some security 
protocols are designed to protect against).

TCP-AO isn't compatible with NATs, but there is an extension that is, FWIW.

> number. This wouldnt break with nats but with other middle boxes.

There is no way to protect the signalling part of TCP and be compatible 
with rewriting NATs; IMO such compatibility should be out of scope.

> the wg is formed, makes sense?

That's why TCP-AO has its HMAC as a header option.

FWIW, I also posted a way to use TCP-AO for encryption.

Joe

---

From: MARCELO BAGNULO BRAUN <[email-masked]>
Date: Sun, 13 Apr 2014 09:09:02 +0200

Joe Touch <[email-masked]> dijo:

> concept of AE was IMO warped into necessarily including channel 
> binding and connection latching, which severely limits the benefit of 
> AE --- CB/CL just move the need for key distribution to a different 
> layer, whereas true AE can avoid it with lesser benefit).
>
> SAAG is trying to redefine widely-cited terminology; that seems like 
> a bad idea.
>
> Further, there's a difference between anonymous and 'keyless'. 
> Anonymous implies lack of traceability, which is harder to prove.
>
> There is no way to protect the signalling part of TCP and be 
> compatible with rewriting NATs; IMO such compatibility should be out 
> of scope.
>

---

From: Andrea Bittau <[email-masked]>
Date: Sun, 13 Apr 2014 08:56:47 -0700

Here're some comments on points raised (I hope I covered it all):

* Header protection.  We probably can't encrypt most of the header without
  breaking NATs but there probably are fields we can MAC without breaking NATs
  (e.g., relative sequence numbers).

  There could also be a software enabled mode where MACing certain fields is
  mandatory - e.g., MACing the RST, enabled maybe on BGP connections.

* "sticky" a la SSH keys.  This is an application-layer concern (where
  authentication is performed) - not something to be tackled at the transport
  layer.  Care must be taken with the forward secrecy requirement and the
  solution must work with load balancers / connecting to different backends.

  For what it's worth, session caching at the transport layer is a temporary,
  poor man's implementation of this - if there was no man-in-the-middle on the
  first connection, the subsequent cached connections are safe.

* UDP.  The fundamental advantage in TCP is the existing three way handshake
  where we can signal whether tcpcrypt is available or not.  This gives us
  transparent incremental adoption.  In UDP we don't have this.  So an
  application layer solution will probably be as good as a transport layer
  solution (both face the same bootstrap problem).  Unless you do crazy things
  like send the first UDP packet with an invalid but fixed "UDPCrypt" checksum
  to signal that you want to start encrypting - but that's a whole different
  mess in itself that is out of scope for this effort.

* NATs & Middleboxes.  The solution must work with them.  The goal should be
  that wherever TCP works, tcpcrypt works, too (maybe disabled initially).

* Session caching.  I agree that it's not fundamental but rather it's a
  performance optimization.  Hey if a scheme that is always fast exists, then
  that's good enough.  The high level requirement is that it should be fast
  enough that you can turn it on by default.  (A session, in practice, is a TCP
  connection.)  I'm not sure how to avoid public key operations for connection
  establishment and that's why we thought session caching should be a
  requirement in practice, as we want to avoid having public key operations for
  each connection.

* Privacy considerations.  Traffic analysis and side-channels are out of scope.
  Trying to detect users by IP address, port addresses, time, traffic patterns
  (packet lengths and inter-packet intervals) is something we should not require
  to defend against.  This is not intended to be a Tor-like solution.  If,
  however, two sessions cannot be linked from the information stated above, they
  should not be linkable by the way we encrypt layer-7 data.  I'd be happy to
  make that a requirement - namely that any encryption (or metadata added by
  tcpcrypt) does not add to a packet's "linkability" to a user or previous
  connection (of course we cannot deal with lower layers or traffic analysis as
  stated).

* Authentication failures & some fail some don't to same host.  There's a
  synergy between multipath TCP and tcpcrypt - it's harder to mount attacks
  because the attacker has to be on path on each connection, and it's easier to
  detect (and potentially kill) one path that is misbehaving.  In any event,
  authentication failures are application-specific problems.  In a web browser
  that supports authentication and mandates it, you'll probably get a red screen
  with a certificate failure.  An e-mail client will probably pop-up a dialog
  saying unable to connect / verify server identity.  The default, where there
  is no authentication and the application is tcpcrypt-unaware, means that the
  connection will always succeed and that the user will not even be aware that
  the connection is encrypted (or not).  Nothing changes from the app's and
  user's perspective.  There's only the added bonus of encryption if no
  man-in-the-middle is present.

* Exposing hooks for authentication (e.g., Session ID).  We do not require
  authentication, so exposing a hook for it does not provide any harm in my mind
  as it can simply be ignored by all.  If anything, exposing the hook will make
  the protocol more future proof.  For example, it can avoid double encryption -
  the application has a way of verifying that the layer-4 encryption is safe and
  does not need to redo its own encryption, but rather it merely includes the
  Session ID in its (possibly already existing) authentication.  Plus, after
  doing all the hard work of setting up an encrypted channel, it seems
  reasonable to take the extra step to expose a simple hash which can be used to
  greatly improve the security guarantees provided.  We don't want to limit our
  security guarantees by design.

On Sun, Apr 13, 2014 at 12:09 AM, MARCELO BAGNULO BRAUN
<[email-masked]> wrote:
>> concept of AE was IMO warped into necessarily including channel binding and
>> connection latching, which severely limits the benefit of AE --- CB/CL just
>> move the need for key distribution to a different layer, whereas true AE can
>> avoid it with lesser benefit).
>>
>> SAAG is trying to redefine widely-cited terminology; that seems like a bad
>> idea.
>>
>> Most of the time I've seen "anonymous" it means "keyless", as in unsigned
>> Diffie-Hellman.
>>
>> FWIW, that has its merits (NATs are an attack that some security protocols
>> are designed to protect against).
>>

---

From: Erik Nygren <[email-masked]>
Date: Sun, 13 Apr 2014 12:45:43 -0400

Thank you for this summary.

Along the lines of application hooks, do we want a way for the application
layer to be able to safely disable encryption part way through a
connection? For example, tcpcrypt may be a good way of protecting the
initial TLS handshake (eg, protecting parts of it from passive
surveillance) but once the TLS session is established it may be redundant
enough that we may wish to let the applications agree to drop back to
plain-text at the TCP layer.  Any negotiation here presumably needs to be
mutual and properly covered by whatever authentication the tcpcrypt
connection has.

A side-note on NATs:  authenticating RSTs could be problematic when a NAT
times out a connection and starts reusing source ports (perhaps for a
different client to the same server), especially if the client and server
on either end using tcpcrypt are unaware of this.  There are a bunch of
annoying corner-cases in this area.

Would we ever want a middle-box (eg, a NAT or transparent proxy) to be able
to opportunistically terminate tcpcrypt on both ends?  While this is
something that active attackers will also try and do, supporting it may
allow for helpful middle boxes to give protections even for clients that
don't support it.  For example, if a users' home NAT gateway did tcpcrypt
out to any servers in the world then they could gain some protection from
passive pervasive surveillance even for older client software in their home.

      Erik

On Sun, Apr 13, 2014 at 11:56 AM, Andrea Bittau <[email-masked]>wrote:

> like
> and
> bad
> unsigned

---

From: Joe Touch <[email-masked]>
Date: Sun, 13 Apr 2014 10:41:18 -0700

>    (e.g., relative sequence numbers).

You should be able to protect parts of the IP and TCP headers (and, 
FWIW, both are necessary to protect IP). Skipping the source port and 
source IP address might not have a big impact on overall effectiveness.

>    mandatory - e.g., MACing the RST, enabled maybe on BGP connections.

You need to MAC the IP dest, dest port, and all signal bits in the IP 
header (sequence, flags, etc.). This will still make it through a NAT, 
but will break a 'rewriting proxy' - but that's the kind of attack that 
TCP crypto ought to protect against, because it's indistinguishable from 
a MITM attack (it *is* a MITM).

>    first connection, the subsequent cached connections are safe.

That won't work if addresses are shared, e.g., behind a NAT.

>    that wherever TCP works, tcpcrypt works, too (maybe disabled initially).

Some solutions ought to work with simple NATs, some ought to protect 
against all rewriting, and nothing is going to be compatible with TCP 
rewriting.

>    synergy between multipath TCP and tcpcrypt

FWIW, can we please use a different acronym for the solution of this 
charter vs. the existing mechanism called tcpcrypt? This sort of comment 
is difficult to understand otherwise.

Maybe call this TCPsec? or tcpcrypto?

>    authentication,

Who's "we"? Are you referring to an existing approach, or this group?

IMO, integrity protection is critical - encryption is useless IMO 
without it. Authentication that ties to a known identity is less so (see 
BTNS), but it's still important to be able to know that the party 
involved hasn't changed.

TCP-AO demonstrates that the session ID for TCP is already there - it's 
the TCP connection + ISNs. There's no need for additional session info.

Joe

---

From: Joe Touch <[email-masked]>
Date: Sun, 13 Apr 2014 10:44:05 -0700

On 4/13/2014 9:45 AM, Erik Nygren wrote:
> Along the lines of application hooks, do we want a way for the
> application layer to be able to safely disable encryption part way
> through a connection?

TCP has no mechanism to do a new handshake mid-connection. Once an 
option is set during the initial handshake, it should be assumed to be 
persistent across the connection.

A better solution, if the goal is to be lightweight, is to change keying 
parameters during the connection, at which point the new parameter can 
be "null".

See again TCP-AO for an exampple of how to coordinate keying parameter IDs.

> A side-note on NATs:  authenticating RSTs could be problematic when a
> NAT times out a connection and starts reusing source ports (perhaps for
> a different client to the same server), especially if the client and
> server on either end using tcpcrypt are unaware of this.  There are a
> bunch of annoying corner-cases in this area.

This issue was discussed in TCP-AO too; IMO, the recommendation there 
(for authentication) is just as relevant here.

Joe

---

From: Tony Arcieri <[email-masked]>
Date: Sun, 13 Apr 2014 10:47:53 -0700

On Wed, Apr 2, 2014 at 8:59 AM, marcelo bagnulo braun <[email-masked]>wrote:

> without authentication

Will this idea be compatible with future authentication systems, i.e. could
some mechanism verify public keys for you, then hand off the rest of the
session to tcpcrypt?

-- 
Tony Arcieri

---

From: Erik Nygren <[email-masked]>
Date: Sun, 13 Apr 2014 13:54:26 -0400

On Sun, Apr 13, 2014 at 1:41 PM, Joe Touch <[email-masked]> wrote:

> header (sequence, flags, etc.). This will still make it through a NAT, but
> will break a 'rewriting proxy' - but that's the kind of attack that TCP
> crypto ought to protect against, because it's indistinguishable from a MITM
> attack (it *is* a MITM).
>

Unfortunately, applying a MAC on the IP dest will break NAT64 which is a
valid and increasingly critial use-case.

     Erik

---

From: Joe Touch <[email-masked]>
Date: Sun, 13 Apr 2014 11:10:21 -0700

On 4/13/2014 10:54 AM, Erik Nygren wrote:
> On Sun, Apr 13, 2014 at 1:41 PM, Joe Touch <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>     You need to MAC the IP dest, dest port, and all signal bits in the
>     IP header (sequence, flags, etc.). This will still make it through a
>     NAT, but will break a 'rewriting proxy' - but that's the kind of
>     attack that TCP crypto ought to protect against, because it's
>     indistinguishable from a MITM attack (it *is* a MITM).
>

If you avoid MACing any address or port info (except perhaps dest port), 
then all you have left to identify your connection is the ISN pair, and 
that seems a bit dangerous.

Joe

---

From: John-Mark Gurney <[email-masked]>
Date: Sun, 13 Apr 2014 13:37:17 -0700

> some mechanism verify public keys for you, then hand off the rest of the

Yes, as long as the new authentication system can authenticate a
token (stream of bytes), then it will be compatible...  It will require
extensions to the protocol to be compatible...  Tcpcrypt had to add
to the TLS protocol to provide the ability to authenticate the session
tokens that tcpcrypt generated...

You did drop part of the message that talks about what you're asking:
In particular, the hooks for supporting higher layer authentication
will be defined in this document.

---

From: John-Mark Gurney <[email-masked]>
Date: Sun, 13 Apr 2014 13:42:02 -0700

> higher-level hooks are provided or not.

I would say <insert perfered term here> w/o the hooks isn't useful...
Because either it will need to provide a knob to turn it off (for SSL
to prevent double encryption), or we'll suffer double encryption,
meaning the layer will be redundant and admins will intentially turn it
off to reduce the load on their boxes, defeating the benifits of always
on encryption...

---

From: John-Mark Gurney <[email-masked]>
Date: Sun, 13 Apr 2014 13:50:31 -0700

> that seems a bit dangerous.

How/Why is that dangerous?

If it is used w/ an authentication layer that authenticates that the
session hash is the same on both sides, how is this dangerous?  The
authentication layer has stated that the session key is known only to
the end points, and not to any MITM.

MAC'ing the IP/port info will prevent 90% of the internet from using
it was most end users are behind NATs...  Be it a corrporate nat, or
the nat their ISP provided so that they are only allocated one IP...

---

From: John-Mark Gurney <[email-masked]>
Date: Sun, 13 Apr 2014 13:54:35 -0700

> passive pervasive surveillance even for older client software in their home.

This is an interesting use case...  There are corporations that require
all sessions to be logged/decrypted at an edge box they control...
Some of these boxes have a private wild card cert that is installed on
all client boxes...

Now that I think about it, there wouldn't need to be much changed
to support the new protocol... It's basicly the same in that they
have to intercept the TLS (or other auth layer) do the necessary
rewriting, and sign with their private key...  I can't think of a
reason that it wouldn't work for these boxes...

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sun, 13 Apr 2014 18:17:14 -0400

> * Privacy considerations.  Traffic analysis and side-channels are out of scope.

I'm not sure that all side-channels are out-of-scope.  For example, I'd
be sad if we came up with a proposal that did not have a clear, strong,
plausible, implementable recommendation that the cryptographic
operations used in whatever scheme we come up with should be constant-time.

Traffic analysis is much harder to defend against in a principled
fashion -- i think it might make sense to leave that as out-of-scope for
this working group.

>   to defend against.

I agree with this.

>   If, however, two sessions cannot be linked from the information stated above, they

I like this way of framing the constraints.  perhaps something like this
could be used in the charter?

	--dkg

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 13 Apr 2014 23:26:30 +0100

On 04/13/2014 11:17 PM, Daniel Kahn Gillmor wrote:
> fashion -- i think it might make sense to leave that as
> out-of-scope for this working group.

I note that the HTTP/2.0 work has included a mechanism
for traffic padding. I'm not sure that we (yet) know how
to use that well, but its existence might be a good thing
as we learn more/better how to counter traffic analysis.

I'm not sure if something similar would or would not make
sense here but at least considering it probably would make
sense as there are presumably many TCP sessions where the
packet sizes alone could reveal an awful lot.

Of course it could also be that transport folks have looked
at this in the past and reached some conclusions already.

S.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sun, 13 Apr 2014 22:43:12 -0400

> do you mind if i ask you to suggest the text you would like to see

sure, i'd probably start with something along the lines that Andrea
Bittau recommended.

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

does this sound reasonable?

	--dkg

---

From: Joe Touch <[email-masked]>
Date: Sun, 13 Apr 2014 22:01:03 -0700

> valid and increasingly critial use-case.

Well, you don't *need* to MAC anything in the header per se, but the 
less you protect, the more you're not protected.

NAT64 is another kind of attack that integrity protection is designed to 
prevent, but it's always possible to lower the defense level and still 
end up with "better than nothing".

Joe

---

From: Joe Touch <[email-masked]>
Date: Sun, 13 Apr 2014 22:06:22 -0700

> How/Why is that dangerous?

It increases the chance of reusing information across connections. It 
also makes it easier to have an attack that consumes receiver resources.

> session hash is the same on both sides, how is this dangerous?

The "session hash" would consist of only the session ID info that isn't 
rewritten; the more you rewrite, the less info is used in that hash - 
and the weaker it becomes.

> The

See above.

> the nat their ISP provided so that they are only allocated one IP...

MAC'ing the dest IP and dest port is weaker than MAC'ing both IP addrs 
and ports, but stronger than MAC'ing nothing.

See TCP-AO NAT traversal mode (RFC 6978); it can be done, but it seems 
preferable to support just the NAT on one side (source addr/port).

Joe

---

From: Joe Touch <[email-masked]>
Date: Sun, 13 Apr 2014 22:08:46 -0700

> off to reduce the load on their boxes, defeating the benifits of always

Double encryption happens all over the place - TLS over WPA, e.g.

It's not only not bad, it has important utility (protecting E2E 
connections vs. protecting the link layer).

When load is an issue, encryption at every layer is susceptible to being 
disabled - but we're approaching the point where we eat the cost because 
we want the benefit. The same happened for VM - we do double-lookups all 
over the place because it's useful; it's certainly not efficient.

Joe

---

From: MARCELO BAGNULO BRAUN <[email-masked]>
Date: Mon, 14 Apr 2014 17:10:40 +0200

below...

> mutual and properly covered by whatever authentication the tcpcrypt

i think we should include a requirement that the app layer should be 
able to request no encrryption i.e. regular TCP. An extended API should 
allow for this.

> annoying corner-cases in this area.

Right, i believe there is a tradeoff between how much security you 
include in the RST and the number of cases the RST actually serves its 
purpose.
I think this tradeoff should be assesed and some design decision need 
to be taken by the WG

> passive pervasive surveillance even for older client software in their home.

I think this is inherent to oportunistic encryption, no? I mean, 
whithout authentication, the solution is vulnerable to MiTM, hence this 
would be possible, i believe.

Regards, marcelo

---

From: MARCELO BAGNULO BRAUN <[email-masked]>
Date: Mon, 14 Apr 2014 17:13:09 +0200

> some mechanism verify public keys for you, then hand off the rest of the

yes, this is expressed in the proposed charter text as hooks for upper 
layer authentication, makes sense?

regards, marcelo

---

From: MARCELO BAGNULO BRAUN <[email-masked]>
Date: Mon, 14 Apr 2014 17:17:22 +0200

below..

> off to reduce the load on their boxes, defeating the benifits of always

I think the solution should work with unmodified apps, so the extended 
API should be an optimization for apps that support it.
There are ways to avoid double encryption even witout the extended API 
(if TLS is being used, dont encrypt), which should be good enough

overall, i think the extended API for both disabling encryption and for 
the authentication hooks are important, but the solution should be able 
to work when these are not used.

makes sense?

regards, marcelo

---

From: MARCELO BAGNULO BRAUN <[email-masked]>
Date: Mon, 14 Apr 2014 17:19:12 +0200

> could be used in the charter?

yes, this makes sense

Regards, marcelo

---

From: MARCELO BAGNULO BRAUN <[email-masked]>
Date: Mon, 14 Apr 2014 17:20:48 +0200

Thanks, will use these and Andrea's text in the next version of the charter

---

From: Joe Touch <[email-masked]>
Date: Mon, 14 Apr 2014 08:26:32 -0700

> layer authentication, makes sense?

Hooks for out-of-band authentication is useful; hooks that are described 
as tying layers together are problematic - they could be interpreted as 
"channel binding", a method that can render the lower-level mechanism 
useless if absent (and thus disabling a useful mode).

Joe

---

From: John-Mark Gurney <[email-masked]>
Date: Mon, 14 Apr 2014 09:25:27 -0700

> and the weaker it becomes.

Except that each connection has an effermerial key associated w/
it that is guaranteed to be unique, and integrated into the sessions
hash, so there can't be any mixing of packets between sessions on
different ports or IPs... And it consumes no more resources than sending
random data to session forcing the receiver to validate the MAC and
when invalid, throw the data away...

Remeber, we are looking at something more interesting than basic
preset shared secrets between hosts which would be suseptible to the
attacks you describe...

> preferable to support just the NAT on one side (source addr/port).

Just read it...  All it does it sets flags to tell it to zero the
respective IP/port... i.e. the same as not MAC'ing them...

---

From: John-Mark Gurney <[email-masked]>
Date: Mon, 14 Apr 2014 09:32:22 -0700

> connections vs. protecting the link layer).

I agree that link layer encryption has it's uses....   since this is
only dealing w/ TCP, UDP, ICMP and other protocols still need to be
protected via things like WPA....

> over the place because it's useful; it's certainly not efficient.

Except that TLS + tcpcrypt is double encryption at the same layer...
Most wifi encryption is now done by hardware, so doesn't have a
significant impact on CPU usage, though TLS + tcpcrypt will usually be
done by the CPU...  Even a fast modern CPU not using dedicated
instructions can only do ~150MB/sec for AES-GCM...  Using double
encryption means immedately half that performance...

That's a pretty steep price to pay...

---

From: Joe Touch <[email-masked]>
Date: Mon, 14 Apr 2014 09:44:26 -0700

> when invalid, throw the data away...

You're assuming a unique ephemeral key per connection - how did you get 
that? Both ends have to use the same info, so you're basing it solely on 
the ISNs if all the address and port info can change. That's a lot 
weaker - and susceptible to collision on different connections - that 
using at least some address and port info.

> preset shared secrets between hosts which would be suseptible to the

See TCP-AO; I am too.

> respective IP/port... i.e. the same as not MAC'ing them...

I gave it as an example that does support NAT, but recommends against 
zeroing the IP/port on both sides.

Note too that zeroing values gives a different MAC value than not MACing 
them (i.e., you have to be specific in how values are excluded to ensure 
endpoint compatibility).

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 14 Apr 2014 09:50:58 -0700

...
> Except that TLS + tcpcrypt is double encryption at the same layer...

TLS encrypts the payload - it's "application" layer, at least as far as 
TCP is concerned (just because it's named "transport layer" doesn't make 
it so).

A TCP crypto solution would necessarily need to protect TCP's signalling 
protocol, i.e., (at a minimum) the sequence numbers and flags.

> done by the CPU...

Hardware support for encryption exists at various layers; TLS and SSL 
hardware accelerators have been common for many years (I have some that 
are over 10 years old in my lab).

> Even a fast modern CPU not using dedicated

Sure. Until we figure out that we didn't really need TLS if we protect TCP.

> That's a pretty steep price to pay...

That's what people said about double-lookup for VM 30 years ago, about 
20 bytes for an IP header 20 years ago, and about TCP 10 years ago. It's 
all relative to what you want.

Let's not please engineer a long-term solution based on ephemeral concerns.

Joe

---

From: Tony Arcieri <[email-masked]>
Date: Mon, 14 Apr 2014 09:58:41 -0700

On Mon, Apr 14, 2014 at 9:32 AM, John-Mark Gurney <[email-masked]> wrote:

> instructions can only do ~150MB/sec for AES-GCM

Most modern CPUs have some sort of native acceleration like AES-NI. If I
run openssl speed -evp aes-128-gcm I get ~1.33GB/s

-- 
Tony Arcieri

---

From: John-Mark Gurney <[email-masked]>
Date: Mon, 14 Apr 2014 10:26:40 -0700

> using at least some address and port info.

Because I'm assuming that the basic architecture of tcpcrypt will be
used...  If we aren't using tcpcrypt as a basis for this w/ minor
modifications, then I will stop participating because all of the work
that Bittau, Hamburg, Handley, Mazie`res and Boneh did on tcpcrypt will
be wasted, and we'll spend another coupld years reinventing what they
already did...

> >preset shared secrets between hosts which would be suseptible to the

I'm not, and that is our disconnect...

---

From: Joe Touch <[email-masked]>
Date: Mon, 14 Apr 2014 10:33:10 -0700

...
>> You're assuming a unique ephemeral key per connection ...
>
> used...

That is an error in the naming of this group.

I already spoke with Martin about this issue, and he claimed that the 
name was an artifact, not intended to focus on a particular solution.

Martin might want to weigh-in on this.

Joe

---

From: John-Mark Gurney <[email-masked]>
Date: Mon, 14 Apr 2014 10:34:07 -0700

> TCP is concerned (just because it's named "transport layer" doesn't make 

I consider TLS a transport layer as it provides pipes, it just happens
to be implemented in the application layer...

> are over 10 years old in my lab).

Yes, and most of the inexpensive (sub $100) ones are very slow now, and
have always been expensive for the moderate performance they provide...
I've priced them out recently, and they are in the $1k range to get what
a $80 CPU w/ AES-NI can now get you... 

> Sure. Until we figure out that we didn't really need TLS if we protect TCP.

Except we will still need the authentication layer of TLS...

> Let's not please engineer a long-term solution based on ephemeral concerns.

I'm trying to make sure that people will use this feature instead of
turning it off because the performance impact is too great...

---

From: John-Mark Gurney <[email-masked]>
Date: Mon, 14 Apr 2014 10:44:43 -0700

> >Because I'm assuming that the basic architecture of tcpcrypt will be

How do you think this point of the charter:
- When encryption is enabled, it must always provide forward secrecy.           

will be achieved w/o a unique key per connection/session?

---

From: John-Mark Gurney <[email-masked]>
Date: Mon, 14 Apr 2014 10:51:02 -0700

> run openssl speed -evp aes-128-gcm I get ~1.33GB/s

I know, I'm working on that right now for FreeBSD...

I used non-dedicated instructions because there are may processors out
there, like ARM cores, Atom embedded CPUs, MIPS cores, PowerPC etc.
that people would like to have a performant solution that don't all
have dedicated instructions...  i.e.  most embedded solutions will be
significantly less than 150MB/sec, and double encryption will be an
even larger burden on these embedded systems (think smart phones where
double encryption also impacts battery life)...

---

From: Joe Touch <[email-masked]>
Date: Mon, 14 Apr 2014 10:51:34 -0700

...
> to be implemented in the application layer...

In the IETF, "transport" means the layer above IP that provides an E2E 
service, e.g., TCP, UDP, SCTP, etc.

TLS does not provide transport security because it fails to protect the 
transport protocol.

...
> a $80 CPU w/ AES-NI can now get you...

Apples and oranges. That $80 CPU doesn't run in a vacuum; it often sits 
in a $1000 box.

The point is that hardware acceleration and offload exists - whether 
inside the CPU, in NIC offload engines, dedicated chips (HiFN), or as 
stand-alone systems.

> Except we will still need the authentication layer of TLS...

Not necessarily. DH without authentication still prevents off-path 
attacks and requires on-path attackers participate in the DH exchange 
(i.e., raising their level of effort).

...
> turning it off because the performance impact is too great...

People (i.e., the masses) turn off security because it's too hard to 
configure. Once it's easy to use, its performance improves (e.g., WPA).

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 14 Apr 2014 10:53:29 -0700

> will be achieved w/o a unique key per connection/session?

The keys can be derived from the session information, using master keys. 
  E.g., how it was done in TCP-AO.

But if you take away the connection identifier (e.g., if you exclude 
both addrs and ports because of NAT issues), how to you create that 
ephemeral key?

Joe

---

From: MARCELO BAGNULO BRAUN <[email-masked]>
Date: Mon, 14 Apr 2014 21:12:18 +0200

Joe Touch <[email-masked]> dijo:

> Hooks for out-of-band authentication is useful; hooks that are 
> described as tying layers together are problematic

I see your concern with this terminology
otoh, out of band make me think about manually configured keys, which 
is not what we want to do, maybe hooks for external authentication, 
maybe?

> - they could be interpreted as "channel binding", a method that can 
> render the lower-level mechanism useless if absent (and thus 
> disabling a useful mode).
>
> Joe
>

---

From: MARCELO BAGNULO BRAUN <[email-masked]>
Date: Mon, 14 Apr 2014 21:20:00 +0200

> That is an error in the naming of this group.

Right, i was surprised when we got that particular name for the ml
Note that in the propose charter and wg name we are using a different 
name (which seems to have other problems, but i guess all names do)

> name was an artifact, not intended to focus on a particular solution.

This is obvious, but i guess it is worthwhile clarifying the IETF 
process for once in a while.

So, the goal of this effort is to create a WG to work on 
anonymous/oportunistic encryption for TCP streams.
As any WG in the IETF, the outcome will be defined by the IETF process, 
i.e. the WG will define how the final solution will look like. this is 
not to rubberstamp with the IETF brand a previously backed solution.

That being said, the work on tcpcrypt in particular is a very valuable 
input and it is expected to influence the work as other pieces of 
existing work (such as TCP AO or others proposals that may come up 
later on). I hope i am not saying anything new to anyone here.

Hope this clarifies the process.

Regards, marcelo

---

From: MARCELO BAGNULO BRAUN <[email-masked]>
Date: Mon, 14 Apr 2014 21:27:43 +0200

Joe Touch <[email-masked]> dijo:

>
> A TCP crypto solution would necessarily need to protect TCP's 
> signalling protocol, i.e., (at a minimum) the sequence numbers and 
> flags.
>

Not necesarily. It is actually explicitly stated in the charter that 
what fields (if any) of the TCP header will be protected by the 
protocol.

As it has become clear from the disucssion in this ml, there are many 
tradeoffs involved when making the decision of what tpc fields to 
protect. I dont think we need to work these tradeoffs here, as this is 
part of the work of the working group (i am perfectly fine with 
discussing the tradeoffs here though).

But just to make it perfectly clear that a solution that doesnt protect 
any of the TCP fields is a acceptable outcome with the proposed charter.

I personally think this is a long discussion and i think it is better 
to leave it for the WG to figure it out.

Regards, marcelo

---

From: Joe Touch <[email-masked]>
Date: Mon, 14 Apr 2014 12:32:17 -0700

On 4/14/2014 12:12 PM, MARCELO BAGNULO BRAUN wrote:
> otoh, out of band make me think about manually configured keys, which is
> not what we want to do, maybe hooks for external authentication, maybe?

Sure - that's probably a better term.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 14 Apr 2014 12:42:33 -0700

> anonymous/oportunistic encryption for TCP streams.

That's not at all clear.

I thought the goal was encryption for TCP streams, which may include 
anonymous, zero-ID (which isn't necessarily anonymous), opportunistic, 
or other solutions.

Why the specific focus on anonymous/opportunistic?

And why list those as if they are related or synonymous?

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 14 Apr 2014 12:43:48 -0700

On 4/14/2014 12:27 PM, MARCELO BAGNULO BRAUN wrote:
>> signalling protocol, i.e., (at a minimum) the sequence numbers and flags.
>>
>
> what fields (if any) of the TCP header will be protected by the protocol.
>

I would argue that this is then not TCP security. If you can't protect 
the TCP protocol itself, there's nearly nothing added vs. TLS.

Joe

---

From: Wesley Eddy <[email-masked]>
Date: Mon, 14 Apr 2014 16:01:30 -0400

> the TCP protocol itself, there's nearly nothing added vs. TLS.

I agree.  Of course, TCP-AO can already protect the connection, just not
the data.  The goal should be to offer improvement for an application
that would currently have to use TCP-AO + TLS in ensemble.

-- 
Wes Eddy
MTI Systems

---

From: Joe Touch <[email-masked]>
Date: Mon, 14 Apr 2014 13:05:19 -0700

On 4/14/2014 1:01 PM, Wesley Eddy wrote:
> the data.

TCP-AO protects the integrity of the connection and the data.

http://tools.ietf.org/html/draft-touch-tcp-ao-encrypt-00
augments TCP-AO with a mode in which the payload is encrypted.

 > The goal should be to offer improvement for an application

Agreed; see ao-encrypt.

Joe

---

From: MARCELO BAGNULO BRAUN <[email-masked]>
Date: Mon, 14 Apr 2014 22:15:19 +0200

Joe Touch <[email-masked]> dijo:

> anonymous, zero-ID (which isn't necessarily anonymous), 
> opportunistic, or other solutions.
>

ok, so i think we have a terminology issue here.
For me, what i have in mind when writing the charter text, the goal of 
the work would be to enable encryption without necesarily requiring 
authentication.
For me, anonymous and opportunistic meant the same thing, i was using 
anonymous in order to stay away from the discussion on oportunistic 
encryption.

I think many of not all of these terms are overloaded. I was hoping the 
goal of what we want to achieve here was clearer but i guess it 
requires more precise wording. Is there any termonilogy that is well 
defined that we can use?

Regards, marcelo

---

From: MARCELO BAGNULO BRAUN <[email-masked]>
Date: Mon, 14 Apr 2014 22:22:06 +0200

Hi Wes,

below...

> that would currently have to use TCP-AO + TLS in ensemble.

I think there is added value to such a solution.
First and probably most important, if we had a solution that encrypts 
tcp stremas without requiring authentication that could be used by 
unmodified apps (i.e. apps opening a regular tcp socket, similar to the 
mptcp approach) this would allow us to deply pervasive crypto with much 
less pain that requiring all apps to adopt TLS.

Of course TLS is a better solution, but for those apps that people dont 
want to run over TLS, this would go a long way imho.

that is the argument why this is complementary with TLS.

Now, the other part of the argument, why not to protect the TCP header. 
Well, i didnt say we shouldnt protect it. Actually i would like to 
protect it, if the price to pay is not that we end up with an 
undeplyable protocol that is imcompatible with middleboxes, current 
operational practices and other elements of the Internet.

That is why i believe the charter shoudlbe open to discuss what is that 
we can protect of the TCP header and still have some chances to get 
wider deployment.
I think there are complex tradeoffs in that disucssion that should be 
better understood in the WG discussion that in the chartering 
discussion.
That is why i believe we should charter a WG on TCP crypto and leave 
the disucssion on what to protect of the TCP header for the WG.

Makes sense?

Regards, marcelo

---

From: Joe Touch <[email-masked]>
Date: Mon, 14 Apr 2014 13:25:17 -0700

> anonymous in order to stay away from the discussion on oportunistic

There are three terms:

	anonymous - which includes proof that a connection cannot be
	traced back to a given source, or different connections
	can't be correlated to a single source

	zero-ID - I think this is what you mean, i.e., PKI-free. That
	was the original intent of BTNS (RFC 5387), but later came to
	include links to channel binding when the WG got hold of it
	(RFC 5386).

	opportunistic - this originated with RFC 4322, which meant
	using keying info found in the DNS in the (opportunistic)
	hope that it would be useful, rather than negotiating
	it with the endpoint.

> I think many of not all of these terms are overloaded. I was hoping
> the goal of what we want to achieve here was clearer but i guess it

SAAG is currently trying to (re)define 'opportunistic security' to 
include the original BTNS meaning (zero-ID). I've already pointed out on 
that this list that such redefinition isn't productive, but they are 
doing so anyway.

I would suggest here that we use an accurate, meaningful term rather 
than redefine terms already in (relatively wide) use.

I would suggest zero-ID - akin to zero-configuration or zero-touch 
network management - if you mean "avoiding PKI".

I would not assume that zero-ID necessarily included links to 
upper-layer protocol authentication - e.g., TLS - because that doesn't 
get rid of PKI so much as move the problem to a different layer, where 
it still isn't solved.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 14 Apr 2014 13:29:03 -0700

> operational practices and other elements of the Internet.

FWIW, ao-encrypt is compatible with conventional NATs, so it's possible 
to both protect most of the TCP header (e.g., except source port and 
source addr) while providing per-connection ephemeral keys based on 
sufficient session-specific information.

There are a few other issues, BTW, that are addressed in TCP-AO-based 
solutions that might be important to consider:

	- avoiding replay attacks, even with TCP sequence number wrap

	- allow key rollover during a connection
		esp. while avoiding increased receiver load,
		e.g., in checking multiple keys

	- coordinate key rollover between endpoints
		so the source knows when it can use
		an available new key

Joe

---

From: MARCELO BAGNULO BRAUN <[email-masked]>
Date: Mon, 14 Apr 2014 22:32:04 +0200

Hi,

> 	hope that it would be useful, rather than negotiating

thanks for this.
Yes, i think zero-id as per the definition above is what we want.
I was just rechecking the btns charter and they use the term 
unauthenticated encryption, which would also fit what we are trying to 
do.

more below...

> include the original BTNS meaning (zero-ID). I've already pointed out 
> on that this list that such redefinition isn't productive, but they 
> are doing so anyway.
>
> upper-layer protocol authentication - e.g., TLS - because that 
> doesn't get rid of PKI so much as move the problem to a different 
> layer, where it still isn't solved.
>

right, my concern if we use zero-id or unathenticated, is that it 
sounds as we are rpeventing the hooks for external authentication, but 
i guess it is something we can live with, as long we properly explain 
it in the charter.

makes sense?

Regards, marcelo

---

From: MARCELO BAGNULO BRAUN <[email-masked]>
Date: Mon, 14 Apr 2014 22:39:51 +0200

Joe Touch <[email-masked]> dijo:

> FWIW, ao-encrypt is compatible with conventional NATs, so it's 
> possible to both protect most of the TCP header (e.g., except source 
> port and source addr) while providing per-connection ephemeral keys 
> based on sufficient session-specific information.
>

agree

let me restate, i am not against protecting the tcp header, i wish we 
could manage to do that

it is just that i think we need to understnad the tradeoff better.

my main concern is with tcp option space

maybe i got this wrong, but my understanding is as follows:
if we protect the tcp header we need to use tcp options to carry the mac
(if we include the mac in the payload, then when we send pure acks, 
they carry data (the mac) and they eat seq numbers so we need to ack 
acks and it all becomes a mess))
if we send the mac in the tcp options, well, we use a lot of option 
space and we are conflicting with other uses of the optcion space, 
especially sack and that would deter the deployment of the solution (we 
dont want that people needs to choose between crypt or sack, because 
they will choose sack)

hence, if we come to the conclusion that it is better to send the mac 
in the payload, then we may need to give up protecting the header

again, there are many dubious statements in the argument above that i 
woudl like to understand better (including for instance how much we 
gain by protecting the tcp header and how much of the option space we 
need to use for the mac and a few others)

that being said, i think this is for the wg to discuss and figure out

regards, marcelo

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 14 Apr 2014 21:42:35 +0100

> get rid of PKI so much as move the problem to a different layer, where

FWIW, my opinion is that this work ought use whatever turns out
to be the consensus terminology that saag ends up with assuming
it does reach rough consensus, which is looking more likely now
after much discussion similar to the above. I also see no good
reason why that discussion needs to be done over here.

S.

---

From: Joe Touch <[email-masked]>
Date: Mon, 14 Apr 2014 13:52:59 -0700

...
> unauthenticated encryption, which would also fit what we are trying to do.

Yeah, but BTNS was integrity protected, and unauthenticated sometimes 
isn't too.

> right, my concern if we use zero-id or unathenticated, is that it sounds
> as we are preventing the hooks for external authentication, but i guess
> it is something we can live with, as long we properly explain it in the
> charter.

I think you can be clear about what you are providing, and allow/require 
hooks that are *optional* easily.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 14 Apr 2014 13:54:46 -0700

On 4/14/2014 1:42 PM, Stephen Farrell wrote:
> after much discussion similar to the above.

I don't agree; much of the discussion there were a lot of arm-chair 
quarterbacks second-guessing the public-relations value of the term they 
were using (i.e., whether the public would adopt it).

AFAICT, they lost their way when they decided to try to redefine 
opportunistic, which is already a well-known and well-cited term (by 
their own admission).

> I also see no good

IMO because they're screwing it up ;-)

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 14 Apr 2014 13:59:20 -0700

> if we protect the tcp header we need to use tcp options to carry the mac

Yes. That's what TCP-AO does, FWIW.

> (if we include the mac in the payload, then when we send pure acks, they
> carry data (the mac) and they eat seq numbers so we need to ack acks and
> it all becomes a mess))'

Anything in the payload except the payload is a mess; we went through 
this discussion with tcp-multipath, FWIW.

> dont want that people needs to choose between crypt or sack, because

See Section 7.6 of RFC 5925. There's enough space.

> hence, if we come to the conclusion that it is better to send the mac in
> the payload, then we may need to give up protecting the header

I think that throws the baby out with the bathwater. I.e., I'd rather 
see a shorter option MAC (if necessary) than a payload MAC at all.

> woudl like to understand better (including for instance how much we gain
> by protecting the tcp header and how much of the option space we need to
> use for the mac and a few others)

The issue with protecting the TCP header is in the TCP-AO RFC as well. 
If you don't, DOS attacks are trivial -- but, more to the point, you 
might as well use TLS (and create a mode where it is OK to ignore 
authentication in both directions - is is done one-way with most 
websites now anyway).

Joe

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 14 Apr 2014 22:01:24 +0100

> opportunistic, which is already a well-known and well-cited term (by

I disagree with the above assertions. The term has been far
more commonly used to mean something else in the last year,
which is why we need to go to the trouble of getting agreement
on the terminology. In the HTTP WG that terminology confusion
alone was part of an argument some people made against
encrypting without https URIs, so the confusion has a real, and
not a mythical, downside in addition to the wasted effort of
re-doing discussions over and over.

> IMO because they're screwing it up ;-)

Right. You disagree and are fully entitled to be in the rough:-)

But if you do disagree please get involved in the discussion
on saag, it'll really be better if we can avoid having to re-do
this discussion a number of times over, no matter which of us
end up in the rough.

S.

---

From: Joe Touch <[email-masked]>
Date: Mon, 14 Apr 2014 14:10:49 -0700

On 4/14/2014 2:01 PM, Stephen Farrell wrote:
...
> more commonly used to mean something else in the last year,

That's just more evidence that it's a poor term to use.

> on the terminology.

Agreement is definitely needed.

> In the HTTP WG that terminology confusion
> on saag,

I did, and it was immediately evident that it was pointless to do so.

 > it'll really be better if we can avoid having to re-do

Although I appreciate the sentiment, not all WGs are worth participating 
in, and not all will necessarily concur on any terminology.

They went off the rails trying to redefine a term that clearly has 
gotten out of their control; I don't think there's much you can do to 
correct that except avoid the term, and they don't want to do that.

IMO, we can do better here.

Joe

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 14 Apr 2014 22:35:41 +0100

...
> IMO, we can do better here.

Depending what you mean, your two statements above could
be in conflict.

But anyway - sometimes one just has to accept being in the
rough on stuff.

If this group use terms that are being defined elsewhere in
a confusing manner then that I think is highly likely to
lead to wasted effort to continually explain that and deal
with e.g. IETF LC's that may go wildly astray.

If this group want to call what they're doing frobble
and say that that's called grobble elsewhere but means
the same, then that's maybe liveable but will I bet end
up wasting time and effort anyway.

I'd much rather not see that wasted effort myself.

S.

---

From: Joe Touch <[email-masked]>
Date: Mon, 14 Apr 2014 14:41:14 -0700

> Depending what you mean, your two statements above could

Sure - let me be more precise:

	Agreement is preferable, but not at the expense of
	compromising meaning at the expense of perceived PR.

> with e.g. IETF LC's that may go wildly astray.

That's happened in SAAG before (it might be a defining characteristic). 
I suspect their LC will be dismissive of anyone who points out the 
contrary, as has happened in the past.

I don't know how they would handle our use of zero-ID; they might just 
assume that we're not using the 'best' term for PR purposes.

> up wasting time and effort anyway.

FWIW, they're quite dismissive of the value of zero-ID security without 
upper layer authentication. So if they call that frobble, it might not 
interfere with us anyway.

> I'd much rather not see that wasted effort myself.

While I agree, I think trying to sync areas on terminology has proven to 
be the very definition of wasted effort in the IETF ;-)

Joe

---

From: MARCELO BAGNULO BRAUN <[email-masked]>
Date: Mon, 14 Apr 2014 23:43:34 +0200

> reason why that discussion needs to be done over here.

I dont have a problem with using whatever terminology saag comes up 
with, but i wouldnt want to wait for them to finish their discussion 
before we can start, so i would like to use some terminology here that 
is not confusing and allow us to make progress.

It doesnt have to be a cool terminology, just useful. For instance 
unauthenticated encryption if integrity protection of tecp streams, 
would that work?

Regards, marcelo

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 14 Apr 2014 22:48:44 +0100

> is not confusing and allow us to make progress.

Fully agree.

> unauthenticated encryption if integrity protection of tecp streams,

I'd say for now just get charter text that folks here like and
then we can s/frobble/grobble/ later if that has rough consensus.

For now, all I'm asking is to not re-do the terminology discussion
here.

S.

---

From: Joe Touch <[email-masked]>
Date: Mon, 14 Apr 2014 14:50:57 -0700

On 4/14/2014 2:43 PM, MARCELO BAGNULO BRAUN wrote:
...
> unauthenticated encryption if integrity protection of tecp streams,

I can't parse that.

Did you mean:

"unauthenticated encryption and integrity protection of tcp streams"

If so, +1

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 14 Apr 2014 14:56:16 -0700

On 4/14/2014 2:48 PM, Stephen Farrell wrote:
...
> For now, all I'm asking is to not re-do the terminology discussion

Sounds good to me, but would necessarily require avoiding existing 
ambiguous terminology.

So "opportunistic FOO" shouldn't be used.

If we say "unauthenticated", we need to be clear that we're talking 
about avoiding a tie to an external identity. Some still call the 
association of the segments in a single connection to be authenticated 
as being from the same stream, though - and that's more than 
"unauthenticated" might imply.

So AFAICT, we want:

	- MUST NOT require external identity
		MUST allow external identity if available and desired

	- MUST provide integrity protection, including tamper and
	replay prevention

	- MUST authenticate segments as being associated with
	a given TCP connection	

	- MUST provide payload confidentiality

Maybe it's sufficient to just list these individual requirements, and 
not give it a name.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 14 Apr 2014 14:57:57 -0700

> Thanks, will use these and Andrea's text in the next version of the charter

PS - can you post an update so we can get back on the same page?

(even if it's rough)

Thanks,

Joe

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 14 Apr 2014 23:02:25 +0100

> Maybe it's sufficient to just list these individual requirements, and

That approach looks reasonable to me and has the benefit of
better precision.

I assume there's also a bunch of MUST NOTs that might be
added as we go, e.g. MUST NOT allow reflection attacks.
But the above look like the main ones that'd need to be
clear at the start.

S.

---

From: Joe Touch <[email-masked]>
Date: Mon, 14 Apr 2014 15:12:48 -0700

> added as we go, e.g. MUST NOT allow reflection attacks.

Sure - I'd add that as a positive, and state it in a section on key 
management:

	Ephemeral session key coordination...

		MUST prevent reflection attacks

		MUST use unique ephemeral keys for each
		distinct TCP connection

		MUST support key rollover without disrupting
		an ongoing connection

As I've already noted, though, that coordination might be "out of band" 
(Marcelo prefers the term "external").

Joe

---

From: MARCELO BAGNULO BRAUN <[email-masked]>
Date: Tue, 15 Apr 2014 00:18:20 +0200

> PS - can you post an update so we can get back on the same page?

i will do so next week

(believe it or not, i am actually in holidays this week!)

---

From: Derek Fawcus <[email-masked]>
Date: Mon, 14 Apr 2014 15:18:32 -0700

> my main concern is with tcp option space
[snip]
> space and we are conflicting with other uses of the optcion space, 

So then,  should we also take on the work of defining how to negotiate
an increased option space?

I seem to recall that was previously mentioned (on tcpm?),
but don't know if it got anywhere.

.pdf

---

From: Joe Touch <[email-masked]>
Date: Mon, 14 Apr 2014 15:34:53 -0700

> an increased option space?

That's been discussed in TCPM many times before...

> but don't know if it got anywhere.

There's provably no way to do that in a backward-compatible way for the 
SYN (where it's really needed).

  It's trivial for later segments (just make a new option and handshake 
during the SYN), but it could break middleboxes. Not sure if that's 
needed, though - see the analysis in the TCP-AO doc about option space. 
You shouldn't need fields other than are basically need for TCP-AO.

Joe

---

From: John-Mark Gurney <[email-masked]>
Date: Mon, 14 Apr 2014 15:41:09 -0700

> Maybe it's sufficient to just list these individual requirements, and 

These look good...

---

From: Wesley Eddy <[email-masked]>
Date: Mon, 14 Apr 2014 23:47:39 -0400

> but don't know if it got anywhere.

Joe summarized the situation well.  One I-D discussing it is:
http://tools.ietf.org/html/draft-eddy-tcp-loo-04

-- 
Wes Eddy
MTI Systems

---

From: MARCELO BAGNULO BRAUN <[email-masked]>
Date: Tue, 15 Apr 2014 09:28:12 +0200

Joe Touch <[email-masked]> dijo:

> There's provably no way to do that in a backward-compatible way for 
> the SYN (where it's really needed).

mmm, interestingly enough, for this, i believe it is also an issue in 
the rest of packets, as all packets need to carry the mac and it eats 
up option space for all packets. Moreover, if you add sack and mptcp 
then it is a potential problem not only for syns.
So, i would say that it would be valuable to have extended tcp options 
if only for non syn packets.

OTOH, i dont think this would be in scope for this wg, it belongs to tcpm.
But this and mptcp could be good motivations for pushing it in tcpm.

>
>  It's trivial for later segments (just make a new option and 
> handshake during the SYN), but it could break middleboxes. Not sure

right, is there any experimental study if that is the case?

> if that's needed, though - see the analysis in the TCP-AO doc about 
> option space. You shouldn't need fields other than are basically need 
> for TCP-AO.
>

well, as i said earlier, when you add to the mix mptcp, then things 
become pretty tight, i believe

Regards, marcelo

---

From: Pasi Sarolahti <[email-masked]>
Date: Tue, 15 Apr 2014 10:57:15 +0300

> http://tools.ietf.org/html/draft-eddy-tcp-loo-04

This idea comes up every once in a while. Perhaps it would be useful to describe the issues in a small informational RFC?

- Pasi

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 23 Apr 2014 08:15:29 +0200

I am working on the new version of the charter and i was thinking about 
this.

below...

>> application layer to be able to safely disable encryption part way

I think this may be a useful thing to do, but i am unconvinced we shoudl 
explicitly mention it in the charter. My suggestion would be to leave it 
for discussion and not mention it in the charter.

I do think we should include a requirement on avoiding double encryption 
when is possible (notable with TLS)

Regards, marcelo

> A better solution, if the goal is to be lightweight, is to change 
> keying parameters during the connection, at which point the new 
> parameter can be "null".
>

---

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

El 13/04/14 19:54, Erik Nygren escribió:
>     IP header (sequence, flags, etc.). This will still make it through
>     a NAT, but will break a 'rewriting proxy' - but that's the kind of
> Unfortunately, applying a MAC on the IP dest will break NAT64 which is 
> a valid and increasingly critial use-case.
>

I dont understand why NAT64 is different than regular NAT44, is it?

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 23 Apr 2014 08:44:31 +0200

Marcelo,
> when is possible (notable with TLS)

One solution could be to allow a renegotiation of the crypto algorithm 
used (in addition to the keys) and support null encryption. This would 
allow to effectively disable encryption during the connection but would 
bring more advanced capabilities

Olivier

-- 
INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be

---

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

El 23/04/14 08:44, Olivier Bonaventure escribió:
> allow to effectively disable encryption during the connection but 
> would bring more advanced capabilities
>

yes, Joe suggested this earlier on, that is why i think it should not be 
very hard to support.
My question was more in the charter context, whether we should include 
this explicitly there or leave it open for the WG to consider and i was 
slightly inclined to leave it for the WG to decide.
Regards, marcelo

---

From: Paul Lambert <[email-masked]>
Date: Wed, 23 Apr 2014 09:14:08 -0700

>>>>> application layer to be able to safely disable encryption part way

I do not see why this would ever be necessary.
A ³connection² should be established with a particular expectation of
services
(like encryption) that should not change.

Paul

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 23 Apr 2014 09:16:11 -0700

> (like encryption) that should not change.

If we've learned anything from TLS, the more features you add, the more
likely you're going to implement one of them incorrectly. What if you make
a mistake and an attacker or MitM can shut off encryption?

The negligible performance impact of double encryption pales in comparison
to the chance that an attacker will be able to maliciously disable
encryption, IMO.

-- 
Tony Arcieri

---

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

> when is possible (notable with TLS)

I already responded about this issue in the updated charter.

Redundant security processing, e.g., TCP-INC with TCP-AO, is clearly 
useful to avoid.

However, encryption at different layers provides different protection. 
TLS - TCP-INC interaction is a really good example of why NOT to turn of 
TCP-INC -- it would leave TLS vulnerable to RST and other attacks at the 
TCP layer.

There are similar important differences in protection between WPA, 
IPsec, and TCP-INC. Encouraging people to disable protection at lower 
layers because it is provided at higher layers is both a bad idea in 
specific and bad general security advice in general.

Joe

---

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

> yes, Joe suggested this earlier on, that is why i think it should not be

You don't need to renegotiate during the connection or in-band. You just 
need to coordinate when to rollover in-band (e.g., as TCP-AO does).

Key rollover without impact is important for a lot of other reasons, 
though, so IMO it should be part of the list.

Joe

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 23 Apr 2014 14:44:19 -0700

> for discussion and not mention it in the charter.

Let me just say that if you do mention it in the charter, I will lose all
interest in Tcpcrypt and completely abandon it.

This is premature optimization. It's not "useful to avoid" until you have
actually measured the performance impact. You don't have a protocol yet,
AFAICT. You are still in the investigative stage, unless there's something
I'm missing.

Adding off-switches for security features "for speed" without measurements
is completely antithetical to the goals I would hope Tcpcrypt has.

Have any of you actually run something like "openssl speed -evp
aes-128-gcm" on your platform? I get 1.33GB/s.

Double encrypting:

1) Will provide a failsafe if one of the layers is compromised
2) Should have negligible performance overhead on modern CPUs. The
overwhelming majority of server, desktop, and mobile processors support AES
in hardware

Adding off switches to security features:

1) Increases attack surface
2) Increases the chance of a mistake
3) Complicates the protocol in ways that make it harder to audit

I have been mulling Tcpcrypt versus my own efforts. If Tcpcrypt seriously
wants to go forward with this, particularly without a specified protocol or
without anyone actually *measuring* the performance impact they want to
prematurely optimize, I'm afraid I'll have to abandon Tcpcrypt as I think
you're going down the wrong path.

I'm serious. Choose wisely!

-- 
Tony Arcieri

---

From: Joe Touch <[email-masked]>
Date: Wed, 23 Apr 2014 15:20:34 -0700

On 4/23/2014 2:44 PM, Tony Arcieri wrote:
>     I think this may be a useful thing to do, but i am unconvinced we
>     shoudl explicitly mention it in the charter. My suggestion would be
>     to leave it for discussion and not mention it in the charter.
>
> Let me just say that if you do mention it in the charter, I will lose
> all interest in Tcpcrypt and completely abandon it.

If you insist on such threats, please leave now. Otherwise, you're 
welcome to stay or leave as you like, as we all are.

> This is premature optimization. It's not "useful to avoid" until you
> have actually measured the performance impact. You don't have a protocol
> yet, AFAICT. You are still in the investigative stage, unless there's
> something I'm missing.
>
> Adding off-switches for security features "for speed" without
> measurements is completely antithetical to the goals I would hope
> Tcpcrypt has.
>

Yes, and if you run things twice you get half that performance. 
Regardless of what you're doing, there can be reasons it will be useful 
to disable it - energy, throughput, etc. - when you're in a trusted 
envinronment, e.g., doing a local backup.

> Double encrypting:

I've already noted that this isn't double - it's different layers, with 
different benefits, which I think is already known useful...

> 1) Will provide a failsafe if one of the layers is compromised

It's not a true failsafe unless you're doing the same kind of things at 
the same layers. No amount of TLS will protect TCP from RST attacks, e.g.

> overwhelming majority of server, desktop, and mobile processors support
> AES in hardware

At a cost - I might not want to take either the performance or energy 
hit to backup my cellphone over a local WiFi with this protection 
because I don't worry about off-path attacks (maybe I should, but let's 
say I make that decision).

> 1) Increases attack surface

No. It means you have decided to not use it.

> 2) Increases the chance of a mistake

we're talking about default-on that can be disabled. That happens 
deliberately.

> 3) Complicates the protocol in ways that make it harder to audit

In the sense that any feature would do this, yes.

However, in it's a single global switch; you either agree to use it or not.

> I have been mulling Tcpcrypt versus my own efforts. If Tcpcrypt
> seriously wants to go forward with this, particularly without a
> specified protocol or without anyone actually *measuring* the
> performance impact they want to prematurely optimize, I'm afraid I'll
> have to abandon Tcpcrypt as I think you're going down the wrong path.

I don't think we need an experiment to convince me that there's non-zero 
energy and performance cost. If you think it's zero, please do let us 
know and we can sell that capability!

Joe
\

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 23 Apr 2014 15:24:16 -0700

On Wed, Apr 23, 2014 at 3:20 PM, Joe Touch <[email-masked]> wrote:

> energy and performance cost. If you think it's zero, please do let us know
> and we can sell that capability!
>

You're shifting the goalposts. Can you absolutely, positively, 100% assure
that this will have *absolutely zero* impact on the security of the
protocol? Can you assure me that there will never, ever be a security
vulnerability related to this feature?

It sounds like you're prioritizing performance (without measuring!!!) over
security. This is the wrong set of priorities, IMO.

Perhaps I'm in the wrong place.

-- 
Tony Arcieri

---

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

On 4/23/2014 3:24 PM, Tony Arcieri wrote:
> On Wed, Apr 23, 2014 at 3:20 PM, Joe Touch <[email-masked]
>     I don't think we need an experiment to convince me that there's
>     non-zero energy and performance cost. If you think it's zero, please
>     do let us know and we can sell that capability!
>
> You're shifting the goalposts. Can you absolutely, positively, 100%
> assure that this will have *absolutely zero* impact on the security of
> the protocol?

Actually, I can claim that adding a feature to disable the security on 
demand will make this more likely to be widely deployed and used.

FWIW, I don't think it's necessary to disable this *in the middle* of a 
connection - that seems like a real security vulnerability.

> Can you assure me that there will never, ever be a
> security vulnerability related to this feature?

Strictly, no, but you can't assure me that the converse is true either.

> It sounds like you're prioritizing performance (without measuring!!!)
> over security. This is the wrong set of priorities, IMO.

No one needs to measure the power cost to know it's non-zero. If it 
were, we'd have bigger problems (i.e., violation of the second law of 
thermodynamics).

As with any system, we're setting the priorities we think will be 
important to get the result widely used. You and I disagree on the 
result, and the rough consensus of the group will determine what we end 
up working on, but there's no absolute right answer to those priorities.

There's no such thing as perfect security; it's all a trade-off of 
complexity, cost, effort, and robustness (among other axes).

Joe

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 23 Apr 2014 15:58:03 -0700

On Wed, Apr 23, 2014 at 3:37 PM, Joe Touch <[email-masked]> wrote:

> No one needs to measure the power cost to know it's non-zero. If it were,
> we'd have bigger problems (i.e., violation of the second law of
> thermodynamics).
>

It's still premature optimization, and will come at a non-zero cost to the
protocol's security:

http://c2.com/cgi/wiki?PrematureOptimization

"For those who don't work to strict memory or CPU cycle limits,
PrematureOptimization is an AntiPattern, since there is only cost and no
benefit. For those who do, it is often confused with poor coding, or with
misguided attempts at writing optimal code."

Nobody here except me has even bothered to measure the performance and yet
this feature is being discussed (before the protocol has even been
implemented), which is putting out huge warning signs to me.

--
Tony Arcieri

---

From: Joe Touch <[email-masked]>
Date: Wed, 23 Apr 2014 16:07:04 -0700

On 4/23/2014 3:58 PM, Tony Arcieri wrote:
> On Wed, Apr 23, 2014 at 3:37 PM, Joe Touch <[email-masked]
>     were, we'd have bigger problems (i.e., violation of the second law
>     of thermodynamics).
>
>
> It's still premature optimization, and will come at a non-zero cost to
> the protocol's security:

Security is a premature optimization too, in that sense. I.e., I already 
care about my cellphone's battery, but don't currently experience 
attacks on TCP connections that a TCP-level solution would be needed to 
secure. You keep claiming that nobody has measured performance impact of 
security, but that's not true (see refs below). The converse is that 
there's very little evidence of attacks at the TCP level of connections 
except between routers.

So if you're core point is that performance is a premature optimization, 
then so is TCP-layer security, and then there's little utility in 
pursuing the solution at all.

Joe

J. Touch, “Performance Analysis of MD5,” in Proc. ACM Sigcomm ’95, pp. 
77-86.

J. Touch, Y. Yang, “Reducing the Impact of DoS Attacks on Endpoint IP 
Security,” Proc. NPSec 2006, in conjunction with ICNP 2006, Nov. 2006.

---

From: Alfie John <[email-masked]>
Date: Thu, 24 Apr 2014 09:28:25 +1000

On Thu, Apr 24, 2014, at 08:20 AM, Joe Touch wrote:
> > Have any of you actually run something like "openssl speed -evp aes-128-
> > gcm" on your platform? I get 1.33GB/s.
>
> Regardless of what you're doing, there can be reasons it will be
> useful to disable it - energy, throughput, etc. - when you're in a
> trusted envinronment, e.g., doing a local backup.

In a trusted environment, you won't be enabling encryption to begin
with. This sounds like complete straw-man to me.

Alfie

-- 
  Alfie John
  [email-masked]

---

From: ianG <[email-masked]>
Date: Thu, 24 Apr 2014 00:56:50 +0100

> with. This sounds like complete straw-man to me.

not really.  Example ssh:  approximately everyone runs it in trusted
environments and does not bother to disable the default setup.

(philosophically, I'm with Tony on this one, but I'm more relaxed.  I'm
also thinking that the process of designing a new security protocol in a
working group is going to force a bunch of 'premature optimisations' as
per Joe's comment, so I'm not expecting to survive any consensus.)

iang

---

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

> with. This sounds like complete straw-man to me.

To be clear, I'm advocating that it's useful to be able to turn TCP-INC 
"off" and not use it at all on a connection for this reason. I am not 
advocating for ways to change things in the middle of a connection.

The only point about change in the middle of a connection is that 
key-rollover can already accommodate that if there's a null-mode 
algorithm, i.e., no new mechanism needs to be defined because (IMO) key 
rollover is already a requirement.

Joe

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 23 Apr 2014 19:40:38 -0700

On Wed, Apr 23, 2014 at 4:28 PM, Alfie John <[email-masked]> wrote:

> In a trusted environment, you won't be enabling encryption to begin with.
>

If you are dealing with remotely sensitive data, you will want to encrypt
in a "trusted" environment too. Source: I work at a company that deals with
remotely sensitive data, and we try to encrypt everything everywhere, in
the same datacenter, in the same firewall zone (and we have many). It
doesn't matter. We want all our flows encrypted. Period.

> advocating for ways to change things in the middle of a connection.

Unless you can absolutely, positively guarantee that this will never be
exploitable by an attacker, you are compromising the security of the
protocol. TLS did this repeatedly and they're paying the price. I would
personally like to see transport encryption that won't compromise security
for dubious reasons (e.g. "it's slow, we think! but we didn't bother to
measure")

-- 
Tony Arcieri

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 23 Apr 2014 20:11:39 -0700

On Wed, Apr 23, 2014 at 5:03 PM, Joe Touch <[email-masked]> wrote:

> "off"

What is the useful distinction between turning TCP-INC "off" versus not
using it in the first place and using a normal TCP connection?

The latter is well understood. The former seems like exactly the sort of
thing that has lead to various TLS vulnerabilities.

-- 
Tony Arcieri

---

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

On 4/23/2014 8:11 PM, Tony Arcieri wrote:
> On Wed, Apr 23, 2014 at 5:03 PM, Joe Touch <[email-masked]
>     To be clear, I'm advocating that it's useful to be able to turn
>     TCP-INC "off"
>
>

None; you just need to set TCP's default to use TCP-INC, and have a 
user-controllable way to decide to not use TCP-INC.

> thing that has lead to various TLS vulnerabilities.

Agreed. I am arguing only that there must be a way to decide that a 
given connection does not need TCP-INC at all.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 23 Apr 2014 20:45:48 -0700

On 4/23/2014 7:40 PM, Tony Arcieri wrote:
> On Wed, Apr 23, 2014 at 4:28 PM, Alfie John <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     with.
> If you are dealing with remotely sensitive data, you will want to
> encrypt in a "trusted" environment too. Source: I work at a company that
> deals with remotely sensitive data, and we try to encrypt everything
> everywhere, in the same datacenter, in the same firewall zone (and we
> have many). It doesn't matter. We want all our flows encrypted. Period.

That's your choice. Others, in the same situation, would make sure that 
the data was encrypted *on the disk* (which, IMO, is a safer way to 
address sensitive data), in which case the only utility in encrypted 
connections is to protect the connection itself - which may or may not 
be needed in a given environment.

>     TCP-INC "off" and not use it at all on a connection for this reason.
>     I am not advocating for ways to change things in the middle of a
>     connection.
>

Unless you're proposing a one-time pad, you can't make that guarantee.

> TLS did this repeatedly and they're paying the price. I would
> personally like to see transport encryption that won't compromise
> security for dubious reasons (e.g. "it's slow, we think! but we didn't
> bother to measure")

All security is a compromise, unless it's a one-time pad. We make 
trade-offs of strength vs. performance all the time - key length, 
rounds, etc.

And again, I did pick up your gauntlet. I cited not one but two papers 
of my own that did such measurements; there are dozens of others. So, 
yes, we have 'bothered' to measure. Even on recent hardware with crypto 
support, everything costs cycles, time, energy, and throughput.

If you have a better argument, this is the time to use it, but "we 
didn't bother to measure" is provably false.

Joe

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 23 Apr 2014 20:48:47 -0700

> Unless you're proposing a one-time pad, you can't make that guarantee.

You want to add an encryption off-switch to Tcpcrypt. I'm saying: you
shouldn't add the switch. If the switch isn't there, the attacker can't
shut it off. It's really that simple.

-- 
Tony Arcieri

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 23 Apr 2014 20:49:25 -0700

> shut it off. It's really that simple.

This is also the point in the conversation I seriously have to ask: are you
working for the NSA to undermine this effort?

-- 
Tony Arcieri

---

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

On 4/23/2014 8:48 PM, Tony Arcieri wrote:
> On Wed, Apr 23, 2014 at 8:45 PM, Joe Touch <[email-masked]

I don't want "encryption off" inside TCP-INC. I want "no need to use 
TCP-INC".

If it's not there, nobody will install it. It's *that* simple.

Joe

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 23 Apr 2014 20:55:14 -0700

> I don't want "encryption off" inside TCP-INC. I want "no need to use

It's called TCP. Problem solved.

</thread> ?

-- 
Tony Arcieri

---

From: Joe Touch <[email-masked]>
Date: Wed, 23 Apr 2014 20:58:44 -0700

On 4/23/2014 8:49 PM, Tony Arcieri wrote:
> On Wed, Apr 23, 2014 at 8:48 PM, Tony Arcieri <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     You want to add an encryption off-switch to Tcpcrypt. I'm saying:
>     you shouldn't add the switch. If the switch isn't there, the
>     attacker can't shut it off. It's really that simple.
>
> This is also the point in the conversation I seriously have to ask: are
> you working for the NSA to undermine this effort?

You've asked yourself; only you can answer.

I work for USC, and (as a consultant) myself on occasion, and no one else.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 23 Apr 2014 21:01:46 -0700

On 4/23/2014 8:55 PM, Tony Arcieri wrote:
> On Wed, Apr 23, 2014 at 8:53 PM, Joe Touch <[email-masked]

IP protocol 6 = TCP

TCP includes, when enabled, TCP-INC.

So IP protocol 6 = TCP=INC too.

I.e., they're *both* TCP.

If you default TCP-INC to system-wide being enabled, and there's no way 
to decide to use TCP without TCP-INC, we have a problem. That's an API 
issue.

Yes, when you use TCP without TCP-INC it's the TCP we're all using today.

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 23 Apr 2014 21:13:10 -0700

On Wed, Apr 23, 2014 at 9:01 PM, Joe Touch <[email-masked]> wrote:

> If you default TCP-INC to system-wide being enabled, and there's no way to
> decide to use TCP without TCP-INC, we have a problem. That's an API issue.
>

So long as the API boundary is at the time the connection is initiated,
i.e. before a single packet has been sent, at the time the socket has been
opened, this distinction possibly makes sense. But I'd like to put the
burden of proof on you: what is the overhead? Can you please go measure it
and report back? I've at least done that due diligence. You have not.

Anything in the nature of the subject of this thread, i.e. "disabling
encryption in the middle of a connection" completely undermines the purpose
of this protocol, IMO.

--
Tony Arcieri

---

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

On 4/23/2014 9:13 PM, Tony Arcieri wrote:
> On Wed, Apr 23, 2014 at 9:01 PM, Joe Touch <[email-masked]
>     If you default TCP-INC to system-wide being enabled, and there's no
>     way to decide to use TCP without TCP-INC, we have a problem. That's
>     an API issue.
>
> i.e. before a single packet has been sent, at the time the socket has
> been opened, this distinction possibly makes sense.

That's what I've been saying.

> But I'd like to put
> the burden of proof on you:

And I'd like you to read the papers I cited. If you had, you wouldn't 
keep asking for proof.

> encryption in the middle of a connection" completely undermines the
> purpose of this protocol, IMO.

We're already in agreement that it's not useful to do that in the middle 
of a connection. Which is why I changed the subject to something to more 
clearly identify the true nature of this thread thus far.

Joe

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 23 Apr 2014 22:29:13 -0700

On Wed, Apr 23, 2014 at 10:25 PM, Joe Touch <[email-masked]> wrote:

> And I'd like you to read the papers I cited. If you had, you wouldn't keep
> asking for proof.
>

I did look at the papers you cited, namely:

"Performance Analysis of MD5" (1995)

and

"Reducing the impact of DoS attacks on Endpoint IP Security" (2006)

Was there something relevant to Tcpcrypt *today* you wished for me to glean
from these papers? Did you cite some other papers besides these?

It also seems you lied about connections to the NSA? Is there any reason I
should continue talking to you?

-- 
Tony Arcieri

---

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

On 4/23/2014 10:29 PM, Tony Arcieri wrote:
> On Wed, Apr 23, 2014 at 10:25 PM, Joe Touch <[email-masked]
>     And I'd like you to read the papers I cited. If you had, you
>     wouldn't keep asking for proof.
>
>
> Was there something relevant to Tcpcrypt *today* you wished for me to
> glean from these papers? Did you cite some other papers besides these?

Both papers indicate the performance cost of doing security. Crypto 
benchmarks are easy to find in any search engine. Here's one from 2014:
http://www.tomshardware.com/reviews/mini-pc-round-up,3697-13.html

> It also seems you lied about connections to the NSA?

It seems you're not familiar with the concept of slander. You might want 
to review that before continuing to entertain your fantasy conspiracy 
theories.

> Is there any reasIon
> I should continue talking to you?

Given how little you've learned so far, I hope not.

Joe

---

From: Tony Arcieri <[email-masked]>
Date: Wed, 23 Apr 2014 23:29:04 -0700

> http://www.tomshardware.com/reviews/mini-pc-round-up,3697-13.html

You're citing out-of-date papers and Tom's Hardware articles?

For the rest of us, there's EBACS:

http://bench.cr.yp.to/

-- 
Tony Arcieri

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 24 Apr 2014 07:35:34 +0000

On 2014-4-23, at 18:16, Tony Arcieri <[email-masked]> wrote:
> The negligible performance impact of double encryption pales in comparison to the chance that an attacker will be able to maliciously disable encryption, IMO. 

Some of us are interested in running this at 40G and eventually 100G.

Lars

---

From: ianG <[email-masked]>
Date: Thu, 24 Apr 2014 09:24:13 +0100

> given connection does not need TCP-INC at all.

Surely that's outside the protocol, and therefore outside scope?

iang

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 24 Apr 2014 10:45:04 +0200

> Surely that's outside the protocol, and therefore outside scope?

In the current version of the charter, this is includedin the extended 
API work, makes sense?

---

From: ianG <[email-masked]>
Date: Thu, 24 Apr 2014 10:39:49 +0100

> Some of us are interested in running this at 40G and eventually 100G.

The charter says:

...This work is part of the IETF effort to harness the Internet
architecture given the latest events of pervasive monitoring...

- The protocol must be usable by unmodified applications. ...

- The protocol must have acceptable performance. ...

There is a clear tension between the goal of hyper-performance and the
goal of surveillance mitigation for apps that don't know better.

I wonder if this is a case of "pick one, or pick both and get neither?"

iang

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 24 Apr 2014 11:55:05 +0200

> I wonder if this is a case of "pick one, or pick both and get neither?"

I guess there are many things that are in tension (see for instance, 
protection and compatibility with NATs)
One of the main challenges of any WG i guess is to make the right tradeoffs.

IMHO, the charter should make clear what are the features that we are 
after and leave for the Wg to work out the tradeoffs.

Regards, marcelo

---

From: ianG <[email-masked]>
Date: Thu, 24 Apr 2014 10:55:57 +0100

> In the current version of the charter, this is includedin the extended

Yes, I see it in the charter, and it makes little sense to me, unless
the objective was to kill it before it started with a "please-everyone"
approach.

Clearly, any implementation will include a switch to turn it on or off
as part of its development process.  Typically distros will include the
new extension and default it to off, so that power users can test it out
in the real world.  When experiences are good, the distros will start
pushing it out with default=on.  And instructions on how to turn it off.

Quite what it means to mandate *in the protocol* an off/on switch makes
no sense to me.  The devs implementing will know far more, and will be
interpreting the need in far more precise ways than belong in the protocol.

If anything, in order to recognise the situation and warn people that
conforming implementations need to be checked, there could be a comment:
 "Implementations may include a switch to permit turning the encryption
off on a per-connection basis."

And leave it at that.  Until you get more experience in what works and
what is reliable, it's hard to say how this will pan out.

(I am here assuming that the goal is as writ, and therefore the default
and reliable expectation is that this stuff be on, hard.  If the goal is
not to address mass surveillance, and is something else, then that's a
discussion that should be had and fixed in the charter.)

iang

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 24 Apr 2014 12:11:25 +0200

> off on a per-connection basis."

So basically you are saying that this should be part of the API and 
should be a switch available in the implementation that can be set but 
not by the application but by the system admin, is that it?

---

From: ianG <[email-masked]>
Date: Thu, 24 Apr 2014 11:14:46 +0100

> not by the application but by the system admin, is that it?

No, that's not what I am saying.

iang

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 24 Apr 2014 13:34:37 +0200

>> not by the application but by the system admin, is that it?

Sorry, i meant,

this should _not_ be part of the API and should be a switch available in 
the implementation that can be set but not by the application but by the 
system admin, better now?

---

From: ianG <[email-masked]>
Date: Thu, 24 Apr 2014 13:50:58 +0100

...
> this should _not_ be part of the API

Well, the API is typically out of scope of the protocol, that's an
implementation issue, so I'm not saying anything about the API.

But, if we were to drift over to that discussion (and this might be
necessary or indicative of a flaw in the process) then yes, it might be
in the API, it might just come out in the wash.

Reason for this is that (iirc) KEX must be acceptable as handled externally.

Which means you have the requirement that in initiation of the
connection, the key must be providable.  I.e., it must be an option to
say "open this connection, use this key."

Which then means that it is pretty easy to provide a null key and thus
encryption is likely off.

Which is to say, there is no necessary presumption of a transparent mode
that just bootstraps, thus contradicting the goal of having apps use
this stuff without knowing about it, and gaining some security.

==> some choices aren't clear yet.  To me, it seems that some design has
to be done before some of these choices can be highlighted and
requirements can be tied down.  Process seems backwards.

> and should be a switch available in
> the implementation

NO, not should, but will.  There *will be* a switch, whether the
protocol likes it or not.  That's just how these things will get
implemented.  The challenge is to get rid of the switch.

> that can be set but not by the application but by the
> system admin,

That will be the implementation's choice.  I'm not saying, either way,
at all.

Obviously, choices here will be dramatic, which is why Tony is against
it.  If a sysadm can set it, we're back to IPSec and it's a no go.  If
the implementation is expected to set it, we're back to choosing TLS and
it won't be used...

iang

---

From: John-Mark Gurney <[email-masked]>
Date: Thu, 24 Apr 2014 09:01:36 -0700

> rollover is already a requirement.

IMO, rolling over to a null-mode algorithm is the equivalent of turning
TCP-INC off in the middle of a connection...  If this is allowed we
MUST require that both sides agree to the downgrade, and not allow one
side to do it...

So, please don't say you don't advocate turning off TCP-INC when you
make the above statement...

---

From: Joe Touch <[email-masked]>
Date: Thu, 24 Apr 2014 10:26:58 -0700

> MUST require that both sides agree to the downgrade, and not allow one

Both sides have to agree to the key rollover anyway.

> make the above statement...

I am not advocating for downgrade; I am demonstrating how a mechanism 
that's already necessary can support downgrade with no additional 
complexity.

Also, there are useful cases for upgrade - starting with NULL keys and 
enabling encryption later. That cannot be done unless TCP-INC is 
negotiated in the three-way handshake at the beginning of a connection.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 24 Apr 2014 10:42:01 -0700

On 4/24/2014 5:50 AM, ianG wrote:
...
> implementation issue, so I'm not saying anything about the API.

A protocol is:

	- endpoint state
	- upper and lower layer interface actions
	- message actions (formats of what is sent/received)
	- rules for how the above three interact

If you omit the API, you don't have a protocol. RFC793 includes an API, 
and all protocols should.

The IETF's position on this has often confused API with "API 
implementation", and by claiming that an API isn't a core part of a 
protocol, has hampered protocol specification for many years. It's time 
to stop that error.

Joe

---

From: ianG <[email-masked]>
Date: Thu, 24 Apr 2014 19:17:47 +0100

> and all protocols should.

Ah.  So, by API we don't mean Application Programming Interface, which
is by definition an implementation issue as it's programming, but
Interface Actions (IA) which is by nature a protocol issue.

Fine, so s/API/IA/g and I'm cool.

> protocol, has hampered protocol specification for many years. It's time

Yes, I can see that...

iang

---

From: Joe Touch <[email-masked]>
Date: Thu, 24 Apr 2014 11:50:06 -0700

> Interface Actions (IA) which is by nature a protocol issue.

In the transport world, "application" is defined as the layer above 
transport, so API is an accurate term.

However, yes, this is intended as "the interface to the upper and lower 
layer events", not merely "how Unix function calls are arranged".

> Fine, so s/API/IA/g and I'm cool.

Me too ;-)

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 24 Apr 2014 12:26:14 -0700

On 4/23/2014 11:29 PM, Tony Arcieri wrote:
> On Wed, Apr 23, 2014 at 11:09 PM, Joe Touch <[email-masked]
>     http://www.tomshardware.com/__reviews/mini-pc-round-up,3697-__13.html <http://www.tomshardware.com/reviews/mini-pc-round-up,3697-13.html>
>
>

I cited a few places that measured the network performance. The 
bench.cr.yp.to version doesn't appear to do that.

Network performance is important because of the kinds of effects shown 
in my (granted, now 'ancient') MD5 Sigcomm paper - in-situ performance 
does not take into account the additional "data touching" overheads 
required to move the data through the crypto processor, vs. doing DMA to 
the NIC.

Joe

---

From: Tony Arcieri <[email-masked]>
Date: Thu, 24 Apr 2014 14:14:07 -0700

On Thu, Apr 24, 2014 at 12:26 PM, Joe Touch <[email-masked]> wrote:

> Network performance is important because of the kinds of effects shown in
> my (granted, now 'ancient') MD5 Sigcomm paper - in-situ performance does
> not take into account the additional "data touching" overheads required to
> move the data through the crypto processor, vs. doing DMA to the NIC.

You cited a paper:

1) From last millennium. It predates the Pentium II
2) It's about an obsolete hash function, not encryption
3) Your complaint is *my source* isn't taking into the overhead of going
through the CPU instead of using direct DMA?

Where's your source that talks about this on computers that aren't two
decades old?

You are making the claim. The onus is on you to deliver the proof.

Where's the proof? Can you please link something that's actually germane to
the discussion? Can it talk about this millennium's computers? Can it talk
about encryption instead of hash functions? Can it actually address the
issue of the very overhead you claim my source doesn't matter?

I'm just pointing you at these sources as a courtesy. You're the one who
claims it's slow. You have the burden of proof.

So, can you provide *relevant* papers?

-- 
Tony Arcieri

---

From: Joe Touch <[email-masked]>
Date: Thu, 24 Apr 2014 15:26:36 -0700

On 4/24/2014 2:14 PM, Tony Arcieri wrote:
> On Thu, Apr 24, 2014 at 12:26 PM, Joe Touch <[email-masked]
>     bench.cr.yp.to <http://bench.cr.yp.to> version doesn't appear to do
>     that.
>
>     Network performance is important because of the kinds of effects
>     shown in my (granted, now 'ancient') MD5 Sigcomm paper - in-situ
>     performance does not take into account the additional "data
>     touching" overheads required to move the data through the crypto
>     processor, vs. doing DMA to the NIC.
>
>
> You cited a paper:
>

And it's still true. Old doesn't mean out of date.

> 2) It's about an obsolete hash function, not encryption

That function is still widely used. It's one of the fastest ones you can 
run, so if that one is slow, then everything will be slower.

> through the CPU instead of using direct DMA?

Most sources don't. That paper didn't; the later NPSec paper did, though.

> You are making the claim. The onus is on you to deliver the proof.

The onus on you is to ask a relevant question. So far, all you keep 
saying is "show me proof", and when someone does (like me), you say 
"that's not proof because it's old".

> Where's the proof? Can you please link something that's actually germane
> to the discussion? Can it talk about this millennium's computers? Can it
> talk about encryption instead of hash functions? Can it actually address
> the issue of the very overhead you claim my source doesn't matter?

Encryption itself is easier than hash functions, but useless without a 
hash function. Encryption can be a lot faster because it requires less 
mixing of the data, but integrity protection requires a hash anyway.

So yes, measuring the speed of either encryption or authentication will 
tell you a lot. The NPSec paper did just that, and compared the results 
- both stand-alone and in a network environment.

> So, can you provide *relevant* papers?

You are confusing me - and this list - for a search engine. If you know 
what you want, then look it up. Your wild claim is that performance 
doesn't matter - and those of us who have been doing research on 
security performance for a long time already know better.

The burden of proof is on you to explain why we should run a class on 
this mailing list, rather than have you come up to speed on a community 
that's been around "since the last millenium", as you put it.

Joe

---

From: Tony Arcieri <[email-masked]>
Date: Thu, 24 Apr 2014 15:48:49 -0700

On Thu, Apr 24, 2014 at 3:26 PM, Joe Touch <[email-masked]> wrote:

> what you want, then look it up. Your wild claim is that performance doesn't
> matter - and those of us who have been doing research on security
> performance for a long time already know better.
>

So you're saying we should compromise the security of the protocol because
you've been "doing research in security performance for a long time" and
therefore you're right?

This isn't an answer. It's called being a blowhard.

I have already given you way more hard data than you've supplied me. I
think it's clear I know the costs better than you do (since you seem to
like blowhards: I come from a professional background, not an academic
one). And I don't think they justify your proposal.

Perhaps if you provided some evidence for your position, I'd believe you,
but you simply sidestep my questions. This is the point where I look at
your CV and all the work you've done for DARPA and the NSA and have to
worry why one of your first proposals is adding an encryption off-switch to
the charter.

If I didn't know better, I'd say you're here to poison this effort.

-- 
Tony Arcieri

---

From: Tony Arcieri <[email-masked]>
Date: Thu, 24 Apr 2014 15:58:58 -0700

> And it's still true. Old doesn't mean out of date.

Newsflash: MD5 IS KNOWN TO BE BROKEN. This alone makes this citation out of
date.

Furthermore, from your paper's abstract:

"The analysis indicates that MD5 software currently runs at 85 Mbps on a
190 Mhz RISC architecture, a rate that cannot be improved more than 20-40%.
 "

Further newsflash: computers are a lot faster than 190MHz now.

> run, so if that one is slow, then everything will be slower.

MD5 is known to be broken and shouldn't be used in new software, and more
modern hash functions like Blake2b are faster.

The onus on you is to ask a relevant question. So far, all you keep saying
> is "show me proof", and when someone does (like me), you say "that's not
> proof because it's old".
>

You're citing a paper for a broken hash function which isn't used in modern
authenticated encryption algorithms like AES-GCM. Modern CPUs support
instructions like AES-NI and PCLMULTQDQ.

> hash function.

I assume you're referring to authenticated encryption, in which case you
seem to be confusing a hash function with a MAC, unless you're talking
about key exchange which should be a one-time cost at session setup.

> tell you a lot. The NPSec paper did just that, and compared the results -
> both stand-alone and in a network environment.
>

And would you seriously propose using MD5 for authentication in Tcpcrypt?

-- 
Tony Arcieri

---

From: Joe Touch <[email-masked]>
Date: Thu, 24 Apr 2014 16:09:23 -0700

On 4/24/2014 3:48 PM, Tony Arcieri wrote:
> On Thu, Apr 24, 2014 at 3:26 PM, Joe Touch <[email-masked]
>     You are confusing me - and this list - for a search engine. If you
>     know what you want, then look it up. Your wild claim is that
>     performance doesn't matter - and those of us who have been doing
>     research on security performance for a long time already know better.
>
> So you're saying we should compromise the security of the protocol
> because you've been "doing research in security performance for a long
> time" and therefore you're right?

You are the one claiming that this compromises the security of the 
protocol. I've already pointed out repeatedly that NULL mode would only 
be useful if *both* ends agreed to use it. Other than the vacuous 
platitude that "anything that makes security more complex makes it 
weaker", you have shown no PROOF at all.

FWIW, if you still haven't figured out how to use a search engine, 
here's a specific, fairly recent ref that includes info on CPU hardware 
support for crypto:
http://dl.acm.org/citation.cfm?id=1851200

Note that the number of cores needed to support 1 Gbps is NOT ZERO. 
Until it is, there's something else I could have done with that core, 
and that's a cost.

And this paper didn't bother to measure the data touching overhead 
costs. One of the reasons we don't keep up-to-date numbers on that cost 
is that those of us who do performance know what it is (roughly 30%), 
and nobody wants to pay researchers to find out info they already know.

...
>This is the point where I
> look at your CV and all the work you've done for DARPA and the NSA and
> have to worry why one of your first proposals is adding an encryption
> off-switch to the charter.

DARPA paid for the Internet, so maybe you should stop using it.

The NSA is one of many agencies that support my research, all of which 
has been published in peer-reviewed venues. If you don't believe any of 
it, then you're welcome to conduct your own research, write your own 
paper, and defend *your* position.

And no, demanding proof from others does not make you right until proven 
otherwise.

Joe

---

From: Tony Arcieri <[email-masked]>
Date: Thu, 24 Apr 2014 16:13:20 -0700

On Thu, Apr 24, 2014 at 4:09 PM, Joe Touch <[email-masked]> wrote:

> The NSA is one of many agencies that support my research
>

That's funny, because earlier you claimed:

-- 
Tony Arcieri

---

From: Joe Touch <[email-masked]>
Date: Thu, 24 Apr 2014 16:26:41 -0700

On 4/24/2014 3:58 PM, Tony Arcieri wrote:
> Newsflash: MD5 IS KNOWN TO BE BROKEN. This alone makes this citation out
> of date.
>
> 190 Mhz RISC architecture, a rate that cannot be improved more than
> 20-40%. "
>

Had you read the paper, you would find that the speed expected is based 
on the number of opcodes/second of the processor. The improvement 
referred to in the abstract is based on code rearrangement and hardware, 
not using a faster clock. See Section 3.1.2. The number of opcodes per 
word is 40-50, which means roughly 1.5 opcodes per bit.

Ivy Bridge i7's do 3.5 instructions per cycle, so at best, at 3GHz is 
10Gbps - i.e., that's you're entire CPU just to run the fastest hash 
algorithm at 10Gbps.

>     That function is still widely used. It's one of the fastest ones you
>     can run, so if that one is slow, then everything will be slower.
>
> MD5 is known to be broken and shouldn't be used in new software, and
> more modern hash functions like Blake2b are faster.

MD5 MAC is known susceptible to birthday attacks. MD5 HMAC is not known 
susceptible - see RFC 6151.

> You're citing a paper for a broken hash function which isn't used in
> modern authenticated encryption algorithms like AES-GCM. Modern CPUs
> support instructions like AES-NI and PCLMULTQDQ.

Those are opcodes have a cost - they make very costly crypto functions 
that used to cost ~30 opcodes/byte (i.e., >4 per bit) now cost roughly 
0.5 opcodes/bit. You continue to provide the proof you ask for - that 
there is a nonzero cost to doing these functions.

>     Encryption itself is easier than hash functions, but useless without
>     a hash function.
>
>     So yes, measuring the speed of either encryption or authentication
>     will tell you a lot. The NPSec paper did just that, and compared the
>     results - both stand-alone and in a network environment.
>

No, but using it for comparison is still valid, because it's still a lot 
faster than the current alternatives (e.g., SHA1).

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 24 Apr 2014 16:30:13 -0700

On 4/24/2014 4:13 PM, Tony Arcieri wrote:
> On Thu, Apr 24, 2014 at 4:09 PM, Joe Touch <[email-masked]
> On Wed, Apr 23, 2014 at 8:58 PM, Joe Touch <[email-masked]

You really can't read.

I work for - i.e., am employed by - USC.

I have received funding for research performed while a USC employee from 
many places.

Your turn. How about we start discussing who you *say* you work for?

Joe

---

From: Tony Arcieri <[email-masked]>
Date: Thu, 24 Apr 2014 16:45:33 -0700

> I have received funding for research performed while a USC employee from

So let me get this straight: you didn't actually work for the NSA, you just
did some work that they gave you money for. Is that it?

You really can't read.

No, I'm just not a fan of USSID 18-style twisting of language to lie about
things. And I'm calling you a liar. You lied about your involvement with
the NSA.

I am the most deep cover NSA sleeper agent the world has ever seen

-- 
Tony Arcieri

---

From: Joe Touch <[email-masked]>
Date: Thu, 24 Apr 2014 16:59:11 -0700

On 4/24/2014 4:45 PM, Tony Arcieri wrote:
> On Thu, Apr 24, 2014 at 4:30 PM, Joe Touch <[email-masked]
>     I have received funding for research performed while a USC employee
>     from many places.
>
> So let me get this straight: you didn't actually work for the NSA, you
> just did some work that they gave you money for. Is that it?

Yup. Just like how DARPA gave money to people at UCLA and BBN initially, 
and lots of others over the years, to create the Internet. It's called 
government funded research.

It's what made the Internet possible, so that lots of companies can make 
billions and not pay for what got them there.

>     You really can't read.
>
> No, I'm just not a fan of USSID 18-style twisting of language to lie
> about things.

Like I said, you can't read.

> And I'm calling you a liar. You lied about your
> involvement with the NSA.

I stated clear and direct facts and you have zero proof otherwise (you 
know, you're fond of proof, right?).

Further, I'll confirm that I'm not funded by the NSA right now, and that 
the project I was working on involved tunnel configuration, not 
encryption or authentication protocols.

Which is more than you have done.

Joe

---

From: ianG <[email-masked]>
Date: Fri, 25 Apr 2014 01:15:42 +0100

> You are the one claiming that this compromises the security of the

Count me in ;)

> I've already pointed out repeatedly that NULL mode would only
> be useful if *both* ends agreed to use it.

Doesn't cut the mustard for me.  Firstly, that isn't shown in the
charter, secondly nobody knows what it will look like when it gets
delivered, thirdly we know that the obligatory existence of a defined
mode creates an entire axis or dimension of state complexity.

Fourthly if you get your NULL in there, everyone else will want their
vanity suite in too, and it'll be SSL sweet madness all over again.
Fifthly, we've been here before:  systems fail when people add too much
stuff of marginal utility (which includes the terabyters).

Sixthly, people are pissed.  They don't want another kitchen sink.  This
might be the last chance IETF WGs have to make a showing in this field,
there are already serious competitors looking to sweep the whole lot
away, and they know the IETF isn't the right forum for security
protocols.  Fixing TCP to go opportunistic isn't going to hold them back
for long, but if it presents an alphabet soup of options, it'll just
make the job soooo much easier [0].

> Other than the vacuous

Standing on proof is an old academic trick to push arguments into a
black hole.  Proof by citation is a joke because every academic paper
finishes with "more funds required, please" and every paper committee is
made of swap buddies and other peers.

Instead of 'proof' we've got data:  20 years of experience in what
happens to secure protocols that aim for complexity.  130 if you count
Kerckhoffs.

iang

[0] wait, why am I arguing against, again?

---

From: Chris Palmer <[email-masked]>
Date: Thu, 24 Apr 2014 17:59:24 -0700

>> You are the one claiming that this compromises the security of the

I'm pretty sure every practicing security engineer worth her cybers
knows from experience that (a) complexity is bad; (b) we already have
unencrypted TCP; and (c) the performance argument is either a red
herring or better answered with "Well, you can always use... TCP."

> make the job soooo much easier [0].

I'm sorry, Joe, but ianG is 200% right.

---

From: Joe Touch <[email-masked]>
Date: Thu, 24 Apr 2014 18:14:09 -0700

>> You are the one claiming that this compromises the security of the

You'll need to do more than that... (see below).

> charter,

It doesn't need to be in the charter per se. Any solution would be 
evaluated against the charter requirements and its own safety. There's 
no need to make the decision of how that's achieved in the charter.

Further, some of these requirements don't belong in the charter either; 
the charter should describe the minimum aspects needed, and let the 
solutions provide and justify their own approach.

> secondly nobody knows what it will look like when it gets
> delivered,

It could look at least partly like this:
http://tools.ietf.org/html/draft-touch-tcp-ao-encrypt-00

< thirdly we know that the obligatory existence of a defined
> mode creates an entire axis or dimension of state complexity.

Every bit in a protocol does that. That itself does not make the overall 
solution more vulnerable.

> vanity suite in too, and it'll be SSL sweet madness all over again.

Slippery slope argument; you get to complain after other people try to 
get their modes in, not just because one mode is considered important to 
add now.

> stuff of marginal utility (which includes the terabyters).

And we've been where systems fail because they lack functionality too.

> Sixthly, people are pissed.  They don't want another kitchen sink.

Again you're back to the slippery slope argument. I don't want 
kitchen-sink either. I just have a specific need for NULL - or something 
like NULL - at some phases of the connection. I've discussed some of the 
details offline with a subset of people, and I'll post it when it's 
written up better.

> This

That's both always true and never true for all IETF output.

> make the job soooo much easier [0].

Again, nobody is asking for alphabet soup, just one option that others 
feel is contentious. Why not at least wait for a proposal before 
declaring that the approach isn't valid?

> black hole.

FWIW, I wasn't really asking for proof; I was playing off the terms of 
the other list contributor.

> Proof by citation is a joke because every academic paper
> finishes with "more funds required, please"

A good academic paper (and there are lots of bad ones) makes a clear 
contribution, and ought to also point the way to future investigation. 
The former is what the citation-as-proof is about; the latter is how 
research moves forward.

As to "more funds required, please", I hear that a lot more from 
industry (upgrades? software updates? patches?) than from academia.

> and every paper committee is made of swap buddies and other peers.

There are certainly some, but more likely is a group of researchers who 
all can't see that their work is useless because they all do research in 
the same area. Sort of like industry running off the cliff loving ATM a 
few years back, until they realized otherwise. Love-fests happen in 
every community.

> happens to secure protocols that aim for complexity.  130 if you count

The plural of anecdote is not data.

My peers know that; do yours?

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 24 Apr 2014 18:16:29 -0700

> herring or better answered with "Well, you can always use... TCP."

The performance argument is to use TCP. What we don't want is something 
that makes all TCP encrypted and we can't shut that off.

However, anyone who thinks complexity is bad can use what we have now 
(e.g., IPsec, TLS, etc.) and leave the group now. Because adding 
*anything* to TCP necessarily makes it more complex than it is now.

Joe

---

From: Alfie John <[email-masked]>
Date: Fri, 25 Apr 2014 20:33:00 +1000

> that makes all TCP encrypted and we can't shut that off.

In today's climate I think encryption by default is what everyone wants.
If you need plain-text, you should have to be made to jump through hoops
to get it. Because in practice, the only people who need plain-text are
developers debugging their code and the government debugging their
citizens.

> *anything* to TCP necessarily makes it more complex than it is now.

Ah IPSec. Funny you should mention that [0]:

  "Every once in a while, someone not an NSA employee, but who had
  longstanding ties to NSA, would make a suggestion that reduced privacy
  or security, but which seemed to make sense when viewed by people who
  didn't know much about crypto. For example, using the same IV
  (initialization vector) throughout a session, rather than making a new
  one for each packet. Or, retaining a way to for this encryption
  protocol to specify that no encryption is to be applied."

    -- John Gilmore

Alfie

[0] http://thread.gmane.org/gmane.technology.liberationtech/1185

-- 
  Alfie John
  [email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 25 Apr 2014 22:24:29 +0100

> Like I said, you can't read.

Wow. Have to say that's not a very mature sequence of exchanges.
Which is a pity. Probably better to just not continue that thread
I'd say.

S.

---

From: ianG <[email-masked]>
Date: Fri, 25 Apr 2014 22:28:18 +0100

I see.

In the below and in other posts, you've made it clear you've made
decisions, and as you say, you're going to fight to the death on any
diversion from your path.  Take no prisoners, not on your watch, your
mission and you've chosen to accept it.  I get it.

Your proof-of-work responses suggest that reasons and opinions here
count for little, so what's the process from here;  do opponents fade
away and let you have it, coz you'll out respond them?

Or is there a way to take a straw vote?

It's not a bid deal for me, because I have low expectations as to the
IETF WGs creating tcpcrypt for the people as opposed to for themselves.
 The 'anecdotal evidence' suggests where this is going.

I even don't mind that you've responding with proof-of-work rejoinders,
it's an efficient coordination method to reach the chosen goal.

What I'm curious about, though, is where the silent majority stand --
what do people who aren't saying think?  What did the mandate say, and
what thought those who were at the deciding plenum to add opp-enc to TCP?

iang

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 25 Apr 2014 22:31:54 +0100

> herring or better answered with "Well, you can always use... TCP."

I agree about the complexity argument and that's why I'd lean
against NULL cipher features myself. Not the strongest argument
because its fairly abstract but simpler really is much better
and is also something where we (the IETF and IETF security folk)
need to do better IMO.

Apart from that, I don't think there's real history of accidental
use of such or real downgrade attacks to such. At least afaik. If
there were that'd be a very strong argument against.

All that said, I don't think this needs to be decided right now
and nor do I think we're in a position where we could make a
sensible yes/no decision on this topic now, before we have more
detail of TCP Inc. (great name btw:-) figured out.

> I'm sorry, Joe, but ianG is 200% right.

IMO ianG is quite wrong there but it doesn't matter since that's
commentary that has no direct impact on what we're trying to do
here. There are plenty of other lists for such discussion.

S.

---

From: Tony Arcieri <[email-masked]>
Date: Fri, 25 Apr 2014 14:44:04 -0700

> here. There are plenty of other lists for such discussion.

I'd like to cite this quote again:

    -- John Gilmore

There is already a cloud of suspicion hanging over Tcpcrypt that even at
its inception it's been tainted by the NSA in order to undermine its
security.

Adding encryption off-switches as one of the first features of what is
supposed to be a "ubiquitous encryption" protocol does not lend credence to
its mission!

The only way this mistrust can be repaired is through quick and decisive
action on the part of its leaders.

-- 
Tony Arcieri

---

From: Tony Arcieri <[email-masked]>
Date: Fri, 25 Apr 2014 14:49:54 -0700

Here's an analogy:

Let's imagine we're pursuing a "full disk encryption" technology.

Some might argue that there are files on your hard drive that are already
encrypted. Would double encrypting these files be silly?

Well, you can try to make that argument, but some might make the argument
that if you added off-switches for files you assumed were already
encrypted, your full disk encryption technology ceases to be full disk
encryption.

I think the idea of a
"most-of-your-disk-but-we-want-some-files-plaintext-encryption" technology
is rather silly. What's the point then?

Tcpcrypt is already going down the arguably silly path of pursuing
unauthenticated opportunistic encryption which is known to be vulnerable to
active Man-in-the-Middle attacks. But it's doing this for a good cause:
encrypt everything.

...or is it? Well, it seems certain people who have taken grant money from
the NSA in the past are opposed to that mission.

-- 
Tony Arcieri

---

From: Tony Arcieri <[email-masked]>
Date: Fri, 25 Apr 2014 14:55:19 -0700

> Which is a pity. Probably better to just not continue that thread

This working group needs to deal with the reality that there is an
organization that has actively worked to undermine these sorts of efforts
repeatedly in the past, and that this person has taken money from them, and
this is exactly how they have poisoned previous cryptographic standards.

Unless this working group actively resists their efforts, they are going to
fall prey to them.

If I think that's happening, I will be sure to tell anyone and everyone
that I think Tcpcrypt is tainted by the NSA and is not to be trusted.

-- 
Tony Arcieri

---

From: Mark Handley <[email-masked]>
Date: Fri, 25 Apr 2014 15:04:55 -0700

There is already a cloud of suspicion hanging over Tcpcrypt that even
at its inception it's been tainted by the NSA in order to undermine its
security.

Sorry, please take a look at the authors of the tcpcrypt draft please,
and tell me which of us you think may have been tainted by the NSA?
The NSA certainly wasn't at UCL when we dreamed this protocol up
several years ago, and I don't remember anyone from any security agency
begging me to bring the work to the IETF, either the first time I tried
a couple of  years ago, or more recently.

Mark

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 25 Apr 2014 23:06:15 +0100

> its inception it's been tainted by the NSA in order to undermine its

That's just totally misguided IMO. The whole "taint" thing I
mean and has nothing to do with this list really.

If you have a technical proposal, write an I-D. If you have a
technical issue with a proposal raise the technical argument.

If you want to follow conspiracy theories then perhaps that'd
be better done elsewhere since the *only* real defence we have
against an organisation willing to waste US$250M/yr to bugger
up Internet security is to be as open as we can about trying
to make Internet security better. (The 250/yr seems real but
the "this person/statement/paper/I-D is evidence that you're
an NSA stooge" is pure consipracy theory stuff IMO.)

And being as open as we need to be *requires* that you take
participants at face value and evaluate their technical
contributions on their merits or else you rapidly end up with
a membership cabal of one sort or another, and/or the sort of
frankly silly and destructive thread we've just seen.

So again - I'd ask that you drop the conspiracy stuff at
least on this list, and we all get back to the technical work
which is what we want to get done here.

If you want to discuss the generic topic of how to
handle the fact that IETF participants are and have been
and will always be funded by all sorts of organisations on
an IETF list, then I'd suggest maybe the perpass list and not
here. Though personally I think that's a bit of a stretch as
a valid topic even there really, but it might be a discussion
worth having in a mature way to get it properly done once at
least.

S.

---

From: Tony Arcieri <[email-masked]>
Date: Fri, 25 Apr 2014 15:14:54 -0700

On Fri, Apr 25, 2014 at 3:04 PM, Mark Handley <[email-masked]>wrote:

> and tell me which of us you think may have been tainted by the NSA?  The
> NSA certainly wasn't at UCL when we dreamed this protocol up several years
> ago, and I don't remember anyone from any security agency begging me to
> bring the work to the IETF, either the first time I tried a couple of
> years ago, or more recently.
>

I have no problems with the majority of people involved.

I'm talking about Joe Touch, who is probably the main impetus for this
thread.

-- 
Tony Arcieri

---

From: Guido Witmond <[email-masked]>
Date: Sat, 26 Apr 2014 00:16:08 +0200

> there were that'd be a very strong argument against.

I've heard a story about someone being tasked to find out if they could
speed up their web service.

After some man-page reading and config tweaking, the administrator made
a huge improvement in speed. He found out that the NULL-cipher was the
fastest. "It's listed among the ciphers, so it is probably good enough,
otherwise, those smart programmers wouldn't have put it in there."

It's only a story, don't know if it is true or not but this is exactly
what should be prevented.

Lesson: Don't give people knobs to tweak if they don't know the effects.

Guido.

---

From: Tony Arcieri <[email-masked]>
Date: Fri, 25 Apr 2014 15:16:30 -0700

On Fri, Apr 25, 2014 at 3:06 PM, Stephen Farrell
<[email-masked]>wrote:

> least on this list

If you're not willing to address these problems internally, I am quite
happy to leave this list and take them public.

-- 
Tony Arcieri

---

From: Joe Touch <[email-masked]>
Date: Fri, 25 Apr 2014 15:17:06 -0700

So there are only two groups of people:
	- those who disclose NSA funding or employment
	(e.g., mine is on my CV as past funding support)
	- those who don't

If you don't trust the former, why do you trust the latter? How can you 
*ever* distinguish the second set from the first that you haven't 
exposed yet?

So basically nobody is to be trusted. I certainly don't trust you, but 
that's because I think you're lacking in technical judgement, not 
because of whom you (claim to) associate with.

But isn't that how we should all always approach every security problem, 
including designing protocols anyway?

Joe

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 25 Apr 2014 23:18:33 +0100

On 04/25/2014 11:16 PM, Guido Witmond wrote:
> It's only a story, don't know if it is true or not but this is
> exactly what should be prevented.

I've heard similar myself, but always 3rd hand. If there were
real evidence of that I'd expect the ssl observatory or others
to have turned it up for TLS at least.

If someone does have real info. on such, that'd be really good
to know.

S.

---

From: Tony Arcieri <[email-masked]>
Date: Fri, 25 Apr 2014 15:20:27 -0700

>         - those who disclose NSA funding or employment

When confronted about your NSA involvement, you said:

-- 
Tony Arcieri

---

From: Guido Witmond <[email-masked]>
Date: Sat, 26 Apr 2014 00:28:43 +0200

> If someone does have real info. on such, that'd be really good

Whether true or not is irrelevant, the fact that is might be very
possible that someone lacks knowledge but has to act on something. Then
mistakes are made.

Taking the possibility of error away is the way forward.

It also stops this round of 'spot the feds'.

Heck, after 150 years of automobiles, people still put diesel in petrol
engines and the other way around.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 26 Apr 2014 00:29:44 +0200

> detail of TCP Inc. (great name btw:-) figured out.

Right.

For amusing this discussion may be, i think we need to keep in mind what 
we need to achieve at this stage i.e. come up with a charter so we can 
get a WG and then we continue with all the fun of these discussions.

So, for me, whether we allow NULL encryption of disabling encryption in 
the middle of the TCP connection, should not be decided in the charter, 
but shold be left for the WG to decide.

We have received some useful input on this second version of the 
charter, i will work on a revision of it in the next week.

Please if you do have comments that impact the charter, please bring 
them up.

Regards, marcelo

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 25 Apr 2014 23:33:29 +0100

On 04/25/2014 11:28 PM, Guido Witmond wrote:
> possible that someone lacks knowledge but has to act on something.
> Then mistakes are made.

Well not quite. I agree its not that relevant for the current
discussion (apologies Marcelo;-) since as I said I figure we're
not yet in a position to argue about that properly.

But knowing vs. wondering makes a big difference - e.g. a 2012
tin foil hat vs. snowdonia makes a real difference in terms of
whether or not people are willing to do work to make stuff
better. So it'd be generally useful to know for sure I think.

S.

---

From: Joe Touch <[email-masked]>
Date: Fri, 25 Apr 2014 15:32:56 -0700

> I'm talking about Joe Touch, who is probably the main impetus for this

Check the thread; I wasn't the one who raised the issue of NULL-mode.

For the benefit of others, here's a link to my NSA-sponsored work:

http://www.isi.edu/touch/atp.html

It's so linked on my web pages, and my CV. That's exactly how well I've 
been hiding it. If anyone wants to hear a talk on it, and is willing to 
pay for the travel, I'll be glad to do so ;-)

My view of network security is public and well documented. It's 
basically that people like you make security so difficult that nobody 
uses it - so if you're looking for a reason YOU shouldn't be trusted, 
that's a fine one.

Easier-to-use security was the basis of BTNS (which has nothing to do 
with ATP), and a number of projects I've been involved with since 1995. 
It includes a keynote I gave at the Computer Communications Workshop 
last year as well.

Joe

---

From: Paul Lambert <[email-masked]>
Date: Mon, 28 Apr 2014 11:35:48 -0700

>and is also something where we (the IETF and IETF security folk)

A NULL cipher is a bad idea.  At the top level of our requirements
we should be considering the service interface we are providing.
When connected - Tcpcrypt should be encrypting.  The service
Interface should also provide clarity on the nature of the peer
system. 

NULL cipher breaks this simple model of a security layer. It
prevents the creation of clear cryptographic/trust boundaries
in a protocol architecture.

Paul

---

From: Alfie John <[email-masked]>
Date: Tue, 29 Apr 2014 07:00:19 +1000

> there were that'd be a very strong argument against.

Here is an example of a NULL cipher option downgrade attack that many
people around the world are vulnerable to everyday - STARTTLS. All it
takes is a MITM to not pass through the STARTTLS command, and now the
connection is in plaintext and the emperor has no clothes.

Remember, unless you can verify every bit that goes down that pipe, it
may not be you that turns the cipher flag to NULL!

Alfie

-- 
  Alfie John
  [email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 28 Apr 2014 22:35:17 +0100

> connection is in plaintext and the emperor has no clothes.

I wouldn't call that a NULL cipher problem TBH. For TLS, the kind of
problem I meant would be negotiating e.g. TLS_RSA_WITH_NULL_SHA256
or one of the other similar ciphersuites from [1].

Again - its not really relevant here (yet), but if we knew of a real
case that'd be interesting (and a nail in the coffin for adding
more such).

Cheers,
S.

[1]
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4

---

From: David Mazieres <[email-masked]>
Date: Tue, 29 Apr 2014 00:20:04 +0200

> case that'd be interesting (and a nail in the coffin for adding

I don't understand why we are having this discussion.  Forward secrecy
must be an absolute requirement of TCP Inc.  A NULL cipher does not
provide forward secrecy.  So end of story, right?

Of course, we have to prepare for the case that some cipher like AES is
someday no longer secure.  That means kind of ciphersuite negotiation is
necessary.  But should any cipher suite later be deemed insecure,
implementations will have to disable it.

David

---

From: ianG <[email-masked]>
Date: Tue, 29 Apr 2014 11:54:56 +0100

> provide forward secrecy.  So end of story, right?

Point.

> someday no longer secure.

You've assumed AES ... not really the place in the charter.

(I'd expect to see ChaCha20/Poly1305 at this stage in the experimental
protocols aiming at charter, but I'd also expect that suite to be
dropped for a CAESAR winner when it goes mainstream.)

> That means kind of ciphersuite negotiation is

When has that ever happened with a properly designed ciphersuite?  In
practice, what happens is the complexity opens up weaknesses and this
might get fixed by switching to some ciphersuite.  Or some old algorithm
that should never have been there has finally permeated its anachronism
into the dark cobwebs of some committee mind.

Have a look at the history of TLS -- agility is a source of problems
more than it is a solution to problems.  If they'd spent the time on
upgrade of the protocol instead of elegantly handling buckets of vanity
suites to meet the fashion needs of developers, it would be a whole more
secure.

iang

---

From: David Mazieres <[email-masked]>
Date: Tue, 29 Apr 2014 05:02:43 -0700

> dropped for a CAESAR winner when it goes mainstream.)

I haven't assumed AES.  I said "like AES."  But there's a point here,
namely that there's a difference between the state of the art in
symmetric crypto and what the IETF has standardized.  For example, I
would love the ability to use Poly1305 with TCP Inc.  But there's no RFC
for that, which is likely to cause problems.  (By contrast, HMAC has
RFC2014 and CMAC has RFC4493.)  We certainly don't want to put TCP
Inc. on hold until better MAC algorithms are standardized, but we also
want to leave room for improving the algorithms later on.

> into the dark cobwebs of some committee mind.

Well, *improperly* designed ciphersuites have needed to be disabled
(DES, RC4, etc.).  But the point is that in the long run, all
ciphersuites may be improperly designed.  Moreover, crypto does get
broken, and if that happens, you don't want to have to push new code
out.  It's much better just to have people disable an option and then
remove it in the next implementation.  If you don't have the ability to
upgrade algorithms, you are arguably more likely to have entrenched
anachronistic protocols persist.

That said, the charter shouldn't over-specify.  There needs to be a way
to change crypto algorithms over time.  Whether that looks like SSL's
crypto agility or something coarser-grained should depend on what
proposals look the best.

> suites to meet the fashion needs of developers, it would be a whole more

Things have changed a lot about since SSL was invented.  We now know a
lot more about protocol design.  Moreover, we don't have to deal with a
lot of stuff SSL had to deal with (remember 40-bit keys?).

David

---

From: John-Mark Gurney <[email-masked]>
Date: Tue, 29 Apr 2014 09:25:58 -0700

> may not be you that turns the cipher flag to NULL!

Sadly, until all packets must be signed, they can just strip the TCP-Inc
bit from the TCP packet, and the same thing will be achieved...

---

From: David Mazieres <[email-masked]>
Date: Tue, 29 Apr 2014 14:46:48 -0700

> bit from the TCP packet, and the same thing will be achieved...

This is why TCP Inc. needs simple hooks for authentication.  As long as
the hooks are there, down the line if the protocol becomes ubiquitous
people can start requiring TCP Inc. for authenticated connections.

So while we can't solve this problem over night, any TCP Inc. proposal
should be compatible with solving the problem long-term after ubiquitous
deployment.

David

---

From: Paul Lambert <[email-masked]>
Date: Tue, 29 Apr 2014 16:22:14 -0700

>implementations will have to disable it.

This is unlikely.   RC4 persists in implementations.

Perhaps we should consider improvements in ciphers and protocol as
the same class of upgrade.  The default mandatory cipher suite
could be tied to the protocol version.  If for some reason the
mandatory cipher needs to change, the version changes.  If there
is something broken in the protocol design, we fix it and increment
the version.  The version is somewhat visible to users and IT
Departments and provides a more robust indicator of the capabilities
than manually disabling specific features.

Paul

---

From: ianG <[email-masked]>
Date: Wed, 30 Apr 2014 00:47:56 +0100

...
> This is unlikely.   RC4 persists in implementations.

Amazing, isn't it.

> than manually disabling specific features.

Thank you!

iang

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 30 Apr 2014 07:55:29 +0200

> crypto agility or something coarser-grained should depend on what 

Right, crypto agility must be required, i will add it to the charter