Re: [stir] JWT/JSON (was - Re: Review of: draft-ietf-stir-passport-05)

[Christer Holmberg <[e-mail]>]

Hi Dave,

I agree with Ekr, and being able to use something pre-existing is the reason I asked the passport authors to consider JWT. If you think there is something better pre-existing, please say so, but if you want to do something from scratch I think we’d need some really good justification for that. I don’t agree with your earlier statements that JWT is complex, and there are tons of tools to test and verify JWTs.

In Berlin I did raise an issue on how STIR uses JWT in SIP (the encoded object is “split up”, and different pieces are placed in different SIP elements), but Jon promised to make sure it’s clarified and well explained in the next version of the bis draft, so I think we should give him a chance to do that.

Regards,

Christer

From: stir [mailto:[e-mail]] On Behalf Of Eric Rescorla
Sent: 21 August 2016 18:37
To: Dave Crocker <[e-mail]>
Cc: IETF STIR Mail List <[e-mail]>
Subject: Re: [stir] JWT/JSON (was - Re: Review of: draft-ietf-stir-passport-05)

Dave,

Whenever we want to add some cryptographic functionality to a protocol [0] (especially
when it's messaging/object security functionality) we have to ask whether it would be
better to define something new, specific to the protocol, and hopefully simple, or reuse
something pre-existing, generic, and presumably more complicated. In my experience,
the history of those who take the former approach is that we find ourselves reinventing
a bunch of stuff and that it's not as simple as we hoped [1][2]

Given the difficulty of correctly specifying and implementing this kind of functionality,
I'd far prefer to stick with a pre-existing component. It doesn't have to be JSON of course
(for instance, I have no opinion on if COSE would be better) but I would not be in favor
of defining something specific here.

-Ekr

[0] Or, I guess, in a bunch of other cases.
[1] Indeed, JOSE is in some respects an attempt to apply this treatment to CMS.
[2] Another example is the current HTTPBIS encryption spec, which has rather expanded
from its simple origins.


On Wed, Aug 3, 2016 at 1:25 PM, Dave Crocker <[e-mail]<mailto:[e-mail]>> wrote:
On 7/29/2016 2:11 PM, Dave Crocker wrote:
On 7/29/2016 10:46 AM, Peterson, Jon wrote:
I wouldn't say it's a correction to the STIR charter - the charter was
always clear that it was not limited to SIP (see the bits about "one or
more non-SIP hops" and "out-of-band mechanism" in the charter). But given
that our original signing mechanism was, as I said, a concatenation of
SIP
header field values, the intervention was that other protocols would need
something less bound to SIP. JWT turned out to be the solution that the
group had consensus to adopt.

JWT has nothing to do with SIP.  So when applied to a SIP context, it's
entirely artificial.  And yes, I noted the views that thought it simpler
or equivalent to the computed string, but could not see the explicit
logic that made JWT a better choice, no does it seem obvious to me.
Quite the contrary.

Note that during the wg session in Berlin there was /still/ question
about where to put the JWT information.


Folks,

I'm citing the above text, for discussing the concern I rasied about JWT/JSON use in Passport, because that was the first time I criticized it, which was several rounds of postings after I sent my review.  That is, it was /not/ part of my review.  I made a conscious choice to leave that concern out, although I already saw it as likely problematic.

On its face, yes it looks like a reasonable choice.  It's pre-existing technology and it looks clean.  The concerns develop in its application, not its concept.

Look for JSON and JWT in SIP.  You won't find it.  That means that it is an added layer of specification.  Or, in this case, specifications.  And since JSON and JWT are their own environments, that means there is a learning curve and other baggage to carry, before it is useful to SIP and STIR.

Even better is that even the STIR specification for SIP does not require using JWT or JSON.  Note that ppt is optional.  This adds to the view that, at best, JWT/JSON is really just an abstraction for STIR.

But in fact the fact that ppt is optional really means that the SIP STIR specification has added complexity, with very unclear benefit.

As for the underlying justification for the Passport model, references to broader applicability are always appealing, but lacking concrete specifications and clear, documented intentions of use -- including a clear explanation of the benefit to be gained by the abstraction -- they turn out mostly to be a distraction from the immediate concern, namely added complexity to the mainstream use.

Again: JSON/JWT adds a layer (or two) of mechanism that almost certainly is not needed and almost certainly adds problematic complexity to the specification, probably to the point of impeding reader comprehension.

As I've noted, the underlying task here is pretty straightforward:

   *  Define a mechanism for finding and validating a public key.

   *  Decide on scope and canonicalization of data to be signed. Define
      a signing mechanism.

   *  Define a validation mechanism.

   *  Decide how to deal with partial adoption

   *  Decide how to deal with broken signatures.


Maybe a little more than this, but not much.


d/

--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net<http://bbiw.net>

_______________________________________________
stir mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/stir