Re: TLS Renegotiation and HTTP/2 (#363)

#1 is not a bad option. It’s not pretty, but just the fact that it’s written down puts it ahead (process-wise) of the others.

The TLS working group is considering getting rid of renegotiation for TLS 1.3, because few use it except for client authentication in HTTPS. Going with option #2 leaves us with all of the complexity. I’d rather we didn’t go there.

#3 is a sure-fire way of getting angry comments and DISCUSSes for HTTP/2. Arguably, those with client certificates are those with the highest security requirements, and to disenfranchise those in a new version is likely to get the document in trouble.

#4 is an interesting one. I’m too lazy to look back at older specifications to see whether it was possible for the server to request the client to send this frame, but it could be done.

#5: hard to comment on things *you* haven’t though of yet, but I can suggest one of my own. Make it an HTTP authentication method. Something along the lines of (apologies for the HTTP/1.1 syntax)

Server sends:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Certs
        realm = “example.com”
        challenge="EKgoC3wwy8KuJROo/gmG1we43c5av9OwOlWaYVPStsw=“

Client sends:
Authorization: Certs
        realm=“example.com”
        hash=“SHA-256”
        cert=“MIIGzTCC...gpECY="
                challenge="EKgoC3wwy8KuJROo/gmG1we43c5av9OwOlWaYVPStsw=“
        signature=“FIMe3WLvlgX3BgJKYN0DXj4UGuauq5fwXgZErnFgVR0=“

All you really need with client certificate authentication is to show the certificate and sign something of the server’s choosing. You can make it fancier by having the server list supported hashes and trusted CAs, but that’s not strictly necessary.


On Apr 1, 2014, at 3:11 AM, Martin Thomson <martin.thomson@gmail.com> wrote:

> In my other email today, I've listed the items that are outstanding,
> of which I identify 6 issues that could result in disruptive changes
> to the protocol if we decide to act on them [1].
> 
> Of those, I think that TLS renegotiation is only the issue that fixes
> something we've actually broken.  Broken, the sense that if we don't
> do something about this issue, we've broken a feature that some people
> rely on.  Importantly, this is broken in a way for which the only real
> recourse is to revert to HTTP/1.1.
> 
> (Transfer-Encoding #445 arguably introduces a feature regression too.
> But it's a regression that can be handled trivially by spending bytes.
> It might be reasonable to say that given the degree to which
> Transfer-Encoding is used today, the odds that we are creating
> incentive to stay on HTTP/1.1 is lower.)
> 
> Relying on renegotiation for re-keying (to avoid key exhaustion) seems
> like a non-problem.  We already require the creation of new
> connections when stream IDs run out.  It does mean that extremely
> large requests or responses (broadly, anything longer than 2^64-1 TLS
> records, though probably less if the cipher suite requires re-keying
> earlier) cannot be carried at all.
> 
> The main issue here is client authentication.  I see several ways out:
> 
> 1. Pursue http://tools.ietf.org/html/draft-thomson-httpbis-catch-00 or
> something like it to the bitter end.  I don't see a way that we can do
> this without creating a new normative reference, unfortunately, and
> that work is clearly half-baked.
> 
> 2. Allow for some very limited form of renegotiation for the client
> authentication use case.  This might mean requiring that
> MAX_CONCURRENT_STREAMS be wound back to 1 at the server before
> renegotiation is triggered.  This avoids the dependency issue, and
> might work for the use cases in question, but the cost in complexity
> and loss of concurrency is extreme to the point that option 3 starts
> looking good.
> 
> 3. Force those using client authentication to stay on HTTP/1.1.  We
> basically get this for free if we intend to pretend that this issue
> doesn't exist.  I tend to think that this would be a bad outcome
> though.
> 
> 4. Resurrect the CREDENTIAL frame from SPDY.  My understanding of this
> mechanism is that it would be non-trivial to add this to the protocol.
> It is quite a flexible mechanism, but one with significant costs.
> This relies on RFC 5705 (TLS extractor) support, which is not
> universally supported in the various TLS stacks that are commonly
> used.  It also requires a new setting and modifications to the HEADERS
> frame.
> 
> 5. Something else that I haven't thought of yet.
> 
> Does anyone have a way forward to recommend?  My primary motivation
> here is getting HTTP/2 done.
> 
> 
> [1] http://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/1292.html
>