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

"Blumenthal, Uri" <uri.blumenthal@intel.com> Tue, 21 November 2006 16:12 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmYEN-0003ci-CX; Tue, 21 Nov 2006 11:12:19 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmYEM-0003cc-5L for tls@lists.ietf.org; Tue, 21 Nov 2006 11:12:18 -0500
Received: from mga01.intel.com ([192.55.52.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmYEI-0004lI-Im for tls@lists.ietf.org; Tue, 21 Nov 2006 11:12:18 -0500
Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by mga01.intel.com with ESMTP; 21 Nov 2006 08:12:14 -0800
Received: from fmsmsx334.amr.corp.intel.com ([132.233.42.1]) by fmsmga002.fm.intel.com with ESMTP; 21 Nov 2006 08:12:13 -0800
X-ExtLoop1: 1
X-IronPort-AV: i="4.09,443,1157353200"; d="scan'208"; a="18393763:sNHT29536101"
Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by fmsmsx334.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 08:12:13 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [TLS] NIST TLS recomendations (IV generation)
Date: Tue, 21 Nov 2006 11:12:03 -0500
Message-ID: <279DDDAFA85EC74C9300A0598E704056FE6957@hdsmsx412.amr.corp.intel.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] NIST TLS recomendations (IV generation)
thread-index: Acb9wgSf1EKVbyKaR12QoVxxwPw3hAPwCs4wAAFWovA=
From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
To: Pasi.Eronen@nokia.com, ray.perlner@nist.gov, tls@lists.ietf.org
X-OriginalArrivalTime: 21 Nov 2006 16:12:13.0567 (UTC) FILETIME=[CE4430F0:01C70D87]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc:
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

Pasi,

For the 1st statement how about:

	The IV SHOULD be chosen at random, and MUST be 
	unique and unpredictable. 

(based on crypto wisdom :-)

-----Original Message-----
From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] 
Sent: Tuesday, November 21, 2006 10:37 AM
To: ray.perlner@nist.gov; tls@lists.ietf.org
Subject: RE: [TLS] NIST TLS recomendations (IV generation)

Ray Perlner wrote:
> Page 20-21: Section 6.2.3.2 under IV The document specifies that the
> IV SHOULD be generated by method (1) or (2) and MAY be generated by
> an alternate method. There is, however, no language forbidding the
> generation of IVs by a fourth unlisted method. If a fourth method is
> used, the protocol will not fail but may be insecure. Therefore we
> recommend adding language forbidding the use of an unlisted method
> for IV generation.

Actually the whole text about IVs is quite long, and contains
implementation details that IMHO are likely to confuse rather than
help an implementer.

How about just replacing the whole text about IVs with something
like this?

   IV

       The Initialization Vector (IV) MUST be chosen at random, and
       MUST be unpredictable. See [SP800-38A] Appendix C for
       RECOMMENDED methods for generating unpredictable IVs.

       It is critical that the IV is not sent before the entire
       plaintext of the record is known; otherwise it is possible for
       the attacker to mount the attack described in [CBCATT].

       Note: In versions of TLS prior to 1.1, there was no IV field,
       and the last ciphertext block of the previous record (the "CBC
       residue") was used as the IV. This was changed to prevent the
       attacks described in [CBCATT].

Best regards,
Pasi

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

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