Skip to main content

The Secure Shell (SSH) Transport Layer Encryption Modes
draft-ietf-secsh-newmodes-05

Yes

(Sam Hartman)

No Objection

(Alex Zinin)
(Allison Mankin)
(Bert Wijnen)
(Bill Fenner)
(David Kessens)
(Jon Peterson)
(Margaret Cullen)
(Mark Townsley)
(Scott Hollenbeck)
(Ted Hardie)

Note: This ballot was opened for revision 05 and is now closed.

Sam Hartman Former IESG member
(was Discuss, Yes) Yes
Yes () Unknown

                            
Alex Zinin Former IESG member
No Objection
No Objection () Unknown

                            
Allison Mankin Former IESG member
No Objection
No Objection () Unknown

                            
Bert Wijnen Former IESG member
No Objection
No Objection () Unknown

                            
Bill Fenner Former IESG member
No Objection
No Objection () Unknown

                            
Brian Carpenter Former IESG member
No Objection
No Objection (2005-09-01) Unknown
From Gen-ART review by Avri Doria:

Questions: 

1.  does SSH count as one of the acronyms that is so well known that
    it can be included in an abstract without expanding?  I tend to
    think so, but I bring up the question for completeness sake.

2. i assume the birthday property [BC: paradox] (3.2) is well know.  For the naive reader
   it might be good to have a reference to where this is explained.


Comments:

in 3  Last sentence:  the note is tantalizing but doesn't explain
  why it might be the case.  Since it is explained later in the document, it
  should at least have a forward xref to section 6.1.

3.1 Several SHOULDs and SHOULD NOTs without any explanation of why not
  MUST or MUST NOT.  Perhaps this is due to the note about one
  recommendation taking precedence over another recommendation, but
  it is not clear that is the case.  In seems that the
  discussion in in 6.1 is relevant, but that is rather far away from the
  requirements themselves.  Perhaps another forward xref would help.
David Kessens Former IESG member
No Objection
No Objection () Unknown

                            
Jon Peterson Former IESG member
No Objection
No Objection () Unknown

                            
Margaret Cullen Former IESG member
No Objection
No Objection () Unknown

                            
Mark Townsley Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
(was Discuss) No Objection
No Objection (2005-08-29) Unknown
  I think that the last paragraph of the Abstract belongs in the
  Introduction.
 
  Section 3.1 says:
  >
  > The preferred way to do this is to rekey after receiving more than
  > 2**31 packets since the last rekey operation.
  >
  I suggest:
  >
  > The preferred implementation technique is to use the reception of
  > more than 2**31 packets since the last rekey operation as a trigger
  > to rekey.

  Two comments about section 4:
   
  * The description of counter mode seems compatible with NIST SP 800-38A.
    A single counter is used here, instead of a counter for each packet,
    but that does not seem to be a problem.  Please reference NIST
    SP 800-38A.

  * The usual reference for Triple-DES is:
      [3DES]  American National Standards Institute. ANSI X9.52-1998,
              Triple Data Encryption Algorithm Modes of Operation. 1998.

  Section 6.2 says:
  >
  > Fortunately, the common concerns with counter mode do not apply to
  > SSH because of the rekeying recommendations and because of the
  > additional protection provided by the transport protocol's MAC.
  >
  This sentence should also include the built-in initial key
  establishment capability.
Scott Hollenbeck Former IESG member
No Objection
No Objection () Unknown

                            
Ted Hardie Former IESG member
No Objection
No Objection () Unknown