Subject: [stir] Draft minutes: STIR@IETF94

From: Robert Sparks <[email-masked]>
Date: Tue, 10 Nov 2015 13:40:14 -0600

Many thanks to Jean and Steve for thorough notes.
The minutes below are also available here:
http://datatracker.ietf.org/doc/minutes-94-stir/

Please send any additions/corrections to the list or the chairs as soon 
as you can.

-------------

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.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 10 Nov 2015 15:01:27 -0500

On 11/10/15 2:40 PM, Robert Sparks wrote:

> Summary:
>
> TThe attendees supported having

Isn't it sufficient that a recipient might trust one of the signers and 
not another?

	Thanks,
	Paul