Re: xmlsec / ECDSA problem

[Peter Bowen]

On Wed, Feb 15, 2017 at 9:22 AM, Gervase Markham  wrote:
> On 15/02/17 17:17, Martin Thomson wrote:
>> Sure.  Both NSS and Firefox support P-521.  We still accept TLS
>> handshakes that use it (for both key exchange and signing).  I believe
>> that it is also supported in webcrypto.
>>
>> I believe that Chrome doesn't support P-521 in TLS.  We tried to
>> follow them, but only briefly.
>
> Did things break when we disabled it?
>
> Do we know why Chrome decided not to support it? Two NIST curves is enough?

I don't have any knowledge of why Chrome decided to only support P-256
and P-384.

I do know that P-256 and P-384 were the only two curves included in
the US NSA's "Suite B" specification and that the NSA did offer an
Elliptic Curve Cryptography (ECC) Patent License Agreement (PLA)
[http://web.archive.org/web/20130308064650/http://www.nsa.gov/business/programs/quick_facts.shtml]
at no charge for certain products.

It is possible that an implementer of Elliptic Curve cryptography
might want have decided to only implement curves included
specifications that are presumably covered by no charge patent license
agreements.

Thanks,
Peter
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Cipher suits, signature algorithms, curves in Firefox

[Peter Bowen]

On Thu, May 5, 2016 at 4:33 PM, Brian Smith  wrote:
> Zoogtfyz  wrote:
>>
>> 3) DHE (not ECDHE) cipher suits are far too often implemented incorrectly,
>> most often with default common DH primes, DH parameter reuse, or generally
>> weak bitstrenght (equivalent to 1024bit RSA, which is already considered
>> insecure in Firefox). Hence it's better to remove support for DHE (not
>> ECDHE) cipher suits rather than give false sense of security.
>>
>
> I agree. I think if people want non-ECC DHE cipher suites, then at a
> minimum we need to define new cipher suite IDs for them that imply keys of
> at least 2048 bits. Unless/until that happens, they are more trouble than
> they are worth.
>
> Note that Chrome recently reached the same conclusion.

Is a reasonable path to implement
https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-10 and
treat ECDHE suites as being DHE using a Supported Group?  This would
avoid new cipher suite IDs and accomplish the same result.
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: [ANNOUNCE] NSS 3.21 Release

[Peter Bowen]

On Thu, Jan 7, 2016 at 1:40 AM, Kai Engert  wrote:
> On Fri, 2015-11-13 at 18:51 +0100, Kai Engert wrote:
>> The full release notes, including the SHA1 fingerprints of the changed
>> CA certificates, are available at
>> https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.21_release_notes
>
> The above release notes have been updated to clarify that NSS 3.21 includes a
> fix for the following security-relevant bug:
>
> * Bug 1158489 (CVE-2015-7575):
>   Prevent MD5 Downgrade in TLS 1.2 Signatures
>
> The NSS development team would like to thank Karthikeyan Bhargavan from INRIA
> for responsibly disclosing the issue in Bug 1158489.

Now that the fix is released, can the bug please be made public?

Thanks,
Peter
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PKCS#11 platform integration

[Peter Bowen]

On Tue, May 12, 2015 at 8:40 AM, David Woodhouse dw...@infradead.org wrote:
 On Mon, 2015-05-11 at 11:21 -0700, Ryan Sleevi wrote:
 It's not simply sufficient to load module X into Chrome or not. p11-kit's
 security model is *broken* for applications like Chrome, at least with
 respect to how you propose to implement.

 I've proposed at least four different options and asked for opinions
 on which might be better and how to refine them; let's not get too
 hung up on how I propose to implement.

How about an even simpler solution?   Don't have p11-kit load the
PKCS#11 modules, just provide a list of paths and let the application
pass those to NSS.  That way the application can choose to
transparently load modules without user interaction, offer a UI option
for load system modules, or provide a pick list of module to load.
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto