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

Paul Hoffman <paul.hoffman@vpnc.org> Wed, 22 January 2014 16:28 UTC

Return-Path: <paul.hoffman@vpnc.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 6C7891A014B for <dsfjdssdfsd@ietfa.amsl.com>; Wed, 22 Jan 2014 08:28:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level:
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] 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 rI7G7iU3EaXI for <dsfjdssdfsd@ietfa.amsl.com>; Wed, 22 Jan 2014 08:28:45 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 53DF21A035D for <dsfjdssdfsd@ietf.org>; Wed, 22 Jan 2014 08:28:45 -0800 (PST)
Received: from [10.20.30.90] (50-0-66-198.dsl.dynamic.sonic.net [50.0.66.198]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id s0MG8Xx9096042 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 22 Jan 2014 09:08:34 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-198.dsl.dynamic.sonic.net [50.0.66.198] claimed to be [10.20.30.90]
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
Content-Type: text/plain; charset="us-ascii"
From: Paul Hoffman <paul.hoffman@vpnc.org>
X-Priority: 3 (Normal)
In-Reply-To: <e309a1b8c4a77ce1da4adfab1fc1db37.squirrel@www.trepanning.net>
Date: Wed, 22 Jan 2014 08:28:41 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <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>
To: Dan Harkins <dharkins@lounge.org>
X-Mailer: Apple Mail (2.1827)
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: Wed, 22 Jan 2014 16:28:46 -0000

On Jan 22, 2014, at 8:13 AM, Dan Harkins <dharkins@lounge.org> wrote:

>  "Ask your OS" is putting faith in the guy that wrote the relevant code
> in your OS.

Yes, exactly.

> It might be a reasonable leap but it's a leap nevertheless.

We put faith in the (~85%) guy for all the other crypto code as well, so I don't see the leap.

> Recent events should tell us that we should not trust a single source for
> these things (even if we are told that this single source is actually the
> output of a bunch of uncorrelated sources of entropy being mixed up).

That's one interpretation. Another is that attackers will look for bad implementations and use those as best they can.

>  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".

--Paul Hoffman