Re: [Trans] Extensibility and algorithm agility

[Ben Laurie <[e-mail]>]

On 12 March 2014 12:57, Phillip Hallam-Baker <[e-mail]> wrote:
> 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?

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.

> Questions we don't have to answer but should probably consider include:
>
> * How would alternative log topologies be identified, for example skip
> lists?

See above.

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

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

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.

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

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.