Minutes for STIR at IETF-94
minutes-94-stir-2

Minutes: Secure Telephone Identity Revisited (STIR) - IETF94

Summary:

The attendees approved of the design team's suggestion to shift the
syntax for carrying the signature to use JWT as captured in
draft-ietf-stir-rfc4474bis-06.  Discussion converged on not explicitly
signaling whether where the number was taken from (PAI or elsewhere)
and on including Date in the signature. The attendees supported having
multiple signatures, but expressed concern that each signature have
enough information attached to be semantically distinct (spec).
Extensibility, and policies around standardizing extensions will
continue to be discussed on the list. The next steps will be to revise
rfc4474bis, splitting the the token description out into a separate
draft. We expect these drafts by the end of November, and we expect to
be able to WGLC these drafts.

The group discussed the requirements for the credentials, and began
working towards some technical decisions. We expect a design team to
form and report recommendations (likely mid-December) after the revised
rfc4474bis and new token draft are available.

The full notes are below:
==============================================================================

STIR: IETF 94: Monday 1300-1500

---------------------------------------------------------
10m Administrivia

Presenters: Chairs
Presentation: https://www.ietf.org/proceedings/94/slides/slides-94-stir-0.pdf

Jabber scribe: Daniel Burnett (1st hour), Cullen Jennings
Jabber log: http://www.ietf.org/jabber/logs/stir/2015-11-02.html
Note takers: Jean Mahoney, Steve Donovan

Note well and agenda were presented. No changes to the agenda.

---------------------------------------------------------
20m Report from design team discussions

Presenter: Sean Turner
Presentation: https://www.ietf.org/proceedings/94/slides/slides-94-stir-1.pdf

No comments or questions were raised.

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

Presenter: Jon Peterson
Presentation: https://www.ietf.org/proceedings/94/slides/slides-94-stir-3.pdf

On the question raised on Slide 4 - The Bare Minimum: Is there a need for a
“switch” to signify using PAI? Jon pointed out that currently there is no such
thing, but it has been working since PAI was first introduced.

Chris Wendt agreed in general that it works as-is, and it would be simpler to
keep the logic the same.

Richard Barnes raised a concern about having to verify every PAI in every
combo. Dave Crocker said that the validator wouldn't know which choice was made
by the signer. Jon asked for more eyes on the draft.

Cullen pointed out that the From and PAI carry the same information. He was
also fine with leaving as-is.

Jon raised a concern about the modification by SBCs of the Date header field
and asked if there were any examples of such behavior.

Cullen said that he had seen SBCs accidentally modifying the Date. Since Date
is almost never modified, it makes a useful debugging tool.

Sean Turner said that Date modification seems like a surface for an attack.

Jim McEachern said that call forwarding may modify the Date.

Jon said some behaviors are not compatible with an end-to-end security system,
but if the Date had only been tweaked a little bit there were strategies for
handling it without re-signing.

slide 5: The Bare Minimum

Adam asked for clarifications. Jon said that the JSON header and claims were
optional since they would make the message larger and he wanted to discourage
that.

Jon asked the room is anyone was uncomfortable with JWT.

Robert Sparks, as an individual, had no problem with it.

Sean agreed with it and wanted to move on. Chris reiterated that JWT could be
used for other purposes.

Jon said that, although SBCs are not defined and have broad powers, we want to
get through them and need to decide what will work for deployment environments
that we care about.

Chris said that it would be easy to update SBCs.

slide 6: Multiple Identity Signatures

Russ Housley from floor supported multiple identity signatures, and pointed out
that email went through a transition from one to multiple signatures caused by
the transition from SHA-1 to SHA-256, and that there could be text that could
be reused.

Jon said that "spec" parameter would allow for signing different fields for use
in authorization, but we would not specify how the authorization decision is
made.

Jon talked about a transitive approach to security, where you don't trust the
endpoint but you trust the intermediary.

slide 7: Handling Metadata

Richard Barnes mentioned a specification that could be used instead of separate
grammars. Jon wanted a pointer to that draft.

slide 8: Extensibility

Size of the message was discussed, and Adam wondered what was sensitive to it.
Robert pointed out that the size was still an order of magnitude lower than an
SDP negotiation. Jon said that there were implementations that could not handle
really large headers. Robert said that the issue had not been seen at SIPit for
many years. Chris said that since UDP is used, it's valid to keep the headers
as small as possible, but he didn't know if it was a showstopper.

Jon asked what the appropriate IANA policy would be for this. JWT
extensibility's IANA policy is expert-review with specification. He didn't see
how we could be less constrained than that.

Dave Crocker pointed out that DKIM's signature lists the fields it has hashed.
Jon said that is what the first option offers.

Adam said that JWT supports private use, but it would be nice to have the
information collected somewhere.

Richard pointed out that if you require the verifier to understand the field,
then you get stuck in lockstep upgrades.

Jon clarified that the 1st option covered adding just one or two new fields.
The second option solves a different problem that may not be specified in the
IETF, but the people wanting to solve that problem want to use the baseline
mechanism. Jon didn't think it was ideal, but he would not say no.

Pete Resnick suggested making it a FCFS registry, with an optional
specification, and the IETF will use the specification. Cullen wanted to know
why they did not want FCFS. Jon said that the arguments against it are that the
specs should not be public, and IETF interoperability constraints don't apply.
Cullen said that if those were the arguments, then "spec" should be removed.
Jon said that with "spec", you don't have to include canon and make the message
huge. For JWT, you have to include canon, which is why both have their place.
Alissa Cooper said don't pervert it for people who don't want to do follow
process. They can just do it.

ACTION: Discuss IANA policy on list.

slide 9: We Have the Technology

Jon asked the working group if it was OK with having a separate WG item on the
token that would be Proposed Standard.

Sanjay said that two docs provides more flexibility. Sean and Chris were fine
with it.

slide 10: Next Steps

Jon will revise the draft.

ACTION: Sean, Chris, Richard to review updated draft.
ACTION: find reviewers on list.

slide 11: The job of non-SIP transports

Jon pointed out this was not in charter and it needed more discussion.

Adam wanted to use this in RTCweb in the future.

Jon would be happy to work on it and set up a design team.

slide 12: Not So SIP specific

Jon asked that, if anyone had a problem, to please talk to them.

---------------------------------------------------------
60m draft-ietf-stir-certificates
Presenter: Sean Turner
Presentation: https://www.ietf.org/proceedings/94/slides/slides-94-stir-2.pdf

slide 6: Ultimate Requirement Questions

Jon said that the first question was a policy question. Richard said that the
slide was one question in four forms. Cullen wasn't sure what to make of the
questions, and that if the members of club were decided by the FCC, the IETF
could only provide technology in supporting that club.

Sanjay said that, on the last point, you need to be able to trace the call back.

Russ from floor said that we were specifying a trust store but not what was in
it, that people will populate the store differently.

Richard said that it was not a technical decision. Build a scalable
infrastructure to deal with it.

slide 7: Transitive Trust vs Intransitive Trust

Jon said that it's unclear how great the value is since we already have ways to
determine if the previous hop vouched for the call. The difference is that you
can see past the previous hop.

Chris said that the slide is implying that the call can only go between
carriers, but the call will be going through multiple hops and untrusted
networks.

Jon wondered what you would get with using the PAI, but Chris said no one is
saying that PAI should be trusted no matter what. Jon said that last-hop
security was not much better than relying on PAI.

Jon asked if we should detect abuse in realtime or just in audit.

ACTION: Discuss transitive vs intransitive trust on the mailing list.

slide 8: Public or Confidential Credentials?

Jon said that 2 years ago, there were concerns that the subject would leak
information, but the right way to manage certs is antithetical to those
concerns.

Chris pointed out there is some risk of leaking information no matter what you
do with the credentials.

Sean recommended that implementations be allowed to pick their pain threshold.

slide 9: Certs for OCN

Jon explained that OCNs may help alleviate leakage concerns.

Richard said there were tradeoffs with cert size, and that there were issues
with OCSP latency.

Brian Rosen said that OCN doesn't fix the problem and asked how to get the
assignments to those operators that don't have OCNs.

Chris wanted flexibility.

slide 10: Other Transitive Approaches

Jon and Chris saw some promise here, and Chris said there should be some
semantics here.

slide 11: So what now?

Sean and Jon want a design team call on certs.

Chris wanted to start out simple with carrier certs and then go from there.

ACTION: Sean Turner to set up a design meeting on certs.

Russ said that the syntax and semantics of the signature should be nailed down
so that we know what the requirements for the cert are.

Jon said that the FCC has created a timeline for this, and he wants an LC as
soon as possible.

ACTION: Jon to bring up Date concerns on mailing list to ensure that it is not
a blocker.

Robert recapped major actions:
- Revise 4474bis draft between now and the end of November.
- Adopt the token draft as a stir doc.
- Start the LC process on 4474bis at end of November.
- Hold a design team discussion in mid December on certs.