On Tue, Dec 01, 2015 at 11:19:15AM -0800, Eric Rescorla wrote: > > 3. The server provides g^y in his ServerHello and then g^xy and g^xs > are jointly used to produce the traffic keys and also to form a MAC over > the handshake. As Hugo pointed out originally, this alone should > be sufficient to authenticate the server's side of the connection and > you could omit the server CertificateVerify (Hugo, please correct > me if I have misunderstood).
Is it guaranteed that the groups are the same? Even if it is, due to implementation bugs, bad idea to rely upon that. > Trying to read between the lines, is your concern that the server is > now no longer explicitly signing over the ServerConfiguration in > its CertificateVerify [Note that the client continues to do so]? The idea > behind removing that was to make the 1-RTT part of the handshake > more uniform regardless of whether 0-RTT data was used. > I'm certainly open to putting that back in if it's needed, but can you > explain your concern in more detail? The concern is that attacker that has managed to inject g^s for known s is able to impersonate the server even through server certificate validation on subsequent connections (under some conditions). (Indirectly) signing g^s would prevent this. ... Funkily enough, this attack doesn't work against either tls-unique nor tls-extractor (however, those still fail nonce check with respect to SS)... -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
