On 04/24/14 15:27, Frederick Akalin wrote: >> From reading through the protocol, it seems there are two modes for >> forward secrecy: > > A) Use forward secrecy, but allow the other side to turn it off. (default) > B) Turn off forward secrecy.
Correct. > However, there could conceivably be a third mode: > > C) Use forward secrecy, and terminate any connection that tries to turn it > off. > > The only problem is that if an endpoint receives 1 for the y value of the > other side, it doesn't necessarily know that the other side has 0 for its x > value. (I'd have to check whether it's possible, given the specific modulus > and the possible range of x, to rule out a non-zero x for a zero y value, > unless someone already knows the answer to this...) If you receive y=1 from a protocol-compliant endpoint, it is running with FPS turned off. Protocol non-compliant endpoints could hardcode other values, e.g., y=2, which would also have the effect of breaking FPS, but of course non-compliant endpoints could do all sorts of things to deliberately leak keys. > This third mode would make it possible to guard against misconfigurations, > e.g. I might want forward secrecy to be always used, and for stuff to blow > up / complain if that changes. Is this a valid use case? It's certainly plausible as an anti-foot-shooting mechanism. It doesn't gain you any theoretical security (since it can be circumvented), but it might still be useful in practice. Want to send me a patch? -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid