SSHM WG @ IETF-121

Chairs

• Job Snijders
• Stephen Farrell

Agenda

• Chairs - Working Group Modus Operandi
• Damien Miller - SSH Agent Protocol
• Theo de Raadt - Deprecating ciphers
• Any Other Business?

No presentations this time:

• ntruprime
• PQ-KE

Administrivia and Modus Operandi

Slides:
https://datatracker.ietf.org/doc/slides-121-sshm-sshm-chair-slides/

• Job presented proposed modus operandi as part of chair slides
• asked room if ok, some positive reaction, no objection (so far:-)
• Bob: does a private fork count as an imlplementation?
• Job: yes, but... up to the WG/chairs/IESG if it's sufficient

• Damien:

  • broadly agree with chair modus operandi suggestion
  • wrt Bob's question, oqs-openssh may be an example

• Rich:

  • try make it easy for commenters and e.g. include a pointer for
    feedback in I-D
  • discourage direct email to authors, get stuff to the list

• Deb:

  • it's possible to make a github org if desired

draft-miller-ssh-agent

Slides:
https://datatracker.ietf.org/doc/slides-121-sshm-ssh-agent-protocol/

• been around 20 years, we're documenting existing stuff
• Who's read it: 2 people
• Stephen: do we want to encourage extensions in this I-D or...?
• Damien: depends, something useful & implemented, let's have the
  conversation
• Damien: should this be informational or? We should ask WG

• Tero:

  • go for PS
  • he'd like an extension to limit the keys here if possible
    ("agent-restrict")

• Damien: would like to see that standardised but would like to see
  someone else implement it first

• Stephen: Tero would you ask on the list if it'd make sense to add
  that?
• Tero: will do

• Mitchell:

  • Implementer from HPN-SSH
  • we may have a 2nd impmentation of this ("soft-fork" of openssh)
  • will read, excited about h/w key support
  • complicated question about 3-host setup and if private key can
    leave agent

• Damien: No, agents don't expose private key itself but it can be
  used

• Mitchell: interested in ways to reduce trust in intermediaries
• Tero: wrt >1 implementation, there's the IETF meaning (independent
  implementers from spec), 2nd one considers widely depployed e.g. in
  different forks
• Stephen: next steps?
• Damien: got a few comments to be included, ask list about RFC
  status, not much else controversial mostly static so could be quick

Deprecating Ciphers

Various prople chatting and maybe good if the WG start chatting about
removing older ciphers. Plans is implementers get together to see what's
already been removed, then document that set as things to
uncontroversially remove. 3DES is on that list.

If anyone wants to be involved in that discussion, contact Theo.

Also need to discuss, how to remove - servers and clients may differ in
this. Some people still want SSH client to use to login to 20 year old
device. So we may end up with lists that differ from IANA's e.g.
something between permit and refuse.

Quendi site mentioned earlier won't work for this, it's good for new
things/ciphers but doesn't get updated so well when things are removed.

Tero:
- IPsec-me has done this kind of thing, maybe can copy that approach?
- He recommends not removing from code, but disabling so can be turned
on via config, or you may force fallback to telnet.
Theo: will take look but let's do it incrementall
Damien:
- like this as it makes things simpler
- removal can help upstream crypto libraries do the same
- recognises pain caused by old devices using old crypto but some pain
justified by removal of footguns, esp on server side
Rich:
- makes sense, good to do it in steps
- good to have different criteria for clients/servers
- would like to help
Tobias:
- wants to disagree a bit about keeping more old stuff in clients
Theo:
- debian have client versions with old features, but those end up with
code-rot and don't pick up non-cipher bug-fixes, not clear that overall
works
Mitchell:
- support deprecating old stuff, but has embedded old expensive n/w
gear that only supports deprecated ciphers, he can handle that but maybe
not everyone can, so not entirely sold on the idea of full removal
- it is ok to break automation and scripts, maybe see if primary
implementations would distribute e.g. ssh-legacy binaries, but is it
feasible?
- does keeping old ciphers add maintenance burder for ciphers
Bob:
- yes it is
Damien:
- the old server case and the better-than-nothing argument: if the
server hasn't been updated in 20 years, they probably have non-crypto
bugs galore so maybe it's not safe in many ways
Tobias:
- agrees with Damien's comment above
Mitchell:
- old gear he mentioned isn't on public Internet (phew:-) and telnet
wasn't an option
Deb:
- is there a way to do clients so not everything is installed all the
time
Theo:
- our client has all old stuff linked in but has to be specifically
turned on to a thing we won't fall back to
- actual removal would help upstream crypto libraries though
- maybe even remove old codepoints from IANA registries?
Bob:
- considered the interaction beween who supports what, question is how
long to try suppoort the long-tail of clients
Damien:
- turning off in server maybe less feasible - if something is in
client, you still need to test it in server
Joseph:
- from the operator perspective - 5 years ago we still had a switch
that was telnet only, now we're ssh only - if you remove things from
client we need to do lots more testing of client updates
Theo:
- we'll be conservative

other drafts

• no presenters for ntru or mlkem today

AOB

Tero:
- what version of file transfer draft to use? take to the list