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
>