Re: Proposed Meeting Discussion Items for the Core IDs

[nisse%lysator.liu.se@localhost (Niels Möller)]

Chris Lonvick <clonvick%cisco.com@localhost> writes:

> On Sun, 7 Nov 2004, [iso-8859-1] Niels Möller wrote:
> 
> > Some of the issues have already been discussed at some length on the
> > list.
> 
> 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?

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 <200311100712.hAA7CAS4004431%thunk.east.sun.com@localhost>.

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

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

>From Bill:

: From: Bill Sommerfeld <sommerfeld%east.sun.com@localhost>
: Subject: Re: additional core draft nits in need of WG attention. 
: To: nisse%lysator.liu.se@localhost (Niels Möller)
: Cc: ietf-ssh%NetBSD.org@localhost, Russ Housley <housley%vigilsec.com@localhost>
: Date: Tue, 11 Nov 2003 10:31:10 -0500
: Reply-To: sommerfeld%east.sun.com@localhost
: 
: > > 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

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

: From: Bill Sommerfeld <sommerfeld%east.sun.com@localhost>
: Subject: (LAST CALL) Re: Implicit server authentication: Proposed clarification
: To: nisse%lysator.liu.se@localhost (Niels Möller)
: Cc: Joseph Galbraith <galb-list%vandyke.com@localhost>,
: 	Jeffrey Hutzelman <jhutz%cmu.edu@localhost>,
: 	Peter Gutmann <pgut001%cs.auckland.ac.nz@localhost>, housley%vigilsec.com@localhost,
: 	ietf-ssh%NetBSD.org@localhost
: Date: Fri, 19 Dec 2003 13:08:05 -0500
: Reply-To: sommerfeld%east.sun.com@localhost
: 
: [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).

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

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 <sommerfeld%east.sun.com@localhost>
: Subject: additional core draft nits in need of WG attention.
: To: ietf-ssh%netbsd.org@localhost
: Cc: Russ Housley <housley%vigilsec.com@localhost>
: Date: Mon, 10 Nov 2003 02:12:10 -0500
: Reply-To: sommerfeld%east.sun.com@localhost
: 
: 
: 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 <sommerfeld%east.sun.com@localhost>
: Subject: Re: additional core draft nits in need of WG attention. 
: To: pgut001%cs.auckland.ac.nz@localhost (Peter Gutmann)
: Cc: nisse%lysator.liu.se@localhost, ietf-ssh%NetBSD.org@localhost
: Date: Sat, 15 Nov 2003 10:57:58 -0500
: Reply-To: sommerfeld%east.sun.com@localhost
: 
: > >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 <markus%openbsd.org@localhost>
: Subject: Re: additional core draft nits in need of WG attention.
: To: Peter Gutmann <pgut001%cs.auckland.ac.nz@localhost>
: Cc: ietf-ssh%NetBSD.org@localhost
: 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