Update NSS to NSS 3.13.4 pre-release snapshot 20120319.

Update NSS to NSS 3.13.4 pre-release snapshot 20120319.

This includes two changes required for Eric Rescorla's DTLS patch:
- the new SSL version range API
- TLS 1.1

clang-sslcon.patch, nextprotocleanup.patch, secret_exporter.patch,
and secret_exporter2.patch are removed because they have been checked
in.

R=rsleevi@chromium.org
BUG=118983
TEST=no build or test errors.

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=127618

[Ryan Sleevi, 2012-03-19 22:15:49]

lgtm

http://codereview.chromium.org/9733012/diff/27/net/third_party/nss/ssl/ssl3con.c
File net/third_party/nss/ssl/ssl3con.c (right):

http://codereview.chromium.org/9733012/diff/27/net/third_party/nss/ssl/ssl3co...
net/third_party/nss/ssl/ssl3con.c:9375: * discard it before decrypting the rest.
Really?

Does this have any timing side-effects?

http://codereview.chromium.org/9733012/diff/27/net/third_party/nss/ssl/ssl3co...
net/third_party/nss/ssl/ssl3con.c:9393: PORT_SetError(SSL_ERROR_BAD_MAC_READ);
Can't they also measure timing?

[commit-bot: I haz the power, 2012-03-20 00:02:18]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/wtc@chromium.org/9733012/27

[commit-bot: I haz the power, 2012-03-20 02:08:08]

Change committed as 127618

[wtc, 2012-03-20 21:15:09]

http://codereview.chromium.org/9733012/diff/27/net/third_party/nss/ssl/ssl3con.c
File net/third_party/nss/ssl/ssl3con.c (right):

http://codereview.chromium.org/9733012/diff/27/net/third_party/nss/ssl/ssl3co...
net/third_party/nss/ssl/ssl3con.c:9375: * discard it before decrypting the rest.

On 2012/03/19 22:15:50, Ryan Sleevi wrote:
> Really?

I think the use of "Instead" in this comment is a little
confusing.

We are doing what the RFC recommends.  We are
decrypting the entire GenericBlockCipher structure.
To avoid creatign a new NSS decryption context
(crSpec->decodeContext) for the new IV, we decrypt the IV
using the existing NSS decryption context.  The decrypted
output is garbage because the IV is decrypted using the
"CBC residue" in the NSS decryption context, but it has
the desired side effect of making the IV become the next
CBC residue.

We direct the output of the first crSpec->decode() to a
separate buffer (the 'iv' local variable) so that it can be
discarded easily.

> Does this have any timing side-effects?

There should be no timing side effects because we do the
same thing regardless of the value of the IV.

http://codereview.chromium.org/9733012/diff/27/net/third_party/nss/ssl/ssl3co...
net/third_party/nss/ssl/ssl3con.c:9393: PORT_SetError(SSL_ERROR_BAD_MAC_READ);

On 2012/03/19 22:15:50, Ryan Sleevi wrote:
> Can't they also measure timing?

Should I remove this comment?  I copied this comment from
the code below that handles a real decryption failure.
Here the decryption fails because the ciphertext does not
even have enough bytes for the IV block.  I also think it is
safe to set the SSL_ERROR_DECRYPTION_FAILURE error here.

[Ryan Sleevi, 2012-03-20 21:23:40]

Thanks for the explanation, Wan-Teh.

Reading the code with your annotations, it makes sense and looks fine. The
"instead" is indeed what threw me off, but I see now it's functionally
equivalent and there are no early exits before the rest of the ciphertext is
decoded.

[wtc, 2012-03-20 21:36:55]

http://codereview.chromium.org/9733012/diff/27/net/third_party/nss/ssl/ssl3con.c
File net/third_party/nss/ssl/ssl3con.c (right):

http://codereview.chromium.org/9733012/diff/27/net/third_party/nss/ssl/ssl3co...
net/third_party/nss/ssl/ssl3con.c:9393: PORT_SetError(SSL_ERROR_BAD_MAC_READ);
If you could suggest better wording for that comment, I'd
appreciate it.  I was confused by the "Instead" in that
comment.  It seems to imply a complete deviation from the
RFC recommendation, but actually we only take a slightly
different approach to accomplish the same effect more
efficiently.