Subject: Proposed Meeting Discussion Items for the Core IDs

From: Chris Lonvick <[email-masked]>
Date: Sun, 7 Nov 2004 10:22:03 -0800 (PST)

Hi,

I've asked for a few minutes at the meeting to review the core IDs and to
close some of our open tickets.  Please look over these slides and come
prepared to discuss.  Hopefully we can close a bunch of these and open
discussion for the rest.

  http://www.employees.org/~lonvick/secsh-wg/ietf61/secshwg.pdf

Thanks,
Chris

---

From: [email-masked] (Niels Möller)
Date: 07 Nov 2004 20:07:17 +0100

Chris Lonvick <[email-masked]> writes:

> Hopefully we can close a bunch of these and open
> discussion for the rest.
> 

Some of the issues have already been discussed at some length on the
list.

Ticket 454: triple-des have too few key bits. I think we had consensus
to "grandfather" triple-des, however that's going to be expressed in
the spec. I.e. just note that triple-des doesn't quite satisfy the
requirements, and allow this exception for historical reasons and
backwards compatibility. I don't think it's a good idea to lower the
general recommendation on key length from 128 to 96 bits.

Ticket 461: "implicit server authentication". This has been discussed
on the list, we may even have had some proposed text.

Ticket 462: discouraging use of different algorithm for the two
directions. This has been discussed at length, I argued that it should
be allowed and up to local configuration, I don't remember who else
agreed with that.

I won't be at the meeting, but I think these three issues have been
discussed thoroughly enough on the list already, so I hope you can get
something more concrete out of the RL meeting than sending the issues
back to the mailinglist for another round.

Best regards,
/Niels

---

From: Chris Lonvick <[email-masked]>
Date: Sun, 7 Nov 2004 14:48:31 -0800 (PST)

Hi Niels,

> Some of the issues have already been discussed at some length on the

Super!  I'd prefer to track them down in the archives rather than re-hash
things.  They must have been discussed before I took over as editor.
Does anyone have any pointers to these discussions and resolutions?  If
not, I'll start digging through the archive but I won't be able to get to
it for a few weeks.

Thanks,
Chris

---

From: [email-masked] (Niels Möller)
Date: 08 Nov 2004 11:31:54 +0100

Chris Lonvick <[email-masked]> writes:

> Does anyone have any pointers to these discussions and resolutions?

The relevant discussion thread seems to be the "additional core draft
nits in need of WG attention.", starting with a message by Bill
Sommerfield, Mon, 10 Nov 2003 02:12:10 -0500, almost exactly one year
ago. Message-id <[email-masked]>.

I'm including a selection of messages from back then, to try to
summarize the discussion. This is naturally my view of the discussion;
I haven't carefully reread *all* of the discussion, and I may have
missed some disagreeing voices. The relevant archive files seems to be
ftp://ftp.ietf.org/ietf-mail-archive/secsh/2003-11.mail and
ftp://ftp.ietf.org/ietf-mail-archive/secsh/2003-12.mail

> > general recommendation on key length from 128 to 96 bits.

From Bill:

: From: Bill Sommerfeld <[email-masked]>
: Subject: Re: additional core draft nits in need of WG attention. 
: To: [email-masked] (Niels Möller)
: Cc: [email-masked], Russ Housley <[email-masked]>
: Date: Tue, 11 Nov 2003 10:31:10 -0500
: Reply-To: [email-masked]
: 
: > > I see a kernel of consensus building for:
: > >  - leave recommended limit at 128 bits
: > >  - explicitly grandfather 3DES
: > 
: > Exactly what does "grandfather" mean here? Change 3DES from REQUIRED
: > to RECOMMENDED? Or OPTIONAL? Or DEPRECATED? 
: 
: My apologies for using an Americanism here.
: 
: "Grandfathering" something means roughly "keep it is, despite not
: (precisely) matching the letter of a newer spec/law/regulations/etc,
: because we've always done it that way".
: 
: So, that would be "keep as REQUIRED".
: 					- Bill

> > on the list, we may even have had some proposed text.

: From: Bill Sommerfeld <[email-masked]>
: Subject: (LAST CALL) Re: Implicit server authentication: Proposed clarification
: To: [email-masked] (Niels Möller)
: Cc: Joseph Galbraith <[email-masked]>,
: 	Jeffrey Hutzelman <[email-masked]>,
: 	Peter Gutmann <[email-masked]>, [email-masked],
: 	[email-masked]
: Date: Fri, 19 Dec 2003 13:08:05 -0500
: Reply-To: [email-masked]
: 
: [Sorry for the delay in dealing with this loose end.]
: 
: Seeing no further followup to this thread, I'm going to suggest a
: slight modification to Niels's text:
: 
: He wrote:
:    All currently defined key exchange methods use explicit server
:    authentication.  
: 
: This is a little vague for my tastes; I'd say 
: 
:    The key exchange method defined in this documents use explicit server 
:    authentication.
: 
: .. and then have dh-group-exchange and gsskeyex say the same..
: 
: This makes the change the following:
: 
: Before:
: 
:    Server authentication in the key exchange MAY be implicit.  After a
:    key exchange with implicit server authentication, the client MUST
:    wait for response to its service request message before sending any
:    further data.
: 
: After:
: 
:    A key exchange method uses "explicit server authentication" if the
:    key exchange messages include a signature or other proof of the
:    server's authenticity.  A key exchange method uses "implicit server
:    authentication" if, in order to prove its autenticity, the server
:    also has to prove that it knows the shared secret K, by sending a
:    message and a corresponding MAC which the client can verify. [1]
: 
:    The key exchange method defined by this document uses explicit server 
:    authentication.  However, key exchange methods with implicit server
:    authentication MAY be used with this protocol.  After a key exchange
:    with implicit server authentication, the client MUST wait for
:    response to its service request message before sending any further
:    data.
: 
: Please send comments on this proposed change to the WG list by Monday,
: January 4th, 2004.
: 
: 					- Bill

(The "[1]" at the end of one of the paragraphs should be deleted).

> > be allowed and up to local configuration, I don't remember who else

There were quite a lot of discussion about this, and I'm not sure what
we reached any concensus. A few relevant messages from the discussion:

: From: Bill Sommerfeld <[email-masked]>
: Subject: additional core draft nits in need of WG attention.
: To: [email-masked]
: Cc: Russ Housley <[email-masked]>
: Date: Mon, 10 Nov 2003 02:12:10 -0500
: Reply-To: [email-masked]
: 
: 
: transport draft:
: 
: > >5.  Section 4. SSH allows the client and server to employ different
: > >algorithms for the data that they encrypt. This practice should be
: > >discouraged somewhere in the document.  It is likely to cause
: > >interoperability problems, and it offers no security advantage.
: 
: [this is section 5 in version -17]
: 
: suggested resolution:
: 
: immediately after this text:
: 
:    The ciphers in each direction MUST run independently of each other,
:    and implementations MUST allow independently choosing the algorithm
:    for each direction (if multiple algorithms are allowed by local
:    policy.
: 
: insert:
: 
:    Note that there is no security advantage to using different
:    algorithms in each direction; implementations SHOULD use the same
:    algorithm in both directions when allowed by policy.
: [...]

: From: Bill Sommerfeld <[email-masked]>
: Subject: Re: additional core draft nits in need of WG attention. 
: To: [email-masked] (Peter Gutmann)
: Cc: [email-masked], [email-masked]
: Date: Sat, 15 Nov 2003 10:57:58 -0500
: Reply-To: [email-masked]
: 
: > >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.
: 
: 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]>
: Subject: Re: additional core draft nits in need of WG attention.
: To: Peter Gutmann <[email-masked]>
: Cc: [email-masked]
: Date: Mon, 17 Nov 2003 09:37:16 +0100
: 
: On Mon, Nov 17, 2003 at 02:06:20PM +1300, Peter Gutmann wrote:
: > >In IPsec the algorithms are unidirectional.  Why should it be a SHOULD for
: > >SSH?
: > 
: > In TLS the algorithms are bidirectional.  Why should it not be a SHOULD for
: > SSH?
: 
: Why should the SSH spec be changed again and again?  It's been like
: this for about 7 years.

Best regards,
/Niels

---

From: "denis bider" <[email-masked]>
Date: Mon, 8 Nov 2004 16:20:29 +0100

I find the below wording still confusing.

What's the idea of waiting for the server's response to the service request?
What is it for? If the server has already proven that it knows the shared
secret K by sending a corresponding MAC, which the client has, if I assume
correctly, verified - what gives? Why the "MUST" wait for the response to
the service request?

I'm probably lacking background here to understand this, but if I lack the
background after working in SSH for years, this will also be a mystery to
new implementors. I'd like this to be clear and explicit enough at least for
me to understand it.

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 08 Nov 2004 11:59:07 -0500

> new implementors. I'd like this to be clear and explicit enough at least for

The server authentication is "implicit" because the client doesn't know
whether the server successfully did its part of the key exchange until
the client receives a subsequent message from the server, not part of
the key exchange, which demonstrates knowledge of K by the server.

(Kerberos can be used this way)

> :    A key exchange method uses "implicit server

I'd suggest changing "by sending a message" to "by sending a subsequent
message"

					- Bill