[stir] stir 95 meeting notes, second session - raw

["A. Jean Mahoney" <[e-mail]>]

Below are my raw notes from the meeting (they are more raw than the 
first set of notes)

Thanks,

Jean

-----------------------------------------------------------------------------------
STIR: IETF 95

Thursday, Afternoon Session II 1620-1720
Buen Ayre A

-----------------------------------------------------------------------------------
5m Administrivia

presenter: Robert Sparks
slides:    https://www.ietf.org/proceedings/95/slides/slides-95-stir-0.pdf

Note taker: Jean Mahoney
Jabber relay: Dan York

Jabber log: http://www.ietf.org/jabber/logs/stir/2016-04-07.html

Note well and agenda were presented. No changes to the agenda.

-----------------------------------------------------------------------------------
45m draft-ietf-stir-certificates

Presenter: Jon Peterson
Slides:    https://www.ietf.org/proceedings/95/slides/slides-95-stir-5.pdf


slide 4: In-band STIR Logical Architecture

ekr - a reference rather than the entity - fore compression?

Jon - for this cert, is this number in scope. Rather than telling all 
the numbers. I don't want to rule out a db.

ekr - Referential integrity of the info. If the protected property - see 
only some of the records.  Tie the integrity to the info rather than to 
the signature.

Jon - we'll go into details in a bit.


slide 5: The First Approach

Richard - there's a scalability issue here.

Jon - 95% of the numbers are done by the top 12 carriers.

Martin Dolly - you could start with this. The long pole is what's 
displayed to the end user. Staged deployments - 7-8 carriers deploy 
signing first and doing it this way. Exchanging certs. At a later date 
there's delivery to the end user. And it's been verified. That's a 
workable path.

Jon - I have a migration path slide. We're not telling operators whom to 
trust. I want to provide support to the operators.

Chris - I'm hoping that this is simpler and can rely on cryptographic 
trust, not just trusting self-signed certs from carriers. There's an 
authority that signs. Need to get the protocol in place and the calls.

Jon - we need a transitional strategy.


slide 6: The Second Approach

Dan York on behalf of Eric Burger - Second approach simply will not work 
in the U.S. Numbers are regularly, and for good reasons, listed as the 
Caller ID that do not have anything to do with the carrier. So, a 
legitimate call under the Second Approach will be rejected. Approach Two 
is DOA, at least in North America, and probably in most jurisdictions. 
This issue also kills the Oracle function Jon mentioned related to the 
First Approach. The most we can do is trust the vouching carrier.

Jon - that's a strong assertion and I would understand the motivation. 
That's not my understanding. Why are we not arresting Tim Cook for that?

Eric - Your number is served by Verizon wholesale number but you're a 
Centurylink customer. You have an ATT 800 number but you're a 
centurylink customer.

Jon - but you can delegate and it solves this problem.

RjS - We have an RFC that says that we are solving this case.

Jon - We are ascertaining that ... It's preposterous that this is illegal.

RjS - I don't think Eric was saying it was illegal. It won't be asserted 
to the person that ...

Dan York  - For hosted apps like Doctor's offices, does the 2nd approach 
work?

Jon - yes. I brought this up in lurk. There are ways to address secure 
redirect.

Chris Wendt - we need a mechanism to protect law enforcement, teachers, 
IRS, etc. and solve this problem for them.

Jon - a seasonal problem is robocalling from IRS numbers - tactically 
protecting some numbers.

ekr - any situation get the cert and then do the fetch.

Jon - if we can make it simple - is this number covered by the cert. 
Don't give me all the numbers covered by the cert.

ekr - you can have a small cert with just one number.

Jon - stapling inverts the privacy consideration.

ekr - that seems viable. OCSP stapling looks like ... If I have that, I 
might as well have cert. You are given a large cert that you can't read, 
please call here for more info. You could have just had a cert with ocsp 
stapling.

Jon - we want an optimization that protects the privacy. I think we can 
punt on that to get us on the migration. If you see something that 
prevents shorter certs, let me know.

ekr - this is flexible. Are all the options useful? I'm assigned a huge 
block. I give you a copy of cert and the chain up the hash tree for 
covers you. If we think certs are enough, we're ok, if it needs to be 
more sophisticated-

Chris - How do we get from A to B? Make sure verification services 
support both approaches.

Richard - if these are done with a meaningful subject, you can use 
existing DKS (?)

Jon - it's CPS.

Eric - By the way, all of the delegation mechanism is TBD in the draft. 
How about a concrete proposal: break the draft into two (or more) 
certificate approaches. Why bundle them together? Approach 1 works 
today. Approach 2 may work if and when fleshed out.  I don't want to 
tell the FCC we are late with STIR because we are working on an approach 
that may not be used.

Jon - I don't want to deliver something that doesn't solve what we said 
in the problem statement. ...


slide 7: Either Way


slide 8: A migration path

Jon - I look like this like DKIM. I want to see large providers do this 
well. We won't be late if we provide a starting point, migration path. I 
don't want implementers only to implement the first step.

ekr -

Martin - I think the first approach with OCN in the cert can go past the 
gang of 8. The 2nd approach is also useful. Supporting both and having a 
migratory path. And can get consensus around it.

Eric - So, if the approach is to put out something that works for 90+% 
of traffic and then, with experience, will work for everybody, why toss 
out something that we may learn, from experience, may or may not work. 
We might even learn the right, right way to do it.

Jon - If the gang of 8 were the source of the calls that are 
problematic, it would be a great solution. But it's the smaller entities 
that are source of problem calls.

Dan York - You and Eric are in violent agreement that approach 1 can be 
done.

Jon - the migration path is not a standard. We will put a standard that 
will create the path.

Dan - Eric just wants to stop with approach 1. But you want to include 
the 2nd approach.

Eric - I want to stop with Approcah 1 for now. Need to learn more before 
doing Approach 2. Important point is "for now", not "for ever"

Jon - I disagree. It's a mistake.

Chris - I'm not sure we're talking about gang of 8.

Richard - looking at the charter - approach one doesn't cover it. It 
doesn't verify the telephone number. Need to get to 2.

Jon - just doing 1 is insufficient.

Russ as individual - approach 1 builds on available tech and get going. 
approach 2 requires new extensions. We need to work on them and learn. 
If we need to do a v2 of approach 2, lets do that.

Jon - the stuff can be built.

Eric - I *do* agree with Richard Barnes. If the threat model is Pink 
Carriers, Approach 1 works.

Jon - pink carriers impersonate ... however the source of this. Henning 
has a draft on this. For VM hacking, the approach is a good one. The 
robocalling one, it's not.

Eric - Agree with Russ: Publish Approach 1, work on and Publish Approach 2.

RjS - I'd like to take a hum. First hum is, if you think we should go 
down Jon's path and persue both approaches. 2nd hum is split the doc - 
do one approach then the other.

Ken Carlberg - could we push approach 2 to an appendix to get a current 
snapshot and continue approach 2 in another document?

Russ - that's just a hybrid.

RjS - Ok, first hum: Should we document both approaches now?

Hums in room, not in the chat room.

RjS - Second hum: Should we split the approaches - put approach 2 in an 
appendix or 2nd document?

2 hums in chat room. None in the room.

RjS - There is a strong majority in the room. If you dissent, please 
argue on list.


slide 9: The IETF and the industry


slide 10: Moving forward

Jon - Are we cool here? Should we worry about the privacy model? Any 
discomfiture with the approach.

No comments.


slide 11: One last plug...

RjS - when will we see the next version of the draft?

Jon - We need to schedule an interim phone call 6-8 weeks, target a 
draft then.

RjS - late may - early june, then.


HUM: There is a strong majority in the room for documenting both 
approaches now.

ACTION: schedule an interim call.

-----------------------------------------------------------------------------------
10m Next steps

No other business.