On Wed, Sep 23, 2015 at 3:54 AM, Ilari Liusvaara < [email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
