Re: [Cfrg] how can CFRG improve cryptography in the Internet?

Tom Ritter <tom@ritter.vg> Wed, 12 February 2014 00:57 UTC

Return-Path: <tom@ritter.vg>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0621A063F for <cfrg@ietfa.amsl.com>; Tue, 11 Feb 2014 16:57:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level:
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, LOTS_OF_MONEY=0.001, 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 aWJP4As55Pnh for <cfrg@ietfa.amsl.com>; Tue, 11 Feb 2014 16:57:56 -0800 (PST)
Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id B433D1A07A2 for <cfrg@irtf.org>; Tue, 11 Feb 2014 16:57:56 -0800 (PST)
Received: by mail-pd0-f174.google.com with SMTP id z10so8178809pdj.5 for <cfrg@irtf.org>; Tue, 11 Feb 2014 16:57:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/8f0NSx39MTUQnsHNDV1WtQTHzezIz5LZqmq3NhreSI=; b=ab5eN2lc916YP/bDwDkcOEV5aQI7+JGQ8JDPbdX7gjB6BfgLkoQBPWCHVgKKPuk2Qr E173yX8TPn0802IL1gRyd41aGnY5mgGvQUAxZrMWfnSBuwJwd9u13DiECnLNHUUsbPZs QdHEMb7DsV1lWV5OW/9lV6OcKL6FwgoIy3g+4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=/8f0NSx39MTUQnsHNDV1WtQTHzezIz5LZqmq3NhreSI=; b=kYClUWGlUJbDk4TyjpRMEwgj3HGePi1xObcD4nF5+xYNkV9ERyVmgi4ti/Ll8/nPS1 4KmJ3wBqzOhhP/MXROUv5Cdrx5b/9zQnfke2v60WKZuwYmkCjWa+J4/Q0cDsaXdpOsu4 rH7+i9TVA15e6f+jLxUmIQs3A7WCeidQqcU0p0oF21gahcizJonqb+WEqqVephdw9+Qi igVcUvR1REXG2/J1mhPDf43lRECwf4E2YQgaY+y4UyhMEMOXjHf/9zU2RJuu+9yREkFn RQ78zITU02nIsqhgeCufIDQmFHKvXiybI0G+tsokZOIuSGS+dsbUW6XTJSH+lbOHV7sx kWGQ==
X-Gm-Message-State: ALoCoQm6VWPyvnX+dfDc9fweP0x2BTx3jv0Jxrw7hc8xgOZNePflvhzeMjaRniTiU+211ZxxTu7l
X-Received: by 10.66.192.74 with SMTP id he10mr35939875pac.126.1392166676074; Tue, 11 Feb 2014 16:57:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.211.169 with HTTP; Tue, 11 Feb 2014 16:57:36 -0800 (PST)
In-Reply-To: <52F52E2D.8090104@cisco.com>
References: <CACsn0ckOL8xdp5z7DdB9wyHhFpax0DhVXjsUMuGj39HgKk4YBA@mail.gmail.com> <52f50c59.aa1b8c0a.77c0.4985SMTPIN_ADDED_MISSING@mx.google.com> <CACsn0cnYkDwyAdwdf0+-JtksWu4NhKPr3L2emG2b3kFDe5v6hg@mail.gmail.com> <52F52E2D.8090104@cisco.com>
From: Tom Ritter <tom@ritter.vg>
Date: Tue, 11 Feb 2014 19:57:36 -0500
Message-ID: <CA+cU71kjvb8bfqxon+_TSpkf=3kQU8e-H0MO9bXARGOprCBF1Q@mail.gmail.com>
To: David McGrew <mcgrew@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: "cfrg@irtf.org" <cfrg@irtf.org>, "nmav@gnutls.org" <nmav@gnutls.org>
Subject: Re: [Cfrg] how can CFRG improve cryptography in the Internet?
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Feb 2014 00:57:58 -0000

If I look at where we are now (well, I look at the bad parts of it) -
and  I look back at how we could have avoided being in the bad shapes
we are, the following comes to mind.


Small-Key RSA has taken too long to deprecate. RSA512, RSA1024.
RSA1024 is going to be used in some applications (payment devices) for
the next several years.  What would accelerate their deprecation? I've
spoken to numerous folks, and while they're all quite familiar with
the GNFS, no one is willing to go record with estimates. Perhaps the
CRFG could estimate computation needs, and costs for factoring RSA
1024 and 2048, and reevaluate it every so often. There's a difference
bewteen "The NSA can pobably factor RSA1024" and "This group of
cryptographers think we can factor it if we have $2 Million".
(Especially if someone has $2M and wants to have a go at it.)


SSL Devices have caused extraordinary upgrade pains. 0-Byte Record
Sizes, Version Intolerance, Suite & Extension Intolerance. Rigorous
test cases for these may have prevented these.  At the very least, we
wouldn't _still_ be generally ignorant about what vendors and firmware
versions are intolerant. Public pressure could help get these resolved
sooner.


We _still_ don't have a general purpose, largely complete SSL
certificate deployment for testing certificate validation. And lord
knows we have enough incorrect certificate validators.


We focus on content confidentiality. Maybe we don't care about sender
or receiver anonymity. (I do, a lot of folks do, but maybe this group
doesn't.) But if we do, we could work on that.


Similarly, there are very few designs (one?) for mutually distrusting
centrally managed architectures. In Certificate Transparency, you have
N logs all run independently asserting their view of things. What if
you had N logs talking to each other and voting to assert one
consensus document?


How about remote attestation of servers so we can assert they are
running the software stack (and web application) they purport to be?


Just some thoughts.
-tom