Re: Cipher suits, signature algorithms, curves in Firefox

[Brian Smith]

Zoogtfyz  wrote:

> This is my recommendation for changes to the supported ciphersuits in
> Mozilla Firefox. I performed rigorous compatibility testing and everything
> works as advertized. I used Firefox telemetry data, SSL Pulse data, and my
> own tests to verify that *not a single* publicly accessible website would
> get handshake errors compared to today.
>

Awesome.

>
> Reasoning:
> 1) Too many people put 256bit CBC cipher suits at higher priority than
> 128bit AEAD cipher suits because they don't know what they are doing.
>

Agreed.


> 2) 256bit AES cipher suits have known issues compared to 128bit AES cipher
> suits. It is not well studied yet how much those issues apply to the cipher
> suit implementation in TLS. Given that 256bit GCM cipher suits will not be
> added to Firefox, it is better to disable 256bit AES cipher suits
> completely.
>

When I the part of https://briansmith.org/browser-ciphersuites-01 regarding
AES-256, I didn't do a good job. A lot of people have interpreted what I
wrote as saying AES-256 is bad or worse cryptographically than AES-128.
That isn't what I meant to write. AES-256 still has some significant
advantages over AES-128. In particular, the larger key size helps w.r.t.
quantum computers. Further, the larger key size helps in preventing some
multi-user attacks. Even if we think that these merits are small, others do
not think they are small, and so there will always be websites that prefer
AES-256. Also, with AES-NI and similar optimizations on CPUs, AES-256 is
not too much slower than AES-128.

So, I don't think that dropping AES-256 is the right thing to do. Instead,
the ECDHE-AES-256-GCM cipher suites should be added to Firefox. Note that
they were just recently added to Google Chrome.


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


> Additionally, Firefox 45esr currently supports these signature algorithms
> in this ordering:
> SHA256/RSA, SHA384/RSA, SHA512/RSA, SHA1/RSA, SHA256/ECDSA, SHA384/ECDSA,
> SHA512/ECDSA, SHA1/ECDSA, SHA256/DSA, SHA1/DSA
>
> I recommend changing it to these in this ordering:
> SHA512/ECDSA, SHA512/RSA, SHA384/ECDSA, SHA384/RSA, SHA256/ECDSA,
> SHA256/RSA, SHA1/ECDSA, SHA1/RSA
>

I suggest you read the text that Google's David Benjamin added to the TLS
1.3 draft regarding this.

Also, see
https://groups.google.com/d/msg/mozilla.dev.security.policy/smAUN2Rtc78/EuQoSyvmAwAJ
where I argued something similar.

Reasoning:
> 1) *not a single* publicly accessible website uses DSA (not ECDSA)
> signatures anymore.


I agree DSA should be dropped


> 3) Ordering from strongest to weakest, as opposed to what it is today.
>

There are other considerations to take into account other than "strength",
as David Benjamin's proposal and my suggestion linked above show.


> Additionally, Firefox 45esr currently supports these elliptic curves in
> this ordering:
> secp256r1, secp384r1, secp521r1
>
> I recommend removing support for secp521r1 since it is not supported in
> the wild, Chrome does not support it, and we should be moving away from
> secp curves to e.g. x25519. Once again, *not a single* publicly accessible
> website breaks with this change.
>

I agree. See https://bugzilla.mozilla.org/show_bug.cgi?id=1128792.

Is your test data set and code available somewhere? It sounds interesting.

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

Re: AES-256 vs. AES-128

[Brian Smith]

Julien Vehent  wrote:

> > The discussion above was biased in favor of what was best for FirefoxOS
> and
> > FxAndroid.
>
> AES-NI has also removed mosts concerns around bad implementations of
> AES, so it seems that the attacks we were concerned about two years ago
> do not apply anymore.
>

I think they still do apply to ARM devices and to low-end Intel/AMD devices.


> ChaCha20 is a different topic entirely,


It is relevant here because there are many CPUs that can't do constant-time
AES.


> ARMv8 added support for it, so I'm guessing all apple and android mobiles
> now support AES-NI, but I am no CPU architecture expert...
>

There are many Android devices, at least, that aren't ARMv8.


> I haven't followed these discussions closely. You're proposal in those
> threads
> concerns tls1.3 specifically. Are we concerned about the nonce handling in
> 1.1 and 1.2?


There are no AEAD cipher suites in TLS 1.0 or 1.1.

For TLS 1.2, it's something that needs to be figured out. Because of the
4-byte implicit part of the nonce in TLS 1.2, the statistics in DJB's batch
attack need to be adjusted by some number <= 2^32.

Cheers,
Brian
-- 
https://briansmith.org/
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: AES-256 vs. AES-128

[Brian Smith]

Julien Vehent  wrote:

> The original thread [1] had a long discussion on this topic. The DJB batch
> attack redefines the landscape, but does not address the original concerns
> around AES-256 resistance. To me, the main question is to verify whether
> AES-256 implementations are at least as resistant as AES-128 ones, in which
> case the doubled key size provides a net benefit, and preferring it is a
> no-brainer.
>
> [1]
> http://www.mail-archive.com/dev-tech-crypto@lists.mozilla.org/msg11247.html


The discussion above was biased in favor of what was best for FirefoxOS and
FxAndroid.

That discussion also didn't account for the emergence of ChaCha20-Poly1305.
I believe it makes more sense for the server to prefer 256-bit cipher
suites than when I wrote in the discussion above, but ChaCha20-Poly1305
needs to be taken into consideration to account for ARM clients. And
unfortunately most software (OpenSSL in particular) isn't ready for
ChaCha20-Poly1305 yet.

It may be useful to compare the processing cost of AES-128, AES-256, and
gzip/deflate when making your case. In particular, if you are compressing
every response then the difference between AES-128 and AES-256 probably
doesn't matter much to you.

Regarding the batch attack mentioned by DJB, make sure you understand how
it does and does not apply to TLS. See [1] and [2] and note how
client_write_IV/server_write_IV are used.

[1] https://www.ietf.org/mail-archive/web/tls/current/msg15573.html
[2] https://www.ietf.org/mail-archive/web/tls/current/msg16088.html

Cheers,
Brian
-- 
https://briansmith.org/
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: PKCS#11 platform integration

[Brian Smith]

David Woodhouse  wrote:

> The sysadmin should be able to configure things for *all* users
> according to the desired policy, rather than forcing each user to set
> things up for themselves.
>
> And in turn the *developers* of the operating system distribution
> should be able to set a default policy for the sysadmin to build upon.
>

Actually, this is the opposite of Firefox's policy. Firefox *intentionally*
doesn't do that. It may be possible to hack things to make it work (I
believe RHEL and Fedora do something like that already, for example), but
those hacks violate the spirit, if not the letter, of the Firefox trademark
policy regarding unauthorized modifications of Firefox. And, also, AFAICT,
those kinds of hacks may stop working at any time.

Said differently, there is nothing special about Linux. Just as Firefox
intentionally doesn't use Windows's central certificate trust database on
Windows, and just as it doesn't use Mac OS X's central certificate trust
database on Mac OS X, it shouldn't use a Linux distro's central certificate
trust database.

Put yet another way, it is basically Mozilla's policy to make sysadmins'
and Linux distros' jobs difficult in this area, because doing so is sort of
required for Mozilla to maintain autonomy over its root CA inclusion
policy. Thus, "fixing" this kind of problem is actually harmful.

That said, of course it would be nice if smart cards and client
certificates worked automatically, but those improvements need to be in
such a way that they wouldn't change the trust and non-trust of server
certificates.

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

Re: Problems with FF and internal certificates

[Brian Smith]

On Fri, May 1, 2015 at 9:11 AM, Tanvi Vyas  wrote:

> > On Apr 27, 2015, at 2:03 PM, Michael Peterson <
> michaelpeterson...@gmail.com> wrote:
> > Now, in the album I posted above (https://imgur.com/a/dmMdG), the last
> two screenshots show a packet capture from Wireshark. It appears that
> Firefox does not support SHA512, which is kind of supported by this article
> (
> http://blogs.technet.com/b/silvana/archive/2014/03/14/schannel-errors-on-scom-agent.aspx).
> I'm not exactly sure this is true, and it seems like a silly thing for
> Firefox to drop support though (this previously worked), especially if
> every other browser in the world supports this.
> >
> > So there's everything we've found, and some of my assumptions. Does
> anyone know what is actually going on with Firefox. Is this a bug? Are we
> doing something wrong? How do we fix this?
>

SHA-384 is SHA-512 truncated to 384 bits.

I guess your ECDSA certificate is using the P-384 curve. If so, your
SHA-512 digest is truncated to ~384 bits in order to work with the P-384
curve. (If you are using the P-256 curve, then it is truncated to ~256
bits.)

Consequently, there's no advantage to using SHA-512 instead of SHA-384.

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

Re: FF 37 - ssl_error_no_cypher_overlap with java SSL and java generated self-signed certificates

[Brian Smith]

Gervase Markham  wrote:
> On 07/04/15 17:32, Hanno Böck wrote:
>> Are you using DSA? Firefox removed DSA recently (which is good - almost
>> nobody uses it and it's a quite fragile algorithm when it comes to
>> random numbers).
>
> Hanno's probably hit the nail on the head here.
> https://bugzilla.mozilla.org/show_bug.cgi?id=1073867 was fixed in
> Firefox 37.

The removal of the DSS-based *cipher suites* was
https://bugzilla.mozilla.org/show_bug.cgi?id=1107787, which was also
done in Firefox 37.

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

Re: What's My Chain Cert?

[Brian Smith]

Rob Stradling  wrote:
> The README [1] says:
> "If multiple certificate chains are found, the shortest one is used."
>
> That's a good strategy for a browser to employ when deciding which chain to
> show in its certificate viewer, but it's unlikely to be the best strategy
> when configuring a server.
> There's often a cross-certificate issued by an older root to a newer root.
> For compatibility with browsers that don't trust the newer root, the server
> should send that cross-certificate too (even though it isn't part of the
> shortest chain).
>
> Using the longest available chain isn't always the correct strategy either
> though.

See also CloudFlare's "cfssl bundle" tool, which has an option to
build the most client-compatible cert chain bundle:
https://github.com/cloudflare/cfssl.

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

Re: Remove Legacy TLS Ciphersuites from Initial Handshake by Default

[Brian Smith]

Ryan Sleevi  wrote:
> On Mon, March 16, 2015 1:06 pm, Erwann Abalea wrote:
>>
>>  Phase RSA1024 out? I vote for it. Where's the ballot? :)
>
> This is a browser-side change. No ballot required (the only issue *should*
> be non-BR compliant certificates issued before the BR effective date)
>
> https://code.google.com/p/chromium/issues/detail?id=467663 for Chrome, but
> unfortunately, can't share the user data as widely. Perhaps Mozilla will
> consider collecting this as part of their telemetry (if they aren't
> already)

The Fx telemetry is
https://bugzilla.mozilla.org/show_bug.cgi?id=1049740 and the Fx bug
for removing support for <2048-bit certificates is
https://bugzilla.mozilla.org/show_bug.cgi?id=1137484.

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

Re: Interested in reviving PSS support in NSS

[Brian Smith]

Hanno Böck  wrote:
> Brian Smith  wrote:
> Having new oids with sane pre-defined parameters would vastly simplify
> things. Back when I wrote that code I thought changing the standard is
> harder than implementing the non-optimal spec, but I might've been
> wrong.

To clarify: I'm suggesting that you parse the raw RSA-PSS parameters
from the signature and from the public key into a tuple
(hashAlgorithm, maskGenAlgorithm, saltLength) like you normally would.
Then, for certain tuples, define OIDs that are only used internally in
NSS to identify (using the SECOidTag representation) that combination.
These OIDs would never be seen on the wire.

This would mean, in addition, that instead of having an rsaPSSKey
type, that we'd have an rsa_PSS_SHA256_MGF1SHA256_32_key type and an
rsa_PSS_SHA384_MGF1SHA384_48_key type.

> Such an RFC could also just declare that keys not divisable by 8 are
> disallowed and by that fix that problem as well.

Sure, but in practice it isn't a problem. Everybody's been doing the
same for RSA-PKCS#1.5 forever already.

> I don't really know what channels I'd have to go through to pursue
> such a preset-OID. Can an OID be defined by an RFC? How does the
> interaction between the OID registration and RFCs work? Is this
> something the CFRG would do or some other entity in the IETF?

As I mentioned above, you don't need to define these OIDs in an RFC,
since they would exist only for the purpose of fitting into NSS's API.

The purpose of the RFC would be to nail down which (hashAlgorithm,
maskGenAlgorithm, saltLength) are allowed and mandatory to support for
certificates.

Note that Microsoft's documentation hints that they implemented
RSASSA-PSS-SHA256 using the tuple (SHA256, MGF1-SHA1, 20) instead of
(SHA256, MGF1-SHA256, 32) like I would expect. Perhaps their
RSASSA-PSS-SHA384 is (SHA384, MGF1-SHA1, 20) too? If so, is it more
important to interop with them than to have all the parameters match
in the intuitive way?

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

Re: Interested in reviving PSS support in NSS

[Brian Smith]

Ryan Sleevi  wrote:
>   - It assumes all the parameters can be expressed via a SECOidTag. That
> is, it's missing hash alg, mgf alg, salt length (e.g. the
> RSASSA-PSS-params construction)

I believe there are only a small number of (hashAlgorithm, mgf alg,
salt length) combinations that need to be supported, namely these two:

(sha256, mgf1-SHA256, 32 bytes)
(sha384, mgf1-SHA384, 48 bytes)

I think that in NSS, these combinations can be identified internally
with some new OID, perhaps in the Netscape OID tree.

Note that the PSS RFC says that SHA-1 is the default for everything.
By not supporting SHA-1 at all, we avoid having to deal with any
implicit encodings of the various parameters. The PSS RFC also says
that SHA-1 is mandatory, but that silliness is just an invitation for
somebody to get their name as an author of a new, reasonable, RFC.

Thoughts?

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

Re: Interested in reviving PSS support in NSS

[Brian Smith]

[+antoine]

Hanno Böck  wrote:
> Unfortunately the code never got fully merged. Right now the state is
> that code for the basic functions exists in freebl, but all upper layer
> code is not merged.

There are multiple "upper layers" and, depending on your goals, some
should be prioritized higher than others.

> I think if I remember correctly the code currently
> in freebl will also not work in some corner cases (keys mod 8 != 0).

IIUC, this is not urgent to support and may not be worth supporting at
all. IIRC, there are lots of places in NSS and mozilla::pkix that
explicitly reject keys and signatures that are not multiples of 8
bits.

> The bugtracker entry is here:
> https://bugzilla.mozilla.org/show_bug.cgi?id=158750

That bug is too big and messy to make sense of at this point. Also,
some of the patches that haven't been checked in yet should be split
up. I suggest that you proceed as follows:

1. Split 000a-pss-verification-v15.diff into two patches: One part
that adds the pk11wrap functionality, and a separate part that adds
the cryptohi functionality. Put each new patch in its own new NSS bug.

2. Move 0009-add-pk11-mgfmap-v3.diff, 000b-pss-sign-v15.diff, and
000c-tests-v2.diff to a new bug.

3. Move 0012-fix-pss-verification-for-uncommon-keysizes-v5.diff to a
new bug, which will have low priority.

4. Close the existing bug as RESOLVED FIXED.

Even with all the above patches landed, Firefox and other Gecko-based
applications will not accept PSS signatures for certificates. Of the
above patches, only the patch to add PK11_VerifyWithSigAlg is relevant
to Gecko. New patches for mozilla::pkix and for its test suite, which
basically duplicate all the work in the rest of the patches mentioned
above, would be needed. But...

> I want to make a proposal to get PSS support into TLS
> 1.3 and it would certainly help if I could say that all major TLS
> libraries support it already.

First somebody needs to create a reasonable specification detailing
exactly which subset of the PSS specification should be supported for
TLS. The current PSS specification allows *way* too much flexibility
and also has terrible defaults. I believe Antoine and his team have a
good idea of what a reasonable subset of PSS would look like. I
recommend working with him to develop such a spec. Without such a
spec, I wouldn't support adding PSS support to mozilla::pkix.

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

Re: Reducing NSS's allocation rate

[Brian Smith]

On Mon, Nov 10, 2014 at 9:04 PM, Nicholas Nethercote
 wrote:
>> In your analysis, it would be better to use a call stack trace depth
>> larger than 5 that allows us to see what non-NSS function is calling
>> into NSS.
>
> I've attached to the bug a profile that uses a stack trace depth of 10.

Unfortunately, 10 isn't enough to see the non-NSS entry (one that
doesn't start with "security/nss/") for every case. However, it looks
like the data supports the types of changes that you are making and
also my suggestions for coalescing and caching results, as well as my
suggestion to avoid constructing CERTCertificate objects. Depending on
how much effort you're willing to invest in this, many (probably most)
of those allocations can be avoided. David Keeler is very familiar
with the code in security/certverifier and security/manager/ssl/src
that would be changed to implement the additional things I suggested,
so I suggest you talk to him about it.

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

Re: Reducing NSS's allocation rate

[Brian Smith]

On Mon, Nov 10, 2014 at 6:51 PM, Nicholas Nethercote
 wrote:
> I've been doing some heap allocation profiling and found that during
> basic usage NSS accounts for 1/3 of all of Firefox's cumulative (*not*
> live) heap allocations. We're talking gigabytes of allocations in
> short browsing sessions. That is *insane*.
>
> I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1095272 about
> this. I've written several patches that fix problems, one of which has
> r+ and is awaiting checkin; check the dependent bugs.

In your analysis, it would be better to use a call stack trace depth
larger than 5 that allows us to see what non-NSS function is calling
into NSS.

The checks done in mozilla::pkix's CheckPublicKeySize can easily be
optimized. But, first check how often the call stack contains
CheckPublicKey vs VerifySignedData; CheckPublicKey can be optimized
even more than VerifySignedData.

My original plans for VerifySignedData was for it to have a cache
added to it, if/when performance testing showed that there was a
performance problem. It is likely that such a cache is important, even
without the heap thrashing that you are concerned about.

Also, there is already a bug on file about caching and coalescing SSL
server cert verification results in SSLServerCertVerification. This is
trickier than the type of caching you can do in VerifySignedData but
it is potentially a bigger win. Also, I think recent changes to
Gecko's connection management (the "parallelism to a new host
restricted to 1" bug being fixed) made it more important to do at
least the coalescing part.

Note that when bug 1036103 is fixed (which will be basically whenever
I get around to posting one more patch), it will be possible to avoid
any of the NSS CERT_* API during certificate verification, if people
are willing to do a little (probably quite a bit, actiually)
refactoring.

That that, except for the calls to
SECKEY_DecodeDERSubjectPublicKeyInfo and SECKEY_ExtractPublicKey in
CheckPublicKeySize, mozilla::pkix allocates no memory at all, ever
(once CheckNameConstraints is replaced, which is the thing that is one
patch away from happening).

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

Re: Road to RC4-free web (the case for YouTube without RC4)

[Brian Smith]

On Sun, Jun 29, 2014 at 11:18 AM, Hubert Kario  wrote:

> The number of sites that prefer RC4 while still supporting other ciphers
> are
> very high (18.6% in June[1], effectively 21.3% for Firefox[6]) and not
> changing much. The percent of servers that support only RC4 is steadily
> dropping (1.771% in April[3], 1.194% in May[2], 0.985% in June[1]).
>
> Because of that, disabling RC4 should be possible for many users. The big
> exception for that was YouTube video servers[4] which only recently gained
> support for TLS_RSA_WITH_AES_128_GCM_SHA256.
>

Sorry that I couldn't say more earlier, but please see this message from
Adam Langley of Google about YouTube working on
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256:

http://www.ietf.org/mail-archive/web/tls/current/msg14112.html

"And TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 support is coming -- it's already
enabled in some locations."

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

Re: Announcing Mozilla::PKIX, a New Certificate Verification Library

[Brian Smith]

On Thu, Oct 2, 2014 at 9:03 AM,   wrote:
> Maybe there is something that can be done to hep this situation? Maybe these 
> old "private" certificates need to be cleaned out on upgrade? Or maybe 
> something in the code that is going nuts trying to validate these "private" 
> certificates needs to be fixed?

There is already a bug report about this issue:
https://bugzilla.mozilla.org/show_bug.cgi?id=1056341

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

Re: Announcing Mozilla::PKIX, a New Certificate Verification Library

[Brian Smith]

On Tue, Aug 5, 2014 at 9:51 AM,   wrote:
> Since updating to 31, I have not been able to log into a self signed web page:
>
> Secure Connection Failed
>
> An error occurred during a connection to taiserver:444. Certificate key usage 
> inadequate for attempted operation. (Error code: 
> sec_error_inadequate_key_usage)
>
> How do I get this corrected?

Please file a bug at
https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Security:%20PSM
(Product: Core, Component: PSM) and attach the certificate in question
to the bug report.

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

David Keeler is now the module owner of PSM

[Brian Smith]

Hi,

Amogst other things, PSM is the part of Gecko (Firefox) that connects
Gecko to NSS and other crypto bits.

David Keeler has taken on most of the responsibility for keeping
things in PSM running smoothly and so it makes sense to have him be
the module owner. After asking the other PSM module peers, I went
ahead and made that change:

https://wiki.mozilla.org/Modules/Core#Security_-_Mozilla_PSM_Glue

Congratulations David!

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

Re: Road to RC4-free web (the case for YouTube without RC4)

[Brian Smith]

On Thu, Jul 10, 2014 at 5:00 AM, Hubert Kario  wrote:
> - Original Message -
>> From: "Brian Smith" 



>> However, it is likely that crypto libraries that make the two changes above
>> will also have support for TLS_ECDHE_*_WITH_AES_*_GCM cipher suites too.
>> So, I hope that they also enable TLS_ECDHE_*_WITH_AES_*_GCM at the same
>> time they deploy these changes.



> What basis do you have to assume that server administrators will actually
> upgrade their Apache/nginx/lighttpd/OpenSSL/etc. installations?

In this thread you pointed out that a number of websites had updated
their servers to add TLS_RSA_WITH_AES*_GCM* and disable
TLS_RSA_WITH_*_CBC_*, so that Firefox now only negotiates RC4 with
them when it could be negotiating AES-GCM. The fact that they updated
their servers to add non-ECDHE AES-GCM support is good evidence that
these server administrators are paying attention and are likely to
update if/when their server software vendor gives it to them if it
solves a need (like improving what Firefox negotiates), right?

Regarding your request about how to write the addon: I don't have time
to work on that addon, but I know it is possible to write it.

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

Curve25519 and/or Curve41417 and/or Alternatives in Gecko/Firefox (was Re: Road to RC4-free web (the case for YouTube without RC4))

[Brian Smith]

On Thu, Jul 10, 2014 at 5:33 AM, Kurt Roeckx  wrote:
>
> [snip]
> An other alternative is using curve25519.  It's also not standardized yet, 
> but at this time it seems more likely to be standardized first.

Thanks for bringing up curve25519. I'd like to share a recent paper
written by Daniel J. Bernstein, Chitchanok Chuengsatiansup, and Tanja
Lange:

  "Curve41417: Karatsuba revisited.''
  http://cr.yp.to/papers.html#curve41417

Section 1.5, "Is high security useful?" is particularly interesting.

I think it is likely the case that Curve25519 solves the wrong
problem*: it tries to be faster than NIST P-256 but only the same
strength, but I think a new standard curve should be the same speed as
NIST P-256 but much stronger. My thinking is that now, when Curve25519
isn't an option, everybody is using P-256 without significant
performance complaints. This shows that we don't really need something
faster than P-256. Further, as the paper states in section 1.5, there
are quite a few reasons to want to have a security level higher than
~125 bits, if we can get it with reasonable performance and without
compromising other security goals, which we apparently can, according
to this paper.

By the way, an extra notable merit of this paper is that they focused
on ARM performance

I would like to hear what others think about this, including what
people think Gecko should do.

Cheers,
Brian

* Besides performance, Curve25519 solves other problems, but in
general all of the other new alternatives like curve41417 solve them
too.
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

ChaCha20-Poly1305 in Gecko/Firefox (was Re: Road to RC4-free web (the case for YouTube without RC4))

[Brian Smith]

On Thu, Jul 10, 2014 at 4:53 AM, Henri Sivonen  wrote:

> On Tue, Jul 1, 2014 at 11:58 PM, Brian Smith  wrote:
> > I am interested in discussing what we can do to help more server side
> > products get better cipher suites by default, and on deciding whether we
> > add support for ChaCha20-Poly130[5].
>
> Out of curiosity, what's holding back a decision to implement
> ChaCha20-Poly1305?
>

As you probably know, Google Chrome already ships some ChaCha20-Poly1305
cipher suites. They have a patch that they apply on top of NSS to implement
them. I recently asked a couple of our friends on the Chrome team about
contributing that patch to NSS proper. Apparently, the implementation of
those cipher suites diverges from the current or some expected future draft
of the IETF specification. Consequently, it isn't clear that it is a good
idea to drop that patch into NSS as-is. And, if we modify the patch to
match the current/future IETF documents then Firefox wouldn't be able to
interoperate with *.google.com using ChaCha20-Poly1305.

So, either we'd have to decide on having Firefox implement an
already-obsolete variant of the cipher suites (temporarily, of course) or
we'd have to find some partner sites (perhaps still *.google.com) that are
willing to speak the new variants of the cipher suites, for it to be
useful. This may require updated patches for OpenSSL in order for those
servers to even be able to do that.

Also, Chromium has a patch on top of NSS that allow the browser to
dynamically reorder the cipher suite list presented in the Client Hello
message. Chromium uses this in order to put the ChaCha20-Poly1305 cipher
suites ahead of the AES-GCM cipher suites on platforms that are lacking AES
and/or GCM processor instructions. That is, usually ChaCha20-Poly1305 is
ordered ahead of AES-GCM on ARM but AES-GCM is ahead of ChaCha20-Poly1305
on x86. We'd have to decide whether that would be appropriate for Firefox
and if so we'd need to add that functionality to NSS.

So, what initially looked like a minor amount of effort turned into a more
significant effort. If there is somebody interested in taking this on, I
would be very happy to help them with it.

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

Re: Road to RC4-free web (the case for YouTube without RC4)

[Brian Smith]

On Wed, Jul 2, 2014 at 5:08 AM, Hubert Kario  wrote:

> Also, see Gavin's email here about adding such prefs in general. He
> > basically says, "Don't do it." Note that Gavin is the Firefox module
> owner:
> >
> https://groups.google.com/d/msg/mozilla.dev.platform/PL1tecuO0KA/e9BbmUAcRrwJ
>
> "As Benjamin notes,
> an add-on is a much better way to suggest people customize these
> things, and writing an add-on that sets a pref is trivial."
>
> So you'd accept code that is able to change this preference but doesn't
> expose it through about:config?
>
> I'm more that willing to create such patchset and extension pair.
>

It is already possible to write such an extension without any new Firefox
APIs, because extensions can call NSS functions.

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

Re: Road to RC4-free web (the case for YouTube without RC4)

[Brian Smith]

On Wed, Jul 2, 2014 at 5:28 AM, Hubert Kario  wrote:

> > On 7/1/2014 14:05, Brian Smith wrote:
> > > I think, in parallel with that, we can figure out why so many sites
> > > are still using TLS_ECDHE_*_WITH_RC4_* instead of
> > > TLS_ECDHE_*_WITH_AES* and start the technical evangelism efforts to
> > > help them. Cheers, Brian
> > The reason for sites choosing RC4 over AES_CBC might be due to the
> > various vulnerabilities against CBC mode, at least for sites that
> > support TLS 1.0 .
>
> problem is that to support AES-GCM and ECDHE you need the very newest
> both Apache and OpenSSL.
>

> If you have older Apache, you do get TLS 1.2 and you do get SHA-256
> suites, but you can't use ECDHE.
>

It depends on what distro you are using and how old of an Apache you are
talking about. Debian has shown it is relatively straightforward to
backport ECDHE support to Apache 2.2.x, so I think other distros will also
be able to do so. I'm sure it isn't a trivial effort, but it is definitely
worthwhile to do so.


> You also can't set different cipher order for TLS1.1 and up and TLS1.0
> and lower.
>

The software can be changed to add this feature, and those changes can be
backported.


> So a server that has order like this:
> DHE-RSA-AES128-GCM-SHA256
> DHE-RSA-AES128-SHA256
> AES128-GCM-SHA256
> AES128-SHA256
> RC4-SHA
> DHE-RSA-AES128-SHA
> AES128-SHA
>
> will negotiate RC4 with Firefox. Such configuration has about 2% of
> servers.
>

I understand. But, I think the best way of accommodating those servers is
for the server software vendor to provide an (semi-)automatic update that
enables the TLS_ECDHE_*_WITH_AES*_GCM_* cipher suites.

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

Re: Road to RC4-free web (the case for YouTube without RC4)

[Brian Smith]

On Tue, Jul 1, 2014 at 7:15 PM, Julien Pierre 
wrote:

> On 7/1/2014 14:05, Brian Smith wrote:
>
>> I think, in parallel with that, we can figure out why so many sites are
>> still using TLS_ECDHE_*_WITH_RC4_* instead of TLS_ECDHE_*_WITH_AES* and
>> start the technical evangelism efforts to help them. Cheers, Brian
>>
> The reason for sites choosing RC4 over AES_CBC might be due to the various
> vulnerabilities against CBC mode, at least for sites that support TLS 1.0 .
> I think a more useful form of evangelism would be to get sites to stop
> accepting SSL 3.0 and TLS 1.0 protocols.
>

Servers that cannot, for whatever reason, support the AES-GCM cipher
suites, should be changed to prefer AES-CBC cipher suites over RC4-based
cipher suites at least for TLS 1.1 and later.

Most sites are not going to stop accepting SSL 3.0 and/or TLS 1.0 any time
soon, because they want to be compatible with Internet Explorer on Windows
XP and other software that doesn't support TLS 1.1+.

However, in the IETF, there is an effort, spearheaded by our friends at
Google, for solving the downgrade problem:
http://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00

This simple feature, if implemented by the browser and by the server,
allows the server to recognize that the browser has tried a non-secure
downgrade to a lower version of TLS. Once the server recognizes that, the
server can reject the downgraded connection. The net effect is that,
assuming modern browsers quickly add support for this mechanism, the server
can be ensure that it only uses CBC cipher suites with modern browsers over
TLS 1.1 or later and that it never uses RC4-based cipher suites with modern
browsers (in conjunction with the "prefer AES-CBC cipher suites over RC4
cipher suites" change I suggest above).

However, it is likely that crypto libraries that make the two changes above
will also have support for TLS_ECDHE_*_WITH_AES_*_GCM cipher suites too.
So, I hope that they also enable TLS_ECDHE_*_WITH_AES_*_GCM at the same
time they deploy these changes.

FWIW, I filed bugs [1][2] for adding support for
draft-ietf-tls-downgrade-scsv-00 to NSS, Gecko, and Firefox.

Cheers,
Brian

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1036737
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1036735
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Road to RC4-free web (the case for YouTube without RC4)

[Brian Smith]

On Mon, Jun 30, 2014 at 1:56 AM, Kurt Roeckx  wrote:

> On 2014-06-30 02:35, Hubert Kario wrote:
>
>> The benefits of ECDHE outweigh the risks of using RC4,
>>>
>>
>> I have to disagree here. Even 1024 bit DHE requires a targeted attack at
>> ~80 bit
>> complexity. Currently we see RC4 at around 56 bit, with a completely
>> unoptimized
>> attack...
>>
>
> Do you have a reference for those 56 bit?  You're not talking about the
> old export ciphers I hope?  I haven't seen anything saying that the 128 bit
> RC4 has a complexity of 56 bit.  If it's really at 56 bit, we should
> disable it everywhere now, no matter if it breaks things or not.
>
> I think we should do all that's possible to avoid RC4.  I think that for
> now we should follow Microsoft in not having RC4 in the initial handshake
> and if fails retry with RC4 enabled.  It's my understanding that that
> should reduce RC4 usage from 20% of the sites to 1%.
>

I would welcome a patch that does that. I think initially we should do it
without disabling TLS_ECDHE_*_WITH_RC4_*, instead only disabling
TLS_RSA_WITH_RC4_*, so that we don't push sites that choose
TLS_ECDHE_*_WITH_RC4_* to using non-ephemeral key exchange. I think, in
parallel with that, we can figure out why so many sites are still using
TLS_ECDHE_*_WITH_RC4_* instead of TLS_ECDHE_*_WITH_AES* and start the
technical evangelism efforts to help them.

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

Re: Road to RC4-free web (the case for YouTube without RC4)

[Brian Smith]

On Sun, Jun 29, 2014 at 5:35 PM, Hubert Kario  wrote:

>
> > As I noted in my bug comment [1], I think that the rhetoric of us not
> > adding any more RSA-key-exchange-based cipher suites, even the AES-GCM
> > ones, is significant. Software engineers at multiple companies referenced
> > our positions on this as part of making the business case for raising the
> > priority of ECDHE support in their products.
>
> I fail to see how changing /non default/ settings affects that.
>

Some Linux distros may be tempted to change their default Firefox
configuration files so that a different set of cipher suites is enabled by
default. I am very opposed to that, and that's one of the biggest reasons
why particularly in PSM I discourage preferences.


> I mean, I've been surfing with disallowed pictures for mixed content
> (security.mixed_content.block_display_content). You'd be surprised at
> amount
> of sites that break because of that. Disabled JavaScript is similar.
> Webmasters make sites and configure servers against the lowest common
> denominator: it works, then the work is done. They don't check what
> happens if
> the user is running non standard configuration. I've never seen a website
> that said to the user to modify the settings in about:config to make the
> site work as intended.
>

If it were up to me, we wouldn't have either of the block_display_content
or disable-Javascript preferences either.

Also, see Gavin's email here about adding such prefs in general. He
basically says, "Don't do it." Note that Gavin is the Firefox module owner:
https://groups.google.com/d/msg/mozilla.dev.platform/PL1tecuO0KA/e9BbmUAcRrwJ


> 20% of Internet servers negotiating suboptimal ciphers is not *really bad*?
> How much do we have to reach for that to be a problem?
>

It would be better to have less (no) RC4 usage but I don't think it is as
urgent of a problem as you seem to. Also, I feel like it is really not a
great use of time to re-open the debate about adding support for
about-to-be-deprecated cipher suites to Firefox. In the short term, things
are going to be suboptimal but we're far from disabling RC4 by default, and
the default configuration is really what we care about.

I am interested in discussing what we can do to help more server side
products get better cipher suites by default, and on deciding whether we
add support for ChaCha20-Poly1304, but otherwise I think we should table
the discussion until more server-side products and more servers have had
sufficient time to react to what we've already decided.

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

Re: Road to RC4-free web (the case for YouTube without RC4)

[Brian Smith]

On Sun, Jun 29, 2014 at 11:18 AM, Hubert Kario  wrote:

> Because of that, disabling RC4 should be possible for many users. The big
> exception for that was YouTube video servers[4] which only recently gained
> support for TLS_RSA_WITH_AES_128_GCM_SHA256.
>

Hi,

I read your blog post at
http://securitypitfalls.wordpress.com/2014/06/29/is-rc4-less, which is
interesting. The blog post compares how enabling/disabling various cipher
suites affects the percentage of sites that end up negotiating RC4.
However, I noticed that you didn't measure how enabling/disabling various
cipher suites affects how often Firefox uses ECDHE, DHE with a strong
(>=1280 bit, at least), DHE with weak, or RSA key exchange.

Using the Firefox 30 telemetry data [0], I saw that
TLS_ECDHE_RSA_WITH_RC4_128_SHA is still the 7th most commonly negotiated
cipher suite, at ~1.1% of all full handshakes that Firefox does, and that
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA is the 12th most common cipher suite, at
0.1%. Also note that these two cipher suites are the least-preferred ECDHE
cipher suites in Firefox's ClientHello, so it seems likely that disabling
these two cipher suites will reduce the use of ECDHE by ~1.2%. IIRC, when I
analyzed this previously, I found that almost every site negotiating
ECDHE-RC4 cipher suites would do RSA key exchange if we disabled these two
cipher suites. The benefits of ECDHE outweigh the risks of using RC4, so I
think that disabling these two cipher suites or changing their
prioritization in the Firefox ClientHello would be a bad idea at this time.
So, at a minimum, it would be important to re-run your analysis with these
two cipher suites still enabled to see what the real effect of adding
RSA-AES-GCM cipher suites.

As I noted in my bug comment [1], I think that the rhetoric of us not
adding any more RSA-key-exchange-based cipher suites, even the AES-GCM
ones, is significant. Software engineers at multiple companies referenced
our positions on this as part of making the business case for raising the
priority of ECDHE support in their products. It has been slow going, but
also it has only been half a year since we shipped the new cipher suite
configuration in Firefox. The effects on other products will be more clear
soon, if what I am told is correct. In particular, I see that Red Hat [2]
and Canonical [3] are still debating whether to backport ECDHE support to
Apache 2.2. I think that by maintaining our position here, we can help the
engineers working on that make a stronger case for those backports.

By the way, I'd like to again thank Kurt Roeckx for his efforts to convince
Debian to backport ECDHE support to Debian's Apache 2.2 [4].


> So let me be blunt. Why we can't have[5] a setting that will allow users of
> over 2% of servers increase their security[6] and make youtube usable for
> people that disabled RC4[7,8,9]. While we have a setting like
> security.ssl3.rsa_seed_sha which as far as I can see affects no servers[6]?
>

I agree that we should treat the RSA-AES-GCM cipher suites the same way we
treat those other cipher suites that are disabled by default. I filed bug
1031952 [5] and wrote the patch to remove the unneeded preferences.


> Note that I'm not talking about changing the default configuration, I'm
> talking only about adding optional functionality.
>

Like I said in the bug [1], in PSM we only add such prefs as a last resort,
and I don't think we're that desperate yet. The prefs like
security.ssl3.rsa_seed_sha existed before we started the effort to reform
Firefox's cipher suite, and it was always intended to remove them once we'd
verified that we hadn't caused any significant compatibility issues with
the new configuration.

Cheers,
Brian

[0]
http://telemetry.mozilla.org/#filter=release%2F30%2FSSL_CIPHER_SUITE_FULL&aggregates=multiselect-all!Submissions&evoOver=Builds&locked=true&sanitize=false&renderhistogram=Table
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1029179#c3
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1035818
[3] https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1197884
[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733564
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=1031952
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Intent to unimplement: proprietary window.crypto functions/properties

[Brian Smith]

On Fri, Jun 27, 2014 at 9:19 AM, David Keeler  wrote:

> On 06/27/2014 07:37 AM, Nathan Kinder wrote:
> > On 06/27/2014 12:13 AM, Frederik Braun wrote:
> >> To be frank, I have only ever seen the non-standard crypto functions
> >> used in attacks, rather than in purposeful use.
> >
> > That doesn't mean that aren't being purposefully used.  The current
> > crypto functions are used pretty heavily by Dogtag Certificate System
> > [1], and this has been the case for many years.
> >
> > I believe that one of the big things lacking in WebCrypto is a suitable
> > replcement for generateCRMFRequest(), which allows for key escrow.  I'm
> > not certain if an addon will be able to replace this functionality.
>
> Looking at the working draft of the spec[0], there are functions to
> generate, export, and wrap keys, so it looks like webcrypto can be used
> to implement key escrow (unless I'm misunderstanding the term).
> Again, though, addons can pretty much do anything, so if webcrypto isn't
> up to the task, an addon should be able to fill the gap.
>

The issue is that the WebCrypto API uses a totally separate keystore from
the X.509 client certificate keystore (if it doesn't, it should be), and
the stuff that Red Hat does is about client certificates. AFAICT, WebCrypto
doesn't get have any mechanism for accessing the client certificate store
and it isn't clear if/when that would be added.

However, an addon would be able to do these things, because the addon could
literally just use the crypto code that you are proposing to remove,
without the DOM parts. However, now that Firefox is minimizing the amount
of NSS that is exposed from libnss3 and friends on non-Limux platforms, it
is probably the case that the addon will need to use platform-specific APIs
to access the operating system keystore, at least on non-Linux platforms.
However, I think that is a good idea anyway, because Firefox (and
Thunderbird) should be using the native OS for client certificates and
S/MIME certificates anyway.

As far as whether it is OK to remove functionality that some websites are
depending on: In this case, I think you can remove functionality that
Chrome currently doesn't support (using the same APIs or different APIs)
without hesitation. For example, I don't think Chrome can do the key escrow
thing so I don't see why Firefox needs to support it either. The advantages
of deleting the code outweigh the value that Firefox gains from supporting
those things.

We had a conversation about this a year ago on this mailing list and AFAICT
nobody has made any effort at W3C to standardize anything related to the
functionality for which you are proposing removal. I think that is a good
indication of how unimportant it is. So, +1 from me.

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

Re: Announcing Mozilla::PKIX, a New Certificate Verification Library

[Brian Smith]

On Mon, Apr 28, 2014 at 4:45 PM, Erwann Abalea  wrote:

> The chain builder can test all possible issuers until it finds a valid one
> (that's what OpenSSL does, for example). The AKI is only here to say
> "pssst, this is most probably the certificate you should try first".
>

Right. We need to measure whether our lack of support for AKI/SKI, which
causes us to do such a brute-force search, actually causes real-world
performance concerns. I am hoping that it doesn't matter so that we can
remove AKI/SKI from the WebPKI X.509 profile.

There's another missing check on the new PKIX lib, PrivateKeyUsagePeriod
> extension. It's been declared as deprecated in RFC2459 and 3280, isn't
> mentioned anymore in RFC5280, but it's still defined in X.509, and used on
> some places, such as CSCA (e-passports, where CA renewal with rekey also
> happen on a regular basis).
>

CSCA is out of scope for mozilla::pkix, at least at this time. More
generally, PrivateKeyUsagePeriodand other deprecated features, including
*all* of the proprietary Netscape/NSS extensions like "Netscape Cert Type,"
are also out of scope. Note that new features like the Must-Staple
extension *are* within scope and can/should/will be added.


>  I agree, it's not mandatory at all. And even if a bunch of certificates
> is sent along the EE cert, the RP is supposed to take them as potential
> candidates for its chain building algorithm. Potential candidates only.
>

Exactly. (In the code, the candidate issuer is called potentialIssuer.)

Thanks for looking so closely at the code. Please let me know if you have
any questions that would help with your investigation of it.

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

Re: Announcing Mozilla::PKIX, a New Certificate Verification Library

[Brian Smith]

On Mon, Apr 28, 2014 at 4:29 PM, Erwann Abalea  wrote:

> I know DER tools is only a decoder, and from
> https://mxr.mozilla.org/mozilla-central/source/security/pkix/lib/pkixocsp.cpp#921the
>  construction of the request makes heavy use of hex magic to build a
> request.
>

Right. OCSP requests are the only thing we *encode* in ASN.1 and so it
would be overkill to write a generic ASN.1 DER encoding library .


> Quick bug: on the same function, line 945, the test against
> issuerCert->serialNumber.len should be against cert->serialNumber.len
> instead..
>

Thanks for this bug report. David Keeler already filed a bug for this:
https://bugzilla.mozilla.org/show_bug.cgi?id=1002814

if you like money I suggest you read
https://blog.mozilla.org/security/2014/04/24/1-security-bug-bounty-for-certificate-verification/and
follow the directions.


> Logic at
> https://mxr.mozilla.org/mozilla-central/source/security/pkix/lib/pkixcheck.cpp#107doesn't
>  follow RFC5280 algorithm, and will probably fail with FBCA and
> other large cross-certification constructions such as CertiPath (I'm sure
> they use PolicyMappings, they may use PolicyConstraints, it has slipped off
> my memory). Current code is sufficient for webPKI, even EV. The normalized
> algorithms are clearly a torture to read (both X.509 and RFC5280, logic is
> slightly different but the result is identical), but it's necessary.
>

The mozilla::pkix code is NOT intended to be a complete implementation of
RFC 5280 and friends. Regarding certificate policy processing in
particular, the *entire* purpose of mozilla::pkix's certificate policy
support is the determination of whether to show the green site identity
block in a browser's address bar. We (I) specifically omitted any part of
certificate policy processing that is unnecessary for that purpose.

As I said in another thread, I'm hoping we will create a new,
much-simplified WebPKI profile of X.509 based on what we learn from
mozilla::pkix: no policy mapping, no policy constraints extension
(mozilla::pkix enforces requireExplicitPolicy=true and
inhibitPolicyMapping=true at all times anyway), no CRLs, etc.


> Same file, #229 (CheckBasicConstraints) doesn't take into account
> potential self-issued certificates in the chain (they don't account for a
> "level" in the pathLenConstraint).
>

Thanks. This is a known issue; see
https://bugzilla.mozilla.org/show_bug.cgi?id=926265. Interestingly, we've
not encountered any websites that are negatively affected by this bug yet.
Perhaps we will be able to remove the special cases for self-issued
certificates in the WebPKI profile.


> Same file, #370 (CheckExtendedKeyUsage), if encodedEKUs is NULL and a
> requiredEKU is asked for, it ends with a success. If encodedEKUs is present
> and contains the anyExtendedKeyUsage OID, it isn't recognized as valid. And
> I'm not sure it allows full support for technically constrained CAs (this
> is done with EKUs used as constraints, which is contrary to X.509/RFC5280,
> but it was pushed by Mozilla).
>

We do intend for mozilla::pkix to enforce the EKU extension in
intermediates in the way that we pushed for (and which we understand that
Microsoft's implementation also enforces).

We do not support anyExtendedKeyUsage and the NSS code we were using before
did not support it either. See
https://bugzilla.mozilla.org/show_bug.cgi?id=970750 (for mozilla::pkix) and
https://bugzilla.mozilla.org/show_bug.cgi?id=279845 (for NSS). Since NSS
has been working fine for at least one decade without support for
anyExtendedKeyUsage, we can almost definitely omit anyExtendedKeyUsage from
the WebPKI profile of X.509.

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

Re: Behavior changes - inhibitAnyPolicy extension

[Brian Smith]

[+dev-tech-crypto; Please discuss technical details of mozilla::pkix on
dev-tech-crypto and save dev-security-policy for discussion about Mozilla's
CA inclusion policies. There has been and will be a lot of technical
discussion on the behavior differences and rationale for those
differences--e.g. why policy mapping isn't supported and why policy
constraints are ignored--on the dev-tech-crypto mailing list. You can
subscribe at https://lists.mozilla.org/listinfo/dev-tech-crypto]

Responses inline.

On Mon, Apr 28, 2014 at 4:52 PM, Brown, Wendy (10421) <
wendy.br...@protiviti.com> wrote:

> Kathleen -
>
> In looking at this Draft CA Communications, I looked at the description of
> Behavior change and #5 doesn't look like the change is the right
> interpretation:
>
> 5. If the inhibitAnyPolicy extension is present in an intermediate
> certificate or trust anchor and children certificates have a certificate
> policy extension the verification will fail. bug 989051
>

I believe the above description of the behavior is wrong in a small but
important way. A better description would be "A certificate will not be
considered an EV certificate if mozilla::pkix cannot build a path to a
trusted root that does not contain any certificates with the
inhibitAnyPolicy extension. However, such certificates will still validate
as non-EV as long as there are no non-policy-related issues."

Please check out the bug: bug
https://bugzilla.mozilla.org/show_bug.cgi?id=989051. We know the current
behavior is wrong (at least, non-optimal). At the same time, it is a
low-priority issue because we only care about certificate policies for
determining whether or not to show the green site identity block for EV
certificates, and we suspect that no EV CAs in Mozilla's program use
inhibitAnyPolicy.

Some background: The original implementation of mozilla::pkix forced
inhibitAnyPolicy=true; i.e. we did not support anyPolicy at all. My hope
was that, when we define the WebPKI profile of X.509, that we would not
have anyPolicy in the profile. However, we found that some CAs in our CA
program depend on anyPolicy support for the EV certificates they issued, so
we had to add anyPolicy support after the fact, and we did it in the
simplest way possible because we were eager to work on higher-priority
issues. If somebody contributes better inhibitAnyPolicy support (with
tests) then that patch would be accepted. (Compare that to policy mapping,
where I probably wouldn't accept a patch even if one was contributed for
free.)

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

Re: OCSP stapling problems

[Brian Smith]

On Tue, Mar 11, 2014 at 3:20 AM, Hanno Böck  wrote:

> I wanted to bring up an issue regarding OCSP stapling.
> I filled this bug shortly after Firefox 27 came out:
> https://bugzilla.mozilla.org/show_bug.cgi?id=972304
>
> Short conclusion: If you have enabled OCSP stapling on your server this
> will break the possibility to add certificate exceptions with Firefox
> 27.
>
> I find it a bit worrying that this issue hasn't received any attention
> yet. To make this clear: This made me disable OCSP stapling on my
> production machines with customers. And it's a serious regression to
> the previous version 26.
>

First, it is important to point out to others reading this that this
problem only affects certificates that don't chain to a trusted root CA
and/or which are considered invalid by Firefox for some other reason.
AFAICT, there is no problem with OCSP stapling in Firefox for valid
(according to Firefox) certificates.

In Firefox 30 (or so), we will switch to a different way of verifying
certificates, including a different way of processing OCSP responses. In
the new way, we won't validate the OCSP response at all for a certificate
that we do not trust, whether it is stapled or not. I believe this will
resolve the issue you are experiencing.

Because we're overhauling all of the certificate verification processing,
and because this is an issue that only affects invalid certificates, and
because there is a workaround (disable OCSP stapling until Firefox 30 is
released), this isn't going to be a high priority. I understand that can be
frustrating but we'll never get the new certificate processing turned on if
we keep going back to fix these issues with the old certificate processing.

It would be great if you could test the new way of doing certificate/OCSP
verification. To do so, please download Firefox 30 Nightly from
http://nightly.mozilla.org/. After you install it, go to about:config and
add a new entry:

1. Right click in the list of preferences and choose New -> Boolean.
2. Enter the name security.use_insanity_verification
3. Change the value of the new pref to "true."

You may have to clear your cache and restart your browser for the change to
fully take effect.

If you try this, let me know if it resolves the issue for you.

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

Re: how to access and use NSS certificate functions From a Firefox extension code?

[Brian Smith]

On Thu, Feb 13, 2014 at 9:57 AM, WebDoctor  wrote:

>> > Should I write my own XPCOM object, or is there any other reasonable 
>> > solution for that?. And can any one collaborate with me create this 
>> > solution ?

> Thank you, i'll  try to test the verifyCertNow in my extension and see what 
> result i can get.

If the verifyCertNow function works for you, then please file a bug
about creating an asynchronous version of verifyCertNow. It is OK to
use verifyCertNow for prototyping, but it is bad to use verifyCertNow
in the final version of an extension. The reason is that verifyCertNow
is synchronous, and it will block everything that Firefox does while
it does the verification, and/or it will spin the event loop, which
creates its own set of problems. If you file a bug for creating the
async variant, I can either help you add it (this will be fastest, if
you know how to add XPCOM APIs already), or I can find somebody to do
it.

Note to David and Camilo: We should change the tests that use this
sync function to use the new async version, and remove the sync
version.

  /** Warning: This interface is inteded to use only for testing only as:
   *1. It can create IO on the main thread.
   *2. It is in constant change, so in/out can change at any release.
   */

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Where are others "SHA256 " cipher suits in Firefox 27?

[Brian Smith]

On Wed, Feb 5, 2014 at 9:54 PM, Rasj  wrote:
> Where are others? For example:
> TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d)

See https://briansmith.org/browser-ciphersuites-01.html. Also, please
look at the archives of this mailing list. There have been several
DOZEN of emails about the cipher suite selection on this mailing list.

in particular: "This proposal does not include the new HMAC-SHA256 or
HMAC-SHA384 ciphersuites that were added in TLS 1.2 since there is not
a clear need for them. Given our current understanding, HMAC-SHA-1,
HMAC-SHA-256, and HMAC-SHA-384 are all more-or-less equal in terms of
security given how they are used in TLS. (This is HMAC-SHA, not plain
SHA. Also, there is a huge difference in the ability to resist an
offline attack vs. the ability to resist an online attack.) Avoiding
these ciphersuites also allows us to sidestep the possibility of
performance regressions from enabling TLS 1.2."

> Many web-sites have only TLS_RSA_WITH_AES_256_CBC_SHA256 as kind of 
> strong(even without PFS) and weak RC4 and 3DES.

Please provide some examples of such sites.

Some of the information in my proposal is outdated. For example, it
seems like we don't have constraints on handshake size, since we've
discovered workarounds for those compatibility issues. So, we have
more flexibility to add these cipher suites than we previously did.

My main thought here is that these cipher suites aren't really
increasing security, but they are decreasing performance, when they
are used. We should advocate instead for cipher suites that increase
security and increase performance. That means, for example, cipher
suites that waste fewer bytes per record on nonces and padding. See
https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-04 for an
example of what I mean.

More generally, the CBC-HMAC mode of cipher suites is outdated and
should just be replaced. We have to support the older variants for
backward compatibility, but I don't see much reason, right now, to add
support for the new, less efficient, no-more-secure, variants.

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Sites which fail with tls > 1.0

[Brian Smith]

On Wed, Feb 5, 2014 at 5:39 PM,   wrote:
> Is the retry logic in nss or in mozilla-central?  And if the latter,
> can anyone help narrow the search?  I didn't find anything relevant
> in comm-central.

It is in mozilla-central, in
security/manager/ssl/src/nsNSSIOLayer.cpp. See these bugs:
https://bugzilla.mozilla.org/show_bug.cgi?id=839310
https://bugzilla.mozilla.org/show_bug.cgi?id=945195

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Sites which fail with tls > 1.0

[Brian Smith]

On Wed, Jan 29, 2014 at 2:57 PM,   wrote:
> I retried with a new ff profile and now it works, but only if I go
> directly to https://wayfarer.timewarnercable.com/; I cannot convince
> the new profile to let me in to the authenticated site for some reason
> I haven't diagnosed.  That is probably why I though it didn't re-try.
> Something else must have prevented the login.
>
> Clearly, though, sm isn't retrying.

Thanks for replying. I am not sure about how SM works but I would
expect it to work like Firefox in this aspect.

>> Also, could you try with Firefox 27 beta? Firefox 27 is supposed to be
>> released next week. The link to the beta version is here:
>> http://www.mozilla.org/en-US/firefox/beta/
>
> That would be more of a pain.

Understood. Next week Firefox 27 will be released and I think SM will
be released around the same time. I would appreciate hearing whether
or not you are having the same issues in Firefox 27 or SM 27.

> Since the retry problem seems limited to sm, It seems my post was a
> false alarm. :(  Sorry for that.

No problem. I appreciate you sharing the problem with us and keeping
us up to date with the status.

Thanks again,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Sites which fail with tls > 1.0

[Brian Smith]

On Mon, Jan 27, 2014 at 2:22 PM,   wrote:
> In case anyone is keeping a list, while helping a relative I determined
> that timewarnercable.com's login server (wayfarer.timewarnercable.com)
> will not work with tls 1.1 or 1.2.  The connection fails after the client
> right after the client hello.
>
> I had to set security.tls.version.max to 1 to get ff (26) or sm (2.23)
> to get her (relevant) profile to log in to their site.

Hi,

What is the value of security.tls.version.min? It should have the
default value of "0". If not, could you please try again with
security.tls.version.min=0 and security.tls.version.max=3?

Also, could you try with Firefox 27 beta? Firefox 27 is supposed to be
released next week. The link to the beta version is here:
http://www.mozilla.org/en-US/firefox/beta/

When I try with Firefox Nightly, I find that we do fail to negotiate
TLS 1.2 and then we try TLS 1.1 and fail at that. But then we retry
with TLS 1.0 and that succeeds. I am curious why that is not happening
for you with Firefox 26, since Firefox 26 should have the retry logic
in it already.

Thank you very much for your help with this!

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

Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox

[Brian Smith]

On Mon, Jan 27, 2014 at 10:49 AM,   wrote:
> On Monday, January 27, 2014 10:52:44 AM UTC-7, Brian Smith wrote:
>> On Mon, Jan 27, 2014 at 9:26 AM,   wrote:
>
> I can't speak for FF - and I've certainly read enough standards to say
> that there are too many standards.  I do think that the IETF does listen
> to NIST however. And if you care about security, the security of your
> implementation is a function of the cryptographic algorithms used.
> So I'd suggest that NIST is telling FF and everyone else where they
> should be to be secure. That being said, the reality of rolling forward
> to a new security level in the real world is much more of a random
> walk through the park. I appreciate your consideration of my comments.

NIST is one input into the IETF process, and NIST and IETF are both
inputs into our decision making. We also help IETF and NIST to update
their proposed standards. There is currently work going on at the IETF
to define best practices for TLS, including recommended cipher suites,
recommended TLS versions to support, and recommended features to
support. However, I suspect that those recommendations will written
such that they define the minimum set of functionality that a good
implementation should support. I suspect they won't fully define what
an application like Firefox has to do to be simultaneously secure and
backward-compatible. The good news, though, is that things are getting
better all around, AFAICT.

> If you understand what it is saying, NIST 800-131a is
> actually pretty clear on what it recommends and why;
> and it points to other standards that do some of the
> explaining. However, it would have been very helpful
> if they had actually bothered in an appendix to
> indicate all the cipher suites that are OK (for TLS
> and IPSEC).

You should look at the SP800-52 draft, which more clearly specifies
how NIST recommends that TLS applications work.
http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-52-Rev.%201.

> I would like to hear more about what you are recommending
> NIST do to align with default configurations (perhaps
> something for a separate email).

I will send my feedback regarding the NIST SP800-52 draft to this
mailing list in a separate thread.

> It would be good if the IETF wrote some standards
> to obsolete stuff that is not used and tell folks to get
> off stuff that is known to be not secure. Perhaps it is
> a work in progress - it's hard to keep up. Even better
> if they had more implementation guidelines for
> implementors.

IETF is currently working on BCP documents to define best practices
for the use of TLS in applications, including web browsers and web
servers. I recommend that you subscribe to the IETF UTA and TLS
working group mailing lists:

https://tools.ietf.org/wg/uta/
https://www.ietf.org/mailman/listinfo/uta
https://tools.ietf.org/wg/tls/
https://www.ietf.org/mailman/listinfo/tls

Also, the HTTP working group at IETF has added some improved minimum
requirements for the use of TLS by HTTP/2 clients and servers, based
on feedback from Mozilla, Google, and others. See
http://http2.github.io/http2-spec/index.html#TLSUsage

> A control to stop accepting SHA-1 signatures would be
> desirable. I would say for the forseeable future, it would
> have to default to off - I'll give you odds that >90% of
> the certificates still have SHA-1.

Agreed. You may be interested in
https://bugzilla.mozilla.org/show_bug.cgi?id=942515 which is about a
way for transitioning away from SHA-1 without breaking backward
compatibility.

> So perhaps I'll try to make an offer here. I really like FF's ideology. I'd 
> like to try to put together a set of 'guidelines' for configuring it to be 
> NIST 800-131a compliant -  e.g. describe what configuration controls are 
> necessary. I think you've told me most of that above - though I think there 
> were a few other things in the list to check out. I'll take that offline from 
> this chat. It's something I could use in my environment. It might be 
> something that would be useful to others as a reference.

It would be great if you could write this up. Please start a new
thread with your initial submission. I think one issue you may run
into is that Firefox's current version of NSS isn't FIPS-140
validated. You may find the following useful:
http://kb.mozillazine.org/Security.tls.version.*
https://developer.mozilla.org/en/docs/NSS/FIPS_Mode_-_an_explanation

Note that the "FIPS Mode - an explanation" and the support.mozilla.org
article it links to are somewhat outdated.

Also, I recommend that you write your document for Firefox 27 and
later, because Firefox 27 makes substantial changes to the default TLS
configuration of Firefox, including enabling TLS 1.2 and AES-GCM by
default.

Thanks!

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox

[Brian Smith]

On Mon, Jan 27, 2014 at 9:26 AM,   wrote:
> On Monday, January 27, 2014 6:19:42 AM UTC-7, Kurt Roeckx wrote:
>   2) NIST is a US government standards board that drives a lot of compliance
>  regulation. There are companies what will want to be able show that they
>  are NIST compliant. The standard at this point does NOT allow you to
>  use Camellia. So there should be some way to configure the browser so 
> that
>  it uses only FIPS approved algorithms (i.e. NOT CAMELLIA). Otherwise 
> you're
>  probably going to be getting the same sort of feedback about "I can't use
>  Firefox because it cannot be made NIST 800-131a compliant" that you got
>  about "I can't use Firefox because it does not support TLS 1.2".

Camellia may get disabled by default soon. But, RC4 won't get disabled
by default soon; we may do what MSIE11 does, but that's not quite the
same thing. You can configure Firefox to disable RC4 and Camellia
cipher suites using about:config. Search for "rc4" and "camellia" to
find those prefs.

>5) I'm trying to tell you what the standard says - not whether I agree with
>   it. I don't get to pick. The standard does not allow Camellia (because
>   it is too new). But the standard does support and justify taking away
>   the set of suites that Marlen suggested. I was just giving a more
>   explicit rational for dropping them.

No NIST standard is "the standard" for Firefox.

I have sent feedback to NIST about its draft recommendations for TLS,
trying to convince them that they should change their guidance to be
in line with what web browsers do in their default configurations.
However, NIST doesn't dictate what we do. In particular, we won't
constrain ourselves to doing only things that NIST 800-131a recommends
in the default configuration. However, assuming it isn't too much
work, we'll support options that allow you to configure Firefox to
conform with NIST guidance.

>   The client is not obligated to enforce NIST 800-131a. But I
>   would suggest two things:
> 1) There should be a visible indication whenever a web site ends up with a
>connections that has less than 112 bit security. Perhaps even ask the
>user if he really wants to connect to a site with 'weak' security. This
>might motivate some of these sites to fix their security.
> 2) There should be a configuration control to block connection to a weak
>sites period.
> Weak = See description at end of post.

This seems like a reasonable suggestion.

>>  >= 112 bit, but their collision resistance isn't that good.  That means>
>> in an HMAC they can perfectly be used.
>>
> MD5 is not a FIPS approved algorithm. It has known issues with collision
> resistance. The NIST 800-131a standard says do not use it - not even in an 
> HMAC. Kind of agree that it should be relatively OK in an HMAC, but any known 
> flaw is a potential attack vector.

There are real compatibility issues with turning off the
HMAC-MD5-based cipher suite. However, you can turn it off in
about:config; search for "md5"

> SHA-1 is 160 bits which as a hash gives it 80 bit security strength. In an
> HMAC, it has 160 bit security which is fine. The item above is about
> digital signatures - not MACs - the point is - all those RSA-/SHA-1
> signatures on Certificates out there are NOT good. Also using SHA-1 in the
> TLS signing protocol is not good - and that's what you get even with TLS 1.2
> if you don't send a Hash and Signature Algorithm extension that prohibits 
> SHA-1.

It is a good point that we need to change what we do in the TLS
handshake when we stop accepting SHA-1 signatures.

It may be reasonable to implement a "don't accept SHA-1 signatures"
preference similar to the one we just removed for MD5.

> I might be wrong, but I thought as long as the client and the server do not 
> BOTH use a static key, then you still have forward perfect secrecy. And I 
> thought the definition in TLS provided for the certificate owner to have a 
> static DH key and for the authenticator to use an ephemeral key when DH or 
> ECDH was used. If this is correct, I'd guess the static key on the server 
> side might save some time. Anyway I'm on shaky ground here perhaps - in my 
> mind, I like it when there are fewer options and clearer choices about what 
> to use. I do notice that the Suite B cipher suites only use ECDHE so that 
> might be some indication that DH or ECDH are not a strategic path. Again - 
> the only point is the standard allows them if there is any reason to support 
> them.

I do think that ephemeral-static key exchange is something that we
could consider. I even mentioned it in my original proposal:
https://briansmith.org/browser-ciphersuites-01.html. However, there
are basically zero servers that support it.

> And BTW - I haven't heard the answer about the Client hello extension for 
> Hash and Signature Algorithm. Does FF send this? Do we know what % of sites 
> tolerate it?

Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox

[Brian Smith]

On Sun, Dec 15, 2013 at 8:46 AM, Kurt Roeckx  wrote:

> But some people are also considering disabling it by default,
> as I think all other where talking in this thread, not just
> reduce the preference.
>
> > For the same reason, the server ciphersuite that we recommend at
> > https://wiki.mozilla.org/Security/Server_Side_TLS
> > does not drop Camellia, but lists it at the bottom of the ciphersuite.
> > It's a safe choice, but not one that we recommend.
>
> As far as I know the reasons for not recommending it are:
> - It's slower
> - It probably doesn't have much constant-time implementations.
>
> So as I understand it, the reason for not recommending it don't
> have anything to do with the security of Camellia itself.
>

Because of unfortunate design choices, Camellia is (along with AES)
difficult to implement in constant time with high performance. That *is* a
serious fault in the algorithm. AES-NI is a workaround for AES, but no such
workaround exists for Camellia. In addition, Firefox supporting Camellia
while other browsers don't is bad for interoperability. Finally, other
browsers have demonstrated that Camellia isn't needed for web
compatibility, so removing support for Camellia means we can avoid
maintaining Camellia.

Like I've said before, for any cipher that we support TLS_RSA_* for, we
should be supporting some TLS_ECDHE_* variants, so that we don't make
servers choose between the cipher they need/want to use and ephemeral key
exchange. So, to keep Camellia support, we'd need to implement and enable
the TLS_ECDHE_* variants. But, it doesn't seem worth the effort when it
doesn't seem to improve interoperability, performance, or security.

I think instead we are better off spending resources on making AES-GCM
constant-time(-ish) and on adding support for ChaCha20+Poly1304. Google
already has constant-time (I think) ChaCha20+Poly1304 patches for NSS and
there's also been progress on constant-time(-ish) GHASH implementations for
NSS. Note that ChaCha20+Poly1304, by design, is straightforward to
implement in a high-speed, constant-time fashion.

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Longterm crypto support

[Brian Smith]

Kurt,

Thanks for your suggestions.

On Sat, Dec 14, 2013 at 12:46 PM, Kurt Roeckx  wrote:

> I think we need to come up with a plan to improve security in the
> long run.  I think what we would like to see in general is:
> - Only SHA256 or better (and so TLS 1.2)
>

This is gated almost purely on servers actually switching to SHA-2 certs
and TLS 1.2. See https://bugzilla.mozilla.org/show_bug.cgi?id=942515, which
is related to this. I think it makes sense to revisit this after we figure
out exactly what we're doing with SHA-1-based certificates, because it
doesn't make sense to plan to go "SHA-2 only" until that happens. So, we're
talking about something after 2017. We (the Mozilla community) could help
coordinate a push for servers to upgrade, but there's not much actionable
we can do now, AFAICT, except for advocate for improvements by servers and
fixing any bugs that impair that switchover.

- Only 2048 bit public, 128 bit symmetric, 256 bit elliptic, or
>   better.
>

Approximately 1.5% of Fx26 full handshakes that use RSA certs use keys
smaller than 2048 bits. So, enforcing the 2048 bit limit is not going to be
a simple thing to do for a while, even though we want to do it soon. We can
enforce the 256 bit limit on ECC now though, because literally everybody
seems to be using the P-256 curve. (This actually makes me wonder if the
P-384 support even works, since not a single handshake in Firefox 26 used
it.)

I think that it is a good idea for us to advocate for server admins and
server software makers to do the things you suggest, but it is unlikely
that browsers will be able to force the issue on all those things by
limiting what they accept. Note that the server-side people at Mozilla have
put together some recommendations that could benefit from some review:
https://wiki.mozilla.org/Security/Server_Side_TLS.

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox

[Brian Smith]

On Sat, Dec 14, 2013 at 4:47 PM, Kosuke Kaizuka  wrote:

> > little supported, never negotiated cipher
>
> One of the largest websites which support Camellia is Yahoo!.
> Firefox 26 or lower use TLS_RSA_WITH_CAMELLIA_256_CBC_SHA with Yahoo!.
>

In Firefox 27 or later, Yahoo! will choose TLS_RSA_WITH_AES_128_CBC_SHA
instead, because of the cipher suite order change in Firefox 27.

In case people are curious how the cipher suite order has changed servers'
selection of cipher suites between Firefox 26 beta and Firefox 27 beta,
here is a table:

 Fx26Fx27   Change   Cipher Suite
 0.00%  14.15%  +14.15%  TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (new)
 0.00%   8.30%   +8.30%  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (new)
 0.74%   0.27%   -0.47%  TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
 0.00%   0.00%   -   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
 1.97%   0.49%   -1.48%  TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
 0.00%   0.00%   -   TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
 0.00%   0.00%   -   TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
10.22%   0.48%   -9.74%  TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
 6.75%   0.11%   -6.64%  TLS_ECDHE_RSA_WITH_RC4_128_SHA
 0.89%   5.64%   +4.75%  TLS_DHE_RSA_WITH_AES_128_CBC_SHA
 0.00%   0.00%   -   TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
 2.66%   0.58%   -2.08%  TLS_DHE_RSA_WITH_AES_256_CBC_SHA
 2.38%   0.03%   -2.35%  TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
 0.00%   0.01%   +0.01%  TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
 0.00%   0.00%   -   TLS_DHE_DSS_WITH_AES_128_CBC_SHA
 0.00%   0.00%   -   TLS_DHE_DSS_WITH_AES_256_CBC_SHA
 3.77%  26.26%  +22.50%  TLS_RSA_WITH_AES_128_CBC_SHA
 0.00%   0.00%   -   TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
21.40%   0.90%  -20.50%  TLS_RSA_WITH_AES_256_CBC_SHA
 3.18%   0.00%   -3.18%  TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
 0.00%   0.00%   -   TLS_RSA_FIPS_WITH_3DES_EDE_CBC_SHA (removed)
 0.04%   0.18%   +0.13%  TLS_RSA_WITH_3DES_EDE_CBC_SHA
 0.00%   0.00%   -   TLS_RSA_WITH_SEED_CBC_SHA (removed)
41.17%  37.57%   -3.60%  TLS_RSA_WITH_RC4_128_SHA
 4.83%   5.03%   +0.21%  TLS_RSA_WITH_RC4_128_MD5

Interestingly:

* AES-128 has largely replaced AES-256 because AES-128 was moved ahead of
AES-256.
* AES-GCM has largely replaced RC4 amongst sites doing ECDHE key exchange.
* Camellia usage dropped from >5% to close to 0% because AES cipher suites
were moved ahead of their corresponding Camellia cipher suites.
* Virtually no site was using SEED.
* There was a ~4% increase in ephemeral key exchange usage, almost all of
which was due to increased adoption of ECDHE.

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox

[Brian Smith]

On Sat, Dec 14, 2013 at 3:51 PM, Kurt Roeckx  wrote:

> On Sat, Dec 14, 2013 at 03:36:44PM -0800, Brian Smith wrote:
> >
> > Note that the cipher suites above were not agreed to in the previous
> > discussion and were not part of my proposal linked to above. They have
> been
> > enabled for a long time, and I did not disable them in Firefox 27
> because I
> > wanted to be conservative in avoiding potential compatibility issues, and
> > because I wanted to see the measurements of the effects of the reordering
> > of the cipher suites. For reference, the cipher suite list for Firefox 26
> > appears at the end of this email.
>
> I assume that 27 when it's released will get the list from your
> other mail, and so for intsance removes all the ECDH ciphers?
>

The current list for Firefox 27 beta is:

C02B  TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
C02F  TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
C009  TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
C013  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
C00A  TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
C014  TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
C012  TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
C007  TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
C011  TLS_ECDHE_RSA_WITH_RC4_128_SHA
0033  TLS_DHE_RSA_WITH_AES_128_CBC_SHA
0032  TLS_DHE_DSS_WITH_AES_128_CBC_SHA
0045  TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
0039  TLS_DHE_RSA_WITH_AES_256_CBC_SHA
0038  TLS_DHE_DSS_WITH_AES_256_CBC_SHA
0088  TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
0016  TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
002F  TLS_RSA_WITH_AES_128_CBC_SHA
0041  TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
0035  TLS_RSA_WITH_AES_256_CBC_SHA
0084  TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
000A  TLS_RSA_WITH_3DES_EDE_CBC_SHA
0005  TLS_RSA_WITH_RC4_128_SHA
0004  TLS_RSA_WITH_RC4_128_MD5

Next week, the following changes will be made:

1. TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA will be disabled
2. TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA will be moved to the third spot,
ahead of TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, due to
https://bugzilla.mozilla.org/show_bug.cgi?id=946147.

There may be more changes during Firefox 27 beta if we find more
compatibility issues. It is also possible that TLS 1.2 and/or AES-GCM
cipher suites could still get disabled before 27 is released, though we're
trying to make sure that doesn't happen.

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

Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox

[Brian Smith]

On Sat, Dec 14, 2013 at 2:13 PM, falcon  wrote:

> I believe startssl (even) will sign ecdsa certs if you send a csr for one,
> but this is of little utility without an ecdsa trust anchor.
>
>  Original message 
> From: cl...@jhcloos.com
>
> Brian Smith  writes:
> > Cipher Suite  Count   %
> > --
> > TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 332,786   8.30%
> > TLS_ECDHE_ECDSA_WITH_RC4_128_SHA  4,601   0.11%
>
> Who issues ECDSA certs?
>
> Is that intra-government usage?
>

Several CAs in Mozilla's CA program are now offering ECDSA certificates.

Some older versions of TLS had a requirement that all certificates in the
cert chain must be signed using the same type of key. However, NSS has
never enforced that and AFAICT most other implementations haven't either.
However, some CAs won't sign ECDSA certificates with their RSA certificates
for reasons that are better described by them than me.

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox

[Brian Smith]

On Fri, Dec 13, 2013 at 10:48 PM,  wrote:

> I present a proposal to remove some vulnerable/deprecated/legacy TLS
> ciphersuits from Firefox. I am not proposing addition of any new
> ciphersuits, changing of priority order, protocol removal, or any other
> changes in functionality.
>
> I have read these proposed IETF drafts and am using them as guidance along
> with my experience:
> https://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-01
> https://tools.ietf.org/html/draft-sheffer-tls-bcp-01
>

Besides those, you may find these interesting:
* My initial proposal (now out of date; I will clean it up):
  https://briansmith.org/browser-ciphersuites-01.html
* Our previous recent discussion on this mailing list:

https://groups.google.com/forum/#!topic/mozilla.dev.tech.crypto/gFfKw3EOffo
and
https://groups.google.com/forum/#!topic/mozilla.dev.tech.crypto/IhrOqMZe8Go
and
https://groups.google.com/forum/#!topic/mozilla.dev.tech.crypto/36na1B2brGU
and maybe more.


> These are the default available ciphersuits in Firefox Aurora 28.0a2 on a
> Windows system:
>




> C012 TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
> 0045  TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
> 0088  TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
> 0016  TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
> 0041  TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
> 0084  TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
>

Note that the cipher suites above were not agreed to in the previous
discussion and were not part of my proposal linked to above. They have been
enabled for a long time, and I did not disable them in Firefox 27 because I
wanted to be conservative in avoiding potential compatibility issues, and
because I wanted to see the measurements of the effects of the reordering
of the cipher suites. For reference, the cipher suite list for Firefox 26
appears at the end of this email.


> Apache/nginx (and possibly many other) configurations that establish
> Perfect Forward Secrecy (PFS) ciphersuits will always have available a PFS
> ciphersuit that contains AES. This means that the following ciphersuits can
> be safely removed, also given their non-usage in real client-server
> connections:
> C012  TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
>

I agree. The data shows that this cipher suite is never selected by servers
and it will be removed.


> C007  TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
> C011  TLS_ECDHE_RSA_WITH_RC4_128_SHA
>

These cipher suites were included in my original proposal that we agreed
to. IMO, it does not make sense to remove these cipher suites unless we
also remove the TLS_RSA_WITH_RC4_128_* variants. Ephemeral key exchange +
RC4 is much better than RSA key exchange + RC4 (or even RSA key exchange +
AES) because it limits the damage of a compromised private key. The data
also shows that these cipher suites are still in use. I suspect that as
AES-GCM becomes more common, the use of these cipher suites will decrease
further and we can reconsider removing them. (More on RC4 below.)


> 0016  TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
>

This cipher suite wasn't in my original proposal, however I think it makes
sense to retain it because it is used surprisingly often. Also, usually DHE
key exchange is better than RSA key exchange, unless the DHE key is very
small. Consequently, I won't remove this one yet, unless/until we come up
with a plan for small DHE keys.


> DSS is obsolete and is not used for real client-server connections, hence
> the following ciphersuits can be removed:
> 0032  TLS_DHE_DSS_WITH_AES_128_CBC_SHA
> 0038  TLS_DHE_DSS_WITH_AES_256_CBC_SHA
>

The data we have shows that these are almost never used, and when they are
used, they are always used with keys less than 2048 bits, which is supposed
to be the minimum key size we support, according to our CA policy. So, we
can try to remove these too.

Camellia ciphersuits are little supported, never negotiated cipher, and not
> as well-tested & reviewed as AES ciphersuits. The following ciphersuits can
> be removed:
> 0045  TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
> 0088  TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
> 0041  TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
> 0084  TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
>

I agree that we can remove the Camellia cipher suites now. With the new
cipher suite ordering, Camellia-256 usage dropped from ~5.55% in Firefox 26
beta to 0.03% in Firefox 27 beta. Also, Camellia-128 usage stayed at about
0% usage. If we have a problem with AES that causes Camellia to become more
important in the future, we can easily re-enable it by default with a
Firefox update.


> The last remaining 3DES ciphersuit should be removed for performance
> considerations and its legacy status:
> 000A  TLS_RSA_WITH_3DES_EDE_CBC_SHA
>

As Kurt noted, there are a lot of servers that support only 3DES and RC4.
If we remove the TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA and
TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher suites, we will increase the usage of
RC4. unless we disable RC4 at the same time. Also, I would bet that there
are now servers that can ONLY do 3DES, i

Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox

[Brian Smith]

On Fri, Dec 13, 2013 at 11:51 PM, Brian Smith  wrote:

> I will comment on your proposal again later. However, I want to share with
> you some usage data from Firefox 28 Beta, that I think we will find helpful
> in understanding what servers do. These numbers represent the cipher suite
> chosen by the server for 4,011,451 real-life full handshakes in Firefox 28
> beta.
>

Above, I meant Firefox 27 beta.

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

Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox

[Brian Smith]

On Fri, Dec 13, 2013 at 10:48 PM,  wrote:

> I present a proposal to remove some vulnerable/deprecated/legacy TLS
> ciphersuits from Firefox. I am not proposing addition of any new
> ciphersuits, changing of priority order, protocol removal, or any other
> changes in functionality.


Hi,

Thank you for suggesting these changes, and thank you for posting your
message on the public mailing list. (I also appreciate the private email
you sent me on the subject.)

I will comment on your proposal again later. However, I want to share with
you some usage data from Firefox 28 Beta, that I think we will find helpful
in understanding what servers do. These numbers represent the cipher suite
chosen by the server for 4,011,451 real-life full handshakes in Firefox 28
beta.

First, here are the figures, sorted according to the order we offer the
cipher suite in the ClientHello:

Cipher Suite  Count   %
--
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256   567,486  14.15%
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 332,786   8.30%
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA   10,952   0.27%
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA  0   0.00%
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA   19,472   0.49%
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA  0   0.00%
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA   0   0.00%
TLS_ECDHE_RSA_WITH_RC4_128_SHA   19,117   0.48%
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA  4,601   0.11%
TLS_DHE_RSA_WITH_AES_128_CBC_SHA226,177   5.64%
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA44   0.00%
TLS_DHE_RSA_WITH_AES_256_CBC_SHA 23,319   0.58%
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA 1,088   0.03%
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA   557   0.01%
TLS_DHE_DSS_WITH_AES_128_CBC_SHA  9   0.00%
TLS_DHE_DSS_WITH_AES_256_CBC_SHA  0   0.00%
TLS_RSA_WITH_AES_128_CBC_SHA  1,053,521  26.26%
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA18   0.00%
TLS_RSA_WITH_AES_256_CBC_SHA 36,203   0.90%
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA 0   0.00%
TLS_RSA_WITH_3DES_EDE_CBC_SHA 7,065   0.18%
TLS_RSA_WITH_RC4_128_SHA  1,507,191  37.57%
TLS_RSA_WITH_RC4_128_MD5201,845   5.03%

Below are the same figures, sorted by frequency (most popular first). The
final column is an indication, of the cipher suites you suggest to remove,
whether I think this data offers strong evidence for the removal; "Remove-"
means "the data seems to contradict your recommendation," "Remove?" means
more study is needed, and "Remove+" means that the data supports your
conclusion.

Cipher Suite Count   %
--
TLS_RSA_WITH_RC4_128_SHA 1,507,191  37.57% Remove-
TLS_RSA_WITH_AES_128_CBC_SHA 1,053,521  26.26% Remove-
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256  567,486  14.15%
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256332,786   8.30%
TLS_DHE_RSA_WITH_AES_128_CBC_SHA   226,177   5.64%
TLS_RSA_WITH_RC4_128_MD5   201,845   5.03%
TLS_RSA_WITH_AES_256_CBC_SHA36,203   0.90%
TLS_DHE_RSA_WITH_AES_256_CBC_SHA23,319   0.58%
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA  19,472   0.49%
TLS_ECDHE_RSA_WITH_RC4_128_SHA  19,117   0.48% Remove?
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA  10,952   0.27%
TLS_RSA_WITH_3DES_EDE_CBC_SHA7,065   0.18% Remove-
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA 4,601   0.11% Remove?
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA1,088   0.03% Remove?
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA  557   0.01% Remove?
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA   44   0.00% Remove?
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA   18   0.00% Remove?
TLS_DHE_DSS_WITH_AES_128_CBC_SHA 9   0.00% Remove?
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA 0   0.00%
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA 0   0.00%
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA  0   0.00% Remove+
TLS_DHE_DSS_WITH_AES_256_CBC_SHA 0   0.00% Remove+
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA0   0.00% Remove+

Your idea of offering a subset of cipher suites during the initial
handshake, and then falling back to another handshake later, requires more
discussion and more measurements to be done. I would like to do something
similar to what you suggest.

Note that my Remove+/?/- comments should not be taken as an acceptance or
rejection of your suggestions. I just want you to know my initial
impression, based on a quick look of the data.

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

David Keeler is now a PSM peer

[Brian Smith]

Hi all,

Please join me in welcoming David Keeler as a PSM peer! Amongst many
other things, David implemented the HSTS preload list, integrated OCSP
stapling into Firefox, and is current implementing the OCSP
Must-Staple feature, which is a key part of our goal of making
certificate status checking faster and more effective. I've been very
impressed by his work and I know many others have been similarly
impressed.

I also shortened up the list of PSM peers so that it only includes
people who are still actively reviewing patches in PSM. I want to
thank Kai Engert and Bob Relyea for the huge contributions that
they've made in PSM. I still recommend that you ask them, or other NSS
peers, for advice whenever you need help with anything to do with NSS
or PKI. Their knowledge of the how & why in those areas is invaluable.

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers

[Brian Smith]

On Tue, Nov 19, 2013 at 9:14 AM, Kurt Roeckx  wrote:
> On Mon, Nov 18, 2013 at 06:47:08PM -0800, Wan-Teh Chang wrote:
>> On Mon, Nov 18, 2013 at 4:57 PM, Brian Smith  wrote:
>> >
>> > Also, AES implementations are highly optimized, well-audited,
>> > well-tested, and are more likely to be side-channel free. Camellia
>> > doesn't get used very often. Yet, some websites (most famously,
>> > Yahoo!), prefer Camellia over AES, even when we offer AES at higher
>> > priority in the handshake.
>>
>> There must be a misunderstanding. NSS offers Camellia at higher
>> priority than AES in the ClientHello.

I think you might be right. I remember testing the new cipher suite
order and I was still seeing Camellia being used on
https://login.yahoo.com. But, I tried it again now and it is using AES
with the new cipher suite order. It is very possible that my original
testing of this was off; perhaps due to the HTTP cache or user error.

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers

[Brian Smith]

On Sun, Nov 10, 2013 at 4:39 AM, Kurt Roeckx  wrote:
> On Sat, Nov 09, 2013 at 02:57:48PM -0800, Brian Smith wrote:
>> Last week, I also learned that ENISA, a European standards group,
>> recommends Camellia alongside AES as a future-proof symmetric cipher
>> algorithm; see [4].
>
> They recommend:
> - *_AES_*_GCM_*
> - *_CAMELLIA_*_GCM_*
> - *_AES_*_CCM_*

Thanks. I filed bug 940119 about adding the TLS_ECDHE_*_CAMELLIA_GCM_*
cipher suites.

> As I already mentioned a few time, I'm still missing some of
> the *_AES_*_GCM_* ciphers, specially the DHE ones.

It should be easy to add TLS_DHE_*_GCM_* cipher suites to NSS.

However, I am not sure it is a good idea to add TLS_DHE_*_GCM_* or
TLS_RSA_*_GCM_* cipher suites to Firefox (or other browsers, for that
matter).

Regarding the TLS_DHE_* variants, I think that we should spend some
effort on advocating support for the TLS_ECDHE variants first. In
particular, you mentioned that Apache 2.2 doesn't support ECDHE. Well,
I'd rather work on backporting Apache 2.4's ECDHE support to Apache
2.2 than add the TLS_[DHE_]RSA_*_GCM_* cipher suites to Firefox.
Unfortunately, DHE cipher suites don't work well in current Apache 2.2
either, because of the hard-coded 1024-bit parameters. I don't think
it would be reasonable to backport the better DHE support from Apache
trunk to Apache 2.4 since there are compatibility issues with doing
so. Also, ultimately, we'd like to use TLS_ECDHE_* cipher suites for
performance reasons.

Regarding the TLS_RSA_* variants, like I said before, I think we
should avoid adding new cipher suites for RSA key exchange to Firefox,
to encourage websites to use the ECDHE variants, which help toward
minimizing the fallout of a private key compromise. I am currently
expecting that the One-RTT variant of the TLS 1.3 handshake will
require ECDHE support anyway.

Regardless, I think we can avoid adding those things for now, and
revisit this later when we see what happens with TLS 1.3 and when we
see how successful (or not) our advocacy attempts are.

>> I think we probably want to still disable Camellia
>> cipher suites by default in the long term anyway, but I did not
>> disable them in Firefox Nightly yet. In order for it to make sense to
>> continue offering Camellia cipher suites long term, we would need to
>> improve NSS's support for Camellia to add the ECDHE variants of the
>> Camellia cipher suites. Currently, I think the best course of action
>> is to let the current configuration ship, then disable Camellia
>> support, and eventually add ECDHE_*_WITH_CAMELLIA_* support to NSS, so
>> that it is ready in case some problem with AES is found.
>
> I don't understand the part where you want to disable it.

Originally I was very concerned about the TLS ClientHello message
size, because we were under the impression that we had to keep it
under 256 bytes. That is the reason I prioritized starting this
discussion so highly, in fact. But, at IETF88, we learned that there
may be another workaround to the interop problems such that we don't
have to keep our ClientHello message size under 256 bytes. Still, we
shouldn't be wasteful with our ClientHello message size, since we'll
always want to keep it under ~1400 bytes for performance and
reliability reasons. 1400 bytes might sound like a lot now, but people
have already been talking about TLS extensions that could easily eat
up the majority of that space.

Also, AES implementations are highly optimized, well-audited,
well-tested, and are more likely to be side-channel free. Camellia
doesn't get used very often. Yet, some websites (most famously,
Yahoo!), prefer Camellia over AES, even when we offer AES at higher
priority in the handshake. I am not sure how much the performance or
existence of lack of side-channel-free implementations of Camellia
matter yet. In Firefox, we've kept Camellia enabled for now, and added
some telemetry to measure how often each cipher is used, to inform our
future decision making here.

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers

[Brian Smith]

On Fri, Nov 1, 2013 at 2:22 AM, Kurt Roeckx  wrote:
> On Mon, Oct 07, 2013 at 09:06:54PM +0200, Kurt Roeckx wrote:
>> On Fri, Aug 30, 2013 at 01:10:08AM +0200, Kurt Roeckx wrote:
>> > So what needs to happen so that we can move on with this?
>>
>> I still have the same question.  Nothing seems to be happening.
>
> So it's been 2 months since the last discussion about this.  Can
> we please move on?

Last week, we enabled TLS 1.2 in Firefox Nightly. Monday's Firefox
Nightly will enable AES-128-GCM and disable the SEED, ECDH, and
DSS_CAMELLIA cipher suites. Firefox Nightly will offer:

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_RC4_128_SHA
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_RC4_128_MD5
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA

Basically, this is what I proposed in my proposal, with some Camellia
and 3DES cipher suites also mixed in, without AES-256-GCM (since NSS
doesn't support it yet), and in a different order. I filed bug 936828
[0]


During IETF88, we learned that the client hello-size-related
interoperability problems may have a very simple workaround; see [1]
and [2]. It is unclear if the workaround provided by F5 will fix all
the size-related ClientHello issues. There appears to be another
problem with Windows Server 2003 [3], but that problem seems unlikely
to affect NSS (at least Firefox) due to the relatively small number of
cipher suites we enable by default.

Last week, I also learned that ENISA, a European standards group,
recommends Camellia alongside AES as a future-proof symmetric cipher
algorithm; see [4]. I think we probably want to still disable Camellia
cipher suites by default in the long term anyway, but I did not
disable them in Firefox Nightly yet. In order for it to make sense to
continue offering Camellia cipher suites long term, we would need to
improve NSS's support for Camellia to add the ECDHE variants of the
Camellia cipher suites. Currently, I think the best course of action
is to let the current configuration ship, then disable Camellia
support, and eventually add ECDHE_*_WITH_CAMELLIA_* support to NSS, so
that it is ready in case some problem with AES is found.

In the IETF88 TLS WG meeting, EKR asked me to write up my proposal as
an internet-draft, so the next revision of the document will be in
that format. I will post it when it is ready.

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=936828
[1] http://www.ietf.org/mail-archive/web/tls/current/msg10423.html
[2] http://www.ietf.org/mail-archive/web/tls/current/msg10445.html
[3] http://www.ietf.org/mail-archive/web/tls/current/msg10471.html
[4] 
https://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Tagged NSS_3_15_4_BETA2 and pushed to mozilla-central

[Brian Smith]

Kai just tagged NSS_3_15_4_BETA1 yesterday but mozilla-central
urgently needs the fix for bug 934378 which is fixed by the patch for
NSS bug 935847, so I created the BETA2 tag which contains that fix.

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: oddball, old cipher suite in firefox client hello

[Brian Smith]

On Fri, Nov 1, 2013 at 1:28 AM, Jeff Hodges  wrote:
>   /* New non-experimental openly spec'ed versions of those cipher suites. */
>   #define SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA 0xfeff
>   #define SSL_RSA_FIPS_WITH_DES_CBC_SHA   0xfefe
>
> Does anyone know what spec this cipher suite came from? And, perhaps, why
> it's still a good idea to be in the client hello? This last question I ask
> very gently and out of curiosity.

See 
http://www-archive.mozilla.org/projects/security/pki/nss/ssl/fips-ssl-ciphersuites.html

Based on reading that, these cipher suites seem to be be a way to
backport the TLS 1.0 PRF to SSL 3.0 after NIST decided that the SSL
3.0 PRF was unacceptable, back when TLS 1.0 was still new and shiny. I
agree it makes sense to remove it from Firefox's ClientHello and we
already have plans for that. See
https://briansmith.org/browser-ciphersuites-01.html.

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers

[Brian Smith]

On Mon, Oct 7, 2013 at 6:05 PM, Mountie Lee  wrote:
> SHA2 hash required in e-commerce transaction by the korean regulation.
> and which is also used in TLSv1.1+.

Hi,

First, we will be enabling TLS 1.2 in Firefox very soon.

But, I think you may be referring to SHA-2-based cipher suites
proposed in this internet draft:
http://tools.ietf.org/html/draft-bjhan-tls-seed-00

Unfortunately, that internet draft expired and also the draft didn't
even specify the cipher suite code points.

Where can I find the current version of the Korean regulations on
encryption. I have read this article:
http://www.koreatimes.co.kr/www/news/biz/2012/04/123_109059.html

That article notes that SEED is actually not mandatory in Korea any
more. If so, it seems like a good idea to help the Korean community
standardize on more common algorithms, right?

That article also notes that implementations other than the ActiveX
control have to be certified by the Korean government in order to be
used. So, it seems like our SEED implementation could not be used
legally anyway, since it hasn't been certified. Is that your
understanding?

My understanding is that the Korean government would also require
websites that fall under these regulations to use certificates issued
by some Korean certificate authorities. But, Mozilla does include
either of the Korean certificate authorities and it seems unlikely to
happen soon. See https://bugzilla.mozilla.org/show_bug.cgi?id=335197

Finally, the SEED cipher suite we do currently support does not
support ephemeral key exchange. I see that the internet draft I linked
to above does attempt to specify SEED cipher suites that support
ephemeral key exchange.

So, it seems pretty clear to me that it is OK to disable the SEED
cipher suite we have currently enabled for now, while we figure out
all the things that are necessary to help our Korean users.

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

Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers

[Brian Smith]

On Thu, Sep 12, 2013 at 7:06 AM, Julien Vehent  wrote:
> It seems that AES-256 is always 25% to 30% slower than AES-128, regardless of 
> AES-NI, or the CPU family.

> The slowest implementation of AES-256 has a bandwidth of 21MBytes/s, which is 
> probably fast enough for any browser

> If performance was the only reason to prefer AES-128, I would disagree with 
> the proposal. But your other arguments regarding AES-256 not
> provided additional security, are convincing.

> This paper: eprint.iacr.org/2007/318.pdf
>   On the complexity of side-channel attacks on AES-256
> - methodology and quantitative results on cache attacks -

Perhaps my arguments were a little over-stated though. The attack I
referenced in the proposal is the related-key attack on reduced-round
AES-256. That is something I should have emphasized. Really, I am
speculating that this shows that thinking AES-256 is hugely more
secure than AES-128 is questionable, but it isn't a slam-dunk case.

The side-channel attack paper you cited seems like the more
interesting one. It doesn't seem like an argument against AES-256 on
its own though, since it still says AES-256 is more difficult to
attack through the given side channels than AES-128.

So, the main remaining question with AES-256 vs. AES-128 is not
whether AES-128 is just as secure as AES-256. Instead, we have to
decide whether AES-256 a better security/performance trade-off vs
AES-128. I agree with you that the performance numbers for AES-256 vs.
AES-128 do not make this a slam-dunk. We should do the measurements on
a typical Firefox OS device and see if there is a significant
difference there. Until then, unless others suggest otherwise, I think
I will just keep the relative ordering of analogous AES-256 and
AES-128 cipher suites the same as they are in NSS today.

> However, it refers to software implementations of AES. Do we know if this
> result still applies for AESNI?

One takeaway from your email is that with AES-NI I don't see a strong
case for prefering AES-128 over AES-256. The issue is really what to
do about the non-AES-NI case, assuming we all agree that the presence
of AES-NI shouldn't affect the order that the client suggests cipher
suites in.

Thank you very much for taking the time to do these measurements and
sharing your insight.

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Removing SSL 2.0 from NSS (was Re: Removing dead code from NSS)

[Brian Smith]

On Mon, Oct 7, 2013 at 3:20 PM, Robert Relyea  wrote:
> On 10/07/2013 12:44 PM, Wan-Teh Chang wrote:
>> On Mon, Oct 7, 2013 at 11:17 AM, Brian Smith  wrote:
>>> I think it is likely that some vendors of NSS-based products with very
>>> conservative backward-compatibility guarantees, like Oracle and maybe
>>> Red Hat, may need to continue supporting SSL 2.0 in their products due
>>> to promises that they've made. If so, either we should create a branch
>>> for these organizations to maintain, or we should create a branch of
>>> libssl without SSL 2.0.
>> The burden of maintaining the branch should fall on the people who
>> still need SSL 2.0, so we should remove SSL 2.0 from the trunk. It is
>> not that hard for a competent NSS developer to support an NSS 3.15
>> branch for another three years.
> Please don't completely screw us over here. I would prefer to be able to
> track NSS updates, particularly since they are pulled in by mozilla. (we
> completely rebase nss whenever we have to pick up new mozilla releases
> that need it).

I think if some Linux distributors would continue to use the code that
contains SSL 2.0 support, then it would be better for Firefox to link
libssl statically to avoid using that variant of libssl.

> That being said, I think we could split the ssl 2.0 code out stand
> along. The only issue is ssl2 hello->ssl3, which would probably mean
> figuring out some why to make that transition that puts the burden on
> the ssl2 code.

> Ideally so ideally we could completely fork the SSL2 code to use it's
> own gather buffers.

This is much easier said than done, because many bits of data are
shared between the implementation of SSL 2.0 and the later versions.
The point of removing SSL 2.0 would be to make the code simpler so
that we can be confident that it is correct, and to make it easier to
improve. Refactoring the SSL 2.0 code in the manner you suggest is
counterproductive to both of those aims, and recent experience gives
clear evidence of that.

> Right now I'm trying to see if I can get management to let us drop SSL2
> support in some upcoming RHEL 6 release. I've already dropped it in
> RHEL7, and I think we may be at the point in RHEL-5 where we may not be
> updating NSS except for some extreme fixes.

That is a Red Hat problem, not a Mozilla problem. The Mozilla project
is bigger than just Firefox and Gecko-based products, but I don't
think the Mozilla project's interests extend so far as to be concerned
about Red Hat backward compatibility guarantee to its customers. We
are willing to help Red Hat when it is reasonable, but I think this
issue has reached the point there it is now unreasonable to carry on
as before.

> One thing that could help is
> to make sure the next mozilla CSB release supports SSL2 that will give
> RHEL 6 some more runway...

For a long time, Gecko-based products hard-code SSL 2.0 to be disabled
and there is no option for enabling SSL 2.0 support in Gecko products.
I would not accept the addition of such an option either. If there is
some server that is SSL 2.0 only then I will be glad to have Firefox
stop working with that server, so that the server admin feels pressure
to improve the security of the server.

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: set default on for SHA2 for TLS1.1+ on firefox

[Brian Smith]

On Wed, Oct 2, 2013 at 2:28 AM, Mountie Lee  wrote:
> Hi.
> currently SHA2 hash algorithm is used in TLS1.1 and 1.2
> mozilla firefox is supporting it now.

Hi,

Are you referring to the TLS_*_SHA256 cipher suites, or something
else? I believe that we support SHA256-based signatures everywhere
already.

If you are referring to the TLS_*_SHA256 cipher suites, then the
current plan is to never enable them in Firefox. It seems Chrome has
decided on something similar, as they disabled those cipher suites
after they added AES-GCM support.

If you are referring to something other than the TLS_*_SHA256 cipher
suites, please be more specific as to what you are referring to.

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

Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers

[Brian Smith]

Mountie Lee  wrote:
> SEED was adopted to encourage escaping ActiveX dependency in Korea
> e-commerce environment.

Many people at Mozilla, including us platform engineers, want this
too. Our goal is to get rid of plugins on the internet completely.
And, also, personally I think it is a great idea for Mozilla to do
more to get Firefox working in South Korea. So, I think we all agree
on the goals.

> at last year, "adding SEED to WebCrypto API" adopted as Action Item.
> the editor sent question "any user agent plan to implement SEED"
>
> I can not say "discussing terminating SEED support in mozilla"

Whether SEED gets implemented to the WebCrypto API is a separate issue
from whether we continue to support SEED in TLS. If we want to add
SEED support to WebCrypto then we can do that even if we don't have
SEED in TLS. I am not going to promise that we will implement SEED as
part of the WebCrypto effort, but I do promise to give it serious
consideration.

> minor algorithm itself has the meaning.
> it will be helpful for neutralizing or keeping possibilities.

I agree that this is a concern. This is one of the reasons we are
looking into the Salsa/ChaCha algorithms, as a backup or replacement
for AES.

Finally, software vendors, including Mozilla, need to work with the
Korean government to agree on what to do about the Korean crypto
regulations. Mozilla has been supporting SEED for TLS for a long time
and it seems to have had no positive impact. If in the future the
software industry and the Korean government decide that SEED in TLS is
the way forward, then we can add SEED back if we remove it now.
However, I am skeptical that the software industry is going to agree
that SEED in TLS is the right path forward.

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

Removing SSL 2.0 from NSS (was Re: Removing dead code from NSS)

[Brian Smith]

On Fri, Oct 4, 2013 at 6:52 PM, Ludovic Hirlimann
 wrote:
> Hi,
>
> AFAIK NSS still contains code for SSL2 , but no product uses it. SSL2
> has been turned off at least 2 years ago. By removing SSL2 code we get :
>
> Smaller librarie
> faster compile time + test time
>
> What do you guys think ?

Hi Ludovic,

I do think it is time to remove SSL 2.0 support from libssl. The size
of libssl won't be much different and it won't compile much faster.
However, removing SSL 2.0 code from libssl will enable us to make the
code much easier to understand in ways that I am 100% sure will
positively impact the security of our SSL3/TLS code. So, I propose
that libssl remove SSL 2.0 support in NSS 3.16. I will be happy to
write the patch for it; I actually have it partially done already.

I can think of at least one serious bug in libssl that likely would
have been avoided if not for the additional complexity of needing to
deal with SSL 2.0. Plus, not having to deal with the SSL 2.0 code will
definitely enable us to improve the SSL3/TLS code easier in the
future. I can think of multiple times where the need to deal with the
SSL 2.0 code has slowed down the implementation of improvements to the
newer protocols. This is an unreasonable cost for us to have to incur
for a feature that we know nobody should be using.

When the NSS team discussed this topic previously, we had agreed that
we wouldn't remove the SSL 2.0 code before TLS 1.2 was implemented, so
that Red Hat could have a version of NSS with both SSL 2.0 and TLS 1.2
for their long-term release. Now TLS 1.2 is implemented and we should
move forward with the removal.

I think it is likely that some vendors of NSS-based products with very
conservative backward-compatibility guarantees, like Oracle and maybe
Red Hat, may need to continue supporting SSL 2.0 in their products due
to promises that they've made. If so, either we should create a branch
for these organizations to maintain, or we should create a branch of
libssl without SSL 2.0. I am OK with doing things either way, though I
prefer to have the NSS trunk be the SSL-2.0-less branch that Mozilla
contributes to.

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

Re: Removal of generateCRMFRequest

[Brian Smith]

sst...@mozilla.com wrote:
> Do we have telemetry on how frequently these APIs are used?

I expect that, of the small percentage of people that are using these APIs, 
they are using them (except signText) very infrequently--like once a year. When 
I talked to Ehsan and Andrew Overholt about this, we agreed that the numbers 
would be pretty meaningless because telemetry is per browser session and we 
can't track users longitudinally. Also note that telemetry may under-count Red 
Hat's customers, as I imagine many of them are running in networks where 
administrators disable telemetry, and also they are all running the ESR 
release, I think. Finally, I suspect that any use of signText() is highly 
localized to specific reasons, which we also cannot capture with Telemetry, 
AFAICT.

Regardless, I am willing to add telemetry to verify that these APIs are not 
being used shockingly often. But first, let's decide on what the threshold for 
making a decision would be. For example, let's say the number comes back as 
less than 1/1000 of sessions are using these APIs. Would that be considered 
evidence in favor of removal?

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

Re: Removal of generateCRMFRequest

[Brian Smith]

On Sat, Sep 28, 2013 at 7:52 AM, Sean Leonard  wrote:
> On 9/27/2013 5:51 PM, Robert Relyea wrote:
>>
>> I don't have a problem with going for an industry standard way of doing
>> all of these things, but it's certainly pretty presumptuous to remove these
>> features without supplying the industry standard replacements and time for
>> them to filter through the internet. bob

Why isn't  good enough?

AFAICT, based on this discussion and others, smart card events are not
a must-have feature for any website. They are a nice-to-have, at best.
At worst, they are the wrong model altogether. Either way,
clearcutting them to make our sandboxing project easier and faster to
complete still seems to make sense for me. I understand that that
isn't the most friendly strategy towards the websites that are using
that feature, but it is extremely unfriendly (at best) of us toward
hundreds of millions of people to be giving them a browser without a
sandbox. Sandboxing is a must-have-ASAP feature.

> In addition, it would be a great shame to remove this set of APIs from
> Firefox because the Mozilla platform itself uses them for chrome-privileged
> purposes. If you search "smartcard-insert", for example:
> http://mxr.mozilla.org/mozilla-central/search?string=smartcard-insert

> Our
> Firefox extension makes use of these events (in addition to the other APIs)
> so that would directly impact us as well.

Good point. We can still keep them around in chrome-privileged
contexts because chrome-context stuff lives in the parent process and
so would not be affected by sandboxing. So, if we preserved the
chrome-context stuff, would your extensions still work?

> It is one thing to remove the  tag, which most users have found
> annoying or harmful (epilepsy). Removing crypto functionality in contrast
> impacts critical security functionality for many users.

Again, smartcard events don't seem like critical functionality and
 exists. signText is the only API I can see where there is no
replacement and that would be difficult to go without. But, it is also
problematic because of its UI; I don't think its UI is sufficiently
clear and bulletproof that it is really effective at conveying exactly
what is being signed--especially when you consider
internationalization and localization issues.

> The Internet is made good when people can use it to do productive work.
> Removing functionality that is used by vendors and users for no reason other
> than "purity" is unproductive and costly.

My main motivation is to make the sandboxing project easier to
complete ASAP. The WebAPI team has the "purity" goal and it isn't my
place to judge that, as I don't know as much as they do about the web
API standardization situation.

> By the logic of "purity",
> XMLHttpRequest should have been removed a long time ago because it was an
> IE-proprietary feature. The "open web" is an ecosystem of server-side and
> client-side technologies where everyone can innovate by introducing new
> things. If it's a useful feature, you can copy it.

XHR became standardized. Which of the Mozilla-proprietary APIs in
window.crypto.* do you think has any chance at all of standardization?
Ryan Sleevi is on the Chrome team and works on the W3C Web Crypto API
spec., and based on what he's written, he seems to agree with me that
they don't.

I also agree with Ryan that we don't have to feel committed to these
APIs just because we implemented them back when we were trying to make
money selling the enterprise server software that these APIs were
created to support. So, I'm not going to predicate the removal of
these APIs on the creation of replacements. However, there's no reason
why this community can't help formulate, standardize, and even
implement the replacements before we ship a browser without these
APIs. In fact, everybody at Mozilla would love for that to happen.
But, also, I don't think we're going to be sad if we ship a sandboxed
browser without any such APIs.

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

Re: Removal of generateCRMFRequest

[Brian Smith]

On Fri, Sep 27, 2013 at 2:31 AM, Eddy Nigg  wrote:
> On 09/27/2013 02:29 AM, From Brian Smith:
>
>> I have met with several members of our DOM and web API teams and we've
>> tentatively agreed that we should remove these functions if at all
>> possible--as soon as 2014Q1. That is, we're hoping to remove all of
>> window.crypto.* except getRandomValues, and all of window.pkcs11.* (smart
>> card events).
>
>
> Just for the record, we are using the window.crypto.enableSmartCardEvents
> and friends - also note that IE provides a similar functionality for that.

Hi Eddy,

My question is not so much "Is anybody using this functionality" but
rather "What really terrible things, if any, would happen if we
removed them?"

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Removal of generateCRMFRequest

[Brian Smith]

On Mon, Apr 8, 2013 at 2:52 AM, helpcrypto helpcrypto
 wrote:
>
> While awaiting to http://www.w3.org/TR/WebCryptoAPI/ Java applets for
> client signning, signText and  are needed.
> Also things like Handling smart card events or Loading PKCS #11
> modules is being use by many.
> So, you _CANT_ remove
> https://developer.mozilla.org/en-US/docs/JavaScript_crypto
>
> If you want/need more detailed discussions, dont hesitate to ask me.

Hi,

Yes, I am interested in hearing why you think we cannot remove these functions.

I have met with several members of our DOM and web API teams and we've
tentatively agreed that we should remove these functions if at all
possible--as soon as 2014Q1. That is, we're hoping to remove all of
window.crypto.* except getRandomValues, and all of window.pkcs11.*
(smart card events). Mozilla's policy about web API removal is to make
an announcement that gives websites at least three releases (18 weeks)
of notice. This is not that announcement, but I hope to make such an
announcement soon.

We don't expect other browsers to ever implement this API, so they are
effectively a Mozilla-proprietary API. We are trying to avoid creating
our own proprietary APIs in the hopes that other browsers will do the
same. You can see some of the guidelines we are working on here:
https://wiki.mozilla.org/User:Overholt/APIExposurePolicy

If we were to try to standardize this functionality, we would almost
definitely have to make substantial changes to the APIs as part of the
standardization process. For example, the current APIs assume some
equivalence relation between RSA key sizes and ECC curve strength.

I think smart card events are especially problematic because they seem
to add additional privacy/fingerprinting exposure.

generateCRMFRequest seems like it can be replaced by some JavaScript +
 + server-side processing, and we suspect that sites that are
using GenerateCRMFRequest in Firefox must already do this for other
browsers. I understand that  is not the greatest thing in the
world either, but it has the benefit of at least having a
specification for browsers to follow.

signText seems to be the most difficult thing to remove because there
is no way to emulate its smart card access capabilities with standard
web APIs. At the same time, the way signText works is problematic
enough that I suspect no other browser will ever implement it.

We are working on creating a multi-process sandbox for web content,
similar to the sandboxes used in other web browsers. This is one of
the few remaining APIs that isn't implemented in a
multi-process-friendly manner, and given all the above issues we don't
want to spent time converting it to be multi-process-friendly.

Instead, I would like to figure out what, if any, alternative to
signText we can provide, and also what we need to do to enhance our
 implementation to help websites migrate away from
generateCRMFRequest.

I am very curious, in particular, what products that use
generateCRMFRequest and/or signText do for other browsers, especially
Chrome.

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers

[Brian Smith]

On Mon, Aug 26, 2013 at 2:24 PM, Brian Smith  wrote:

> Something to note is that MSIE has always put AES-128 cipher suites ahead
> of AES-128 cipher suites. They also put RSA cipher suites ahead of PFS
> cipher suites, though.
>
>

I meant: MSIE has always put AES-128 cipher suites ahead of **AES-256**
cipher suites.

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers

[Brian Smith]

On Thu, Aug 22, 2013 at 11:21 AM, Robert Relyea  wrote:

> So looking at this list, I think we have a major inconsistency.
>
> We put Ephemeral over non-ephemeral, but we put 128 over 256.
>
> While I'm OK with Ephemeral (PFS) over non-ephermal (non-pfs), I think
> in doing so we are taking a much more significant performance hit we get
> back by putting 128 over 256.
>

It is not exactly true that PFS always has more of a negative performance
impact than AES-128 vs AES-256. In Chromium, PFS ciphersuites will be
faster than non-PFS cipher suites because Chromium requires PFS
ciphersuites to be used for False Start. Also, I have an idea for how we
can make PFS cipher suites + False Start work much more commonly on the
web, that won't work for RSA key exchange. So, ultimately, I expect PFS
cipher suites to be a performance win over non-PFS cipher suites.

But, raw performance isn't the only issue. We expect that PFS cipher suites
*can* have significantly better security properties (see below) if the
server puts in the effort to make the encryption keys actually ephemeral,
and we expect that they are generally no worse they are no worse regarding
security (barring disastrous implementation errors).

Conversely, it isn't clear that AES-256 offers any significant security
advantage over AES-128, though it is clearly slower, even on my
AES-NI-equipped Core i7 processor. First, AES-128 has held up pretty well
so that it might just be "good enough" in general. Secondly, as I already
pointed out in my proposal, some research has shown that AES-256 doesn't
seem to offer much more security than what we understand AES-128 to offer.
See http://www.schneier.com/blog/archives/2009/07/new_attack_on_a.html and
https://cryptolux.org/FAQ_on_the_attacks. Thirdly, when non-constant-time
implementations are used, AES-256 seems to offer more opportunity for
timing attacks than AES-128 does, due to more rounds and larger inputs.


> The attack profile protection of PFS versus non-PFS is basically two
> points:
> 1) some government agency could force a server to give up it's private
> keys and decrypt all the traffic sent to that server. But we already
> know that government agencies with such power simply ask for the the
> data on the server.
>

This argument seems to assume that all the data that was transferred over
the network is stored on the server. But, this is not necessarily the case.
I don't think that is a reasonable assumption. The site may have already
deleted the data (perhaps at the request of the user) from the server.
Also, there is a lot of transient data that is never stored anywhere.
Finally, sometimes it is more interesting for the attacker to know what
data was transmitted than to know what data is on the server. For example,
if somebody is trying to prosecute me for posting my album collection to
MegaUpload, the existence of the album data on the MegaUpload server may
not be too useful, whereas a record of me doing the upload of that data
with my actual credentials may be.


> I still think PFS algorithms are useful and agree with preferring them,
> but compared to 128 versus 256 it seems like the cost/security tradeoffs
> are actually less for the PFS algorithms.
>

First, I agree with the overall idea that the performance cost of AES-256
over AES-128 isn't huge. However, I do think that it is significant, at
least for mobile clients where such concerns are most critical--not just
speed, but also battery life. We can gather the numbers (perhaps others
already have them) if that helps.

Something to note is that MSIE has always put AES-128 cipher suites ahead
of AES-128 cipher suites. They also put RSA cipher suites ahead of PFS
cipher suites, though.

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

Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers

[Brian Smith]

On Mon, Aug 12, 2013 at 6:52 AM, Gervase Markham  wrote:

> On 09/08/13 18:12, Brian Smith wrote:
> > No, each combination is hard-coded into its own distinct code point that
> is
> > registered with IANA:
> >
> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4
> .
> > This is a design choice based on the fact that many crypto modules don't
> > let you mix/match algorithms at will, and because you often
> can't/shouldn't
> > move keys between crypto modules.
>
> OK. So you are choosing from a fixed palette, and changing that palette
> is outside the scope of this proposal?
>

It is possible to add new cipher suites, but new cipher suites should have
substantial value and a realistic shot at becoming widely-deployed.


> I agree this is theoretically possible but, as Tom points out, if we
> posit an attacker who can see your traffic, the chances of you
> concealing the identity of your user agent from him are pretty small.
>
> When risk is there to a user of having a network eavesdropper able to
> tell that they are using a particular browser? If I had an exploit for a
> particular browser, I'd just try it anyway and see if it worked. That
> seems to be the normal pattern.
>

One example is Tor: it tries to look like "a normal browser" so that it is
hard to detect that you are using Tor. And, if Tor is properly configured
then the network attacker will never see any non-TLS traffic.


>  >> * Re: Camellia and SEED: we should talk to the organisations which
> >> pushed for their addition, and our business development people in the
> >> region, before eliminating them. (This is not to say that we will
> >> definitely not remove them if they raise objections.)
> >
> > Do you have suggestions for who to contact?
>
> The first person I would talk to would be Gen Kanai ,
> although he may put you in touch with others.
>

Thanks. I will send ask him to forward a link to these threads to the
people he thinks may be interested in it.

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

Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers

[Brian Smith]

On Fri, Aug 16, 2013 at 5:58 PM, Wan-Teh Chang  wrote:

> On Fri, Aug 16, 2013 at 3:36 PM, Rob Stradling 
> wrote:
> >
> > Wan-Teh, why do you think Firefox should specify a preference for ECDSA
> over
> > RSA?
>
> Because ECDSA is more secure than RSA, and ECC implementations will
> become faster over time.
>
> The ordering of RSA and ECDSA is really a "symbolic gesture" right now
> because they each require a certificate, and very few websites have
> both an RSA certificate and an ECDSA certificate.
>

I agree that the ordering of ECDSA vs. RSA is mostly a symbolic gesture at
this point in time due to the small number of websites that have both types
of certificates, and the motivations for those sites to have both types.
But, I don't think we should base the order that browsers choose based on
this symbolic meaning; instead, we should base the ordering on what gives
the client the best security/performance/compatibility tradeoff.

I am not sure that we can say that ECDSA is more secure than RSA in a
meaningful way. The old Debian OpenSSL bug and the new Android OpenSSL bug
both offer some empirical evidence that implementation errors in PRNGS are
more likely to reduce security than the theoretical concerns that would
indicate that ECDSA is generally more secure than RSA. Also, the minimum
RSA key size that is acceptable according to the baseline requirements is
2048 bits. For digital signatures, there seems to be quite a significant
margin between what seems to be needed to authenticate a single TLS
handshake and the security level that RSA 2048 offers. If we assume that
websites will generally choose the smallest/fastest key that is considered
acceptable according to the CABForum baseline requirements (RSA 2048 and
ECDSA P-256) then especially on ARM there is quite a performance advantage
for the client to get an RSA signature instead of an ECDSA signature. If
the server is choosing which certificate to use based on the client's
preferences instead of its own performance needs, then the client should be
suggesting what is best for the client, on the assumption that the server
is making a rational decision.

More generally, the ordering I suggested isn't intended to be the ordering
that servers should use if they are configured to disregard the client's
preferences. For example, many servers wouldn't want to choose CBC-based
ciphersuites over RC4 yet if they are concerned about BEAST or Lucky 13.
But, for NSS-based clients, it does make sense to choose the CBC-based
ciphersuites in the proposal over RC4 because the NSS-based clients have
implemented fixes for BEAST and Lucky 13, but not for the RC4 issue.

I will update the proposal to mention these things.

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers

[Brian Smith]

On Fri, Aug 16, 2013 at 11:13 AM, Camilo Viecco  wrote:

> Hello Brian
>
> I think this proposal has 3 sections.
> 1. Unifing SSL behavior on browsers.
> 2. Altering the criteria for cipher suite selection in Firefox (actually
> NSS)
> 3. removing certain cipher suites from the default firefox ciphersuite.
>
> On 2:
> The proposal is not clear. I want an algorithmic definition.




This criteria gets to your ordering proposal. What do you think of
> re-framing your list in a criteria like

this? (note national ciphers could go in step 6 instead of step 3).
>

That sounds reasonable to me. I did not invest too much effort on making
the results computable from the rationale section because I think it is
likely that a lot (or all) of the rationale section would be reduced or
removed from any IETF internet draft that proposed a web browser profile of
TLS.


> On 3:
>
> Not adding:
> TLS_(EC?)DHE_RSA_WITH_AES_(**128|256)_CBC_SHA256
> Disagree I dont think a potential performance issue should prevent us from
> deploying that suite as there could be sha1 attacks that we dont know of.


Now that NSS has AES-GCM, we have an alternative to HMAC-SHA1. Also, if we
are a little presumptuous, we can expect to have a third alternative in
Salsa20/12+(UMAC|VMAC|Poly1305) sometime in the near future. If we find it
is important to offer HMAC-SHA256/384 later, we can do so then. But, if we
add them now, we will have difficulty removing them later.


> If we have enough space in the handshake I see no problem in including
> them.
>

We will have to determine whether the 256-byte client hello limitation is
really something that we have to deal with in the long term. But, even if
that turns out now to be something we need to ever worry about, I would
still be against adding HMAC-SHA256/384 when there seem to be better
alternatives that do not regress performance from what we're offering now.

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

Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers

[Brian Smith]

On Thu, Aug 15, 2013 at 10:15 AM, Chris Richardson wrote:

> I believe this plan would have poor side effects.  For example, if Apple
> ships clients with a broken ECDSA implementation [0], a server cannot
> detect detect if a connecting client is an Apple product and avoid the use
> of ECDSA in that subset of connections.  Instead, ECDSA suddenly becomes
> unsafe for anyone to use anywhere.
>

I think your argument is more about the "Future work: A comprehensive
profile for browsers' use of TLS" part of the document, since the
fingerprinting that OpenSSL is now using to detect Safari 10.8 uses the
presence and ordering of TLS extensions like SNI that are not in the scope
of the current proposal. Although I think browsers could now realistically
all agree on the sequence of ciphersuites to offer by default in their
client hello, we're far from standardizing on the contents of the entire
client hello. Let's defer the debate the pros/cons of completely
eliminating fingerprinting in TLS until it is more realistic to do so (if
ever).

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

Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers

[Brian Smith]

On Fri, Aug 9, 2013 at 3:27 AM, Gervase Markham  wrote:

> * Can you provide some background or references on exactly how
> ciphersuite construction and choice works? Can I invent e.g.
> TLS_DHE_ECDSA_WITH_AES_128_MD5 or some other random combination of
> elements? Can any combination be encoded in the ClientHello? Does the
> server support specific sets, or will it support my combination if it
> supports all the component pieces?
>

No, each combination is hard-coded into its own distinct code point that is
registered with IANA:
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4.
This is a design choice based on the fact that many crypto modules don't
let you mix/match algorithms at will, and because you often can't/shouldn't
move keys between crypto modules.


> * "We should avoid leaking the distinction between mobile and desktop
> products in the TLS handshake, which means that the handshake should
> look the same on mobile and desktop."
>
> Why is this a goal? There are many, many other ways of determining this
> distinction, some supported by Mozilla (e.g. the UserAgent string).
>

There is a difference between leaking to somebody on the network and
leaking to the server you are connecting to. Remember that TLS hides the
User-Agent string and other HTTP-level information is hidden from others on
the network. So, if Firefox for Android and Firefox for Desktop use the
exact same TLS handshaking logic/parameters, then it should be possible to
make them indistinguishable from each other.


> The same question applies to your point about avoiding TLS
> fingerprinting. I think it should be a goal to make it hard to
> distinguish between specific instances of Firefox, but it seems to be
> not a goal to avoid people distinguishing between Firefox and IE, or
> Firefox for desktop and Firefox for Android.
>

If every browser's TLS handshake were to look the same, then observers on
the network wouldn't be able to tell browsers apart, though the website you
are connecting to obviously would. I admit that is a state that is likely
to be difficult to obtain.

* "this proposal does not recommend supporting the CBC-HMAC-SHA-2-based
> ciphersuites that those browsers recently added"
>
> Can you spell out why? Is it because they don't offer forward secrecy?
>

It is explained below. Worse performance, no security benefit, and they
take up space in the handshake.


> * "In the course of testing TLS 1.2 and the ALPN TLS extension, the
> Chromium team recently found that some servers choke when the
> ClientHello message in the TLS handshake is larger than 256 bytes."
>
> How many bytes are taken up per ciphersuite? How many can we probably
> fit in, if we say we need to include all the other stuff?
>

They take two bytes per ciphersuite. If the 256-byte limitation cannot be
worked around, then we basically can't afford to waste *any* bytes in the
TLS handshake. It is already likely going to be very difficult for us to
support the ALPN extension as it is, even after making these reductions.


> * Re: Camellia and SEED: we should talk to the organisations which
> pushed for their addition, and our business development people in the
> region, before eliminating them. (This is not to say that we will
> definitely not remove them if they raise objections.)
>

Do you have suggestions for who to contact?


> * "Given our current understanding, HMAC-SHA-1, HMAC-SHA-256, and
> HMAC-SHA-384 are all more-or-less equal in terms of security given how
> they are used in TLS."
>
> However, if we never use them, then have to switch to them because a
> problem arises with HMAC-SHA-1, how will they have received any testing?
>


>
> More generally, is there a place for including ciphersuites 'of the
> future', perhaps at lower priority, to try and make sure there aren't
> problems or interop issues with them?
>

We will soon have AES-GCM and we'll hopefully soon have
Salsa20/12+(Poly1305|UMAC|VMAC) to mitigate that. Relying on either/both of
those alternatives kills more birds with fewer stones. I think ultimately
we'd rather have all HMAC-based ciphersuites also marked deprecated, for
performance and security reasons.


> * Your final section says what cipersuites should be added and dropped.
> Is this simply a config change with testing, or does it require code to
> be written in one or more of the TLS stacks?
>

Dropping ciphersuites is a simple configuration change.

In the top table, the "notes" column lists the ciphersuites that will
require code changes to NSS and to SChannel. Bug
880543tracks the
addition of AES-GCM ciphersuites to NSS's libssl. OpenSSL
already implements them. I think Google may be working on
Sals20/12+Poly1305 ciphersuites and there has been some small progress on
adding Sals20/12 ciphersuites in the IETF TLS working group.

Reordering ciphersuites in SChannel can be done with a configuration change
to the app. Reordering cip

Proposal to Change the Default TLS Ciphersuites Offered by Browsers

[Brian Smith]

Please see https://briansmith.org/browser-ciphersuites-01.html

First, this is a proposal to change the set of sequence of ciphersuites
that Firefox offers. Secondly, this is an invitation for other browser
makers to adopt the same sequence of ciphersuites to maximize
interoperability, to minimize fingerprinting, and ultimately to make
server-side software developers and system administrators' jobs easier.

Suggestions for improvements are encouraged.

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: libnss3.so available on FireFox on Android?

[Brian Smith]

On Wed, Jul 31, 2013 at 1:58 AM, Robert Relyea  wrote:

> On 07/30/2013 04:27 PM, Brian Smith wrote:
>
>> See
>> https://mxr.mozilla.org/**mozilla-central/source/**
>> services/crypto/modules/**WeaveCrypto.js#123<https://mxr.mozilla.org/mozilla-central/source/services/crypto/modules/WeaveCrypto.js#123>
>> and 
>> https://bugzilla.mozilla.org/**show_bug.cgi?id=583209<https://bugzilla.mozilla.org/show_bug.cgi?id=583209>
>> and 
>> https://bugzilla.mozilla.org/**show_bug.cgi?id=648407<https://bugzilla.mozilla.org/show_bug.cgi?id=648407>
>>
>
> Oh, I didn't get that it was a call from inside extension services. I did
> read through the bug, and it sounds like there is some work the extension
> needs to do to get access to NSS functions, but it wasn't clear what it
> was. Brian is there a document that deals with what extensions need to do
> to change to this new monolithic linking?
>

Basically, all of the NSS libraries except softoken and freebl get folded
into libnss3.so. But, not on Linux. So, if you're going to use something
that is not normally in libnss3.so, you need to have two code paths: one
for Linux, and one for all other platforms.

Basically, the WeaveCrypto.js link seems to be doing the things that are
required, such as making sure PSM is initialized so that NSS is initialized.

But, now I remember that WeaveCrypto.js got replaced with a Java
implementation on Android a while back. So, maybe WeaveCrypto.js isn't
handling the Android case correctly.

If you are still having trouble then try adding a "lib/" to the path on
Android. And, if that doesn't work, ask on #developers on irc.mozilla.org.

Cheers.
Brian



>
> bob
>
>
>>
>>
>>
>> On Tue, Jul 30, 2013 at 11:58 PM, hv  wrote:
>>
>>  Hi,
>>>
>>> I was not able to open NSS on FF android. Is NSS available on FireFox on
>>> Android?
>>> I tried the follwing:
>>>
>>> var ds = Services.dirsvc.get("GreD", Components.interfaces.**
>>> nsILocalFile);
>>> var libName = ctypes.libraryName("nss3");
>>> ds.append(libName);
>>>
>>> var nsslib = ctypes.open(ds.path); // FAILS TO OPEN
>>>
>>> --
>>> dev-tech-crypto mailing list
>>> dev-tech-crypto@lists.mozilla.**org 
>>> https://lists.mozilla.org/**listinfo/dev-tech-crypto<https://lists.mozilla.org/listinfo/dev-tech-crypto>
>>>
>>>
>>
>>
>
>
> --
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>



-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: libnss3.so available on FireFox on Android?

[Brian Smith]

See
https://mxr.mozilla.org/mozilla-central/source/services/crypto/modules/WeaveCrypto.js#123
and https://bugzilla.mozilla.org/show_bug.cgi?id=583209
and https://bugzilla.mozilla.org/show_bug.cgi?id=648407




On Tue, Jul 30, 2013 at 11:58 PM, hv  wrote:

> Hi,
>
> I was not able to open NSS on FF android. Is NSS available on FireFox on
> Android?
> I tried the follwing:
>
> var ds = Services.dirsvc.get("GreD", Components.interfaces.nsILocalFile);
> var libName = ctypes.libraryName("nss3");
> ds.append(libName);
>
> var nsslib = ctypes.open(ds.path); // FAILS TO OPEN
>
> --
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>



-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Removal of "Revocation Lists" feature (Options -> Advanced -> Revocation Lists)

[Brian Smith]

Julien Pierre wrote:
> If this is about removing the feature from NSS altogether on the
> other hand, I would like to state that we have several several
> products at Oracle that use NSS and rely on the ability to have
> CRLs stored in the database, and processed during certificate
> validation.

I am not proposing any change to NSS.

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

Re: Removal of "Revocation Lists" feature (Options -> Advanced -> Revocation Lists)

[Brian Smith]

Robert Relyea wrote:
> On 05/02/2013 02:02 PM, Brian Smith wrote:
> So are you actually going to ship a different version of NSS with the
> default Firefox, or are you going to create a switch that changes the
> behavior of NSS with respect to stored CRLs (and what about cached
> CRLs, and do you want to support persistent cached CRLs?). I'm not
> really sure this decision has been completely thought through...

There are no plans to change NSS, so as long as we're using NSS we would still 
check the stored CRLs, though there would be no UI to manage them. I doubt that 
the type of deployments that you are concerned about are managing these CRLs 
through the Firefox UI anyway.

> > I think this will address the desires of your customers, since they
> > are using system NSS with libpkix on RHEL, right? This would also
> > meet the goal of driving the web towards sane, uniform, and
> > standardized certificate processing, since Firefox wouldn't do it
> > by default.
> 
> I'm not completely sure. I know I have to worry about off-line for
> things like smart card login, which doesn't affect FF. I don't know
> if the customer has some sort of off-line use of FF on windows (It
> does seem like an oxymoron: off-line and FireFox and https...). 
> You are probably right on this case.

I am only talking about SSL. There seems to be a vague agreement to stop using 
code signing for Firefox extensions, and I have a goal of removing all the 
email-certificate related stuff from Gecko (moving all S/MIME functionality it 
to mailnews). So, then Gecko and Firefox only need to worry about the SSL case. 
Like you noted, it would be very strange to me to *require* these offline CRLs 
for the SSL case for a closed network. Also, even if it were to be important to 
those particular users, it does not seem to be a particularly important use 
case for the Firefox product.

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

Re: Removal of "Revocation Lists" feature (Options -> Advanced -> Revocation Lists)

[Brian Smith]

Robert Relyea wrote:
> Oh, in that case I can say we have customers that definately need to
> use CRLs that have been loaded and stored in the database.

> > To be clear, I don't know of any reason to consider the processing
> > of already-loaded CRLs as a requirement for Firefox.

> Oh, then I'd say we really can't remove it

Right now, I am thinking that we will remove it in the default configuration of 
Firefox. If the user has switched Firefox to use the system's certificate 
verification logic, and the system's certificate validation logic happens to 
use this information, then it will get used. The good thing (for Firefox) is 
that it will be the operating system's responsibility to provide tools to 
manage this and also to make sure that it works, independently of anything that 
Firefox explicitly does.

I think this will address the desires of your customers, since they are using 
system NSS with libpkix on RHEL, right? This would also meet the goal of 
driving the web towards sane, uniform, and standardized certificate processing, 
since Firefox wouldn't do it by default.

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

Re: Removal of "Revocation Lists" feature (Options -> Advanced -> Revocation Lists)

[Brian Smith]

Robert Relyea wrote:
> Brian, I was under the impression you wanted to remove the CRL
> autofetching feature (where you enter a URL and a fetching time and
> the CRL will automatically be fetched). When I looked at the UI, it
> looked like it had both the URL fetching feature as well as the
> ability to manage downloaded CRLs. I think you need to be careful
> about removing the management ability with CRLs. The most important
> part of the UI is the ability to delete CRLs which may have gotten
> into the database.

My intent is to remove/disable all aspects of this feature: the UI *and* the 
processing of CRLs stored in the database.

> Any the processing of already loaded CRLs is part of NSS proper. You
> can load them and delete them by hand with crlutil. What you can't do
> is have them automatically refreshed.
> 
> Sean, is it the ability to load offline CRLs or the automatically
> fetch/refresh them that you object to. I already know that processing
> offline, already loaded CRLs are a requirement, so it's not going
> away from NSS anytime soon.

To be clear, I don't know of any reason to consider the processing of 
already-loaded CRLs as a requirement for Firefox.

Anyway, I wouldn't get to hung up about what NSS currently does. We can always 
change Firefox and/or NSS to get the behavior we need.

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

Re: Removal of "Revocation Lists" feature (Options -> Advanced -> Revocation Lists)

[Brian Smith]

Sean Leonard wrote:
> Brian Smith wrote:
> > The "Revocation Lists" feature allows a user to configure Firefox
> > to poll the CAs server on a regular interval. As far as I know,
> > Firefox is the only browser to have such a feature. Other browser
> > either ignore CRLs completely or download CRLs on an "as needed"
> > basis based on a URL embedded in the certificate.
> 
> This is not true.
> 
> The Microsoft Windows CryptoAPI stack allows users (and admins) to
> load CRLs manually, not just via an automated network call during
> certificate validation. These CRLs are checked by default (indeed,
> in preference to the network download) if they are present. Admins
> can push updated CRLs to PCs as well.

Thanks for correcting my mistake. I did search for this feature, but I could 
not find it. How does one access this feature?

> All applications on Windows that use CryptoAPI use the CRL store.
> This includes Internet Explorer, Google Chrome (at least certain
> versions and/or derivative Chromium products), and all other
> Windows-based apps that use the operating system-provided SSL or
> other certificate-touching functions (Outlook, the rest of the
> Office Suite, Authenticode, driver/kernel signing, etc.).

Also, like Jan noted in this thread, and as others have noted previously, this 
feature seems to be buggy. So, I hope that nobody has been relying on this 
feature for anything important. And, given that it seems to be 
broken/unreliable for a long time, underused, and difficult to figure out, it 
seems silly to devote any resources to fixing it, when it is much easier to 
just remove it and forget about it.

> Similar statements could be made about libnss on *nix, if and when
> multiple apps use libnss and the same stores.

> > For example, in its default configuration, Google Chrome ignores
> > CRLs, AFAICT (they use some indirect mechanism for handling
> > revocation, which will be discussed in another thread).
> 
> Not necessarily true. See above. It may be more accurate to say that
> "Chrome does not take any special effort to download CRLs of its own
> accord". 

It seems, insofar as this feature might be useful, that it would be better to 
integrate with the systems' CRL stores, rather than have our own. And, in 
general, for systems that care about this kind of stuff, it seems better in 
general to just have an option to use the system's certificate validation logic 
(e.g. Windows CryptoAPI), as configured by the sysadmin/user, for certificate 
validation, instead of Gecko/NSS's certificate validation. For the type of user 
that requires such special handling and centralized control, that seems like 
the "real" solution to this problem and related problems.

Still, insofar as revocation checking is important, it is equally important on 
all platforms. But, I seriously doubt that many of these platforms will ever 
have this feature. That is, certificates have to be safe even for platforms 
that don't have this feature, and given that, it seems pointless to have this 
if other mechanisms must already be sufficient.

> Additionally, the UI for Revocation Lists is part of "pippki", which
> is a core Mozilla Toolkit component. Removing the UI would be tantamount
> to removing it from all other apps, including Thunderbird. In theory you
> could remove it--or the button--from just Firefox, but what would be
> the point? You would just be removing functionality that has already
> proven its utility.

It would be removing broken functionality that slows down progress fixing much 
more important broken functionality.

Also, before I became module owner of PSM, I had it clarified that decisions in 
mozilla-central are to be focused on the needs of Firefox and FirefoxOS. If 
Thunderbird or another application needs a particular (mis)feature of PSM that 
Firefox/FirefoxOS doesn't need, then they can add that feature back in the 
products that need it (and fix all the bugs in those misfeatures).

> As long as you follow RFC 5280

RFC 5280 allows us to do revocation checking in any way we choose.

> However, "improvements to the core certificate validation logic" are
> NOT improvements if they ignore valuable revocation information. If a
> user (or admin) intentionally ships Firefox--or any app--with
> **additional revocation information**, that user preference ought to
> be respected.

It's going to be a long week. :)

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

Removal of "Revocation Lists" feature (Options -> Advanced -> Revocation Lists)

[Brian Smith]

Hi all,

I propose we remove the "Revocation Lists" feature (Options -> Advanced -> 
Revocation Lists). Are there any objections? If so, please explain your 
objection.

A certificate revocation list (CRL) is a list of revoked certificates, 
published by the certificate authority that issued the certificates. These 
lists vary from 1KB to potentially hundreds of megabytes in size.

Very large CRLs are not super common but they exist: Reportedly, GoDaddy (A CA 
in our root CA program) has a 41MB CRL. And, Verisign has at least one CRL that 
is close to 1MB on its own, and that's not the only CRL that they have. the US 
Department of Defense is another example of an organization known to have 
extremely large CRLs.

The "Revocation Lists" feature allows a user to configure Firefox to poll the 
CAs server on a regular interval. As far as I know, Firefox is the only browser 
to have such a feature. Other browser either ignore CRLs completely or download 
CRLs on an "as needed" basis based on a URL embedded in the certificate. For 
example, in its default configuration, Google Chrome ignores CRLs, AFAICT (they 
use some indirect mechanism for handling revocation, which will be discussed in 
another thread). AFAICT, the "Revocation Lists" feature was added to Firefox a 
long time ago when there were IPR concerns about the "as needed" behavior. 
However, my understanding is that those concerns are no longer justified. In 
another thread, we will be discussing about whether or not we should implement 
the "as needed" mechanism. However, I think that we can make this decision 
independently of that decision.

Obviously, the vast majority of users have no hope of figuring out what this 
feature is, what it does, or how to use it.

Because of the potential bandwidth usage issues, and UX issues, it doesn't seem 
like a good idea to add this feature to Mobile. But, also, if a certificate 
feature isn't important enough for mobile*, then why is it important for 
desktop? We should be striving for platform parity here.

Finally, this feature complicates significant improvements to the core 
certificate validation logic that we are making.

For all these reasons, I think it is time for this feature to go.

Cheers,
Brian

[*] Note: I make a distinction between things that haven't been done *yet* for 
mobile vs. things that we really have no intention to do.
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Root Certificates in Firefox OS (was Re: NSS in Firefox OS)

[Brian Smith]

Rob Stradling wrote:
> > I presume that Firefox OS trusts NSS's "Built-in" Root Certificates
> > [1], but what (if anything) does Firefox OS do for EV SSL?

As you found, Firefox OS doesn't have an EV UI, and in fact I just disabled the 
EV validation logic in B2G for performance reasons, given that it was wasted 
effort without a UI.

> > Does Firefox OS import PSM's list of EV-enabled Root Certificates?
> > [2]

It did, but I just disabled that since it wasn't being used for anything.

Note that this wasn't a policy decision. It could be that we will have an EV 
indicator in the future on B2G. I expect we will eventually try to make all our 
products consistent, one way or another.

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

Re: Firefox behavior for CDP and AIA

[Brian Smith]

Rick Andrews wrote:
> I know that FF allows you to choose a CRL and it will check status
> against that CRL when it finds a cert issued by the CRL issuer. Does
> anyone know if FF uses the CDP in the cert or the cert's issuer name
> as a key to find the CRL?

I assume you are talking about the "Revocation Lists" feature exposed in the 
Options > Advanced > Certificates UI.

It uses the cert's issuer name. In particular, it uses CERT_CheckCRL, which 
calls cert_CheckCertRevocationStatus, which calls AcquireDPCache, which looks 
things up by issuer name. I didn't look to see Whether we allow multiple CRLs 
for a given issuer name.

> The reason I ask is in regards to partitioned CRLs, where a CA could,
> for example, have one CRL for odd serial numbers and one for even.
> The CA would put the appropriate CDP in each cert, but would that
> confuse FF?

I'm not sure. The "Revocation Lists" feature is somewhat unmaintained and may 
be removed.

> Same question about OCSP responses and AIA.

Currently, Firefox uses the first OCSP responder URL listed in the end-entity's 
cert's AIA for doing OCSP fetches.

> Does anyone know the answers for IE?

I am not sure exactly what IE does, but IIRC Microsoft has very good 
documentation on MSDN regarding revocation checking in Windows.

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

Re: Clarification regarding SEC_PKCS7VerifyDetachedSignatureAtTime

[Brian Smith]

> What does this mean for building Firefox?
> 
> If you want to build a development snapshot of Firefox against a
> systemwide installed NSS, and you want to build Firefox 22 aurora at
> this time, you have the following choices:
> 
> - don't build Firefox 22 aurora until Mozilla cleaned up the
>   situation.
>   If you are waiting for that to happen, you could remind Mozilla
>   to either apply bug 853776 to aurora 22
>   or to extend bug 858231 to cover aurora 22, too.

I will apply the patches for bug 853776 to mozilla-aurora. The patch for that 
is going through try now:
https://tbpl.mozilla.org/?tree=Try&rev=5d0543e962b6

> Let's hope this kind of situation will remain an exception and can be
> avoided in the future.

The expectation should be that there will be local patches in mozilla-central 
and mozilla-aurora whenever those patches are the fastest way to get work done 
for Firefox. I will do what I can to get as many patches upstreamed first but 
in order for Mozilla to be able to experiment and test changes we want to 
upstream, to minimize disruption to the other users of NSS, we should utilize 
the ability to have private patches in mozilla-central and mozilla-aurora more.

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

Removal of generateCRMFRequest

[Brian Smith]

See https://bugzilla.mozilla.org/show_bug.cgi?id=524664 (bug 524664) and
See 
https://developer.mozilla.org/en-US/docs/JavaScript_crypto/generateCRMFRequest

My understanding is that  is supposed to replace 
window.crypto.generateCRMFRequest.

I have no idea how common window.crypto.generateCRMFRequest is. Is it obsolete? 
Should it be removed? Does anybody have a link to a site that is using it for 
its intended purpose?

If it is obsolete, I would like to remove it ASAP.

More generally, I would like to remove all the Mozilla-proprietary methods and 
properties from window.crypto; i.e. all the ones 
athttps://developer.mozilla.org/en-US/docs/JavaScript_crypto. Some of them are 
actually pretty problematic. Are there any worth keeping?

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

Re: Ensuring certificate chain when creating certificates in memory without db.

[Brian Smith]

passf...@googlemail.com
> I use SSL_ConfigSecureServer with a certificate which was created in
> memory (no db). The certificate was created with the
> CERT_CreateCertificate passing the CA's issuer. The same cert was
> also signed with the CA's key. The CA cert was also created on the
> fly, i.e. without the need to setup a DB. My understandings are that
> SSL_ConfigSecureServer will extract the chain from the certificate
> using CERT_CertChainFromCert but since at no stage I am somehow
> embeding the CA into the resulting cert how is this going to work?
> 
> I am not sure if it is possible to embed the CA cert data in the cert
> created by CERT_CreateCertificate. If this is possible, can you
> point me to an example how this is done?

Every time you create a CERTCertificate object, NSS adds the certificate to a 
hidden global hash table in memory, keyed by the subject name. When doing 
certificate path building (CERT_CertChainFromCert, CERT_VerifyCert, et al.) NSS 
looks up the issuer names in that global hash table. Consequently, as long as 
you have a reference to the CERTCertificate for the certs in the cert chain at 
the time libssl calls CERT_CertChainFromCert, libssl will be able to construct 
the cert chain correctly.

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

Re: Create a SelfSign Certificate in C++

[Brian Smith]

James Burton wrote:
> I want to create a selfsign certificate in c++ but i don't know were
> to start and i would like some help if you could make a example
> application to show me how to create a selfsign certificate or show
> me some documentation to create a selfsign certificates in c++.

Thanks for moving the discussion to this mailing list from Bugzilla.

In addition to looking at the source code of certutil (which is in 
security/nss/cmd/certutil/certutil.c), you can look at this code in Firefox's 
WebRTC implementation:

https://mxr.mozilla.org/mozilla-central/source/media/mtransport/dtlsidentity.cpp#28

Note that the Firefox WebRTC code was mostly based on the certutil code, IIRC.

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

NSS 3.14.2 BETA 3 tagged ; NSS 3.14.2 BETA 3 + one patch now required to build mozilla-central

[Brian Smith]

Hi all,

I tagged NSS 3.14.2 BETA 3 and pushed it to mozilla-inbound to fix build 
breakage of ASAN and dxr builds.

Also, now mozilla-central contains a patch for bug 834091. That patch adds a 
new public function to libsmime, SEC_PKCS7VerifyDetachedSignatureAtTime, which 
fulfills a last-minute B2G 1.0 need. I expect that function to get added to NSS 
in NSS 3.14.3 (not NSS 3.14.2), but first I want to make some additional 
changes to it which will change its signature and its semantics.

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

NSS 3.14.2 BETA 1 (NSS_3_14_2_BETA1) tagged and is now the minimum version for Gecko 20

[Brian Smith]

Today I tagged the CVS HEAD with the NSS_3_14_2_BETA1 tag and imported it into 
Gecko (pushed to inbound).

We expect to finalize the NSS 3.14.2 release in late January, 2013. In the 
interim, you can pull and build NSS betas from CVS:

After mozilla-inbound is merged into mozilla-central, NSS 3.14.2 BETA1 or later 
will be the minimum version of NSS for Gecko. This is relevant primarily for 
people building Gecko-based applications using the --use-system-nss option.

cvs -d:pserver:anonym...@cvs-mirror.mozilla.org:/cvsroot co -r NSS_3_14_2_BETA1 
NSS
cd mozilla/security/nss
make nss_build_all

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

NSS_3_14_2_BETA2 landed, with some patches backported to mozilla-beta (was CVS HEAD tagged NSS_3_14_1_BETA1 and pushed it to mozilla-inbound)

[Brian Smith]

Brian Smith wrote:
> Brian Smith" 
> > https://bugzilla.mozilla.org/show_bug.cgi?id=816392
> 
> This change was backed-out before it reached mozilla-central from
> mozilla-inbound because NSS crashes during startup on Android (and
> probably B2G). See bug 817233.

After the backout, I tagged NSS_3_14_2_BETA2 on the CVS HEAD and pushed it to 
mozilla-central.

Three patches were backported to mozilla-aurora and mozilla-beta as they are 
required for B2G. See:
https://bugzilla.mozilla.org/show_bug.cgi?id=818717

Firefox 18 will build correctly against NSS_3_14_2_BETA2 but it won't build 
correctly against NSS 3.14. However, if you build Firefox 18 against 
NSS_3_14_2_BETA2, you will be able to run Firefox 18 against NSS 3.14, because 
all of the changes that Gecko 18 depends are build-time-only and do not affect 
the ABI.

An alternative would be to apply just the patch for bug 808218 to system NSS 
for building Firefox 18. The other two backported fixes are not needed for 
Firefox; they are only needed for B2G.

Firefox 18 will be released on the week of 2013-01-06. This should give us 
plenty of time to finalize the NSS 3.14.1 RTM release for Linux distros to 
package it, if they choose to have their Firefox 18 packages depend on NSS 
3.14.1 instead of NSS 3.14.

I hope this unusual situation does not cause too much inconvenience.

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

NSS 3_14_1_BETA1 crashes at startup on Android (was CVS HEAD tagged NSS_3_14_1_BETA1 and pushed it to mozilla-inbound)

[Brian Smith]

Brian Smith" 
> I tagged the CVS HEAD as NSS_3_14_1_BETA1 and pushed it to
> mozilla-inbound.
> 
> If you are building Firefox or a Gecko-based application using
> --use-system-nss, you need to use the NSS 3.14.1 beta release, as
> that is now the minimum required version to build Gecko.
> 
> Thanks for the help from everybody on this.
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=816392

This change was backed-out before it reached mozilla-central from 
mozilla-inbound because NSS crashes during startup on Android (and probably 
B2G). See bug 817233.

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

CVS HEAD tagged NSS_3_14_1_BETA1 and pushed it to mozilla-inbound

[Brian Smith]

I tagged the CVS HEAD as NSS_3_14_1_BETA1 and pushed it to mozilla-inbound.

If you are building Firefox or a Gecko-based application using 
--use-system-nss, you need to use the NSS 3.14.1 beta release, as that is now 
the minimum required version to build Gecko.

Thanks for the help from everybody on this.

https://bugzilla.mozilla.org/show_bug.cgi?id=816392

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

Re: NSS 3.14 release

[Brian Smith]

Julien Pierre wrote:
> I know what code changes are necessary. I'm only a developer on a
> couple of NSS applications at this point, not an NSS maintainer.
> If this was only about those couple of apps, it wouldn't be an issue.
> But there are other apps in Oracle that could be affected.
> I can safely say that tracking and modifying every single app that
> this binary compatibility change may affect is not going to happen at
> Oracle at this point. Many other apps may not have the same kind of
> tests we have for ciphers and won't even catch the issue. As NSS gets
> distributed as patches to many existing application, binary
> compatibility is a requirement.

Generally everybody is trying to maintain binary compatibility by default. But, 
there are other concerns too, such as compatibility with other implementations, 
and/or cost of maintenance issues, that may sometimes outweigh any binary 
compatibility requirement. 

Regarding the cipher suite changes, I think that overall, more applications 
will benefit than will be hurt. In fact, although it is probably the case that 
some Oracle products are "affected," it isn't clear from your message whether 
the effect is negative or positive.

> I agree that they should be, but the decision of the defaults was
> always up to the application until now.

When an application does not explicitly set the set of enabled cipher suites, 
and/or it doesn't set a particular SSL option, then IMO it is saying "Let the 
NSS library decide what is best for me." If that isn't a good policy for an 
application, then it should set the options explicitly.

> Unless the DES ciphers were broken, I don't see the rationale
> for this change.

These were the not the 3DES ciphers; they were the original, weak, DES ciphers. 
In 2012 it is not worth analyzing whether DES ciphers are strong enough to keep 
enabled, because it is clear that they are obsolete, and everybody recommends 
against their use. But, also, see:
http://en.wikipedia.org/wiki/Data_Encryption_Standard#Security_and_cryptanalysis

"In 2008 their COPACOBANA RIVYERA reduced the time to break DES to less than 
one day, using 128 Spartan-3 5000's."

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

Re: NSS 3.14 release

[Brian Smith]

julien.pie...@oracle.com> wrote:
> Oracle still ships NSS with many products even though we are no
> longer actively involved with its development.

It is important to have somebody at least monitoring the bugs filed/fixed in 
the NSS component in bugzilla. See 
https://bugzilla.mozilla.org/userprefs.cgi?tab=component_watch for how you can 
subscribe to a feed of all NSS bug discussions.

Chris Newman wrote:
> --On October 24, 2012 22:19:40 -0700 Julien Pierre
>  wrote:
> > Oracle still ships NSS with many products even though we are no
> > longer actively involved with its development. We do pick up new
> > releases from time to time. We picked up 3.13.x last year and I'm
> > looking into picking up 3.14 .
> >> 2)
> >> - The NSS license has changed to MPL 2.0. Previous releases were
> >> released under a MPL 1.1/GPL 2.0/LGPL  2.1 tri-license. For more
> >> information about MPL 2.0, please see
> >> http://www.mozilla.org/MPL/2.0/FAQ.html. For an additional
> >> explantation
> >> on GPL/LGPL compatibility, see security/nss/COPYING in the source
> >> code.
> >
> > This may be a serious problem also, but IANAL, so that is not for
> > me to decide.
> 
> Will vulnerability fixes can be provided on the NSS 3.13.x patch
> train? And if so, is there a date when vulnerability fixes will no
> longer be provided for that version?

First, I think pretty much everybody agrees that, concerns about backward 
compatibility aside, the changes that were made were all positive. And, so, we 
have to balance backward compatibility with old versions of NSS with 
compatibility with websites on the internet and compatibility with web 
browsers. Now, there are no people actively contributing to NSS that are 
arguing in favor of absolute backward compatibility.

AFAICT, there is no plan to work on 3.13.x any more. IMO, it is better to 
continue to focus development on the trunk.

Even if somebody were to backport fixes to 3.13.x, then that work would also be 
under the MPL 2.0, for various reasons that, at this point, I think we cannot 
do anything about. For example, all the fixes in the new version are assumed to 
have been contributed under MPL 2.0. See the MPL 2.0 FAQ that contains the 
email address to send licensing questions to: 
http://www.mozilla.org/MPL/2.0/FAQ.html

Also, I thought the goal was/is to remove the bypass mode code soon. Perhaps 
that decision will partly be based on how much it gets in the way of the TLS 
1.2 implementation? I would be surprised if we required the TLS 1.2 
implementation to support the bypass mode.

By the way, I think it would be very useful to know what causes the difference 
in performance between the bypass mode and the non-bypass mode, to see if we 
can optimize the non-bypass mode so that everybody (including users of NSS 
outside of libssl) can get the performance improvements.

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

How does SMIME work in NSS (was Re: NSS in Firefox OS)

[Brian Smith]

Vishal wrote:
> On Saturday, October 20, 2012 10:33:58 PM UTC+5, Brian Smith wrote:
> > Anders Rundgren wrote: > Anyway, I guess that Firefox OS uses NSS?
> > > Is it still is based on the idea that key access is done in the
> > > application context rather than through a service? B2G (Firefox
> > OS) does use NSS. Nothing has changed regarding the process
> > separation between Gecko and the private key material. However,
> > B2G uses a process separation model where the Gecko parent
> > (chrome) process is separated from the web content. Cheers, Brian
> 
> Can someone give a detailed view if how smime works in nss ?

I don't work on S/MIME stuff. If I had to learn it, I would start by reading 
the source code to cmsutils, and the header files for lib/smime.

http://mxr.mozilla.org/security/source/security/nss/cmd/smimetools/cmsutil.c
http://mxr.mozilla.org/security/source/security/nss/lib/smime/cmst.h
http://mxr.mozilla.org/security/source/security/nss/lib/smime/cms.h
http://mxr.mozilla.org/security/source/security/nss/lib/smime/smime.h

Then, I would search for "SMIME" in the Thunderbird source code:
https://mxr.mozilla.org/comm-central/search?string=SMIME&case=1&find=&findi=&filter=^[^\0]*%24&hitlimit=&tree=comm-central

Cheers,
Brian

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

Re: NSS in Firefox OS

[Brian Smith]

Anders Rundgren wrote:
> Anyway, I guess that Firefox OS uses NSS?
> Is it still is based on the idea that key access is done in the
> application context rather than through a service?

B2G (Firefox OS) does use NSS. Nothing has changed regarding the process 
separation between Gecko and the private key material.

However, B2G uses a process separation model where the Gecko parent (chrome) 
process is separated from the web content.

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

Re: Accessing Mozilla NSS library functions in JavaScript-XPCOM

[Brian Smith]

Brian Teh wrote:
> Currently, my extension uses the NSS library which is coded in C++.
> But due to 6-week release cycle for Thunderbird, I am wondering
> whether are there examples on how to use Mozilla NSS for
> JavaScript-XPCOM, to avoid the need for re-compiling the binary
> components?

Currently, you should not use jsctypes or other JS-to-C++ bridges to access NSS 
in Gecko. One reason is that "proper" use of NSS in Gecko requires you to 
extend the native C++ nsNSSShutDownObject class in many (most? all?) 
circumstances.

The second reason is that we (Mozilla) have found it to be surprisingly 
difficult to correctly use jsctypes with NSS. In particular, you must be very 
careful that the garbage collector will not garbage collect your native code 
objects. This is one of the reasons I always recommend people to avoid jsctypes 
completely.

That said, I heard that Thunderbird is going to be based on the Gecko 17 
Extended Support Release for the next 11 months or so. That may mean you may 
not need to recompile your binary addons for Thunderbird so frequently any 
more, but I am not sure. I have CC'd Mark Banner to get clarification about 
that.

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

Re: undefined reference to '_InterlockedIncrement' when compiling nss under MinGW

[Brian Smith]

weizhong qiang wrote:
> Thanks for the instruction. I tried the build of nss on with
> mozillabuild tool (with MS VC and MS SDK, using MS compiler for
> compilation) on Win7. And the build did pass.
> But the build with MinGW/MSYS (using gcc for compilation) still
> failed.

> I hope the build (with MS compiler) can be used for my software
> (which uses gcc for compilation).

If at all possible, I recommend using the MozillaBuild toolchain to build NSS, 
with OS_TARGET=WIN95, with Visual Studio 2010. That is the best-supported 
configuration on Windows because that is what we use for official builds of NSS 
for Firefox.

I am sure it must be possible to use DLLs compiled with Visual Studio in a 
program that is built with GCC, because all built-in Windows DLLs are built 
with Visual Studio. But, I am not sure how to do it.

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

Re: Combining OCSP stapling with advance MITM preparation

[Brian Smith]

Kai Engert wrote:
> The domain owner
> could configure their server to include this OCSP response in all TLS
> handshakes, even though this OCSP response is unrelated to the server
> certificate actually being used.

For complete protection, the real domain holder would have to staple all the 
OCSP responses for all compromised certificates in every full SSL handshake it 
does, until those certificates expire.

How do you compare this with 
http://tools.ietf.org/html/draft-evans-palmer-key-pinning-00?

In that mechanism, the server staples information that "pins" the public key of 
the cert such that certs with different public keys will automatically be 
dis-trusted by the browser.

The Evens/Palmer pinning mechanism has an advantage in that it protects against 
mis-issued certs before the issuing CA or the domain owner even learns about 
them.

The Mozilla security team is already planning to implement the Evens/Palmer 
mechanism in Firefox and Chrome has implemented it, AFAICT.

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

Re: Alternative for SGN_DecodeDigestInfo

[Brian Smith]

Robert Relyea wrote:
> Why are they linking with Freebl anyway? It's intended to be a
> private interface for softoken. It's a very good way to find
> yourself backed into a corner.

Right. This was a long time ago. You helped me add the J-PAKE implementation to 
Softoken after we discovered this problem.

- Brian
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Alternative for SGN_DecodeDigestInfo

[Brian Smith]

Robert Relyea wrote:
> On 03/24/2012 03:05 PM, VJ wrote:
> > I'm trying to use RSA_HashCheckSign() function to verify the
> > message.
> How are you even Linking with RSA_HashCheckSign()?

I don't know what platform JV is on, but I know on Mac OS X, all the internal 
symbols in FreeBL and maybe other libraries are exported. This is how the 
Firefox Sync developers got so far in developing their JavaScript 
implementation of J-PAKE based on FreeBL's internal math library; they did all 
their development and testing on Mac OS X and when they were done, they were 
surprised to find they were using functions that you can't even reference on 
Windows (and Linux?).

I am not sure if there is something we can do about this problem for Mac OS X.

- Brian
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: To NSS-Java or not to NSS-Java, thats the question.

[Brian Smith]

helpcrypto helpcrypto wrote:
> IMHO, this is some that needs some clarification, as Mozilla *IS*
> supporting it developing JSS but at the same time saying "we do not
> support it", 

Some people who are part of the Mozilla project maintain JSS. I will help 
review patches to JSS if/when the members of the NSS team that want to continue 
supporting JSS ask me to. That is as much enthusiasm for JSS as you are likely 
to get from Mozilla employees.

> and other options dont work properly due to some bugs
> that need to be fixed...or not. Google Chrome works well and is
> taking some advantage on this feature (too).

Google Chrome is exposing NSS to Java/JSS on Mac OS X? I did not think that 
Chrome uses the NSS certificate database at all on Mac OS X.

> -Does mozilla *WANT* Java use certificates stored on NSS to do
> document signning?
> -What about Java applets?
> -Is mozilla going to *AVOID* Java use certificates, or consider this
> as an "undocumented/undesired behaviour"?
> -What about Java applets?

We already expose window.crypto.signText which supposedly will sign documents 
using certificates stored in NSS on all *desktop* Firefox versions. This should 
be accessible from Java via the Java-JS bridge that I know nothing about.

> -Supporting this (or document sign with XAdES or any other advanced
> systems) is one of mozilla's targets?

In Firefox and Thunderbird? No.

> -Will patches which fix this issues merged (if correct) in branch, or
> will they become marked as WONTFIX?

It depends on whether the bug is in JSS, NSS, Gecko, and what exactly the bug 
is, and how complex the patch is. If you provide more details of what doesn't 
work, we can discuss whether it is reasonable to try to fix it.

> We dont want to rely on "undocumented/undesired" behaviour, and will
> like to discuss whats the "official opinion" on this.

I cannot tell you an official opinion but I would say that I personally would 
not bet any money on depending on Java + NSS integration to work reliably in 
Firefox, because that would be a very low priority for most Gecko developers.

> Consider the following example:
> Signning a document with XAdES format with a certificate stored
> on NSS.
> Can it be done? 

I am not sure.

> How should it be done?

I am not sure how to solve whatever problems you are having in the short term.

In the long term:

1. Write patches that replace the usage of NSS in Firefox with usage of the 
system certificate store for client certificates.
2. Help specify and develop the DOMCrypt JS API in Firefox, including 
integration of DOMCrypt with the system certificate store.
3. Rewrite the applet in JS. If you can't, then have your Java application use 
the JS<->Java API we have to use the DOMCrypt JS API to sign your documents.

I noticed that you seem to be considering reading the NSS keyX.db and certX.db 
files from Java directly. Keep in mind that it is not supported to access these 
files directly, that these files may change format at any time (e.g. Red Hat 
would like Firefox and Thunderbird to switch to the SQLite-based format), and 
that hopefully Firefox and Thunderbird will eventually stop using these NSS 
certificate databases completely except on Linux. None of those things will 
happen any time soon, but I expect them all to happen eventually.

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

Re: Recent builds of NSS on Windows?

[Brian Smith]

> Today, a buggy old/legacy modutil.exe binary we are using, made me
> try building NSS using mingw. Once again.

The only way I recommend building NSS on Windows is with Microsoft Visual C++ 
and the mozilla-build package located at 
https://developer.mozilla.org/en/Windows_Build_Prerequisites#MozillaBuild_.2F_Pymake

Looking at your errors, it seems like the problem is a general problem with the 
MinGW/MSYS configuration itself, and not a problem specific to NSS. In my 
experience, more than a year ago, getting a correct GCC-based toolchain working 
in MSYS/MinGW (not just for building NSS, but in general) that isn't using an 
ancient version of GCC has been impractically difficult. 

See https://bugzilla.mozilla.org/show_bug.cgi?id=570340 where there is a 
MinGW/MSYS/GCC user trying to build NSS. If you are not him, then he might be 
more helpful than I.

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