TAP 6 - Include specification version in metadata

[vladimir-v-diaz]

Initial draft of TAP 6 posted to mailing list on Oct. 6, 2016 by David Lawrence
https://groups.google.com/forum/#!topic/theupdateframework/iDdRsl-gUII

[ecordell]

Extra :?

[ecordell]

What types of change to the spec constitute a spec_version change?

What should a client do if it sees fields defined in a spec_version different from the listed spec_version?

What does a client that supports v1 do when it sees a v1.1? Give up, since it doesn't know the security implications of the .1 change?

Does the version being in the signed portion of the metadata adequately mitigate downgrade attacks?

The TAPs currently consider backwards compatibility in terms of clients that support the TAP and clients that don't. In all of those cases, the client makes decisions based on the data it sees, not the stated spec version. The motivating example is not an issue for newer clients, which ignore the deprecated field.

My current thinking is that if a TAP's changes are backwards-compatible, this does not constitute a need for a version change. Most changes can probably be backwards compatible, only those that change "protocol" like order of metadata downloading or types of metadata files would need to break.

Thoughts?

[vladimir-v-diaz]

What types of change to the spec constitute a spec_version change?

I think any accepted TAP that introduces a backwards incompatibility warrants a change to the specification's major version number. That is, the X in version number X.Y. For example, TAP 3 (multi-role delegations) should require a change to the X. For TAP 7 (Conformance testing), the Y would change and imply that it's a backwards compatible change to the specification.

What should a client do if it sees fields defined in a spec_version different from the listed spec_version?

Are you asking what should a client do if the format of metadata, that's supposedly for a specific spec_version, is not valid? For example, metadata for spec_version: 1.2 requires a terminating field, but the 1.2 metadata downloaded by the client does not include the required terminating field.

I think in this case, the client should reject the metadata as improperly formatted and raise an exception. I think the client should only reject major version numbers that it doesn't support/recognize. Metadata with varied minor version numbers should be safe to parse by the client.

What does a client that supports v1 do when it sees a v1.1? Give up, since it doesn't know the security implications of the .1 change?

See above. It shouldn't give up if it's a minor version change. However, unsupported major version numbers should be rejected and cause an exception.

My current thinking is that if a TAP's changes are backwards-compatible, this does not constitute a need for a version change. Most changes can probably be backwards compatible, only those that change "protocol" like order of metadata downloading or types of metadata files would need to break.

I agree.

Please note that this is only my opinion, and I haven't discussed them with the rest of the team.

[JustinCappos]

On Wed, Jan 25, 2017 at 5:03 PM, Vladimir Diaz ***@***.***> wrote: What types of change to the spec constitute a spec_version change? I think any accepted TAP that introduces a backwards incompatibility warrants a change to the specification's major version number. That is, the X in version number X.Y. For example, TAP 3 (multi-role delegations) should require a change to the X. For TAP 7 (Conformance testing), the Y would change and imply that it's a backwards compatible change to the specification.

I agree, with the proviso that when we say "backwards compatible", we really mean "behavior we intend to have outdated (version X.*) clients". The rest seems good to me.

[vladimir-v-diaz]

Okay, I will update the TAP to explain how specification version numbers change when a TAP is implemented.

[awwad]

@ecordell

What does a client that supports v1 do when it sees a v1.1? Give up, since it doesn't know the security implications of the .1 change?

That's a good question! If we go with this behavior that @vladimir-v-diaz suggested:

"It shouldn't give up if it's a minor version change. However, unsupported major version numbers should be rejected and cause an exception.")

then we should make sure that we never release a specification version X.Y where interpretation as if it were version X.Z (Z<Y) by a client familiar with X.Z might result in insecure or undesired behavior.

In other words, regardless of whether or not the metadata "format" has changed, if the expected behavior changes in such a way that the meaning of new metadata with the same text has changed, then the major version number for the metadata must be increased, because we cannot allow an old client to misunderstand new metadata.

For example, reversing the default value of terminating (used to be backtracking) from False to True, must result in a change to the specification's major version number so as to prevent old clients from misinterpreting the new metadata (They should reject it instead.).

[vladimir-v-diaz]

@JustinCappos
A word, or two, might be missing from the quote you provided: "behavior we intend to have outdated (version X.*) clients"

Are you saying that a change to the spec's minor version is only backwards compatible for clients within the same major version? I originally said, "... the Y would change and imply that it's a backwards compatible change to the specification" Are you pointing out that the use of specification at the end of the sentence is unclear?

[vladimir-v-diaz]

TAPs that have been assigned a TAP number will now be merged into the "master" branch. This does not mean that the merged TAP has been accepted, only that the proposed change (with potential tweaks) is likely to be incorporated into TUF.

We'll likely continue to comment on the pull request after it's been closed, so that we can easily comment on specific lines of the TAP.

@endophage Thanks for submitting TAP 6!

[JustinCappos]

On Fri, May 19, 2017 at 11:32 AM, Vladimir Diaz ***@***.***> wrote: TAPs that have been assigned a TAP number will now be merged into the "master" branch. This does not mean that the merged TAP has been accepted, only that the proposed change (with potential tweaks) is likely to be incorporated into TUF.

I would say instead that merging a TAP means it is worth having a permanent / fixed TAP number to point to this discussion. Moving from 'draft' to 'accepted' status is what means it is likely to be merged with tweaks.