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

From: "Blumenthal, Uri" <[email-masked]>
Date: Tue, 21 Nov 2006 12:25:04 -0500

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

:-)

-----Original Message-----
> From: ext Blumenthal, Uri [mailto:[email-masked]] 
> Sent: 21 November, 2006 18:12
> To: Eronen Pasi (Nokia-NRC/Helsinki); [email-masked]; 
> [email-masked]
> Subject: RE: [TLS] NIST TLS recomendations (IV generation)
> 
> 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: [email-masked] [mailto:[email-masked]] 
> Sent: Tuesday, November 21, 2006 10:37 AM
> To: [email-masked]; [email-masked]
> 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 21 Nov 2006 18:42:52 +0100

> 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

---

From: Ray Perlner <[email-masked]>
Date: Tue, 21 Nov 2006 16:14:41 -0500

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?

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 21 Nov 2006 14:43:57 -0800

Ray Perlner <[email-masked]> writes:
> the first encrypted block which is unpredictable.

But the first encrypted block is then used as the TLS IV.
We're just talking about the interface with the encryption
module.

-Ekr

---

From: Ray Perlner <[email-masked]>
Date: Wed, 22 Nov 2006 08:53:30 -0500

Sorry about that. I must have flipped mask and IV in my head. I will 
try to read more carefully next time.