SSHM IETF 122

2025-03-21 0600-0730 UTC (Boromphimarn 1/2)

Chairs:

• Stephen Farrell
• Job Snijders

Responsible AD:

• Deb Cooley

Notetaker(s):

• Daniel Kahn Gillmor; Rich Salz (some help)

Administrivia (chairs)

• Note well, and please be kinder to each other and don't react when
  someone, incorrectly, imputes other people's motives.

Document Status (chairs)

• NTRUPrime, WGLC phase ended (main focus on IANA registry reference,
  and document status)

  • Chairs concluded IANA registry entry should be marked as SHOULD.
  • Eric Rescorla (ekr) raised an appeal about no clear consensus on
    the IANA entry
  • IANA marking question brought back to the WG as an e-mail poll
  • Chairs interpreted poll responses as a rough consensus for
    SHOULD
  • Job is tackling Shepherd writeup
  • Tero: i sent comments during WGLC and they haven't been
    incorporated or acknowledged (even to be explicitly rejected),
    in the flood of all the comments.
  • Job: my shepherd review will comb the rest of the messages, and
    ensure they are at least considered, especially editorial
    cleanup. Another revision for the draft is pending. If Tero (or
    anyone else in the same position) is concerned, please hold off
    on followup until the new revision is posted.
  • John Mattsson, could we have a GitHub track for tech issues? And
    which track is it on?
  • Job: NTRU prime will be an informational document; choice of
    tracker, revision control, solely mailing list, etc, will be
    left up to the document author.

• up next: WGLC on chacha20-poly1305, ssh-agent, or ml-kem-hybrid-kex
  ?

  • WG needs to provide feedback and authors need to say when
    they're ready to take next step (from adopted draft to WGLC)
  • PaulW: Does chacha/poly draft depend on strict-kex? Ans: yes
  • Scott Fluhrer: charter seems broader than just documenting
    what's done in practice. So novel primitives like ML-KEM are in
    scope. Agreed? (Stephen and Job: agreed)
  • Job: if the ML-KEM author thinks there are two implementations
    that can interoperate, they can let the chairs know that we're
    ready for WGLC.
  • ekr: Not much is at stake in the priority discussion. The WG
    will figure it out via standard process.

Terrapin attack and Strict KEX (Damien Miller)

• See slides.

• Paul Wouters: what if client and server don't agree on strict KEX
  protection?

  • Damien: then you don't get the protections

• Paul: should the client or server reject the connection if it
  doesn't have these protections? do we have guidance in the spec?

  • Damien: only option is to kill the connection; i don't think the
    potential damage is worth dropping the connection. I'll take
    feedback.

• Guilin WANG: do we need an academic expert to review the fix? do we
  need formal analysis?

  • Damien: I welcome cryptographic review of any of this. it's
    2025, we should be analyzing our protocols.
  • Job: For strict-kex, the fix was developed with the academics
    who found it

• Dierdre: yes, if we look at a full transcript hash in the future
  would be performant, and use a real KDF as well.

• John Preuẞ Mattsson: this is a good thing to use, but we can't find
  it everywhere (there are legacy devices that can't deploy it?).
  Ericsson took the option instead of just disabling chacha20-poly1305

• Tero: if we move to full KDF hash of transcript, can't we use the
  same hack of a pseudo-KEX message? That'd give you this, plus
  backward compatibility. No need for a new SSH revision.

  • Damien: i'd be happy to fix that. The stuff in strict-KEX is
    what should happen anyway. I expect a full transcript KEX/KDF
    draft will take months if not years to vet with the WG and the
    academic community's review, so we should document the current
    workaround.
  • Theo De Raadt: agree with Damien; such an update will take a
    long time to roll out, and so we need to have this documented.
  • David Schinazi: agree with Theo and Damien. We can do both, and
    on different timelines.
  • Deb Cooley: taking on full session transcript hash+KDF would
    require a recharter. i don't want to recharter right away. let's
    get the community all rowing in the same direction.
  • Job (no hats): you can add a section "future work" in the
    strict-kex draft identifying what needs to be done.
  • Damien: i think it's in the Security Considerations already.

• Job: John, if Ericsson disables chacha20-poly1305, does this draft
  address your willingness to re-enable chacha20?

  • John: if this draft lets us negotiate it, then we would. but it
    won't.
  • Damien: agreed with John. if you end up with chacha20-poly1305
    but the peer doesn't offer strict-kex, then your only option is
    to bail. The limit is the deployments that you care about.

• Stephen: do you want to offer this for WG adoption?

  • Damien: oh, do i need to? yes, i ask for adoption
    Chairs to do a call for adoption.

OpenSSH certificate format (Damien Miller)

• See slides

• Hannes: slide 11: type is just key usage -- there are only two key
  usages defined? (Answer: yes) first line is the certificate format
  identifier.

  • Damien: most implementations just ignore certs with formats that
    they don't understand.

• How is string list (e.g. extensiosn) constructed?

  • It's an "ssh string" which contains 0+ pairs of key/value sets

• DKG: Is behavior common across implenmentatins? What's in them?

  • Damien: critical_options are the place for critical extensions.
    "extensions" are by definition non-critical
  • critical, we have fido flags
  • non-critical, we have things like permitting pty, forwarding,
    etc.
  • DKG: We'll probably need a registry to track them
  • Damien: yup, it's in the draft

• Hannes: key_id: is it just human-readable?

  • Damien: yes, it's an arbitrary string, humans should be able to
    read it. there's also a revocation list mechanism that you could
    revoke by serial_number; revocation list includes just CA
    pubkey and list of serial numbers.

• Deb: what about signature algorithms? always ed25519?

  • Damien: this is an example of an instance of a cert; you can
    specify any kind of key in the pk field; it has a subfield that
    indicates the algorithm.

• Scott: signature is the full key of the CA? i recommend using a hash
  of the pubkey. ML-DSA will make each cert very tiny.

  • Damien: fair point

• Job: string stuff what? Please include some examples. test vectors
  are helpful. Adding a version is useful/confusing based on rPKI
  experience

  • Damien: yes to examples. The name is the "version field" I aimed
    for simplicity being simplistic here.

AOB (as time permits)

Adjourn 80 seconds early