IETF-SSH archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: suggestion for new ssh maintenance wg



> SFTP v3 - as implemented by OpenSSH and everyone who wants to interoperate with it

Gah, sorry, wrong version. That's SFTP v4, which is also implemented by many clients and servers. However, most that implemented v4 by now also implement v6.

This is version 3:

https://tools.ietf.org/html/draft-ietf-secsh-filexfer-02


denis bider <ietf-ssh3%denisbider.com@localhost> , 1/29/2016 9:59 PM:
With regard to AEAD:

I think we should just make the following simple and clear statement:

MAC algorithms are secondary to encryption algorithms, and are evaluated only if the encryption algorithm is not AEAD. If an AEAD encryption algorithm is negotiated, the outcome of MAC negotiation is irrelevant and must be ignored. If no mutual MAC algorithms are available, this causes key exchange to fail if, and only if, the negotiated encryption algorithm is not AEAD.

I believe this is what aesXXX-gcm%openssh.com@localhost does, and is the behavior that makes most sense to me.


With regard to SFTP:

We may not have an agreement in what SFTP should be; but by necessity, we have an agreement in what it is.

I suggest we should simply do the minimum work possible to promote the following drafts to some type of RFC, and call it a day:

SFTP v3 - as implemented by OpenSSH and everyone who wants to interoperate with it
https://tools.ietf.org/html/draft-ietf-secsh-filexfer-04

SFTP v6 - implemented by many (perhaps most?) clients and servers
https://tools.ietf.org/html/draft-ietf-secsh-filexfer-13
https://tools.ietf.org/html/draft-galb-filexfer-extensions-00

This is the de facto SFTP as we have it. Implementers have to follow these drafts, so they might as well be RFCs.


----- Original Message -----
From: Niels "Möller"
Sent: Friday, January 29, 2016 15:34
To: Stephen Farrell
Cc: ietf-ssh%NetBSD.org@localhost ; denis bider ; Watson Ladd ; Daniel Migault ; Curdle Chairs ; mdb%juniper.net@localhost
Subject: Re: suggestion for new ssh maintenance wg
 
Stephen Farrell <stephen.farrell%cs.tcd.ie@localhost> writes:
 
> If you think such an ssh maintenance wg is a bad plan,
> please also do say that and why you think that.
 
There's definitely some work that needs to be done. I'm not very
familiar with ietf processes, so I'm not sure a new working group would
make it easier to make progress. I guess what's needed is either an
active wg chair, or an active area director, or someone informally
accepting (and being accepted) in a similar role.
 
> PPS: Note that this could be short-lived wg that never
> needs to meet face-to-face, or maybe it'd not be like that,
> but don't get fussed about having to go to IETF meetings
> to get this work done - if it's maintenance then that may
> well not be needed.
 
Don't worry about IETF meetings. I felt I was deeply involved during the
work on the ssh rfc:s. And I've never been to a secsh wg meeting, only
on the mailing list. (I've actually been to one ietf meeting in my life,
but the secsh wg didn't meet that time).
 
>> Extension negotiation for SSH:
>> https://datatracker.ietf.org/doc/draft-ssh-ext-info
 
An extension mechanism makes sense to me, but I find most of the
proposed extensions questionable and/or hard to get right.
 
>> In addition to the above, I very much agree that aes-gcm%openssh.com@localhost
>> needs standardization.
 
I think the single issue that might motivate forming a new wg is how to
properly negotiate the use of aead crypt in ssh. There should be no
difference between aes-gcm (which I'm not very fond of) and
chacha-poly1305.
 
>> Among other things, the erstwhile SSH working group never finalized
>> the SFTP spec due to lack of consensus. We now have two SFTP specs,
>> version 3 implemented by OpenSSH, and version 6 implemented by most
>> everyone else.
 
I honestly doubt we'll see much progress there, wg or not. It was a bit
too much of second system syndrome. But if some others have the energy
to revive it, I can't object, of course.
 
Regards,
/Niels
 
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.


Home | Main Index | Thread Index | Old Index