Re: [TLS] '15 TLS Fall Interim Minutes

[Adam Langley <[e-mail]>]

On Wed, Sep 23, 2015 at 3:54 AM, Ilari Liusvaara
<[e-mail]> 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 [e-mail] https://www.imperialviolet.org