Subject: [stir] stir 94 meeting notes - raw

From: "A. Jean Mahoney" <[email-masked]>
Date: Thu, 5 Nov 2015 09:47:39 +0900

And below are my raw notes. Ellipses (...) show where I missed stuff.

Thanks,

Jean

STIR: IETF 94: Monday 1300-1500

---------------------------------------------------------
10m Administrivia

Presenters: Chairs
Presentation: 
https://www.ietf.org/proceedings/94/slides/slides-94-stir-0.pdf

Jabber scribe: Daniel Burnett (1st hour), Cullen Jennings
Note takers: Jean Mahoney, Steve Donovan

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

---------------------------------------------------------
20m Report from design team discussions

Presenter: Sean Turner
Presentation: 
https://www.ietf.org/proceedings/94/slides/slides-94-stir-1.pdf

No comments or questions were raised.

---------------------------------------------------------
30m draft-ietf-stir-rfc4474bis

Presenter: Jon Peterson
Presentation: 
https://www.ietf.org/proceedings/94/slides/slides-94-stir-3.pdf

slide 1: Title

slide 2: New Questions about Syntax

slide 3: A Compromise Position

slide 4: The Bare Minimum

Jon - Is there anyone who thinks there needs to be a switch to indicate 
using PAI?

Chris Wendt - I agree in general. From a normative perspective any 
concern with the generality. If they're a service provider network, they 
look at PAI.

Richard Barnes - ... verify twice. ...

Jon - there's multiple PAI headers.

Richard - have to verify every PAI in every combo.

Jon - you already know what you need to use. It's the way it works 
today, and for 15 years.

Cullen - it's fine. It's often the same thing in both headers.

Jon - it will canonicalize to the same value.

Chris  - ... simpler to keep logic the same as it is today.

Dave Crocker, from Jabber room - "Probably"?  So the validator of the 
signature won't know which choice was made by the signer? "Verify twice" 
is an approach to guessing.  Guessing is not typically considered valid 
in interoperable protocol specifications.  The specs need to be 
deterministic.

Jon - supposed to ... deterministically. I appreciate eyes on the draft 
to make sure we don't botch it.

Jon - the SBC could modify the Date header field. Date plays an enormous 
role. If there are transit networks that will modify the Date, I want to 
know.

Cullen Jennings - We had SBCs accidentally modify the Date. Keeping Date 
unmodified is one of the best debugging tools.

Jon - pics or it didn't happen.

Sean Turner - it seems like a surface for an attack.

Jon - yes, you can reply at the later time.

Jim McEachern, from Jabber room - isn't call forwarding another case 
where the time could be modified by something other than the SBC?

Jon - if acting as a b2bua, yes, the new message would have a new date. 
But there are some things that are not compatible with an e2e security 
system. Absent the cut n paste protection, voice mail protection goes 
out the window. There are strategies that we can use to handle the Date 
being tweaked a little bit.

Chris - It would have to be re-signed.

Jon - no. However if people are really mucking - but someone explain to 
me who would do this.

Chris - the concern was about b2bua, and keeping signature valid through 
them.

Jon - ...

slide 5: The Bare Minimum

Adam Roach - are we caring about the assertions?

Jon - yes but optional. It will make the message larger and want to 
discourage that.

Adam - need to know a priori that it will happen.

Jon - correct you can't anticipate how a verifier will handle it.

Adam - this will ...

Jon - there's a good tradeoff on message size vs ...

Jon - this isn't different than what we were doing in the draft. It's 
what we've all been signing. Just a change of syntax. Anyone 
uncomfortable with it?

Robert Sparks - personally have no problem.

Sean - if we're all in agreement, let's just move on

Chris - the benefit is using JWT for other purposes.

Robert - I didn't see any response on the Date question. Let's move 
ahead unless someone screams.

Jon - SBCs are not defined and have broad powers, and we want to get 
through them. Need to decide what will work for deployment environments 
that we care about.

Chris - the point Adam was making. If you want to participate in 
ecosystem, it is easy to update your SBC.

Robert  - if the SBC cannot be differentiated from the attacker ...

slide 6: Multiple Identity Signatures

Russ from floor - we went through this with email, and SMIME only 
supported 1 signature. Transitioning from SHA-1 to SHA-256 caused this. 
This is something we need. The algorithms were different but the 
semantics were the same. Are the semantics different for some cases? If 
not, we can borrow text.

Jon - ... People have a spec that would allow you sign a very different 
set. Like a superuser of the network, authorizing the call. We don't 
specify how the authorization decision is made.

Jon - don't trust the endpoint but trust the intermediary. It's a 
transitive approach to security. there a multiple use cases where spec 
can be useful.

slide 7: Handling Metadata

Do people understand this?

Barnes - I should read the draft. Instead of separate grammars, use the 
specification...

Jon - point me at the draft.

slide 8: Extensibility

Adam - we're focusing on size - what's sensitive to it?

Jon - 700-800 bytes for encoding without spec.

Robert - that's an order of magnitude lower than an SDP negotiation.

Cullen - What you see with a video call at SIPit is not the same as 
carrier phones. If your message gets too large to handle, maybe you 
weren't handling it correctly.

Jon - if you pull out the header and claims, it's 100 bytes. There are 
people who are adamant about using UDP. I've heard of implementations 
that will barf if headers are really large.

Robert - haven't seen it for many years.

Chris - people are clinging to UDP. It's valid to keep it as small as 
possible... Don't know if it's a showstopper.

Jon - what's the change then?

Chris - it's good to have the option of both.

Andrew Allan - ...

Jon - UDP limits are more forgiving than most think.

Jon - What's an appropriate IANA policy for this? If you read the JWT 
extensibility, it is expert-review with spec. I don't see that we'll 
will get a less constrained policy than that.

Dave - DKIM's signature lists the fields it has hashed.

Jon - that's what the first option offers. ...

Adam - JWT talks about some of these being private use. Would that 
approach address their use cases? People who are using this, would be 
nice to have it collected somewhere,

Jon - ...

Richard - if you require the verifier to understand the field, then you 
get stuck in lock step upgrades.

Jon - 1st option... The point is, if you're adding by onesies-twosies, 
you use the first option. If you want to solve a different problem, we 
won't specify it in the IETF, but they want to use the baseline 
mechanism. It's not ideal for me, but I won't say no.

Pete Resnick - why not make it a FCFS registry, with an optional 
specification, and the IETF will use the specification.

Jon - I'd have to think about the trades offs.

Richard - FCFS is not inconsistent

Jon - there's 2 approaches here. 1st one - bare minimum and add a little 
thing to it, if don't understand it, that's ok. But the 2nd is for 
something different.

Richard - ...

Cullen - I haven't heard why they can't deal with FCFS.

Jon - I'll channel the views of those who are not here - The specs 
should not be public. IETF interoperability constraints don't apply. If 
you don't ...

Cullen - if that's it, then the spec should be removed.

Jon - I can image uses of spec, it's in Sean's certs presentation. ... I 
want that to be interoperable. With spec, you don't have to include 
canon and make the message huge. For JWT, you have to include canon. 
Which is why both have their place.

Alissa - don't pervert that for people who don't want to do follow 
process. They can just do it. No reason to pervert a legit use of this.

Robert - we're in dead horse territory.

Jon - If we took a hum, the room would show consensus ... but on the list -

Robert - we can take this to list. I don't think we'll see a hard push 
against FCFS.

ACTION: Discuss IANA FCFS on list.

slide 9: We Have the Technology

Jon - OK with the WG to have a separate WG item on the token? It would 
be Proposed Standard.

Sanjay - 2 docs provides more flexibility.

Sean - I'm fine with it. The 2 people involved in the compromise are 
working on it. Can't we just do it?

Chris - I'm fine with it.

slide 10: Next Steps

Jon - I need to do one more rev, and then we need reviewers.

Robert - ACTION: find reviewers on list.

volunteers: Sean, Chris, Richard

slide 11: The job of non-SIP transports

Jon - Not in charter, need to discuss more. May want to have a call.

Adam - long term, I would like to use this in RTCweb. Don't need to hold 
this up though. If you move to JWT, it becomes elegant. PSTN GW working 
with other protocol. The ability to carry this into the browser would be 
valuable.

Jon - I'll be happy to work with you. Setup a design team on this.

slide 12: Not So SIP specific

Jon - if you have a problem, talk to us.

---------------------------------------------------------
60m draft-ietf-stir-certificates
Presenter: Sean Turner
Presentation: 
https://www.ietf.org/proceedings/94/slides/slides-94-stir-2.pdf

slide 1: Title

slide 2: No New Version

slide 3: What is the STIR certs draft?

slide 4: In-band STIR logical architecture

slide 5: Is there another way?

Jon - we think there are many approaches, they aren't exclusive.

Sean - we're open to input.

slide 6: Ultimate Requirement Questions

Sean - is there anyone who doesn't think the calls should not be 
verifiable on the Internet?

Chris - is that a policy question or tech question

Jon - it's a policy question. Do you want to trust someone with whom you 
have no previous association?

Chris - that's a different question.

Richard - The 2nd question subsumes the first.

Russ from floor - what you are asking is, how are we doing trust ...

Jon - are we going to create systems that constrain...

Richard - one question in 4 forms. How could the answer be no and it 
being ... (something about using keys)

Cullen - I don't know what to make of these questions. If the membership 
of the club is allocated by FCC, we can only provide technology that 
could support that club.

Chris - could boil the question down to, does X 509 work or not?

Sanjay - on your last point, you need to be able to trace the call back.

Russ from floor - to Cullen - there is a trust store, people will 
populate it differently. We can specify the trust store, not what's in it.

Richard - it's not a tech decision. Build a scaleable infrastructure to 
deal with it.

slide 7: Transitive Trust vs Intransitive Trust

Jon - it's unclear how great the value is. It's only saying the previous 
hop vouched for this. We have ways to determine this. Not sure what the 
difference between PAI and when the environment is the small community 
of carriers that trust each other. The difference is that you can see 
past the previous hop.

Chris - It's implying it can only go between carriers. It will be going 
through multiple hops and untrusted networks.

Jon - assume that you are using PAI, what do you get with that? If I 
trust the sender...

Chris - no one is saying that PAI should be trusted no matter what.

Jon - it's your relationship with the carriers you know. It's 
effectively translated. If you discover call was abusive, you can take 
it to Comcast. Should we detect in realtime or just in audit. It's for 
accountability not for realtime.

Chris - I don't think anyone is advocating that.. . unless I'm confused 
by the slide.

Jon - using 4474bis, provides just last hop security not much better 
than PAI.

Chris - that's a new conversation.

Sean - can take to list.

ACTION:

slide 8: Public or Confidential Credentials?

Jon - 2 years ago, there were concerns that the subject would leak 
information. The right way to manage certs (I'm AT&T) is antithetical to 
concerns expressed 2 years ago.

Chris - if you are tying yourself to public keys you are exposing 
something.

Sean - you can have lots of certs, you can leave it blank, lots of ways 
to do it.

Chris - there's some risk of leaking no matter what you do.

Sean - allow implementations to pick their pain threshold.

slide 9: Certs for OCN

Jon explains  - OCNs are carrier ids, may help alleviate leakage concerns.

Richard - trade off between cert size and ... OCSP latency is not up to 
snuff. We're shoving more stuff in the first message we get.

Brian Rosen - OCN doesn't fix the problem. How do get the assignments to 
those guys that don't have those?

Chris - As long as there's flexibility.

slide 10: Other Transitive Approaches

Jon - there's some promise here. ... Tools that verifiers will have...

Chris - I agree with that - there should be some semantics.

Sean - otherwise you don't know what it is.

Chris - but don't go nuts with semantics.

Jon - ...

slide 11: So what now?

Sean - I didn't know about the timeline. Have a design team call.

Jon - need a design team call on certs.

Chris - from our perspective, we want to start out simple with carrier 
certs. Go from there.

Sean - ACTION - Setup a design meeting.

Russ - nail down syntax and semantics of the sig are so we know what the 
requirements for the cert are.

Jon - the FCC has created a timeline for this. I want a LC as soon as 
possible. Make sure that this Date thing is not a blocker.

Chris - ... escape options?

Robert - 5 minutes. Recap: Between now and end of Nov - rev of the 
4474bis draft. The token doc as a stir doc. Start a LC process on 
4474bis at end of Nov. Design team discussion in mid December on certs.