Re: [TLS] '15 TLS Fall Interim Minutes

[Ilari Liusvaara <[e-mail]>]

On Tue, Sep 22, 2015 at 04:27:35PM -0700, Sean Turner wrote:
> I’ve gone ahead and posted the minutes/list of decisions to:
> 
> https://www.ietf.org/proceedings/interim/2015/09/21/tls/minutes/minutes-interim-2015-tls-3

Minutes:

> ## Issue 223 - absolute or relative time
> 
> Leave as-is because a) switching to relative time is painful and it's
> not standalone, b) it's not entirely clear what > benefit we get from
> this, and c) we're already using absolute time for other things like
> certificates & OCSP.

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.

> ## Client Authentication
>
> We agreed that we need to support this in TLS 1.3.
> 
> ### How
> 
> 2. We will modify the data that's signed to conform with what Andrei
> is proposing provided we also terminate the transcript for key
> derivation before the CC/CCV.

Oh yay, Server 0-RTT?

> 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?

> 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.)
 
> 5. We agreed to take out the ClientCertificatType from CertificateRequest.

Yeah, that one is not needed for anything.

> 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.

And results of lack of binding for the certificate are not easy
for me to analyze.

> ## Data transfer limitation per connection (issue 125/4)
> 
> After quibbling with the math a bit, we need to specify how good we
> think the current ciphers are numbers.

Parse error. Does this mean something like "how much data current
ciphers can safely encrypt"?

> ## Include randoms directly in digital signatures
> 
> Issue 224
> 
> Consensus at the interim was that this has straightforward to do by
> just having the authentication server supply the ServerRandom was
> enough since it can search through the handshake transcript.

This assumes that authentication server receives full handshake and
not just handshake To-Be-Signed.

> # PRF designation in server certificate verify
> 
> Issue 227
> 
> Consensus was to leave as-is. A hash identifier isn't the way to
> solve this.  What you really need is contributory behavior to solve
> this issue.

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).

Now, the issue is probably entierely theoretical and thus would not
need solving.



-Ilari