On Wed, Sep 23, 2015 at 3:54 AM, Ilari Liusvaara <[email protected]> wrote: > One thing to note: The time is 4 octets, and 32 bit time since unix > epoch runs out a good bit faster than what I would like.
It's an unsigned value so it stretches until 2106 rather than the standard epoch rollover at least. >> investigate: using the same construct for server/client sigs. > > Huh? Don't both currently use the same construct, except for the > context string? Are you proposing to remove the context string or > what? The on-the-fly client auth messages were envisioned to sign the certificate and a TLS Exporter value. That point was reflecting a desire to have the handshake signatures sign the same thing if that makes sense. >> 4. We agreed to not allow unsolicited client auth. > > What will browser using HTTP/2 do if it receives client reauth request > when it has stream blocking identity change open? > > - Open new connection and ??? to elict certificate request. > - Reset all streams that block identity change and then change identity. > - Reset all streams, change identity and retry request. > - Kill connection (e.g. PROTOCOL_ERROR). > > (Just changing the identity is known to be insecure.) "Unsolicited" means that the TLS server never sent an on-the-fly CertificateRequest. So the HTTP/2 situation would involve the server sending a CertificateRequest which includes an opaque identifier. The application protocol is free to decide that that identifier means and HTTP/2 can decide that it's the stream id of the request that triggered the need for a certificate. The client returns a certificate (empty or not) and, in the mean time, the connection can continue flowing. (And other CertificateRequests can be sent while one is outstanding.) >> 6. We want a consolidated certificate message and certificate verify. > > Just be careful that certificate is still signed, as many signature > algorithms fail to even properly bind the key, and nothing binds the > certificate. Yes, that's understood. > Parse error. Does this mean something like "how much data current > ciphers can safely encrypt"? Yes. > Huh? This is about collisions between different hash algorithms. I > don't see how contributory behavior would help there (which is severly > limited by 1RTT maximum there). I think we quite possibly didn't understand the concern here. Could you spell it out at more length? Cheers AGL -- Adam Langley [email protected] https://www.imperialviolet.org _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
