On Wed, Dec 2, 2015 at 9:08 AM, Ilari Liusvaara <ilariliusva...@welho.com> wrote:
> 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? > Yes, it's a requirement that the groups be the same. If the text doesn't say that, it should. > Even if it is, due to implementation bugs, bad idea to rely upon that. Can you expand on this point? Is there a specific easy-to-make implementation error you are concerned with? > > > 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). > I'm sorry, I'm still not following. All the data that the server sends is tied to g^y which is signed with the server's certificate, so even if s were published, the attacker should not be able to inject data which the client would accept. With that said, it's certainly true that if the attacker is able to convince the client that the server has a certain g^a where a is known to the attacker, then the client has a problem because he will encrypt data *to* the attacker in 0-RTT, so obviously we are assuming that the attacker does not know s and cannot convince the client to accept a g^s of his choice. (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)... Do you think you could draw a ladder diagram that shows the attack you are concerned about? -Ekr > > > > -Ilari >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
