
Quiche – An implementation of the QUIC transport protocol in Rust - jgrahamc
https://github.com/cloudflare/quiche
======
dochtman
I still don't quite understand why Cloudflare is going their own way rather
than joining our Rust implementation
([https://github.com/djc/quinn](https://github.com/djc/quinn)). So far the
primary maintainer told me "I quite like how quiche has turned out, and we
already started integrating into internal stuff", which I haven't found very
satisfying.

Perhaps they just want to strategically own their own stack, but it seems to
me aligning with the broader Rust ecosystem and getting features for free from
the community would also bring some value.

Initially I thought it was mainly about integrating with BoringSSL rather than
_ring_ and rustls, but even the promise of pluggable crypto didn't seem to
affect their decision.

Would be nice to have more clarity on this.

(Previously they were happy enough to use Quinn for their Noise experiment,
although without crediting our project explicitly in the resulting paper.)

~~~
jgrahamc
Fundamentally, we wanted an interface to QUIC that we could integrate with our
existing server systems. Our servers, naturally, have their own methods of
handling a wide range of things like: socket addressing; events state; memory
management; TLS handshake processing; request and response processing; and we
needed our QUIC implementation to be as independent of these notions as
possible. Looking at a library like quinn and some other QUIC implementations,
we see that these APIs are tied to many of these external notions, and
specific implementations of these notions for that matter, one example being
the core protocol objects in quinn that directly link to specific socket and
address and even event loop reactor objects - and these objects strictly in
Rust to boot.

It was obvious from our experience with our first QUIC proof of concept, and
from our evaluation of options for our continued QUIC offerings, that existing
solutions available right now would not be able to offer the level of
flexibility and abstraction we need, nor would they likely be able to add the
interfaces we need in a reasonable timescale, nor would they likely tolerate
our requests to do so.

~~~
downsideup
I'm one of the engineers working on QUIC projects at Cloudflare.

This response from jgrahamc just came to my attention. His comments are based
on a discussion I had with him about our first QUIC project and then
additionally what I knew of quinn. I described how quinn was arranged and that
it provided an interface that was oriented towards the tokio IO library. What
I seem to have failed to communicate was the IO specific interfaces were not
the only interfaces provided by quinn, and that more abstract interfaces do
exist. This mistaken impression seems to have been bundled with the multitude
of reasons that we did not choose various other QUIC implementations.

I'm sorry that this this mischaracterisation was made against your work, and
hope anyone reading this thread does not take away the same impression.

------
marceloneil
Why use BoringSSL? I was under the impression that it was not recommended for
third-party use.

~~~
ocdtrekkie
Extended opinion on this by someone formerly Google and currently Cloudflare:
[https://github.com/sandstorm-
io/sandstorm/issues/3036#issuec...](https://github.com/sandstorm-
io/sandstorm/issues/3036#issuecomment-366792583)

tl;dr is that Google is not supporting features in BoringSSL that Google
doesn't need, but it's probably adequate for a lot of other projects.

~~~
tialaramex
Really we should learn to expect that "I don't support that" is the default
unless somebody's _actual_ business is supporting you doing whatever it is.
Which it rarely is these days. This obviously matters most for security, but
it's true everywhere.

Another security example is that a tremendous amount of stuff ultimately
decides whether to trust a certificate based on Mozilla's root trust
programme.

That seems fine right? Well, kinda. It's definitely better than "I found this
file named CA_TRUST.Z on an old Solaris machine in 1997 and so that'll have to
do" as a policy.

But it's different from two things you or end users might expect you're
achieving.

1\. This isn't "You know, the same Certificate Authorities trusted
everywhere". There is no such thing. The big root trust programmes have a fair
amount of commonality, which is fine if you're out to obtain a certificate for
a web site (pick anyone in the common set) but they aren't even close to
mirrors. Mozilla's list is significantly different from Apple's which is
likewise different from Microsoft's.

2\. This also isn't "Like in Firefox". This problem is more subtle, after all
the Firefox build process consumes the same file, ultimately, as your code
does. But, Firefox has a long list of extra rules beyond whether or not
something is in Mozilla's published trust store and your application would
need lots of extra work to implement all those rules and track updates to
them. Did you do that work? No you did not.

This probably won't bite you, and likewise relying on bits of BoringSSL that
Google doesn't care about probably won't cause massive security problems in
your code. But only probably.

------
aboutruby
I thought they were doing Go whenever possible.

~~~
jgrahamc
We do have a lot of Go but we are not religious about languages as that would
be silly. Rust has some interesting properties and compiles readily to
WebAssembly. We'll continue to use Go and Rust for projects. We also have lots
of Lua, PHP and C++ in production. Plus lots of Python and other languages.

------
funkythings
I hope rust becomes more mainstream in companies. At the moment it seems like
a lot of smaller components are implemented in rust, to allow employees to get
familiar with it.

~~~
pornel
Rust is mainstream at Cloudflare. It's used for many new projects. New
projects naturally start small.

There are millions of lines of existing production code in other languages,
but they won't get rewritten. Even if they would be better in Rust, there's a
high opportunity cost of rewriting existing code that works, instead of
spending the effort on adding value elsewhere.

