Subject: [saag] fyi: tcpcrypt draft

From: Sean Turner <[email-masked]>
Date: Sun, 08 May 2011 12:31:41 -0400

The authors of the following draft have asked that I forward this to 
saag for comment:

https://datatracker.ietf.org/doc/draft-bittau-tcp-crypt/

They also noted that there's a Usenix Security paper and video:
http://tcpcrypt.org/docs.php

Please direct discussion to [email-masked].

Cheers,

spt

---

From: David McGrew <[email-masked]>
Date: Tue, 10 May 2011 16:03:58 -0700

Hello Tcpcrypt authors,

I have skimmed the internet draft and the USENIX Security paper on  
tcpcrypt, and while it is interesting and thought-provoking work, I  
have a hard time understanding what the goals of the I-D are relative  
to the TCP standard.  The draft says "Standards Track"; would  
Experimental be more appropriate?  It mentions the following objectives:

"Tcpcrypt maintains the confidentiality of data transmitted in TCP  
segments against a passive eavesdropper.  It can be used to protect  
already established TCP connections against denial-of-service attacks  
involving injection of forged RST segments or desynchronizing of  
sequence numbers."  Yes, but TLS and IPsec perform the former  
function, and IPsec and TCP-AO perform the latter.  In addition,  
running TCP over DTLS would also accomplishes the latter function;  
this practice is done in some (so-called) SSLVPNs.

"Finally, applications that perform authentication can obtain end-to- 
end confidentiality and integrity guarantees by tying authentication  
to tcpcrypt Session ID values."  This seems like a potentially useful  
feature, though it seems similar to channel binding (RFCs 5056 and  
5929).

"Tcpcrypt is designed to require relatively low overhead, particularly  
at servers, so as to be useful even in the case of servers accepting  
many TCP connections per second."  The idea of batching signatures  
seems like a useful contribution that could be put to good use by  
servers that are under heavy loads.  But why not implement this idea  
in a way that could be used by multiple applications and protocols?    
It should not be hard to define a format for digital signatures that  
carries a few extra hash values, and allows a verifying party to check  
the signature on the message that they care about, while ignoring the  
rest.  The idea of reversing the client/server association between RSA  
encryption/decryption is a pragmatic way to help out servers, though  
it is tied to a specific algorithm (the results would be quite  
different for ECDH or ECDSA, say).  Both of those performance  
optimizations are definitely interesting, but I don't understand why  
the best way utilize those ideas would be through a new cryptographic  
protocol within the TCP layer.

I also have some comments on some other points.  The USENIX Security  
paper mentions the goal of ubiquitous encryption (though the draft  
does not).  Requiring changes to the TCP stack would hinder deployment  
and work against the goal of ubiquity.

The draft describes the RSA public keys as "ephemeral", and the  
companion paper says that the protocol achieves forward secrecy.   
However, if it was really the case that a new RSA keypair was  
generated for each exchange, then the performance would be  
significantly worse than what is shown in the paper, because the cost  
of that operation is significantly higher than that of RSA  
decryption.   I think the claims and/or guidance to implementers needs  
to be clarified.

The Security Considerations section looks like boilerplate, while it  
seems that there is a lot to be discussed, such as the security  
properties of Session IDs.

Is it possible to relate the protocol to a previously analyzed  
protocol?   It is similar to ISO/IEC 11770-3, in that it relies on  
public key encryption of nonces, without signatures.  Perhaps there is  
some analysis of that protocol, or of a protocol with cryptosuite  
negotiation, that could be leveraged.  The companion paper does have a  
brief analysis of the security of the protocol, but it would be good  
if it were possible to benefit from detailed analyses of all aspects  
of protocol security.  (I do realize that the analysis is made easier  
by the relative simplicity of the protocol; that's a good thing.)

The security analysis defines the parameter "k ~ 256 is the minimum of  
the min-entropy of a public key".  Surely that doesn't match the 2048- 
bit RSA examples in the paper?

As a side note, I am surprised to see a proposal to add so much  
cryptographic functionality into the TCP standard, considering that  
not many years have passed since the transport area declined to add  
(much simpler) key transport functionality into TCP in support of TCP- 
AO.  Perhaps "Experimental" was intended, or perhaps I have missed or  
misunderstood some aspect of this work.

regards,

David

On May 8, 2011, at 9:31 AM, Sean Turner wrote:

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

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 11 May 2011 14:42:17 +1200

David McGrew <[email-masked]> writes:

>I have a hard time understanding what the goals of the I-D are relative to
>the TCP standard.  The draft says "Standards Track"; would Experimental be
>more appropriate?

+1.  I've got it set aside for next week when I may have a bit more time to
look at it, but my first reaction was "why?".  I understand it's always fun to
dream up a new crypto protocol (Ferguson and Schneier wrote a whole book on
it), but... why?  It definitely seems like an Experimental to me, not
Standards-track.

Peter.

---

From: Nico Williams <[email-masked]>
Date: Tue, 10 May 2011 21:59:20 -0500

On Tue, May 10, 2011 at 6:03 PM, David McGrew <[email-masked]> wrote:
> "Finally, applications that perform authentication can obtain end-to-end
> confidentiality and integrity guarantees by tying authentication to tcpcrypt
> Session ID values."  This seems like a potentially useful feature, though it
> seems similar to channel binding (RFCs 5056 and 5929).

That's exactly what it would, well, depending on the security
properties of those session ID values.

I would prefer that the channel binding data for tcpcrypt be derived
as a keyed PRF taken over the key exchange messages, with the key
being derived from the session key.  This approach has the benefit of
strongly binding the entire negotiation (e.g., of algorithms, ...) and
also being defined independently of the key exchange algorithm (which
is nice because you propose using key transport, but I can imagine
that some will want key agreement).

I'll review the I-D in detail later.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 10 May 2011 22:00:42 -0500

> it), but... why?  It definitely seems like an Experimental to me, not

Most likely because someone's thinking of putting this on silicon.
Sure, there's IPsec, but then you'd need to implement RFC5660 if you
want similar semantics, and no one has yet.

Nico
--