Re: potential new wg - curdle...

Hi Stephen,

Stephen Farrell <[email protected]> writes:

> If you have changes to charter text to suggest please do so,
> preferably in OLD/NEW form.

The charter seems reasonable to me.

> If there's not enough interest or if there're sound objections then
> we can abandon the idea and fall back to processing this stuff more
> slowly and more ad-hoc as AD sponsored drafts. (The main point of
> curdle is to be more organised and hopefully quicker at this.)
> 
> Thanks,
> S.
> 
> [1] https://datatracker.ietf.org/doc/charter-ietf-curdle/
> 
> (*) Thanks to Simon Josefsson, Yoav Nir, Russ Housley and
> Sean Turner for help with the text. The fault however is mine,
> if it's bad text or a dumb idea:-)
> 
> _______________________________________________
> saag mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/saag

I wonder if RFC 5647 which is an information RFC for "AES Galois Counter
Mode for the Secure Shell Transport Layer Protocol" could be cleaned up
to address the problems of the key exchange as expressed by the OpenSSH
team and made into a standard track document?

To quote the objection from the OpenSSH PROTOCOL document:

| 1.6 transport: AES-GCM
| 
| OpenSSH supports the AES-GCM algorithm as specified in RFC 5647.
| Because of problems with the specification of the key exchange
| the behaviour of OpenSSH differs from the RFC as follows:
| 
| AES-GCM is only negotiated as the cipher algorithms
| "[email protected]" or "[email protected]" and never as
| an MAC algorithm. Additionally, if AES-GCM is selected as the cipher
| the exchanged MAC algorithms are ignored and there doesn't have to be
| a matching MAC.

Given that current implementatons of this informational RFC are using
AEAD_AES_128_GCM and AEAD_AES_256_GCM and all of the standards track
Cipher algorithms use lowercase with '-' as word separators, I would
suggest that 'aes128-gcm' and 'aes256-gcm' may be more appropriate and
that they should NOT be added to the MAC Algorithms Names in IANA.

This same objection would arise to any AEAD Cipher, so I think it might
be well to do something similar for SSH for standardize
"chacha20-poly1305" for Secure Shell again as a Cipher name only with
the MAC Algorithm Name ignored.

	Thank you,
	-- Mark