Minutes IETF116: stir: Wed 13:30
minutes-116-stir-202303291330-00

Meeting Minutes Secure Telephone Identity Revisited (stir) WG
Date and time 2023-03-29 06:30
Title Minutes IETF116: stir: Wed 13:30
State Active
Other versions markdown
Last updated 2023-04-13

minutes-116-stir-202303291330-00

IETF STIR WG 116 Meeting Minutes

Wednesday, 29 March 2023 - 15:30 JST

SCRIBE: Simon Castle

Summary

draft-ietf-stir-identity-header-errors-handling has been approved by the
IESG. The only changes during IESG review were editorial.

draft-ietf-stir-passport-rcd is nearing the finish line. There have been
a number of clarifications during IESG review. Participants in the room
also agreed to limit "icn" to use HTTPS URLs. These involve some changes
to normative language. Russ sent an email asking for objections to the
changes to be sent to the list by April 7.

The WG recommends Errata 6519 be set to "Hold for Document Update" and
the notes from IETF115 be added to the erratum.

draft-stir-messaging has had a number of changes due to the AD review.
There are pending changes to clarify the reasoning for the Proposed
Standard status and to reference the COSE registry for integrity
mechanism hash algorithms. (People noted that
draft-ietf-stir-passport-RCD may need to reference the same registry for
RCDi.)

draft-ietf-stir-rfc4916-update has had a number of changes since the
last version and will go to WGLC shortly after the meeting.

draft-ietf-stir-servprovider-oob seems to have resolved most comments.
We need to progress it soon, since related work has already happened in
ATIS. [Note: The minutes do not explicitly mention WGLC, but it sounds
like time.]

draft-ietf-stir-certificates-ocsp is making good progress, but needs
polish before WGLC. Discussion will continue on the list.

Detailed Notes

STIR Working Group at IETF 116

1) Administrivia

  • Agenda Bashing
  • Minute Taker
  • Jabber Scribe
  • Bluesheets

2) Identity Header Error Handling

Chris Wendt: Only changes from 7 to 8 were editorial comments. No
slides. Hopefully all set; we're done.

3) PASSporT Extension for Rich Call Data

Chris Wendt: Hopefully crossing finish line. Resolving last comments,
including Roman Danyliw's very comprehensive helpful comments. Ben
brought up some comments around HTTPS and/or CID.

Chris Wendt: In addressing comments: some normative language change.
Only one that upgraded normative requirements was the "nam" key section;
was clarifying that the display name should be followed as part of
RFC3261. Feedback wanted esepicailly for this one.

Chris Wendt: Other sections on "icn" HTTPS URL refs, JWT Claim
Constraints "rcd" adding a MAY, JWT Constraints for "crn" downgraded
from MUST to MAY, "rcdi" added NOT RECOMMENDED but didn't change the
intent. Level of Assurance removed a MUST and clarified a RECOMMEND
about third-party assurances.

Chris Wendt: A section about "rcd" and "rcdi" claims as additional
claims to other PASSporTs contained a note that was remoevd.

Ben Campbell: That last note being removed didn't change anything right?

Chris Wendt: No, no change

Jon Peterson: Because we're doing that right?

Chris Wendt: Correct. The procedure doesn't change, people just didn't
like the language.

Chris Wendt: Added paragraphs to Security Considerations (RCD URI linked
resources, URL/URI guidance) following Roman's feedback. Happy with
where we've got to.

Ben Campbell: Roman asked why we had a support for URL rather than
HTTPS. We orignally added because we thought e.g. logos might want to be
imbedded in the SIP request. But we'd probably be fine with HTTPS only.
If we need others later we can update. If anyone does want CID etc say
soon!

(Further comments from Chris Wendt and Jon Peterson broadly agreeing)

Chris Wendt: Updates to SIP Core list which are referenced, but that's
pended until after the RCD changes were done.

Ben Campbell: There are a few normative language changes. Propose
leaving for a few days to allow for review and feedback. Silence is
consent. Odds are we'll get through any call directions before the ISG
is ready to prgoress anyway.

4) Errata 6519

Robert Sparks: Errata filed against an RFC about whether the value to
the "ppt" parameter is quoted or not. From meeting recordings and
minutes there's a fairly concise description on what to do, but no
follow-up.

Robert Sparks: Proposal - capture the notes from that meeting as notes
for the errata, put forward with "Hold for Document Update". I don't
think that getting a correction published in the RC base in a more
timely fshion is necessary. It's a minor point of interoperability but
as far as we're aware not causing a problem in deployments. Any
comments? [No response]. That's what I'm going to do.

5) STIR for Messaging

Jon Peterson: This one got out of the WG, into the IESG. This is a draft
for leveraging STIR work into text messaging. More spam in the messaging
network - in part caused because our work in making call spam harder!

Jon Peterson: There's a problem in messaging: E2E encryption.

Jon Peterson: it's a waste to come up with a new approach for messaging,
so just reuse STIR technology.

Jon Peterson: Lots of fixes in -07 after review. Two outstanding fixes
for -08: resuing COSE registry for an algorithmic agility fix, and add a
note to the introduction clarifying that there is (a small amount of)
normative language, but also plenty of informative guidance.

Ben Campbell: Does the rcdi need to reference the same COSE registry?

Jon Peterson: We could, and the msgi description was taken directly from
it. From standards perspective we probably should. Chris would be
writing that - he can just copy what I write for msgi. [Chris agrees]

Jon Peterson: We could add some language around MIME/MME - don't know if
it'll change anyone's world but can do it.

Jonathan Rosenberg: There are other use cases around this and you can
only do that if there's something in the document to start that.

Jon Peterson: There have been preliminary discussions around that, and
someday there will be a draft around that.

Chris Wendt: Want to clarify on the COSE registry - you should have some
text that it says only the hash algorithms.

Jon Peterson: No we're just using their tokens. We can allude to their
algorithms and rely on their expertise. Other than that, I think we're
pretty close and should be able to go forwards.

6) Connected Identity for STIR

Jon Peterson: Connected Identity began as a solution to how you do STIR
in the backwards direction. Problem is it struggles with any redirection
(among other points).

Jon Peterson: So why am I interested in this? Various considerations
looking to leverage STIR. For example, avoiding forged BYEs (Route
higacking, call stretching). So we extended the charter to cover this.

Jon Peterson: Decided last meeting to remove "from-change" and start a
new approach, through introduction of an "rsp" PASSporT, signed with
authority for the 'dest' rather than the 'orig'. It'll work really well
in a sunny-day case with no div (good for things like banking,
healthcare). Can also secure media keys (for messaging cases like MSRP).

Jon Peterson: So I've punted all the "from-change" work. Someone else
could pick this up if they wanted.

Jon Peterson: So new document is not so much of an update to RFC 4916.
It could be said to obsolete that one but it's nice to leave in case
someone does want to fix the "from-change" in the future. I'd like to
make some comments and propose it's ready to advance to Last Call.

Eric Rescorla: Seems better than nothing. Curious what the expectation
is around how the call behaves in the absense or incorrectness of this -
always a problem in incremental deployment of this.

Jon Peterson: We don't specify outright but there could be a critically
flag a user could add which means a call requires this.

Eric Rescorla: Have you given any thought to being able to condition a
caller's expectations in a more useful way?

Jon Peterson: There's some sci-fi language in here that could provide
operational systems or enum like systems to support this.

Eric Rescorla: Is there some way you can decorate the URL?

Jon Peterson: SIP has required supported options tags; we could put an
option tag in for that says something like "it's required that this
option exists for this call to go forward".

Eric Rescorla: Seems like a good start.

Chris Wendt: That's a good point but I think we can punt it to just be a
SIP application that handles the response, and maybe specify something
in the future.

Jon Peterson: There's a lot of stuff in there that says "these
provisional responses aren't reliable". It's kind of best erffort. The
only thing that can mitigate that or create the proper experiecnce is
that there is a criticality button you can press that says "for this
kind of call it's really important and if it doesn't I don't want the
call to be set up." But that's entirely UX. That's my assess; I'm open
to better ideas.

Jon Peterson: I think what's there is baked enough, I'd like some eyes
on it and maybe advance the document?

Ben Campbell: What still needs to be done about this? You said you
needed to decruft this, was that before or after last call?

Jon Peterson: It's just de-crufting, it can be after.

Ben Campbell: So question for the floor is - does anyone think this is
not ready for WG Last Call?

[No comments from the floor]

[Chairs agree to issue a Working Group Last Call for this document ASAP
(And will do a better job about it than last time!)]

7) Out-of-Band STIR for Service Providers

Jon Peterson: What do you do if not everything is SIP? The CPS was
designed as a fallback. We've defined an alternative use case in this
draft where an entity who knows the called/calling parties hosts the
CPS. Aiming for a description.

Jon Peterson: Few useful comments from Simon Castle asking about how the
CPS can be identified. Didn't want to be presecriptive about the process
for advertising but there's questions about how you map from TN to SPC
unless something already exists so the draft now disclaimers that issue.

Jon Peterson: Also added a disambiguation for SPCs vs TNs based on the
TNEntry value. Russ, does that seem sufficient?

Russ Housley: Seems OK

Jon Peterson: Also what if you want to support non-TN based STIR e.g.
URIs. Decided to leave that for someone else to address.

Simon Castle: All comments addressed.

Jon Peterson: So we're all good to go?

Ben Campbell: ATIS has done a document that's based on the concepts in
here. They don't directly reference it and there's been some controversy
there around issues with potential substitution attacks and privacy
issues. I don't think they apply to this draft, just to the ATIS
version, but want to raise to the floor.

Jon Peterson: I agree with you.

Ben Campbell: They make some architectural assumptions that change the
security consideration some; I'm not taking a side on whether it's a
but...

Jon Peterson: Certianly if you take the concept of the CPS and decouple
it from the Service Providers that way and everyone who operates a CPS
is required to flood and share every PASSporT they see with every other
CPS - I don't believe that's salient to this.

Jon Peterson: Time to ship? [No responses]

8) OCSP Usage for Secure Telephone Identity Certificates

Jon Peterson: Freshness for STIR Certs - everyone wants to know that a
cert in STIR is fresh due to the TnAuthList extension (and specifically
TNs and TnRanges). How do you know if a TN is still in the scope of
authority of a certificate?

Jon Peterson: Looked at OCSP and short lived certs. Jack Rickard put
together a summary of the various options (existing by-ref; OCSP with or
without stapling; short-lived with or without stapling).

Jon Peterson: Existing by-ref works but involves very large downloads
that are hard to be cached - can we do better?

Jon Peterson: OCSP is used commonly already (my company already uses
it). This allows a single TN to be requested minimizing data
revelation.But this still reveals info about who's calling where.

Jon Peterson: Alternative is short-lived certificates for a single TN
which can be relied on, but these might not be usefully cacheable and
mechanisms need to include more options.

Jon Peterson: Jack's summary including a new option: stapling the
short-lived certs, putting the certificate in the x5c value. So those
are the options on the menu.

Eric Rescorla: At the highest level, seems like there are two
possibilities - either contain all the information you need in something
with a short life-span or lack it and someone has to go query it. My way
to reason about this is that the long lived certificate has the entire
range of TNs and over time starts to accumulate gaps.

Jon Peterson: Except the by-ref option. But that has the revelation
problem.

Eric Rescorla: Right. Is the conventional practice now with OCSP that
you advertise a range that contains numbers you never owned and then
when people live check they say actually I don't?

Jon Peterson: That practice hasn't been implemented that I'm aware of.
We put regular OCSP without this extension; the way this extension would
work is we added the extension to the OCSP query so that when the query
comes back you get a binary pass/fail.

Eric Rescorla: If you do regular OCSP, why doesn't that have the same
revelation problem as by-ref?

Jon Peterson: If you poll the whole number space, yes, of course. We
don't bake the numbers into the cert at all - the AIA replaces the
TnAuthList that would have been baked into the cert. The only thing you
care about as a verification service is validation of a single number,
we want to reveal as little infomation as possible that provides that,
that's our design goal.

Eric Rescorla: I guess that's what you and I were talking about before
the sessions; there's cryptography that does this this but it's
expensive. So the question is if there's a less expensive version. Maybe
we can chat offline to get a sense of the size of the space. Because I
can imagine some ideas that will work a lot better if the certificates
can only cover relatively small ranges. If there are only 1000 valid
numbers asking the question "is this number allowed" is an easier
question than when there's all possible numbers.

Jon Peterson: It'd be hard to put an upper bound on the number of
numbers that could be in the range that the cert has responsibility for.
That's the challenge.

Eric Rescorla: One possible design you might imagine: certificates cover
blocks of 100. Then it might be possible to get answer to "do you cover
this number" efficiently. But there's no way around the polling problem,
fundamentally.

Jon Peterson: Unless stapling can suffice, where you ship the leaf cert
in a parameter in the PASSporT itself.

Eric Rescorla: If you're willing to poll the CA every time you want to
do that.

Jon Peterson: We could push the entire chain, ultimately. It's just the
PASSporT will be huge then. That's the trade-off.

Chris Wendt: Number ranges don't make sense in this discussion any more.
Should all be single TNs using OCSP or short-lived.

Jon Peterson: That is the part that does our data minimization
responsibility best, if we do that. Unless Ecker comes up with a crypto
thing. We can talk about that offline. We're less concerned about paying
costs on the relying party side than about the dip in the latency.

Jonathan Rosenberg: Back in the Viper days we had a similar problem of
revealing information to the cloud based on what calls were being
received, the solution there was that you'd query for multiple numbers
rather than just the one you'd received.

Jon Peterson: We're less concerned about the revelation of the relaying
party to the CA than the amount that the relaying parties learn about
the assets of the enterprise that owns all the numbers. But yes, we
could use bogus queries, that's something we do with the CPS.

Jonathan Rosenberg: The OCSP problem is that it's open; not everyone in
the world needs to be able to access it, just given providers.

Jon Peterson: I can imagine a scenario - thinking internationally -
where you have a set of trusted entities in one nation state but then
should blind parties who aren't party to this, should they still be able
to be relying parties on this - I don't know.

Jonathan Rosenberg: In practice isn't that true?

Jon Peterson: In practice in North America there's a list of trusted CAs
and effectively there's a list of Verification Services that have some
ties to the PAs in the SHAKEN model that is a closed network, but I've
noticed you can't always predict where a call is going to land based on
the calling party number. It'd be great if wherever it lands, even if
it's not part of your trust network, that could still show up - but
maybe that's a property we should discard, that's a valid comment.

Eric Rescola: Just so I understand the threat model a little more - we
want to avoid impersonation of a number when it's ported from one
provider to another?

Jon: More just need to be able to handle numbers being ported and other
kinds of acquisition, and moving from one place to another, and we can
rely on CAs as a source of truth.

Eric: So how long is the reaction time?

Jon Peterson: About 24 hours is reasonable for number porting.

Chris Wendt: It also has benefits if there's a bad actor you want to
revoke.

Jon Peterson: Some have argued that we should cut down to only support
one thing. I think this is premature. Short-lived and AIA already work
out-the-box. OCSP is already in use so getting that extension to work,
we sort of get that for free. I'm reluctant to rule much of this out for
now. We might end up in a pluraist environment. People might want to do
short-lived certs for their own reasons and be compatible with the fact
that of course OCSP is going to get used.

Jon Peterson: What we proposed in the OCSP stapling draft (not yet
adopted) was a new stapling feature to the PASSporT. This was considered
for other places like in the SIP layer, but kept to PASSporT since this
is very important for Out-Of-Band and messaging use-cases. It could be
extended to short-lived certs, sending the leaf cert or even the whole
chain in the PASSporT. This will massively increase the size of the
PASSporTs. We get comments about MTU etc on the mailing list. But that's
what Jack was proposing.

Jon Peterson: We need more discussion. Any thoughts? Anyone got
implementations of STIR that will barf with this?

???: It's the SIP that will barf with this. There's a lot of UDPs still
out there.

Ben Campbell: I've seen major carriers talk about they have IP
interconnects they still can't do SHAKEN over because they're UDP. But
we already can't do any of this over UDP!

Jon Peterson: SHAKEN should have adopted compact form some time ago.

Ben Campbell: Then you're just shoving information over back into the
SIP header.

Jon Peterson: No, compact form just dispense with everyhing but the SAG.

Ben Campbell: If we've already pushed this into using TCP, then what
difference is a little more?

Jon Peterson: Yeah, for this you'd need a SIP header that would carry
the entire leaf cert, x5c with it.

Chris Wendt: We've been debating this so long. I like either form of
stapling, because it removes the number of round trips - it'd be good to
pick one of the forms, but OK to keep both.

Jon Peterson: My proposal - I'd like to keep three elements: keep the
OCSP baseline that's close to done (some SDOs are using it, so let's get
it published so it's something people can rely on); adopt and advance
the currently expired shortlived draft (hoping to twist Jack's arm into
helping on this) but probably downplaying the ACME dimension since
people are getting short-lived certificates from their service providers
over a different interface; and take the existing stapiling draft for
OCSP and generalize it to a 'freshness' element to PASSporTs that can
apply to OCSP or short-lived.

Jon Peterson: Nothing's actually being dropped, but from a workflow
perspective let's advance OCSP and short-lived. Both are applicable,
we're not in a position to pick a winner, and they're not obviously
competing.

Eric Rescorla: This seems in the finest traditions of the IETF.

Jon Peterson: We provide tools to be used in different profiles and
different environments; we should just make the tools available.

Eric Rescorla: I'm not clear why you'd use OCSP to do stapling. It's not
clear why we have to do both, they're kind of isomorphic.

Jon Peterson: It's because they're isomorphic that it's hard to decide.

Eric Rescorla: Typically you'd imagine short-lived is a better approach
because they're smaller.

Jon Peterson: Those x5c chains could be quite large in delegation, these
could be five or six chains. My intuition is there's no free lunch, we
end up doing the same work.

Jonathan Rosenberg: Is one of these mandatory to implement?

Jon Peterson: My intention is that these are independent specifications
and that compliant implementations will specify which ones they're
compliant with. There'll be no guide which one is mandatory. Maybe in
the future one will be the winner.

Jonathan Rosenberg: Is there an interoperability problem? Or are you
saying ATIS will pick one so in practice there won't be an
interoperability problem? These might have to be stripped at national
boundaries.

Chris Wendt: I think we should pick one. I'm not concerned about long
certificate chains; I think we should go with short-lived with
'stapling'. I'd be OK with both forms of stapling but would prefer just
the short-lived one; it's the simplest.

Jon Peterson: I agree from a security perspective it's the strongest. It
provides the data minimization we want. As an assurance it feels
stronger to me than OCSP, but operationalizing that system where on a
per-call basis you're synthesizing a certificate for a single TN and
providing its chain and getting it into a certificate in time, and the
validation then runs which is complex, with multiple paths that could be
built - there's no free lunch. Every way I look at this, I get worried
about complexity in the architecture.

Chris Wendt: These are all pre-call things. You could gather that
information pre-call.

Jon Peterson: You could gather all the information for every number you
could possibly sign for, but then the question becomes how short-lived
are those? How often do you have to do that process? Generate 500,000
certs every 5 minutes? Don't underestimate the complexity this could be.

Chris Wendt: But you're gathering all those things asynchronously.
You're not doing that all at the call.

Jon Peterson: I'd probably do it at the call if I was building this. If
I was doing it for 100 numbers I might do it on the API call to my AS,
but if I have to do it for a large enterprise for tens of millions and I
have to keep a keyring... Not saying it's impossible.

Eric Rescorla: As you say, either you have the certificates in advance
or do you get them on the fly? Can we make it so you don't have 500,000
signatures? Probably. Can we make it so you don't have to store some
stuff? Probably not. You have to store some data.

Jon Peterson: I'm worried about 500 million more than 500 thousand.

Jon Peterson: I don't have an answer to this other than "let's advance
three docs at roughly this scope." and see if we can do better.

Ben Campbell: As chair, what are the concrete Working Group actions to
do?

Jon Peterson: I'll do a bit of polishing of the OCSP before going for WG
Last Call. Call for adoption on Short-Lived immediately as lots of
people seem to want that. General stapling only occured to me this
morning so let me do at least one rev of that before we talk about
adoption.

[Further agreement that more discussion needed on the list]

9) Any Other Business (if time permits)

No other business.