Subject: [Trans] Extensibility and algorithm agility

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 12 Mar 2014 08:57:47 -0400

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
lists?
* 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/

---

From: Ben Laurie <[email-masked]>
Date: Thu, 13 Mar 2014 18:08:22 +0000

> offered for the SCT heads?

Because SCTs can be embedded in certificates, there's no hope of being
agile. All certs would have to be re-issued and the re-issued certs
would have to be deployed. Realistically, this is not going to happen.

Thus, you change algorithms by creating new logs with different metadata.

> * How would alternative log topologies be identified, for example skip

See above.

> incorporating the old log as the stating point of the new.

This one may be worth addressing. But again, it can also be addressed
by simply starting a new log.

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

I agree that different encodings are possible, and somewhat
straightforward, but there are a bunch of other moving parts - for
example, should you have SCTs or just go straight to
proof-of-inclusion. What about including proof-of-STH-linkage. And so
forth.

None of these are possible with TLS certs for various reasons, but
clearly are for other scenarios, particularly where there is no
legacy.

> specifying what the version of the data structure being requested is.

Yes it does: its in the URL. But I agree that the STH and the leaves
should have separate versions. I thought there was a ticket for this
already.

---

From: Eran Messeri <[email-masked]>
Date: Fri, 14 Mar 2014 10:17:50 +0000

On Thu, Mar 13, 2014 at 6:08 PM, Ben Laurie <[email-masked]> wrote:

> only
> structures
There is now: http://trac.tools.ietf.org/wg/trans/trac/ticket/12

>
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>