Subject: Review (Re: [TLS] I-D ACTION:draft-ietf-tls-ctr-00.txt)

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 03 Mar 2006 15:34:08 -0800

Hi Nagendra,

I have a few questions and thoughts on the TLS-CTR mode I-D:

On the IV construction:

I see that the nonce is 48 bits in length.  My recollection of David 
McGrew's analysis of CTR mode is that 64 bits of nonce would provide 
128-bit security (for a 128bit key and CTR mode).  My question is on 
the level of security 48-bit nonces provide.  I see that 3686 uses a 
32-bit nonce.  I am confused at what is the right length for the 
nonce.  Some discussion on that might be appropriate in the SEC 
considerations section.  Perhaps David might help clarify (I may have 
misread his paper).

On the block level counter, 3686 specifies a 32-bit counter citing 
IPv6 Jumbograms' requirement.  SRTP makes a note that for multimedia 
apps, that might be safely ignored.  Could you also make a similar 
note in this document, or perhaps you might also want to support 
jumbograms?  (Perhaps IPv6 historians might tell us whether there are 
practical uses for jumbograms).

I don't think it is sufficient to refer to 3686's security 
considerations.  Those notes are written for a different protocol and 
context.  Perhaps you might copy and paste from there and edit the 
text, if you want to reuse text.

best,
Lakshminath

At 03:50 PM 2/28/2006, you wrote:
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>This draft is a work item of the Transport Layer Security Working 
>Group of the IETF.
>
>         Title           : AES Counter Mode Cipher Suites for TLS and DTLS
>         Author(s)       : N. Modadugu, E. Rescorla
>         Filename        : draft-ietf-tls-ctr-00.txt
>         Pages           : 9
>         Date            : 2006-2-28
>
>    This document describes the use of the Advanced Encryption Standard
>    (AES) Counter Mode for use as a Transport Layer Security (TLS) and
>    Datagram Transport Layer Security (DTLS) confidentiality mechanism.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-tls-ctr-00.txt
>
>To remove yourself from the I-D Announcement list, send a message to
>[email-masked] with the word unsubscribe in the body 
>of the message.
>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
>to change your subscription settings.
>
>
>Internet-Drafts are also available by anonymous FTP. Login with the username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>         "get draft-ietf-tls-ctr-00.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>         [email-masked].
>In the body type:
>         "FILE /internet-drafts/draft-ietf-tls-ctr-00.txt".
>
>NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
>
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>
>Content-Type: text/plain
>Content-ID: <[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-tls-ctr-00.txt
>
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-ctr-00.txt>
>_______________________________________________
>TLS mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/tls

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

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sat, 4 Mar 2006 09:55:39 +0100

On Wed 01 Mar 2006 00:50, [email-masked] wrote:

Hello,
 I've read the CTR draft and I have some questions on it, phrased below.
I'm not familiar with the counter mode and attacks on it, thus my 
questions are based on facts that were not clear while reading the 
document and after having read rfc3686 (which was mandatory for
me to read to understand the CTR draft).

1. What is the size of IV generated after the ciphersuite is generated? 
128 bits? In that case why not generate only 48 bits if the rest of the
bits are not used?

2. What is the purpose of having the blk_ctr and the seq_num used in the 
counter and reinitialized for every record packet? What do they protect
from?

3. What is the rationale behind constructing a counter block in the
given way? Why not use the full 128 bit IV? 

4. terminology: sometimes different than rfc2246. Say the abreviations 
PT block and CT block are never used in rfc2246. Also "nonce" could be
"random bytes" to match rfc2246.

5. At par 3.1.1. It says "A given counter block MUST never be
 used more than once with the same key.". But this is not up
 to the implementation to choose, thus must instead of MUST
 may be more appropriate.

6. Same paragraph: It gives a brief description of CTR, but I think
it can be confusing to somebody who doesn't know CTR. It says
"Each PT block is XORed with a block of the key stream to generate the
   ciphertext, CT.  The AES encryption of each counter block results in
   128 bits of key stream."
but nowhere before it was mentioned that CTR mode is supposed to 
generate a key stream.

regards,
Nikos Mavrogiannopoulos

---

From: nagendra modadugu <[email-masked]>
Date: Mon, 20 Mar 2006 00:45:27 -0800

> considerations section.  Perhaps David might help clarify (I may have

My understanding is that 32-bits of nonce are sufficient to accomodate
for pre-computation attacks on CTR mode.  Though, if there is a problem 
here, then it would apply equally to 3686.

> practical uses for jumbograms).

The limit on the counter here is to support a TLS record of 2^14 octets.

> text, if you want to reuse text.

Good point.  That's probably the right thing to do.

Thanks,
nagendra

---

From: nagendra modadugu <[email-masked]>
Date: Mon, 20 Mar 2006 00:46:38 -0800

> 128 bits? In that case why not generate only 48 bits if the rest of the

Good catch -- I'll clean up this text.

> given way? Why not use the full 128 bit IV? 

Agreed, there's nothing wrong with using the full 128-bit IV.  The current
design mimics counter block generation as described in 3686.  This design
also has the minor advantage that no additions are required in order to 
generate the counter block. 

> "random bytes" to match rfc2246.

Is the current description unclear?  2246 doesn't need to use the same
shorthand for plain text and cipher text since ciphering transformations
are only described in prose.  I don't think nonce is used anywhere, or am
I missing something?

>  to the implementation to choose, thus must instead of MUST

The goal is to make it clear about the security requirements of
implementing CTR mode, and hence the corresponding requirement
on sequence number usage.  I'm happy to discuss further if
this is an issue.

> but nowhere before it was mentioned that CTR mode is supposed to 

I'll clarify in the introduction section.

Thanks,
nagendra

---

From: "Nikos Mavrogiannopoulos" <[email-masked]>
Date: Mon, 20 Mar 2006 15:10:45 +0100

On 3/20/06, nagendra modadugu <[email-masked]> wrote:

Hello Nagendra,

> generate the counter block.

Now that I think of it this construction seems to benefit unreliable
datagrams most
(thus maybe DTLS couldn't work without that, but I don't remember much of dtls).

I don't understand the no additions are required though. The additions
are required
anyway since the ctr_blk has to be increased for every block to be encrypted.

> are only described in prose.  I don't think nonce is used anywhere, or am

It might be not that important but the fact that you used nonce
instead of random
bytes it initially made me think that you wanted to distinguish them
with the nonces
used in TLS (say for IV) that are referred to as random bytes.

I also wasn't that familiar with the PT and CT blocks. It might be
better if they are
properly spelled. It is nitpicking but I noticed this stuff on my first read.

> on sequence number usage.  I'm happy to discuss further if

Yes it indeed makes it clear, but since this is a requirement actually for the
author of the specification and not for the implementor, I didn't see much point
in having it capitalized.

regards,
Nikos