Minutes IETF104: stir
minutes-104-stir-01

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.

<No hums in the room.>

Robert - If you do think we should adopt it, hum now.

<Hums in the room.>

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.

<laughter and raspberries in the room>

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.

<None mentioned>

EOM