Subject: [TLS] Re: comments on draft-modadugu-tls-ctr-00.txt

From: nagendra modadugu <[email-masked]>
Date: Tue, 8 Nov 2005 11:19:02 -0800

Hi Dave, thanks for your comments.  I'll integrate changes
into the next revision of the drafts.  Some comments inline:

> Section 1.1.
> 
> "Parallelizable" is a real implementation advantage, but the feature  
> that really buys hardware efficiency is the fact that CTR is amenable  
> to pipelining in hardware.  It's probably worth mentioning.

Good point.

> Section 3.1.
> 
> A nit:  I'd clarify "The cipher stream generated by AES-CTR is much  
> like the cipher stream generated by stream ciphers like RC4." to  
> something like "AES-CTR is functionally equivalent to a stream  
> cipher; it generates a pseudorandom cipher stream that is exored into  
> the plaintext to form the ciphertext."

Right.

> Section 3.1.1.
> 
> Another nit: "A given counter block MUST never be used more than once  
> with the same key."  The term "used" might not be clear to an  
> implementer.  It might be better to put this MUST after the  
> definition of AES-CTR, at which point an implementer new to CTR would  
> have a better understanding.

Sure, I'm happy to repeat the statement.

> The definition speaks of most significant and least significant, but  
> are we talking about integers or bit strings?  "Leftmost" and  
> "rightmost" might be more precise.  Similarly, the increment function  
> is presumably defined in terms of an unsigned integer in network byte  
> order, but that's not stated.  It might be implicit from some TLS  
> presentation layer convention I'm not aware of, but it would be good  
> to state it anyway.

Right.

> It is great that the client_write_iv and server_write_iv values can  
> be used to set the initial blocks; it looks like a good design.   I'm  
> curious about whether or not there is an 'entropy bottleneck' in the  
> KDF though; have you analyzed this?

The output from the KDF is used in the same same way other ciphers
use KDF output -- so we certainly haven't made entropy exhaustion an issue
through our design.

> The CtrBlk definition clears up some of the questions I'd had  
> earlier; might be good to move it up higher in the text.

I'll look into how the layout may be modified.

> A nit: it would be good to add an argument to the TRUNC() function  
> that indicates the length that it returns.    (Here I'm passing on a  
> comment that I've heard when I've used implicit lengths in crypto  
> specs that I've written :-)
>
> Another nit: INCR(CtrBlk) would be more clear than CtrBlk := CtrBlk + 1.

The notation here is lifted from Housley's RFC3686 -- I'd prefer to
maintain some fidelity with his notation, unless clarity is a big issue here.

> A question: why not include AES-192?  Not that I care much either  
> way, but I'm curious.

TLS 1.1 only supports AES-128 and AES-256 in CBC mode, so CTR mode is
essentially a mirror of those modes.

> In order to allow crypto hardware to really take advantage of  
> parallel/pipelined processing, it would make sense to also define an  
> AES-GCM ciphersuite for TLS, which would allow the elimination of  
> HMAC-SHA1 for bulk data processing.  RFC4106 (GCM ESP) is in many  
> ways identical to RFC 3686, on which this draft is based, so I  
> believe that the definition would be quite easy.  AES-GCM would offer  
> efficiency and/or speed advantages that would be useful in servers or  
> network devices that aggregate many TLS connections.

AES-GCM is certainly interesting, but for now we'd like to focus on
AES-CTR -- we'd be interested in investigating authenticated encryption 
modes in the future.

Thanks,
nagendra

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls