The Secure Shell (SSH) Transport Layer Encryption Modes
draft-ietf-secsh-newmodes-05
Yes
No Objection
Note: This ballot was opened for revision 05 and is now closed.
(Sam Hartman; former steering group member) (was Discuss, Yes) Yes
(Alex Zinin; former steering group member) No Objection
(Allison Mankin; former steering group member) No Objection
(Bert Wijnen; former steering group member) No Objection
(Bill Fenner; former steering group member) No Objection
(Brian Carpenter; former steering group member) No Objection
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 steering group member) No Objection
(Jon Peterson; former steering group member) No Objection
(Margaret Cullen; former steering group member) No Objection
(Mark Townsley; former steering group member) No Objection
(Russ Housley; former steering group member) (was Discuss) No Objection
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 steering group member) No Objection
(Ted Hardie; former steering group member) No Objection