Extract creation and expiration time requirements language

[jricher]

Originally in #1235

[ioggstream]

imho this PR introduces a very weak normative part. I'd ask for feedback from the community/ML.

[ioggstream]

At first, thanks @jricher for asking me to review!

In this paragraph imho we are giving information that does not help interoperability:

• the first sentence states that "the verifier MUST comply with their own requirements, that depend on the use case", but it does not make a clear statement on those requirements;
• the fact that an "expired" signature MAY be accepted can be perceived as an abuse from a signer which instead wants to be in control of the data he signed.

I think that using fields like nbf,iat,exp allows to implement the very same behavior without removing control from the signer, and putting a solid interoperability ground instead: signer and verifier just have to agree about the interval they accept.

This is clearly IMHO, and probably @martinthomson or @jyasskin can give more useful guidance than me on this subject.

[richanna]

Thanks for the feedback!

There are three objectives that this paragraph is trying to achieve:

• 1st Sentence: Require implementers' time-related constraints to be enforced relative to the Creation Time and Expiration Time properties defined by the spec (as opposed to the Date header, or some proprietary property embedded in the request somewhere).
• 2nd Sentence: Allow verifiers to account for clock skew between the signer and verifier, which may be significant.
• 3rd Sentence: Allow verifiers to reject signatures based on their own requirements, i.e., "I don't care if you're telling me this 2 year old signature fine, I'm not going to accept it."

Open to suggestions on rewording to make these objectives clearer.

the first sentence states that "the verifier MUST comply with their own requirements, that depend on the use case", but it does not make a clear statement on those requirements;

Explained above, but restating for clarity: the purpose is to ensure that verifiers use the spec-defined Creation Time and Expiration Time properties to evaluate time-related constraints. Would it help to give example constraints? (e.g., a maximum signature age)

the fact that an "expired" signature MAY be accepted can be perceived as an abuse from a signer which instead wants to be in control of the data he signed.

It may be necessary for a verifier to accept a signature whose Expiration Time is after the current time as measured by the verifier, in order to allow verifiers to account for clock skew between signer and verifier. Maybe it would be better to reframe this as a verifier may offset their current time by some amount to account for clock skew, at least for the purposes of evaluating time-related constraints? That would allow us to bring back in the prohibition on accepting signatures past their Expiration Time.

I think that using fields like nbf, iat, exp allows to implement the very same behavior

I'm not sure how to interpret this in the context of this spec, since it does not use JWTs.

[ioggstream]

@richanna can we split the sentences over multiple lines? I'd find it easier to discuss them, eg.

Suggested change

	The verifier MUST examine the signature's Creation Time and Expiration Time and evaluate whether they meet the verifier's requirements. These requirements may vary depending on the use case. When comparing Creation Time and/or Expiration Time to a timestamp obtained from another source (e.g., testing that the Expiration Time is later than the local time at the verifier), the verifier MAY allow for some variability due to clock skew between the two timestamp sources (e.g., the signer and the verifier). The verifier MAY impose its own maximum age limits, and reject signatures that are too old (i.e., have a Creation Time too far in the past) regardless of whether the signer gave the signatures an Expiration Time.
	The verifier MUST examine the signature's Creation Time and Expiration Time and evaluate whether they meet the verifier's requirements. These requirements may vary depending on the use case.
	When comparing Creation Time and/or Expiration Time to a timestamp obtained from another source (e.g., testing that the Expiration Time is later than the local time at the verifier), the verifier MAY allow for some variability due to clock skew between the two timestamp sources (e.g., the signer and the verifier).
	The verifier MAY impose its own maximum age limits, and reject signatures that are too old (i.e., have a Creation Time too far in the past) regardless of whether the signer gave the signatures an Expiration Time.

[ioggstream]

I'd rephrase with something like the following. the 2119 keywords can be tuned, and the rest is just an example... your feedback is welcome!

The passage below ensures the verifier cannot take action beyond the will of the signer.

[addition] To take into account clock skew, the signer MAY provide the NotBefore Time parameter
indicating that the signature is valid prior to the Creation Time.

The verifier MUST NOT process a signature where:
- the Expiration Time is in the past;
- the lowest value between NotBefore and Creation Time is in the future.

This second sentence ensures that the verifier is free to impose further requirements that may relate - but not limit to - Time parameters, thus giving more freedom to invalidate to the verifier that the previous version:

The verifier MAY impose further requirements depending on the use case, including:
- maximum age limits;
- constraints between Creation Time and Exipration Time, or on other signature parameter values;
- (insert here some examples).

Some guidance for implementers about how to communicate further requirements could be helpful, because providing extensive information on why a signature is invalid may expose the peers to attacks

Those requirements SHOULD be communicated out-of-band or when it is safe to do so MAY be communicated on the wire (eg. in the response payload or headers).

[jyasskin]

I don't have a firm suggestion here, but here are a couple thoughts in the hope that they might help:

• The discussion of "the verifier's requirements" might really be talking about how this header is embedded into a higher-level protocol. The CBOR spec explicitly puts constraints on CBOR-based protocols and mandates that they specify certain things. For example "The first layer that does process the semantics of an invalid CBOR item MUST take one of two choices: …. A CBOR-based protocol MUST specify which of these options its decoders take". Maybe this spec could just say that

  A protocol using HTTP Message Signatures MUST define how it uses

  1. the verifier's current time,
  2. the verifier's estimate of any clock skew between the verifier and the signer,
  3. the Creation Time, and
  4. the Expiration Time

  to determine whether the signature is currently valid.

• Handling clock skew is probably more complicated than just offsetting the verifier's current time, and checking that the new time is between the creation and expiration times. Clock skew is inherently uncertain and the verifier's estimate of it might be vulnerable to attack, especially if the verifier is a client. The signed exchange spec currently says clients may adjust the creation time for skew but mustn't adjust the expiration time. The current Chromium implementation doesn't adjust for skew at all. Leaving it open for protocols to experiment with, as the current PR text does, is probably the right answer for this PR.

• My reading of JWT's "nbf" indicates that they don't take the earliest of the not-before and the creation times when comparing to the current time. Instead, it looks like the "Issued At" value is used for allowing a signature to be created some time before it's supposed to be valid. The signer also can't prevent the verifier from using whatever "now" value it wants, so I don't think it's worthwhile to add complexity to attempt to prevent that.

• I'm intrigued by the suggestion that saying why a signature was invalid could help attackers. Saying "when it is safe to do so" probably doesn't help protocol designers much, but it could be useful to have some more detail in the Security Considerations. On the other hand, most of the time, saying "the requirements are in the higher-level protocol definition" is likely to be enough.

• I like the examples of constraints verifiers might impose, like "MAY impose its own maximum age limits".

[jricher]

"not before" is not really helpful when dealing with clock skew as it falls under the same limitations.

I'm personally in favor of defining only the "signature creation time" and having everything else be decided by the verifier. Look at it from the signer's perspective: Why should I be able to tell you how long to accept my signature? I don't have the security context for that, and you can override it anyway and reject it even if I tell you it's not expired yet.

Better, I think, to mark the creation time and have guidelines on reasonable default expiration and lifetimes for validators, especially if we can state them in terms of a delta from the current time (and possibly the "date" header).

[ioggstream]

@jyasskin thanks for your feedback!

A protocol using HTTP Message Signatures MUST define how it uses
... to determine whether the signature is currently valid.

This approach is a good starting point

The signed exchange spec currently says clients may adjust the creation time for skew
but mustn't adjust the expiration time
Chromium implementation doesn't adjust for skew at all

I think that this spec should allow to implement this behavior.

My reading of JWT's "nbf" indicates that they don't take the earliest

Right, but still it's useful to account for clock skew.

The signer also can't prevent the verifier from using whatever "now" value it wants

It is true if the verifier purposedly wants to accept expired signatures. OTOH if the verifier
have a very large skew tolerance the protocol could become vulnerable to replay attacks.

... when it is safe to do so ...

This part was just a placeholder to highlight that security considerations are required.

@jricher

reasonable default expiration and lifetimes

you know my opinion :D there can be no reasonable default value, because imho it's for the signer to say :D
not supporting expiration will hinder adoption of this spec in all cases where an expiration is mandatory...

[richanna]

I like the idea of including guidance/requirements for profiling specs, though I would want to aggregate those under a separate "Considerations for Profiling Specifications" (e.g.) section, rather than have them distributed across the document. That makes it easier for profilers to understand what's needed of them, and for non-profilers to ignore stuff that's irrelevant to them.

Why should [the signer] be able to tell [the verifier] how long to accept [the signer's] signature?

Think of it instead as the signer saying how long they will acknowledge the signature, from a non-repudiation standpoint. That also serves as an implicit recommendation to the verifier – "I'm not trusting this after X, so you probably shouldn't either." The value of X may be informed by how the signer manages their signing keys, or knowledge about the network environment between signer and verifier that the verifier may not have.

At the same time, the signer may not know how the verifier will process the signed message. It may verify the signature on receipt, then forward the whole message (with signature) to an async workflow, which might revalidate the signature minutes or hours later. In such a scenario, the async workflow may need to be looser with expiration time enforcement than recommended by the signer.

There are very few absolute statements we can make about time-related signature validity checks, at least at this level of abstraction. I'm 100% in favor of providing examples, and requiring profiling specifications to define requirements and/or provide guidance.

With all of this, here is what I think needs to go into the spec:

1. Define Expiration Time as the signer's statement/recommendation to the verifier.
2. Explicitly state that this spec does not impose any limits on how verifier considers Expiration Time (examples of scenarios where a verifier might apply a higher or lower Expiration Time).
3. State that profiling specifications can (SHOULD? MUST?) impose limits (provide examples).
4. Require time-based checks to use Creation Time and Expiration Time where applicable (e.g., cannot use the value of the Date header field instead of Creation Time).

[ioggstream]

I'm 100% in favor of providing examples, and requiring profiling specifications to define requirements and/or provide guidance.

Providing examples and discussing is a great way to tune up specs and identify use-cases :)

Let me know when I can re-review the PR!

[jricher]

@ioggstream I think this has been replaced by the new language in #1411 but please check before I close this PR.

[ioggstream]

@jricher had a glimpse at the PR and seems ok but for a few comments I filed here https://github.com/httpwg/http-extensions/pull/1411/files (sorry for the late reply).
The only critical one is arbitrarily setting a missing expires as infty, but we already discussed this many times and there's plenty of time to refine that point when specs are almost ready :)

As soon as I have some time I'll review the last signature release, but I think #1411 improves things. Feel free to close this PR then