[147763] in cryptography@c2.net mail archive
Re: [Cryptography] [RNG] on RNGs, VM state, rollback, etc.
daemon@ATHENA.MIT.EDU (ianG)
Sun Oct 20 12:22:16 2013
X-Original-To: cryptography@metzdowd.com
Date: Sun, 20 Oct 2013 12:28:32 +0300
From: ianG <iang@iang.org>
To: cryptography@metzdowd.com
In-Reply-To: <20131020033658.GK2976@mournblade.imrryr.org>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
On 20/10/13 06:36 AM, Viktor Dukhovni wrote:
> On Sat, Oct 19, 2013 at 05:22:55PM -0400, Jeffrey I. Schiller wrote:
>
>> That is a value judgment, one where you let security be more important
>> than anything else. That is a mistake.
>>
>> There are plenty of applications where it is better to have things
>> work then to have them not work in the name of security. Consider an
>> embedded controller running a critical resource (like your heart
>> pacemaker). It is better to have it fail by using poor entropy then to
>> fail completely and leave you dead.
>
> Indeed.
>
> Some years back a few brave users of Postfix attempted to use the
> GnuTLS OpenSSL API compatibility layer to run Postfix over GnuTLS.
>
> It was found that the GnuTLS library would call exit() if it did
> not find an entropy on startup instead of returning an error to
> the application. This approach was deemed safer by GnuTLS. When
> this was discovered, Postfix dropped support for the GnuTLS OpenSSL
> emulation. From the TLS_README file:
>
> NOTE: Do not use Gnu TLS. It will spontaneously terminate a
> Postfix daemon process with exit status code 2, instead of
> allowing Postfix to 1) report the error to the maillog file,
> and to 2) provide plaintext service where this is appropriate.
>
> I don't know whether this has changed since, but I concur that the
> security/availability tradeoff is not always clear-cut.
Good example. I'm going to get off the fence and say that the RNG
should never block.
The security/availability tradeoff is *always* a business decision. In
the above example, it is a decision of Postfix.
The problem for the tool above, TLS, is that it doesn't know the
business, nor the business decisions. So it tries to make its product
as universal as it can. Which means, in the eyes of the tool-maker, it
should be as secure as it can be.
But not more. The trap is sprung when in order to make the product that
little bit more secure, and defeat the bogeyman threats, an impractical
requirement is loaded onto the business.
Examples abound:
* In the above, Gnu TLS exits. Bad.
* With RNGs, they block. Not good because programmers can't deal
with it, and blocked startup sequences can cause deadlocks, and and
and... (I recall that FreeBSD 'fixed' this by making /dev/random never
block, and equivalent to urandom. Highly controversial at the time.)
* With SSL, to solve the bogeyman MITM, they imposed certs and turned
off opportunistic opportunities -- and consequently split the security
for the web, and made it always vulnerable to an easy downgrade attack.
A billion or so of damages for that 'perfect' decision.
A product should be as secure as it can be *at no cost to the user*, but
no more. Beyond that, the user has to make the decisions, and if the
user really cares, the user can read the doco and understand the
limitations.
If they don't do their research, and they need to, then they are
negligent. It is not up to the tool to predict how negligent or needy
the caller is. There is no such thing as perfect.
iang
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography