Re: [dsfjdssdfsd] Any plans for drafts or discussions on here?

Krisztián Pintér <pinterkr@gmail.com> Thu, 23 January 2014 20:40 UTC

Return-Path: <pinterkr@gmail.com>
X-Original-To: dsfjdssdfsd@ietfa.amsl.com
Delivered-To: dsfjdssdfsd@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58A761A00C5 for <dsfjdssdfsd@ietfa.amsl.com>; Thu, 23 Jan 2014 12:40:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lehlccyDykRf for <dsfjdssdfsd@ietfa.amsl.com>; Thu, 23 Jan 2014 12:40:11 -0800 (PST)
Received: from mail-ea0-x232.google.com (mail-ea0-x232.google.com [IPv6:2a00:1450:4013:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id B71641A0197 for <dsfjdssdfsd@ietf.org>; Thu, 23 Jan 2014 12:40:10 -0800 (PST)
Received: by mail-ea0-f178.google.com with SMTP id a15so631320eae.9 for <dsfjdssdfsd@ietf.org>; Thu, 23 Jan 2014 12:40:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:message-id:to:cc:subject:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=csTLfGH+095QFNzAaqOMPlGvwOiaLeKlTLVT7x6YzHQ=; b=SrQK74GkSjQj7eWxW/CiMPoVYpP4nKKpTrvC646NaEpycfqEKfFVLDbxPvU7wMuD2U 8BG6V7BrSDkQmT0+IDua643xsbViIcwchAcrK1Rbfi0nF4PRqY6IeTD3/cr2esLTEbUG vWJPXFRHX8uii/D6UHWsTp9Kse3SRjhe7yLynIyGAbGSUkPc3WTXf1LmHf503oQOUhGb t9OpfOMT0RGfFMDeapNRu8MnVqQ+kY147UDeSE+bpCTHfuLNW1pDN36QI+XjpwFAacgQ onxJThwCuOhw/Y75pMOR1/5GlFUjhhJUn2gzrdLvE1i2PkZ7SYGRn/Lxlt77ojY6m/G9 ABqw==
X-Received: by 10.14.202.8 with SMTP id c8mr4585433eeo.88.1390509609397; Thu, 23 Jan 2014 12:40:09 -0800 (PST)
Received: from [192.168.2.244] (catv-176-63-52-22.catv.broadband.hu. [176.63.52.22]) by mx.google.com with ESMTPSA id b41sm42942939eef.16.2014.01.23.12.40.08 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 23 Jan 2014 12:40:08 -0800 (PST)
Date: Thu, 23 Jan 2014 21:40:20 +0100
From: =?windows-1252?Q?Kriszti=E1n_Pint=E9r?= <pinterkr@gmail.com>
X-Priority: 3 (Normal)
Message-ID: <15541579.20140123214020@gmail.com>
To: ietf@hosed.org
In-Reply-To: <03f201cf17ee$e34ccbf0$a9e663d0$@hosed.org>
References: <52DD996F.3040708@cs.tcd.ie> <CAF4+nEHEWaSr3HMuGtQ=vQzuuhkTo2uNpedUTNgmT5NsWRsTfA@mail.gmail.com> <30316745-8091-46AD-95A1-407757489FF9@vpnc.org> <1737731959.20140122185149@gmail.com> <03f201cf17ee$e34ccbf0$a9e663d0$@hosed.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cc: dsfjdssdfsd@ietf.org
Subject: Re: [dsfjdssdfsd] Any plans for drafts or discussions on here?
X-BeenThere: dsfjdssdfsd@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "The dsfjdssdfsd list provides a venue for discussion of randomness in IETF protocols, for example related to updating RFC 4086." <dsfjdssdfsd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dsfjdssdfsd>, <mailto:dsfjdssdfsd-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dsfjdssdfsd/>
List-Post: <mailto:dsfjdssdfsd@ietf.org>
List-Help: <mailto:dsfjdssdfsd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dsfjdssdfsd>, <mailto:dsfjdssdfsd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jan 2014 20:40:12 -0000

ietf@hosed.org (at Thursday, January 23, 2014, 4:54:59 AM):

> The problem with relying on the OS is that you're not always sure what the
> OS is doing.  Example:  If I run Linux under ESXi on a headless server, with
> an SSD for a disk, and I use the Ethernet NIC built into the motherboard,
> where is the entropy for /dev/random coming from?

you do know what the OS does, you have either a source code, or at
least a statement that everything is fine. you choose the OS with this
knowledge in mind.

it is another issue that in certain systems, the opsys might be not
good enough. but i doubt that you can write RFC that is of any use for
such special systems. plus, it is still advisable that you only
implement your additional entropy collection, and just feed it back to
the OS.


> Those of us who deal with FIPS 140 and Common Criteria are now being asked
> to document entropy sources,

we need to make clear what the goal is. me being new here, maybe i
just missed it, but i'm not sure what do we want:

a, building a secure system
b, building a system that can be marketed as secure
c, building a FIPS compliant system

because i claim that these are very different. if you want to be FIPS
compliant, you probably need to do a whole sort of silly things that
helps nobody in no way. but again, this won't be too much aided with
an RFC, or any "best practices" document. nor i personally care much.

marketability of a system can be affected by any number of things,
probably boasting a lot of numbered acronyms, like RFCs as well. but
i'm not into this kind of psychology.

but if we aim at security, the OS can provide the best service here.
yeah, windows don't, but really, how secure your application will be
on windows anyway? you don't need to go over that level.


> The various DRBGs are fine IMHO for handing out bits of random to an
> application, and lacking anything better today I would certainly encourage
> developers to use one.  But the question is how do we seed the DRBG in the
> first place?  

i certainly agree that we are well equipped with good DRBGs (which
linux still refuses to include, forget about windows).

do you happen to know fortuna, and especially its entropy collection
policy? i think it is kind of a cool concept, except does not really
solve the problem you mentioned before, namely early entropy
gathering.

one more point: it is not only about creating good random. you also
need to protect it. what sources of entropy do you have that other
processes on the same system don't? what information do you leak
during the collection phase? a little bit harder problem than a DRBG.