Subject: Fwd: [saag] potential new wg - curdle...

From: Stephen Farrell <[email-masked]>
Date: Wed, 18 Nov 2015 11:33:49 +0000

Hiya,

Here's how we're thinking of doing IETF processing of some of the
new work that's been discussed on here. Please say what you think.

I've not followed all the recent mails on here though about new
work, so I'm not sure if this captures everything that folks want
to get done. Figuring that out here would be good.

Comments on non-SSH aspects of this are probably better sent to
the saag list.

Thanks,
S.

-------- Forwarded Message --------
Subject: [saag] potential new wg - curdle...
Date: Wed, 18 Nov 2015 11:23:56 +0000
From: Stephen Farrell <[email-masked]>
To: [email-masked] <[email-masked]>

Hiya,

Following on from the earlier discussion about adding curves
etc. a few folks (*) helped Kathleen and I craft an initial cut
at charter text. [1]

I think we have people (well, mostly Simon:-) to do the editing
work for this.

If you'd be willing to be a chair, please send an offlist mail
to Kathleen and I.

If you think this is useful and would review documents please
respond to this mail saying so. I'd like to see that we have
enough folks interested to make this work.

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

If you think this is a bad idea, I'm sure you'll not be shy in
saying so too:-)

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-masked]
https://www.ietf.org/mailman/listinfo/saag

---

From: "Mark D. Baushke" <[email-masked]>
Date: Wed, 18 Nov 2015 09:24:34 -0800

Hi Stephen,

> preferably in OLD/NEW form.

The charter seems reasonable to me.

> if it's bad text or a dumb idea:-)

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-masked]" or "[email-masked]" 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

---

From: [email-masked] (Niels Möller)
Date: Thu, 19 Nov 2015 07:12:45 +0100

> that they should NOT be added to the MAC Algorithms Names in IANA.

THe openssh way of ignoring the mac negotiation completely, if an aead
cipher is negotiated, seems nice and simple. How does it interact with
first_kex_packet_follows logic, does that need any clarification (a
simple rule is to say that if both sides advertise the same aead cipher
as the first cipher, then for first_kex_packet_follows purposes, the mac
negotiation is considered successful and correctly guessed)?

Not sure if it has a place in the same rfc, but I think a proper
specification for use aead is quite inportant.

Regards,
/niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.

---

From: "Mark D. Baushke" <[email-masked]>
Date: Thu, 19 Nov 2015 08:59:38 -0800

> negotiation is considered successful and correctly guessed)?

I am not sure that first_kex_packet_follows would guess properly because
the first listed algorithm must be the same on both sides and I am not
sure that will be true very often given the number of different host key
algorithms that exist.

> specification for use aead is quite inportant.

Okay.

	Thanks,
	-- Mark

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 20 Nov 2015 10:51:07 +0000

Mark D. Baushke <[email-masked]> writes:

>I am not sure that first_kex_packet_follows would guess properly because the
>first listed algorithm must be the same on both sides and I am not sure that
>will be true very often given the number of different host key algorithms
>that exist.

How widely is first_kex_packet_follows used in practice?  That's another thing
I'd like to see deprecated in any future changes (see the SimpleSSH proposal I
mentioned a week or so back), it vastly complicates the handshake when you
have to guess at things and potentially roll back to the previous state and
try again.  Best-case if you've got identical, identially-configured
implementations at both ends you save a whole RTT, but more common case you
have a lot of extra complexity and overhead as you roll back from the
incorrectly-guessed keyex and try again.

Peter.