Re: IESG feedback on core drafts.

[Chris Lonvick <clonvick%cisco.com@localhost>]

Hi,

My attempts at resolution in-line.  I will note that I make no claim to
cryptographic abilities.  I've merely tried to work Joseph's thoughts
into a hopefully more palatable contribution.  :-)


On 29 Mar 2003, Eric Rescorla wrote:

> Some detailed comments,
>
> "Joseph Galbraith" <galb-list%vandyke.com@localhost> writes:
> >    So long as the "none" cipher is not used, this protocol
> >    provides confidentiality.  Older, smaller ciphers, such
> Why do you say "smaller". How is 3DES smaller than AES?
>
> >    as 3des and arcfour MAY be less secure from attack than
> >    ciphers such as AES.  Implementors SHOULD prefer ciphers
> >    such as twofish, serpent, or AES over blowfish, 3des and
> >    arcfour.
> Why would you recommend twofish and serpent over 3DES?
> 3DES has received vastly more analysis than either.

Replace with:

   It is beyond the scope of this document and the Secure Shell Working
   Group to analyze or recommend specific ciphers other than the ones
   which have been established and accepted within the industry.  At the
   time of this writing, ciphers commonly in use include 3DES, ARCFOUR,
   twofish, serpent and blowfish.  AES has been accepted by cryptographic
   experts as being stronger than most of the other ciphers in use today
   and it is being implemented in other security protocols as it is within
   SSH.  As always, implementors and users should check current literature
   to ensure that no recent vulnerabilities have been found in ciphers used
   within products.  Implementors should also check to see which ciphers
   are considered to be relatively stronger than others and should
   recommend their use to users over relatively weaker ciphers.  It would
   be considered good form for an implementation to politely and
   unobtrusively notify a user that a stronger cipher is available and
   should be used when a weaker one is actively chosen.  Implementors may
   wish to offer relatively weaker ciphers in their products for
   interoperability but should strive to depricate them as soon as
   possible.

   The "none" cipher is provided for debugging and should never be used
   except for that purpose.  It's cryptographic properties are
   sufficiently described in RFC 2410.

[This last part should probably be worked into the preceding paragraph in
Joseph's original proposal - paragrph 1 of section 11.1.]

>
> >    With ciphers operating in CBC mode is theoretically
> >    vulnerable to choosen cipher-text attacks because of
> >    the high predicability of the start of packet sequence.
> >    However, this attack is still relatively hard enough, and
> >    requires a sufficiently high number of packets, to be safe
> >    in the short term.  Ciphers with larger block sizes are
> >    less vulnerable the ciphers with smaller block sizes.
> >    [Is this true?]
> What attack are you talking about here? The Rogaway attack?
> Perhaps you need a citation and some explanation?

Replace with:

   The relative merits of these and other ciphers may also be found in
   current literature.  Two references that may provide information on the
   subject are [SCHNEIER] and [KAUFMAN,PERLMAN,SPECINER].  Both of these
   describe the CBC mode of operation of certain ciphers and the weakness
   of this scheme.  Essentially, this mode is theoretically vulnerable to
   chosen cipher-text attacks because of the high predictability of the
   start of packet sequence.  However, this attack is still deemed
   difficult and not considered fully practicable especially if relatively
   longer block sizes are used.

   [SCHNEIER] Applied Cryptography, Second Edition, Bruce Schneier, Wiley
   and Sons Publisher, 1996

   [KAUFMAN,PERLMAN,SPECINER] Network Security; PRIVATE Communication in
   a PUBLIC World, Charlie Kaufman, Radia Perlman, Mike Speciner, Prentice
   Hall Publisher, 1995


>
>
> >    Effort is underway to standardize the use of CTR mode
> >    ciphers in the SSH protocol.  When this work is completed,
> >    implementors SHOULD support it.
> >
> >    In addition, the CBC mode attack can be mitigated by
> >    ensuring the an SSH_MSG_IGNORE packet preceeds any real
> >    data at the start of a TCP packet.
> A TCP packet? How is the TCP mapping relevant?

   Additionally, the CBC mode attack may be mitigated through the
   insertion of packets containing SSH_MSG_IGNORE.  This technique may be
   used to obfuscate the relative positions of the enciphered message and
   its use is encouraged.  Beyond that, an effort is currently underway to
   standardize the use of the CTR mode of operation in ciphers used in the
   SSH protocol.  When that work is completed, implementors SHOULD support
   it as that will obviate the CBC mode attack.


>
> >    Because MACs use a 32 bit sequence number, they may
> >    start to leak information after 2**32 packets have
> >    been sent.
> You should be specific here about how they leak data.
>
> > 11.1.3 Replay
> >
> >    This protocol binds each session key to the session
> >    by including random data that is specific to the
> >    session in the hash used to produce session keys.
> >
> >    This session id is used by higher level protocols
> >    to prevent replay of packets form previous sessions.
>                                   ^^^^
> from.
>
> >    In addition, the use of cipher chaining prevents
> >    replay of packets within the session.  Cipher chaining
> >    also prevents the insertion or deletion of packets.
> I'm not sure this is true if the MAC is disabled.
>
> > 11.3.2 Proxy forwarding
> >
> >    The ssh connection protocol allows proxy forwarding
> >    of other protocols.  The proxy forwarding functionality
> >    can be used to circumvent firewall protections.  Implementors
> >    SHOULD provide a mechanism to disable to administratively
> >    control the proxy forwarding funcitonality.
> This sentence is ungrammatical.

Replace with:

   The SSH connection protocol allows for proxy forwarding of other
   protocols such as SNMP, POP3, and HTTP.  This may be a concern for
   network administrators who wish to control the access of certain
   applications by users located outside of their physical location.
   Essentially, the forwarding of these protocols may violate site
   specific security policies as they may be undetectably tunneled
   through a firewall.  Implementors SHOULD provide an administrative
   mechanism to control the proxy forwarding functionality so that
   site specific security policies may be upheld.


>
> -Ekr
>
> --
> [Eric Rescorla                                   ekr%rtfm.com@localhost]
>                 http://www.rtfm.com/
>


Thanks,
Chris