[Trans] Extensibility and algorithm agility

Phillip Hallam-Baker <hallam@gmail.com> Wed, 12 March 2014 12:57 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id BD06C1A0986 for <trans@ietfa.amsl.com>; Wed, 12 Mar 2014 05:57:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id OvdIrRRcBxjZ for <trans@ietfa.amsl.com>; Wed, 12 Mar 2014 05:57:54 -0700 (PDT)
Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 4ECEF1A096E for <trans@ietf.org>; Wed, 12 Mar 2014 05:57:54 -0700 (PDT)
Received: by mail-la0-f52.google.com with SMTP id ec20so6702611lab.11 for <trans@ietf.org>; Wed, 12 Mar 2014 05:57:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=iCWAYEL5ruXjfpU4cjStcl8svfofLREtCrIh8xWjWqs=; b=KQM25LRIwmg3rLJtxdrYWWt4viSjptzKmxKFlYmweBYsarkeelRtaBlRcneUqrDK4B 3aiP4LeMH8H149FXYHFGL7znFw0GSBGL2p7PNBxUuSF+/lh2kLjTs7jW1siX57BiFKds 61MVzRD0uxOu80GyYiAD6NvTV5P5mhdyX6EPFZA6bUHrTPBDHmdr2xeAmPObm43eIBAC 3hbnIMS1qKVk8iRseqvdHoW6M8+S+jNoUgCL34bujmDTz90b+QCM6xkjhkZBnY//YBTO /fl3RxbOnt8q9pUBeEMsT9VdrMMB25qWqFBGVm+uh9DCWX+f0D+QC+z+x+R0zAxp0Sv2 jeYQ==
MIME-Version: 1.0
X-Received: by with SMTP id df5mr1785489lbb.36.1394629067446; Wed, 12 Mar 2014 05:57:47 -0700 (PDT)
Received: by with HTTP; Wed, 12 Mar 2014 05:57:47 -0700 (PDT)
Date: Wed, 12 Mar 2014 08:57:47 -0400
Message-ID: <CAMm+LwjpCGA4Hc-cjMWZsgLQWkxHc-j3Z9fyqALCJVqXpSpzNg@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: "trans@ietf.org" <trans@ietf.org>
Content-Type: multipart/alternative; boundary="001a1135f7ac289dc504f4686235"
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/PpC_tNEI8njONrNZS3_SiXWKF0s
Subject: [Trans] Extensibility and algorithm agility
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Mar 2014 12:57:56 -0000

One of the areas that we have to address to go to proposed standard is
algorithm agility. Another area we can skip but probably should not is
strategy for extensibility so as to be able to apply TRANS to other areas.

On algorithm agility we have to consider questions like:

* Using algorithms other than SHA-2-256 for the tree.
* How does a client discover which algorithm is being used.
* What sort of algorithm substitution attacks become possible.

* How does a client make a selection where a choice of signing algorithm is
offered for the SCT heads?

Questions we don't have to answer but should probably consider include:

* How would alternative log topologies be identified, for example skip
* Do we want to permit the size of the tree to be bounded by periodically
rolling to a new log? If so we probably want to have a mechanism for
incorporating the old log as the stating point of the new.

Extensibility is an area where we can and quite probably should punt. But
we do need to describe a punting strategy.

The TLS data encoding used in TRANS is a placed based encoding that can
only be decoded by reference to the corresponding schema. That makes it
very hard to use it in an application where extensibility is being used.
The extensions end up being encoded in opaque extension blobs. This is one
of the many parts of ASN.1 that don't work either and is one of the reasons
that JSON has become much more interesting. JSON is after all simply RFC822
headers with braces added to allow recursive structures to be represented...

When I started looking at this, I had thought that the TRANS data
structures are fixed because any changes would be reflected deep in the
Merkle tree. However looking at the situation again, it seems to me that
just as a tree head could be signed with a different algorithm, a different
encoding for the SCT data structure could be communicated in the same way.

Another, rather more minor issue is version numbering. At the moment there
is (or appears to be) one version number for the SCT structures and the
protocol. But there is no reason why these should be linked or even that
every data structure should need to be changed if there is a rev. When we
talk about X.509v3 we are actually talking about v2 of the CRL structure.

This matters because the v1 protocol does not have a mechanism for
specifying what the version of the data structure being requested is.

Website: http://hallambaker.com/