Intent to Implement and Ship: HTTP Too Early

[Victor Vasiliev]

Contact emails

vas...@chromium.org, r...@chromium.org

Spec

https://tools.ietf.org/html/draft-ietf-httpbis-replay-02

The draft is currently in the Working Group Last Call.

Summary

HTTP 425 is an error code that allows the server to indicate that it’s unwilling to process a given request since it was sent over 0-RTT using TLS 1.3 or QUIC.  Upon receiving it, browser has to wait until a full TLS session is established and then retry the request.

Motivation

In TLS 1.3 and QUIC, a request can be sent over 0-RTT; this allows to avoid latency penalty of establishing a full connection, but allows network attackers to replay the request.  In order to avoid that, there are multiple safeguards, one of which is allowing the server to reject a request and ask the client to resend it once the server has a cryptographically strong proof that the request is not being replayed.  The proposed error code provides such a mechanism.

Risks

Interoperability and Compatibility

The interoperability risk is fairly low.  The draft is in last call and is mandatory for all implementations that use 0-RTT over TLS 1.3; same will be the case for QUIC once it becomes an IETF standard.  The error code is not processed outside of that context.

The main risk is that the error code could change between now and IANA allocation.  This is unlikely since it appears to be unused (outside of an obscure WebDAV extension which is dubiously real), and Firefox has already shipped it.

Edge: Public support -- http://lists.w3.org/Archives/Public/ietf-http-wg/2017JulSep/0347.html

Firefox: Shipped -- https://bugzilla.mozilla.org/show_bug.cgi?id=1406908

Safari: No signals

Web developers: Nothing from actual developers of web applications; not directly related to the status code, but other parts of the draft seems to be supported by HTTP server developers (shipped by HAProxy and h2o, more support on the mailing list)

Ergonomics

This feature will use the same retry mechanisms as many other HTTP-internal retries do, so there should be no possible concerns with respect to how the retry is actually done.

Activation

The feature is only required when 0-RTT is used.  For TLS 1.3, Chrome will not use 0-RTT until this feature is shipped.  For pre-IETF QUIC, existing deployments already rely on the GET/POST distinction for replay protection, hence this is mostly useful for newer deployments.

Debuggability

The requests retried upon the 425 code will be visible in net-internals logs.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Is this feature fully tested by web-platform-tests?

No. It will be tested by network stack tests.

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5866220553240576

Requesting approval to ship?

Yes.

[Victor Vasiliev]

[Dave Methvin]

It will be critical to get this page updated. https://httpstatusdogs.com/425-unordered-collection  :)

Also http://networksmart.wikidot.com/status-code-http-425 mentions the old function.

[PhistucK]

So, in practice, since Chrome does not support 0-RTT in TLS 1.3 yet, this feature will only apply to QUIC at the moment, right?

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9faddacf-8ada-4551-8458-aed1bf800635%40chromium.org.

[David Benjamin]

Yes, but the same code will be used for TLS 1.3 0-RTT once that is shipped. We're working with Victor here to align the TLS 1.3 and QUIC 0-RTT stories.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9faddacf-8ada-4551-8458-aed1bf800635%40chromium.org.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_KshQzuDPNsUiEK5QA8Wchq4yG%2BGR9DCY7eQ2bkJuFxyQ%40mail.gmail.com.

[Yoav Weiss]

From an "RTT accounting" perspective, if we're sending a request with 0-RTT and the server responds with a 425, that response reaches the browser at the end of the first RTT. So basically attempting 0-RTT is a win-win regardless of percentage of server support for such requests. Is that correct?

I kinda wish we started expanding WPT to cover network stack features as well. I'm guessing that right now WPT's infrastructure and WPTServe do not enable you such testing. Could you figure out what's missing and open issues on WPT? 

[David Benjamin]

On Thu, Nov 30, 2017 at 8:47 AM Yoav Weiss <yo...@yoav.ws> wrote: 

Is this feature fully tested by web-platform-tests?

No. It will be tested by network stack tests.

I kinda wish we started expanding WPT to cover network stack features as well. I'm guessing that right now WPT's infrastructure and WPTServe do not enable you such testing. Could you figure out what's missing and open issues on WPT? 

Honestly, I think adding support is not even plausible right now. It's not something that can be captured by one or two tickets for missing features. This is one of those places where the usual Blink process and networking needs don't quite match.

The world certainly needs a better story for implementation-independent testing for network protocols, but it's not like testing a JavaScript API. Testing a JavaScript API is a matter of adding some function calls and checking they give the right result. Maybe talk to a few servers, but the web platform sees the network at a very high-level with most details abstracted, so it's easy to mock behaviors. (This is a good thing! This tight abstraction is why we can deliver networking improvements at all. It's also critical for the security model.) Additionally browsers inherently come with a common scripting language, so you get a test driver for free.

On the wire, we have a different problem space. The abstraction is not a scriptable platform, so there's no free test driver. Then we add in encryption which is intended to prevent replaying saved bytes. In all, integration tests for a network protocol means a new implementation of most of that protocol, but with added flexibility (and thus complexity) of being able to emulate the full range of possible peer behaviors, both valid and invalid. On top of that, there's more implementation flexibility in networking protocols, so test expectations are harder to hammer down.

I can mostly speak to the TLS side of things. BoringSSL has an extensive custom test suite in Go. A few other stacks have had some success in using it, but even then it's supplemental and best-effort. Our test suites is very BoringSSL-specific. Smoothing that over without sacrificing test fidelity is still an open problem. Within Chromium, a lot of our tests are unit tests or reuse large chunks of our own implementation because, well, we just have that one QUIC or TLS implementation. (There's tlslite checked in too, but it's no good.)

Thus I don't think "how can we test this in WPT?" is a reasonable question yet. We're still at "How can we test this in an implementation-generic way at all?". Afterwards, sure, we can and should think about doing it in WPT. For starters, I can guarantee you that WPT and Chromium need a new language dependency. Python's cryptography and network support is not usable for this. We've had a lot of success in BoringSSL with Go. Doing it in WPT comes with the additional complexity that the previously free JavaScript test driver is now quite far (by design and for security reasons) from the parts the test would otherwise need to drive, so that limits the testing fidelity.

[Yoav Weiss]

I probably should have made it clearer that I don't suggest blocking this intent on web-platform-tests, but just exploring what it would take to make such a feature testable there.

There are many HTTP based features that are tested with WPT: CSP, RefererPolicy, Preload, etc.

There are others (e.g. Preconnect), which are not, and which we discussed at TPAC ways to make them testable.

Your comments regarding Python's network stack and crypto being insufficient make a lot of sense as to why WPT may not be the right target for such tests, at least not right now. At the same time, I still think it's a shame every vendor will have to recreate not-necessary-compatible tests for such features.

[Anne van Kesteren]

On Thu, Nov 30, 2017 at 3:48 PM, David Benjamin <davi...@chromium.org> wrote:
> The world certainly needs a better story for implementation-independent
> testing for network protocols, but it's not like testing a JavaScript API.

TLS does indeed seem like a more complicated story (though if there's
willingness to upstream the custom server endpoint I think that could
be made to work), but I think many aspects of networking can be easily
tested on web-platform-tests (and indeed you can find some tests there
that do):

* HTTP message parsing
* HTTP header value parsing
* Handling of duplicate HTTP headers
* HTTP cache handling

If this was taken more seriously as part of the various IETF efforts I
think we'd have a much better story for HTTP by now (and
implementations that would be much closer in behavior than they are).

> On top of that, there's more implementation flexibility in networking protocols,
> so test expectations are harder to hammer down.

Whenever HTTP has this it's usually a problem of sorts (that we either
paper over in Fetch or end hope will get fixed at some point; e.g.,
merely allowing implementations to rewrite POST to GET on a 301/302).


--
https://annevankesteren.nl/

[Harald Alvestrand]

There's a decades-long history of testing network protocols in various ways.

A lot of them (especially those labelled "conformance") have been found useless in the long run, because they test "conformance to the letter of the law" rather than "do something that works for realistic cases".

Interoperability testing has a better reputation in networking circles - "if you can talk to the other guy, at least you're interpreting the specs in compatible ways".

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADnb78iVik5_xmw16nwv3nza5OXFu%3DiXeFCmZbD4FEf53cX3zQ%40mail.gmail.com.

[Anne van Kesteren]

On Thu, Nov 30, 2017 at 6:11 PM, Harald Alvestrand <h...@google.com> wrote:
> There's a decades-long history of testing network protocols in various ways.
> A lot of them (especially those labelled "conformance") have been found
> useless in the long run, because they test "conformance to the letter of the
> law" rather than "do something that works for realistic cases".

Outside the IETF the practice is to accept the specification is broken
in such cases and get it fixed, as the specification cannot be used by
new implementations and refactoring of old implementations. It would
be good for the IETF to adapt. (As examples, consider
https://encoding.spec.whatwg.org/ and https://url.spec.whatwg.org/
which are both an evolution of work that happened in the IETF, but
didn't get driven to full interoperability there.)


--
https://annevankesteren.nl/

[Harald Alvestrand]

Remember that perspectives differ.

The IETF version I've heard of the URL story is (roughly) that the whatwg forked a spec that was used in many places, disregarded all the experience that usage of the spec outside the Web context had gathered, mangled it so that it was useless outside a quite limited scope, and declared that "this is now the new standard".

The nice thing about standards is that there are so many of them, and if you don't like any of the current ones, fork.

[Harald Alvestrand]

Replying to the topic of testing rather than the distraction of forking specs.....

The "conformance tests" that gave the term a bad name were largely done in the 1990s - especially the experience with various labs building *expensive* test suites to do "conformance testing" on X.400.

These "conformance tests" would uncover bugs like "this particular implementation doesn't support putting 63 A's with diacritics into the organizational unit field", but would fail totally to discover bugs like "this implementation will discard all mail sent on the 31st of the month".

It was quite traditional to have two systems that were tested at the same lab, and both had passed their conformance tests, but when we tried to interconnect them, a large investment of engineering time had to be made in order to make them interoperate at all.

I think all organizations agree in principle that specs need to be fixed to conform to what works in reality - but the methods and cadence of that fixing varies between organizations.

[Rick Byers]

LGTM1 to ship

If anyone wants to continue the discussion on how best to test HTTP features like this (which obviously I'd love to see progress in), can you please update the subject so that we can keep this thread focused on what is blocking shipping this feature?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOqqYVH%2B%2BWTuyMhGTeP3xwf-5_n3DfY-KGw-9eGfQZ2A2yqSsg%40mail.gmail.com.

[Chris Harrelson]

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-_%2BJD9JRhzPj2wJd1zckSiDJzKq4j%3DjPfUMBkyvoU6Cg%40mail.gmail.com.

[Yoav Weiss]

LGTM3

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.