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

"Dan Harkins" <dharkins@lounge.org> Wed, 22 January 2014 18:40 UTC

Return-Path: <dharkins@lounge.org>
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 E83381A0158 for <dsfjdssdfsd@ietfa.amsl.com>; Wed, 22 Jan 2014 10:40:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Level:
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham
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 wBgCXpTZM8CI for <dsfjdssdfsd@ietfa.amsl.com>; Wed, 22 Jan 2014 10:40:35 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 922CC1A011C for <dsfjdssdfsd@ietf.org>; Wed, 22 Jan 2014 10:40:35 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 1D9E41022404A; Wed, 22 Jan 2014 10:40:34 -0800 (PST)
Received: from 205.201.168.123 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 22 Jan 2014 10:40:34 -0800 (PST)
Message-ID: <eaa6cc3f162888d40834d61907256a26.squirrel@www.trepanning.net>
In-Reply-To: <F6B381C1-089D-4723-9A2C-7937C6C74EFB@vpnc.org>
References: <52DD996F.3040708@cs.tcd.ie> <CAF4+nEHEWaSr3HMuGtQ=vQzuuhkTo2uNpedUTNgmT5NsWRsTfA@mail.gmail.com> <30316745-8091-46AD-95A1-407757489FF9@vpnc.org> <e309a1b8c4a77ce1da4adfab1fc1db37.squirrel@www.trepanning.net> <F6B381C1-089D-4723-9A2C-7937C6C74EFB@vpnc.org>
Date: Wed, 22 Jan 2014 10:40:34 -0800 (PST)
From: "Dan Harkins" <dharkins@lounge.org>
To: "Paul Hoffman" <paul.hoffman@vpnc.org>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: dsfjdssdfsd@ietf.org, Dan Harkins <dharkins@lounge.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: Wed, 22 Jan 2014 18:40:37 -0000

On Wed, January 22, 2014 8:28 am, Paul Hoffman wrote:
> On Jan 22, 2014, at 8:13 AM, Dan Harkins <dharkins@lounge.org> wrote:
>>
>>  I see value in draft-eastlake-randomness3 and I also see value in an
>> Informational RFC on a good DRBG for those who feel the need to have
>> a belt as well as suspenders.
>
> We disagree here; the chance that the person writing the belt will get it
> wrong and make their crypto trivial to break for an attacker who knows the
> weakness seems much higher to me than the change that the OS got it wrong.
> Yes, we could put some warning at the front of the new document about
> this, but that warning will be ignored by programmers who are sure they
> know this stuff.
>
> I could see writing something that forces them to mix in randomness from
> the OS to their possibly-borked DRBG in the hopes that at least that step
> will fix their problems. However, if we do that, nearly all the
> interesting technical stuff in the current document is just confusing
> fluff. The new document reduces to "use an HMAC with the randomness from
> your OS as the key and whatever stuff you think is random as the data;
> done".

  To minimize the possibility of someone borking their DRBG implementation
we can include some test vectors-- instantiating with A produces state of
B; reseeding of state B with C produces state D; generating with state D
produces E, etc.

  The more people that implement anything will increase the probability of
a broken implementation somewhere, I definitely agree. But it is an accepted
economic truth that relying on a single source for anything is a bad idea.

  Dan.