Re: [TLS] NIST TLS recomendations (IV generation)

Ray Perlner <ray.perlner@nist.gov> Tue, 21 November 2006 21:14 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmcxG-0002hq-NE; Tue, 21 Nov 2006 16:14:58 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmcxF-0002hH-2Y for tls@lists.ietf.org; Tue, 21 Nov 2006 16:14:57 -0500
Received: from rimp2.nist.gov ([129.6.16.227] helo=smtp.nist.gov) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmcxB-0005JU-FB for tls@lists.ietf.org; Tue, 21 Nov 2006 16:14:57 -0500
Received: from magneto.nist.gov ([129.6.54.159]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id kALLEgeV017880; Tue, 21 Nov 2006 16:14:43 -0500
Message-Id: <7.0.1.0.2.20061121155529.02175ba8@nist.gov>
X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0
Date: Tue, 21 Nov 2006 16:14:41 -0500
To: Bodo Moeller <bmoeller@acm.org>, "Blumenthal, Uri" <uri.blumenthal@intel.com>
From: Ray Perlner <ray.perlner@nist.gov>
Subject: Re: [TLS] NIST TLS recomendations (IV generation)
In-Reply-To: <20061121174252.GB15201@tau.invalid>
References: <279DDDAFA85EC74C9300A0598E704056FE69FD@hdsmsx412.amr.corp.intel.com> <20061121174252.GB15201@tau.invalid>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: ray.perlner@nist.gov
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
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


It seems to me, that the proposed wording rules out procedure 2 and 
the alternate procedure, as in those procedures it is not the IV, but 
the first encrypted block which is unpredictable. Not that I have a 
problem with that --  it seems like it would be good for 
compatibility if TLS clients were consistent about whether the first 
block of the message is sent up to the application layer. Speaking of 
which, what is the standard procedure for a TLS 1.1 client to 
determine whether or not the first block of a decrypted message 
should be ignored?

At 12:42 PM 11/21/2006, Bodo Moeller wrote:

>On Tue, Nov 21, 2006 at 12:25:04PM -0500, Blumenthal, Uri wrote:
>
> >>> For the 1st statement how about:
> >>>
> >>>     The IV SHOULD be chosen at random, and MUST be
> >>>     unique and unpredictable.
> >>>
> >>> (based on crypto wisdom :-)
>
> >> I'd like to align the text with NIST SP 800-38A, which doesn't
> >> require uniqueness for CBC mode (and for other modes where
> >> uniqueness is required, generating the IV randomly is not
> >> usually acceptable).
>
> > I guess I have an issue with SP 800-38A then :-).
>
> >> So how about "The Initialization Vector (IV) SHOULD be
> >> chosen at random, and MUST be unpredictable" ?
> >>
> >> (This text is in section titled "CBC block cipher",
> >> so no need to consider OFB or CTR here...)
>
> > Well, I still would like to see at least "SHOULD be unique", but since
> > we are aligning with the official standard (and the issue is indeed
> > rather improbable for CBC) - I'm leaving it to the others to decide. No
> > strong push from my side in either direction.
>
>Being unpredictable makes the IVs unique except with negligible
>probability (unless you've used CBC on too long a data stream), so
>there's no need for an explicit uniqueness requirement.
>
>If we write "MUST be unique", this might evoke the perception that
>implementations using randomly generated IVs are expected to check
>whether these actually are unique, which usually is totally
>impractical, and totally unnecessary.
>
>So "SHOULD be chosen at random, and MUST be unpredictable" looks
>exactly right to me.
>
>Bodo



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