[TLS] some more questions and comments on draft-ietf-tls-ctr-00.txt

Nikos Mavrogiannopoulos <nmav@gnutls.org> Sat, 04 March 2006 08:55 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFSYM-000382-Kz; Sat, 04 Mar 2006 03:55:54 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFSYL-00037S-AB for tls@lists.ietf.org; Sat, 04 Mar 2006 03:55:53 -0500
Received: from uproxy.gmail.com ([66.249.92.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFSYL-0000Gb-0q for tls@lists.ietf.org; Sat, 04 Mar 2006 03:55:53 -0500
Received: by uproxy.gmail.com with SMTP id m3so396423ugc for <tls@lists.ietf.org>; Sat, 04 Mar 2006 00:55:52 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=VtM2gKp2MS0Vs+pmrqt05xalYm+ulk2zZoOyCImt2iOJ/xMr7YRjobxd+76A16eAlM9i6nYgLh35BVGMHemJKpz5gJAmx2z2G7PJb1Vwwmj3U/IA4onXqDiSIDfSmsf3Y6CslcPlQ4pRyIRLLVK6j3mhK6GyBFgLxVKfw9szTPU=
Received: by 10.66.237.14 with SMTP id k14mr1581192ugh; Sat, 04 Mar 2006 00:55:52 -0800 (PST)
Received: from ?172.16.1.94? ( [81.175.93.238]) by mx.gmail.com with ESMTP id h1sm3410715ugf.2006.03.04.00.55.51; Sat, 04 Mar 2006 00:55:51 -0800 (PST)
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
To: tls@lists.ietf.org
Date: Sat, 04 Mar 2006 09:55:39 +0100
User-Agent: KMail/1.9.1
References: <E1FEEbS-0006vT-DQ@stiedprstage1.ietf.org>
In-Reply-To: <E1FEEbS-0006vT-DQ@stiedprstage1.ietf.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-7"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200603040955.39552.nmav@gnutls.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Subject: [TLS] some more questions and comments on draft-ietf-tls-ctr-00.txt
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org

On Wed 01 Mar 2006 00:50, Internet-Drafts@ietf.org 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

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls