TLS timing attack in nss (Lucky 13)

Debian Bug report logs - #699888
TLS timing attack in nss (Lucky 13)

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Thijs Kinkhorst <thijs@debian.org>

To: submit@bugs.debian.org

Subject: TLS timing attack in nss (Lucky 13)

Date: Wed, 6 Feb 2013 11:50:50 +0100

[Message part 1 (text/plain, inline)]

Package: nss
Severity: serious
Tags: security

Hi,

Nadhem Alfardan and Kenny Paterson have discovered a weakness in the handling
of CBC ciphersuites in SSL, TLS and DTLS. Their attack exploits timing
differences arising during MAC processing. Details of this attack can be
found at: http://www.isg.rhul.ac.uk/tls/

Upstream NSS progress is tracked at
https://bugzilla.mozilla.org/show_bug.cgi?id=822365

The generic protocol issue has been assigned CVE name CVE-2013-0169. The 
specific fix for NSS is known as CVE-2013-1620. Please mention these 
identifiers in the changelog.

Can you see to it that this issue is addressed in unstable and testing? And 
are you available to create an update for stable-security?


Cheers,
Thijs

[signature.asc (application/pgp-signature, inline)]

Message #10 received at 699888@bugs.debian.org (full text, mbox, reply):

From: Thijs Kinkhorst <thijs@debian.org>

To: 699888@bugs.debian.org

Subject: Re: TLS timing attack in nss (Lucky 13)

Date: Sun, 24 Feb 2013 10:47:18 +0100

[Message part 1 (text/plain, inline)]

Hi,

For the record, this is fixed in upstream release 3.14.3.
https://developer.mozilla.org/en-US/docs/NSS/NSS_3.14.3_release_notes

Cheers,
Thijs

[signature.asc (application/pgp-signature, inline)]

Message #15 received at 699888@bugs.debian.org (full text, mbox, reply):

From: Salvatore Bonaccorso <carnil@debian.org>

To: Yves-Alexis Perez <corsac@debian.org>

Cc: Michael Gilbert <mgilbert@debian.org>, 699888@bugs.debian.org, Debian Security Team <team@security.debian.org>

Subject: Re: new nss packages fixing cve-2013-1620

Date: Fri, 15 Mar 2013 16:34:51 +0100

Hi!

On Fri, Mar 15, 2013 at 03:33:05PM +0100, Yves-Alexis Perez wrote:
> On jeu., 2013-03-14 at 22:48 -0400, Michael Gilbert wrote:
> > Hi,
> > 
> > I've prepared new nss packages fixing the "lucky 13" issue:
> > http://people.debian.org/~mgilbert
> > 
> > For the mozilla team, this is a new upstream, so would you be ok with
> > it uploaded as an nmu, or would you like to upload?
> 
> It seems the BTS never received your mail, not sure why (at least it
> doesn't appear on the BTS web interface). So I'm not sure mozilla people
> received it either. Hopefully this mail will reach them.

Hmm, this is probably due to:

Topic for #debian-devel: BROKEN: mailhandling of bugs.debian.org

Current mailhandling for bugs.debian.org is not working.

Regards,
Salvatore

Message #20 received at 699888@bugs.debian.org (full text, mbox, reply):

From: Mike Hommey <mh@glandium.org>

To: Yves-Alexis Perez <corsac@debian.org>

Cc: Michael Gilbert <mgilbert@debian.org>, 699888@bugs.debian.org, Debian Security Team <team@security.debian.org>

Subject: Re: new nss packages fixing cve-2013-1620

Date: Fri, 15 Mar 2013 18:52:45 +0100

On Fri, Mar 15, 2013 at 05:50:08PM +0100, Yves-Alexis Perez wrote:
> On jeu., 2013-03-14 at 22:48 -0400, Michael Gilbert wrote:
> > Hi,
> > 
> > I've prepared new nss packages fixing the "lucky 13" issue:
> > http://people.debian.org/~mgilbert
> > 
> > For the mozilla team, this is a new upstream, so would you be ok with
> > it uploaded as an nmu, or would you like to upload?
> > 
> > For the security team, these fixes are so large that I think a
> > backport is likely impossible.  Should (can) we attempt to convince
> > the release team to jump from 3.13.6 to 3.14.3 in testing, or is that
> > crazy at this point in the freeze?  If not, then what?
> > 
> Manually adding Mike in the loop because of the broken BTS.

I was considering we should get 3.14.x in both testing and
stable-security, actually, but it needs some work to make it on par with
the versions in testing and stable, because in its current state it
breaks some things people might expect not to be broken with a stable
update (most notoriously, md5 signature of certificates are rejected,
and there are a few other things like that)

Mike

Message #25 received at 699888@bugs.debian.org (full text, mbox, reply):

From: Yves-Alexis Perez <corsac@debian.org>

To: Michael Gilbert <mgilbert@debian.org>

Cc: 699888@bugs.debian.org, Debian Security Team <team@security.debian.org>

Subject: Re: new nss packages fixing cve-2013-1620

Date: Fri, 15 Mar 2013 15:33:05 +0100

[Message part 1 (text/plain, inline)]

On jeu., 2013-03-14 at 22:48 -0400, Michael Gilbert wrote:
> Hi,
> 
> I've prepared new nss packages fixing the "lucky 13" issue:
> http://people.debian.org/~mgilbert
> 
> For the mozilla team, this is a new upstream, so would you be ok with
> it uploaded as an nmu, or would you like to upload?

It seems the BTS never received your mail, not sure why (at least it
doesn't appear on the BTS web interface). So I'm not sure mozilla people
received it either. Hopefully this mail will reach them.
> 
> For the security team, these fixes are so large that I think a
> backport is likely impossible.  Should (can) we attempt to convince
> the release team to jump from 3.13.6 to 3.14.3 in testing, or is that
> crazy at this point in the freeze?  If not, then what?

Well, starting by asking them their pov might be a good idea. And what
about Squeeze?

Regards,
-- 
Yves-Alexis

[signature.asc (application/pgp-signature, inline)]

Message #30 received at 699888@bugs.debian.org (full text, mbox, reply):

From: Yves-Alexis Perez <corsac@debian.org>

To: Michael Gilbert <mgilbert@debian.org>, glandium@debian.org

Cc: 699888@bugs.debian.org, Debian Security Team <team@security.debian.org>

Subject: Re: new nss packages fixing cve-2013-1620

Date: Fri, 15 Mar 2013 17:50:08 +0100

[Message part 1 (text/plain, inline)]

On jeu., 2013-03-14 at 22:48 -0400, Michael Gilbert wrote:
> Hi,
> 
> I've prepared new nss packages fixing the "lucky 13" issue:
> http://people.debian.org/~mgilbert
> 
> For the mozilla team, this is a new upstream, so would you be ok with
> it uploaded as an nmu, or would you like to upload?
> 
> For the security team, these fixes are so large that I think a
> backport is likely impossible.  Should (can) we attempt to convince
> the release team to jump from 3.13.6 to 3.14.3 in testing, or is that
> crazy at this point in the freeze?  If not, then what?
> 
Manually adding Mike in the loop because of the broken BTS.
-- 
Yves-Alexis

[signature.asc (application/pgp-signature, inline)]

Message #35 received at 699888@bugs.debian.org (full text, mbox, reply):

From: Mike Hommey <mh@glandium.org>

To: Yves-Alexis Perez <corsac@debian.org>

Cc: Michael Gilbert <mgilbert@debian.org>, 699888@bugs.debian.org, Debian Security Team <team@security.debian.org>

Subject: Re: new nss packages fixing cve-2013-1620

Date: Sat, 16 Mar 2013 08:34:02 +0100

On Fri, Mar 15, 2013 at 06:52:45PM +0100, Mike Hommey wrote:
> I was considering we should get 3.14.x in both testing and
> stable-security, actually, but it needs some work to make it on par with
> the versions in testing and stable, because in its current state it
> breaks some things people might expect not to be broken with a stable
> update (most notoriously, md5 signature of certificates are rejected,
> and there are a few other things like that)

So, here are a few more info:
- 3.13 disabled SSL 2.0 by default
- 3.13 added a defense against the Rizzo and Duong attack, which is
  known to break applications. It can be disabled easily.
- 3.14 removed support for md5 signature of certificates.

These are the main compatibility issues we'd have with bumping NSS to
3.14 in stable (where it's 3.12) and testing (where it's 3.13). All of
them can be fixed by turning some constants to PR_FALSE. That would
leave us with the possibility of pure bugs emerging. I think we should
take that risk, especially considering the fixes we can't backport.
That would also fix bug 697865 (that one is backportable, but that's
painful and risky).

FWIW, AFAIK, RedHat is pushing 3.14 to all its long term support
releases.

Mike

Message #40 received at 699888@bugs.debian.org (full text, mbox, reply):

From: Yves-Alexis Perez <corsac@debian.org>

To: Mike Hommey <mh@glandium.org>

Cc: Michael Gilbert <mgilbert@debian.org>, 699888@bugs.debian.org, Debian Security Team <team@security.debian.org>

Subject: Re: new nss packages fixing cve-2013-1620

Date: Sat, 16 Mar 2013 09:37:25 +0100

[Message part 1 (text/plain, inline)]

On sam., 2013-03-16 at 08:34 +0100, Mike Hommey wrote:
> So, here are a few more info:
> - 3.13 disabled SSL 2.0 by default
> - 3.13 added a defense against the Rizzo and Duong attack, which is
>   known to break applications. It can be disabled easily.
> - 3.14 removed support for md5 signature of certificates.
> 
> These are the main compatibility issues we'd have with bumping NSS to
> 3.14 in stable (where it's 3.12) and testing (where it's 3.13). All of
> them can be fixed by turning some constants to PR_FALSE. That would
> leave us with the possibility of pure bugs emerging. I think we should
> take that risk, especially considering the fixes we can't backport.
> That would also fix bug 697865 (that one is backportable, but that's
> painful and risky).
> 
> FWIW, AFAIK, RedHat is pushing 3.14 to all its long term support
> releases.

I know it's invasive but I'm not sure we won't have to do anyway during
Wheezy support life. I mean, nobody should do SSL 2.0 at all anyway
(OpenSSL already disable SSLv2 in 1.0.1, even though it doesn't matter
for browsers), and md5 for certificates is known broken too.

I'ts definitely late for such surprise for users, but will it be better
if it's done during the life of a stable release?

Regards,
-- 
Yves-Alexis

[signature.asc (application/pgp-signature, inline)]

Message #45 received at 699888@bugs.debian.org (full text, mbox, reply):

From: Thijs Kinkhorst <thijs@debian.org>

To: 699888@bugs.debian.org

Cc: Mike Hommey <mh@glandium.org>, Debian Security Team <team@security.debian.org>

Subject: Re: new nss packages fixing cve-2013-1620

Date: Sat, 16 Mar 2013 10:19:37 +0100

[Message part 1 (text/plain, inline)]

Op zaterdag 16 maart 2013 09:37:25 schreef Yves-Alexis Perez:
> On sam., 2013-03-16 at 08:34 +0100, Mike Hommey wrote:
> > So, here are a few more info:
> > - 3.13 disabled SSL 2.0 by default
> > - 3.13 added a defense against the Rizzo and Duong attack, which is
> >
> >   known to break applications. It can be disabled easily.
> >
> > - 3.14 removed support for md5 signature of certificates.
> >
> > 
> >
> > These are the main compatibility issues we'd have with bumping NSS to
> > 3.14 in stable (where it's 3.12) and testing (where it's 3.13). All of
> > them can be fixed by turning some constants to PR_FALSE. That would
> > leave us with the possibility of pure bugs emerging. I think we should
> > take that risk, especially considering the fixes we can't backport.
> > That would also fix bug 697865 (that one is backportable, but that's
> > painful and risky).
> >
> > 
> >
> > FWIW, AFAIK, RedHat is pushing 3.14 to all its long term support
> > releases.
> 
> I know it's invasive but I'm not sure we won't have to do anyway during
> Wheezy support life. I mean, nobody should do SSL 2.0 at all anyway
> (OpenSSL already disable SSLv2 in 1.0.1, even though it doesn't matter
> for browsers), and md5 for certificates is known broken too.

Well, wheezy already has 3.13 so SSLv2 and Rizzo (BEAST) are already gone in 
wheezy, right? I'm all for adding the md5 part aswell to wheezy. Indeed, we 
need to be proactive with this before it becomes a stable release. So let's go 
with 3.14 for wheezy.

> I'ts definitely late for such surprise for users, but will it be better
> if it's done during the life of a stable release?

I think the main question is if we can push this out to users of squeeze. I'm 
not against that per se. If disabling SSLv2 hurts someone seriously, it's 
about time because they'd have a big problem otherwise. This is also the case 
for BEAST, but perhaps the risk of it breaking something legitimate is higher.

We can consider to put it into a DSA in which the text details how to disable 
the options if they cause trouble. An alternative is to put it into spu 
instead, where it may be slightly (probably just slightly) more acceptable to 
change behaviour than in a DSA. But it will also mean having to wait a few 
months at least.

Do you know if RHEL is pushing it through the security channels or the stable 
updates channels?


Cheers,
Thijs

[signature.asc (application/pgp-signature, inline)]

Message #50 received at 699888@bugs.debian.org (full text, mbox, reply):

From: Michael Gilbert <mgilbert@debian.org>

Cc: 699888@bugs.debian.org, Mike Hommey <mh@glandium.org>, Debian Security Team <team@security.debian.org>

Subject: Re: new nss packages fixing cve-2013-1620

Date: Sat, 16 Mar 2013 16:53:00 -0400

> We can consider to put it into a DSA in which the text details how to disable
> the options if they cause trouble. An alternative is to put it into spu
> instead, where it may be slightly (probably just slightly) more acceptable to
> change behaviour than in a DSA. But it will also mean having to wait a few
> months at least.
>
> Do you know if RHEL is pushing it through the security channels or the stable
> updates channels?

For what its worth, ubuntu pushed 3.14 to all of its releases through
their security update channel:
http://www.ubuntu.com/usn/usn-1763-1

It also looks like bumping nspr was also required:
http://www.ubuntu.com/usn/usn-1763-2

Do you want me to look at preparing those updates for squeeze?

In the meantime, this should really be fixed in unstable.  Mike, do
you want to do a maintainer upload, or is ok if I go ahead with the
nmu?

Thanks,
Mike

Message #55 received at 699888@bugs.debian.org (full text, mbox, reply):

From: Mike Hommey <mh@glandium.org>

To: Michael Gilbert <mgilbert@debian.org>, 699888@bugs.debian.org

Cc: Debian Security Team <team@security.debian.org>

Subject: Re: Bug#699888: new nss packages fixing cve-2013-1620

Date: Sat, 16 Mar 2013 22:35:06 +0100

On Sat, Mar 16, 2013 at 04:53:00PM -0400, Michael Gilbert wrote:
> > We can consider to put it into a DSA in which the text details how to disable
> > the options if they cause trouble. An alternative is to put it into spu
> > instead, where it may be slightly (probably just slightly) more acceptable to
> > change behaviour than in a DSA. But it will also mean having to wait a few
> > months at least.
> >
> > Do you know if RHEL is pushing it through the security channels or the stable
> > updates channels?
> 
> For what its worth, ubuntu pushed 3.14 to all of its releases through
> their security update channel:
> http://www.ubuntu.com/usn/usn-1763-1
> 
> It also looks like bumping nspr was also required:
> http://www.ubuntu.com/usn/usn-1763-2

IIRC, it's not required, but one of the releases between 4.9.2 and 4.9.5
fixed some issue that might be worth fixing at this point.

> Do you want me to look at preparing those updates for squeeze?

I'd rather know what we do wrt md5, ssl2 and beast.

> In the meantime, this should really be fixed in unstable.  Mike, do
> you want to do a maintainer upload, or is ok if I go ahead with the
> nmu?

Likewise, I'd rather know what we do wrt md5, and while at it, cacert
(the cert of which uses a md5 signature at the moment, so it effectively
doesn't work ; see bug 682470) before uploading, so as to avoid doing
two uploads.

Mike

Message #60 received at 699888@bugs.debian.org (full text, mbox, reply):

From: "Thijs Kinkhorst" <thijs@debian.org>

To: "Mike Hommey" <mh@glandium.org>

Cc: "Michael Gilbert" <mgilbert@debian.org>, 699888@bugs.debian.org, "Debian Security Team" <team@security.debian.org>

Subject: Re: Bug#699888: new nss packages fixing cve-2013-1620

Date: Sun, 17 Mar 2013 10:10:06 +0100

On Sat, March 16, 2013 22:35, Mike Hommey wrote:
> On Sat, Mar 16, 2013 at 04:53:00PM -0400, Michael Gilbert wrote:
>> > We can consider to put it into a DSA in which the text details how to
>> disable
>> > the options if they cause trouble. An alternative is to put it into
>> spu
>> > instead, where it may be slightly (probably just slightly) more
>> acceptable to
>> > change behaviour than in a DSA. But it will also mean having to wait a
>> few
>> > months at least.
>> >
>> > Do you know if RHEL is pushing it through the security channels or the
>> stable
>> > updates channels?
>>
>> For what its worth, ubuntu pushed 3.14 to all of its releases through
>> their security update channel:
>> http://www.ubuntu.com/usn/usn-1763-1
>>
>> It also looks like bumping nspr was also required:
>> http://www.ubuntu.com/usn/usn-1763-2
>
> IIRC, it's not required, but one of the releases between 4.9.2 and 4.9.5
> fixed some issue that might be worth fixing at this point.
>
>> Do you want me to look at preparing those updates for squeeze?
>
> I'd rather know what we do wrt md5, ssl2 and beast.
>
>> In the meantime, this should really be fixed in unstable.  Mike, do
>> you want to do a maintainer upload, or is ok if I go ahead with the
>> nmu?
>
> Likewise, I'd rather know what we do wrt md5, and while at it, cacert
> (the cert of which uses a md5 signature at the moment, so it effectively
> doesn't work ; see bug 682470) before uploading, so as to avoid doing
> two uploads.

What information is still lacking to make a decision on that?


Thijs

Message #65 received at 699888@bugs.debian.org (full text, mbox, reply):

From: Mike Hommey <mh@glandium.org>

To: Thijs Kinkhorst <thijs@debian.org>, 699888@bugs.debian.org

Cc: Michael Gilbert <mgilbert@debian.org>, Debian Security Team <team@security.debian.org>

Subject: Re: Bug#699888: new nss packages fixing cve-2013-1620

Date: Sun, 17 Mar 2013 14:28:50 +0100

On Sun, Mar 17, 2013 at 10:10:06AM +0100, Thijs Kinkhorst wrote:
> On Sat, March 16, 2013 22:35, Mike Hommey wrote:
> > On Sat, Mar 16, 2013 at 04:53:00PM -0400, Michael Gilbert wrote:
> >> > We can consider to put it into a DSA in which the text details how to
> >> disable
> >> > the options if they cause trouble. An alternative is to put it into
> >> spu
> >> > instead, where it may be slightly (probably just slightly) more
> >> acceptable to
> >> > change behaviour than in a DSA. But it will also mean having to wait a
> >> few
> >> > months at least.
> >> >
> >> > Do you know if RHEL is pushing it through the security channels or the
> >> stable
> >> > updates channels?
> >>
> >> For what its worth, ubuntu pushed 3.14 to all of its releases through
> >> their security update channel:
> >> http://www.ubuntu.com/usn/usn-1763-1
> >>
> >> It also looks like bumping nspr was also required:
> >> http://www.ubuntu.com/usn/usn-1763-2
> >
> > IIRC, it's not required, but one of the releases between 4.9.2 and 4.9.5
> > fixed some issue that might be worth fixing at this point.
> >
> >> Do you want me to look at preparing those updates for squeeze?
> >
> > I'd rather know what we do wrt md5, ssl2 and beast.
> >
> >> In the meantime, this should really be fixed in unstable.  Mike, do
> >> you want to do a maintainer upload, or is ok if I go ahead with the
> >> nmu?
> >
> > Likewise, I'd rather know what we do wrt md5, and while at it, cacert
> > (the cert of which uses a md5 signature at the moment, so it effectively
> > doesn't work ; see bug 682470) before uploading, so as to avoid doing
> > two uploads.
> 
> What information is still lacking to make a decision on that?

Rereading your message, nothing, so I'm preparing an upload of 3.14.3
with no other change. Turns out the cacert md5 signature is not a
problem in itself, and bug 682470 is actualy about another cacert root.

Now, the problem with 3.14 is that it apparently broke other things:
bug 682470.

Mike

Message #70 received at 699888-close@bugs.debian.org (full text, mbox, reply):

From: Mike Hommey <glandium@debian.org>

To: 699888-close@bugs.debian.org

Subject: Bug#699888: fixed in nss 2:3.14.3-1

Date: Sun, 17 Mar 2013 15:05:49 +0000

Source: nss
Source-Version: 2:3.14.3-1

We believe that the bug you reported is fixed in the latest version of
nss, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 699888@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Mike Hommey <glandium@debian.org> (supplier of updated nss package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Sun, 17 Mar 2013 15:01:06 +0100
Source: nss
Binary: libnss3 libnss3-1d libnss3-tools libnss3-dev libnss3-dbg
Architecture: source amd64
Version: 2:3.14.3-1
Distribution: unstable
Urgency: high
Maintainer: Maintainers of Mozilla-related packages <pkg-mozilla-maintainers@lists.alioth.debian.org>
Changed-By: Mike Hommey <glandium@debian.org>
Description: 
 libnss3    - Network Security Service libraries
 libnss3-1d - Network Security Service libraries - transitional package
 libnss3-dbg - Debugging symbols for the Network Security Service libraries
 libnss3-dev - Development files for the Network Security Service libraries
 libnss3-tools - Network Security Service tools
Closes: 699888
Changes: 
 nss (2:3.14.3-1) unstable; urgency=high
 .
   * New upstream release.
     - Fixes TLS timing attack (luck 13). Closes: #699888.
   * debian/libnss3.symbols: Add NSS_3.14.3 symbol version.
   * debian/control: Unbump sqlite3 build dependency, 3.14.3 lifted the need
     for sqlite 3.7.15.
Checksums-Sha1: 
 3c2d194df9378bed4f164f3ec58f06c41b0b2225 2174 nss_3.14.3-1.dsc
 94d8781d1fa29cfbd37453dda3e9488709b82c4c 6189790 nss_3.14.3.orig.tar.gz
 6aa4358a512f7b541c72c1779c659a7c7f21e9a8 39498 nss_3.14.3-1.debian.tar.gz
 cc50157e4cfc4596feb18badb9e827f5272097dd 1062656 libnss3_3.14.3-1_amd64.deb
 786dae0f88b47fb24057c042e6e0472bc90da816 19956 libnss3-1d_3.14.3-1_amd64.deb
 f98eba1f5c04bd8fef485104a0ff669453188a78 228668 libnss3-tools_3.14.3-1_amd64.deb
 b70b79c2ae6c91c5463e3e01ff1b2cd32722fbda 219402 libnss3-dev_3.14.3-1_amd64.deb
 d1ee046eaf1768d53bf7629dd94559ed31b49a8a 4833896 libnss3-dbg_3.14.3-1_amd64.deb
Checksums-Sha256: 
 d25ff7871ee7c390a3d4f92b9dfad5b6ebb2c660cc1d648b6e73444a2d59ac75 2174 nss_3.14.3-1.dsc
 d9d366be94d33395597ebf82363fcdedfa693a6d627cf7f6bec025f609d54cc0 6189790 nss_3.14.3.orig.tar.gz
 c7aad54bf03f4b71a0b6700dca59aa38fc392a9ea31e1b44b050e991d6885041 39498 nss_3.14.3-1.debian.tar.gz
 93dd385717fafee68232e3f7f311221efb6a861b47c711c656456e53572d51ab 1062656 libnss3_3.14.3-1_amd64.deb
 fb47b8259ac78e1be61c46e45c7c733703b11b1515d31e31e89c40f771f1e5f2 19956 libnss3-1d_3.14.3-1_amd64.deb
 50105e13c5e626faf6fc631345dc71d3ffd02ba36138ad081b81da383308c3d4 228668 libnss3-tools_3.14.3-1_amd64.deb
 77a57612ec112848aea7f774facedeaf9dcb45b942885c8af863b1a2dd067817 219402 libnss3-dev_3.14.3-1_amd64.deb
 d317aa987bdf399ce9dffd08802dc58a0d9f2b3c2a3ce467c1d4e9c3d2fc31b9 4833896 libnss3-dbg_3.14.3-1_amd64.deb
Files: 
 8407f46305c8bfe7097bdcaada4dca81 2174 libs optional nss_3.14.3-1.dsc
 b326c2be8df277f62fb9c65fb3428148 6189790 libs optional nss_3.14.3.orig.tar.gz
 24d9781956461f453ffcb410ae5a9d27 39498 libs optional nss_3.14.3-1.debian.tar.gz
 eec9890e6e0cf580d667e1d57280b49a 1062656 libs optional libnss3_3.14.3-1_amd64.deb
 95567bdc605ff8b1cd62b27705dace4a 19956 oldlibs extra libnss3-1d_3.14.3-1_amd64.deb
 007ca0adadbacd4165630da026cdcc5e 228668 admin optional libnss3-tools_3.14.3-1_amd64.deb
 1070967e0d4e259dee92052f844469f3 219402 libdevel optional libnss3-dev_3.14.3-1_amd64.deb
 2efd4ddc4800f3a3bf02b43160481800 4833896 debug extra libnss3-dbg_3.14.3-1_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIVAwUBUUXN4+QqoE+mqoxyAQgb2A/9F7t3ei/2yT3XaQMZKUhQvYpA/MPrfRLx
Jszs4mgZVqPFCdhFuHA2ZC3CbTyq5UZeFVypffeG+aEsOa+TKVHemW8emQ6dZ2tc
snEa4KLXmy7pjP8xMKenAwVlWr8pbZuZNXYPcgPFcKrM3k9YlOCU5q3+zTMeLN4L
f4oISDf9kKpzeegp8tq07yqo3O9wq1pBGJN1QkDpSbs5+g9/wR/K3FXEePwAvDvY
PMh0ae5c6AhAlRC0YjaEX5DXsUGq9h05MxobiRcAPlzg6ZfieQB/tY3ocNrkvXIG
LzTdEh7WQ3Dsp5Z0reksUE4ZW8XS6QtNNy+p3CuFKeVdCL0adWORF8bS0X72Cut2
3pXz0P1gfK5f5BZ93VJMvhs2vS1z8mZLI3Q0yJ/hmKPqm6ppRsra2SsjzZBn+Auv
6lUSXCJ1LELtHhRL/5MAYQbno6kGHTdmL7tD2SB2bemBwsU3Fy+/jHJNeIy+tQMD
FQ66mwPl7ZeN/VWTpbjXz8dvYeEg5zP25vvi4DA2N6yyF0mhCdEZc4kXYZHHTYIh
OvwUJZuN/kqiPesRA5qp2VuJynPGGiq7dfgeperJjwKjx5yfGEeI4vg9tKQcXlWX
XIzo06Z0545LODRpjKLV7ont++pFA+XrkOgvapQEHua/vdtgCKY3Nwr96HLljR8N
pAMxApGdoMQ=
=oag7
-----END PGP SIGNATURE-----

Message #75 received at 699888@bugs.debian.org (full text, mbox, reply):

From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>

To: Mike Hommey <mh@glandium.org>, 699888@bugs.debian.org

Cc: Michael Gilbert <mgilbert@debian.org>, Debian Security Team <team@security.debian.org>

Subject: Re: Bug#699888: new nss packages fixing cve-2013-1620

Date: Mon, 18 Mar 2013 11:22:56 -0400

[Message part 1 (text/plain, inline)]

On 03/16/2013 05:35 PM, Mike Hommey wrote:
> Likewise, I'd rather know what we do wrt md5, and while at it, cacert
> (the cert of which uses a md5 signature at the moment, so it effectively
> doesn't work ; see bug 682470) before uploading, so as to avoid doing
> two uploads.

the choice of signature digest for the root CA certificate shouldn't be
relevant -- it should only be relevant for intermediate CA certificates
and end entity certificates.  if NSS is requiring certain digest
algorithms on the root CA certs, that's probably a bug.

Mike, can you clarify whether that's the case?

	--dkg

[signature.asc (application/pgp-signature, attachment)]

Message #80 received at 699888@bugs.debian.org (full text, mbox, reply):

From: Mike Hommey <mh@glandium.org>

To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>

Cc: 699888@bugs.debian.org, Michael Gilbert <mgilbert@debian.org>, Debian Security Team <team@security.debian.org>

Subject: Re: Bug#699888: new nss packages fixing cve-2013-1620

Date: Tue, 19 Mar 2013 06:45:54 +0100

On Mon, Mar 18, 2013 at 11:22:56AM -0400, Daniel Kahn Gillmor wrote:
> On 03/16/2013 05:35 PM, Mike Hommey wrote:
> > Likewise, I'd rather know what we do wrt md5, and while at it, cacert
> > (the cert of which uses a md5 signature at the moment, so it effectively
> > doesn't work ; see bug 682470) before uploading, so as to avoid doing
> > two uploads.
> 
> the choice of signature digest for the root CA certificate shouldn't be
> relevant -- it should only be relevant for intermediate CA certificates
> and end entity certificates.  if NSS is requiring certain digest
> algorithms on the root CA certs, that's probably a bug.
> 
> Mike, can you clarify whether that's the case?

It's not.

Mike

Send a report that this bug log contains spam.