Hi there, On September 24, 2003 06:37 am, Colin Watson wrote:
[snip] > I've gone for OPENSSL_NCIPHER_FALLBACK=off, which just turns off > software fallback altogether. The new ENGINE control commands are more > granular. [snip] > Hm. After more thought, I observe that users who don't want software > fallback should be using hardware-protected keys, and hwcrhk will not > offer software fallback in those cases, since the key material isn't > available in plaintext outside the hardware module. Only software keys > can use fallback, and it seems quite reasonable for them to do so. Well I think it depends if your hardware could be used for the purposes of scalability and throughput. If so, this approach is a naive way to "improve the user experience" because in reality it blows away all attemps by the architect/admins to have any congestion management. With respect, these are the only people who have the budgets and time to think about buying dedicated crypto hardware anyway, right? <technical rant> So if you choose the number of accelerators to address what you see as appropriate resourcing for SSL/PKC demands, and you resource your web-server (or whatever) hosts to cover what you foresee as appropriate for web/application/accelerator-"controller" purposes, then how do you keep an overload in one component from bringing down the rest? I see two possible causes for hardware failure. If the hardware fails because of bugs, all bets are off. If it fails because it's overloaded and input queuing is full, then the controller should somehow propogate this condition by applying its own backpressure, either through suspending client requests or dropping them. The last thing you would want is for the controller to suddenly spend 100% CPU spinning on the very same RSA operations that you purchased the specialised hardware for. In particular, that can cause the host to lose cycles that it should be using for controlling hardware and performing web/app-data duties, so the problem magnifies itself, rinse and repeat - the entire architecture can drown because one component (PKC capacity) overloaded. Stable architectures allow temporary and specific error conditions (such as not having enough PKC grunt for your 9am https peak-time) to pass without cascading into a catastrophic burial of your whole architecture. If the same servers are running clear-text services (http, smtp, pop, nfs, [whatever] ...) then "falling back to software" is another way of saying "taking a ncipher hardware overload and turning it into a full scale server architecture overload". </technical rant> Rant over - this will only affect users of ncipher hardware, and once 0.9.8 is out I won't have any control over your engine implementations beyond providing these sorts of guidelines anyway. So you/ncipher should ultimately work this out for yourselves, I've said my piece. Provided you allow for this behaviour to be controlled from both inside and outside applications, I will resist dictating what the default should be. > Based on that, do you still think that the change in behaviour is > serious, as opposed to simply a bug-fix/enhancement? There's certainly > no change in security boundaries involved. As you said, the security arguments are addressed by whether the key material is even available in software or not. My issue is about the "principle of least migraine". People rarely find out in advance how their architectures will react to higher-than-capacity demand (eg. DDoS), and having a threshold condition implicit in to your ENGINE's default that would cause the entire server farm to start spinning on RSA operations when this happens would be a nasty surprise (IMHO) for any admin. If this weren't the case, surely the drivers for your hardware would perform fallback operations in software rather than having the API return errors? > I've submitted the patch with software fallback enabled (for software > keys only, since nothing else is possible) by default. However, if you > would still prefer it the other way round, I won't make that stand in > the way of having the facility available. Perhaps just think on what I've said and/or discuss it with others before deciding how you really want this to behave "out of the box". (Pun intended :-). Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.geoffthorpe.net/ ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
