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

[Dave Crocker <[e-mail]>]

On 8/21/2016 9:03 AM, Christer Holmberg wrote:
> 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.


Christer,

Just to be thorough, I'll repeat that I agree with the goal of using 
existing solutions, where they represent a high-enough point of 
departure (if they aren't a perfect match), preferably with enough track 
record to establish efficacy.

And I'll repeat that my view of the passport draft did not criticize the 
use of JWT.  (By the way, is it only JWT or is it actually JOSE, and if 
it isn't why not?)

It's not that I didn't question the use, it's that I didn't indulge in 
that questioning at that point.  This came later, as I watched the 
documentation efforts to integrate use of JWT.


 > 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.

There are at least two major problems here.

The technical one is that the current approach requires doing encoding 
and packaging twice, from what I can tell.  Once in a JSON context and 
the second in a SIP header context.  By itself, that should be worrying. 
That the latter hasn't been fully documented and agreed to, yet, raises 
a question about how anyone thought the documents were ready for last call.

The other major problem is that the introduction of JSON/JWT has 
produced levels of indirection in the documentation that made it 
essentially impossible for me to understand and analyze the 
specification details.  And I tried pretty hard.  So this does not bode 
well for other new readers of the specifications.  (More generally, the 
documents make cross-references and indulge in cross-dependencies that 
defeat the benefits of modularity and create really serious reading 
complexity.)


And now, yes, I'll indulge in the dreaded "DKIM" reference...

DKIM is another existing mechanism that provides exactly the needed 
functionality, with more than 10 years of field experience (counting the 
predecessor Yahoo's Domainkeys) and a relatively simple design.

As I've noted before, the list of 'topics' for the STIR work is not 
long.  I'll do an abbreviated listing here:

    1. Calling value acquisition -- getting the string to validate

    2. Key management --getting the key and validating that it is
       authorized for use with the calling value.

    3. A bunch of crypto-related computation -- including
       canonicalization of the data of course

    4. Packaging the result -- for use by the validation mechanism.

Step 1 is not part of the crypto work, but it is of course fundamental, 
as well as being specific to STIR.  The crypto subsystem just uses it as 
input. The choice of JSON/JWT, DKIM, or whatever is irrelevant to this step.

Step 2:

   a)  For non-telephone URIs, DKIM's DNS model can be used directly.

   b)  I'm unclear about the role of the domain name in the URIs that 
have a phone number in the left-hand side.  In any event, as I've noted 
repeatedly, number-based key management is an open issue, with 
demonstrated high risk, given that the previous effort failed.

Step 3 can use DKIM almost directly.

Step 4 can use DKIM almost directly.


So the DKIM approach is dramatically simpler and offers by far the 
highest point of departure for STIR.

In particular, the hard parts of doing STIR aren't solved by this choice 
-- JSON/JWT don't help either.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net