Minutes for STIR at IETF-95
minutes-95-stir-1

Minutes - Secure Telephone Identity Revisted (STIR) - IETF95

STIR met in two sessions - the first on Tuesday Apr 5, the second 
on Thursday Apr 7.

The RFC4474bis and passport drafts are nearing working group last call.
The participants in the meeting were comfortable with the changes made
in the recent versions, particularly with the handling of Date.  
A provisional mime type registration for application/passport was
completed during the meeting.  A virtual interim will be held in late
May to drive those to completion and make progress on certificates. The
drafts need revision to finish aligning syntax.  Additional examples
and backwards compatibility text will be added.

High points from the discussion:

* The participants in the meeting strongly supported requiring
that verifiers implement verifying signatures based on ECC
algorithms and signatures based on RSA algorithms

* There was a long discussion around how to avoid having a space
in the json serialization carrying fingerprints. It converged to 
replacing the space with a period.

* The participants in the meeting strongly supported having the 
initial certificates draft document both the approach of identifying 
the number holder in the certificate's subject (identified as 
Approach 1 below), and defining certificates that identify the 
held numbers (Approach 2).

Thanks go to Jean Mahoney and Brian Rosen for taking notes,
and to Dan York and Sean Turner for Jabber scribing.
The raw notes for each session are included below.

================ RAW NOTES: Jean Mahoney : Tuesday Session ===================
STIR: IETF 95

Tuesday, Afternoon Session III 1740-1910
Quebracho B

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

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

Note takers: Brian Rosen and Jean Mahoney
Jabber relay: Sean Turner
Jabber log: http://www.ietf.org/jabber/logs/stir/2016-04-05.html
Note well and agenda were presented. No changes to the agenda.

----------------------------------------------------------------------------
10m  Overview of changes across the WG documents

presenter: Sean Turner
slides:    https://www.ietf.org/proceedings/95/slides/slides-95-stir-1.pdf

  Brian Rosen asked if it was still true that anyone on path can do the
  verification.

  Sean said that it was still true.

  No actions.

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

presenter: Jon Peterson
slides:    https://www.ietf.org/proceedings/95/slides/slides-95-stir-2.pdf

slide 1: Title
slide 2: Divide and Conquer
slide 3: Changes since -06
slide 4: Date Fix

  Jonathan Lennox - You need to check for copy-n-paste attacks.

  Jon - It's there in the text.

  Jon (to the room) - we're cool? The Date fix is the biggest change.

  Room had no objections.

slide 5: Extensibility

  Chris Wendt - The worst case would be 2 identity headers with two tokens.
  It would nice to combine those.

  Jon - Either we build it into ppt or create a MIME type. We can do
  either.  There's no good reason to do one or the other. Now we're doing
  nothing. If PASSporT decides to make the MIME type a component of ppt, 
  then we don't need to change.

  Eric Burger - There might be different network elements that put them in.
  Having multiple headers may be desirable.

  Jon - It could. we'll talk about it when we talk about extending with
  CNAM.

  Chris - We want something that can combine them like CNAM.

  Jon - It would be nice not to have 15 of these things.

slide 6: Opportunistic STIR

  Jon - This is of marginal benefit but still offers some benefit. This is
  not in the main path of deliverables.

  Alan Johnston - This is orthogonal to OSRTP. I don't have an opinion on
  this.

  Jon - The signature is only as good as the entity that signed over it.
  Can be added without knowledge or consent of the app, but not meddled with
  by a MITM.

  Alan - It can't be used in place of OSRTP.

  Jon - The draft in dispatch will just point to OSRTP. This doesn't
  replace it.  It relies on it. Anyone have a problem with opportunistic
  STIR?

  Room had no objections.

slide 7: Future work

  Jon - Please review carefully because of swapping in passport.

  Robert Sparks - You need to add a few words about backward compatibility
  into the next draft.

  Robert - I see some implementers in room, will you sign up to review?

  Martin Dolly, Eric Burger, John Mattsson volunteered

  Robert - Is anyone going to SIPit?

  Eric Burger - We'll have something.

  ACTIONs: Authors to add text on backward compatibility. Martin Dolly, Eric
  Burger, John Mattsson to review draft-ietf-stir-rfc4474bis.

----------------------------------------------------------------------------
30m draft-ietf-stir-passport

presenter: Chris Wendt
slides:    https://www.ietf.org/proceedings/95/slides/slides-95-stir-3.pdf

slide 1: Title
slide 2: Overview
slide 3: PASSporT Header

  Sean - Have you already registered the MIME Type? It's really easy. Just
  send me email and I can help with that.

slide 4: PASSporT Payload
slide 5: PASSporT Payload
slide 6: PASSporT Payload - Identity Types

  Jon - What about Dr. Hardie's comment that they need to be strictly typed
  and extensible? We're not excluding WEBRTC.

  Richard Barnes - What about Tel URIs?

  Jon - We using otn and dtn. We won't do tel URIs because we want it to be
  canonicalized.

  Chris - Should we forbid tel URIs? A passport can have tel URIs, but it
  wouldn't be for 4474bis.

  Brian Rosen - a URN is a pretty straight forward thing to canonicalize.

  Jon - I'd rather see a phone number in otn and dtn and explain what we
  mean. I would prefer not to see a tel URI.

  Chris - You don't have an option for telephone numbers. Must use otn and
  dtn.

  Jon - Let me look at it.

slide 7: PASSporT Payload - Media Key

  Jon - If it's a telephone number, then use otn and dtn. 4474bis allows
  ouri and dturi.

  Christer Holmberg - There are multiple fingerprints.

  Chris - It's covered in the text.

  Jon - They're alphabetized and concatenated. This is a misalignment
  between passport and 4474bis now. When we'll get to serializing, I'll get
  to it.

slide 8: Multi-Party Communications

  Richard - Should you be tempted to have tight polymorphism and sometimes
  have a string and sometimes have an array, don't.

  Chris - There's nothing to prevent it. That can happen in passport and
  4474bis.

slide 9: Extension to PASSporT base claims
slide 10: Extending base claims
slide 11: Extending base claims
slide 12: Defining new set of claims
slide 13: Registering PASSporT extensions

  Chris - Any opinions on registering extensions?

  Jon - We want to make sure we understand what we're asking people to do.
  People need sufficient guidance when extending passport. What are 
  pitfalls?  We need to get that language correct.

slide 14: Deterministic JSON serialization

  Jon - We can replace the whitespace with a dot or something.

  Chris - Or we can just remove it.

  Jon - With non-SIP protocols this may be the only place the info is. If
  we want people to be able to look at it. It's not terribly confusing. If
  there was a new session negotiation protocol, and it chose to use 
  passport, what would be the form to use? Our responsibility is to be more
  semantically clear. Use a structured data format. One part gives the algo 
  for the keying. Multiple algos listed. The other part, separate.

  Chris - a JSON array.

  Jon - If it's a one-way hash, it can be crunched together.

  Robert - For debugging, I can't think of many cases of visual ambiguity,
  but SHA25 and the first characters are 25 is one.

  Chris - This brings up human readability. Canon with base64 isn't human
  readable.

  Jon - If we're passing the entire object outside of SIP, then base 64
  could be appropriate. In SIP, it should be as human readable as possible.
  Not base 64. I think this is an open issue. We can take a couple of cracks
  at it. We can explore alternate key mechanisms. New keys for JWS. It may 
  be sufficient for STIR. We need to get this done. We may revise this with 
  an array going forward.

  Chris - We should have guidelines for future claims. But we don't have
  text yet. Other than "no whitespace".

  Jon - JWS gives guidance. Need to think of semantics. I would prefer to
  see separable characters. Keep the semicolon. Good enough. Anyone here
  upset?

  Richard - Don't worry about whitespace in the the JSON string, you'll have
  other problems.

  Eric - We can deal with the space.

  Chris - I'm ok with the period.

  Jon - Have a separator.

  Richard - I see no reason why a decoder would want to enforce that.

  Russ - It's so that it can hash the same string. Go away.

  Chris - Space or period?

  Eric - period or vertical bar?

  Brian - vertical bar looks too much like an I.

  Richard - Use template filling. Write the template in the draft. 

  Jon sends Richard to the corner.

  Chris - We'll use a period.

  Jon - We need to provide an example. Last meeting, someone was on the
  hook on this. We need to show whole shebang.

  Robert - I was supposed to find someone to do the example. Cullen was to
  help me. I would like to borrow from the passport document. Show multiple
  fingerprints in an example.

  Chris - I have a tn and uri in that example.

  Sean - I want to see an elliptic curve example.

slide 15: Examples
slide 16: passport-02

  Jon - I'd like to talk about ECC. There is an email saying we should move
  away from RS256. JWT uses this, which is why we are using it.

  John Mattsson - RS and ES are both required.

  Jon - This is a certs issue as much as a passport issue. Can I get this
  from web CAs today? No. We can be forward-looking in our implementation.
  Will use existing web PKI from web CAs. There are people who want to use
  commercial web CAs. If we assume that we will build all new CAs for this,
  I've been told that will take too long. Telling regulators that we'll wait
  for implementers is unacceptable. If we can turn on this year.

  Chris - EC256 has CPU benefits.

  Richard - ECC is technically better.

  Chris - can we say both with a preference?

  Richard - ECC are generally available in the modern CA market. If you use
  Web PKI, you have to commit to move as fast they move. Getting behind 
  means that the devices cannot work. It's worth having a system that has 
  its own CAs.

  Chris - For future proofing, should we recommend higher keys as well?
  384, 512?

  Richard - I don't think I understand. You don't want to specify a single
  elliptic curve. You can say 256 is mandatory to implement and 384 is
  optional.  Ensuring that your software is upgradable is an implementation
  issue.

  John Mattsson - ECC should be required and RSA is optional.

  Chris - CPU

  Sean - We need to get this out in 9 months. Would have to stick with RSA.
  You can get elliptic curves. Verify both - be liberal in what you receive.

  Chris - I like that conclusion.

  Jon - Small keys are great. I listen to Russ, Sean, and ekr. I don't know
  about when it's ready for runtime. Russ, please chime in. I don't have an
  opinion.

  Russ - Do you need one mandatory to implement. Or can you verify both?

  Jon - I'm cool with verifying both.

  Richard - Let's Encrypt will have free ECC certs available in the time
  frame.

  Eric - One and only one is the way to go. ECC certs will be available. Why
  should we make ourselves do more work?

  Russ - Very few EC certs are available today.

  Eric - Only one country will be doing this anytime soon, and in that
  market, it doesn't matter that it's a small handful.

  Jon - It will matter when you are dragged in front of the FCC. Saying
  that we can't do this today makes me nervous. People want it done today.

  Chris - Have it there and then move to ECC.

  Jon - This sounds like a road block.

  Robert, as chair - I'm not seeing pushback on verifiers having to
  implement more that one algo.

  Eric - It's only money.

  Robert - If you don't have a cert that uses the older algos, you won't 
  exercise that code.

  Russ - My sense of the room is that we have verification of both RSA and
  ECC signatures so that we can have a smooth transition to ECC.

  Sean - Happy with the JWT names you have, but you should say why you didn't 
  use the existing "phone number" name. Add explicit text.

  Jon - That one has vCard semantics. JWS registration for claims doesn't 
  require a lot of text, but we can provide text.  Non-normative text about 
  why we're aren't using the current JWT claim for telephone.

  Jon - Need to align on MIME type versus ppt.

  Chris - we can chat about it. A plus in between - can we settle on that?

  Jon - let's just do that. Get this done.

  Robert, as chair - There are just a few minutes left in the meeting.
  Should we break and pick it up next session?

  Martin Dolly - You need to make extensibility very clear in the examples.
  For instance, I'll be writing up extending passport for the
  Resource-Priority header. I'd like to write that doc in ATIS and do the
  registration in the IETF.

  Russ - We had planned to discuss this today, or we can discuss in the next
  session.

  Jon - We can do it now.

  ACTIONs: Authors to register the MIME type (Done). Have verification of
  both RSA and ECC signatures.

--------------------------------------------------------------------------------
15m Passport extensibility

presenter: Jon Peterson
slides:    https://www.ietf.org/proceedings/95/slides/slides-95-stir-4.pdf

slide 1: Title
slide 2: Twofold STIR extensibility model
slide 3: Testing extensibility
slide 4: The "cna" extension
slide 5: Elaborating on "cna"

  Brian Rosen - in your example, you didn't sign the display name in the SIP
  headers, you created a new CNAM thing.

  Jon - the draft does, the slides don't.

  Brian - all I care about is taking a base type and adding a subtype to it.

  Jon - I think it does. If the new claim is not in the SIP message, you
  MUST include canon. Resource-Priority will not require canon.

slide 6: Should we test MIME as well?
slide 7: Sanity checking

  ACTIONs: None
  Russ - have a good evening.

================== RAW NOTES: Brian Rosen : Tuesday Session ================

IETF 95 stir meeting minutes by Brian Rosen
Tuesday, Afternoon Session III 1740-1910 : Quebracho B
          
Administrivia
Overview of changes across the WG documents : Sean Turner
draft-ietf-stir-rfc4474bis : Jon Peterson
  Believed just about ready to go.
  Need reviewers, and hopefully implementations at the next sipit at UNH

draft-ietf-stir-passport : Chris Wendt
  Need a separator, but remove whitespace in JSON serialization.  
  Agreed on period.
  MTI min crypto discussion: Elliptic Curve vs RSA.  Sense of room is to
  require ability to verify both RSA (min 2048) and ECDSA (min 256)

Passport Extensibility - Jon Peterson

=================== RAW NOTES: Jean Mahoney : Thursday Session =============
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 - for 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 whether or not the signator has the authority
  to sign for that number. It's preposterous that this is illegal.

  RjS - I don't think Eric was saying it was illegal, rather that it won't
  work technically.

  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 WebPKI certs.

  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 at this like I look at 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 - Initially we support simply the carrier asserting their identity as
  enough, and then have a migration path to something that supports richer
  delegation.

  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 numbers used by the gang of 8, however the
  robocallig sources -  Henning has a good graph of this - are different.  
  For VM hacking, the approach is a good one. For the robocalling case, 
  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.