Subject: Core draft last call update.

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 06 Mar 2002 15:35:21 -0500

The two drafts we were waiting for have emerged from the queue (and,
at least for me, were identical to the files Darren mailed to this
list); I'm accordingly revising the last call notice:

A Working Group Last Call began on 1 March 2002 and will end on 12 March
2002 for the following four drafts:

	draft-ietf-secsh-architecture-12.txt 
	draft-ietf-secsh-connect-15.txt
	draft-ietf-secsh-transport-13.txt
	draft-ietf-secsh-userauth-15.txt

I believe that these documents likely the current consensus of the
working group and should be submitted to the IESG for consideration
for publication as Proposed Standards.

Comments regarding the content of these documents should be sent to
the working group mailing list, <[email-masked]>.  If you believe
a change to a document is necessary, please include revised wording
along with your comment.

This Last Call period extends until 12 March 2002.

Issues raised so far:

 - Wei Dai: plaintext-guess-verification attack possible against CBC
based symmetric encryption modes.

Proposed resolution: WG does not see this as a serious issue but will pursue
other encryption modes; no document change necessary at this stage.

 - XXX: existing text regarding certificates needs still more
   wordsmithing.

Proposed resolution: during the previous last call, the WG concluded
that certificate handling should be be described in a separate
document.  When that document exists, it can supply any necessary
clarifications; there's correspondingly no need to respin the core
drafts at this time.

					- Bill

---

From: [email-masked] (David Wagner)
Date: 6 Mar 2002 20:56:47 GMT

>other encryption modes; no document change necessary at this stage.

Hmm.  I'm a little concerned about this.  Here's my reaction.

I looked at the packet format and it looks like there may be the
opportunity to exploit this against sessions that contain at least
2^16 packets and that multiplex data from multiple sources (surprisingly
common).  That's not a devastating attack, but it's probably not
such a good property, either.

3DES, AES, and Blowfish are supposed to be very conservative ciphers.
The above flaw partially undermines this strength.  If there were some
attack on our block cipher requiring only 2^16 known or chosen plaintexts,
we'd run screaming; are there reasons to hold our modes of operation
to a lower standard?

For comparison, attacks of comparable impact have led to changes in the
IPSec packet format (Bellovin's cut-and-paste attacks) and might lead
to changes to TLS (heavy discussions ongoing in TLS WG right now).

I don't see it as an urgent "fix this today!" bug, but standards move
slowly and it may make sense to get started on fixing the specification.
(It's not going to get any easier with time.)

Looking at this from a design perspective, the fix seems to be
straightforward.  AES-CTR would do fine.  AES-CBC with unpredictable
IV's would also be ok, so long as all implementations enforce the
constraint that they won't start emitting ciphertext until they've
consumed all the plaintext for this message, but I bet many implementations
do not enforce this condition -- for this reason, I suggest AES-CTR.

How much work would it take to fix this weakness?

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 06 Mar 2002 16:13:38 -0500

David,

Note that I'm not saying we don't have to fix the problem.  

SSH is a modular protocol, and this very CBC flaw is also present in
SSL/TLS.

Documents specifying additional fixed modes can be advanced quickly
once we have consensus, but need not delay the core documents.

We SHOULD NOT DELAY THE REST OF SSH while we discuss a solution,
particularly since there appears to be some resistance to counter
modes from the membership.

					- Bill

---

From: Derek Fawcus <[email-masked]>
Date: Fri, 8 Mar 2002 18:22:31 +0000

> Issues raised so far:

Well there is also the issue I raised on 4th Feb in
Message-ID: <[email-masked]>

Pasted again below:

I've got a slightly different issue with the userauth spec,  section 3 states:
  
   Message numbers of 80 and higher are reserved for protocols running
   after this authentication protocol, so receiving one of them before
   authentication is complete is an error, to which the server MUST
   respond by disconnecting (preferably with a proper disconnect message
   sent first to ease troubleshooting).
  
Maybe I'm missing something,  but I can't see the need to disconnect in this
case,  as opposed to simply discarding these messages.  At the moment an
extra RTT is required to wait for the SSH_MSG_USERAUTH_SUCCESS,  assuming
that the log in method succeeds.  Given that I happen to frequently log
into machines over long slow (long RTT) links,  it gets painful.
  
Unless there is a valid security reason for disconnecting,  I'd suggest
a change to:
 
   Message numbers of 80 and higher are reserved for protocols running
   after this authentication protocol, so any of these messages received
   before authentication has completed cannot be processed;  if this
   situation occurs the server MUST silently discard those messages.
 
An alternative would be to generate some sort of error response to the
messages.  However silent discard serves the purpose of allowing one to
pipeline the initial connection protocol messages after a USERAUTH_REQUEST
on the assumption that it will succeed,  and still automatically deal
with the request failing.  The failure response indicating that the
subsequent higher level protocol messages have been discarded.

DF

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 08 Mar 2002 14:57:39 -0500

> case,  as opposed to simply discarding these messages.  

I don't think think it's that simple.  Have you actually prototyped
this?  

Many of these message types are ones for which the client expects a
response -- simply discarding such requests on the server will confuse
and/or hang clients which were expecting responses.

Any implementors want to comment on this in more detail?

						- Bill

---

From: Derek Fawcus <[email-masked]>
Date: Fri, 8 Mar 2002 20:24:30 +0000

> I don't think think it's that simple.  Have you actually prototyped

Not yet.  I'm working on an implementation,  but I've not got to the
user auth part yet.

My concern is pipelining messages in anticipation of success,  and
being able to cope with an error occuring.  Looking at the packet
sequences,  the current restriction forces another RTT into the
log in sequence.

> and/or hang clients which were expecting responses.

I did state in the original message that returning an error was also
acceptable to me,  I just didn't want them to cause the connection
to be terminated if there was no security implication of doing so.

I also don't think it'll cause a problem for existing clients,  as
they simply won't trigger this situation.

> Any implementors want to comment on this in more detail?

I'd not have thought there'd be any implication of existing client's,
as they'd not send the message until the RTT had expired,  and they'd
got a response.

There would be an issue for new clients connecting to existing servers,
but I was going to deal with that by having a flag which would delay
based upon a CLI flag,  so I could connect through old servers.

It would also mean that existing servers would strictly be non conforming,
but that could be dealt with during upgrades.

If as you state there is a problem with silent discard,  I'd be happy
with the following alternate text:

   Message numbers of 80 and higher are reserved for protocols running
   after this authentication protocol, so any of these messages received
   before authentication has completed cannot be processed;  if this
   situation occurs the server MUST respond with an error response,  and
   then not act upon the message.

For the error response,  I'd suggest that SSH_MSG_UNIMPLEMENTED would be
workable.  I'd rather have a generic message as a response,  as this
means we don't place a burden on the higher level protocols or always
have a failure type of response.  An alternate would be a message sent
back to state that the message was explicity exgnored (as opposed to
unimplemented),  which would in all other regards look like an unimplemented
message,  i.e. 

   byte SSH_MSG_IGNORED
   uint32 packet sequence number of ignored message

However that would then place more restrictions upon the sender in
that they'd have to check for IGNORED and UNIMPLEMENTED,  and decide
if they wish to allow the connection to continue.

DF

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 08 Mar 2002 15:33:03 -0500

> they simply won't trigger this situation.

What this tells me is that changing this later (after the current core
drafts go to proposed standard RFC and we're ready to go for draft
standard) is eminently doable.

I'll repeat my litany:

Is this something we absolutely positively need to fix this very
instant?  It doesn't seem that compelling to me..

							- Bill

---

From: Wei Dai <[email-masked]>
Date: Fri, 8 Mar 2002 21:37:22 -0800

> modes from the membership.

Would be appropriate to either (1) put something in the security
considerations section about this attack, so that implementors are warned
about this problem and will know to look for a future RFC describing the
solution, or (2) delay the SSH transport protocol spec and advance the
rest of SSH? 

P.S. I'm currently on vacation and my Internet connection is spotty.
Please excuse the late replys.

---

From: Bill Sommerfeld <[email-masked]>
Date: Sat, 09 Mar 2002 10:26:50 -0500

> solution, or (2) delay the SSH transport protocol spec and advance the

(2) is not useful, because you can't do SSH without all four drafts.

Remember that a certain set of folks will use telnet instead simply
because there's an RFC for telnet and there isn't one for SSH.

(1) is a possibility but needs to be worded very carefully (to not
scare telnet users away from deploying ssh).

						- Bill

---

From: Wei Dai <[email-masked]>
Date: Sun, 10 Mar 2002 21:38:49 -0800

> because there's an RFC for telnet and there isn't one for SSH.

Who are these people who puts that much more value on the availability of
an RFC than on security? I'm not sure we should be so concerned with them.

As the working group charter states, this working group is supposed to
assure that the SSH protocol provides strong security against
cryptanalysis and protocol attacks. I think it does nothing to inspire
confidence in potential users of the SSH protocol to have a security fix
come out immediately after the core RFCs are published. To me, being able
to claim that the set of core RFCs is free from known protocol weaknesses
is much more valuable than having the RFCs published a few weeks earlier.

Given that the problem was found in time, and that the fix is simple (I've
already provided the suggested language), why not just agree to fix it
now? I'm new to the IETF standardization process, but how much time could
it possibly take to put in the fix? If CTR mode is too controversial
(although I don't know why it would be and still haven't seen a
substantial argument against it) I would be willing to compromise by using
OFB or CFB mode instead.

---

From: "Andersson, Mats" <[email-masked]>
Date: Mon, 11 Mar 2002 09:37:09 +0100 (CET)

> Any implementors want to comment on this in more detail?

I can't see a big win in discard versus disconnect (especially since we
are in last-call now, considering the earlier comments on last minute
changes to the drafts...). Disconnect seems safer and easier to handle
from a protocol-perspective. If you want to optimistally assume the
authentication goes well and start higher-level traffic based on this
assumption it is better to handle this by queueing this traffic until the
authentication stage is done. There would be a marginal performance win of
course, however the complexity in handling potentially discarded messages
seems a high price for this. Since the whole transport setup and
authentication stages are pretty slimmed down anyway, this wouldn't add
much IMHO.

Cheers,

/Mats

---

From: Markus Friedl <[email-masked]>
Date: Mon, 11 Mar 2002 10:09:07 +0100

> substantial argument against it) I would be willing to compromise by using

Personally I think it would be better to add OFB and/or CFB modes than
to scare people in the draft by saying: "we use CBC but CBC can be
broken easily" (this is how people will read it).

As to CTR: AFAIK in CTR mode the handling, formating of the counter
needs some work before we can agree, e.g the proposal for aes128-ctr in
IPsec makes size(ciphertext) != size(plaintext), so CTR should not be
added now, because it will delay the process significantly.

So, if we would need a spec for OFB/CFB (with cipher block-sized
feedback) soon.

Having a paragraph about the dangers of CBC is a bad idea unless
we offer alternatives to CBC in the very same document.

---

From: [email-masked] (David Wagner)
Date: 11 Mar 2002 09:22:05 GMT

>So, if we would need a spec for OFB/CFB (with cipher block-sized

Hmm.  I must admit I'm a little confused: what are the reasons to
prefer OFB mode over CTR mode?  Are there some security reasons?  Is it
something else?  I don't see anything terribly wrong with OFB mode,
but I'd like to understand why it is preferred over CTR mode.

I'm also confused on why it's a problem that IPSec uses a form of CTR
mode not so well suited for SSH.  Or is it better not to ask?

P.S. I assumed that if there is a known security weakness, it would be
disclosed in the RFC, so I'm surprised that you consider it a bad thing to
have a paragraph describing the weakness.  Were you proposing that mention
of this risk should be omitted from the RFC?  That seems dangerous.

---

From: "Joseph Galbraith" <[email-masked]>
Date: Mon, 11 Mar 2002 08:51:15 -0700

> authentication stages are pretty slimmed down anyway, this wouldn't add

I agree with this.  The current language seems
safer and more likely to get us to RFC status
without any egg-on-face.

Complexity is the enemy.  Complexity introduces
bugs.  If it was just complexity in the client,
that the client could chose whether or not to
deal with, I might be more inclined to
'not care'.

But, it also introduces complexity in
the server (which in my opinion is more
sensitive to bugs.)  And the server
MUST bear that complexity.

If a server implements the current language,
there is very little chance of a packet
for a higher level being processed before
the user correctly authenticates (due
to server bug.)  Sure it could happen,
but it isn't likely.

On the other hand, it seems more likely
to happen with the new complexity.

Also, since we are in last call, we have
very little time to analyze the implications
and behaviors of the change.

It doesn't seem like we stand to gain
enough to take the risk.  Maybe we should
discuss it more for 2.1 after we've gotten
2.0 to RFC status.

- Joseph

---

From: Derek Fawcus <[email-masked]>
Date: Mon, 11 Mar 2002 17:14:05 +0000

On Mon, Mar 11, 2002 at 08:51:15AM -0700, Joseph Galbraith wrote:
> 
> Complexity is the enemy.  Complexity introduces bugs.  If it was
> just complexity in the client,  that the client could chose whether
> or not to deal with, I might be more inclined to 'not care'.

That is where I see the complexity,  the server behaviour would be fixed.
Instead of the current "shutdown complete SSH connection",  it would be
either "silent discard" or "generic error response".

> But, it also introduces complexity in the server (which in my opinion
> is more sensitive to bugs.)  And the server MUST bear that complexity.

Agreed.  However my contention is that this is only client complexity,
and then only if the client chooses to invoke the triggering condition.

> If a server implements the current language,  there is very little
> chance of a packet for a higher level being processed before
> the user correctly authenticates (due to server bug.)  Sure it could
> happen,  but it isn't likely.
> 
> On the other hand, it seems more likely to happen with the new complexity.

Disagree.  You're using the same flag (has authentication passed) to
simply perform a different action.  The packet in question has to be
inspected in either case,  instead of closing the connection you
simply silent discard or send a generic error response.

There is no additional complexity,  the server behaviour would change
from one fixed type of behaviour to another fixed type of behaviour.

> Also, since we are in last call,  we have very little time to
> analyze the implications and behaviors of the change.

We have as much time as we choose to take.

(i.e. the other thread about CBC mode...)

> It doesn't seem like we stand to gain enough to take the risk.

OK.  The granted,  gain is quite small.  It's the elimination of
one RTT.  The issue being that on long RTT links,  we already
have a multi RTT set up time.

Other parts (say the key exchange) are replaceable in the base spec,
and a protocol with a small number of RTs could be used.  This part
of the spec is fixed,  and precludes any form of client optimisation.

> Maybe we should discuss it more for 2.1 after we've gotten
> 2.0 to RFC status.

Well if the consensus is for that,  I'll accept it.

I threw the suggestion in 'cause it seemed a small change,  with no
security impact,  little implementation impact,  and because I couldn't
see a _security_ (as opposed to an implementation) reason for the
current language in the draft.

DF

---

From: [email-masked] (Niels Möller)
Date: 11 Mar 2002 18:14:01 +0100

> Any implementors want to comment on this in more detail?

This is my analysis: 

Discarding packets on the server side should be easy, except that one
must not discard any connection-level packets that are sent after the
userauth request that succeeded. But this logic should fit well with
the logic for discarding userauth messages received after the
succeeding one.

On the client side, one would compute the initial one or more packets
one wants to send after userauthentiation, and piggyback them onto
each send userauth request. After the succeeding userauth packet that
succeeds, one would expect the replies to the initial packets.

However, consider the client sending several userauth requests
(corresponding to the user's several public keys, say), with a piggy
backed SSH_MSG_CHANNEL_OPEN after each of them. In order:

 SSH_MSG_USERAUTH_REQUEST
 SSH_MSG_CHANNEL_OPEN
 SSH_MSG_USERAUTH_REQUEST
 SSH_MSG_CHANNEL_OPEN

If the second and final userauth request is that which succeeds, all
is well, if the above rules are applied. But if the first userauth
request succeeds, the second userauth request will be discarded, but
*both* SSH_MSG_CHANNEL_OPEN requests will be processed by the server,
so the client gets more than it wanted.

One solution to this is to require the client that wants to piggyback
non-userauth messages to wait for the reply to the first userauth
request before sending the second, but then we get more roundtrips.
Another might be to not *discard* non-userauth messages, but queue
them for later processing after a successful userauthentication. Then
the client could send

 SSH_MSG_CHANNEL_OPEN
 SSH_MSG_USERAUTH_REQUEST
 SSH_MSG_USERAUTH_REQUEST

and the server would process the channel open request exactly once,
*after* user authentication. But I think this reordering trick gets a
little ugly.

BTW, which implementations set the first_kex_packet_follows flag in
the SSH_MSG_KEXINIT? Perhaps we should evaluate that feature before
trying to optimize away some more roundtrips.

/Niels

---

From: "Joseph Galbraith" <[email-masked]>
Date: Mon, 11 Mar 2002 10:42:15 -0700

> trying to optimize away some more roundtrips.

I believe SSH Communications is the only
implementation using this, but I'm not sure.

- Joseph

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 12 Mar 2002 14:02:56 +0100

[...]
> now?

What about the attack described in Appendix C of
<URL:http://eprint.iacr.org/2001/045/>, which appears to be
applicable to the SSH binary packet protocol as specified in
draft-ietf-secsh-transport-13.txt (no matter if CBC or OFB or
counter mode is used)?

-- 
Bodo Möller <[email-masked]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 12 Mar 2002 09:52:54 -0500

> draft-ietf-secsh-transport-13.txt (no matter if CBC or OFB or

This attack has greatly increased difficulty for SSH because the SSH
MAC also covers the random pad at the end of the message.  As a
result, you can only tell if m and m' are identical if the random
padding appended by the sender is identical.

Quoting from the transport draft:

   After key exchange, the selected MAC will be computed
   before encryption from the concatenation of packet data:

     mac = MAC(key, sequence_number || unencrypted_packet)

   where unencrypted_packet is the entire packet without MAC (the length
   fields, payload and padding), and sequence_number is an implicit
   packet sequence number represented as uint32.

The chance of this happening depends on the message length -- ssh
requires at least 4 bytes of padding, and requires that messages be
padded to a multiple of the block size and a multiple of 8.

If the implementation inserts the minimum padding, this will be
between 4 and 11 bytes (and it can always insert more).

The most "interesting" case is, of course, a single byte of channel
data, which will get a minimum of 9 bytes of padding.

You also only get one shot at this per connection -- the peer will
drop the connection and forget the session key if you get it wrong.

Compression will complicate this attack as well.

					- Bill

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 12 Mar 2002 16:05:22 +0100

> padding appended by the sender is identical.

I see.  Actually the current draft only says that the padding 'SHOULD'
be random, not that it 'MUST' be random.  Also the minimum padding
length of 32 bits isn't large enough to make the attack really
intractable, so the protocol should eventually be fixed.

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 12 Mar 2002 10:26:34 -0500

> draft-ietf-secsh-transport-13.txt (no matter if CBC or OFB or

Now that I've had some caffeine -- there's another reason why this
attack can't work for SSH.

The appendix C attack works only if the IV is carried with each
message -- each message is independant, with no initial state other
than the key.

This is emphatically not the case for the ssh transport protocol in
any of CBC, CFB, OFB, or counter modes.

CBC, CFB:
With ssh, the IV of message N comes from the last block of message
N-1.  If the attacker simply substitutes c1 for c1', the first block of
c will be garbled due to the wrong IV.

If the attacker attempts to substitute the previous cipherblock as
well so that the IV's match, this will garble the previous message and
cause the connection to drop before the attack can be attempted.

OFB, counter mode:

The attack simply can't work as described, since the keystream
generated by the cipher will be completely different for c and c'; if
you substitute c for c', the entire decryption will be garbled.

I may be mistaken but in order for the "OTP" version of the attack
described in the appendix to be possible, the system under attack
would need to be committing a much greater cryptographic sin: that of
allowing the reuse of a stream cipher!

						- Bill

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 12 Mar 2002 17:04:22 +0100

> any of CBC, CFB, OFB, or counter modes.

Yes, you are right.  For any given record in the stream, after
processing the previous record has been completed, the mapping between
ciphertexts and plaintexts is bijective.  Thus it is not possible to
substitute a different ciphertext corresponding to the same plaintext
because there *is* no different ciphertext corresponding to the same
plaintext.

---

From: [email-masked] (David Wagner)
Date: 12 Mar 2002 17:01:56 GMT

>padding appended by the sender is identical.

Do all implementations use truly random padding?
It wasn't clear to me from the draft that the randomness
of the padding is security-critical, so I could easily imagine
as an optimization using not-very-random randomness for the
padding if I were implementing.  But maybe I missed something,
or maybe it was more obvious to others.

Would it be prudent to make the draft say that the padding
MUST use high-quality randomness, and to describe the security
threat so that implementors are less likely to fall into this trap?

---

From: [email-masked] (David Wagner)
Date: 12 Mar 2002 17:57:30 GMT

David Wagner wrote:
>Do all implementations use truly random padding? [...]

Please ignore my message.  I overlooked some remaining messages,
and thus this message is irrelevant.  (Thanks to Bill Sommerfeld
for gently pointing this out.)

---

From: Markus Friedl <[email-masked]>
Date: Tue, 12 Mar 2002 23:26:09 +0100

> implementation using this, but I'm not sure.

Who understands how first_kex_packet_follows is supposed to work?

---

From: Markus Friedl <[email-masked]>
Date: Tue, 12 Mar 2002 23:30:31 +0100

> but I'd like to understand why it is preferred over CTR mode.

my point is that for CTR there is no common format (e.g.
how is the counter encoded, etc) whereas a spec for OFB mode
is simpler.

> have a paragraph describing the weakness.

i think it's bad to have such a paragraph without offering
alternative cipher modes.

---

From: "Joseph Galbraith" <[email-masked]>
Date: Tue, 12 Mar 2002 17:11:15 -0700

> Who understands how first_kex_packet_follows is supposed to work?

I believe that the draft is accurate now
(it wasn't for a long time.)

Looking at the draft now, I could
wish that the description guessing
and when the guess was wrong was
grouped with the first_kex_packet_follows
instead of up above.

If the first_kex_packet_follows flag is
set, and the first item on the clients
list for public key or for key exchange
method does not match the first item
on the server list, the next packet
should be discarded as invalid.

If key exchange doesn't match, then
it is a packet for a key exchange
method that will not be run; and
in theory, the hostkey/public key
type could affect the first packet
sent, so this makes sense.

On the other hand, I'm less than
100% fond of this feature -- it seems
to add quite a bit of complexity for
a relatively small performance gain.

But I don't want to change it now :-)

- Joseph

---

From: [email-masked] (David Wagner)
Date: 13 Mar 2002 05:52:19 GMT

>how is the counter encoded, etc) whereas a spec for OFB mode

That's easily fixed, and I'd gladly volunteer to help.  Is this
really the only barrier to getting a fix in place?

>alternative cipher modes.

I admit I don't understand.  I come from a philosophy that says
you disclose what you know about the security properties of the
protocol, both positive and negative: truth in advertising.  If
the decision is that fixing this weakness is too costly at present,
that's one thing; avoiding all mention of it is another.  What's
gained by hiding the facts from implementors and readers of the RFC?
Can you help me understand the rationale behind such a stance?

---

From: "Andersson, Mats" <[email-masked]>
Date: Wed, 13 Mar 2002 09:03:43 +0100 (CET)

> Who understands how first_kex_packet_follows is supposed to work?

I've not used it and haven't contemplated it much though my interpretation
(implementation) of it is:

wrongguess = "
   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 Section 5.1)."

if(wronguess && first_kex_packet_follows) {
	<discard next received packet>
}

E.g. a guessing client just sends SSH_MSG_KEXDH_INIT directly after
SSH_MSG_KEXINIT, if it discovers that this is wrong (according to above)  
it knows that it can safely just retransmit some other KEX method's init.

Cheers,

/Mats

---

From: Markus Friedl <[email-masked]>
Date: Wed, 13 Mar 2002 09:37:43 +0100

> Can you help me understand the rationale behind such a stance?

Oops, this is not my intention:  I think it's better to offer
alternatives in the RFC.  If we want to offer alternative
reaching consens on OFB and CFB is faster, especially since many
installations/implementations already support these.

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 13 Mar 2002 12:52:21 -0500

> really the only barrier to getting a fix in place?

To quote Randy Bush:

"Please Send Draft"

					- Bill

---

From: Wei Dai <[email-masked]>
Date: Wed, 13 Mar 2002 15:14:07 -0800

> > really the only barrier to getting a fix in place?

What about the proposed language I sent earlier? It already specifies
everything needed for CTR mode.

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 13 Mar 2002 18:33:34 -0500

> everything needed for CTR mode.

It needs to be turned into a stand-alone internet-draft.

> For any cipher in CTR mode, the counter used to encrypt each plaintext
> block MUST be the IV if no previous plaintext block exists, or C+1 mod 2^N
> where C is the counter used to encrypt the previous block, and N is the
> block size of the cipher in bits.  Network order SHOULD be used to convert
> the counter between its octet string form and its integer form for the
> computation of C+1 mod 2^N. 

so:

The size of the IV is left unspecified.

The text "the counter used to encrypt each plaintext block" is
unspecified, and could mean any of:

	C[n] = ECB-Encrypt(ctr++, P[n]);
	C[n] = P[n] ^ ECB-Encrypt(K, ctr++);
	C[n] = P[n] ^ ctr++;

Also left underspecified is the block size of the mode (i.e., in terms
of how the transport layer pads out messages to the block size);
fundamentally there's no reason why this has to be the same as the
underlying cipher block size, but if they're different, you need to
specify whether or not partial blocks get carried over from message to
message.

				- Bill

---

From: Wei Dai <[email-masked]>
Date: Wed, 13 Mar 2002 18:32:02 -0800

> It needs to be turned into a stand-alone internet-draft.

Why?

> The size of the IV is left unspecified.

Ok, add this sentence to the end of 5.2:

For block cipher based algorithms with variable-length IVs, the IV length
SHOULD be the block size of the underlying block cipher.

> 	C[n] = P[n] ^ ECB-Encrypt(K, ctr++);

Ok, add this reference to the first mention of CTR:

   [SP800-38A] "Recommendation for Block Cipher Modes of Operation", 
   United States of American, National Institute of Science and 
   Technology, NIST Special Publication 800-38A 2001 Edition, December 
   2001. 

> specify whether or not partial blocks get carried over from message to

Good point, change the first paragraph under "random padding", section 4: 

Arbitrary-length padding, such that the total length of (packet_length ||
padding_length || payload || padding) is a multiple of the cipher block
size.  For ciphers that do not need to process data in blocks (for example
stream ciphers and block ciphers in CTR mode), a block size of 8 SHOULD be
used for the purpose of determining padding length.

And change the phrase "initialization vectors" in second paragraph of
section 4.3 to "initialization vectors and unused keystream octets".

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 13 Mar 2002 21:54:23 -0500

> > It needs to be turned into a stand-alone internet-draft.

I made a ruling as working group chair that, because (a) the problem
could be fixed by a separate document introducing new ciphers, and (b)
there clearly did not exist consensus on the a fix, that we should not
hold up advancement of the rest of SSH while we attempted to solve the
problem.  

You've missed the train.  The core specs are now out of our hands.

> block size of the cipher in bits.  Network order SHOULD be used to convert

s/SHOULD/MUST/.  If both sides don't increment the counter in the same
way, you won't interoperate.

[By comparison, random padding is only a SHOULD since getting it wrong
won't break interoperability (but might have subtler ramifications).
RFC2119 is quite clear that implementors may ignore SHOULD but they
do so only at their own peril.  ]

> SHOULD be the block size of the underlying block cipher.

I think this misses the point.  Something like:

   For counter mode, we use a counter equal in size to the cipher's
   block size.  The first block-size bytes of the "initialization
   vector" value negotiated by the transport protocol are used to
   initialize the counter.

would be much clearer.

>    Technology, NIST Special Publication 800-38A 2001 Edition, December 

I still think the text is confusing and vague.  The counter value is
not used to encrypt the plaintext.

---

From: Wei Dai <[email-masked]>
Date: Wed, 13 Mar 2002 21:20:51 -0800

> You've missed the train.  The core specs are now out of our hands.

I don't agree with the proposed resolution to the issue I raised. Should
I contact the Area Director now or wait for the general Last-Call?

> way, you won't interoperate.

I wrote SHOULD in case people want to define their own CTR ciphers and use
little endian counters. BTW, what about these two "SHOULD"s in 4.3:

   The encrypted data in all packets sent in one direction SHOULD be
   considered a single data stream.  For example, initialization vectors
   SHOULD be passed from the end of one packet to the beginning of the
   next packet.

If one side doesn't follow these shoulds, it would be an interoperability
problem, as well as a security problem.

> not used to encrypt the plaintext.

My assumption is that the implementor already knows what CTR mode is, and
we only need to specify the options (i.e. full-size IVs, big-endian
counter) that SSH uses. For comparison, there is no explanation of how CBC
mode works in the current draft, or even a specific reference for it.

---

From: Markus Friedl <[email-masked]>
Date: Thu, 14 Mar 2002 09:36:28 +0100

> everything needed for CTR mode.

I don't see a need to rush and consider CTR only, when CFB/OFB is
less controversal and already supported by existing implementations.

What am I missing?

---

From: Markus Friedl <[email-masked]>
Date: Thu, 14 Mar 2002 10:08:31 +0100

On Thu, Mar 14, 2002 at 09:36:28AM +0100, Markus Friedl wrote:
> when CFB/OFB is

Additional ciphers

   The following additional ciphers are defined in output feedback
   (OFB) mode:

     3des-ofb         RECOMMENDED       three-key 3DES in OFB mode
     blowfish-ofb     RECOMMENDED       Blowfish in OFB mode
     aes256-ofb       OPTIONAL          AES (Rijndael) in OFB mode,
                                        with 256-bit key
     aes192-ofb       OPTIONAL          AES with 192-bit key
     aes128-ofb       RECOMMENDED       AES with 128-bit key
     cast128-ofb      OPTIONAL          CAST-128 in OFB mode

   These ciphers are block ciphers use the same key setup, block
   size and IVs as their CBC counterparts, see [SSH-TRANS] for more
   information. (The IV must be changed if the same encryption key
   is reused.)

   The OFB mode is used with full feedback [HANDBOOK-APPLIED-CRYPTO,
   ISO10116]:

   "3des-ofb", "blowfish-ofb" and "cast128-ofb" use 64 bit feedback
   in OFB mode.

   "aes256-ofb", "aes192-ofb" and "aes128-ofb" use 128 bit feedback
   in OFB mode.

-m

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 14 Mar 2002 18:36:21 -0500

> I contact the Area Director now or wait for the general Last-Call?

Wei,

	If your goal is really to improve the deployed security
of the Internet, then you ought to just create the standalone
I-D and let the core drafts go without trying to de-rail
the train.

	Bottom line is some crypto is a higher work function for
an adversary than no crypto (telnet and plain-text).  Crypto
can always be improved.  Trying to optimise IPsec (repeatedly;
along many dimensions) is one of several reasons it was so badly
delayed.

	Also, for my part, I don't (yet) have a comfort level with
your proposal.

IMHO,

Ran
[email-masked]

---

From: Wei Dai <[email-masked]>
Date: Thu, 14 Mar 2002 20:00:54 -0800

> less controversal and already supported by existing implementations.

I was not aware that existing implementations already support CFB/OFB. 
Apparently this is the case for OpenSSH, but it's not documented anywhere.
OpenSSH also seems to support ECB mode, which does not make any sense to
me. BTW, OpenSSH appears to use unregistered reserved names for these
ciphers, which violates section 5 of the architecture spec. 

The way OpenSSH implements OFB (assuming it's accurately documented by the
draft spec you sent in a later post) is different from how I would have
done it. I would pad each packet to a multiple of 8 instead of the block
size, but never mind.

As I mentioned earlier, in the interest of time I'm willing to compromise
and use OFB instead of CTR if we can get it into the core spec. If we have
to do an additional RFC we might as well go for CTR since that is
technically superior.

---

From: Niels Provos <[email-masked]>
Date: Fri, 15 Mar 2002 00:34:58 -0500

> ciphers, which violates section 5 of the architecture spec. 
You have me confused.  What are you talking about?  Did you look at
the source code, cipher.c contains the supported ciphers, including
their names as announced during kex init:

        { "3des-cbc",           SSH_CIPHER_SSH2, 8, 24, EVP_des_ede3_cbc },
        { "blowfish-cbc",       SSH_CIPHER_SSH2, 8, 16, EVP_bf_cbc },
        { "cast128-cbc",        SSH_CIPHER_SSH2, 8, 16, EVP_cast5_cbc },
        { "arcfour",            SSH_CIPHER_SSH2, 8, 16, EVP_rc4 },
        { "aes128-cbc",         SSH_CIPHER_SSH2, 16, 16, evp_rijndael },
        { "aes192-cbc",         SSH_CIPHER_SSH2, 16, 24, evp_rijndael },
        { "aes256-cbc",         SSH_CIPHER_SSH2, 16, 32, evp_rijndael },

I do not think that any of these ciphers violate any section of
any spec produced by this working group.  Specficially:

   The following ciphers are currently defined:

     3des-cbc         REQUIRED          three-key 3DES in CBC mode
     blowfish-cbc     RECOMMENDED       Blowfish in CBC mode
     twofish256-cbc   OPTIONAL          Twofish in CBC mode,
                                        with 256-bit key
     twofish-cbc      OPTIONAL          alias for "twofish256-cbc" (this
                                        is being retained for
                                        historical reasons)
     twofish192-cbc   OPTIONAL          Twofish with 192-bit key
     twofish128-cbc   RECOMMENDED       Twofish with 128-bit key
     aes256-cbc       OPTIONAL          AES (Rijndael) in CBC mode,
                                        with 256-bit key
     aes192-cbc       OPTIONAL          AES with 192-bit key
     aes128-cbc       RECOMMENDED       AES with 128-bit key Y
     serpent256-cbc   OPTIONAL          Serpent in CBC mode, with
                                        256-bit key
     serpent192-cbc   OPTIONAL          Serpent with 192-bit key
     serpent128-cbc   OPTIONAL          Serpent with 128-bit key
     arcfour          OPTIONAL          the ARCFOUR stream cipher
     idea-cbc         OPTIONAL          IDEA in CBC mode
     cast128-cbc      OPTIONAL          CAST-128 in CBC mode

Please, explain yourself.

I believe the biggest concern is a further delay of the drafts which
already have been delayed for several years.  None of the attacks that
have been discussed here seem relevant enough to warrant delaying the
drafts for another year.

We can always define more ciphers and modes once the main drafts have
been published.

Niels.

---

From: Markus Friedl <[email-masked]>
Date: Fri, 15 Mar 2002 09:57:36 +0100

> ciphers, which violates section 5 of the architecture spec. 

What versions of OpenSSH are you talking about?

About released versions?  Or about software that never left my laptop?

Well, who cares, I'm getting used to OpenSSH-FUD...

---

From: [email-masked] (Sami J. Lehtinen)
Date: 15 Mar 2002 12:20:19 +0200

> Well, who cares, I'm getting used to OpenSSH-FUD...

I think he is referring to our ssh, which has those modes for some
ciphers (they come with the crypto lib, specified as in IPSEC etc).
Sorry about that.

Anyway, I believe the core documents don't need this, as a draft for
additional modes is simple enough to do (as you demonstrated).

Cheers,
-- 
[email-masked]

---

From: Wei Dai <[email-masked]>
Date: Fri, 15 Mar 2002 18:24:35 -0800

> What versions of OpenSSH are you talking about?

My apologies, what I said above applies to the SSH implementation from SSH
Communications Security, not OpenSSH. 

> About released versions?  Or about software that never left my laptop?

I guess that mean you've implemented OFB mode ciphers for OpenSSH but have
not released it yet?

---

From: "Andersson, Mats" <[email-masked]>
Date: Sat, 16 Mar 2002 07:45:32 +0100 (CET)

On Fri, 15 Mar 2002, Wei Dai wrote:
> My apologies, what I said above applies to the SSH implementation from
> SSH Communications Security, not OpenSSH.
> 
> I guess that mean you've implemented OFB mode ciphers for OpenSSH but
> have not released it yet?

We've also got OFB mode in place (tested with SSH Inc. server).

Cheers,

/Mats

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 18 Mar 2002 10:20:40 -0500

[wg chair hat off]

I took the liberty of drafting a possible disclaimer for the CBC
attack.  Please send substantive comments regarding this text to this
list.

					- Bill

NOTE:

Nearly all ciphers specified in this document are used in cipher block
chaining (CBC) mode. It's been known for some time that CBC modes will
reveal information about the plaintext if two ciphertext blocks
encrypted under the same key are equal; this is one of the reasons
this document strongly recommends rekeying at least once per gigabyte
of data, to reduce the chance that a "birthday paradox" collision will
appear.

Recent research has uncovered a new attack on CBC mode which, under
certain conditions, allows a chosen plaintext attacker aware of the IV
for a forthcoming message to have some chance to artificially induce a
system into generating ciphertext collisions, allowing the attacker's
guesses at likely prior plaintexts to be confirmed.

Any protocol which uses CBC in a way which allows advance knowledge of
a message's IV (e.g., by using the last block of the preceding message
as the IV) might be vulnerable to this attack.

Preliminary analysis of this attack as applied to the SSH protocol
suggests that the protocol is actually fairly resistant to this
attack; while estimates vary, it appears that, on average, an attacker
would have to inject tens or hundreds of millions of chosen plaintexts
to confirm guesses on the value of a few unknown plaintexts.
	
While this attack involves less work than a brute-force attack on the
underlying cipher (and is thus a matter of some concern), it is also
likely to be significantly more difficult than attacks on other parts
of a system using the SSH protocol, and so is unlikely to be an
immediate risk to real-world systems.  Due to this document's
recommendation that rekeying occur once an hour, an attacker also has
a limited amount of time to complete any particular attack.

Nevertheless, work is underway to specify, in a separate document or
documents, additional cipher modes for the SSH protocol to address
this vulnerability.  Implementors should be prepared to add new
algorithms to their implementations as this work progresses.

---

From: Wei Dai <[email-masked]>
Date: Mon, 18 Mar 2002 17:54:43 -0800

> to confirm guesses on the value of a few unknown plaintexts.

I think this paragraph is not accurate. Specificly, the protocol itself is
not resistant, rather it's the current implementations that are somewhat
resistant, and the attacker does not have to inject tens of millions of
chosen plaintexts, he just needs to cause tens of millions of packets to
be sent, and do one chosen plaintext at the right moment.

> immediate risk to real-world systems.  

I don't think it's the case that the attack is unlikely to be an immediate
risk to real-world systems. On any particular system, it's probably not
the biggest hole, but it quite likely is the biggest hole on *some*
real-world systems.

> Due to this document's

I suggest rewording this section of the warning as follows:

Preliminary analysis of this attack as applied to the SSH protocol
suggests that current implementations of the protocol contain a number of
limitations which have the side effect of hindering the attack. As a
result the attacker must at least cause tens of millions of packets to be
sent over the same connection and encrypted with the same key before the
attack has a reasonable chance of success. Due to this document's
recommendation that rekeying occur once an hour, an attacker also has a
limited amount of time to complete any particular attack. 

While this attack involves less work than a brute-force attack on the
underlying cipher (and is thus a matter of some concern), it is also
likely to be significantly more difficult than attacks on other parts of a
system using the SSH protocol.

---

Also, I think we need to say something to the effect that once the new
modes are defined, CBC ciphers should be considered deprecated and no
longer REQUIRED or RECOMMENDED, so that future users are not confronted
with the choice of CBC mode.

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 19 Mar 2002 09:16:44 -0500

> resistant

I'm rephrasing to:

Preliminary analysis of this attack as applied to the SSH protocol
suggests that the protocol as implemented today is actually fairly
resistant to this attack...

> the attacker does not have to inject tens of millions of

I'll rephrase to:

.. on average, an attacker would need tens or hundreds of millions of
opportunities to inject chosen plaintexts to be encrypted with a known
IV to confirm guesses on the value of a few unknown plaintexts.

> On any particular system, it's probably not the biggest hole, but it
> quite likely is the biggest hole on *some* real-world systems.

I think you severely underestimate how many latent undiscovered
security holes are out there at the moment.. I don't think we have
*any* reason to believe that.

> Also, I think we need to say something to the effect that once the
> new modes are defined, CBC ciphers should be considered deprecated
> and no longer REQUIRED or RECOMMENDED, so that future users are not
> confronted with the choice of CBC mode.

It's premature to overconstrain the possible solutions.

We haven't decided on the fix.  If we choose to fix the problem by
introducing new ciphers, the document which specifies them can
deprecate the old ciphers.  We could investigate new ciphers,
determine we can't agree on the right ones, and fall back to fixing
the problem some other way (i.e., start each block of ciphertext with
an SSH_MSG_IGNORE).

						- Bill

---

From: Wei Dai <[email-masked]>
Date: Wed, 20 Mar 2002 20:24:07 -0800

> *any* reason to believe that.

Ok, let me rephrase that: it quite likely is the biggest *known* hole on
some real-world systems. The point remains that we can't be confident that
it's not a threat to any real world system.

> the problem some other way (i.e., start each block of ciphertext with

Regarding the parenthetical suggestion, I thought each SSH packet can
contain only one message. Is that incorrect?

---

From: Wei Dai <[email-masked]>
Date: Wed, 20 Mar 2002 21:33:09 -0800

> contain only one message. Is that incorrect?

I would still appreciate an answer to my question, but I now see that the
proposed fix works in either case. The sender could send two packets for
every normal message, the first one containing an SSH_MSG_IGNORE, and the
second one containing the actual message.

Following a suggestion David Hopwood posted to IETF-TLS, it seems a good
idea to implement this workaround for CBC mode in any case, so that at
least one direction of the connection is protected against the
predictable-IV attack even if the other side has not implemented the final
fix.

---

From: [email-masked] (Niels Möller)
Date: 21 Mar 2002 13:11:43 +0100

> contain only one message. Is that incorrect?

That's right, but if the implementation does some buffering, i.e.
assembles a sequence on n packets

  P_1, P_2, ... P_n

before the first packet (in encrypted form) is sent across the
network, then I beleive packets P_2 ... P_n are not susceptible to the
known iv attacks: Their contents is fixed before the attacker learns
their iv:s. So if you make sure that each such sequence of packets
starts with an SSH_MSG_IGNORE packet P_0, no other packets have their
iv:s known in advance.

This solution is impractical in my implementation, as I buffer the
data to be written later, after encryption, so I hope we can find
other solutions. Adding SSH_MSG_IGNORE at the end of the sequence is
easier, and I'm considering doing that, to make traffic analysis
harder.

(And furthermore, the sequence of packets above need not correspond at
all to actual ip-packets: ssh-packet boundaries and ip-packet
boundaries are independent. For instance, one could arrange that every
ip-packet that is transmitted starts and ends with a partial
SSH_MSG_IGNORE packet, and as the length fields are encrypted. That
would make it hard for an attacker to even see the ssh-packet
boundaries).

/Niels

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 21 Mar 2002 09:06:28 -0500

> their iv:s. 

For what it's worth, this matches my analysis.

						- Bill

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 21 Mar 2002 11:58:02 -0500

On Wednesday, March 20, 2002, at 11:24 , Wei Dai wrote:

> some real-world systems.

I actually think that your revised claim is extremely unlikely
to be the case.  In particular, "known" and "widely known" aren't
the same.  Also, several of us are not convinced your issue is
a "big known hole", though I think everyone considers it a serious
issue.

> The point remains that we can't be confident that it's not
> a threat to any real world system.

No one has said made the claim that you knock down.  This thread
is about risk management, not whether we think the current SSH spec
is perfectly secure.  Delaying the spec over this level of nit
is not a responsible posture for the WG, IMHO, given that we can
change the attacker's work function from [wiretap cleartext passwords]
to [computationally expensive cryptographic attack] by moving
forward as-is today.

I fully support Bill's proposed language and shipping the documents
as Proposed Standard as soon as possible.

Ran
[email-masked]

---

From: "Joseph Galbraith" <[email-masked]>
Date: Thu, 21 Mar 2002 10:02:46 -0700

> as Proposed Standard as soon as possible.

Ditto.  Lets ship 'em.

- Joseph