Re: [Trans] Extensibility and algorithm agility

[Eran Messeri <[e-mail]>]

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

> 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.
>
There is now: http://trac.tools.ietf.org/wg/trans/trac/ticket/12

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