Subject: [Fwd: [Russ Housley] DISCUSS: draft-ietf-secsh-newmodes-05]

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 29 Aug 2005 13:43:32 -0400

Some review comments from Russ Housley.

As a strawman resolution to the DISCUSS comment, how about making
aes128-ctr REQUIRED?   (this new requirement has no effect on
implementations which don't claim to implement newmodes).

I haven't looked closely at the non-DISCUSS comments just yet.

						- Bill

-----Forwarded Message-----

From: Russ Housley <[email-masked]>
Subject: DISCUSS: draft-ietf-secsh-newmodes-05
Sender: [email-masked]
To: [email-masked]

SSH Transport Layer Encryption Modes (Proposed Standard)

DISCUSS

   All of the encryption modes described in this document are RECOMMENDED
   or OPTIONAL.  Why isn't one of them REQUIRED?

COMMENT

   I think that the last paragraph of the Abstract belongs in the
   Introduction.

   Section 3.1 says:
   >
   > The preferred way to do this is to rekey after receiving more than
   > 2**31 packets since the last rekey operation.
   >
   I suggest:
   >
   > The preferred implementation technique is to use the reception of
   > more than 2**31 packets since the last rekey operation as a trigger
   > to rekey.

   Two comments about section 4:

   * The description of counter mode seems compatible with NIST SP 800-38A.
     A single counter is used here, instead of a counter for each packet,
     but that does not seem to be a problem.  Please reference NIST
     SP 800-38A.

   * The usual reference for Triple-DES is:
       [3DES]  American National Standards Institute. ANSI X9.52-1998,
               Triple Data Encryption Algorithm Modes of Operation. 1998.

   Section 6.2 says:
   >
   > Fortunately, the common concerns with counter mode do not apply to
   > SSH because of the rekeying recommendations and because of the
   > additional protection provided by the transport protocol's MAC.
   >
   This sentence should also include the built-in initial key
   establishment capability.

---

From: Ben Harris <[email-masked]>
Date: Mon, 29 Aug 2005 19:07:01 +0100

>Some review comments from Russ Housley.
...
>>   or OPTIONAL.  Why isn't one of them REQUIRED?
...
>implementations which don't claim to implement newmodes).

I'd prefer to make 3des-ctr the REQUIRED algorithm, since all SSH
implementations are required to have 3DES code around anyway to support
3des-cbc, so anyone implementing newmodes can put in 3des-ctr support
trivially, whereas aes128-ctr might be a lot more effort or even impossible
(imagine a small implementation without room for both 3DES and AES).

This does raise the question of how to arrange a transition to AES (or
whatever) in the longer term, but I don't think it should be done on the
back of newmodes.

-- 
Ben Harris

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 29 Aug 2005 14:15:24 -0400

On Monday, August 29, 2005 07:07:01 PM +0100 Ben Harris <[email-masked]> 
wrote:

> trivially, whereas aes128-ctr might be a lot more effort or even
> impossible (imagine a small implementation without room for both 3DES and
> AES).
>

Russ's comment notwithstanding, I don't think we actually need any of the 
modes described in newmodes to be REQUIRED.  It's one thing to say "if you 
support ssh then you MUST support 3des-cbc".  It's quite another to say "if 
you support 3des-ctr then you MUST also support aes128-ctr" or vice versa. 
The former insures that ssh implementations will be interoperable; the 
latter does not appear to me to add any value.

-- Jeff

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 29 Aug 2005 14:41:38 -0400

> you support 3des-ctr then you MUST also support aes128-ctr" or vice versa. 

I believe the goal is "if you support 'newmodes' you must support
aes128-ctr" so that two implementations which claim to support
"newmodes" will not fail to interoperate because one only supports
3des-ctr and the other only supports aes128-ctr.

					- Bill

---

From: der Mouse <[email-masked]>
Date: Mon, 29 Aug 2005 14:54:09 -0400 (EDT)

>> I don't think we actually need any of the modes described in
>> newmodes to be REQUIRED.  [...]

I don't see that as an especially useful property, because I don't
think "supports `newmodes'" is a useful thing.  "Supports aes128-ctr
from `newmodes'", or "rekeys as recommended by `newmodes'", or the
like, those could be useful, but newmodes qua newmodes isn't so much a
thing to be supported (or not) as a convenient umbrella under which to
collect a bunch of individual things to be supported (or not).

I'm in favour of the "no REQUIRED items" position.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       [email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Sam Hartman <[email-masked]>
Date: Mon, 29 Aug 2005 15:15:16 -0400

>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:

    Jeffrey> On Monday, August 29, 2005 07:07:01 PM +0100 Ben Harris
    Jeffrey> <[email-masked]> wrote:

    >>>> All of the encryption modes described in this document are
    >>>> RECOMMENDED or OPTIONAL.  Why isn't one of them REQUIRED?
    >> ...
    >>> As a strawman resolution to the DISCUSS comment, how about
    >>> making aes128-ctr REQUIRED?  (this new requirement has no
    >>> effect on implementations which don't claim to implement
    >>> newmodes).
    >>  I'd prefer to make 3des-ctr the REQUIRED algorithm, since all
    >> SSH implementations are required to have 3DES code around
    >> anyway to support 3des-cbc, so anyone implementing newmodes can
    >> put in 3des-ctr support trivially, whereas aes128-ctr might be
    >> a lot more effort or even impossible (imagine a small
    >> implementation without room for both 3DES and AES).
    >> 
    >> This does raise the question of how to arrange a transition to
    >> AES (or whatever) in the longer term, but I don't think it
    >> should be done on the back of newmodes.

    Jeffrey> Russ's comment notwithstanding, I don't think we actually
    Jeffrey> need any of the modes described in newmodes to be
    Jeffrey> REQUIRED.  It's one thing to say "if you support ssh then
    Jeffrey> you MUST support 3des-cbc".  It's quite another to say
    Jeffrey> "if you support 3des-ctr then you MUST also support
    Jeffrey> aes128-ctr" or vice versa. The former insures that ssh
    Jeffrey> implementations will be interoperable; the latter does
    Jeffrey> not appear to me to add any value.

I tend to agree with Jeff.  Note that Russ asked a question; he did
not yet ask for a change.  I think someone should answer his question.

--Sam

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 29 Aug 2005 15:15:46 -0400

> collect a bunch of individual things to be supported (or not).

Exactly.

---

From: der Mouse <[email-masked]>
Date: Mon, 29 Aug 2005 16:25:13 -0400 (EDT)

> Note that Russ asked a question; he did not yet ask for a change.  I
> think someone should answer his question.

>>>>> RECOMMENDED or OPTIONAL.  Why isn't one of them REQUIRED?

My own answer to it, then, which anyone is welcome to use if it seems
appropriate, is:

    Because it's not appropriate; newmodes is not so much a thing to
    implement or conform to in its own right as it is a collection of
    individual things to implement or conform to.  Thus, making (say)
    des3-ctr REQUIRED is really just saying "you cannot claim to do
    newmodes if you don't do des3-ctr", but since claiming to implement
    newmodes is not a useful thing (as opposed to claiming
    implementation of particular things defined in newmodes), this is
    not useful.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 29 Aug 2005 16:38:50 -0400

> latter does not appear to me to add any value.

<wg chair hat off>

The motivation for the counter-mode ciphers in newmodes is to avoid the
known, but generally considered minor, security hole from the use of CBC
with known IV values.

I'd expect that users concerned with this attack will therefore want to
move to a world where it is possible to disable CBC-mode ciphers.

I think that, alone, justifies making one or more of the ciphers
REQUIRED, to avoid a situation where two implementations would be
required to fall back to 3des-cbc because neither implements the same
counter-mode cipher.

---

From: der Mouse <[email-masked]>
Date: Mon, 29 Aug 2005 16:51:09 -0400 (EDT)

> I'd expect that users concerned with this attack will therefore want
> to move to a world where it is possible to disable CBC-mode ciphers.

> required to fall back to 3des-cbc because neither implements the same

I don't see this as an issue.  There's always the risk of not agreeing
on a cipher; even if everyone were to pay attention to the REQUIREDs,
admins can still tell implementations to refuse to use them.

Furthermore, "a world where it is possible to disable CBC-mode ciphers"
is what we already have.  Certainly my implementation, and I think
every other implementation I've looked at (all two? of them :), can be
told to refuse to use any desired subset of the ciphers it implements,
regardless of what any spec may name REQUIRED.

Unless you mean "a world where it is practical to disable CBC-mode
ciphers and still expect to interoperate with arm's-length third
parties", in which case naming anything REQUIRED in newmodes won't do
that unless you can also guarantee not only sufficiently universal
implementation of newmodes but paying attention to that REQUIRED.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign

---

From: Ben Harris <[email-masked]>
Date: Tue, 30 Aug 2005 01:10:01 +0100 (BST)

> required to fall back to 3des-cbc because neither implements the same

Making one of the ciphers REQUIRED, though, isn't sufficient to ensure
that CBC-mode ciphers aren't used.  To take a concrete example, PuTTY's 
preference order for AES is currently "aes256-ctr,aes256-cbc,aes192-ctr,
aes192-cbc,aes128-ctr,aes128-cbc", so even though PuTTY supports 
aes128-ctr, it'll get aes256-cbc if the server supports that.  To get the 
effect you want, you'd have to require clients to provide an option to 
prefer CTR-mode ciphers over CBC-mode (and presumably over other ciphers 
as well).  As yet, the SSH drafts have avoided this kind of requirement on 
the configurability of clients, and I think this is probably a good thing.

Incidentally, I'm not opposed to making 3des-ctr REQUIRED, for all that I 
think it's unnecessary.  I _am_ opposed to making aes128-ctr REQUIRED.

-- 
Ben Harris

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 29 Aug 2005 20:42:36 -0400

On Tuesday, August 30, 2005 01:10:01 AM +0100 Ben Harris 
<[email-masked]> wrote:

> As yet, the SSH drafts have avoided this kind of requirement
> on the configurability of clients, and I think this is probably a good
> thing.

I agree.