[stir] Comments on draft-ietf-stir-passport-divert

[Ben Campbell <[e-mail]>]

Hi,

I agreed in Prague to review draft-ietf-stir-passport-divert, and have done so. I think it’s mostly in good shape, but have some minor comments and questions.

Thanks!

Ben.


*** Substantive Comments ***

§4.2:

- What happens if a “div” passport chains back to a PASSporT object with an unknown “ppt” value? Is the answer the same if the offending ppt occurs at the innermost PASSporT vs in the middle of the chain? (That is, is there any possibility of traversing a ppt of unknown type when verifying the chain?)

- "The verification service SHOULD also verify
that all other "div" PASSporTs in the chain share the same "orig"
value.”

What is the benefit of doing this? What would be the consequences of not doing it? What would be reasonable behavior if the verifier discovered a non-matching orig? (And depending on the answers: Why not MUST?)

- "It
is furthermore RECOMMENDED that the verification service check
that the "iat" field of the innermost PASSporT is also within the
date freshness interval; otherwise the verification service could
allow attackers to replay an old, stale PASSporT embedded in a
fresh "div”.”

Why is this not a MUST? Do you envision situations where it would be reasonable not to comply?

- "PASSporT. Note
that (per Section 4.1) a chain may terminate at more than one
innermost PASSporT, in cases where a single "div" is used to
retarget from multiple based PASSporTs.”

What happens if some of the terminating PASSporTs fail verification but others succeed?

§6:

 Is “opt" intended for general purpose use? If so, I suggest splitting it out into a separate draft. “Div" seems like a strange place to hide it.

Is there a hard 3 letter limit for passport parameter names? “opt” seems rather non-mnemonic due to the collision with the plain English word.

§11: Are there scenarios wheret the original destination in a diverted call could be privacy sensitive?



*** Editorial Comments and Nits ***

- There are some minor complaints from IDNits that should be addressed prior to pubreq.

- Please expand the following acronyms:

PASSporT (in title, abstract and body)
JWT
STIR

§1:
- "practically speaking some operational environments do alter the
To header field”
That may be a bit of an understatement. Perhaps “some” should be “many”?

- "and they both can capture minor syntactical changes in
URIs that do not reflect a change to the actual target of a call.”

I’m not sure what “capture” means in this contexrt. Are we talking about otherwise unnecessary H-I entries due to semantically equivalent but syntactically different URIs?

§2: Is there a reason not to use the updated boilerplate from RFC8174?

§4.2: It seems early in the evolution of STIR to call base verification services “traditional” :-)