Subject: core draft issue resolution

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 09 Nov 2004 17:53:43 -0500

Proposed core issue resolutions from today's meeting:

If anyone objects to these resolutions, or thinks I mis-summarized the
discussion, please speak up.

ticket 440, 441, 450: close, edits complete.

ticket 453: WG chair to identify stable reference for sshv1
	(sent to list recently)

ticket 454: explicitly grandfather 3DES
	Editor to insert text equivalent to:

	NOTE: There is a known attack on 3-key 3DES involving
	2^112 space and 2^56 time; however, for the purposes of this
	requirement 3DES is considered to be strong enough.

ticket 461 (implicit server auth): 
	Editor to dig up clarification from list archives, 
	insert into document.

ticket 462: different algs in each direction
	proposal: allow but discourage; Editor to supply text.

ticket 463: login timeout
	proposal: no change to document

	rationale:
	- 10 minutes is shorter than typical SMTP listener idle timeout
	- user interaction is covered in this timeout (entering
	passwords, etc.,; as a result there may be accessibility requirements
	for slow typers..)
	- implementations will likely have knobs to adjust this

ticket 464: utf8:
	utf8 requires input canonicalization; stringprep of usernames
	and passwords was previously solved by SASL in
	draft-ietf-sasl-saslprep-10.txt (in RFC Editor Queue, EDIT state)

	Rather than reinvent the wheel, just cite it.

ticket 465: close.  was request for consulting

ticket 474: x509: remove x509-related text.  joe galbraith to supply
	followup I-D documenting what they do for x509

ticket 460, 601:  no consensus on list.
	flipped coin, heads for "group2", tails for "group14", 
	came up tails

	will stick with diffie-hellman-group14-sha1

---

From: Chris Lonvick <[email-masked]>
Date: Wed, 17 Nov 2004 09:58:38 -0800 (PST)

Hi,

> 	requirement 3DES is considered to be strong enough.

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.
As such I was going to use the following text:

   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
   algorithm is still REQUIRED for historical reasons; essentially, all
   known implementations at the time of this writing support this
   algorithm, and it is commonly used because it is the fundamental
   interoperable algorithm.  At some future time it is expected that
   another algorithm, one with better strength, will become so prevalent
   and ubiquitous that the use of "3des-cbc" will be depricated by
   another STANDARDS ACTION.

Does this work?

> 	Rather than reinvent the wheel, just cite it.

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.

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

Thanks,
Chris

---

From: [email-masked] (Niels Möller)
Date: 17 Nov 2004 22:01:25 +0100

> 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.

>    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.

>    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

Regards,
/Niels

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 17 Nov 2004 17:33:26 -0500

> > 	requirement 3DES is considered to be strong enough.

this is a typo.  i meant 2^112 time, 2^56 space.  sorry for any
confusion.