Subject: Re: additional core draft nits in need of WG attention.

From: [email-masked] (Peter Gutmann)
Date: Sun, 16 Nov 2003 00:24:54 +1300

[email-masked] (Niels =?iso-8859-1?q?M=F6ller?=) writes:

>Out of curiosity, which ciphers did you support at all? With only one or both
>of aes and des3 to choose from, assymetric choices doesn't make much sense.

{ "whatever the user has enabled" union "3des, aes, blowfish, cast, idea" }
alongside any custom algorithms the user (meaning the person who built the
code) has added.  For example the user may have disabled IDEA due to patent
concerns, so cryptlib wouldn't advertise that as available, or may have
enabled some other algorithm of their choice which isn't one of the built-in
defaults.  Out of the box though it's the above five, that's all of the
mainstream ciphers covered.

(Hmm, I just saw RC4 buried down under Serpent there, I could switch that on
as well now that I've noticed it's in the list :-).

>Or will it enforce that the *input* to the selection processing is symmetric,
>i.e. that in the KEXINIT message,
>
>  encryption_algorithms_client_to_server
>     == encryption_algorithms_server_to_client
>
>  mac_algorithms_client_to_server
>     == mac_algorithms_server_to_client

That's what I do, and from the error message I got when I accidentally didn't
do it, at least one other implementation does that too.

>If we really want to get rid of this possibility, the cleanest and least
>confusing way of doing it would be to define protocol version 2.1 with a
>changed KEXINIT format,

I don't really know if such a big change is necessary, just discouraging the
use of asymmetric choices (which shouldn't be hard given that nothing (?) does
it at the moment, so any attempt to implement it will fail to interop) should
be enough.  No need to break things.

>I'm always confused when a spec allows flexibility which, for good or bad and
>perhaps undocumented reasons, noone implements.

I guess I've been polluted by too long with PKIX RFCs, there are so many MUSTs
in there that you need to ignore in order to get things to work it's scary.

Peter.

---

From: Bill Sommerfeld <[email-masked]>
Date: Sat, 15 Nov 2003 10:57:58 -0500

> I don't really know if such a big change is necessary, just
> discouraging the use of asymmetric choices (which shouldn't be hard
> given that nothing (?) does it at the moment, so any attempt to
> implement it will fail to interop) should be enough.  No need to
> break things.

The proposal during the WG session was that we should add text so that
for both algorithms and language tags, the negotiated value SHOULD be
the same in both directions.  I'll send a more precise recommended
edit in the next day or two..

Note the RFC2119 definition of SHOULD:
   
   3. SHOULD   This word, or the adjective "RECOMMENDED", mean that
   there may exist valid reasons in particular circumstances to ignore
   a particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

Note that this is somewhat stronger than the plain-english meaning of
SHOULD.

Given the current state of the documents (near approval by the IESG),
I'm extremely reluctant to make a larger change at this point.

We can revisit this issue when we move beyond Proposed Standard.

(The process for advancement to Draft Standard requires that we
document that all of the protocol features interoperate.  if nobody
has actually implemented asymmetric algorithms, we can strike it at
that point).

					- Bill

P.S., There are certainly a few obscure applications where it makes
sense to use different algorithms in each direction.  One which comes
to mind is the case of a remote sensor/space probe/etc., where the
"uplink" is low data-rate management/control traffic, where strong
integrity protection is required to prevent the probe from being
hijacked, and the "downlink" is a higher-volume, lower-value data
stream, where weak integrity protection may be sufficient.

---

From: Markus Friedl <[email-masked]>
Date: Sat, 15 Nov 2003 17:27:13 +0100

> I'm extremely reluctant to make a larger change at this point.

I don't like the idea of changing anything at this point.

The documents have been around for years and if this
issue is was important then someone whould have
complained before.

(I even think that allowing asymmetric algorithms
leeds to better implementations, because they
have to be more careful.)

> has actually implemented asymmetric algorithms, we can strike it at

OpenSSH might support this.

> stream, where weak integrity protection may be sufficient.

Well, you could also send the request, rekey with different
algorithms, send the reply, rekey again, ...

---

From: Paul Swartz <[email-masked]>
Date: Sat, 15 Nov 2003 11:50:00 -0500

> OpenSSH might support this.

I know Conch does support this.

> algorithms, send the reply, rekey again, ...

...because renegotiating keys is more efficient than using assymetric
ciphers...

-p
-- 
      Paul Swartz
(o_   z3p at twistedmatrix dot com
//\   http://www.twistedmatrix.com/users/z3p.twistd/
V_/_  AIM: Z3Penguin

---

From: [email-masked] (Niels Möller)
Date: 15 Nov 2003 17:55:03 +0100

Bill Sommerfeld <[email-masked]> writes:

> for both algorithms and language tags,

Why language tags? I think assymmetric choices make a lot of sense:
For example, sending Swedish messages from server to client (because
that's the user's native and preferred language, but default language
or English (because these messags will end up in the server log, and
the sysadm doesn't read Swedish, or because the client doesn't
implement any localization for messages it sends to the server).

And furthermore, implementations that want to take the easy way can
just send an empty language list and ignore whatever is received, so
they gain no simplicity by the ban on assymmetric language lists.

And what about compression? Should support for assymetric choices for
compression be required?

> the negotiated value SHOULD be the same in both directions.

I think it's a lot better to say that the lists in the KEXINIT
message, i.e. the *input* to the negotiation, SHOULD be the same for
both directions.

It makes no sense to say that implementations MUST go to the
trouble[1] of performing independent algorithm selection for both
directions, and then say that they are allowed, and even recommended,
to sometimes refuse to use the result. The point of discouraging
assymetric choices should be to make things simpler for the
implementations.

I'm still uneasy about this issue. I believe it is a *minor* trouble
to implement assymetric choices. But since I have to admit that I
don't implement any way for the user to configure assymmetric choices,
and therefore haven't tested it at all, I can agree that it's not an
essential feature.

I think I'd prefer to keep the feature, and perhaps add some text that
allows implementations to refuse to accept KEXINIT messages with
assymetric algorithm lists for encryption and authentication.
Something like

  The ciphers in each direction MUST run independently of each other,
  and implementations SHOULD/MAY allow independently choosing the
  algorithm for each direction (if multiple algorithms are allowed by
  local policy).

  Implementations MAY choose to not support independent algorithm
  choices for the two directions. In this case it MUST check that

  in all received SSH_MSG_KEXINIT messages. If the lists differ, the
  implementation MUST send a SSH_MSG_DISCONNECT message with reason
  code SSH_DISCONNECT_KEY_EXCHANGE_FAIL and a proper explanation.

  Implementations SHOULD send SSH_MSG_KEXINIT messages with

  unless they have been explicitly configured to behave differently.

and similarly for authentication methods, but *not* for language tags
or compression algorithms. The essence of this is to

  (i) make support for assymmetric choices an optional feature,

  (ii) to specify how the protocol should work if the feature is not
       implemented, and finally,

  (iii) say that implementations shouldn't use the feature unless
        there's a good reason to use it, for example "the user said
        so".

/Niels

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 16 Nov 2003 22:53:26 -0800

> implement any localization for messages it sends to the server).

Neither list of lang tags has anything to do with with logs on the
server.

The lists supposedly represent the languages that the client and server
can have the user "speak at" the server and the languages that the
client and server can "speak at" the user - the latter refers to L10N of
server messages for the user and the former refers to, to what?  to the
language that the user is willing to answer prompts in??.  (Logs just
don't enter into this.)

Now, why would I want to have the server localize messages for me in one
language but accept, from me, answers to [yes/no, ...] prompts in some
other language??  Is there an assumption that servers may have
incomplete L10N support for certain languages?  If so, still, why a
second list of language tags?  Or is there an assumption that users
could be really tricky and prefer one language for reading and another
for typing?  Now, we humans do weird things, so I suppose this could be,
but I'd like to see some examples.

On Solaris, in any case, there isn't much we can do with this language
assymetry, though one can play some games.  E.g., client2server langs ->
LC_CTYPE setting and server2client langs -> LC_MESSAGES setting.  But
really, is this worth it?

> they gain no simplicity by the ban on assymmetric language lists.

Some implementors don't have a choice and have to implement what G11N
features the protocols provide due to regulations, internal or
otherwise.  Such implementors will gain something from at least a
clarification on what the hell assymetric langtag negotiation really
means.

[...]
> message, i.e. the *input* to the negotiation, SHOULD be the same for

I agree with this.  But if we find no theoretical use for assymetric
langtag negotiation that we wish to support I would consent to
deprecating one of the two langatg list fields.

> assymetric choices should be to make things simpler for the

For langtag negotiation it may make sense to ignore the negotiation for
one of the directions.  See above.

Cheers,

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 17 Nov 2003 18:46:51 -0500

> message, i.e. the *input* to the negotiation, SHOULD be the same for

Actually, that was my interpretation of what was said during the working 
group meeting.  It seems to me that requiring or recommending that the 
foo_client_to_server and foo_server_to_client fields of the KEXINIT message 
contain the same list is the only sane way to describe this requirement.

---

From: Damien Miller <[email-masked]>
Date: Tue, 18 Nov 2003 12:54:32 +1100

> contain the same list is the only sane way to describe this requirement.

I don't agree.

It is reasonable for a server to be willing to accept compressed data,
but refuse to send it (decompression being generally less CPU intensive
than compression). I.e. comp_c_to_s "zlib, none", comp_s_to_c "none"

Likewise a server may be happy to encrypt data to clients with a less
secure, but faster cipher whilst requiring that clients send their
information (especially the auth transactions) with a stronger, slower
cipher. An extreme case would be the use of the "none" cipher in the
s->c direction (though OpenSSH doesn't support "none").

Bidirectional algorithms have been in the spec for years (without
complaint) and are supported by a number of implementations. Why is it
that these objections are always raised at the 11th hour?

I don't think the draft should be changed. Implementors who don't like
the idea of bidirectional algorithms are free to disallow them in their
implementation.

-d

---

From: Damien Miller <[email-masked]>
Date: Tue, 18 Nov 2003 13:16:52 +1100

> Bidirectional algorithms have been in the spec for years (without

s/Bidirectional/assymetric/ if there is any ambuiguity.

-d

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 17 Nov 2003 21:29:05 -0500

> s/Bidirectional/assymetric/ if there is any ambuiguity.

well, I've seen "assymetric algorithms" used to refer to public key
algorithms...

						- Bill

---

From: [email-masked] (Niels Möller)
Date: 18 Nov 2003 11:13:13 +0100

Damien Miller <[email-masked]> writes:

> Implementors who don't like the idea of bidirectional algorithms are
> free to disallow them in their implementation.

I don't think this is correct. The only way an implementation can
disallow assymetric choices of encryption algorithms, and at the same
time be compliant to the current draft, is by never ever advertising
algorithm lists with more than a single element.

*If* you really want to allow implementations to drop support for
assymetric algoririthm choices, then you need to change the spec.

/Niels