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

[Eric Rescorla <[e-mail]>]

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]> 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
>
> _______________________________________________
> stir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/stir
>