Rename to DSSE, update PAE, mark as v1 #37

MarkLodato · 2021-06-04T17:16:21Z

Renames to DSSE (fixes Choose a more specific name than "signing-spec" #16)
Switches to a simpler PAE (fixes Create a reference implementation and test vectors #28)
Marks as v1 (What comes before v1.0? #21)
Clarifies parsing rules, particularly around ignoring unrecognized fields.

Once this is submitted, we can rename the repo and tag as v1.0.0.

The name is now Dead Simple Signing Envelope.

The previous PAE required binary encoding, which can be tricky in some langauges. The new PAE is pure ASCII so it can be implemented very easily in almost any language.

adityasaky

This looks reasonable to my eyes. I'd like to hear thoughts from some associated folks as well, as we move to 1.0.0.

@mnm678 @SantiagoTorres @trishankatdatadog @JustinCappos

adityasaky · 2021-06-08T16:46:42Z

Also, is this blocked by any of #33, #34, #35, #36? I'm uncertain of the impact they'd have on the version number.

I think #35's consensus appears to be to distribute the pertinent information as part of the key rather than the signature.

trishankatdatadog

LGTM! I really, really like how dead simple it is, really lives up to its name, greatly reduces scope for errors.

A few comments:

Just to convince that we can still do canonical JSON, would you mind terribly much including an example on how to encode and decode a TUF or in-toto 1.0.0 payload?
Am I understanding correctly that body is just an arbitrary sequence of bytes?
Could you briefly explain why not to specify a generic media type?

MarkLodato · 2021-06-09T11:36:41Z

Also, is this blocked by any of #33, #34, #35, #36? I'm uncertain of the impact they'd have on the version number.

I think #35's consensus appears to be to distribute the pertinent information as part of the key rather than the signature.

Let's decide #34, which is whether to include the version in the JSON envelope. (It is already in the PAE.)

Otherwise, I suggest saying no to #33, #35, and #36 for v1. The entire idea of DSSE is that it is simple and avoids the pitfalls of JWS. We shouldn't add anything until there is both a strong case for it and a clear guidance so that it won't be misused. In particular:

Design: Where to put timestamps in envelope? #33: It's not clear why the timestamp can't go in the payload. I say defer until a future version.
Communicating signing algorithm and parameters #35: The lack of algorithm is a security feature to avoid attacks.
Envelope headers #36: The lack of generic headers is a security feature to avoid misuse.

MarkLodato · 2021-06-09T12:09:05Z

Just to convince that we can still do canonical JSON, would you mind terribly much including an example on how to encode and decode a TUF or in-toto 1.0.0 payload?

No problem. I'll try to get to this soon.

Am I understanding correctly that body is just an arbitrary sequence of bytes?

Yes. Added "Arbitrary". Does that help?

Could you briefly explain why not to specify a generic media type?

Done. Please take a look at the latest commit.

MarkLodato · 2021-06-09T13:15:16Z

From #33, it sounds like the addition of a timestamp would not affect the PAE, thus adding it would not invalidate signatures. Therefore I recommend deferring to a future minor revision, e.g. v1.1, because it would be backwards compatible with existing clients (they can just ignore that field).

Speaking of which, do we need some guidance on whether or not it's OK to ignore fields?

mnm678 · 2021-06-09T14:04:34Z

Speaking of which, do we need some guidance on whether or not it's OK to ignore fields?

This might be fine to leave for a future minor version, but it would be nice to let implementers (or future spec versions) add additional fields that may be ignored by clients who don't support them. As long as security features are added to new major versions, this would make backwards compatibility easier.

MarkLodato · 2021-06-09T16:10:12Z

Just to convince that we can still do canonical JSON, would you mind terribly much including an example on how to encode and decode a TUF or in-toto 1.0.0 payload?

Actually, @trishankatdatadog, could you explain the reasoning for this request? We already have an example in the implementation directory showing the signing and verifying of an arbitrary payload. Why would canoncial JSON payload be significantly different?

MarkLodato · 2021-06-09T16:59:51Z

And I ask simply to prioritize my time, not because I think it's unreasonable.

trishankatdatadog · 2021-06-09T17:03:19Z

And I ask simply to prioritize my time, not because I think it's unreasonable.

No problem, understood. I think as long as someone else can quickly double check here, we are good to go. I'm 99% certain it will work, I just want to make sure we didn't miss anything.

Incidentally, how soon do you need a 1.0.0 while we are checking this? Do you have a blocker?

MarkLodato · 2021-06-09T17:36:11Z

No hard deadline. We're starting to see various projects implement this spec so it would be good to get this change through sooner rather than later to minimize the number of things that need to get cleaned up.

trishankatdatadog · 2021-06-09T17:44:30Z

Gabish. Let me look at your code tonight and tinker with it.

trishankatdatadog · 2021-06-10T04:51:24Z

Gabish. Let me look at your code tonight and tinker with it.

Unfortunately, I have to wake up early today, so this is not happening tonight, but hopefully later today...

trishankatdatadog · 2021-06-10T23:16:07Z

Unfortunately, I have to wake up early today, so this is not happening tonight, but hopefully later today...

Okay, so I finally understand how this works. I tested signing and verifying SecureSystemsLib-style Canonical JSON with DSSE. Interested readers can find the source code here. A few observations:

Signatures issued prior to DSSE are of course not going to be verifiable with DSSE, as DSSE also expects the payload type to be signed. So, there's no two ways about it, it's a breaking change that needs to be fixed with something higher-level like TAP 14 for TUF and I'm not sure what for in-toto (cc @adityasaky).
The payload for SecureSystemsLib for DSSE needs to be the literal Canonical JSON. Any SecureSystemsLib-compatible implementation must always write Canonical JSON back to disk in order for signatures from different roles/functionaries on the same exact payload to be verifiable.
Threshold signatures of course continue to work.
I need to think about whether DSSE does or should solve the exclusive ownership problem (or whether it is even applicable).

@mnm678 @SantiagoTorres @adityasaky @JustinCappos please fact-check me here, including my code, thanks.

mnm678 · 2021-06-11T12:34:09Z

1. Signatures issued prior to DSSE are of course not going to be verifiable with DSSE, as DSSE also expects the payload type to be signed. So, there's no two ways about it, it's a breaking change that needs to be fixed with something higher-level like [TAP 14 for TUF](https://github.com/theupdateframework/taps/blob/master/tap14.md) and I'm not sure what for in-toto (cc @adityasaky).

@trishankatdatadog That makes sense, changing the signature wrapper will make existing clients unable to parse the new metadata. TUF is amassing a collection of TAPs with breaking changes, so this could fit into an eventual 2.0.0 release, including TAP 14 for version management.

4\. I need to think about whether DSSE does or should solve the [exclusive ownership](https://www.bolet.org/~pornin/2005-acns-pornin+stern.pdf) problem (or whether it is even applicable).

This is an interesting question. I don't think we need exclusive ownership in TUF (or in-toto?). Delegations are processed top-down, so the reverse property shouldn't be needed.

adityasaky · 2021-06-11T22:08:25Z

I'm not sure what for in-toto

@trishankatdatadog ITE-5 requires implementations to support both envelopes, and the pseudocode shows how current envelopes must be handled. https://github.com/in-toto/ITE/blob/master/ITE/5/README.adoc#backwards-compatibility

However, there's probably a broader conversation here which likely belongs in an ITE-5 specific thread regarding how long implementations are expected to support both, I think? I may be wrong...

adityasaky · 2021-06-14T15:32:18Z

Taking stock, I think the only open discussion that's still being considered is #33. Am I correct? Where do folks stand on the rest of the changes here?

@trishankatdatadog , if I'm not mistaken, you've given your approval. @mnm678, @SantiagoTorres any overall thoughts? 😄

mnm678

LGTM! As you say @adityasaky, it would be good to decide about #33 before merging this as 1.0, but otherwise I think it's good to go.

trishankatdatadog · 2021-06-14T15:42:27Z

No, I haven't given my approval yet. I think it's good to go, but I just want to make sure the exclusive ownership problem doesn't apply, or is something that we solve on a lower-level (i.e., the cryptographic algorithm and schemes). Let me try asking Pornin and friends for advice.

dlorenc · 2021-06-15T13:48:25Z

This might be fine to leave for a future minor version, but it would be nice to let implementers (or future spec versions) add additional fields that may be ignored by clients who don't support them. As long as security features are added to new major versions, this would make backwards compatibility easier.

If we're not going to do #33 here I think @mnm678's suggestion would be good to have instead. I can think of lots of other info I want to stick on an envelope somewhere, simply allowing extra fields would be enough for now.

MarkLodato · 2021-06-15T14:21:46Z

If we're not going to do #33 here I think @mnm678's suggestion would be good to have instead. I can think of lots of other info I want to stick on an envelope somewhere, simply allowing extra fields would be enough for now.

Done. To clarify, this is about ignored unrecognized (and thus unauthenticated) fields.

Since this PR seems to have become everything we want for v1, I also added a new change that warrants review: allowing zero signatures. I think this is a logical thing to do since we allow multiple signatures, and one could always use a dummy signature to get around the ">= 1 signature" requirement. But I wanted to get feedback from you all first to make sure you agree with the change. (We'd like to use this for SLSA.)

mnm678

One minor comment, but LGTM

envelope.md

MarkLodato · 2021-06-15T17:37:05Z

Since this PR seems to have become everything we want for v1, I also added a new change that warrants review: allowing zero signatures. I think this is a logical thing to do since we allow multiple signatures, and one could always use a dummy signature to get around the ">= 1 signature" requirement. But I wanted to get feedback from you all first to make sure you agree with the change. (We'd like to use this for SLSA.)

Note: I reverted this change and moved it to #38.

wietse-gmail · 2021-06-17T13:02:18Z

protocol.md

-    le64(n) := 64-bit little-endian encoding of `n`, where 0 <= n < 2^63
+    ```python
+    PAE(type, body) := "DSSEv1 <len(type)> <type> <len(body)> <body>"
+    len(s) := ASCII decimal encoding of the byte length of s, with no leading zeros


Can you add that lt-type-gt and lt-body-gt have no leading or trailing space (just like the lengths have no leading zeros)

Just pushed an update. Does that help clarify (using + SP + to make it more clear that a single space is used)?

trishankatdatadog · 2021-06-21T04:45:44Z

No, I haven't given my approval yet. I think it's good to go, but I just want to make sure the exclusive ownership problem doesn't apply, or is something that we solve on a lower-level (i.e., the cryptographic algorithm and schemes). Let me try asking Pornin and friends for advice.

Ok, I read up exclusive ownership (EO). The problem is roughly as follows. Given an original public key from A, which used its private key to sign a message m with signature s, transformations 5 and 7 would destroy conservative and destructive EO respectively:

In transformation 5, we have a different public key from B fooling a validator into accepting m and s from A. (Not the worst thing ever, but concerning.) In transformation 7, we have a different public key from B fooling a validator into accepting m` from B but with s from A. (Definitely bad.)

The TLDR for us is that, assuming that TUF and in-toto clients have a known good copy of the appropriate root public keys (the root role for TUF and root layout functionary for in-toto), the EO problem should not apply to them, because they always used a fixed, known, and trusted public key A for any TUF role or in-toto functionary. However, DSSE should warn other client applications about the EO problem if they do not distribute public keys securely (especially using cryptosystems such as RSA and DSS that do not provide EO). I could have misunderstood something, so it would be good if someone could double-check my understanding.

trishankatdatadog · 2021-06-21T05:00:41Z

The TLDR for us is that, assuming that TUF and in-toto clients have a known good copy of the appropriate root public keys (the root role for TUF and root layout functionary for in-toto), the EO problem should not apply to them, because they always used a fixed, known, and trusted public key A for any TUF role or in-toto functionary. However, DSSE should warn other client applications about the EO problem if they do not distribute public keys securely (especially using cryptosystems such as RSA and DSS that do not provide EO). I could have misunderstood something, so it would be good if someone could double-check my understanding.

@pornin, would you mind terribly much checking my understanding here?

pornin · 2021-06-21T12:28:20Z

I don't know the context here, but, yes, this seems to be the correct understanding here. A signature algorithm can be seen as transferring "trust" from the public key to the signed data: IF there is a message m, and a signature s, and a public key pk, AND verify(pk, m, s) = true, THEN whoever controls the private key sk that matches pk must have been involved. Thus, if pk is "trusted", then that trust is conveyed to the message m. The gist of all the talk about exclusive ownership is that the trust does not goes into the other direction, i.e. there is no information flow FROM the message m TO the public key. For instance, there is no guarantee that s was originally produced with the signature algorithm, or that the public and private key existed at all at that time.

In PKI (X.509) contexts, where you have root public keys and intermediate CAs, and you verify certificate chains starting from the root, there is nominally no problem. You can run into trouble in some implementations, though, if you try to infer properties of the public key by looking at the signature and the message. In 2005, our example was revocation. In X.509, a certificate can be revoked or not-revoked; the revocation status can be obtained from a signed object (CRL or OCSP response) that is nominally issued (signed) by an authorized party, and there are conditions on who can sign it (e.g. an OCSP response is valid if it is signed by the same CA as the certificate whose revocation status is to be ascertained, or if it is signed by an "OCSP responder" whose certificate contains a specific tagging extension, and is signed by the CA). Trouble can happen if you begin to assume that revocation status is unique and well-defined, i.e. that if you find a CA with a public key that matches the signature on the certificate, and an OCSP response signed by that CA that says "this is not revoked", and then you begin to believe that the certificate is "not revoked" in absolute terms. Since signature algorithms, in general, do not ensure exclusive ownership, there could be another CA with a different public key and another OCSP response that instead says "this certificate is revoked". In other words, signatures guarantee a downward information flow ("this CA says this certificate is valid and not revoked, and I trust that because I trust that CA") but not an upward flow (you cannot conclude that "every CA matching that certificate must agree that it is valid and not revoked, even those I don't trust").

There have been a couple of recent papers that investigate these notions more thoroughly:

trishankatdatadog · 2021-06-21T19:10:53Z

I don't know the context here, but, yes, this seems to be the correct understanding here. A signature algorithm can be seen as transferring "trust" from the public key to the signed data: IF there is a message m, and a signature s, and a public key pk, AND verify(pk, m, s) = true, THEN whoever controls the private key sk that matches pk must have been involved. Thus, if pk is "trusted", then that trust is conveyed to the message m. The gist of all the talk about exclusive ownership is that the trust does not goes into the other direction, i.e. there is no information flow FROM the message m TO the public key. For instance, there is no guarantee that s was originally produced with the signature algorithm, or that the public and private key existed at all at that time.

In PKI (X.509) contexts, where you have root public keys and intermediate CAs, and you verify certificate chains starting from the root, there is nominally no problem. You can run into trouble in some implementations, though, if you try to infer properties of the public key by looking at the signature and the message. In 2005, our example was revocation. In X.509, a certificate can be revoked or not-revoked; the revocation status can be obtained from a signed object (CRL or OCSP response) that is nominally issued (signed) by an authorized party, and there are conditions on who can sign it (e.g. an OCSP response is valid if it is signed by the same CA as the certificate whose revocation status is to be ascertained, or if it is signed by an "OCSP responder" whose certificate contains a specific tagging extension, and is signed by the CA). Trouble can happen if you begin to assume that revocation status is unique and well-defined, i.e. that if you find a CA with a public key that matches the signature on the certificate, and an OCSP response signed by that CA that says "this is not revoked", and then you begin to believe that the certificate is "not revoked" in absolute terms. Since signature algorithms, in general, do not ensure exclusive ownership, there could be another CA with a different public key and another OCSP response that instead says "this certificate is revoked". In other words, signatures guarantee a downward information flow ("this CA says this certificate is valid and not revoked, and I trust that because I trust that CA") but not an upward flow (you cannot conclude that "every CA matching that certificate must agree that it is valid and not revoked, even those I don't trust").

Got it, thanks very much, Thomas, I think we're on the same page! @SantiagoTorres and I also agreed earlier today that it does not look like EO applies to applications like TUF and in-toto where there is a hierarchy of trust for exactly which public keys to use for which messages.

trishankatdatadog

Almost LGTM, thanks, just a few more things, please @MarkLodato:

Please clarify that DSSE by itself cannot and does not solve the exclusive ownership problem, and that applications must be careful to establish a secure hierarchy of trust for which public keys to use for which messages.
Please update your reference implementation to use the optional keyids to efficiently find which verifier/public key to use for which signatures (like so). This will help readers implement efficient implementations out of the box.

@SantiagoTorres @mnm678 am I being unreasonable here?

mnm678 · 2021-06-21T19:32:14Z

Almost LGTM, thanks, just a few more things, please @MarkLodato:

1. Please clarify that DSSE by itself cannot and does not solve the exclusive ownership problem, and that applications must be careful to establish a secure hierarchy of trust for which public keys to use for which messages.

This might fit well into a more general 'out of scope' section that could include DoS attacks, etc.

2. Please update your reference implementation to use the optional keyids to efficiently find which verifier/public key to use for which signatures ([like so](https://github.com/trishankatdatadog/signing-spec/tree/fde1e9e7a4b65e88edab896a7acc8904fc6c6e9a/implementation)). This will help readers implement efficient implementations out of the box.

I don't think the reference implementation needs to include the optional fields, at the very least I don't think that this is a blocker.

MarkLodato · 2021-06-21T19:50:15Z

@trishankatdatadog

Is ddb48b2 sufficient? We already say that PKI is out of scope, and exclusive ownership seems to be a property of PKI.
Implemented in 04e1715. I'm just using a fingerprint as an example, since the spec says that it is opaque. I agree it's valuable because it shows how the keyid filtering works.

trishankatdatadog · 2021-06-21T20:00:37Z

@trishankatdatadog

Is ddb48b2 sufficient? We already say that PKI is out of scope, and exclusive ownership seems to be a property of PKI.

At least we noted it, thanks. I wouldn't say EO is a property of PKI, but PKI helps to avoid EO problems.

Implemented in 04e1715. I'm just using a fingerprint as an example, since the spec says that it is opaque. I agree it's valuable because it shows how the keyid filtering works.

Wonderful, thanks! We can make this more efficient by being able to index verifiers by keyid, but this should work for now.

adityasaky · 2021-06-21T20:25:19Z

Thanks, @trishankatdatadog and @MarkLodato! I think we're good to merge and release?

MarkLodato · 2021-06-21T20:29:20Z

Yay! I'll do that now and tag.

adityasaky · 2021-06-21T20:30:39Z

Thanks a lot for all your work on this, @MarkLodato. 😄

adityasaky · 2021-06-21T20:31:52Z

I'm going to rename this repository in a moment. https://github.com/secure-systems-lab/dsse is what I have in mind.

MarkLodato · 2021-06-21T20:34:13Z

Sounds good to me!

adityasaky · 2021-06-21T20:35:23Z

Done! I think github mostly handles renames well, but some remotes may need to be updated.

MarkLodato added 3 commits June 4, 2021 13:11

Rename signing-spec to DSSE (secure-systems-lab#16)

1fecce3

The name is now Dead Simple Signing Envelope.

Use a simpler ASCII-based PAE (secure-systems-lab#27)

93903bf

The previous PAE required binary encoding, which can be tricky in some langauges. The new PAE is pure ASCII so it can be implemented very easily in almost any language.

Mark as version 1.0.0.

7d54f6a

MarkLodato changed the title ~~Rename to DSSE and update PAE~~ Rename to DSSE, update PAE, mark as v1 Jun 4, 2021

adityasaky self-requested a review June 8, 2021 16:25

adityasaky reviewed Jun 8, 2021

View reviewed changes

trishankatdatadog reviewed Jun 9, 2021

View reviewed changes

Clarify PAYLOAD and PAYLOAD_TYPE.

989a069

MarkLodato mentioned this pull request Jun 9, 2021

Add envelope version #34

Open

adityasaky self-requested a review June 14, 2021 15:28

mnm678 approved these changes Jun 14, 2021

View reviewed changes

MarkLodato mentioned this pull request Jun 14, 2021

Design: Where to put timestamps in envelope? #33

Open

mnm678 approved these changes Jun 15, 2021

View reviewed changes

envelope.md Outdated Show resolved Hide resolved

Explain parsing rules; ignore unrecognized fields.

27ce241

MarkLodato force-pushed the dsse branch from a1aef95 to 95381c7 Compare June 15, 2021 17:16

dlorenc reviewed Jun 15, 2021

View reviewed changes

envelope.md Outdated Show resolved Hide resolved

MarkLodato force-pushed the dsse branch from 95381c7 to 27ce241 Compare June 15, 2021 17:27

trishankatdatadog mentioned this pull request Jun 15, 2021

Allow signature-less envelopes. #38

Closed

MarkLodato mentioned this pull request Jun 16, 2021

Use a simpler PAE #27

Closed

wietse-gmail reviewed Jun 17, 2021

View reviewed changes

adityasaky mentioned this pull request Jun 17, 2021

Consider splitting signing-spec/ITE-5 code (package ssl) into a standalone repository in-toto/in-toto-golang#110

Closed

Define PAE more rigorously to avoid ambiguity

e43395a

trishankatdatadog reviewed Jun 21, 2021

View reviewed changes

Note that exclusive ownership is out of scope

ddb48b2

Add keyid to reference implementation.

04e1715

trishankatdatadog approved these changes Jun 21, 2021

View reviewed changes

MarkLodato merged commit cacf247 into secure-systems-lab:master Jun 21, 2021

MarkLodato deleted the dsse branch June 21, 2021 20:29

Rename to DSSE, update PAE, mark as v1 #37

Rename to DSSE, update PAE, mark as v1 #37

Conversation

MarkLodato commented Jun 4, 2021 • edited Loading

adityasaky left a comment

Choose a reason for hiding this comment

adityasaky commented Jun 8, 2021

trishankatdatadog left a comment • edited Loading

Choose a reason for hiding this comment

MarkLodato commented Jun 9, 2021

MarkLodato commented Jun 9, 2021 • edited Loading

MarkLodato commented Jun 9, 2021

mnm678 commented Jun 9, 2021

MarkLodato commented Jun 9, 2021

MarkLodato commented Jun 9, 2021

trishankatdatadog commented Jun 9, 2021

MarkLodato commented Jun 9, 2021

trishankatdatadog commented Jun 9, 2021

trishankatdatadog commented Jun 10, 2021

trishankatdatadog commented Jun 10, 2021 • edited Loading

mnm678 commented Jun 11, 2021

adityasaky commented Jun 11, 2021

adityasaky commented Jun 14, 2021

mnm678 left a comment

Choose a reason for hiding this comment

trishankatdatadog commented Jun 14, 2021

dlorenc commented Jun 15, 2021

MarkLodato commented Jun 15, 2021

mnm678 left a comment

Choose a reason for hiding this comment

MarkLodato commented Jun 15, 2021

wietse-gmail Jun 17, 2021 • edited Loading

Choose a reason for hiding this comment

MarkLodato Jun 17, 2021

Choose a reason for hiding this comment

trishankatdatadog commented Jun 21, 2021

trishankatdatadog commented Jun 21, 2021

pornin commented Jun 21, 2021

trishankatdatadog commented Jun 21, 2021

trishankatdatadog left a comment

Choose a reason for hiding this comment

mnm678 commented Jun 21, 2021

MarkLodato commented Jun 21, 2021

trishankatdatadog commented Jun 21, 2021

adityasaky commented Jun 21, 2021

MarkLodato commented Jun 21, 2021

adityasaky commented Jun 21, 2021

adityasaky commented Jun 21, 2021

MarkLodato commented Jun 21, 2021

adityasaky commented Jun 21, 2021

MarkLodato commented Jun 4, 2021 •

edited

Loading

trishankatdatadog left a comment •

edited

Loading

MarkLodato commented Jun 9, 2021 •

edited

Loading

trishankatdatadog commented Jun 10, 2021 •

edited

Loading

wietse-gmail Jun 17, 2021 •

edited

Loading