STIR 122 Minutes

Summary

The chairs would like to thank Robert Sparks for taking notes, and going
above and beyond to summarize discussion from the meeting recording
after the fact.

Certificates

Chris Wendt presented draft-wendt-stir-certificate-transparency-05 on
Certificate Transparence (CT). The group discussed whether CT as defined
in RFC 9162 could be used as-is and whether the I-D should be treated as
a fork or a profile and whether it could be informational. People also
discussed how a verifier can determine if a certicate is actually
logged. The sense of the room was that the intent is to use CT with no
protocol change but be clear about how the relying parties look at the
result. The document will be restructured to reflect that. Any adoption
call will be made on a restructured document.

Chris briefed the room on
draft-wendt-acme-authority-token-jwtclaimcon-00, to be "officially"
presented in ACME.

VESPER

Chris presented VESPER Use Cases (draft-wendt-stir-vesper-use-cases-00).
People discussed the differences in conveying display names and other
caller details in STIR verses in the WebPKI, and the potential for
verification by accountable verication authorities. The authority might
be different for different display elements, for example calling numbers
vs display names. The chairs asked people to focus the conversation on
what we need to figure out in order to decide whether to adopt a
document on this problem. Discussion concluded that interested parties
should talk more and refine the use-cases and trust model and bring that
back for further discussion.

Caller ID Verification (CIV)

Feng Hao presented draft-hao-civ-00. This was originally submitted to
DISPATCH, but redirected to STIR because of the domain expertise of the
group. The chairs suggested that people think about the DISPATCH
question. Several people raised objections to the premise that STIR does
not do real-time caller authentication and that the STIR/SHAKEN
difficiencies described in the draft might apply to SHAKEN, but not
necessarily for STIR in other contexts. Time ran out with no resulting
action items.

AoB

Orie Steele (as AD) announced that Robert Sparks would step down as
chair, and thanked Robert for his service. Russ and Ben will continue as
co-chairs.

Detailed Notes

Chair overview

• draft-ietf-stir-passport-rcd is in the RFC Editor queue awaiting
  draft-ietf-sipcore-callinfo-rcd as a MISSREF
• draft-ietf-stir-servprovider-oob and draft-ietf-stir-rfc4916-update
  are scheduled for the May 8 IESG telechat

• draft-ietf-stir-certificates-ocsp is in Revised-ID needed

  • Jon and Orie discussed ocsp before the session - Jon will adjust
    a few minor things this week to reflect the conversation.

• draft-ietf-stir-certificates-shortlived is in WGLC

  • Agenda bash removed this doc from today’s agenda for lack of
    anything to discuss.
  • Chris Wendt notes that shortlived is being referenced from ATIS
    documents.

Certificates

draft-wendt-stir-certificate-transparency-05

STI Certificate Transparency
Chris Wendt leading the discussion

• Eric Rescorla - why can't you just use CT?

  • Discussion around whether this is a different protocol (a fork)
    or is intended to be a profile.
    • Discussion of logs, mis-issuance, and persona.
    • Jon Peterson - Expects that we would use CT, and that this
      would be a foundational technology that could be built on to
      do more in the future.
    • Eric - Any PDU that appears in this document for any purpose
      other than providing informational clarity a problem.
      Copying things from the CT spec is a problem.

• Eric - how do you expect relying parties to verify that the
  certificate was actally put into the log as opposed to the SCT was
  issued? This has been a huge problem in the web PKI.

  • Chris - the verification service would rely on auditing.
  • Eric - doesn't work - the immutability claim relies on the
    verification service actually verifying that the certification
    is in the log. See
    https://educatedguesswork.org/posts/transparency-part-2/
  • Jon - the extent that we proscribe the conditions under which
    the entries in the ledger are valid invalid might not be the
    IETF’s job. Example: interpreting two delegate certificates in
    the ledger covering the same number may require different
    policies in different environments.
  • Alec Fenichel - Less of a problem for the verifying service to
    verify the logs than in the web world as the volume of
    information the verification service needs to look at is orders
    of magnitude smaller than in the web world. It would be
    realistic to have a large number of verification services also
    be monitors.
  • Eric - the issue to consider isn’t scale, it’s privacy.
  • Alec - don’t think there’s a privacy concern in shaken with
    verifying certificates with service provider codes in them. If
    the certificates actually had phone numbers in them it would be
    more of a problem.

• Ben Campbell - if this document is recast as only a profile of CTI
  does it really need to progress in the IETF?

  • Chris argued that there is value in working on this in the IETF.

• Jon - can this document be Informational?

  • Room had general agreement that it could.

• Alec - agree that this should not be a fork of CT, but wouldn’t call
  it the exact same thing as CT in the web world as it’s a bit of a
  subset in the sense that there’s a slight difference in the parties.
  The CT spec is written in the lens of TLS, specifically TLS clients
  and handshakes vs relying parties.

• Eric - I’m not flustered about the parts of the CT spec you don’t
  use, and I think this document can briefly say things like
  “everywhere the CT spec says TLS clients this document means
  verifier” and the ADs can work out PS vs Informational.

Summary of result:

• The sense in the room was that the intent is to use CT with no
  protocol change but be clear about how the relying parties would be
  looking at the result. The document would be restructured to reflect
  that. Any adoption call would be made on a restructured document.

draft-wendt-acme-authority-token-jwtclaimcon-00

Brief STIR regarding draft to be presented in ACME
Chris Wendt

• +1s on continuing discussion and encouraging acme to adopt this work
  from several people in the room

VESPER - VErifiable STI Personas

draft-wendt-stir-vesper-use-cases-00

VESPER Use Cases
Chris Wendt

• Eric - What exactly would appear in the PDU? (Home Depot was used as
  an example for discussion). The web pki largely abandoned a similar
  idea of putting a name string in the cert for display to the end
  user because it is trivially easy to get an official name that
  sufficiently, even exactly, matching any given string by registering
  it another jurisdiction.
• Chris - I recognize the issue, and the industry is working on
  addressing this kind of confusion in other fora.
• Jon - This is very complicated - see CNAM, branded calling,
  call-reasons, etc. But what makes this different from the web PKI
  and EV is the set of Know-Your-Customer vetters that are
  accountable for vouching for the assertion. But looking at PKI
  through the lens of whether it has all the slots we need would be
  useful. Is there actually any new tooling that needs to be specified
  to carry the information we need to cary, or should this effort be
  recast in how to use the tools we already have? Why do we need a new
  token rather than using existing fields in the certificate?
• Eric - consider the trust model. Is the entity who validates I’m
  entitled to use this number the same entity who validates the name
  (dicussion: it can be but doesn’t have to be, but that won’t be part
  of what the IETF stipulates). If these are different entities, we
  have to figure out how to hoist the validation decision on the mark
  into the credential signing the phone number binding.
• Jon - We have tools that address different models of how to hoist
  that validation. We don’t have a protocol mechanism that’s missing -
  just specification of policy.
• Russ Housley - can we focus the conversation on what we need to
  figure out in order to decide whether to adopt a document on this
  problem?

Summary of result:

• Jon, Chris and Eric should discuss more and refine the
  use-cases/trust model and bring that back for further discussion

Caller ID Verification (CIV)

draft-hao-civ-00
Feng Hao

• Ben - the group should be thinking as if this discussion were a
  DISPATCH like decision.
• Jon - This should be discussed in ATIS/SHAKEN. STIR solves this
  problem already, and the strawman issues with shaken aren’t
  accurate.
• Robert Sparks - Real time verification was part of the requirements
  when we started this work and STIR provides that capability.
• Jon - (describes how STIR can do real-time authentication)

• Eric - In what ways is the problem you’re describing different/worse
  than the web PKI’s ability to provide real-time verification of
  domain names?

  • Fen Hao's response was interrupted by the need for final
    comments as the meeting was running out of time.

• Alec - these claims misrepresent how SHAKEN works.

• Chris - ATIS does have specs that deal with delegate certificates
  for rich call data.

Summary: Time ran out - no action items resulted.

AOB

• Orie Steele (as AD): Thanks Robert as the outgoing STIR chair.