Subject: [stir] stir 93 meeting minutes

From: "A. Jean Mahoney" <[email-masked]>
Date: Mon, 20 Jul 2015 20:02:18 +0200

Hi all,

My notes from the meeting below. Ellipses (...) mark places where I 
didn't catch what was said. Feel free to fill in.

Thanks,

Jean

Secure Telephone Identity Revisited (STIR)
IETF 93
Session 2015-07-20 1520-1720: Karlin III

10m Administrative  - Chairs
Presentation: 
https://www.ietf.org/proceedings/93/slides/slides-93-stir-2.pdf
Presenters: Robert Sparks, Russ Housley

Jabber scribe: Pete Resnick
Jabber archive: http://www.ietf.org/jabber/logs/stir/2015-07-20.html
Note taker: Jean Mahoney

Slides presented. Note Well noted, no changes to the agenda.

50m draft-ietf-stir-rfc4474bis-04
Document: https://datatracker.ietf.org/doc/draft-ietf-stir-rfc4474bis
Presentation: 
https://www.ietf.org/proceedings/93/slides/slides-93-stir-0.pdf
Presenter: Jon Peterson

slide 1: Title

slide 2: What we did since -03

slide 3: Open Issues: Signing PAI

"canon" is an optimization, it captures how the signer saw it. Helpful 
for debugging.
Can assume that everyone within a Trust domain can do the 
canonicalization. PAI is stripped when leaving the trust domain, but 
what about 'canon' - maybe the gateway wouldn't remove it. This is noted 
in the draft text. What's the value of the signature in a closed, 
trusted network?

Martin Dolly: Not quite true that PAI only originate in a TD. We receive 
them over other interfaces. Having a verification mechanism and sign 
it... Enterprises today will send a PAI to the carrier. We process on 
customer subscriber ID, we don't look at it. For a North Am deployment 
that the enterprise could use that number, and the basis for the carrier 
signing it.

Jon: Do we need to revisit 3325? Kill me if we do. It's the edge 
element's responsibility to ... and promulgate it through the trust 
domain.  I'm skeptical that's the motivation.

Brian Rosen: It /might/ be acceptable to write text that the PAI is 
there... If the person doesn't put in the right From, the call will fail.

Jon: ... I'm not going to recommend it - there are problems

Brian: Even if they don't put the canon in, if it doesn't match what is 
in the From, it's ok. The originator didn't do it right, or a middle box 
didn't do it right, and it will fail.

Jon: and that's ok.

Henning: Schulzrinne: PAI does cross boundaries across the carriers - 
SIP Forum/ATIS document.

Jon: This is what Mark Watson was imagining when he wrote RFC3324. The 
SIP networks would behave like the PSTN.

Martin: If you look at spoof and robocalling, they're typically from 
smaller carriers. ATT doesn't trust those carriers like it trusts 
Verizon, but we have to interwork with them. It was said on the list a 
few times - we cannot just drop calls, we are legally obligated.

Brian: Ok, verification might fail. I didn't say drop.

Jon: how do verify...

Martin: If we are going to deploy on signing certain parts of the 
messages that are validated at the end. To address reality - you have to 
sign PAI.

Jon: It lets you sign PAI today.

Henning: The brief privacy discussion we had earlier on the list today. 
Anonymity is really pseudo-anonymity. The carrier knows, but not the 
recipient. The current model - use the standard anonymity in the From 
header and keep the PAI. We need to distinguish because they are 
different services. Particularly, if you have anonymous calls, you 
should sign. Needs to be default behavior.

Jon: we can add motivating text to explain when you want to make the 
tradeoff. There's privacy leakage. Implementations have to be mindful, 
and shouldn't hurt anybody.

Robin Wilton: There's another use case - I have a portable, 3rd party 
number and I give it to other people. It breaks for a couple reasons, 
like because the receiver won't accept tariff uplift. It might break here.

Jon: I think we have a story for this. NNI use cases that use PAI, would 
be good to know.

slide 4: Signing anything else

Jon: CNIT - how to implement? I swore I wouldn't do it, but I've defined 
a blank-check extension header for future proofing - Identity-Extension. 
Need to have strict IANA controls on it - standards action and enough 
review.

Henning: We have 2 mechanisms - Identity-Extension and identity-reliance 
mechanisms. Getting cozy with each other. These are exceptional 
mechanisms and will be widely deployed. The more we unify these 
concepts. Take URI, make it part of the signature. One can fail, one can 
succeed. Part of the motivating design - organized and single way. 
Concern about current draft - multiple signing authorities - enterprises 
and carrier. We need to look at the permutations.

Jon: valid concerns. I allow 1 extension per request. Becomes a LOA, and 
the decisions become more complex.

Henning: It should not be a kitchen sink. Don't object to raising the 
bar. What's the operational model? How do you fingerprint it? How to 
canonicalize it? Do you expect hard or soft failure? There's enough 
stuff to be specified... I prefer a single, extensible mechanism rather 
than three. Identity-Extension is not a good sign.

Jon: It can be done. We have 3 things that are one-off mechanisms, may 
or may not be in the signing. Secure RTP - not always present. 
Identity-Reliance - can sign the entire message. Henning is saying that 
I should just generalize, and it will look like DKIM. I can live with 
that, but I swore I would not do DKIM. I want it to be clear - is it 
trustable?

Henning: From the code perspective: it doesn't matter. I think we're 
close enough to convergence. It's easier to separate out things that 
ATIS will worry about immediately versus long term.

Pete Resnick: Make sure the Identity-Extension is signed.

Jon: The Identity header ensures the it's signed. Make all the options a 
Identity-Extension, and a path to extend it.

Henning: Need to be aware of 2 models - single entity doing a lot of 
sigs. We want to downgrade attacks. You have 2 entities that are doing 
the signing. Depending on the ordering, may happen before CNAM signing. 
For instance, Carrier signs it, hands it to Dunn & Bradstreet, who 
verifies that it's from this bank and signs it. The signature is always 
the last one. Need to be aware of it. The master signer is the one that 
adds the Identity header.

Jon: I was going to argue that the CNIT was the .. Signed by.. I want 
the trust to be end-to-end. To get the property - have its own signer. 
being argued in CNIT.

Robert Sparks: as you make the changes, what pitfalls do we need to 
avoid its looking DKIM-y?

Jon: standards action.

Robert: anyone object?

Alyssa Cooper: You could make it more burdensome - have to address how 
it will interact with what is already there.

Jon: we can create a template - what you have to do. I'm good.

slide 5: Eric's Comments

Robin: The authentication service must authenticate - why did Eric make 
that comment?

Jon: Eric thinks that an authentication service is a intermediary. But 
there is no bar, the auth service could be in the endpoint.

Robin: conflation of ... if you hand out credentials, but if you haven't 
authenticated. We can help disambiguate.

Eric Burger (in the jabber room, relayed via Pete): the difference is 
what we know versus a non-IETF implementor. I'm sure the people who 
wrote the PATRIOT Act had no idea it would be used to spy on Americans, 
for example. Yes, the draft has a sentence about the service can be in 
the SIP UA. It then has paragraphs on a separate service. If you did not 
listen to this discussion (and who does), what would you think if you 
were an implementor?  I think we should explicitly describe the three 
major  deployment models: In the SIP UAC, By the service provider 
(P-CSCF/SBC) or Enterprise (IP PBX), and a third-party service bureau 
(as Henning *just* said).

Jon: I'm content to say "end points" and "intermediaries", and these 
elements understand their logical roles.

Henning: I agree. SIP forum and ATIS can explain how to use it in their 
environments as long as the models aren't being excluded. These 
extensions are presented in the draft like characters in a novel. Can 
cover the extensions in the overview. That would address the functional 
flexibility.

Eric: Agree

Jon: Good suggestion.

slide 6: Next Steps?

Jon: As identified here - Identity-Extension to subsume the fingerprint 
and reliance mechanisms.

Brian: I raised the issue about # and *.

Robert: When will this get done? There are environmental pressures to 
finish. Will there be spin and talk in Yokohama, or a LC before late 
September?

Jon: Let's try to do it by September.

Henning: People can send text to help out.

Jon: definitely. There's going to be surgery on this draft.

4:06 60m draft-ietf-stir-certificates-02 - Jon Peterson
Document: https://datatracker.ietf.org/doc/draft-ietf-stir-certificates

slide 1: Title

slide 2: What we did since -01

Martin: I don't see where this is needed. Authorities assign TNs to 
companies that they can punish. If you sign this, it's traceable. If you 
didn't do it correctly, you can be punished. I don't think this mandatory.

Jon: We're trying to detect threats. The certs could be delegated, maybe 
to small enterprises or end users. They can sign from their own end points.

Henning: I don't understand the difference between sign it and - signed 
by number allocated, then signed by ATT, delegated down to a PBX company -

Jon: that's one model. For ATT it isn't useful to list numbers. ATT and 
Verizon trust each other.

Henning: They could create a custom cert for each number.

Jon: Or they can have 1 cert for every number they own.

Paul Kyzivat from Jabber room via Pete: For UAS to be able to 
authenticate, the cert and TNAuthList must be accessible to any UAS. Any 
plan to require that?

Jon: if it is present, it's part of the cert. They have this TNAuthList.

slide 3: Why OCSP? (Refresher)

Eric: Even if we agree to the presentation today, and I will be the 
first to say that I may have *totally* misunderstood the Certs draft, 
but if someone with just half a clue can totally misunderstand the draft 
(and I don't think I did), then someone with a quarter clue will be 
totally lost. And, I agree with others, I still do not see the merits of 
knowing whether or not someone is authorized to sign for a number.

Jon: Can we pull up the charter - the point is to know if someone is 
authenticated to use the number.

Martin: ATT authenticates and validates that the phone can use that 
phone number, ATT doesn't know if its actually _you_. ATT says this 
phone can use this number.

Jon: That's exactly the mechanism.

Brian: and it they want to, they can have just one cert for every number.

Chairs pulled up the charter: The STIR working group will specify 
Internet-based mechanisms that allow verification of the calling party's 
authorization to use a particular telephone number for an incoming call.

Martin: The solution doesn't need to include TNs in the cert. You need 
to validate the cert.

Jon: If I can get to the slide that describes this.

slide 4: In-band STIR Logical Architecture

Henning: Every student in computer science knows that any problem can be 
solved by adding another level of indirection. We're trying to avoid a 
per-number cert.

Jon: But we will allow it.

Henning: The number of network transits

Jon: have whole slide. From an efficiency perspective. OCSP is not 
required.

Henning: The more mechanisms we add, on the validation side, you have to 
support all of them. I'm worried that the more mechanisms, the higher 
the burden on the receiver. We've just added complexity without adding 
value.

Jon: I think we should go the slides

Richard Barnes: you should do OCSP anyway - then 0 cost.

Jon: can download via URL.

Eric: I do not want to let the statement "The charter says we MUST have 
a cert mechanism to carry TNs" go unchallenged. That is factually 
incorrect.

Paul: if I get a cert not from ATT, but from acme-telco.net signing a 
number, if I can't get evidence that it is entitled to sign for the 
number, then why would I trust it?

Pete, to Eric: Nobody is saying that the cert has to carry the TN 
AFAICT. Who did?

Eric: The alternative in the draft is you poll at a transaction rate of 
100,000 tps for a typical U.S. busy hour to ask someone else if the cert 
covers the TN. Not a realistic model. So it is not the issue of carrying 
the TN, but that anyone cares about the TN at all. (TN in the or covered 
by the cert. Of course, the whole point is validating the TN)

Jon: I think we should take the discussion to the list. At a high level, 
it won't matter to you. But it's to support use cases, that the cert is 
associated to TN. This charter is not of use for you.

Brian: 100k/hour or minute is no big deal. We can do that.

slide 5: RFC5019 vs RFC6960

Richard: This thing shouldn't impact scalability of RFC5019

Paul:  if the usage model becomes one of recipients trusting certain 
signers, then users will be forced to get their numbers from a widely 
trusted provider.

Jon: Don't think so - there will be a proper chain of delegation

Robin: There's a level of confusion - who is trusting what, how is it 
exchanged? TN vs not-TN, what's it mean?

Jon: we say what goes on the wire, you make the decision of what to do. 
If there's interest in specifying the policy decisions. As the bis draft 
becomes more DKIM-like.

slide 6: Our Extension: TNQuery

Jon: Sean and I talked this over. Seemed OK. Russ? Russ is not barfing. 
Don't want an "unknown" response, it has hard edges.

Richard: the optimization that 5019 gives you is based on "unknown". If 
a cert is expired, you don't have to keep it. It lets you pre-generate 
responses.

Russ: There's also a serial number that hasn't been issued.

Richard: The only thing you say yes on - are things that are valid. 
Things expired or not issued - it's unknown. The cert is "unknown".

Jon: I don't trust it. Why have even have "unknown"?

Henning: One reason - for caching. If you receive a no, the cert won't 
get more valid with time. If you get an "unknown" - you might try again. 
I have a question about the mechanism - a validator would separate into 
- carriers will sell you a cert and say OCSP.

Jon: You have to check the OCSP - see the chain.

Russ Housley: OCSP responses - good, bad, unknown - the only one you are 
interested in is good. We are adding - does it apply to the number? If 
the cert is good, you get yes or no on that question.

Pete: I'm checking with the chair - go with a whitelist?

Brian: in every formal system, there are always informal systems.

Jon: Premise is false - the carriers don't know each other's numbers. 
And get upset if another carrier finds out.

Jon: what do we do with "unknown"?

Russ: treat it as "no"

???: treat it as "no"

Jon: done

Robert: RTFM

slide 7: TNQuery (2): Open Questions

Richard: it doesn't seem critical, you get the ... Allow multiple TNs in 
the request, it has a privacy benefit. Don't put it in the response. 
Like fuzzing in geopriv.

Robert: you can't say yes for some.

Jon: you can glom OCSP into one request.

Richard: check the RFC.

Robert: Since i haven't read the RFCs in quite some time, can you 
include more numbers in the response than in the request?

Richard: yes. you can cache by chunk.

Jon: yes

slide 8: TNQuery (3): Why do you ask?

Jon: would like to tie the request to a call. To avoid impersonators and 
spidering.

Richard: the attacker can't ask for any number. Has to be in the scope 
of the cert. They can segment the space.

Jon: But if Martin wants to be lazy, I don't want to prevent that. It's 
only fair, what he gives me on the list.

Henning: you have to have a small number - a cert for an area code 
doesn't help a whole lot. I don't think dividing the space will help.

Martin: if you allow for one cert per carrier. ok.

Jon: do we think this is a problem? We can work on it.

slide 9: Fancy Measures

Robert (from floor): reacting or overreacting to this in real time - 
I'll restate what I heard. CA gives a secret to the caller. The hash is 
included in the request and the hash has

Jon: TN is part of it with the nonce.

Robert: why restrict it to the TN? OCSP server digests the hash. Could 
you bury the ranges in the hash?

Richard: (off mic)

Russ: it certainly interferes with this.

Robert: this is getting weedy.

Jon: ...

Richard: The entire point to add numbers was to provide chaff.

Jon: This is the only promising path.

Richard: not very promising.

Pete: anyone want to do this?

Martin: No!

Pete: Suggestion - let's not do this, and see who yelps. There are other 
ways of doing this.

Richard: I think the answer is no. To put one more knife in this, don't 
you need the signer online to do this nonce-y thing?

Jon: this is an idea that Sean and I had at the bar yesterday.

Russ: I want to see that napkin.

Jon: This is not in the draft, and if people don't want to work on this, 
that's ok.

slide 10: Acquiring TNAuthList By Reference

Henning: who would return?

Jon: Cisco PBX with 1k numbers.

Henning: a carrier that owns 50M numbers. These numbers are going to be 
onsies and twosies because of ports. If the cert says I'm a carrier. If 
I have to ask the LNPA, that changes by the minute and will be outdated 
when I get it.

Jon: 2 cases - root of trust issues every cert. ATT goes to that 
authority to ask on behalf of the entity. The root give it to the 
entity. Or ATT can delegate. All these certs exist still. The chain will 
say if that part of the chain had authority.

Jon: issued by ATT for a larger share.

Henning: list of 50M random numbers.

Jon: all that matters - what's been delegated is a part of the ATT list.

Henning: if I'm a validator, and I don't know the small carrier, and I 
go to the OCSP server.

Jonathan Lennox: Say I'm mafia telecom, and I control the OCSP server. 
It has to be who delegated to mafia telecom.

Jon: 2 ways - go to LNPA or go to the carrier. There's always the guy 
above you. You didn't self-sign the cert.

Lennox: what about multiple delegated chains? I have to validate every 
step in chain.

Jon: yes.

Sean Turner: you have to go up the path, but you can cache. You can send 
more than one request per query.

Richard: I'll throw out a idea in realtime - live OCSP to resolve - 
prefer not to do this for web. OCSP stapling. In addition to cert you 
get a signed blob.

Jon: you put the burden on the sender.

Richard: need to take the idea to the list.

Jon: the signer choses what the validation is. The validator can't ask 
about random numbers. The way to spider is one call per number. The 
stapling occurs during call.

Robin: this heading in a direction of a problem in the web PKI world, 
where there are multiple chains of authority

Jon: there's a single for each country.

Robin: good.

Martin: needs to be simple. Are you still going to have spoof calls? 
Yes. Circuit calls will continue, and they won't be validated. If you 
are going to make it better, but not solved.

Chris Wendt: A while ago I advocated a grouping model. I'm moving to a 
one cert per number model.

Henning: We have 3 mechanisms - caching, OCSP, and this mechanism. What 
I'm missing is an estimate on real scenarios - typical interaction. 
Deployability is the biggest concern. How would OCSP work? If something 
got invalidated 10 seconds ago? Who needs to talk to whom?

Jon: We are designing tools, we're not designing architecture. This is 
the first time we're discussing this.

Henning: a set of roughly common test cases. Long before ATIS gets it. 
We need to have a common understanding about who does what to whom. 
Trying to make it efficient.

Jon: this is new stuff. OCSP changes everything. We're still looking at 
design space.

Eric: And then we are back to the entity issuing the cert attesting they 
are authorized to issue the cert. In the real world, that is good enough 
because as Martin says, they can be punished. It also highlights why no 
one will care whether or not someone is allowed to sign for a particular 
TN, or block of TNs. Punishment is good enough. And then the Mafia goes 
to jail. Bad for a day, but then the problem gets fixed for at least 10 
years. (10 years when they are in jail)

Jon: no comment

Pete: Joe Blow telecom gets a query regarding a call. Joe Blow telecom 
lies about owning the number. As a validator, I received a response from 
ATT about the number, but I won't get the answer that joe blow telecom 
is nonsense.

Jon: you won't get to the OCSP server if Joe is self-signing

Lennox: What's the difference between stapled response and a ...

Jon: ...

Lennox: why would I want multiple?

Richard: tiny response and answer, versus big answer.

Lennox: what's the benefit of big certs? It seems better to be per TN.

Jon: I suspect that carriers want certs for blocks.

Sean: we bring DOS up. But there are other things to worry about.

Brian: create a couple of use cases and work it out.

Chris: Good suggestion.

Jon: the big certs are for big carriers.

Robert: We are out of time.

Jon: I got a lot of good feedback.

Robert: there are lot of comfy couches and hallways here. Have 
conversations.

Russ: Take it to the list.

Rest of slides skipped:

slide 11: Future Work: Subscriptions

slide 12: Other Open Issues

slide 13: Eric's Comments

slide 14: Next Steps

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Tue, 21 Jul 2015 09:31:24 +0000

Edits inline

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of A. Jean Mahoney
Sent: Monday, July 20, 2015 2:02 PM
To: [email-masked]
Subject: [stir] stir 93 meeting minutes

Hi all,

My notes from the meeting below. Ellipses (...) mark places where I didn't catch what was said. Feel free to fill in.

Thanks,

Jean

Secure Telephone Identity Revisited (STIR) IETF 93 Session 2015-07-20 1520-1720: Karlin III

slide 1: Title

"canon" is an optimization, it captures how the signer saw it. Helpful for debugging.
Can assume that everyone within a Trust domain can do the canonicalization. PAI is stripped when leaving the trust domain, but what about 'canon' - maybe the gateway wouldn't remove it. This is noted in the draft text. What's the value of the signature in a closed, trusted network?

Martin Dolly: Not quite true that PAI only originate in a TD. We receive them over other interfaces. Having a verification mechanism and sign it... Enterprises today will send a PAI to the carrier. We process on customer subscriber ID, we don't look at it. For a North Am deployment that the enterprise could use that number, and the basis for the carrier signing it.
>>mcd begin
 .... having a verification mechanism and signing the PAI is the only way to guarantee verification. ...... For a North American deployment, the carrier could validate that the enterprise is allowed to use the number in the PAI (network verification in ISUP/ISDN terms) and sign it.
>>>mcd end

Jon: Do we need to revisit 3325? Kill me if we do. It's the edge element's responsibility to ... and promulgate it through the trust domain.  I'm skeptical that's the motivation.

Brian Rosen: It /might/ be acceptable to write text that the PAI is there... If the person doesn't put in the right From, the call will fail.

Brian: Even if they don't put the canon in, if it doesn't match what is in the From, it's ok. The originator didn't do it right, or a middle box didn't do it right, and it will fail.

Jon: and that's ok.

Henning: Schulzrinne: PAI does cross boundaries across the carriers - SIP Forum/ATIS document.

Jon: This is what Mark Watson was imagining when he wrote RFC3324. The SIP networks would behave like the PSTN.

Martin: If you look at spoof and robocalling, they're typically from smaller carriers. ATT doesn't trust those carriers like it trusts Verizon, but we have to interwork with them. It was said on the list a few times - we cannot just drop calls, we are legally obligated.
>Mcd begin:
....we are legally obligated to complete them.
>MCD end

Jon: how do verify...

Martin: If we are going to deploy on signing certain parts of the messages that are validated at the end. To address reality - you have to sign PAI.

Henning: The brief privacy discussion we had earlier on the list today. 
Anonymity is really pseudo-anonymity. The carrier knows, but not the recipient. The current model - use the standard anonymity in the From header and keep the PAI. We need to distinguish because they are different services. Particularly, if you have anonymous calls, you should sign. Needs to be default behavior.

Jon: we can add motivating text to explain when you want to make the tradeoff. There's privacy leakage. Implementations have to be mindful, and shouldn't hurt anybody.

Robin Wilton: There's another use case - I have a portable, 3rd party number and I give it to other people. It breaks for a couple reasons, like because the receiver won't accept tariff uplift. It might break here.

Jon: I think we have a story for this. NNI use cases that use PAI, would be good to know.

Jon: CNIT - how to implement? I swore I wouldn't do it, but I've defined a blank-check extension header for future proofing - Identity-Extension. 
Need to have strict IANA controls on it - standards action and enough review.

Henning: We have 2 mechanisms - Identity-Extension and identity-reliance mechanisms. Getting cozy with each other. These are exceptional mechanisms and will be widely deployed. The more we unify these concepts. Take URI, make it part of the signature. One can fail, one can succeed. Part of the motivating design - organized and single way. 
Concern about current draft - multiple signing authorities - enterprises and carrier. We need to look at the permutations.

Jon: valid concerns. I allow 1 extension per request. Becomes a LOA, and the decisions become more complex.

Henning: It should not be a kitchen sink. Don't object to raising the bar. What's the operational model? How do you fingerprint it? How to canonicalize it? Do you expect hard or soft failure? There's enough stuff to be specified... I prefer a single, extensible mechanism rather than three. Identity-Extension is not a good sign.

Jon: It can be done. We have 3 things that are one-off mechanisms, may or may not be in the signing. Secure RTP - not always present. 
Identity-Reliance - can sign the entire message. Henning is saying that I should just generalize, and it will look like DKIM. I can live with that, but I swore I would not do DKIM. I want it to be clear - is it trustable?

Henning: From the code perspective: it doesn't matter. I think we're close enough to convergence. It's easier to separate out things that ATIS will worry about immediately versus long term.

Jon: The Identity header ensures the it's signed. Make all the options a Identity-Extension, and a path to extend it.

Henning: Need to be aware of 2 models - single entity doing a lot of sigs. We want to downgrade attacks. You have 2 entities that are doing the signing. Depending on the ordering, may happen before CNAM signing. 
For instance, Carrier signs it, hands it to Dunn & Bradstreet, who verifies that it's from this bank and signs it. The signature is always the last one. Need to be aware of it. The master signer is the one that adds the Identity header.

Jon: I was going to argue that the CNIT was the .. Signed by.. I want the trust to be end-to-end. To get the property - have its own signer. 
being argued in CNIT.

Robert Sparks: as you make the changes, what pitfalls do we need to avoid its looking DKIM-y?

Jon: standards action.

Robert: anyone object?

Alyssa Cooper: You could make it more burdensome - have to address how it will interact with what is already there.

slide 5: Eric's Comments

Robin: The authentication service must authenticate - why did Eric make that comment?

Jon: Eric thinks that an authentication service is a intermediary. But there is no bar, the auth service could be in the endpoint.

Robin: conflation of ... if you hand out credentials, but if you haven't authenticated. We can help disambiguate.

Eric Burger (in the jabber room, relayed via Pete): the difference is what we know versus a non-IETF implementor. I'm sure the people who wrote the PATRIOT Act had no idea it would be used to spy on Americans, for example. Yes, the draft has a sentence about the service can be in the SIP UA. It then has paragraphs on a separate service. If you did not listen to this discussion (and who does), what would you think if you were an implementor?  I think we should explicitly describe the three major  deployment models: In the SIP UAC, By the service provider
(P-CSCF/SBC) or Enterprise (IP PBX), and a third-party service bureau (as Henning *just* said).

Jon: I'm content to say "end points" and "intermediaries", and these elements understand their logical roles.

Henning: I agree. SIP forum and ATIS can explain how to use it in their environments as long as the models aren't being excluded. These extensions are presented in the draft like characters in a novel. Can cover the extensions in the overview. That would address the functional flexibility.

Eric: Agree

Jon: Good suggestion.

slide 6: Next Steps?

Jon: As identified here - Identity-Extension to subsume the fingerprint and reliance mechanisms.

Robert: When will this get done? There are environmental pressures to finish. Will there be spin and talk in Yokohama, or a LC before late September?

slide 1: Title

Martin: I don't see where this is needed. Authorities assign TNs to companies that they can punish. If you sign this, it's traceable. If you didn't do it correctly, you can be punished. I don't think this mandatory.

Jon: We're trying to detect threats. The certs could be delegated, maybe to small enterprises or end users. They can sign from their own end points.

Henning: I don't understand the difference between sign it and - signed by number allocated, then signed by ATT, delegated down to a PBX company -

Jon: that's one model. For ATT it isn't useful to list numbers. ATT and Verizon trust each other.

Paul Kyzivat from Jabber room via Pete: For UAS to be able to authenticate, the cert and TNAuthList must be accessible to any UAS. Any plan to require that?

Eric: Even if we agree to the presentation today, and I will be the first to say that I may have *totally* misunderstood the Certs draft, but if someone with just half a clue can totally misunderstand the draft (and I don't think I did), then someone with a quarter clue will be totally lost. And, I agree with others, I still do not see the merits of knowing whether or not someone is authorized to sign for a number.

Jon: Can we pull up the charter - the point is to know if someone is authenticated to use the number.

Martin: ATT authenticates and validates that the phone can use that phone number, ATT doesn't know if its actually _you_. ATT says this phone can use this number.

Chairs pulled up the charter: The STIR working group will specify Internet-based mechanisms that allow verification of the calling party's authorization to use a particular telephone number for an incoming call.

Martin: The solution doesn't need to include TNs in the cert. You need to validate the cert.

Henning: Every student in computer science knows that any problem can be solved by adding another level of indirection. We're trying to avoid a per-number cert.

Jon: have whole slide. From an efficiency perspective. OCSP is not required.

Henning: The more mechanisms we add, on the validation side, you have to support all of them. I'm worried that the more mechanisms, the higher the burden on the receiver. We've just added complexity without adding value.

Eric: I do not want to let the statement "The charter says we MUST have a cert mechanism to carry TNs" go unchallenged. That is factually incorrect.

Paul: if I get a cert not from ATT, but from acme-telco.net signing a number, if I can't get evidence that it is entitled to sign for the number, then why would I trust it?

Pete, to Eric: Nobody is saying that the cert has to carry the TN AFAICT. Who did?

Eric: The alternative in the draft is you poll at a transaction rate of
100,000 tps for a typical U.S. busy hour to ask someone else if the cert covers the TN. Not a realistic model. So it is not the issue of carrying the TN, but that anyone cares about the TN at all. (TN in the or covered by the cert. Of course, the whole point is validating the TN)

Jon: I think we should take the discussion to the list. At a high level, it won't matter to you. But it's to support use cases, that the cert is associated to TN. This charter is not of use for you.

Paul:  if the usage model becomes one of recipients trusting certain signers, then users will be forced to get their numbers from a widely trusted provider.

Robin: There's a level of confusion - who is trusting what, how is it exchanged? TN vs not-TN, what's it mean?

Jon: we say what goes on the wire, you make the decision of what to do. 
If there's interest in specifying the policy decisions. As the bis draft becomes more DKIM-like.

Russ: treat it as "no"

???: treat it as "no"

Jon: done

Robert: RTFM

Richard: check the RFC.

Jon: yes

slide 9: Fancy Measures

Richard: (off mic)

Jon: ...

Martin: No!

Jon: yes.

Robin: good.

Jon: no comment

Jon: ...

Chris: Good suggestion.

Rest of slides skipped:

slide 14: Next Steps

_______________________________________________
stir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/stir

---

From: Tony Rutkowski <[email-masked]>
Date: Tue, 21 Jul 2015 08:14:56 -0400

Hi Martin,

It might be worth assessing the "obligation" assertion in
light of the Commission's recently released TCPA Omnibus
Declaratory Ruling and Order.  See
https://www.fcc.gov/document/tcpa-omnibus-declaratory-ruling-and-order
See esp. at para. 152 et. seq.

The FCC Ruling and Order is arguably a game
changer, and the basis for implementing STIR
or equivalent platforms.  If you get the customer's
approval, you can drop - unless there is some
additional inter carrier contract obligation.
Although even if there is, the Commission's
Order arguably prevails.

--tony

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Tue, 21 Jul 2015 12:22:27 +0000

Tony,

Yes, of course we can take action, like dropping the call, with the consumers consent.
WTS, what is the criteria? If not the same for all, if not it would be unmanageable. Also, black lists are not a one size fits all solution.

I believe the best model is to deliver the call with an indication that the calling party has been "validated by", and let the consumer to decide to accept or not.

Regards,

Martin

-----Original Message-----
From: Tony Rutkowski [mailto:[email-masked]] 
Sent: Tuesday, July 21, 2015 8:15 AM
To: DOLLY, MARTIN C; A. Jean Mahoney; [email-masked]
Subject: Re: [stir] stir 93 meeting minutes

Hi Martin,

It might be worth assessing the "obligation" assertion in light of the Commission's recently released TCPA Omnibus Declaratory Ruling and Order.  See https://www.fcc.gov/document/tcpa-omnibus-declaratory-ruling-and-order
See esp. at para. 152 et. seq.

The FCC Ruling and Order is arguably a game changer, and the basis for implementing STIR or equivalent platforms.  If you get the customer's approval, you can drop - unless there is some additional inter carrier contract obligation.
Although even if there is, the Commission's Order arguably prevails.

--tony

---

From: Travis Russell <[email-masked]>
Date: Tue, 21 Jul 2015 08:32:24 -0400

There is some potential for “profiling” some of these calls. For example, looking at the characteristics of a group of calls to find commonalities that match the profile of a robocall (something being done today). Its not perfect, but until the problem of spoofed identities gets resolved, its the best means for identifying possible nuisance calls. As these profiles are developed, they can be used in the network core to determine call treatment (block, route, etc). This is the approach that many are taking today. 

Having a “cert” for a caller identity would add to the subscribers confidence that an incoming call from an unrecognized number is legitimate. 

Travis Russell | Director, Product Marketing, Service Provider Networks | 
+1919.205.6857 (o) | +1919.412.1167 (c)

5200 Paramount Pkwy
Morrisville, NC 27560
USA

Oracle is committed to developing practices and products that help protect the environment

> On Jul 21, 2015, at 8:22 AM, DOLLY, MARTIN C <[email-masked]> wrote:
> 
> Tony,
>

---

From: Brian Rosen <[email-masked]>
Date: Tue, 21 Jul 2015 14:37:06 +0200

If you are passing on the responsibility to decide what to do to the endpoint, then you might as well have the endpoint do the validation and decide what to do.
Otherwise, the endpoint has to decide how much it trusts whomever it is currently connected to (roaming, etc) before deciding how to proceed.  After all, an unscrupulous or careless service provider could say “validated by someone else” and not bother doing any checking at all.

We’ve long agreed that the options when validation was completed by the terminating service provider were accept/drop/forward (possibly to voicemail) or label, and that labeling was likely a popular choice.  But I think labeling is the called party ID, “missing” or “invalid” and the SP that is passing the labeling is the source, at least in my opinion.

Brian

> On Jul 21, 2015, at 2:22 PM, DOLLY, MARTIN C <[email-masked]> wrote:
> 
> Tony,
>

---

From: "PFAUTZ, PENN L" <[email-masked]>
Date: Tue, 21 Jul 2015 12:40:14 +0000

The problems with profiles are 1) they change so you are always playing whack-a-mole and 2) they can impact legit calls prior to the stir solution.
I had my office number spoofed which fortunately is a number never actually sent as caller ID (old PBX that sends a main number). If a number is spoofed and then a network, as opposed to an end user, blocks a legitimate call form the number owner, might the caller sue the network? You betcha

From: stir [mailto:[email-masked]] On Behalf Of Travis Russell
Sent: Tuesday, July 21, 2015 8:32 AM
To: DOLLY, MARTIN C
Cc: [email-masked]; A. Jean Mahoney; [email-masked]
Subject: Re: [stir] stir 93 meeting minutes

5200 Paramount Pkwy
Morrisville, NC 27560
USA

On Jul 21, 2015, at 8:22 AM, DOLLY, MARTIN C <[email-masked]<mailto:[email-masked]>> wrote:

Tony,

Regards,

Martin

-----Original Message-----
From: Tony Rutkowski [mailto:[email-masked]]
Sent: Tuesday, July 21, 2015 8:15 AM
To: DOLLY, MARTIN C; A. Jean Mahoney; [email-masked]<mailto:[email-masked]>
Subject: Re: [stir] stir 93 meeting minutes

Hi Martin,

--tony

_______________________________________________
stir mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/stir

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 21 Jul 2015 12:43:49 +0000

In terms of recipient handling, surely all the considerations that currently apply to handling anonymous calls also apply to calls where the identity cannot be validated.

Many networks already offer features where the called user can elect to automatically reject anonymous calls (as opposed to calls where the identity could not be passed for interoperability reasons).

Keith

> From: stir [mailto:[email-masked]] On Behalf Of DOLLY, MARTIN C
> Sent: 21 July 2015 13:22
> To: [email-masked]; A. Jean Mahoney; [email-masked]
> WTS, what is the criteria? If not the same for all, if not it 
> would be unmanageable. Also, black lists are not a one size 
> fits all solution.
> 
> I believe the best model is to deliver the call with an 
> indication that the calling party has been "validated by", 
> and let the consumer to decide to accept or not.
> 
> Regards,
> 
> Martin
> 
> The FCC Ruling and Order is arguably a game changer, and the 
> basis for implementing STIR or equivalent platforms.  If you 
> get the customer's approval, you can drop - unless there is 
> some additional inter carrier contract obligation.
> > Martin: If you look at spoof and robocalling, they're 
> typically from smaller carriers. ATT doesn't trust those 
> carriers like it trusts Verizon, but we have to interwork 
> with them. It was said on the list a few times - we cannot 
> just drop calls, we are legally obligated.
> >> >
> 
> 
>

---

From: Travis Russell <[email-masked]>
Date: Tue, 21 Jul 2015 08:44:25 -0400

Yes you are absolutely correct. Profiling therefore cannot take into account the calling party number. Instead, other characteristics have to be considered. For example, one variation of a robocall is an automated call that rings once and hangs up (hoping the subscriber calls back the missed call). Looking at the signaling one can find:
Short duration calls
Released by calling party
Possibly calling party originated a number of other calls in a range or randomly
Volume of calls from calling party exceeds a certain threshold
etc.

This is the technique being used today in fraud departments to identify suspect calls, where again, the calling party number cannot be the key.

5200 Paramount Pkwy
Morrisville, NC 27560
USA

> On Jul 21, 2015, at 8:40 AM, PFAUTZ, PENN L <[email-masked]> wrote:
> 
> On Jul 21, 2015, at 8:22 AM, DOLLY, MARTIN C <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Tony,
> 
> From: Tony Rutkowski [mailto:[email-masked] <mailto:[email-masked]>] 
> To: DOLLY, MARTIN C; A. Jean Mahoney; [email-masked] <mailto:[email-masked]>
> It might be worth assessing the "obligation" assertion in light of the Commission's recently released TCPA Omnibus Declaratory Ruling and Order.  Seehttps://www.fcc.gov/document/tcpa-omnibus-declaratory-ruling-and-order <https://www.fcc.gov/document/tcpa-omnibus-declaratory-ruling-and-order>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/stir <https://www.ietf.org/mailman/listinfo/stir>
>

---

From: Tony Rutkowski <[email-masked]>
Date: Tue, 21 Jul 2015 08:47:26 -0400

Agreed.

However, it appears as if the Order encourages
a robust marketplace of protocols and platforms.

It might help if the relevant ATIS committees
engaged in an open standards making process
with publicly available materials.  :-)

--tony

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Tue, 21 Jul 2015 12:53:04 +0000

Agreed, but this is simple manageable criteria

-----Original Message-----
From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
Sent: Tuesday, July 21, 2015 8:44 AM
To: DOLLY, MARTIN C; [email-masked]; A. Jean Mahoney; [email-masked]
Subject: RE: [stir] stir 93 meeting minutes

Keith

> WTS, what is the criteria? If not the same for all, if not it would be 
> unmanageable. Also, black lists are not a one size fits all solution.
> 
> I believe the best model is to deliver the call with an indication 
> that the calling party has been "validated by", and let the consumer 
> to decide to accept or not.
> 
> Regards,
> 
> Martin
> 
> It might be worth assessing the "obligation" assertion in light of the 
> Commission's recently released TCPA Omnibus Declaratory Ruling and 
> Order.  See 
> The FCC Ruling and Order is arguably a game changer, and the basis for 
> implementing STIR or equivalent platforms.  If you get the customer's 
> approval, you can drop - unless there is some additional inter carrier 
> contract obligation.
> typically from smaller carriers. ATT doesn't trust those carriers like 
> it trusts Verizon, but we have to interwork with them. It was said on 
> the list a few times - we cannot just drop calls, we are legally 
> obligated.
> >> >
> 
> 
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 21 Jul 2015 12:59:46 +0000

I suppose the carrier could mark the From (user parameter?) as "verified", "invalid" or "unverified". This obviously only works if the carrier strips any "verified" parameters that it sees on incoming calls. This is conceptually similar to how email MTAs add spam metric and SPF validation headers for incoming email.

In general, we'll need diagnostic headers for call filtering and validation.

________________________________________
From: stir <[email-masked]> on behalf of DOLLY, MARTIN C <[email-masked]>
Sent: Tuesday, July 21, 2015 8:53 AM
To: DRAGE, Keith (Keith); [email-masked]; A. Jean Mahoney; [email-masked]
Subject: Re: [stir] stir 93 meeting minutes

---

From: Robert Sparks <[email-masked]>
Date: Tue, 21 Jul 2015 16:03:14 +0200

Folks -

When you change the topic of a thread, please change the Subject.

The conversation started from the raw minutes will be hard to find 
searching for it later, and it will be in the way when preparing the 
final minutes.

RjS

---

From: Richard Shockey <[email-masked]>
Date: Tue, 21 Jul 2015 10:00:42 -0400

Both of you are correct.

The ³Safe Harbor² provision in the FCC Order provides the underpinning to
block in the case where the consumer or enterprise has granted consent.

Martin is also right to point out the entire STIR system is somewhat
useless unless the consumer enterprise is given some indication of who is
calling and the level of trust the network has in that data. That will
require two parts. First how is the data passed in the INVITE and B how
does the CUA display it. 3GPP will have to get involved with this at some
point.

Third if the call is blocked then the originating party should have some
indication that the call was blocked and why. That will require some
modifications of the REASON headers.

And yes blacklists suck. Whitelists are not much better since they create
the balloon problem Where you think you solve the problem but the bad guys
just start using allocated numbers and the problem gets even worse.

On 7/21/15, 8:22 AM, "stir on behalf of DOLLY, MARTIN C"
<[email-masked] on behalf of [email-masked]> wrote:

>I believe the best model is to deliver the call with an indication that
>the calling party has been "validated by", and let the consumer to decide
>to accept or not.
>
>Regards,
>
>Martin
>
>Commission's recently released TCPA Omnibus Declaratory Ruling and Order.
> See

---

From: Hala Mowafy <[email-masked]>
Date: Tue, 21 Jul 2015 14:22:53 +0000

Keith,
I agree in principle that could be one possible treatment for non-validated calls. It may be easier to offer it as a service (just like Anonymous Call Rejection: ACR) and educate the consumer that they may miss some important calls.  This way, if you subscribe, it is your choice, your responsibility. 
Keep in mind that ACR gives the "anonymous" caller an announcement that if they wish to reach this called party they need to change their status to "public" and re-dial.  And that is easy with the star codes. 
Similarly, for non-verified calls, the caller should be informed of the outcome.  I imagine if you are a legitimate caller, you are more likely to have other means of contacting the recipient; e.g., email or text.  
But other options need to be thought out. 

Allowing callers to leave a VM will be just as annoying as it is today with getting 50 robo call VMs a day.  However, if it is a doctor calling for the first time, has no other contact info for you, how does he get the message across without a VM?

I also imagine if a legit caller encounters this treatment frequently, he may contact his SP or eventually change his SP!  
BR/
Hala
Sent from my iPhone

> On Jul 21, 2015, at 2:44 PM, DRAGE, Keith (Keith) <[email-masked]> wrote:
>

---

From: Richard Shockey <[email-masked]>
Date: Tue, 21 Jul 2015 10:07:49 -0400

>with publicly available materials.  :-)

Oh you mean like thisŠyes the documents are free.

ATIS and SIPForum Complete New IP-Based
Network to Network Interface (NNI) Technical Specification

Joint task force delivers major milestone with the publication of the
first standardized, industry-based,
consensus-driven specification designed to achieve IP-based
interconnection of service
provider networks.

http://www.sipforum.org/content/view/431/171/

>>the calling party has been "validated by", and let the consumer to
>>decide to accept or not.
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Jul 2015 10:48:47 -0400

> modifications of the REASON headers.

IMO "should" is too strong here. Telling the calling party they have 
been blocked is one policy that might work for some callees. So having 
additional mechanisms to communicate reason to them are fine. But some 
may want to use another policy. E.g.

- allow the call to appear to the caller as "ringing" until the caller 
decides to hang up. (But without bothering the callee at all.)

- route the call to a special voice mailbox and record the message for 
future analysis.

- route the call to what appears to be a voice mailbox, but that doesn't 
bother to record the media at all.

All of these could be accompanied by keeping a log of such calls.

My point is that this ought to be a policy decision by the *callee*.

	Thanks,
	Paul

---

From: "PFAUTZ, PENN L" <[email-masked]>
Date: Tue, 21 Jul 2015 14:56:27 +0000

Paul,
I have some concerns about approaches that mislead the caller about what is happening:
1. In the US, carriers are now required to report on rural versus non-rural call completion and non-answered call disposition. What you propose might skew these statistics
2. Although the FCC has said that carriers may block calls at customer request, it is not clear that this extends to sending back what is essentially false signaling - explicitly prohibited in the order.
3. When calls are failing without explanation, calling customers including legitimate telemarketers - unwanted as they may be - may complain to their carrier resulting in wasted network investigations. Some blocking services already this this result.

I'd be interested in Henning's take on this...

Penn Pfautz
AT&T Global Connection Management 

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Tuesday, July 21, 2015 10:49 AM
To: [email-masked]
Subject: Re: [stir] stir 93 meeting minutes

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Jul 2015 11:10:21 -0400

> I'd be interested in Henning's take on this...

(I changed the subject line this time.)

Well...

The approaches I mentioned can be achieved by the callee's UA. AFAIK 
that is not subject to FCC rules.

I would think it reasonable that any behavior legal for an end user 
should be able to be delegated to a provider without it becoming 
forbidden. (But I realize that being reasonable doesn't always apply to 
telecom regulations.)

Still, I think such behaviors ought to be considered possibilities, even 
if they may not be used in some contexts.

	Thanks,
	Paul

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 21 Jul 2015 15:23:29 +0000

I'd note that when anonymous call rejection was defined in European documents, the caller was notified that the call was rejected specifically for this reason.

Remember also that the calling user is generally paying for this call, and has a contract with the telecommunications provider to provide service. There is a balancing of rights here between the calling user, the called user, and one or more network operators. While forcing a spoof caller to incur additional costs may seem justified to the called user, it might not necessarily be justified when a complete analysis of all parties rights is performed.

Some of these actions also have legal implications in some jurisdictions, so for example recording a call without giving notice that the call is being recorded. 

Regards

Keith

> From: stir [mailto:[email-masked]] On Behalf Of PFAUTZ, PENN L
> Sent: 21 July 2015 15:56
> To: Paul Kyzivat; [email-masked]
> 1. In the US, carriers are now required to report on rural 
> versus non-rural call completion and non-answered call 
> disposition. What you propose might skew these statistics 2. 
> Although the FCC has said that carriers may block calls at 
> customer request, it is not clear that this extends to 
> sending back what is essentially false signaling - explicitly 
> prohibited in the order.
> 3. When calls are failing without explanation, calling 
> customers including legitimate telemarketers - unwanted as 
> they may be - may complain to their carrier resulting in 
> wasted network investigations. Some blocking services already 
> this this result.
> 
> > Third if the call is blocked then the originating party should have 
> > some indication that the call was blocked and why. That 
> will require 
> > some modifications of the REASON headers.
> 
> IMO "should" is too strong here. Telling the calling party 
> they have been blocked is one policy that might work for some 
> callees. So having additional mechanisms to communicate 
> reason to them are fine. But some may want to use another policy. E.g.
> 
> - allow the call to appear to the caller as "ringing" until 
> the caller decides to hang up. (But without bothering the 
> callee at all.)
> 
> - route the call to a special voice mailbox and record the 
> message for future analysis.
> 
> - route the call to what appears to be a voice mailbox, but 
> that doesn't bother to record the media at all.
>

---

From: Tony Rutkowski <[email-masked]>
Date: Tue, 21 Jul 2015 11:47:34 -0400

> does the CUA display it. 3GPP will have to get involved with this at some

Hi Richard,

3GPP SA3 is already involved.  Below is the draft
report text from the last meeting in April.
The next SA3 meeting is coming up in August.
Also GSMA plays a major role here, and has
has initiatives over the past few years.

> 8.4     IMS Enhanced Spoofed Call Prevention and Detection
> S3-151307    FS_ESCAPADES: Previous spoofed call detection solutions
>                     TR 33.832 v..
> Source: NEC
> Abstract: This document introduces previous spoofed call detection 
> solutions to TR 33.832.
> Discussion: Nokia Networks supported the document.
> Decision:         The document was approved.
>
> S3-151295    Spoofed call actor definitions
>                     TR 33.832 v..
> Source: Sprint
> Abstract: -
> Decision:         The document was approved.
>
> S3-151296    Valid and invalid (spoofed) call scenarios
>                     TR 33.832 v..
> Source: Sprint
> Abstract: -
> Decision:         The document was approved.
>
> S3-151309    Summary of IETF STIR group active drafts on spoofed call 
> detection
>                     TR 33.832 v..
>                     Source: Alcatel-Lucent
> Abstract: summary of IETF STIR group active drafts on spoofed call 
> detection
> Decision:         The document was approved.
>
> S3-151308    FS_ESCAPADES: Consideration on verifier behaviour against 
> detected spoofed call
>                     TR 33.832 v..
>                     Source: NEC
> Abstract: This document identifies a consideration regarding the 
> verifier behaviour against detected spoofed call and then proposes a 
> corresponding contribution to sub clause 8.1 of TR 33.832.
> Decision:         The document was revised to S3-151533.
>
> S3-151533    FS_ESCAPADES: Consideration on verifier behaviour against 
> detected spoofed call
>                     TR 33.832 v..
>                     Source: NEC
> (Replaces S3-151308)
> Decision: The document was approved.
>
> S3-151534    TR 33.832
> Source: Rapporteur
> Decision:         The document was left for email approval.

---

From: Eric Burger <[email-masked]>
Date: Thu, 23 Jul 2015 21:12:42 -0400

Just a clarification. As reported in the minutes, I stated that if STIR ended up making OCSP or other per-call queries, that would put a transaction rate of 100k transactions PER SECOND.

100k per hour is old school.

100k per minute is challenging.

100k per second is stupid.

> On Jul 20, 2015, at 2:02 PM, A. Jean Mahoney <[email-masked]> wrote:
> Eric: The alternative in the draft is you poll at a transaction rate of 100,000 tps for a typical U.S. busy hour to ask someone else if the cert covers the TN. Not a realistic model. So it is not the issue of carrying the TN, but that anyone cares about the TN at all. (TN in the or covered by the cert. Of course, the whole point is validating the TN)
>

---

From: Eric Burger <[email-masked]>
Date: Thu, 23 Jul 2015 21:12:47 -0400

On the one hand, I 1,000% agree with Paul. On the other hand, NONE of this is in scope for STIR. All we do is provide the marking. If in Country A the service provider is barred from blocking calls, fine, the customer’s UAS can deal with it. If in Country B the service provider offers a premium service to block such calls, great, the service provider can block them. If in Country C there is a robust free market of services providers offering CPL scripts to Joe Sixpack so he can program his own enhanced service, great, Joe can have at it.

The point is NONE of this is anything we should be saying anything about in a protocol document. It would be great in a Gee Whiz Look At How Cool STIR Is document.

> On Jul 21, 2015, at 10:48 AM, Paul Kyzivat <[email-masked]> wrote:
> 
> IMO "should" is too strong here. Telling the calling party they have been blocked is one policy that might work for some callees. So having additional mechanisms to communicate reason to them are fine. But some may want to use another policy. E.g.
> 
> - allow the call to appear to the caller as "ringing" until the caller decides to hang up. (But without bothering the callee at all.)
> 
> - route the call to a special voice mailbox and record the message for future analysis.
> 
> - route the call to what appears to be a voice mailbox, but that doesn't bother to record the media at all.
>

---

From: Eric Burger <[email-masked]>
Date: Thu, 23 Jul 2015 21:12:50 -0400

Like the subject says, this is a policy issue, not a STIR issue. Carriers and subscriber’s UAS’ and service bureaux will do whatever STIR enables. We absolutely cannot be in the business of setting policy!

Now, the point that we may need new status codes is correct. More especially with PSTN-IP interworking, we may need to prepare a liaison with ITU-T to add some SS7 ISUP cause codes.

> On Jul 21, 2015, at 10:56 AM, PFAUTZ, PENN L <[email-masked]> wrote:
> 
> Paul,

---

From: Richard Shockey <[email-masked]>
Date: Thu, 23 Jul 2015 21:25:06 -0400

On 7/23/15, 9:12 PM, "stir on behalf of Eric Burger"
<[email-masked] on behalf of [email-masked]> wrote:

>Like the subject says, this is a policy issue, not a STIR issue. Carriers
>and subscriber¹s UAS¹ and service bureaux will do whatever STIR enables.
>We absolutely cannot be in the business of setting policy!
>
>Now, the point that we may need new status codes is correct. More
>especially with PSTN-IP interworking, we may need to prepare a liaison
>with ITU-T to add some SS7 ISUP cause codes.

LOL .. Oh that¹s funny Eric modify ISUP cause codes ..that is the funniest
thing I¹ve heard all day other than the latest Donald Trump quote.

---

From: Richard Shockey <[email-masked]>
Date: Thu, 23 Jul 2015 21:30:24 -0400

Exactly finish 4474bis and then we are done.

On 7/23/15, 9:12 PM, "stir on behalf of Eric Burger"
<[email-masked] on behalf of [email-masked]> wrote:

>On the one hand, I 1,000% agree with Paul. On the other hand, NONE of
>this is in scope for STIR. All we do is provide the marking. If in
>Country A the service provider is barred from blocking calls, fine, the
>customer¹s UAS can deal with it. If in Country B the service provider
>offers a premium service to block such calls, great, the service provider
>can block them. If in Country C there is a robust free market of services
>providers offering CPL scripts to Joe Sixpack so he can program his own
>enhanced service, great, Joe can have at it.
>
>The point is NONE of this is anything we should be saying anything about
>in a protocol document. It would be great in a Gee Whiz Look At How Cool
>STIR Is document.
>
>>>some
>> - route the call to what appears to be a voice mailbox, but that
>>doesn't bother to record the media at all.
>>