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

nagendra modadugu <nagendra@cs.stanford.edu> Mon, 20 March 2006 08:46 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLG2F-0004pE-CH; Mon, 20 Mar 2006 03:46:43 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLG2E-0004oe-3s for tls@lists.ietf.org; Mon, 20 Mar 2006 03:46:42 -0500
Received: from agp.stanford.edu ([171.67.73.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLG2D-0000WO-O9 for tls@lists.ietf.org; Mon, 20 Mar 2006 03:46:42 -0500
Received: from theory.stanford.edu ([171.64.78.10]) by agp.stanford.edu with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.43) id 1FLG2D-0003Ab-9i for tls@lists.ietf.org; Mon, 20 Mar 2006 00:46:41 -0800
Received: from mail by theory.Stanford.EDU with spam-scanned (Exim 4.30) id 1FLG2C-0006wM-GP for tls@lists.ietf.org; Mon, 20 Mar 2006 00:46:41 -0800
Received: from cipher.stanford.edu ([171.64.78.146]) by theory.Stanford.EDU with esmtp (TLSv1:AES256-SHA:256) (Exim 4.30) id 1FLG2B-0006wA-BB; Mon, 20 Mar 2006 00:46:39 -0800
Received: from cipher.Stanford.EDU (localhost.localdomain [127.0.0.1]) by cipher.Stanford.EDU (8.13.4/8.12.11) with ESMTP id k2K8kdrT031889; Mon, 20 Mar 2006 00:46:39 -0800
Received: (from nagendra@localhost) by cipher.Stanford.EDU (8.13.4/8.13.4/Submit) id k2K8kcNQ031888; Mon, 20 Mar 2006 00:46:38 -0800
X-Authentication-Warning: cipher.Stanford.EDU: nagendra set sender to nagendra@cs.stanford.edu using -f
Date: Mon, 20 Mar 2006 00:46:38 -0800
From: nagendra modadugu <nagendra@cs.stanford.edu>
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>
Subject: Re: [TLS] some more questions and comments on draft-ietf-tls-ctr-00.txt
Message-ID: <20060320084638.GC30961@cs.stanford.edu>
References: <E1FEEbS-0006vT-DQ@stiedprstage1.ietf.org> <200603040955.39552.nmav@gnutls.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <200603040955.39552.nmav@gnutls.org>
User-Agent: Mutt/1.4.1i
X-Scan-Signature: 506ee2a94cbf17163a55f02c75f10d0d
X-Spam-Checker-Version: SpamAssassin 3.0.4-cs-csdcf (2005-06-05) on cs-smtp-3.Stanford.EDU
X-Spam-Level:
X-Spam-Status: No, score=-104.9 required=7.0 tests=BAYES_00, USER_IN_WHITELIST autolearn=no version=3.0.4-cs-csdcf
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc: tls@lists.ietf.org
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

Hi Nikos, sorry about the delay in responding.  My comments inline:

> 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?

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

> 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? 

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. 

> 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.

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?

> 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.

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.

> 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.

I'll clarify in the introduction section.

Thanks,
nagendra


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