Re: AEAD in ssh

"Mark D. Baushke" <[email protected]> writes:

> Rather than "n/a" as the atom, why not "AEAD" or "aead" so we are clear
> about the intent? That said, I am fine with ignoring the Mac if the
> 'Cipher' is an AEAD like the OpenSSH folks do if that is helpful.

Should we allow advertising an empty mac list when all advertised
ciphers are aead?

RFC4253, Sec 7.1., is quite clear that "Each name-list MUST contain at
least one algorithm name.". Is it ok to depart from that? Otherwise we
need some placeholder, be that "n/a" or "aead". (Or perhaps we could use
"none" in the particular case that *all* ciphers are aead, but I kind-of
dislike ever adding "none" to these lists, it's about as appropriate in
this case as using "hmac-md5", which would actually work just as well).

Rereading 4253, it also seems I misremembered the current spec of
first_kex_packet follows. It says

   o  the kex algorithm and/or the host key algorithm is guessed wrong
      (server and client have different preferred algorithm), or

   o  if any of the other algorithms cannot be agreed upon (the
      procedure is defined below in Section 7.1).

so maybe no tweaks needed there for aead. If the dependence on host key
algorithm is confusing or improper, that's an independent issue,
unrelated to aead.

I'm also happy to say that I've gotten some time to work on a draft.
Hopefully I have something within a few days.

Regards,
/Niels

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