OpenSSH: Meaning of cipher with email address @openssh.com

Question

When using OpenSSH server (sshd) we specify allowed ciphers, host key algorithms and MACs. Some of those ciphers have an email address appended, for example [email protected] as opposed to aes256-ctr. What is the meaning of that? I checked sshd_config and couldn't find an explanation.

Answer 1

Those are algorithms defined by vendors like openssh, not defined by the SSH standard (IETF RFCs). They are extensions to the protocol. Of course, you are not guaranteed that software other than openssh would interoperate with those options.

The specifics of [email protected] is defined in openssh documentation:

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.

In this case, the non standard extension is used as a bugfix for the spec.

In general, using non standard extensions is how they are able to experimentally support a post quantum key exchange algorithm, [email protected], years before PQ Crypto will get standardized.

Compare this with how old Chrome used custom TLS cipher suite for ChaCha20Poly1305, before that was standardized by IETF in an incompatible way, and some TLS servers support old chacha and ietf-chacha. Or how Chrome did a series of post quantum crypto experiments using non-standard cipher suite values.

Algorithms that have been widely deployed and have not encountered problems might get "blessed" by IETF, and become standardized, and this, in theory, is how IETF protocols evolve: broad consensus among practitioners, rather than standardizing a design no one has tried to use (or even implemented at all) and discovering problems only after the standard is out.

Answer 2

By the way, that's a domain name, not an email address. As explicitly pointed out in RFC4251 section 6:

There are two formats for algorithm and method names:

   o  Names that do not contain an at-sign ("@") are reserved to be
      assigned by IETF CONSENSUS.  ....

   o  Anyone can define additional algorithms or methods by using names
      in the format name@domainname, e.g., "[email protected]".
      The format of the part preceding the at-sign is not specified;
      however, these names MUST be printable US-ASCII strings, and MUST
      NOT contain the comma character (","), whitespace, control
      characters (ASCII codes 32 or less), or the ASCII code 127 (DEL).
      They MUST have only a single at-sign in them.  The part following
      the at-sign MUST be a valid, fully qualified domain name [RFC1034]
      controlled by the person or organization defining the name.  Names
      are case-sensitive, and MUST NOT be longer than 64 characters.  It
      is up to each domain how it manages its local namespace.  It
      should be noted that these names resemble STD 11 [RFC0822] email
      addresses.  This is purely coincidental and has nothing to do with
      STD 11 [RFC0822].