Re: [TLS] '15 TLS Fall Interim Minutes

[Eric Rescorla <[e-mail]>]

On Wed, Sep 23, 2015 at 3:54 AM, Ilari Liusvaara <
[e-mail]> wrote:

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

I will fix this.



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

Yes, the server can send immediately after receiving the first flight.


> 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 idea on the table was to use an exported value to match Token binding.
Input needed here.




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

Yes, there was consensus to include the certificate.



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

There was a lot of confusion at the interim about whether the concern here
was an auth server at the attesting party or the relying party.



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


There was confusion about this too. Could you provide a (perhaps contrived)
example of the attack you are concerned about and a mechanism which would
defend against it?

Thanks,
-Ekr



>
>
> -Ilari
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>