Re: Requiring TLS 1.3 as alternative to HTTP/2 section 9.2.2

One possible route is to do the following:

1) Re-version all current TLS 1.3 work as TLS 1.4
2) Write a new TLS 1.3 draft that is JUST TLS 1.2 with HTTP/2 section 9.2.2 applied
3) Make this new minimal TLS 1.3 mandatory for HTTP/2 over TLS

This effectively means bumping all on-the-wire changes for the current TLS 1.3 draft to 1.4 and making 1.3 simply be 1.2 without non-AEAD ciphers or compression. (renegotiation would still be a question, though) Just throw in a MTI cipher or two and publish it. As there would be nothing fundamentally new to test, just spec removal, the path to implementation, testing, and standardization would be far simpler.

HTTP/2 doesn't need ideal TLS now; it merely needs competent TLS. All 9.2.2 was attempting was to formalize the best current practices and keep old known bad policy from spilling over into the new. Simply publishing it via the correct route is all that's really needed to move forward with it. TLS 1.4 can be released when it's ready.

HTTP/1.1 and other applications would also have easy access to a simplified TLS 1.3 standard, as well. Sure, it wouldn't actually give anything new, but it would guarantee nothing particularly old and bad. It's a useful incremental improvement, and one that would hopefully have better adoption rates.


-- Dave


On Tuesday, October 28, 2014 02:47:57 pm Jason Greene wrote:
> > 
> > On Oct 28, 2014, at 1:03 PM, Erik Nygren <erik@nygren.org> wrote:
> > The ordering of HTTP/2 and TLS 1.3 is backwards from an ideal world
> > for this, but it seems like it might be better to try and aim for something that gets
> > us into a good state 18 months out from now if it means reduced complexity
> > in both the short-term and the long-term.  The cost seems to be that the initial
> > HTTP/2 implementations may start falling back if not updated within some time period.
> 
> What about the question of scope with 1.3 that Dave asked? If you limit 1.3 to just ciphers
> and negotiation (e.g. fallback scsv etc), does that potentially improve the schedule? I suppose the challenge is the required interop events and implementation.
> 
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
> 
>

Received on Tuesday, 28 October 2014 23:38:28 UTC