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

[Dave Crocker <[e-mail]>]

On 8/8/2016 2:44 PM, Peterson, Jon wrote:
>
> PASSporT is indeed an object format in its own individual specification,
> if that's what you mean by the "level of indirection". I consider it a

It's not.  It's more than that.

The small thread that eventually produced your note was debating support 
for format processing and whether it was a requirement for a verifying 
entity to support the syntax.  The conclusion was that it does.

My point, however, is that you note makes clear there is an entire 
semantic engine embodied in Passport that is independent of SIP and 
independent of 4474bis.  That engine needs care and feeding, just like 
any other networking service.

Think carefully about the language you used:

      "... bare minimum" set of headers
and claims that are mandatory for PASSporT. Ultimately, the question of
what headers and claims are mandatory in PASSporT is a stir-passport
question...will populate those mandatory components of a PASSporT
object...Extensions may propose additional claims..."

That's an entity that is more than just a format.


> point of architectural modularity.

Yes, and it's appealing.  I /like/ modularization too.  That's why it 
has taken be awhile to appreciate how much downside this particular 
modularization is introducing.

If there were a variety of specifications that used and benefited from 
all that generality, it might be defensible.  But the specifications in 
front of us today merely show added complexity, making concrete analysis 
challenging.

At that, it's pretty clear that the specifications in front of us are 
still significantly incomplete.  That is, they are insufficient for 
developing a working caller-id authentication service.


  The working group agreed to organize
> the work this way because we did not want to tie STIR too closely to any
> particular using protocol (such as SIP).

I understand the motivation.  Really I do.  But after 3 years, SIP is 
all you've got and even that isn't complete.


  The actual job that needs to be
> done here is mitigating the threats defined in our charter and threat
> model, which are not specific to SIP.

That phrasing is common in the email anti-abuse community too.  Threats 
(attacks) are what motivate the work, and so threats are what everybody 
focuses on.

However the underlying nature of the current solution path in fact is 
not to 'prevent' misbehavior, but rather to have a way of detecting 
valid behavior.  That is, rather than a focus on MIStrust, 
authentication focuses on Trust... of the identifier.  (The actor 
associated with the identifier might not be a good actor, but assessing 
that is a separate matter.)  Again: It seeks to validate something, 
rather than to find things that aren't valid.

Those sound obviously related but in fact they require entirely 
different operational modes.

Consequently, I'll claim that the working group task isn't really to 
mitigate threats but to create a basis for trusting a caller-id, and 
I'll claim that that difference in wording has fundamental import.

That the mechanism for doing this is resistant to those threats is 
merely an enticing distraction, because nothing in this work is going to 
stop that folk from creating false caller-ids.

Really.

Consider that point a bit...  Over 90% of email traffic across the open 
Internet is still spam.  However the mail that comes in with SPF and/or 
DKIM protection constitutes a clean channel of authorized identifiers. 
Mail coming through that channel can be handled differently that mail 
coming through the messy, unauthenticated channel.  (And for folk who 
know something of the way actual filtering engines work, yes, I'm being 
simplistic.)


Even though we've repeatedly
> explained to you that this independence from SIP was the motivation for
> adopting PASSporT, it still does not seem to be sinking in, as you keep
> saying things below about how the role of PASSporT is SIP-specific.

Actually, I've been careful to distinguish theory from fact.  I said 
that the actual /use/ is for SIP.

After 3 years, there are no other specifications than for SIP.  And even 
that is incomplete.


> Although you seem to feel that this modularity is for some reason a matter
> of impossible complexity, the working group, as far as I can tell, is

Marshall Rose once noted that with enough thrust, even pigs can fly.  So 
I've been careful not to say or imply anything quite as absolute as 
'impossible'.



d/


-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net