Re: core draft issue resolution

[nisse%lysator.liu.se@localhost (Niels Möller)]

Chris Lonvick <clonvick%cisco.com@localhost> writes:

> Is there a name and reference for that attack?  Also, I had thought that
> the reason for keeping 3DES was that it is the "interoperable" algorithm.

Another reason is that 3des is believed to be a strong and robust
cipher. DES is probably the most well-analyzed ciphers in the world.

>    The "3des-cbc" cipher is three-key triple-DES
>    (encrypt-decrypt-encrypt), where the first 8 bytes of the key are
>    used for the first encryption, the next 8 bytes for the decryption,
>    and the following 8 bytes for the final encryption.  This requires 24
>    bytes of key data (of which 168 bits are actually used).  To
>    implement CBC mode, outer chaining MUST be used (i.e., there is only
>    one initialization vector).  This is a block cipher with 8 byte
>    blocks.  This algorithm is defined in [FIPS-46-3].  Note that this
>    algorithm does not meet the specifications that SSH encryption
>    algorithms must use keys of 196 bits or more.  However, this
                                 ^^^

The actual requirement, from section 6.3 of the transport draft, is
"All ciphers SHOULD use keys with an effective key length of 128 bits
or more."

So 3des has sufficiently many key bits on the surface, the problem is
that there's a space/time trade-off that lets one brute force 3des by
using a large amount of memory and only a 112 bit keysize. Which is
slightly smaller than the 128 bits we say we want.

This is pretty old, Schneier summarizes it as "triple encryption, with
three independent keys, is as secure as one might naïvely expect
double encryption to be". He refers to R.C. Merkle and M. Hellman, "On
the Security of Multiple Encryption," Communication of the ACM, v. 24,
n. 7, 1981, pp 465-467.

And Bill is talking about some other, newer, attack, with 2^112 space
and 2^56 time; I'm afraid I'm not familiar with that, and I can't say
if that is more or less practical than the old attack. 2^112 in either
space or time is pretty hard.

> How about this:
> 
>    Note that the 'plaintext password' value is encoded in ISO-10646
>    UTF-8.  This encoding MUST be performed canonically as described in
>    [RFC9999].  It is up to the server how it interprets the password and
>    validates it against the password database.  However, if the client
>    reads the password in some other encoding (e.g., ISO 8859-1 - ISO
>    Latin1), it MUST convert the password to ISO-10646 UTF-8 before
>    transmitting, and the server MUST convert the password to the
>    encoding used on that system for passwords.

Looks ok to me. The message descriptions should probably be updated as
well, e.g,

Before:

3.1.1  Authentication Requests

   All authentication requests MUST use the following message format.
   Only the first few fields are defined; the remaining fields depend on
   the authentication method.
      byte      SSH_MSG_USERAUTH_REQUEST
      string    user name in ISO-10646 UTF-8 encoding [RFC2279]
      string    service name in US-ASCII
      string    method name in US-ASCII
      The rest of the packet is method-specific.

After: Change the definition of the second field to

       string    user name in UTF-8, normalized according to RFC9999

> [RFC9999] is a placeholder for "SASLprep: Stringprep profile for user
> names and passwords".

Regards,
/Niels