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.