Subject: [Cfrg] draft-agl-tls-snapstart-00

From: David McGrew <[email-masked]>
Date: Mon, 21 Jun 2010 07:53:47 -0700

Hi Adam,

a few comments and questions:

What anti-replay assurance does the server have, and how exactly is it  
provided?   If I understand correctly, the intent is that the client  
suggests a a truly random value for the server_random, and the server  
is responsible for rejecting duplicate values, and that a time-window  
strategy can be used by the server to minimize storage.   This would  
put a tension between storage requirements (which would want a short  
window) and snapstart re-establishment (which would want a long window).

I suggest adding this as a requirement for the "orbit": it MUST be  
generated uniquely at random by each server.  If virtualization is in  
use, each instance of the server MUST generate and use a distinct  
orbit value.

An option that might be worth considering: have the server issue the  
client a range of nonce values that can be included in the  
server_random, and require the client to use them sequentially (e.g.  
as integers) or at least in a non-decreasing way.  In this scheme, a  
server can check for a replay by storing a single integer, instead of  
the set of server_random values within the time window.  This would  
have the benefit of removing the tension on window size.  Of course,  
it will be necessary for the server_random to contain an actual random  
value, because we want to retain that property of the protocol to the  
greatest extent possible (e.g. to retain analyses of the key  
derivation processes).

"In order for the server to be assured of uniqueness, it will have to  
remember every "server_random" value that has been used so that it may  
reject duplicates."   I suggest changing this to " ... it will need to  
be able to detect potential duplicates", which is less pessimistic  
about the amount of server state.

It would be disastrous if an attacker could cause a collision in the  
predicted_server_handshake, that is, if the client and server had  
different ideas about what the response flow actually was (e.g. if the  
client thought that RC4 was offered, while the server meant to offer  
only AES-128).  I suggest either changing the computation of this  
field to use a collision-resistant hash, or documenting how the  
current spec avoids this problem.

There should be some discussion about denial of service attacks.

regards,

David

> From: [email-masked] [mailto:[email-masked] 
> ] On
> Behalf Of [email-masked]
> Sent: Friday, June 18, 2010 10:45 AM
> To: [email-masked]
> Subject: I-D Action:draft-agl-tls-snapstart-00.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
> 	Title           : Transport Layer Security (TLS) Snap Start
> 	Author(s)       : A. Langley
> 	Filename        : draft-agl-tls-snapstart-00.txt
> 	Pages           : 22
> 	Date            : 2010-06-18
>
> This document describes a Transport Layer Security (TLS) extension
> for eliminating the latency of handshakes when the client has prior
> knowledge about the server.  Unlike resumption, this prior knowledge
> is not secret and may be obtained from third parties and stored on
> disk for significant periods of time.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-agl-tls-snapstart-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/