Re: [stir] draft-peterson-secure-origin-ps-02.txt

["Peterson, Jon" <[e-mail]>]

>Pieces to add:
>
>Section 4 needs to have a separate section expanding on why PAI isn't
>good enough.  Basically Section 4 has two whole long sections on 4474 and
>VIPR, but really it needs one on PAI as well.  At the end of the day
>that's the one that's actually *deployed* currently, compared to these
>other two. (more on VIPR later)

I agree a section along those lines would be useful. I could take a stab
at it, or be happy if you have text in mind to fit it in.

>There needs to be a section on the difficulties handling legitimate
>call-forwarding scenarios vs. the need to prevent malicious cut-paste
>appearing like call-forwarding.  It's a fairly technical problem, so
>might be better in a different doc, but at least at a high-level it's a
>"problem" for a problem statement doc to raise.

I agree it's worth a mention, given that we mention things like legitimate
spoofing already. Probably the extent of the difficulty depends
significant on the specific solution, so that might be a good place to
draw the line of what belongs in this doc and what belongs elsewhere.

>There should be a section about the relative similarity (and differences)
>of STIR's problem with Email's problems of spam and identity.

Hmm. Would a reference to RFC5039 suffice for this? Might be a little
dated, but kind of silly we don't reference that already, and I wouldn't
want to spend a lot of real estate here reiterating it.

>--------------------
>Pieces to delete:
>
>Abstract: everything after the first sentence is just plain wrong, imo.
>It's not the interworking of SIP that has reduced the security of Caller
>ID, nor the lack of standards for identifying the calling party.  This
>would have happened whether it was SIP, H.323, or even SS7 over Sigtrans.
> Section 2 does a reasonable job of explaining why it's become a problem,
>but even that section doesn't really nail why it's grown so much: imo,
>ultimately it boils down to reduction in cost, reduced complexity, and
>availability of tools. (see
>http://tools.ietf.org/html/draft-kaplan-stir-fried-00#section-3.8)

I did re-read the abstract after your earlier mail to see if I would find
it similarly flawed, and I guess I had, and have, a hard time seeing it. I
still believe that interworking SIP with the traditional telephone network
has ultimately reduced the security of Caller ID, which is true regardless
of whether or not the same would have applied had H.323 enjoyed SIP's
market dominance, for example.

But your argument here really seems not to be that the story is wrong, but
just incomplete, as it points at results rather than causes, and that the
causes here are low costs and the other factors identified in stir-fried
3.8. I don't have any objection to having those points in the ps document,
but the abstract isn't trying to ferret out root causes, it's discussing
why we need to do work and what the work is. I don't think that makes its
claims "just plain wrong," but if you think it does, let's talk more about
it.

You say below that the secure-origins document is slanted towards an
out-of-band solution, but by calling out SIP here I see it as slanted the
other way. Agreed that, had SS7 over sigtran been the dominant VoIP
protocol, and had the deployment environment used it for all sorts of
IP->PSTN gateways, then yes, it would be critical for us to provide secure
identity for it instead of for SIP. Does that mean we shouldn't focus on
an in-band solution for SIP?

>Section 4.2: VIPR.  I don't understand what value having this section
>adds.  Afaik, VIPR didn't claim to solve the STIR problem, and doesn't
>appear to solve it.  It just adds confusion to have this drawn out
>explanation of VIPR in a problem statement doc about STIR.  There are
>plenty of other technologies we've developed in the IETF that don't solve
>STIR either, that we could advertise in this doc as well. ;)

VIPR attempted to solve the secure origin problem specifically for
telephone numbers, to provide a strong attestation of who is placing a
call, as one of its suite of features. It was certainly positioned as a
solution to the SIP identity problem, given that SIP calls were all using
telephone numbers. It was charted as its own working group, and (unlike
RFC4474) was actually implemented, deployed and to some degree used in the
wild. Some techniques it introduced are potential salient to the STIR
solution space, as are the many reasons it was not ultimately a success. I
have a hard time thinking of another chartered IETF work item focused on
addressing identity for telephone numbers, regardless of whether or not it
"solved" STIR. I think this text (or at least something like it) has to
stay.

>Section 6 Requirements: I'm not sure a requirements list is appropriate
>for this doc, or if we intend to have a more exhaustive list in a
>separate doc.  Either way, the "Display name" one is not in scope for
>STIR.

We should exile "display name" and probably also the "extended validation"
bullet in the roadmap to CNIT where they belong.

>Section 7 Roadmap: this isn't germane to a problem statement doc, afaik.

Now that we have a charter, the need for a roadmap is significantly
reduced. I do think this text (or a derivative) could remain useful for
defining what in-band and out-of-band mean, but that doesn't need to be
presented as a roadmap.

>--------------------
>Miscellaneous comments:
>
>I've read the doc multiple times and it still feels like it's heavily
>weighted in favor of an out-of-band solution.  I recognize it's an
>individual draft and the authors get to say whatever they believe, but
>for a WG doc I think it sends the wrong message.  Maybe it's just my
>sensitivity to the heavy attention it pays to VIPR, the "Shift to Mobile
>Communications", and the evil-ness of B2BUAs and the PSTN that it subtly
>portrays.

"Out-of-band" certainly appears in the text more than "in-band," and yes
that is largely due to the VIPR section and the "mobile" section. But the
document clearly says we need both "in" and "out", and discusses both.
That was my understanding of the chartered work here in STIR as well. I
don't think the ps can be read as arguing we shouldn't do in-band, or
giving it insufficient consideration. Was there some missing consideration
of in-band that you think should be added?

I can go through and try to expunge any text that seems to vilify B2BUAs,
though again if there's some particular lines here that seem unfair, do
point 'em out.

>Also, this is minor, but several times the doc ventures into concerns
>about malicious man-in-the-middle attacks.  For example section 4.1 page
>12 top paragraph talks about the problem of a 4474 Identity header being
>dropped by an intermediate and creating a new header in its place; or
>section 5.4 discussing how we could have two signatures to protect the
>payload from being changed by MITM.  But the truth is that's not the
>problem we need to solve.  We're not worried about malicious MITM.  We're
>worried about malicious ends.  Nothing more.  Protecting SIP NOTIFY
>bodies or even SDP is not a problem we need to solve.

The reference in 4.1 to an RFC4474 header being dropped by an intermediary
is merely summarizing the argument of draft-rosenberg-rfc4474-concerns,
and reiterating its concerns here does not mean that the STIR working
group is going to address them - the brokenness of RFC4474 is however part
of the fundamental motivation for revisiting identity. Even though the
problem space of STIR does not involve protecting NOTIFY bodies,
understanding the limitations and scope of RFC4474 is essential to getting
this right. 

I'm more sympathetic to your concern about the text in Section 5.4 (though
that idea appears as a "for example", not a "here's what we're going to
do"), which probably I'd be willing to drop in favor of the more nuanced
discussion of MitM in the threat model document.

I do however maintain that, just as a mechanism for signing SIP requests
from telephone numbers and might also work for other forms of identifiers,
similarly a signature mechanism might work for assuring the origin and
also for protecting other parts of a request. Saying it's "not a problem
we need to solve" doesn't mean "solving that would be a problem."

Jon Peterson
Neustar, Inc.


>-hadriel
>
>On Sep 11, 2013, at 2:25 PM, "Peterson, Jon" <[e-mail]>
>wrote:
>
>> 
>> Could you elaborate a bit? It is the right time to have this
>>discussion, I
>> think. What sections need to go, and what material needs to be added?
>> 
>> Jon Peterson
>> NeuStar, Inc.
>> 
>> On 9/11/13 11:17 AM, "Hadriel Kaplan" <[e-mail]> wrote:
>> 
>>> 
>>> I guess it depends on how we want to handle big changes.  In some IETF
>>> WGs I've been involved with, we iterated the I-D to get it close to
>>> "right" before we make it a WG item; in others we took an initial I-D
>>>as
>>> a WG draft and then changed it once it was a WG doc.  I'm not sure it
>>> really matters which way it's done, so long as we don't raise the bar
>>>for
>>> changes because the doc "is a WG doc with content that was already
>>>agreed
>>> upon".
>>> 
>>> I say that because there's a lot of good stuff in this draft, but also
>>> there are sections of this doc I think should be removed entirely, and
>>> sections I think should be added. (and that's not counting the minor
>>> nits, like the abstract being ~80% wrong :)
>>> 
>>> So if it's ok to make big changes after we adopt it as a WG doc, then I
>>> don't see an alternative I-D being proposed and don't see a reason not
>>>to
>>> take this one as the WG doc.
>>> 
>>> -hadriel
>>> 
>>> 
>>> On Sep 10, 2013, at 6:32 PM, Russ Housley <[e-mail]> wrote:
>>> 
>>>> http://www.ietf.org/id/draft-peterson-secure-origin-ps-02.txt
>>>> 
>>>> Should the working group adopt this I-D as the basis for the STIR
>>>> problem statement docuent?
>>>> 
>>>> Russ
>>>> _______________________________________________
>>>> stir mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/stir
>>> 
>>> _______________________________________________
>>> stir mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/stir
>> 
>> _______________________________________________
>> stir mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/stir
>