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

Is there an operational approach we can take that gets us to the right
place eventually
(or at least within a reasonable time-frame)?

For example, if servers SHOULD NOT negotiate h2 via ALPN over anything
below TLS 1.3
starting a year after TLS 1.3 reaches a particular status?   This would
presumably need
to be an expectation set now, followed by an action by UTA or similar in a
year or so from now?
This unfortunately still leaves the onus on the server-side since the
client-side doesn't
have a way to specify the allowed protocol versions in the ALPN message.

What would be the impact on HTTP/2 client implementers if they knew that
clients would start falling back to HTTP/1.1 if they didn't incorporate TLS
1.3
support within some time window after it was available?

Another option might be to add an ALPN token for h2-requiring-tls-1.3
that would be added in by client implementations when they add TLS/1.3
support
with h2-15 or whatever it is being dropped at some point subsequently?

I'd like to see us move in the right direction, but I agree with Yoav and
others
that it would be unfortunate to introduce interop issues that result in
connection
failures.  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.

     Erik



On Tue, Oct 28, 2014 at 1:07 PM, Mark Nottingham <mnot@mnot.net> wrote:

> I’ve asked the TLS WG chairs of their estimate of when 1.3 will LC, and
> the answer was that they’re hoping to WGLC around Dallas, but that may be
> “too aggressive.”
>
> My perception is that there isn’t yet a lot of confidence about that date.
>
> Regards,
>
>
> > On 27 Oct 2014, at 6:42 pm, Dave Garrett <davemgarrett@gmail.com> wrote:
> >
> > It looks like HTTP/2 section 9.2.2 is on the chopping block, with little
> push-back thus far, so I'm going to ask the obvious question: what's going
> to replace it?
> >
> > Attempting to enforce cipher requirements here is problematic, however
> removing these requirements will also add its own interoperability
> problems. If a server were to follow the spec without these requirements,
> then a browser that already implements them will reject the connection.
> Unless everyone is also going to pledge to remove already implemented
> security checks, this will be an issue. Without 9.2.2, even RC4 is valid
> for HTTP/2 traffic, which seems like something implementors would fight
> against introducing.
> >
> > There were a few people that suggested simply waiting for TLS 1.3 and
> requiring that instead of TLS 1.2 plus a series of hacks. Is it possible to
> fast-track TLS 1.3 from its current draft to standardization for HTTP/2,
> and move further TLS development to 1.4? This is the simplest solution and
> obsoletes almost all of section 9.2, not just 9.2.2.
> >
> > I guess the real question is: can two working groups work together here?
> >
> >
> >
> > -- Dave
> >
> >
> >
>
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
>
>