STIR Working Group at IETF 114

Actions:

• draft-ietf-stir-passport-rcd will be submitted to the IESG for
  publication.
• Jon will add "AS may not include msgi in nonmsg passport and VSes
  must ignore msgi in nonmsg passports" to -05 of
  draft-ietf-stir-messaging, which will then be submitted to the IESG
  for publication.
• Chris will update draft-ietf-stir-identity-header-errors-handling
  based on the discussion (and subsequent list discussion). WGLC
  continues.
• The list will be polled on whether stapling should be included now
  in draft-ietf-stir-certificates-ocsp - the room felt it was not
  needed. If the list agrees, -02 will go to WGLC.

Administrivia

• Agenda Bashing
• Minute Taker - Jean Mahoney
• Jabber Scribe - Jonathan Lennox
• Bluesheets

WG document status presented.
No changes to agenda.

PASSporT Extension for Rich Call Data

• Chris Wendt and Jon Peterson
• draft-ietf-stir-passport-rcd-19
• Have all WG Last Call issues been resolved?

Chris presented.

Changes: normative text changed based on Ben's feedback.

Ben - my comment was on the normativity - making requirements on the
ecosystem. I'm ok with SHOULD. I don't want to push another revision
unless other changes occur.

Chris - want people to think of appropriate policies. Okay either way.

Jon - we won't bless these policies in the IETF. An IETF spec shouldn't
specify. The wording is tortuous here. Don't want to require that the
ecosystem to comply.

Lennox - (something about meeting the requirements trivially). There is
something wrong grammatically with the statement.

Jon - need an Englishing pass on this.

Russ - we're in WGLC. Do you want to send -19 or -20 to the AD?

Jon - okay with sending -19 to the AD.

richard - agree. Send as soon as possible. There's a queue of
implementers waiting for this.

Russ - we'll leave the grammatical error in.

Ben - the clearer it is, the quicker it will get through the review.

Russ - we'll send today. Will the authors send me an IPR statement?

STIR for Messaging

• Chris Wendt and Jon Peterson
• draft-ietf-stir-messaging-03 (-04 published just before)
• Have all WG Last Call issues been resolved?

Jon presented.

Ben (from queue) - I did not propose polymorphism. Glad we don't have
it. Don't make it hard to specify another use for this.

Jon - updates RFC-this - low cost.

RjS - letting other passport types pick this up. This nice short name -
will it be future proof? What do you mean "msg"?

Jon - We have generic definition of msg. Can be taken pretty broadly.
msg isn't email. I think it's okay. It could be a mime thing?

RjS - willing to leave it alone, just wanted to kick it around.
Confusion at the implementer's layer.

Jon - no worse than rcd and rcdi.

Jack - don't care from a message PoV. Odd side effects that I'm worried
about. A question of enforcement on the verifier side. One that enforces
will look very different than one that doesn't.
If a future or weird AS creates a passport with a msgi on it. A verifier
that doesn't implemnt the spec will carry on just fine - will ignore. A
verifier that does implement it, can drop it.

Jon - AS may not include msgi in nonmsg passport and VSes must ignore
msgi in nonmsg passports. I can add that.

Subir - ... do we need to do anything for those ppts?

Jon - concerned about a security weakness if we don't clamp this down.
non msg passport types.

Chris - I like where we landed.

Jon -

Ben - I would like to keep it. Other message types might use oob. Might
be worth to have disclaimer language - it's not solved in the draft.

Jon - 8816 - whatever comm system you're using, don't need any

Lennox - a crypto hash over message. Needs to be unambiguous, eg Unicode
denormalisation.

Jon - turn this into mime and it needs to be unambiguous before signing.

Jon - any other changes before shipping?

Ben - this version? I'll be doc shepherd.

Jon - 04.

Ben - you agreed to make changes

Jon - Can we add that insertion after LC? Fine, I'll just make the
change now.

Identity Header Error Handling

• Chris Wendt
• draft-ietf-stir-identity-header-errors-handling-02
• WG Last Call is underway; discuss any open issues

Chris presented.

Jon - There's no supported for Reason, is there?

RjS - it's a constant churn. Implied signaling of support. It's not
helpful and agreed that we wouldn't do implied signaling.

Lennox - Would anything go wrong if you inserted it?

Chris - if you don't understand stir Reason headers, you ignore it.

Richard Shockey - 607, 608, 603 reason codes. Ample precedent for reason
codes.

Chris - slightly different topic. Including the Reason header field and
negotiating support.

Chris - Should we wait for draft-ietf-sipcore-multiple-reasons before
sending error-handling to WGLC?

RjS - don't think so, let the process move forward this document. I'll
get a new version of the draft out soon, but don't need to wait.

Shockey - reason codes may or may not have privacy implications.

Chris - we include the full passport, we recommend compact form. I think
we're okay.

Chris - use case for multiple errors. There can only be one cause code.
Is there a case for multiple cause codes? Do we want to restrict?

Jon - SIP cause codes indicate repairable conditions. There could be
lots of things wrong in the SIP message. We decided that there would be
a single expression of what is wrong. There can be cascading issues at
other elements. Fine with having that constraint. Do single.

Chris - only remove ppi and only for full form?

Jon - makes sense

Jack - what's the benefit?

Jon - you leak info in full form, but not compact form.

Chris - would it be useful for the AS to know there was an error
upstream. Do we need to describe what happened?

Roman - remove it completely. If a feature is implemented, ... makes it
contained to the device implementing stir.

Chris - if you get a Reason header without the ppi?

Jon - one prior AS removes it, it makes sense that the AS removes it...

Chris - stir-specific cause codes.

Jon - is 603 stir specific?

Shockey - how extensive to want extensibility?

Chris - going forward, want to support new stir cause codes.

Lennox - does the future spec says, hey I'm stir-specific. I'm in this
category.

Chris - yes.

Chris - Bullet 3 - explicit about only 1 cause code. Bullet 4 - no
change.

Jon - we'll need to name some other status codes that are applicable.

Chris - these are reason headers intended for consumption by the AS

Jon - only thing that would help if the AS fixed it.

Chris - I can make these changes and discuss on list.

OCSP Usage for Secure Telephone Identity Certificates

• Jon Peterson and Sean Turner
• draft-ietf-stir-certificates-ocsp-02
• Early days; needs review and discussion

Jon presented.

Jon - what do people think of punting on stapling?

Jack - what's the point of this without stapling? They're cacheable -
speeds verification.

Jon - instead of a massive list of TNs, just use OSCP, a single query -
is number in scope. I was happy to do TN by ref. If the list is simple,
and don't care if someone learns of your list. Attis pushed back.

Jack - There was a discussion - we wanted something like OSCP or
short-lived certs. We know how to do short-lived certs.

Jon - short-lived certs - ACME which is a heavier list.

Jack - without stapling, I'd be surprised if anyone used it.

Chris - is it about roundtrips.

Jack - roundtrips, cacheability.

Jon - which side pays the cost.

Chris - TN by ref -- inserting and removing TNs, is like revoking the TN
being covered by the cert?

Jon - hmmhmm. OCSP has a further issue do you do it stapled or not? We
know how to do it without stapling. What's it look like with stapling?
Who does it? AS vs VS side?

Chris - short-term cert is mutually exclusive?

Jon - not saying don't do short-term certs. It means doing ACME and
people don't want to do ACME.

Russ - OCSP includes a next-update field. You can cache between uses if
you are verifying the same cert.

Jon - there is no RTT gain on stapling vs not.

Subir -

Jon - the short-lived cert is.... short-lived certs done offline, once a
day. Paid in cacheability. The VS has to dereference. It's less for call
processing. Cost is ACME*.

Subir - how often are numbers are revoked? SOmething to consider.

Jon - any given number can be revoked at any time. Sometimes where's
it's static. Sometimes very dynamic.

Subir - if this in place, do we need short-lived certs?

Jon - I'm not saying abandon that path. It's easier to do. We need
something to cover delegation cases.

Lennox - how quickly does it change. How quickly do you need to say it's
dead. If you're terminating, doesn't the CA know all the numbers calling
the VS. That's a privacy consideration.

Jon - it is leaking information. Stapling mitigates that. Changing the
AS side, what if some AS implement it and some don't vs incomplete
implementation by VSes. OCSP on the VS side is the easiest thing to
implement.

Russ - raise of hands: Is it worth doing OCSP without stapling?

Jon - Initially. Not saying we're not going to do stapling.

Russ - 8 people is fine. 2 think it's not.

Jon - please speak?

No one spoke up.

Jon - We will get to the stapling part. If we're agreed, then we're
pretty close to shipping.

Russ - we'll give people time to look at it. If we don't hear anything,
we'll WGLC.

Any Other Business (if time permits)

Jack - In the cert rfc, the tnauthlist is only noncritical. If you
ignore it, you don't understand the extension.

Russ - we assumed that anything in the system would understand it.

Jon - these are specialized CAs.

Russ - are you asking to open the RFC?

Lennox - hold for doc update, it will happen eventually.

Jon - need energy behind connected id. We need it, but it's clunky, hard
to solve. Don't know if people will do it. Do we need to figure out
something weirder that people will actually implement.

Chris - the whole messaging space is a different interaction model. The
relationship is setup pre. Nonmedia invites establish the relationship.

Jon - medialess dialogs updating to media dialogs, which was our best
story. Whatever we do, it will go to sipcore. Prack path... Do you want
to do it in the early media phase. It's clunky. Don't have to solve
herfp to solve this. If you get a 200 ok, but what's in it is passport
but there's something's wrong, ... you get pracks and you need to go
into a sip drawing board.

Ben - this is turning into offline discussion. Anytime herfp is
mentioned, beer is required.