On Wed, Dec 2, 2015 at 11:23 AM, Ilari Liusvaara <ilariliusva...@welho.com> wrote:
> > > > > 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. > > I would certainly expect the signature check, if it is there at all, to > be proper nonce over SS. > > IIRC, the key exchange is explicitly intended to be secure (but forward > security is lost) if ES is revealed. > > Config-authenticated ciphersuites are different matter (the main > challenge there seems to be deciding when those are to be enabled[1], > not so much designing the key exchange[2]). > I may be being stupid, but I think I'm still not following. Do you think you could provide a ladder diagram showing the messages that demonstrate the attack you are concerned about. Best, -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
