Proposal: TLS library for Servo

[Diane Hosfelt]

Servo has been using the cryptographic library, OpenSSL (via the Hyper
library) for securing communications. As the project transitions to
shipping nightly builds and hopefully products, we need to make a more
explicit decision about our library usage. As a web browser, there’s a high
standard to meet, resulting in requirements that are possibly stricter than
those of other projects.

Requirements

-

Production ready library, opportunities for auditing and reviewing
-

Actively maintained, up to date on current state of the art, implements
all common algorithms used on the web
-

Full CVE/disclosure plan in place: In order to be a fully-fledged
browser engine, we will need to have the ability to report and fix critical
vulnerabilities
-

PKI support: PKI forms the backbone of trust on the Internet, and it’s
essential that we fully support certificate verification.


Options

1.

Continue to use existing OpenSSL bindings
2.

Contribute to a new or existing library in Rust
3.

Create bindings to another existing library


Option 1:

This is our current solution. While trying to distribute nightlies, the
team discovered that the Rust bindings for OpenSSL need some work1.
Additionally, many projects are moving away from OpenSSL; for example, when
Google2 and OpenBSD forked OpenSSL into BoringSSL3 and LibreSSL4, one
motivation was to create a leaner codebase.

It will take some work to enhance and broaden these bindings. Another
concern for Servo is the difficulty of multi-threading with OpenSSL. It’s
not thread safe by default, and requires callbacks to lock and unlock an
array of locks5.

Option 2:

There's interesting work going on in the Rust crypto ecosystem, and it's
worth keeping an eye on. For the time being, Servo needs production-ready
libraries. At least for now, building crypto infrastructure is out of scope
for the team. But we should keep our options open for the future, and see
if there are ways we can support these efforts.

Option 3:

A third option is to create Rust bindings for a currently existing SSL
library. Some options I investigated were BoringSSL6, LibreSSL, or NSS. A
significant con is that we don’t have significant expertise in either
LibreSSL or BoringSSL, or the resources to devote towards developing it.

Furthermore, BoringSSL is explicitly not recommended7 for general use
because there are no guarantees of API/ABI stability.

NSS is the current library used to secure Firefox, so using it in Servo is
mutually beneficial to both projects. Additionally, we have access to
significant NSS expertise, and NSS is committed to providing stable API and
ABI. API stability will allow Servo to more easily upgrade versions and
stay current with security patches, while reducing our maintenance
overhead. ABI stability will allow Servo to distribute security fixes to
the DLL in the wild without recompiling the executable.

Proposed Development

I propose to create Rust bindings for NSS, which is the crypto library used
to secure Firefox. Not only does it fulfill all of Servo’s requirements,
but it already has support for future work like TLS 1.3. I also propose
that we create bindings for Mozilla:pkix8 for certificate validation. I
spoke to the NSS team to see if they would be able to support an effort
like this, and they were interested in helping. This is a practical way to
get trusted, tested crypto into Servo and the wider Rust community.

For more information on these discussions, you can see the current Rust
security projects (http://libs.rs/cryptography/) and a discussion of
cryptographic development in Rust (
https://internals.rust-lang.org/t/why-is-a-trusted-feature-complete-crypto-library-not-a-top-priority-for-the-rust-community/3125
).


I'd like to hear your comments about this proposal here (or privately). I
know that this is an area that a lot of people are interested in, and it's
important that we do it right.


*TL;DR *Servo needs to make an explicit decision about how to do TLS, and I
think we should use NSS.


Thanks!

-Diane | avadacatavra


*References:*

1. https://github.com/servo/servo/issues/12015

2. Google's comparison of OpenSSL and NSS
<https://docs.google.com/document/d/1ML11ZyyMpnAr6clIAwWrXD53pQgNR-DppMYwt9XvE6s/edit?usp=sharing>

3. BoringSSL took OpenSSL from 468k lines of code to 200k, even with adding
additional tests

4. LibreSSL initially removed over 90k lines of code

5. https://www.openssl.org/docs/man1.0.2/crypto/threads.html

6. https://www.imperialviolet.org/2015/10/17/boringssl.html

7. https://boringssl.googlesource.com/boringssl/

8.
https://blog.mozilla.org/security/2014/04/24/exciting-updates-to-certificate-verification-in-gecko/

[Dirkjan Ochtman]

Hi Diane,

Thank you for bringing this discussion into the open.

On Fri, Aug 26, 2016 at 2:13 AM, Diane Hosfelt <dhos...@mozilla.com> wrote:
> This is our current solution. While trying to distribute nightlies, the
> team discovered that the Rust bindings for OpenSSL need some work1.
> Additionally, many projects are moving away from OpenSSL; for example, when
> Google2 and OpenBSD forked OpenSSL into BoringSSL3 and LibreSSL4, one
> motivation was to create a leaner codebase.
>
> It will take some work to enhance and broaden these bindings. Another
> concern for Servo is the difficulty of multi-threading with OpenSSL. It’s
> not thread safe by default, and requires callbacks to lock and unlock an
> array of locks5.

Another concern is that rust-openssl will need a bunch of work to be
able to work with the new OpenSSL 1.1.0 APIs.

> There's interesting work going on in the Rust crypto ecosystem, and it's
> worth keeping an eye on. For the time being, Servo needs production-ready
> libraries. At least for now, building crypto infrastructure is out of scope
> for the team. But we should keep our options open for the future, and see
> if there are ways we can support these efforts.

As I understand it, Servo is also a research project designed in part
to validate the capabilities of the Rust language for the kinds of
needs a browser has. It seems to me that the safety guarantees and
general ergonomics that Rust provides were designed in part to make it
significantly easier to build secure software. While that does not
mean that Servo should build its own crypto libraries, it seems more
sensible to me to adopt one of the Rust crypto stacks (provided it of
sufficiently high quality), and thus help validate Rust-for-crypto
while also supporting the development of crypto libraries for the Rust
ecosystem.

> Option 3:
>
> A third option is to create Rust bindings for a currently existing SSL
> library. Some options I investigated were BoringSSL6, LibreSSL, or NSS. A
> significant con is that we don’t have significant expertise in either
> LibreSSL or BoringSSL, or the resources to devote towards developing it.
>
> Furthermore, BoringSSL is explicitly not recommended7 for general use
> because there are no guarantees of API/ABI stability.
>
> NSS is the current library used to secure Firefox, so using it in Servo is
> mutually beneficial to both projects. Additionally, we have access to
> significant NSS expertise, and NSS is committed to providing stable API and
> ABI. API stability will allow Servo to more easily upgrade versions and
> stay current with security patches, while reducing our maintenance
> overhead. ABI stability will allow Servo to distribute security fixes to
> the DLL in the wild without recompiling the executable.

NSS also has a fairly bad security record, with 6 CVEs in 2015 and 4
in 2016 until now (with the most recent one fairly high-risk). This
does not yet include the necessarily immature Rust bindings that would
be provided on top of it. Also, most non-Mozilla projects seem to be
moving away from NSS.

> For more information on these discussions, you can see the current Rust
> security projects (http://libs.rs/cryptography/) and a discussion of
> cryptographic development in Rust (
> https://internals.rust-lang.org/t/why-is-a-trusted-feature-complete-crypto-library-not-a-top-priority-for-the-rust-community/3125
> ).

This discussion is fairly dated at this point.

> I'd like to hear your comments about this proposal here (or privately). I
> know that this is an area that a lot of people are interested in, and it's
> important that we do it right.

My counter-proposal is that Servo should use a TLS stack built on the
*ring* crypto library. *ring* is built around BoringSSL, and thus
inherits much of the well-audited low-level primitives that BoringSSL
provides (*ring* continues to merge the relevant BoringSSL work).
BoringSSL has a much better security track record than either NSS or
OpenSSL. *ring* is improving on this by moving as much as possible
into safe Rust. webpki is a Rust library by the same author as *ring*
(a former MoCo employee), which is implemented using the same design
as was used in the mozilla::pkix library used in Firefox. rustls is a
modern Rust TLS stack that builds on *ring* and webpki.

While rustls and the underlying libraries are immature compared to
core NSS (but not any Rust bindings for it), I'm not sure the level of
maturity NSS (and OpenSSL) have at this point should be considered a
good thing, given their respective security track records. Instead,
Servo should strive to support Rust-based crypto and TLS, so that the
security of Rust code can be validated and further improved.

Cheers,

Dirkjan

[etern...@gmail.com]

Replies inline.

On Thursday, August 25, 2016 at 5:14:22 PM UTC-7, Diane Hosfelt wrote:

<snip>

> Options
>
> 1.
>
> Continue to use existing OpenSSL bindings
> 2.
>
> Contribute to a new or existing library in Rust
> 3.
>
> Create bindings to another existing library

4. Use existing bindings to another existing library, enhance where necessary

An example here would be Telos[1], which binds to LibreSSL's new "libtls" API.

<snip>

> Proposed Development
>
> I propose to create Rust bindings for NSS, which is the crypto library used
> to secure Firefox. Not only does it fulfill all of Servo’s requirements,
> but it already has support for future work like TLS 1.3. I also propose
> that we create bindings for Mozilla:pkix8 for certificate validation. I
> spoke to the NSS team to see if they would be able to support an effort
> like this, and they were interested in helping. This is a practical way to
> get trusted, tested crypto into Servo and the wider Rust community.

There is also webpki[2] which is based on *ring*[3] and was written by Brian Smith, who also wrote a large fraction of mozilla::pkix[4]

<snip>

[1] https://crates.io/crates/telos
[2] https://crates.io/crates/webpki
[3] https://crates.io/crates/ring
[4] https://github.com/mozilla/gecko-dev/commits/master/security/pkix

[Gavin Sharp]

> NSS also has a fairly bad security record, with 6 CVEs in 2015 and 4
> in 2016 until now (with the most recent one fairly high-risk).

"number of CVEs over time" is a poor way to evaluate software
security, because the number of issues found is proportional not only
to code quality or development practices, but also to incentives to
find and disclose those issues, which is tied to how commonly the
software is used in practice. One could argue that more CVEs makes
commonly-used libraries *more* secure than untested developmental
libraries.

I don't have a strong opinion about what the right decision here is,
and see benefits to both options. But concluding that "NSS has a bad
security record", based solely on the reasoning quoted above, is not a
strong argument.

Gavin

> _______________________________________________
> dev-servo mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo

[Brian Anderson]

Fun topic! Rust crypto is super important. My perspective on this is from
someone who wants the greatest benefits for Rust. Whatever the decision I
hope you enjoy hacking on Servo.

On Thu, Aug 25, 2016 at 5:13 PM, Diane Hosfelt <dhos...@mozilla.com> wrote:

> Servo has been using the cryptographic library, OpenSSL (via the Hyper
> library) for securing communications. As the project transitions to
> shipping nightly builds and hopefully products, we need to make a more
> explicit decision about our library usage. As a web browser, there’s a high
> standard to meet, resulting in requirements that are possibly stricter than
> those of other projects.
>
> Requirements
>
> -
>
> Production ready library, opportunities for auditing and reviewing
> -
>
> Actively maintained, up to date on current state of the art, implements
> all common algorithms used on the web
> -
>
> Full CVE/disclosure plan in place: In order to be a fully-fledged
> browser engine, we will need to have the ability to report and fix
> critical
> vulnerabilities
> -
>
> PKI support: PKI forms the backbone of trust on the Internet, and it’s
> essential that we fully support certificate verification.
>

Not all of these may be near-term requirements, though for full
productization they look important. Particularly with the current focus on
upstreaming Servo tech into Firefox, Servo has more freedom to do research
and less pressure to deliver a fully-compatible stack. Still, they all look
reasonable and I think could be accomplished with any of the potential
approaches, with more or less effort and time.

>
>
> Options
>
> 1.
>
> Continue to use existing OpenSSL bindings
> 2.
>
> Contribute to a new or existing library in Rust
> 3.
>
> Create bindings to another existing library
>
>

> Option 1:

>
> This is our current solution. While trying to distribute nightlies, the
> team discovered that the Rust bindings for OpenSSL need some work1.
> Additionally, many projects are moving away from OpenSSL; for example, when
> Google2 and OpenBSD forked OpenSSL into BoringSSL3 and LibreSSL4, one
> motivation was to create a leaner codebase.
>
> It will take some work to enhance and broaden these bindings. Another
> concern for Servo is the difficulty of multi-threading with OpenSSL. It’s
> not thread safe by default, and requires callbacks to lock and unlock an
> array of locks5.
>

> Option 2:

>
> There's interesting work going on in the Rust crypto ecosystem, and it's
> worth keeping an eye on. For the time being, Servo needs production-ready
> libraries. At least for now, building crypto infrastructure is out of scope
> for the team. But we should keep our options open for the future, and see
> if there are ways we can support these efforts.
>

There are many benefits to this approach. Advancing Rust crypto is
perennially a high-priority strategic nice-to-have in Rust, but so far we
have not been able to find the right motivation to put weight behind it.
Any time there is a glimmer of opportunity for Mozilla to accelerate Rust
crypto we should try our hardest to take it. It is notable that we have not
done so yet. Rust is probably, if not obviously, one of the best platforms
there is for cryptographic and security software, and delivering a
high-quality solution would generate widespread attention and goodwill for
Mozilla, and have compounding effects for the entire Rust ecosystem.

Porting Servo to NSS has less significant benefits. As I understand it the
biggest concern with using experimental crypto in Servo is that the more
users Servo has the greater risk there is from a serious security flaw.
This is of course an important concern, but it's not clearly outweighed by
the benefits of pursuing Rust-oriented security research. There may be
mitigation strategies that would allow Servo to pursue a Rust solution
while protecting itself from a high-profile security disaster.

Making high-quality NSS bindings available to the greater Rust community
would be valuable, but less valuable I think than one might expect. Today
the Rust ecosystem generally uses OpenSSL and the biggest practical problem
with that is build complexity. Any time one has to bail out of Rust to C or
any other language the portability of your build tanks, and Rust aims to be
highly portable. OpenSSL is a big offender, particularly in that it's not
simple to build on Mac and Windows. I don't know that NSS is better or
worse in this regard, but as a general principle it's better for Rust
projects to be written in Rust. Because of this issue the direction TLS
support is going for general Rust code ISTM is to defer to the platform's
TLS stack where appropriate, particularly on Mac and Windows [1]. This
isn't appropriate for a web browser, but for general Rust software is a
great simplification. This calculus might change with a pure-Rust TLS
stack, or if a hybrid Rust/C/C++ TLS stack becomes so simple that it just
works everywhere rustc does.

[1]: https://github.com/sfackler/rust-native-tls

> Option 3:
>
> A third option is to create Rust bindings for a currently existing SSL
> library. Some options I investigated were BoringSSL6, LibreSSL, or NSS. A
> significant con is that we don’t have significant expertise in either
> LibreSSL or BoringSSL, or the resources to devote towards developing it.
>
> Furthermore, BoringSSL is explicitly not recommended7 for general use
> because there are no guarantees of API/ABI stability.
>
> NSS is the current library used to secure Firefox, so using it in Servo is
> mutually beneficial to both projects. Additionally, we have access to
> significant NSS expertise, and NSS is committed to providing stable API and
> ABI. API stability will allow Servo to more easily upgrade versions and
> stay current with security patches, while reducing our maintenance
> overhead. ABI stability will allow Servo to distribute security fixes to
> the DLL in the wild without recompiling the executable.
>

Of these, I think the reduced maintenance burden on Servo is the most
compelling. I don't see that this approach it has mutual benefits though.
How would using NSS in Servo benefit Firefox?

ABI stability isn't a clear need for Servo. Distributing security fixes via
DLL isn't obviously important for Servo, particularly in the near term.

>
> Proposed Development
>
> I propose to create Rust bindings for NSS, which is the crypto library used
> to secure Firefox. Not only does it fulfill all of Servo’s requirements,
> but it already has support for future work like TLS 1.3. I also propose
> that we create bindings for Mozilla:pkix8 for certificate validation. I
> spoke to the NSS team to see if they would be able to support an effort
> like this, and they were interested in helping. This is a practical way to
> get trusted, tested crypto into Servo and the wider Rust community.
>

> For more information on these discussions, you can see the current Rust
> security projects (http://libs.rs/cryptography/) and a discussion of
> cryptographic development in Rust (
> https://internals.rust-lang.org/t/why-is-a-trusted-
> feature-complete-crypto-library-not-a-top-priority-
> for-the-rust-community/3125
> ).
>
>

> I'd like to hear your comments about this proposal here (or privately). I
> know that this is an area that a lot of people are interested in, and it's
> important that we do it right.
>
>

> *TL;DR *Servo needs to make an explicit decision about how to do TLS, and I
> think we should use NSS.
>
>
> Thanks!
>
> -Diane | avadacatavra
>
>
> *References:*
>
> 1. https://github.com/servo/servo/issues/12015
>
> 2. Google's comparison of OpenSSL and NSS
> <https://docs.google.com/document/d/1ML11ZyyMpnAr6clIAwWrXD53pQgNR
> -DppMYwt9XvE6s/edit?usp=sharing>
>
> 3. BoringSSL took OpenSSL from 468k lines of code to 200k, even with adding
> additional tests
>
> 4. LibreSSL initially removed over 90k lines of code
>
> 5. https://www.openssl.org/docs/man1.0.2/crypto/threads.html
>
> 6. https://www.imperialviolet.org/2015/10/17/boringssl.html
>
> 7. https://boringssl.googlesource.com/boringssl/
>
> 8.
> https://blog.mozilla.org/security/2014/04/24/exciting-
> updates-to-certificate-verification-in-gecko/

[Patrick Walton]

First of all, thanks for putting this together!

I'm in agreement with Brian that *ring* and rustls seem like the way to go
first. Second, I would suggest rust-native-tls as a backup if it doesn't
work out.

*ring* *is* BoringSSL -- at least the crypto primitives from it -- wrapped
into a nice Rust library. rustls uses *ring* to provide a TLS
implementation that seems fairly complete. The main thing that rustls is
missing seems to be support for older TLS versions; it looks like modern
TLS (albeit not 1.3) works just fine. rustls has quite a bit of community
interest--if I had to place a bet on the long-term solution that the Rust
ecosystem will stabilize on, it'd be that library. Most importantly, I have
confidence in the maintainers of *ring* and rustls to provide a
well-mainted secure solution going forward.

rust-native-tls seems like a good conservative backup option. Steven
Fackler has done a lot of work on it and is committed to maintaining it
going forward. Using the native TLS bindings is not obviously a bad idea
for browsers: Chromium used to do it before switching to BoringSSL.

Fundamentally, I think that we shouldn't underestimate the amount of effort
it'll take to write and maintain idiomatic Rust bindings to a TLS library
ourselves. Rust isn't C or C++: the fact that Rust has an excellent FFI
doesn't negate the fact that using a C library in practice isn't as simple
as just importing it. There's a lot of value in leveraging existing
community bindings to libraries.

Finally, I don't see any particular reason why Servo using NSS would help
Gecko. As far as I can tell, the potential things that could help NSS'
development are (1) more users, to shake out bugs, and (2) demand for new
features. Servo has essentially zero userbase at this time, so it won't
help with (1). And to my knowledge we aren't planning on using any new TLS
features in Servo that Gecko doesn't use, so (2) isn't applicable either.

Again, thanks for putting all of this together and starting the discussion!

Patrick

On Fri, Aug 26, 2016 at 7:11 AM, Brian Anderson <band...@mozilla.com>
wrote:

[Jack Moffitt]

> I'm in agreement with Brian that *ring* and rustls seem like the way to go
> first. Second, I would suggest rust-native-tls as a backup if it doesn't
> work out.

rusttls doesn't seem to support TLS 1.1, which seems like a
non-starter. We'll probably want to dig up some data on how much of
the web relies on that.

libwebpkix does not yet support revocation checking.

I believe this is what was meant by suggesting we follow these
projects' progress and adapt our decisions along the way.

> Fundamentally, I think that we shouldn't underestimate the amount of effort
> it'll take to write and maintain idiomatic Rust bindings to a TLS library
> ourselves. Rust isn't C or C++: the fact that Rust has an excellent FFI
> doesn't negate the fact that using a C library in practice isn't as simple
> as just importing it. There's a lot of value in leveraging existing
> community bindings to libraries.

The NSS team has offered their help to create the bindings and
maintain and host them in tree.

No solution here involves zero work for us, but using NSS seems to
involve the least work aside from doing nothing.

> Finally, I don't see any particular reason why Servo using NSS would help
> Gecko.

I don't think this was part of the requirements. As you stated there
are some mild benefits for NSS exposure with that option, but none of
the options presented benefit Gecko very much.

jack.

[Brian Anderson]

Hi Jack <3

On Fri, Aug 26, 2016 at 10:29 AM, Jack Moffitt <ja...@metajack.im> wrote:

> > I'm in agreement with Brian that *ring* and rustls seem like the way to
> go
> > first. Second, I would suggest rust-native-tls as a backup if it doesn't
> > work out.
>
> rusttls doesn't seem to support TLS 1.1, which seems like a
> non-starter. We'll probably want to dig up some data on how much of
> the web relies on that.
>

Perhaps it can be made to do so.

>
> libwebpkix does not yet support revocation checking.
>

As part of integration into Servo, implementing this would be a good
contribution to the Rust ecosystem.

>
> I believe this is what was meant by suggesting we follow these
> projects' progress and adapt our decisions along the way.
>
> > Fundamentally, I think that we shouldn't underestimate the amount of
> effort
> > it'll take to write and maintain idiomatic Rust bindings to a TLS library
> > ourselves. Rust isn't C or C++: the fact that Rust has an excellent FFI
> > doesn't negate the fact that using a C library in practice isn't as
> simple
> > as just importing it. There's a lot of value in leveraging existing
> > community bindings to libraries.
>
> The NSS team has offered their help to create the bindings and
> maintain and host them in tree.
>

Dos that mean that NSS is the only solution that will result in work being
done here? What are the consequences of sticking with the status quo of
OpenSSL until a Rust-based solution matures?

>
> No solution here involves zero work for us, but using NSS seems to
> involve the least work aside from doing nothing.
>
> > Finally, I don't see any particular reason why Servo using NSS would help
> > Gecko.
>
> I don't think this was part of the requirements. As you stated there
> are some mild benefits for NSS exposure with that option, but none of
> the options presented benefit Gecko very much.
>

While we're still on requirements I might bring up a few potential
requirements that haven't been explicitly mentioned:

- Seed the Rust community with production-grade Rust code. Servo is
explicitly architected to serve this purpose and many of the Servo
components Firefox is excited about now have reaped reciprocal benefits
from this model.

- Act as a halo project for Rust. Servo showcases off all the best facets
of Rust, things that no other language can achieve. The TLS stack is
another opportunity to add a feather to Servo's cap.

- Do research. Servo is a project of the research group and there are
opportunities here to advance the state of the art.

This probably sounds a bit cheeky, but they are important things to remind
ourselves as Servo grows and the demands on it increase.

While I still have the mic I'll make an argument in favor of NSS in Servo:
if there is a goal to move Servo's network stack into Firefox in the
near/medium term, then that is strong reason to give Firefox's requirements
weight over Rust's.

<3






>
> jack.

[Patrick Walton]

> rusttls doesn't seem to support TLS 1.1, which seems like a
non-starter. We'll probably want to dig up some data on how much of
> the web relies on that.

> libwebpkix does not yet support revocation checking.

They don't support those things now, but will they support them on Servo's
timeframe?

> I believe this is what was meant by suggesting we follow these
projects' progress and adapt our decisions along the way.

If this means "start on NSS bindings now and then (consider) switching over
once the native Rust solutions are Web compatible", then I think we should
carefully consider the downsides to this. We risk doing a lot of work that
will just be thrown away later, as well as the technical debt that comes
with ripping out old dependencies and replacing them with new ones. "The
native Rust solutions don't support X and Y" are not necessarily slam-dunk
arguments to work on alternatives; it may be less work to just implement X
and Y in those projects.

>
No solution here involves zero work for us, but using NSS seems to
involve the least work aside from doing nothing.

That may be true as far as rusttls/libwebpki are concerned (though I'm not
convinced), but it doesn't seem to be true for rust-native-tls.

> I don't think this was part of the requirements. As you stated there
> are some mild benefits for NSS exposure with that option, but none of
> the options presented benefit Gecko very much.

Yeah, I should have said "Firefox" or "the NSS project" instead of Gecko.
The same arguments apply.

Patrick

On Fri, Aug 26, 2016 at 10:29 AM, Jack Moffitt <ja...@metajack.im> wrote:

> > I'm in agreement with Brian that *ring* and rustls seem like the way to
> go
> > first. Second, I would suggest rust-native-tls as a backup if it doesn't
> > work out.
>
> rusttls doesn't seem to support TLS 1.1, which seems like a
> non-starter. We'll probably want to dig up some data on how much of
> the web relies on that.
>

> libwebpkix does not yet support revocation checking.
>

> I believe this is what was meant by suggesting we follow these
> projects' progress and adapt our decisions along the way.
>
> > Fundamentally, I think that we shouldn't underestimate the amount of
> effort
> > it'll take to write and maintain idiomatic Rust bindings to a TLS library
> > ourselves. Rust isn't C or C++: the fact that Rust has an excellent FFI
> > doesn't negate the fact that using a C library in practice isn't as
> simple
> > as just importing it. There's a lot of value in leveraging existing
> > community bindings to libraries.
>
> The NSS team has offered their help to create the bindings and
> maintain and host them in tree.
>

> No solution here involves zero work for us, but using NSS seems to
> involve the least work aside from doing nothing.
>
> > Finally, I don't see any particular reason why Servo using NSS would help
> > Gecko.
>
> I don't think this was part of the requirements. As you stated there
> are some mild benefits for NSS exposure with that option, but none of
> the options presented benefit Gecko very much.
>

[Josh Matthews]

On 2016-08-26 2:03 PM, Brian Anderson wrote:
> While I still have the mic I'll make an argument in favor of NSS in Servo:
> if there is a goal to move Servo's network stack into Firefox in the
> near/medium term, then that is strong reason to give Firefox's requirements
> weight over Rust's.

I'm not aware of any such goal, especially in near/medium term. Our
network stack is lightyears behind Gecko's, and doesn't contain any
compelling new results/architecture to motivate such a goal at present.

[Michael Howell]

So, got any good research papers on networking?

On Fri, Aug 26, 2016, 12:06 PM Josh Matthews <jo...@joshmatthews.net> wrote:

> On 2016-08-26 2:03 PM, Brian Anderson wrote:

> > While I still have the mic I'll make an argument in favor of NSS in
> Servo:
> > if there is a goal to move Servo's network stack into Firefox in the
> > near/medium term, then that is strong reason to give Firefox's
> requirements
> > weight over Rust's.
>

> I'm not aware of any such goal, especially in near/medium term. Our
> network stack is lightyears behind Gecko's, and doesn't contain any
> compelling new results/architecture to motivate such a goal at present.
>

[Michael Howell]

So, got any good research papers on networking?

On Fri, Aug 26, 2016, 12:06 PM Josh Matthews <jo...@joshmatthews.net> wrote:

> On 2016-08-26 2:03 PM, Brian Anderson wrote:

> > While I still have the mic I'll make an argument in favor of NSS in
> Servo:
> > if there is a goal to move Servo's network stack into Firefox in the
> > near/medium term, then that is strong reason to give Firefox's
> requirements
> > weight over Rust's.
>

> I'm not aware of any such goal, especially in near/medium term. Our
> network stack is lightyears behind Gecko's, and doesn't contain any
> compelling new results/architecture to motivate such a goal at present.
>

[Jack Moffitt]

> So, got any good research papers on networking?

My undestanding is that I/O is the bottleneck for networking, not the
CPU. So research here tends to focus on elimination of network
requests, optimizations to solve overhead (pipelining, keepalive),
more efficient protocols, or better data compression.

I believe the existing browsers have the latest practical versions of
all of these things. I'm sure many improvements can be made, but we
haven't got a ready made list of avenues to explore as we did with
parallelizing previously sequential things.

jack.

[Jack Moffitt]

[Brian Smith]

Patrick Walton wrote:
> *ring* *is* BoringSSL -- at least the crypto primitives from it --
> wrapped into a nice Rust library.

Originally, *ring* could accurately be described as a subset of
BoringSSL. Then it became a subset of BoringSSL wrapped in Rust. Since
then we've replaced a lot of the C code in BoringSSL with Rust code,
and we've made many improvements to the C code beyond what I've been
able to contribute to BoringSSL. Consequently, saying that *ring* is
BoringSSL is actually short-changing *ring* because we've improved
upon BoringSSL in several areas. In particular, a lot of important
crypto stuff is already done in Rust in *ring* and we're using
improved techniques that haven't been adopted in BoringSSL, OpenSSL,
or NSS yet. (Note: I'm sure that you don't mean to short-change
*ring*; my point is that we shouldn't be questioning how much worse
*ring* is than alternatives, but rather questioning how much better it
is, which is probably surprising to many people.)

But also saying *ring* is BoringSSL doesn't given enough credit to the
BoringSSL team for the stuff that they've improved that wasn't needed
in *ring*. For example, they implemented SPAKE2 and NewHope and TLS
1.3, none of which are included in *ring*. And Google has done an
absolutely incredible job with testing BoringSSL that is way too easy
to under-appreciate. The *ring* project is lucky to build upon all of
that. I think both teams are doing a great job in different ways.

Regarding mozilla::pkix and webpki: I am proud of the work that David
Keeler, Camilo Viecco, and I did on mozilla::pkix. I actually tried to
create Rust bindings for mozilla::pkix, but I found it was easier to
create the pure-Rust webpki instead. Based on my experience, I predict
it would be a significant amount of work to create really usable
bindings for mozilla::pkix, and I doubt you'd like the resulting code
much if you did it.

I didn't include OCSP in webpki because I had written the OCSP code at
Mozilla and so Mozilla Corp. has the copyright on it, so I couldn't
port it to Rust with the better license that webpki has. In contrast,
I own the copyright on most other parts of mozilla::pkix that were
useful for creating webpki, because I wrote them after leaving
Mozilla; this greatly sped up the creation of webpki because I didn't
have to take the "clean room" approach I had to take for some other
parts. If Mozilla were to contribute the existing C++ OCSP code from
mozilla::pkix to the webpki project under the webpki license, this
would greatly speed up the addition of OCSP support to webpki.

I have some plans for how to support the bad crypto in TLS 1.0 and TLS
1.1 in a way that doesn't put other users of *ring* at risk of
misusing them. That's something that's better discussed privately for
now, as there's non-technical factors to consider. Note that Rustls is
Joseph Birr-Pixton's project, and so even if I were to somehow support
the bad crypto that TLS 1.0 and TLS 1.1 require, Rustls may choose not
to do so.

If a major goal of the Servo project is still research into how Rust
and Rust-like languages can improve the current sad and dangerous
state of software, then I think it's clear that Servo should prefer to
use libraries that are are in line with that goal. I think *ring* and
webpki and Rustls are good examples of such libraries. *ring* is
interesting because it shows how to evolve a pure C + asm library into
what will become something close to a Pure Rust + asm library
incrementally. webpki is interesting because it shows how to do a
from-scratch rewrite of an existing library. Rustls is interesting
because it shows how to create a from-scratch security-oriented
library. And, of course, they all provide incredibly useful
functionality and are all written in modern, security-first mindset,
beyond being good examples to learn from. Further, as we move more of
the *ring* functionality into Rust we push the limits of Rust, which
will help Rust improve, which benefits not just *ring*, but many other
Rust-based projects.

Cheers,
Brian
--
https://briansmith.org/

[Brian Smith]

On Fri, Aug 26, 2016 at 1:59 PM, Brian Smith <br...@briansmith.org> wrote:
> I am proud of the work that David Keeler, Camilo Viecco, and I
> did on mozilla::pkix.

Sorry to reply to my own post. I just wanted to point out two things:
Matt Wobensmith, the QA person that we worked with on mozilla::pkix,
was a major factor for its success. Also, most of the code that
*isn't* being replaced with Rust code in *ring* is actually OpenSSL's
asm code; regardless of what gets rewritten or improved in *ring*, it
wouldn't exist at all if not for OpenSSL.

[Gervase Markham]

On 26/08/16 15:11, Brian Anderson wrote:
> There are many benefits to this approach. Advancing Rust crypto is
> perennially a high-priority strategic nice-to-have in Rust, but so far we
> have not been able to find the right motivation to put weight behind it.
> Any time there is a glimmer of opportunity for Mozilla to accelerate Rust
> crypto we should try our hardest to take it. It is notable that we have not
> done so yet. Rust is probably, if not obviously, one of the best platforms
> there is for cryptographic and security software, and delivering a
> high-quality solution would generate widespread attention and goodwill for
> Mozilla, and have compounding effects for the entire Rust ecosystem.

To reinforce this a small amount: another thing Mozilla is doing is
Secure Open Source, a fund for helping open source projects be more
secure. At the moment, it's focussed on providing source code audits and
fixing the immediate bugs, but we hope to expand the scope in 2017. One
of the things we are looking at is how Rust can feature in that wider scope.

I personally think that the existence of a fully-Rust modern TLS stack
(usable in otherwise-C applications) would be a very good thing for the
world, and entirely consonant with Mozilla's mission to make the web a
better and more secure place. We have identified this as something we'd
like to see, but it's too big a project for SOS Fund to take on at the
moment. However, while SOS Fund is not about funding Mozilla's
priorities, Servo moving in this direction might well encourage us to
put our shoulder to the wheel as well in some way.

Gerv

[adel...@gmail.com]

Hi,
just want to point that using independent Rust libraries may be good to avoid problems like this: https://github.com/sfackler/rust-openssl/issues/255

Adelar

[Diane Hosfelt]

Hi all--

Thanks for everyone’s comments about this—I think the discussion has been really illuminating.

Right now, what I’m working on is updating some TLS statistics using https://github.com/mozilla/cipherscan <https://github.com/mozilla/cipherscan> (it’s taking a bit longer than I’d originally anticipated). Based on my current results (~50k sites), over 7% can only use TLS1 or lower. This means that, at a minimum, rustls would need need to implement TLS1 and 1.1 in addition to 1.2 (and eventually 1.3) in order for Servo to use it. I’m not quite sure what the bar should be for deciding that it’s okay to not support legacy protocols, but I definitely think that 7% is too high. In my opinion, web compatibility should be a goal of Servo.

I’d also like to draw a distinction between ring and rustls (or any other Rust TLS implementation) . As far as I’m aware, ring implements cryptographic primitives, but not cryptographic protocols. The protocols can then be built on top of ring, as is the case with rustls. For what it’s worth, I think that this is the right design approach. Rustls is brand new and is explicitly not feature-complete enough for web compatibility. It’s a noble goal to only want to implement ‘good’ crypto, but it’s not very practical.

I get really excited about Rust crypto. Personally, I think that Rust is a great language for implementing crypto, and I think that there will be a place in Servo for it. However, the way that I’ve looked at Servo is as a “practical” research project—yes, it's doing cutting edge research, but it also should work well and securely for web browsing (maybe embedded applications, etc). Because of this, I still think that it’s best to start with a wrapper of mainstream crypto.

One thing I’m also looking at is how it could be possible to make the Servo crypto library interchangeable via traitization (I might be making up words now). That way, people who want to use Rust crypto can do so, and people who would prefer a wrapper of a more established library can do that. Whatever Servo uses today doesn’t have to be the “final” decision (for whatever definition of final you prefer, I guess).

Regarding webpki—I don’t think I can disagree with Brian (since he’s definitely the expert). I also don’t know of any additional options other than webpki, so maybe adopting webpki is something that Servo should look into more.

Diane | avadacatavra

[Robert O'Callahan]

On Thu, Sep 1, 2016 at 12:57 PM, Diane Hosfelt <dhos...@mozilla.com> wrote:

> Right now, what I’m working on is updating some TLS statistics using
> https://github.com/mozilla/cipherscan <https://github.com/mozilla/
> cipherscan> (it’s taking a bit longer than I’d originally anticipated).
> Based on my current results (~50k sites), over 7% can only use TLS1 or
> lower. This means that, at a minimum, rustls would need need to implement
> TLS1 and 1.1 in addition to 1.2 (and eventually 1.3) in order for Servo to
> use it. I’m not quite sure what the bar should be for deciding that it’s
> okay to not support legacy protocols, but I definitely think that 7% is too
> high. In my opinion, web compatibility should be a goal of Servo.
>

FWIW, while I agree with that, I think it's important to get key
high-volume sites working well in Servo --- Facebook, GMail, Youtube,
Yahoo, Twitter, Amazon, etc --- before tackling the "long tail". I assume
the former do not require TLS < 1.2. That gives you plenty of time to add
TLS < 1.2 to rusttls.

One question I haven't seen asked or answered yet is whether the rusttls
maintainers would accept contributions to make it Web-compatible, and if
not, how one would maintain a Web-compatible version of it.

Rob
--
lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf
toD
selthor stor edna siewaoeodm or v sstvr esBa kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea
lurpr
.a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn

[Patrick Walton]

> In my opinion, web compatibility should be a goal of Servo.

I agree. However, it's worth noting that layout and DOM bugs and missing
functionality currently prevent far more than 7% of Web sites from working.
In these areas, it will take significant time to get to 90%+ Web
compatibility. (Granted, statistically it's more complicated than this
because some sites which Servo *can* run properly will be on older versions
of TLS, so our Web compatibility can regress—but I think that this doesn't
change the overall analysis.) So the more interesting question to me is
whether support for legacy protocols and ciphers (TLS 1.0/1.1, AES+CBC,
3DES+CBC?) will be present in the native Rust stack by the time layout and
DOM get up to speed.

As roc pointed out, this is likely to hinge on whether upstream rustls is
open to accepting support for these legacy features. Perhaps an
off-by-default Cargo feature might be a useful compromise between
upstream's (valid!) desire to provide safe defaults and the need to support
the Web as it exists today...

Patrick

On Wed, Aug 31, 2016 at 5:57 PM, Diane Hosfelt <dhos...@mozilla.com> wrote:

> Hi all--
>
> Thanks for everyone’s comments about this—I think the discussion has been
> really illuminating.
>

> Right now, what I’m working on is updating some TLS statistics using
> https://github.com/mozilla/cipherscan <https://github.com/mozilla/
> cipherscan> (it’s taking a bit longer than I’d originally anticipated).
> Based on my current results (~50k sites), over 7% can only use TLS1 or
> lower. This means that, at a minimum, rustls would need need to implement
> TLS1 and 1.1 in addition to 1.2 (and eventually 1.3) in order for Servo to
> use it. I’m not quite sure what the bar should be for deciding that it’s
> okay to not support legacy protocols, but I definitely think that 7% is too
> high. In my opinion, web compatibility should be a goal of Servo.
>

[Jack Moffitt]

> One thing I’m also looking at is how it could be possible to make the Servo crypto library interchangeable via traitization (I might be making up words now). That way, people who want to use Rust crypto can do so, and people who would prefer a wrapper of a more established library can do that. Whatever Servo uses today doesn’t have to be the “final” decision (for whatever definition of final you prefer, I guess).

Since we currently use OpenSSL via hyper, this means the trait would
be used there. I assume we'll also need a trait for the pki parts (and
those are in Servo I think).

With that boundary we could replace OpenSSL with NSS and then add
others as they come online. The main complication of multiple options
is QA. If we don't run them through CI they are likely to bitrot
quickly.

> Regarding webpki—I don’t think I can disagree with Brian (since he’s definitely the expert). I also don’t know of any additional options other than webpki, so maybe adopting webpki is something that Servo should look into more.

mozpkix was the proposal, which Brian is also an author of. Brian, why
exactly is mozpkix hard to wrap? Specific examples may help us
understand Rust / C++ limitations. If that library is hard enough to
wrap, then it might be less work to add whatever is needed to webpki.
However, wrapping a C++ lib and implementing functionality may require
quite different skillsets.

One reason I would like to see the NSS bindings is that other projects
in the Rust ecosystem may need more confidence in the crypto bits or
functionality not yet implemented. Not every project in Rust is as
pre-production as Servo. NSS bindings are also likely to be better
maintained than the existing OpenSSL stuff with support from upstream.

jack.

[Dirkjan Ochtman]

On Thu, Sep 1, 2016 at 10:43 PM, Jack Moffitt <ja...@metajack.im> wrote:
> One reason I would like to see the NSS bindings is that other projects
> in the Rust ecosystem may need more confidence in the crypto bits or
> functionality not yet implemented. Not every project in Rust is as
> pre-production as Servo. NSS bindings are also likely to be better
> maintained than the existing OpenSSL stuff with support from upstream.

You seem to have a lot of confidence in MoCo's ability to support a
project on its own, and very little confidence in the Rust ecosystem
to maintain its chosen solutions. It seems very unlikely that Rust
projects will move to NSS over OpenSSL or *ring* once bindings for NSS
are available and mature enough; you also seem to evaluate the current
state of rust-openssl and *ring*/rustls against some future where NSS
bindings exist, discounting any progress that the other projects will
make in the mean time.

It may be comfortable from a MoCo perspective to rely on MoCo
staff/funding, but this mostly feels like "no one ever got fired for
buying IBM". Wouldn't it be great if Mozilla and the Rust community
actually aligned to advance and mature Rust crypto?

Cheers,

Dirkjan

[Jack Moffitt]

> You seem to have a lot of confidence in MoCo's ability to support a
> project on its own, and very little confidence in the Rust ecosystem
> to maintain its chosen solutions. It seems very unlikely that Rust
> projects will move to NSS over OpenSSL or *ring* once bindings for NSS
> are available and mature enough; you also seem to evaluate the current
> state of rust-openssl and *ring*/rustls against some future where NSS
> bindings exist, discounting any progress that the other projects will

> make in the mean time..

The current openssl bindings are not good. Take a look at Servo's
openssl related bugs for some examples. As far as I know the Rust
community is not super interested in fixing this, or at least it
hasn't happened yet. With most of the big players abandoning openssl
in general, it is easy to see why this might be the case. The Servo
community could invest in these bindings, but if we're going to divert
resources, then the natural question to ask is how best to utilize
them.

NSS has been going strong for years powering both Chrome and Firefox
for years. Chrome has recently switched to BoringSSL. Unlike Boring
and other projects, it is very stable.

So yes, I have some confidence that NSS will continue to be maintained
and stay stable for some time, and very little of this is blind faith
in my employer.

If NSS bindings are more ergonomic, provide a better build experience,
and are well maintained, why wouldn't the Rust community use them over
the openssl bindings? You imply that the Rust community has chosen
openssl as the best solution somewhere, but I think the fact it has
been used so far is happenstance. Someone made openssl packages and
everyone else used those because they were there. The point of this
thread is to discuss the tradeoffs of different solutions.

One potential benefit of NSS is that it could fix the deficiencies of
the openssl solution that exists now in the Rust ecosystem. Another is
that products built in Rust that don't trust young crypto code have an
option that is well known. It's possible the Rust ecosystem will not
be attracted to NSS, and it's also possible that everyone will have no
trouble shipping rusttls.

I am not discounting the progress other projects may make, and I
sincerely hope to see pure Rust solutions for all parts of Servo some
day. However implementing crypto code and protocols is a lot more
difficult than writing bindings to an existing API, and it seems
reasonable to imagine that NSS bindings will be completed in a short
amount of time.

> It may be comfortable from a MoCo perspective to rely on MoCo
> staff/funding, but this mostly feels like "no one ever got fired for
> buying IBM". Wouldn't it be great if Mozilla and the Rust community
> actually aligned to advance and mature Rust crypto?

How are we not aligned here? Servo has existing issues with openssl
that we'd like to solve, and there are several possible solutions. The
proposal suggests we choose the one that seems most likely to be
available in the short term, and making sure that the work doesn't
preclude adopting a different solution down the road. On top of that,
Diane has been collecting data for feedback to rusttls, ring, and
webpki on what features we're waiting on. This is really no different
than any of the other situations we've been in where we've adopted
some non-Rust dependency (freetype and font-rs are perhaps a good
parallel, but without the unique trust component of crypto/protocols).

jack.

[Patrick Walton]

> The current openssl bindings are not good. Take a look at Servo's
openssl related bugs for some examples. As far as I know the Rust
community is not super interested in fixing this, or at least it
hasn't happened yet. With most of the big players abandoning openssl
in general, it is easy to see why this might be the case.

If this is true, then I suspect the reason is that the Rust community is
more interested in putting effort into the native Rust crypto stack:
*ring*, libwebpki, and rustls.

The availability of high-quality NSS bindings is not likely to change the
general desire of the Rust community to focus on the native Rust stack.
That's because practical crypto is an area that plays to Rust's strengths
as a language.

I concur with Dirkjan that it's likely that we will be one of the few Rust
users of NSS if we go down this route, and we may be effectively isolating
ourselves from the rest of the community.

Patrick

[Brian Anderson]

There are two things I can think of that are barriers to adoption as a
general rust solution: the mpl, and build complexity.

All critical components of the rust stack have a permissive license, but
nss is mpl. I don't see myself supporting nss as the default rust TLS stack
for this reason alone.

I'm not sure of the build deps for nss, but the ultimate solution for rust
will be limited to rust, c, and asm, and will be buildable with nothing but
cargo, GCC, and gcc-rs.

I do think it will take time yet for rust crypto to mature enough for
general use, but in the meantime we will necessarily need to maintain the
openssl bindings anyway (or move to boringssl), as the interim rust
solution.

[Ms2ger]

On 02/09/16 16:26, Jack Moffitt wrote:
> If NSS bindings [...] provide a better build experience,

FWIW, I haven't heard a good word about the NSS build experience in the
years that I've been around, and plenty of bad ones.

Ted's work to move NSS to gyp [1] might change that, though. (OTOH,
Servo doesn't currently depend on gyp AFAIK, so that might not be an
unequivocal plus.)

HTH
Ms2ger

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1237872

[Ms2ger]

On 26/08/16 02:13, Diane Hosfelt wrote:
> Proposed Development
>
> I propose to create Rust bindings for NSS, which is the crypto library used
> to secure Firefox. Not only does it fulfill all of Servo’s requirements,
> but it already has support for future work like TLS 1.3. I also propose
> that we create bindings for Mozilla:pkix8 for certificate validation. I
> spoke to the NSS team to see if they would be able to support an effort
> like this, and they were interested in helping. This is a practical way to
> get trusted, tested crypto into Servo and the wider Rust community.

Would we be linking NSS statically and dynamically, and if the latter,
would we try to use the system NSS or ship the libraries ourselves?

Thanks
Ms2ger

[Diane Hosfelt]

NSS doesn’t currently support building as static libraries. Do you think it would be better to try to use the system NSS or ship the libraries?

Diane

[Jack Moffitt]

> NSS doesn’t currently support building as static libraries. Do you think it would be better to try to use the system NSS or ship the libraries?

Depending on the system one exclusively is one reason why our OpenSSL
bindings suck. So we have to have it built by Cargo as a fallback.

jack.

[Brian Smith]

On Thu, Sep 1, 2016 at 10:43 AM, Jack Moffitt <ja...@metajack.im> wrote:

> mozpkix was the proposal, which Brian is also an author of. Brian, why
> exactly is mozpkix hard to wrap? Specific examples may help us
> understand Rust / C++ limitations. If that library is hard enough to
> wrap, then it might be less work to add whatever is needed to webpki.
> However, wrapping a C++ lib and implementing functionality may require
> quite different skillsets.
>

When we developed mozilla::pkix we had two use cases that were quite
different from each other: signed packaged apps (for B2G) and extensions,
and TLS. Consequently, mozilla::pkix is actually more of a framework than a
standalone certificate validation subsystem, where the differences between
these two use-cases were abstracted away into something called
TrustDomain[1].

Firefox implements TrustDomain two different ways, using code that is
dependent on Gecko stuff. Servo would almost definitely need its own
implementation of TrustDomain. The details of the TrustDomain interface are
security-critical so you'd probably need to have domain experts help with
the implementation of it.

In order to use mozilla::pkix from Rust, one would need to wrap the C++
mozilla::pkix API in a Rust API, and then implement in C++ a new
TrustDomain implementation that presumably forwards calls to new Rust code
that mirrors the TrustDomain class with a Rust analog. The TrustDomain
interface requires implementing many callbacks that require would
translating types C++ <-> Rust. As a result, when I started doing a Rust
wrapper around mozilla::pkix, I found that the boilerplate for translating
C++ <-> Rust was overwhelming and I became quite unhappy with the code. In
particular, the point of using Rust is to make code less error-prone, but
these wrappers were themselves adding lots of potential for errors.

Keep in mind that when we decided to do mozilla::pkix, we optimized it as
much as possible for C++. I think the idea that it has a "C-like" API is
perhaps due to a misunderstanding. It would be a significant amount of work
to create a real C API around it, because it is so optimized for use from
C++. I think this is why, after two years, mozilla::pkix hasn't been
integrated into NSS, even though Mozilla had promised the NSS team that it
would do so: using it from non-C++ code ends up being a lot more work than
it initially appears. Also, I expect it would be quite a burden on the
current mozilla::pkix maintainers to keep the Rust bindings in sync with
whatever changes they make to the internals of mozilla::pkix.

Because I had implemented most of mozilla::pkix, and because I did so that
used relatively modern C++ features like closures, I felt confident that I
could make a new Rust implementation of the same functionality that was
optimized for use by non-experts. I felt (and feel) that this is more
useful to the Rust community than what we did in mozilla::pkix, where it
was assumed that the users would be experts in certificate validation.

Thus, wrapping mozilla::pkix requires both Rust and certificate validation
expertise, just like extending webpki would. I do not think, for example,
that creating a safe and full-featured wrapper around mozilla::pkix would
require less total effort than to add OCSP and the other "missing" features
to webpki.

Note that mozilla::pkix makes extensive use of what Rust calls slices, to
avoid copying data. My primary motivation for creating webpki was to solve
the fundamental limitation that we had in mozilla::pkix: Although we were
very careful, the C++ compiler doesn't have a borrow checker to verify that
the slicing is safe from use-after-free. This, combined with the
much-simplified end-user API [2], are the primary technical advantages of
webpki over mozilla::pkix as webpki exists today. Looking forward to next
year, I feel much more comfortable adding advanced multi-threading and
other features to webpki than I would to mozilla::pkix.

[1]
http://hg.mozilla.org/mozilla-central/file/990aca9e4d11/security/pkix/include/pkix/pkixtypes.h#l169
[2] https://briansmith.org/rustdoc/webpki/struct.EndEntityCert.html

[Brian Smith]

Jack Moffitt <ja...@metajack.im> wrote:

> Since we currently use OpenSSL via hyper, this means the trait would
> be used there. I assume we'll also need a trait for the pki parts (and
> those are in Servo I think).
>
> With that boundary we could replace OpenSSL with NSS and then add
> others as they come online. The main complication of multiple options
> is QA. If we don't run them through CI they are likely to bitrot
> quickly.
>

This is unlikely to work well. It is based on an assumption that it makes
sense for all crypto libraries to work the same way and provide a similar
API. I expect, in particular, that Rust crypto libraries are going to be
able to take advantage of Rust's strengths to offer fearless concurrency in
a way that legacy crypto libraries would struggle to keep up with. Plus,
abstracting everything over traits requires all users of the crypto code to
be abstracted over those traits and/or use Trait objects, which would force
them into sub-optimal memory management decisions.

> One reason I would like to see the NSS bindings is that other projects
> in the Rust ecosystem may need more confidence in the crypto bits or
> functionality not yet implemented. Not every project in Rust is as
> pre-production as Servo. NSS bindings are also likely to be better
> maintained than the existing OpenSSL stuff with support from upstream.

Outside of the NSS team, who has more confidence in NSS than *ring* +
webpki + Rustls, BoringSSL, or OpenSSL? And, what is the reasoning?

Comparing NSS and other things is a difficult topic to talk about because I
am a former NSS team member and I don't want anybody to misinterpret
anything I say as disrespect for Wan-Teh Chang, Bob Relyea, and the people
that comprised the NSS team prior to me leaving it in 2014. However, If you
do a **technical** comparison of NSS to other options, I don't think NSS
would compare favorably. As far as political support for NSS is concerned,
I agree with what Patrick said, based on having recently talked to the tech
leads of crypto/TLS teams of many organizations.

[Jack Moffitt]

> Outside of the NSS team, who has more confidence in NSS than *ring* +
> webpki + Rustls, BoringSSL, or OpenSSL? And, what is the reasoning?

I think the assumption here is that many people outside the current
Rust community would have more confidence in NSS, BoringSSL, or
OpenSSL than Ring + rusttls + webpki. I think the reason behind that
is age, and that reason will not be true indefinitely. You've made
good points elsewhere in this thread that the bindings may introduce
some confidence problems of their own, and perhaps that invalides some
of the assumption.

I don't think Diane's proposal intended to imply we have more
confidence in NSS over BoringSSL. The choice of NSS was due to other
factors like BoringSSL having no stable API and being discouraged for
wider use.

jack.

[Brian Smith]

On Tue, Sep 6, 2016 at 11:38 AM, Jack Moffitt <ja...@metajack.im> wrote:

> > Outside of the NSS team, who has more confidence in NSS than *ring* +
> > webpki + Rustls, BoringSSL, or OpenSSL? And, what is the reasoning?
>
> I think the assumption here is that many people outside the current
> Rust community would have more confidence in NSS, BoringSSL, or
> OpenSSL than Ring + rusttls + webpki. I think the reason behind that
> is age, and that reason will not be true indefinitely.

So, this is a servo mailing list, so I guess the main issue here is what
Servo should do, rather than Rust cryptography in general. I think it would
be helpful to think about what the Servo team is doing to make people more
confident in Servo than they are in Gecko, Blink, and WebKit. I doubt the
situation is different for browser engines than it is for crypto libraries.

As far as non-Servo concerns regarding crypto libraries in Rust are
concerned, it's probably better to discuss them in a broader forum than
this Servo-specific one.

[Diane Hosfelt]

Thanks for the info about mozilla::pkix. I think that webpki looks like it
might be the right answer for a certificate library.

I 100% understand the desire to use a pure Rust TLS library for Servo, but
I think we need to not ignore the fact that there isn't one right now. Ring
implements the crypto primitives, not the protocols. Rustls is promising,
but it's brand new and lacks a number of features required to be a full TLS
library (and that's if the owner/community decide to allow insecure
algorithms for the sake of web compatibility). I don't think that Servo has
the resources to majorly contribute to a new TLS library in Rust. This
leaves a few options:

1. Continue with OpenSSL bindings until there's a more mature rust TLS
implementation
2. Create bindings for another library

>From this point, I think we should look at the resource problem. How much
work will it take to maintain/improve the OpenSSL bindings? Who can do
this? Ditto for the bindings for another library.

This leads me to the reason that I proposed NSS in the first place--I spoke
to the NSS team and they're interested in having Rust bindings, so they can
help create them (thus alleviating the resource problem). Personally, I
think this would be beneficial to the Rust community as well as Servo.

On Tue, Sep 6, 2016 at 10:38 PM, Jack Moffitt <ja...@metajack.im> wrote:

> > Outside of the NSS team, who has more confidence in NSS than *ring* +
> > webpki + Rustls, BoringSSL, or OpenSSL? And, what is the reasoning?
>
> I think the assumption here is that many people outside the current
> Rust community would have more confidence in NSS, BoringSSL, or
> OpenSSL than Ring + rusttls + webpki. I think the reason behind that

> is age, and that reason will not be true indefinitely. You've made
> good points elsewhere in this thread that the bindings may introduce
> some confidence problems of their own, and perhaps that invalides some
> of the assumption.
>
> I don't think Diane's proposal intended to imply we have more
> confidence in NSS over BoringSSL. The choice of NSS was due to other
> factors like BoringSSL having no stable API and being discouraged for
> wider use.
>
> jack.

> _______________________________________________
> dev-servo mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-servo
>

--
Diane Hosfelt
avadacatavra

[Dirkjan Ochtman]

On Wed, Sep 7, 2016 at 12:41 AM, Diane Hosfelt <dhos...@mozilla.com> wrote:
> I 100% understand the desire to use a pure Rust TLS library for Servo, but
> I think we need to not ignore the fact that there isn't one right now. Ring
> implements the crypto primitives, not the protocols. Rustls is promising,
> but it's brand new and lacks a number of features required to be a full TLS
> library (and that's if the owner/community decide to allow insecure
> algorithms for the sake of web compatibility).

I disagree with your statement that there "isn't one right now", as
you refer to a pure Rust TLS library. rustls implements full TLS, but
not old TLS, which would be needed to talk to a long tail of the web
today. As Servo matures, the long tail will become more important,
just as it will be in DOM or layout work, but for now, Servo can
probably do without it. Also, brand new-ness is not just a bad thing;
it also means that rustls can take advantage of modern knowledge on
what areas of TLS are more or less important and more or less
vulnerable.

> I don't think that Servo has
> the resources to majorly contribute to a new TLS library in Rust. This
> leaves a few options:
>
> 1. Continue with OpenSSL bindings until there's a more mature rust TLS
> implementation
> 2. Create bindings for another library
>
> From this point, I think we should look at the resource problem. How much
> work will it take to maintain/improve the OpenSSL bindings? Who can do
> this? Ditto for the bindings for another library.

Creating NSS bindings now is skating to where the puck currently is,
not to where it's going to be. Creating the bindings will involve
significant work. You may discount the work because the resources
don't have any cost to you, but it's still work that, in the bigger
picture, there is not much of a need for in the longer term. As the
NSS bindings work is going on, the alternatives will move forward as
well, and might even do so at a faster pace. Instead, Servo could
start skating now to where the puck will be, i.e. pure-Rust crypto.

To explain it in another way, I think you're implicitly dismissing one
factor, which is the rest of the Rust community. Notice that rustls
already exists, in a fairly usable form, without Servo or other MoCo
teams investments. As more people start using rustls, it will grow the
features that Servo needs, to some extent even without investments
from the Servo team itself. As one example, I myself have contributed
to both Servo and *ring*, and would be happy to work on rustls to
advance the cause of Rust crypto and Servo, in tandem.

It would be much harder to find volunteer contributors for NSS
bindings; I don't think the argument that significant amounts of Rust
users are interested in using NSS holds water, even if they care about
age -- they will probably go to OpenSSL instead, which has the virtue
of being more established now in the Rust community. (Also, will
people who care about the age of the crypto code magically not care
about the age of the bindings code?)

Cheers,

Dirkjan

[Jack Moffitt]

> Also, brand new-ness is not just a bad thing;
> it also means that rustls can take advantage of modern knowledge on
> what areas of TLS are more or less important and more or less
> vulnerable.

Several people heavily involved in the TLS standards process are at
Mozilla and work on NSS. NSS and BoringSSL are both getting TLS 1.3
implementations that are being tested and debugged, and those
implementations' findings are fed back into the standards work. Even
if the same is true for rust-tls, it does not seem to be an advantage.

At least with TLS 1.3 implementations the age concern mostly goes
away. They will all be brand new and contain bugs, but at least the
Rust code shouldn't have memory bugs.

jack.