Minutes IETF122: secdispatch: Mon 02:30
minutes-122-secdispatch-202503170230-00

SECDISPATCH/DISPATCH Hybrid Meeting @IETF122

Monday 17 March 2025
Room: Sala Thai Ballroom
09:30-11:30 Local

Log into the IETF datatracker to access:

• MeetEcho
• Notes
• Zulip

9:30 Status and Agenda Bash - Chairs and ADs (10 min)

• one remote user had issues hearing, seemed to be a local issue.
• note well and note really well presented

Recommendations for Key Directories over HTTP

Presenter: Thibault Meunier (Remote)
draft-darling-key-directory-over-http

Scott Fluhrer:

• If you're going to pass public keys over HTTP you have to worry
  about integrity and making sure the public key is tied to the use
  it's permitted for.
• If you're going to move this to a WG, it needs to be one which knows
  about security.

Mike Jones:

• Author of some of the documents cited
• Putting JWK sets at specific well-known URLs or indirected places
  (like OAuth and openid connect does) is working well in practice.
• Would want to be convinced that you're solving a problem that's
  necessary to solve given that existing practice has worked for many
  years.

A: JWK works well. Not all systems work well, key rotation and caching
not defined well. Key rotation could use more eyes.

Mike: we're discussing on list already. Propose dispatch to JOSE, but
ambivilent if needs to be done.

Tommy Pauly: (Apple)

• Thank you for bringing it up. Topic is interesting, think it's worth
  thinking about the problem space.
• Not sure what is the "this" we are dispatching. What is the
  particular idea?
• JOSE part should go to JOSE. Privacy pass has its own formats. Is
  there something at a higher level?
• With IAB hat on, is this just a pattern we see?
• Also practical things like key rotation strategies, which are
  mentioned in your draft as future work - consistency, transparency.
• Maybe stays in privacypass or ohai, or maybe gets something new?
  Would like to clarity on "which part is the main part?"

A: main part, recommendations on existing or new protocol, "SHOULD
CONSIDER".

Rohan Mahy:

• For COSE keysets, this would be quite useful. Fine with that being
  in JOSE. Ways to do this with JWK but not for COSE keysets.

Joseph Salowey:

• Have interest in looking at doing different things with JWK. From a
  privacypass perspective, have key consistency as part of our work
  which isn't fleshed out yet.
• Going back to Tommy's question - how this fits together is somethig
  to flesh out a bit more.

Martin Thomson:

• Looking at this draft, it's clear there are a lot of patterns going
  on which, are emerging in multiple groups - with commonality across
  groups.
• Can see desire to have a grand unifying scheme.
• The ways this draft is approaching it is more restrictive than the
  groups need.
• Would encourage you to take this to individual groups rather than
  trying to develop this in one place.
• There's a suite of things where consistency in design would be
  useful rather than a grand unifying scheme.
• E.g. the key generation here is totally unsuitable for some
  protocols. Maybe this is not one thing.

Pete Resnick:

• Question is more for Tommy - is this something the IAB would take
  on?

Tommy:

• Doing a survey in the broad - this works, this doesn't - is a thing
  that IAB has done before.
• We can start a little program to work on something, if we think it's
  useful as advice to future protocol developers in the IETF.

A: as for where to dispatch, don't have a good answer.

Stephen Farrell wanted to say:

• JOSE/COSE and directories of keys does not seem like a good match
  (and other things from chat)

DISPATCH OUTCOME:

• Deb (security AD) - not ready yet. Either multiple WGs with own
  pieces, or somewhere else, but not fully baked yet.
• Murray (art AD) - you said "prefer existing WG" (which do you think)
  • originally though HTTPAPI working group, but seemed broader.
• Francesca (wit AD) - needs more work, would be helpful for
  proponents to know where to discuss more. Could set up a mailing
  list, or is there an existing place?

Jim: would people join a mailing list? A few hands at the back.

Murray: suggests - SAAG (security area).

Mike Jones: just discuss it on secdispatch, already consensus it's a
security thing.

Jim: designate secdispatch as the place, build a list if it outgrows
that.

Organization Trust Relationship Protocol

Presenter: Ralph W. Brown (Remote)
draft-org-trust-relationship-protocol

(there was much heckling in the chat)

Mark Nottingham:

• .well-known: question whether it gives you the benefit you think it
  does.
• Similar to work happening in the W3C, and they're doing a lot of
  thinking about this.
• Have a real problem with this being AD sponsored.
• New speculative thing which is quite complex.

Richard Barnes:

• Not tight like security.txt; would be super worried about this.
  Having tighter scope would help.
• This document is kind of sprawling.

Martin Thompson:

• It's not clear to me exactly what the goal of this work is. Who is
  going to consume this implementation and how.
• Talking about specifics and mechanics without the security model is
  missing the most important questions. What do I gain by consuming
  this information?
• (via chat) This particular design approach is not something I'm a
  fan of. Rather than use a well-defined format, we do a new bespoke
  text format. That ads.txt and robots.txt did it are not reasons to
  repeat their mistakes.

Eric Rescorla:

• Many points I would make have been made by other people and in my
  extensive email!
• If browsers would use it, would want to hear from Browsers.
• Could see this being done at IETF rather than W3C, but would want to
  see indication of support.
• Think AD sponsored would be inappropriate, not something with wide
  deployment.
• Suggested a new mailing list

Thom Wiggers:

• Aside from question of venue, want to echo what Martin said. What do
  you expect to get here?
• Draft specifies that there are no security implications, but think
  that's no true. How do you prevent phishing, fake associations, etc.

A: have talked at w3c, had conversations about trust.txt with them
there. Organisation wasn't well structured, wasn't clear what their
objectives are.

Not an attractive target - if you can compromise a site, may as well
compromise the whole thing not just its trust.txt.

Have considered "signed trust.txt files" as a level of assurance.

Verdict:

• have some discussion offline about whether there's enough interest
  to create a mailing list.

LDAP Additional Syntaxes

Presenter: Carl Eric Codère (remote)
draft-codere-ldapsyntax

Russ Housley:

• RFC5280 uses the old ASN1 syntax for certificates.
• New RFC uses newer syntax but same bits on the wire.
• Lots of reasons to move to new (with open source tooling available)

Rich Salz:

• Seems reasonable. Everyone wants to do datatype-based schemes. Could
  be in ART or WIT.
• Suggest contact ART and WIT ADs to find a place to go.

Comments from ADs?

• Orie (art AD) - would love to hear from others in the ART AREA - is
  there broad support for a dedicated WG?
• If you're active in ART, please go to the mike. (Nobody did)

Jim: coordinate via ART ADs and Dispatch list to discuss.

SUMMARY:

• Key Directories over HTTP => discuss on secdispatch
• Trust Relationship Protocol => discuss on art
• LDAP Additional Syntaxes => discuss on art