STIR WG, IETF 104 FRIDAY, 29 March 2019 at 0900, Karlin 1/2 Chairs: Russ Housley, Robert Sparks Minute Taker: Jean Mahoney Jabber scribe: Sean Turner Summary of actions: ACTION: Jon to create errata on RFC 8224: add DQUOTE to ABNF of "token". ACTION: Mary Barnes, Ben Campbell and Eric Burger will review draft-ietf-stir-passport-divert for WGLC. ACTION: Chris Wendt, Mary Barnes, Sean Turner will review draft-ietf-stir-oob for WGLC. ACTION: Chairs to ask for adoption of draft-peterson-stir-cert-delegation on the mailing list. -------------------------------------------------- Administrivia presenter: chairs slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-stir-chair-slides-00 Agenda Bash - no changes -------------------------------------------------- draft-ietf-stir-passport-divert Presenter: Jon Peterson Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-stir-divert-and-out-of-band-00 slide 1: Title slide 2: draft-ietf-stir-passport-divert-04 slide 3: What’s New in -05? slide 4: An Aside: quoted PPTs slide 5: Issues Jon Peterson - It should have a second WGLC. Any comments? Subir Das - On the quoted PPTs and RFC 8224 - do we need to correct the other claims? Jon - We've been consistent with quoting. I think we just need to fix RFC 8224, everything else uses quotes, like rph. Subir - We used quotes. Russ Housley - Do we need to do a bis? Jon - No, just add an errata. It's a one line change. Robert Sparks - Any volunteers to review the draft? Jon - Mary will read it. Russ - we need one more reviewer. Ben Campbell volunteered. Chris Wendt - I have read it. Jon - It has been thoroughly read on the ATIS side. I haven't read it. I just write, and keep my eyes closed. Russ - Mary and Ben will read it for WGLC. (On jabber, Eric volunteered to read for WGLC as well.) ACTION: Jon to create errata on RFC 8224: add DQUOTE to ABNF of "token". Clarify that the info parameter value is not quoted. ACTION: Mary Barnes, Ben Campbell and Eric Burger will review draft-ietf-stir-passport-divert for WGLC. -------------------------------------------------- draft-ietf-stir-passport-rcd Presenter: Chris Wendt Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-stir-rich-call-data-00 slide 1: Title slide 2: Overview of update slide 3: Three standard key/values for 'rcd' claim slide 4: Example of 'rcd' PASSporT with 'nam' slide 5: Example of ‘rcd’ PASSporT with ‘jcd’ slide 6: Example of ‘rcd’ PASSporT with ‘jcl’ slide 7: Further work/discussion Chris Wendt - Given the BIMI discussion, we talked about adding logos. I don't know. Jon - Saying this recklessly - I think that logos here are slightly more addressable in this case than BIMI. Mostly impractical rather than impossible. Chris - I'd like feedback on phishing in general. Is cnam a phishing attack? Are phone numbers like look like other phone numbers a phishing attack? Jon - Caller ID shows James Bond. Which one is it. Caller name in general has this problem. We're already screwed. Not any more screwed. Mary Barnes - I think we need this. In the other forum people want to see this. There are a lot of examples showing this Eric Rescorla (ekr) - We have an preexisting infrastructure that can attach identifiers to these things. The problem with BIMI and logos - we are talking about a new infrastructure that we don't know how to manage - how to populate it? Chris - We need to think about those things. Jon - I'd put one up if you were to pay me money for it. Apple does this already. This is in the wild. Can we do better than what is in the wild? ekr - Would Apple arrange to show a Cisco logo when Cisco calls an Apple device. Does anyone else do this? Ben Campbell - Logos appear on spoofed calls from Apple. Richard Barnes - Yes we have an existing infrastructure of authorities, and we can propagate and authenticate it. It's only an issue with global interop, I don't think it's this case. Jon - The global email problem is intractable. The NA free phone numbers have a very particular authority structure. There's a responsible organization associated with every free phone number. There's a chain of authority for attesting who that is. I can imagine a registry created just for that. A narrow use case. ekr - If only Fortune 500 companies are allowed to have this - Sure. Richard - For emails, they don't have these pre-existing authorities, and they don't want to introduce them, don't have a proposal for it. ekr - The BIMI case was for four email providers -- Microsoft, Yahoo, Google and AOL -- can have logos appear. The problem is that a logo for RTFM would not appear. The problem is not the authority structure, it's who has the authority for the logo. Russ, as individual - I'm worried that it is a URL to an logo image and there is no hash value in the signed object to make sure the website provider doesn't change the logo. An integrity mechanism is needed to ensure so that the signer of the PASSporT knows the logo that is going to be displayed. Jon - I'm not sure I understand the attack. The original service provider inserts the URL, has control over the website, signs the jcard. It's an https URL. If the case is just Fortune 500 companies, they can point to HTTPS websites that then can point to the logo. If it's originating service providers putting this in, I'm happy if it's optional. Russ - I am not - the Fortune 500 website has a CDN in front of it - the credential is not one-to-one as you are describing it. Jon - What is the impersonation threat model here? Russ - The point is, you want the signer to know what they are signing. Jon - the point in STIR is that there is a particular set of threats that we are trying to mitigate. Russ - You are now adding a logo that is not bound by the signer. Sean Turner as Jabber Scribe, for Eric Burger - Eric will review the previous draft. Or that the logo is some kind of tracker. Note, we don't need to worry much about the tracker, because we have cryptographic identity (and after we finish talking about the reference being kind of in the signature), we do know (and can decide about showing), per Jon. ekr - There are two cases. I sign up for the system, I'm an attested caller. For instance, I'm United Airlines. I have a logo and I call Jon, and then I change the logo to be Delta and sorry Mr. Peterson your flight is canceled, why don't you come to United. Is that the attack? Russ - I was thinking about the website being hacked, swapping what gets displayed, and you get the logo with extra Micky Mouse ears on -- ekr - The attacker is not the attesting party. The attacker is attacking where the logo is hosted. I would be happier with it being treated as a link, not as an authority. Every time I get a phone call, now I have to hit the website - if this Akamai. Having a hash solves that problem. You can do hash caching. What resources are being conserved without the hash? Jon - The jcard is big. We can make the hash mandatory. Not a big deal. Chris - W3C has an integrity header. Jon - The defacing the logo, I can see that as an attack. Chris - Should it be a hash across the entire jcard - the URL and image? Jon - No ekr - You want the URL and the hash of the image together. Russ - Correct. ekr - The object consists of a URL to the image and a hash of the image. If the hash don't match, you have a problem. If I have an object with that image in cache, I just display it rather than looking it up. Chris - How to insert that? Maybe define the jcard thing. Would need to know what the hash is pointing to. Have to figure it out. Sean for Eric - At some point the URL + hash will be about the size of the jpg. Russ - No. Chris - I agree it would be shorter, we're talking about multiple identity headers anyway. Jon - Do we want to talk about JSON vs jscontact? Chris - There was a new effort for canonical JSON. Jon - There's an alternative plan for doing JSON in vCard, but their plan is not to adhere to jcard semantics, would look more like a JSON object. Chris - I don't think there are huge issues. the JSON was directly translated from XML and it is a little fuggly. Sean - It is. I like idea that it's ... and just converting it. Chris - I think we have it and it should work. Mary, as individual - I would rather us not do that. The Dispatch WG didn't agree on the way forward for that work. Chris - Just to address it in case people have questions. Can always define new key value pairs in the future. Mary - Not now. Sean for Eric: I don't think we need to wait another year for JSCARD, if it happens at all... BTW, 608 shows jCard is good enough. Sean - Whatever that is. Chris - sipcore-rejected. I think everyone is agreeing on that point. -------------------------------------------------- draft-ietf-stir-oob Presenter: Jon Peterson Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-stir-divert-and-out-of-band-00 slide 6: Title slide 7: Basic STIR Out of Band slide 8: What's new in -04 slide 9: Next Steps Robert - It would benefit from 2nd WGLC and a couple of dedicated reviewers. This one's easy. Any volunteers? Chris, Mary, and Sean volunteered. ACTION: Chris Wendt, Mary Barnes, Sean Turner will review draft-ietf-stir-oob for WGLC. -------------------------------------------------- STIR Certificate Delegation Presenter: Jon Peterson Slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-stir-certificate-delegation-00 slide 1: Title slide 2: draft-peterson-stir-cert-delegation-00 slide 3: Delegation and Authority slide 4: How does STIR use it? Richard Barnes - +1, for that approach, a necessary and sufficient condition is that the relying parties are instructed to enforce the hierarchy. Jon - They are. That's why theres AS/VS behavior in here that talks about the expectations of the VS. There are some hard edges, like when delegating from an OCN to a TN block. This requires domain expert knowledge to determine the encompassment. I don't know how to fix it; I don't think it can be fixed. There are databases that say which TNs are under which OCN, and you need database access to decide whether a particular TN or block is encompassed by an OCN. Richard - Some certificate chains that have OCN-to-OCN hops will not be globally verifiable. Calling from CZ to Malaysia, and they try to verify against some Czech db. They won't be set up to do that. But that's kinda okay with me, because most use cases are in zones where people have this set up. Where it fails, creates pressure to create TN all the way certificates. Jon - This emerges from North American deployments; it has this property based on SHAKEN principles. I don't see how the general delegation should work for STIR; the assumptions always apply. Those entities that participate in IPNI within ATIS have access to that. People who are verifying it, have access to those resources. It's a trusted network in the RFC 3324 sense, the SHAKEN PASSporTs have to be stripped if they exit the trusted network. Mary - You can get this data from somebody. We have other problems to solve if we want this to work globally. Chris - we are slowly transforming the network. Hopefully the network will evolve. Sean - I echo all of that. There's this verification system that will do this. The worry that a CA will pop up and start doing stuff - pretty hard for that to happen in this system. Richard - This is not blocking. The document should be clear that this is a hard edge. Be nice to provide links to help people connect to these databases. Chris - That's the assumption we have in SHAKEN that it's an implicit association with OCN. That you should verify that the TN is owned by OCN. Jon - I think there's a caveat in the document. We design STIR here, not SHAKEN. STIR is high-level. SHAKEN will have to provide far more detail for North America. Sean - I see this as future proofing the document. Richard - There's general PKI issuance stuff to put in the security considerations. Make sure you prove possession of private keys. If you go out into the wild, here are some bears to watch for. Russ - There will be a Certificate Policy somewhere. slide 5: ACME (through a STIR lens) slide 6: Future Work Chris - Would partial delegation apply to RFC 8226? Jon - Yes, already mentioned in RFC 8226. Richard - 3 letters for you - EKU. This seems extensible. Jon - We don't want to reinvent X.509 here. Jon - Connected identity is STIR in the backwards direction -- know that you've connected to the right identity. The SIPBRANDY work plugs into this as well. Richard - RFC 8555 has fields that say I want this to be that short. The CA can apply policy. What other work is necessary? Jon - We had text in the short-lived certificates document that talked about tradeoffs with OCSP. We were trying to figure out if we should do OCSP stapling for validation. How to specify the ATC. Should the authority be able to say that your token expires in 5 seconds because you're a punk. Jon - Certificate conveyance with X5U with CID, but haven't fleshed it out. Should it be a header. There are chains now. Richard - JWT has a X5C slot where you can stick these things. Jon - Maybe we should to that - X5C. Change everything in RFC 8225. Chris - Certificate rotation mechanisms -- if we don't convey it directly, can we have a pointer to the new certificate before the current one expires? Jon - That's a generic capability. Sean - I want to echo that - CRLs suck. It's not working well. If it makes the industry consider doing better and faster, then I'm all for it. Mary - I don't want to figure out CRLs for this stuff. Can we add it to the new version? Jon - It's a short-lived certificates draft. Are you are volunteering to work on it? Mary - Yes, I don't like CRLs. Chris - This is very important stuff. People want to know how VoIP providers can start signing calls. Jon - Chris and I are getting hammered on this in the industry. Richard - +1, customers are asking for this. slide 7: Next Steps Robert - We can ask for call for adoption on list. If you do not think the WG should adopt this, hum now. Robert - If you do think we should adopt it, hum now. Robert - Room thinks it's the right thing to do. We do need to put it on the list. Sean for Eric - Think it should be adopted, way more important than OOB. ACTION: Chairs to ask for adoption of draft-peterson-stir-cert-delegation on the mailing list. -------------------------------------------------- Wrap Up Adam Roach - There was a discussion around RUM, it may be useful to do work on Called party ID. Jon - That's connected identity. Definitely need it. Robert - Do the reviewers have vacations that would make starting WGLC next week difficult. EOM