> 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 <dhosf...@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. > > 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 > > > > On Aug 28, 2016, at 19:22, adela...@gmail.com wrote: > > > > 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 > > _______________________________________________ > > dev-servo mailing list > > dev-servo@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-servo > > _______________________________________________ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo > _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
