Re: [TLS] ALPS and TLS 1.3 half-RTT data

[Martin Thomson <[e-mail]>]

On Sat, Jan 30, 2021, at 10:38, David Benjamin wrote:
> How does NSS expose the late client authentication to the application? 
> I thought NSS didn't support half-RTT at all when the server requests 
> client certificates, but perhaps I misunderstood.

There are three states we use with respect to client authentication; those guide what might be done:

1. No CertificateRequest (0.5-RTT is therefore always safe to send)
2. Request a client certificate, but don't require it (positions differ here)
3. Require a client certificate (0.5-RTT is arguably unsafe to send, unless you can be sure it is not conditional on client authentication)

I originally decided to allow 0.5-RTT in cases 1 and 2.  My logic was that a server in that posture always needed to check for a certificate before sending anything.  That is, the server was already in the appropriate posture and enabling 0.5-RTT could not make things worse.  However, Ekr was unhappy with that idea and I decided not to fight it (that doesn't make him any more right, but he was definitely right to insist on stronger justification; I just didn't have the energy to provide that justification, more so because we don't really make a server and all I really wanted to know was that we correctly handled 0.5-RTT at the client).

Back to the main subject...

On reflection, the buffering thing was a false trail.  The reason we have buffering for 0-RTT is primarily because that is followed by handshake-critical data.  We have to clear 0-RTT aside to get to handshake data, because there is a risk that it fills the congestion window and prevents the Finished from ever being sent.  Unless you support blocking writes that also block reads, I don't believe that 0.5-RTT has the same problem.

For me, this whole question is down to imposing constraints on usage.  We have this artificial constraint that says an extension or handshake message (like ALPS) can't contain anything that is conditioned on application data.  That is a useful constraint, because it makes the handshake easier to reason about.  But the same constraint can be applied to 0.5-RTT if we chose, making all versions of it safe to use in the same way (even case 3 above).

At that point, the question becomes whether you think that covering this data with the handshake transcript is worth the head-of-line blocking exposure.  (And other miscellany, I guess, like what your priors are regarding adding more extension points.)