Re: [stir] current draft charter

["DOLLY, MARTIN C" <[e-mail]>]

So, we define a charter to a solution that we want to get at, versus in REALLITY need to solve... I am simple, so please explain...

-----Original Message-----
From: Peterson, Jon [mailto:[e-mail]] 
Sent: Sunday, June 16, 2013 8:22 PM
To: DOLLY, MARTIN C; Hadriel Kaplan; [e-mail]
Cc: [e-mail]
Subject: Re: [stir] current draft charter


>[mcd] - the issue is not between trusted carriers, but rather traffic of
>the wholesale/enterprise.

I'm sure you're right, but from a technology perspective it's the
protocol-level trust itself that we can improve here.

>{mcd} - further the charter needs to focus on the violating parties.

Again, I think the IETF can only focusing on designing technology that
doesn't suffer from these problems. Violating parties will not exactly be
early adopters of protocols that constrain them, so we can't expect to
charter work that they will abide by. What we can do is try to make the
identity story better all around, so that violating parties are
marginalized.

But if there's something specific in the charter text you'd want to see
different to capture this, let me know.

Jon Peterson
Neustar, Inc.

>
>Regards,
>
>Martin
>
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf Of
>Peterson, Jon
>Sent: Sunday, June 16, 2013 7:28 PM
>To: Hadriel Kaplan; [e-mail]
>Cc: [e-mail]
>Subject: Re: [stir] current draft charter
>
>
>>
>>> RFC 4474 has been standards track for 7 years; that's a long time.
>>> 
>>> What is its level of operational deployment and use, so far?  If the
>>>answer is "not much", then it's not clear that automatically invoking
>>>its application here is as comforting or facilitative as one might wishŠ
>>
>>The answer is less than "not much"... more like "not at all".
>>I'd argue the reasons it has never been deployed are: (1) people didn't
>>believe there was an identity spoofing problem yet, (2) it only really
>>validates email-style identities such as [e-mail], not E.164
>>numbers, and (3) it's not deployable due to B2BUAs changing the fields it
>>would sign.
>
>I agree with those three reasons. I'd further say (1) is part of a broader
>trend in which the deployment community hasn't shown much interest in the
>security mechanisms available in SIP versus operating in effectively
>private environments. These identity spoofing concerns show a limitation
>of transitive trust in these private communities.
>
>>> If I understand the RFC 4474 model correctly, a validated Identity
>>>field has the semantics of asserting that the From field is valid.  So
>>>the assertion is not limited to the owner of the From field value.
>>>Correct?  While such a model is understandable, it dramatically
>>>increases the reputation-management complexity of the task.  I'm not
>>>aware of an extant service over the public Internet of similar
>>>complexity.
>
>We weren't exactly proposing a domain assurance council or something like
>that. The authorization decision was supposed to be checking the reference
>integrity of the domain in the From header field against the domain in the
>subjectAltName of the cert (provided the cert is valid and the root
>trusted): if there's a match, then this was signed for by the right
>entity, if not, then not. I'm not sure what you mean by "not limited to
>the owner of the From field value." In so far as the originating domain is
>the "owner," then only they can sign it, if that's the limitation you're
>concerned about.
>
>>> 
>>> Better still is that it's the entity making the assertion that tells
>>>the verifier where to look for verification information...  What's seems
>>>to be missing from the text in RFC 4474 is how the verifier can tell
>>>whether the credential is a valid authorization for use of the From
>>>field value. (If it wasn't clear before, now you can understand why I'm
>>>curious about the concrete details of this authentication service.)
>>I think the general idea was a DKIM-like model, so if the From field
>>value is '[e-mail]', then you check the cert it points you to is for
>>foo.com and signed by a CA you trust.  That works for email-style names
>>like that, because you can verify it's coming from foo.com, and foo.com
>>is the authority for a '[e-mail]' name. (Assuming all CAs you trust
>>are not compromised of course)
>
>Correct. The entity making the assertion tells the verifier where a cert
>can be fetched, in the case that the verifier doesn't already have a cert
>for the signer. Whether the cert is valid, or the CA itself is trusted by
>the verifier, is however a different and prior question.
>
>>The hard part comes with E.164 numbers, because even if they appear as
>>user@domain strings, like '[e-mail]', most SIP devices would
>>treat it as an E.164 number - and that means it's not scoped to foo.com
>>at all but rather a separate, global namespace that foo.com has no
>>natural authority for.  So with 4474 you'd have to believe foo.com is
>>authoritative for the number based on reputation alone - i.e., you have a
>>local list of domains you trust to claim E.164 numbers.  That would work
>>for a limited number of domain names, for example the domain names of the
>>major carriers within a country, but it would fall apart quickly if we
>>ever want Enterprises to sign, or international scenarios to work.
>
>Right. At the risk of waxing philosophical about it, I'd say that RFC4474
>took for granted the baseline assumption that RFC3263 would be how SIP
>requests were routed. If you assume SIP requests get routed by taking the
>domain portion of the request-URI and looking it up in the DNS to locate a
>SIP server, RFC4474 probably isn't a bad fit for what you do. If however
>SIP requests get routed based on the user portion of the Request-URI (like
>a TN) without reference to the DNS, then probably having a domain sign for
>identity won't be appropriate. JDR's I-D on rfc4474-concerns is pretty
>much all about that.
>
>>So one proposal so far is that there would be certs which identify the
>>E.164 numbers they're authoritative for (in a CN/SAN field for example),
>>and that cert would be signed by some CA (or chain leading to one) that
>>you trust.  If it's a chain rather than directly signed by a CA, then
>>it's not clear how one goes about retrieving the certs for the chain's
>>links, and doing so could cause unacceptable delay.  It also means we
>>need revocation checks for the chain.  And I'd argue the management
>>aspects for this thing would be just as difficult as anything else
>>proposed so far.
>
>Although I'm not the expert, my understanding is that there are various
>cert chain compression techniques that could be applicable here. I've
>squinted a bit at OCSP and other possible real-time revocation checks for
>this as well.
>
>The exact amount of tolerable delay is a very interesting dimension of
>this problem space. I suspect we have a considerable amount of time, given
>all the human expectations about both post-dial delay and the wait for
>someone to pick up after altering. I think it's enough time to perform
>some non-trivial operations.
>
>But I do agree that there's no such thing as a free lunch, and that
>implementing a credential system for telephone numbers, even just in a
>single nation state, is operationally complex. In my day job, we have a
>few different credentials today that carriers can use to interface with
>various NANPA/NPAC system, and some of them already have requirements
>similar to what we've discussed here, like delegation for example. I think
>if we go down this STIR path, at the end of the day we'll end up with a
>system that relies on many numbers aggregated behind a single credential,
>on signatures and validations being performed by network elements much
>more so than endpoints, and similar optimizations. Provided we can do this
>without making e2e security impracticable, I think we'll be on the right
>track.
>
>Jon Peterson
>Neustar, Inc.
>
>>-hadriel
>>
>
>_______________________________________________
>stir mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/stir