[TLS] draft-ietf-tls-rfc4346-bis-09 LC comments (2)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[TLS] draft-ietf-tls-rfc4346-bis-09 LC comments (2)
Hello,
as promised last week, I'd like to submit the second part of my
LC comments on the I-D edited by you, draft-ietf-tls-rfc4346-bis-09.
For ease of reference, I continue the item numbering from
the first part, msg-id <200802221143.MAA13458 at TR-Sys.de>,
and occasionally include by reference rationale explained there.
(8) Section 7.3
The 4th paragraph below the bulleted list contains a typo:
Following the hello messages, the server will send its certificate,
if it is to be authenticated. Additionally, a server key exchange
| message may be sent, if it is required (e.g., if their server has no
^^
certificate, or if its certificate is for signing only). [...]
---
Following the hello messages, the server will send its certificate,
if it is to be authenticated. Additionally, a server key exchange
| message may be sent, if it is required (e.g., if the server has no
certificate, or if its certificate is for signing only). [...]
(9) Section 7.4.1.2
(9a) Outdated time base
In the initial part of this section, the draft still uses the outdated
time base, GMT, which hase been superseeded by UTC long ago.
I acknowledge that the names of the protocol elements should not
be changed for backwards compatibility, but I strongly suggest to
used UTC in the prose, and explaining the background in a short note.
Thus, I propose tyo change:
gmt_unix_time
The current time and date in standard UNIX 32-bit format
| (seconds since the midnight starting Jan 1, 1970, GMT, ignoring
^^^
leap seconds) according to the sender's internal clock. Clocks
are not required to be set correctly by the basic TLS Protocol;
higher-level or application protocols may define additional
requirements.
---
gmt_unix_time
The current time and date in standard UNIX 32-bit format
| (seconds since the midnight starting Jan 1, 1970, UTC, ignoring
leap seconds) according to the sender's internal clock. Clocks
are not required to be set correctly by the basic TLS Protocol;
higher-level or application protocols may define additional
| requirements. Note that, for historical reasons, the data
| element is named using GMT, the predecessor of the current
| world-wise time base, UTC.
(9b) explanation of ClientHello field: session_id
Please correct the typo:
session_id
The ID of a session the client wishes to use for this connection.
| This field is empty if no session_id is available, or it the
client wishes to generate new security parameters.
--- ^^
session_id
The ID of a session the client wishes to use for this connection.
| This field is empty if no session_id is available, or if the
client wishes to generate new security parameters.
^^
(9c) explanation of ClientHello field: compression_methods
For clarity (and conformance to RFC-Ed style), please add a comma:
compression_methods
This is a list of the compression methods supported by the client,
sorted by client preference. If the session_id field is not empty
| (implying a session resumption request) it MUST include the
compression_method from that session. [...]
---
compression_methods
This is a list of the compression methods supported by the client,
sorted by client preference. If the session_id field is not empty
| (implying a session resumption request), it MUST include the
compression_method from that session. [...]
(10) Section 7.4.1.3
In the explanation of the ServerHello field: session_id ,
I suggest adding the definite article in the last sentence,
for the sake of consistency in the style used almost everywhere
throughout the document:
| [...]. Client MUST be prepared to do a full negotiation --
including negotiating new cipher suites -- during any handshake.
--- vvvvv
| [...]. The client MUST be prepared to do a full negotiation --
including negotiating new cipher suites -- during any handshake.
(11) Section 7.4.1.4
(11a) Proactive consistency with upcoming FIPS PUB 186-3
The draft defines:
enum {
none(0), md5(1), sha1(2), sha256(3), sha384(4),
sha512(5), (255)
} HashAlgorithm;
The current and the recent draft version of the SHS also defines
SHA-224 and the draft version of the DSS [DSS-3] also makes
provisions for using SHS-224 with all signature algorithms
specified there (DAS, RSA, and ECDSA), subject to (key) size
restrictions; in particular, FIPS PUB 186-3 allows the use of SHA-224
for DSA with L=2048. The new version of TLS should align with this
upcoming standard as far as practical.
Therefore,
I strongly suggest to immediately assign a HashAlgorithm code point
for SHA-224 and not defer this action to a separate document:
enum {
| none(0), md5(1), sha1(2), sha224(TBA), sha256(3), sha384(4),
sha512(5), (255)
} HashAlgorithm;
^^^^^^^^^^^^^
(11b) explanation of the signature field
For completeness and consistency with the definition of the
SignatureAlgorithm,
enum { anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) }
SignatureAlgorithm;
... I suggest to also mention the ECDSA alternative there:
signature
This field indicates the signature algorithm which may be used.
The values indicate anonymous signatures, RSASSA-PKCS1-v1_5
| [PKCS1] and DSA [DSS] respectively. The "anonymous" value is
meaningless in this context but used in Section 7.4.3. It MUST NOT
appear in this extension.
---
signature
This field indicates the signature algorithm which may be used.
The values indicate anonymous signatures, RSASSA-PKCS1-v1_5
| [PKCS1], and DSA or ECDSA [DSS] respectively. The "anonymous"
^ ^^^^^^^^^
value is meaningless in this context but used in Section 7.4.3.
It MUST NOT appear in this extension.
(11c) missing articles and clarification
For consistency in style and garmmar, I suggest inserting one instance
of "the" in the subsequent paragraph:
The semantics of this extension are somewhat complicated because the
cipher suite indicates permissible signature algorithms but not hash
algorithm. Sections 7.4.2 and 7.4.3 describe the appropriate rules.
---
The semantics of this extension are somewhat complicated because the
| cipher suite indicates permissible signature algorithms but not the
^^^^
hash algorithm. Sections 7.4.2 and 7.4.3 describe the appropriate
rules.
Similarly, in the next paragraph I suggest inserting another "the"
and perform another small clarifications:
: [...]. If the client does not support the default algorithms, or
^^^
supports other hash and signature algorithms (and it is willing to
| use them for verifying messages sent by server; server certificates
^
and server key exchange), it MUST send the signature_algorithms
| extension listing the algorithms it is willing to accept.
--- ^
[...]. If the client does not support the default algorithms, or
supports other hash and signature algorithms (and it is willing to
| use them for verifying messages sent by the server, i.e., server
^^^^ ^^^^^^^
certificates and server key exchange), it MUST send the
| signature_algorithms extension, listing the algorithms it is willing
^^
to accept.
(11d) improper use of notation for `struct` constants
According to Section 4.8, constants for `struct` constructe in the
TLS Presentation Language should be enclosed in curly braces. This
rule is broken in the bulleted list near the end of section 7.4.1.4.1.
For consistency in the notation, therefore please change 3 instances:
- If the negotiated key exchange algorithm is one of (RSA, DHE_RSA,
DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had sent
| the value (sha1,rsa).
--- ^ ^
- If the negotiated key exchange algorithm is one of (RSA, DHE_RSA,
DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had sent
| the value {sha1,rsa}.
^ ^
- If the negotiated key exchange algorithm is one of (DHE_DSS,
| DH_DSS), behave as if the client had sent the value (sha1,dsa).
--- ^ ^
- If the negotiated key exchange algorithm is one of (DHE_DSS,
| DH_DSS), behave as if the client had sent the value {sha1,dsa}.
^ ^
- If the negotiated key exchange algorithm is one of (ECDH_ECDSA,
| ECDHE_ECDSA), behave as if the client had sent value (sha1,ecdsa).
--- ^ ^
- If the negotiated key exchange algorithm is one of (ECDH_ECDSA,
| ECDHE_ECDSA), behave as if the client had sent value {sha1,ecdsa}.
^ ^
(12) Section 7.4.2
In the last paragraph of Section 7.4.2, for consistency please also
insert the missing article:
As cipher suites that specify new key exchange methods are specified
| for the TLS Protocol, they will imply certificate format and the
required encoded keying information.
--- ^
As cipher suites that specify new key exchange methods are specified
| for the TLS Protocol, they will imply the certificate format and the
required encoded keying information.
(13) Section 7.4.3
(13a) 'hooks' for ECDH missing
It strikes that, unlike other preceding and subsequent sections, this
section does not provide the fundamental `hooks` for extensibility,
in particular the use of Elliptic Curve Cryptography with TLS
(RFC 4492 [TLSECC], see also Appendix A.7).
At a minimum, I suggest to ...
- add a note referring to [TLSECC] for the ECC key exchange
methods (ECDH_*) to the initial prose of the section;
- amend the presentation language definition of the enumerated
type KeyExchangeAlgorithm by a related comment:
| enum { dhe_dss, dhe_rsa, dh_anon, rsa, dh_dss, dh_rsa }
KeyExchangeAlgorithm;
--- ^
| enum { dhe_dss, dhe_rsa, dh_anon, rsa, dh_dss, dh_rsa
| /* may be extended, e.g. for ECDH -- see [TLSECC] */
| }
KeyExchangeAlgorithm;
- amend the presentation language definition of
struct ServerKeyExchange by a related comment:
struct {
select (KeyExchangeAlgorithm) {
case dh_anon:
ServerDHParams params;
case dhe_dss:
[...]
case dh_rsa:
struct {} ;
/* message is omitted for rsa, dh_dss, and dh_rsa */
| };
} ServerKeyExchange;
---
struct {
select (KeyExchangeAlgorithm) {
case dh_anon:
ServerDHParams params;
case dhe_dss:
[...]
case dh_rsa:
struct {} ;
/* message is omitted for rsa, dh_dss, and dh_rsa */
| /* may be extended, e.g. for ecdh_* -- see [TLSECC] */
| };
} ServerKeyExchange;
(13b) 2nd-to-last paragraph: terminology
As already indicated in item (4) for Section 4.7, I suggest to
precisely distinguish between 'DSA' and 'DSS' in the prose of
the draft, and to more explicitely deal with the scope of the DSS.
I also suggest to consistently use the definite article in front of
both acronyms (in standalone occurrences).
Therefore, I suggest to change and clarify, in the 2nd-to-last
paragraph of Section 7.4.3:
Because DSA signatures do not contain any secure indication of hash
algorithm, there is a risk of hash substitution if multiple hashes
| may be used with any key. Currently, DSS [DSS] may only be used with
| SHA-1. Future revisions of DSS [DSS-3] are expected to allow other
| digest algorithms, as well as guidance as to which digest algorithms
should be used with each key size. In addition, [...]
---
Because DSA signatures do not contain any secure indication of hash
algorithm, there is a risk of hash substitution if multiple hashes
| may be used with any key. Currently, the DSA [DSS] may only be used
vvvv ^^^^ ^
| with SHA-1. Future revisions of the DSS [DSS-3] are expected to
allow other digest algorithms with all supported signature algorithms
vvvvvvvvvvvvvvvvvvvvv ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| (DSA, RSA, and ECDSA), as well as guidance as to which digest
algorithms should be used with each key size. In addition, [...]
(14) Section 7.4.5
For clarity and conformance with preferred RFC-Editor style,
I suggest adding a comma in the 2nd paragraph of the
"Meaning of this message" clause:
Upon receipt of the server hello done message, the client SHOULD
| verify that the server provided a valid certificate, if required
and check that the server hello parameters are acceptable.
--- ^
Upon receipt of the server hello done message, the client SHOULD
| verify that the server provided a valid certificate, if required,
and check that the server hello parameters are acceptable.
(15) Section 7.4.6, "Meaning of this message" clause
(15a)
For clarity and consistency in the grammar, I suggest to slightly
modify the 1st paragraph:
This message conveys the client's certificate chain to the server;
: the server will use it when verifying the certificate verify
^^^^^^^^^^^^^^
| message (when the client authentication is based on signing), or
^^^^
| calculate the premaster secret (for non-ephemeral Diffie-Hellman).
--- ^
This message conveys the client's certificate chain to the server;
the server will use it when verifying the certificate verify
| message (when the client authentication is based on signing) or
| calculating the premaster secret (for non-ephemeral Diffie-
Hellman).
(15b)
Also for consistency in style/grammar, I suggest to add a missing
article in the last sub-item of the second bullet:
rsa_fixed_ecdh ECDH-capable public key; MUST use
ecdsa_fixed_ecdh the same curve as server's key, and
MUST use a point format supported by
the server.
---
rsa_fixed_ecdh ECDH-capable public key; MUST use the
| ecdsa_fixed_ecdh same curve as the server's key, and
MUST use a point format supported by
the server.
(Line folding also 'flattened' a bit for enhanced optics)
(16) Section 7.4.7 -- typo
In the first line of the "Meaning of this message" clause, please
s/either though/either through/
(17) Section 7.4.7.1
(17a) paragraph between the two "Note"s
To disambiguate the text regarding the differences between 'plain' and
'encoded' TLS versions, I suggest to change pure "1.0" to "TLS 1.0":
Client implementations MUST always send the correct version number in
: PreMasterSecret. If ClientHello.client_version is TLS 1.1 or higher,
^^^^^^^
server implementations MUST check the version number as described in
| the note below. If the version number is 1.0 or earlier, server
^^^
implementations SHOULD check the version number, but MAY have a
configuration option to disable the check. [...]
---
Client implementations MUST always send the correct version number in
PreMasterSecret. If ClientHello.client_version is TLS 1.1 or higher,
server implementations MUST check the version number as described in
| the note below. If the version number is TLS 1.0 or earlier, server
^^^^
implementations SHOULD check the version number, but MAY have a
configuration option to disable the check. [...]
(17b) subsequent enumerated list
To avoid confusion between the encrypted and the plaintex version
of the message, I suggest changing item 2. of the subsequent list:
2. Decrypt the message M
3. If the PKCS#1 padding is not correct, or the length of
message M is not exactly 48 bytes:
[...]
---
| 2. Decrypt the message to recover the plaintext M
^^^^^^^^^^^^^^^^^^^^^^^^^
3. If the PKCS#1 padding is not correct, or the length of
message M is not exactly 48 bytes:
[...]
(17c) spurious word replication
Near the end of the 4th paragraph below the numbered list (i.e., the
first "Implementation Note, or the 3nd-to-last paragraph of section
7.4.7.1), please correct the spurious replication of "the":
/the the length bytes/the length bytes/
^^^^
(18) Section 7.4.8, last paragraph
Please apply the change recommended in item (13b) above, again:
Because DSA signatures do not contain any secure indication of
hash algorithm, there is a risk of hash substitution if multiple
hashes may be used with any key. Currently, DSS [DSS] may only be
used with SHA-1. Future revisions of DSS [DSS-3] are expected to
allow other digest algorithms, as well as guidance as to which
digest algorithms should be used with each key size. [...]
Because DSA signatures do not contain any secure indication of
hash algorithm, there is a risk of hash substitution if multiple
| hashes may be used with any key. Currently, the DSA [DSS] may
| only be used with SHA-1. Future revisions of the DSS [DSS-3] are
| expected to allow other digest algorithms for all supported
| signature algorithms (DSA, RSA, and ECDSA), as well as guidance as
to which digest algorithms should be used with each key size.
[...]
(19) Section 7.4.9, "Meaning of the Message" clause
I suggest the following clarification, and to delete a hyphen:
The finished message is the first protected with the just-
negotiated algorithms, keys, and secrets. [...]
--- vvvv ^ v
| The finished message is the first one protected with the just
negotiated algorithms, keys, and secrets. [...]
(20) Section 12
In the middle bulleted 'list' (of only a single item), the trailing
period is missing:
- TLS ExtensionType Registry: Future values are allocated via IETF
| Consensus [RFC2434]
--- ^
- TLS ExtensionType Registry: Future values are allocated via IETF
| Consensus [RFC2434].
^
(21) Appendix A
To accommodate the true content of the appendix and not misguide
the reader, I suggest amending the title of the appendix:
Appendix A. Protocol Constant Values
---
Appendix A. Protocol Data Structures and Constant Values
^^^^^^^^^^^^^^^^^^^^
(22) Appendix A.4.1
(22a) HashAlgorithm
As indicated in item (11a) above, I strongly recommend to provide
the immediate assignment of a codepoint for SHA-224 (this change
needs to be synchronized with Section 7.4.1.4):
enum{
none(0), md5(1), sha1(2), sha256(3), sha384(4),
sha512(5), (255)
} HashAlgorithm;
---
enum {
| none(0), md5(1), sha1(2), sha224(TBA), sha256(3), sha384(4),
sha512(5), (255)
} HashAlgorithm;
^^^^^^^^^^^^^
(22b) SignatureAlgorithm -- inconsistency / code point missing
For consistency with Section 7.4.1.4, as quoted in item (11b) above,
the missing code point for ecdsa needs to be supplied here as well:
enum { anonymous(0), rsa(1), dsa(2), (255) } SignatureAlgorithm;
---
| enum { anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) }
| SignatureAlgorithm;
(23) Appendix A.4.2
As noted above in item (13a), I strongly suggest to make the `hooks`
for Elliptic Curve Cryptography with TLS more (and more consistently)
visible.
Therefore, I recommend to also amend the copies of the presentation
language definitions of
enum KeyExchangeAlgorithm
and
struct ServerKeyExchange
repeated here by a the comments proposed in item (13a) above.
(24) Appendix A.5
(24a) textual enhancements for paragraph below TLS_RSA_* table
There's a replicated "a", and the phrase "DHE parameter" might be
considered confusing / ambiguous. I suggest the textual improvement:
[...] DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman
| parameters are signed by a a signature-capable certificate, which has
^^^
been signed by the CA. The signing algorithm used by the server is
| specified after the DHE parameter. [...]
--- ^^^^^^^^^^^^^
[...] DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman
| parameters are signed by a signature-capable certificate, which has
been signed by the CA. The signing algorithm used by the server is
| specified after the DHE name component of the Ciphersuite designation.
[...]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
(24b) TLS_DH* tables
I recommend to always use the same spelling of the Ciphersuite
constants, with no space after the comma and a single space in front
of the trailing "}", not only for the legacy code points, but also
for the new ones, "TBDx".
Thus, please enhance the presentation as follows:
[...]
CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x38 };
CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x39 };
| CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA256 = { 0x00, TBD4};
| CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA256 = { 0x00, TBD5};
| CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 = { 0x00, TBD6};
| CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 = { 0x00, TBD7};
| CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA256 = { 0x00, TBD8};
| CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA256 = { 0x00, TBD9};
| CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 = { 0x00, TBDA};
| CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 = { 0x00, TBDB};
--- ^^ ^
[...]
CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x38 };
CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x39 };
| CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA256 = { 0x00,TBD4 };
| CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA256 = { 0x00,TBD5 };
| CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 = { 0x00,TBD6 };
| CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 = { 0x00,TBD7 };
| CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA256 = { 0x00,TBD8 };
| CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,TBD9 };
| CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 = { 0x00,TBDA };
| CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,TBDB };
^ ^^
and:
CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 };
CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B };
CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA = { 0x00,0x34 };
CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA = { 0x00,0x3A };
| CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA256 = { 0x00, TBDC};
| CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA256 = { 0x00, TBDD};
--- ^^ ^
CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 };
CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B };
CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA = { 0x00,0x34 };
CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA = { 0x00,0x3A };
| CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA256 = { 0x00,TBDC };
| CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA256 = { 0x00,TBDD };
^ ^^
(24c) last long paragraph
Please consider adding two instances of the indefinite article:
Note that using non-anonymous key exchange without actually verifying
the key exchange is essentially equivalent to anonymous key exchange,
and the same precautions apply. [...]
--- vv
| Note that using a non-anonymous key exchange without actually
| verifying the key exchange is essentially equivalent to an anonymous
key exchange, and the same precautions apply. [...]
^^^
(change might be replicated subsequently)
(25) Appendix A.6
As in Section 6.1 (item (5) of first part of this review), the
extended algorithm agility should be indicated for PRFAlgorithm
as well, in the presentation language comment:
| /* The algorithms specified in CompressionMethod,
BulkCipherAlgorithm, and MACAlgorithm may be added to. */
--- vvvvvvvvvvvvvv
| /* The algorithms specified in CompressionMethod, PRFAlgorithm,
BulkCipherAlgorithm, and MACAlgorithm may be added to. */
(26) Appendix B
(26a) placement of ref. tags, hyphenation
Occasionally, in this Appendix ref. tags are placed behind the
trailing period of a sentence. This may be acceptable if done
at the end of an entry, but it is confusing in its middle.
Thus, at a minimum, please change, e.g., (this proposal also
incorporates the placement of four hyphens in attribute-like
number/word combinations):
Advanced Encryption Standard (AES)
AES is a widely used symmetric encryption algorithm. AES is a
block cipher with a 128, 192, or 256 bit keys and a 16 byte block
| size. [AES] TLS currently only supports the 128 and 256 bit key
sizes.
--- ^^^^^^^^^
Advanced Encryption Standard (AES)
| AES [AES] is a widely used symmetric encryption algorithm. AES is
a block cipher with a 128, 192, or 256-bit keys and a 16-byte
block size. TLS currently only supports the 128- and 256-bit key
sizes.
(26b) update/clarification
There are several placed, where the definitions in Appendix B are
outdated and should be adapted to current knowledge/practice.
For instance:
block cipher
A block cipher is an algorithm that operates on plaintext in
| groups of bits, called blocks. 64 bits is a common block size.
---
block cipher
A block cipher is an algorithm that operates on plaintext in
| groups of bits, called blocks. 64 bits was, and 128 bits is,
a common block size.
(26c) update/clarification (plus hyphenation)
Second instance:
Data Encryption Standard
DES is a very widely used symmetric encryption algorithm. DES is a
block cipher with a 56 bit key and an 8 byte block size. Note that
in TLS, for key generation purposes, DES is treated as having an 8
byte key length (64 bits), but it still only provides 56 bits of
protection. (The low bit of each key byte is presumed to be set to
produce odd parity in that key byte.) DES can also be operated in
a mode where three independent keys and three encryptions are used
for each block of data; this uses 168 bits of key (24 bytes in the
TLS key generation method) and provides the equivalent of 112 bits
of security. [DES], [3DES]
---
Data Encryption Standard
| DES still is a very widely used symmetric encryption algorithm,
^^^^^^ ^
| although it is generally considered as rather weak now. DES is a
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| block cipher with a 56-bit key and an 8-byte block size. Note that
^ ^
in TLS, for key generation purposes, DES is treated as having an
| 8-byte key length (64 bits), but it still only provides 56 bits of
^
protection. (The low bit of each key byte is presumed to be set to
produce odd parity in that key byte.) DES can also be operated in
a mode where three independent keys and three encryptions are used
for each block of data; this uses 168 bits of key (24 bytes in the
TLS key generation method) and provides the equivalent of 112 bits
of security. [DES], [3DES]
(26d) update
Digital Signature Standard (DSS)
A standard for digital signing, including the Digital Signing
Algorithm, approved by the National Institute of Standards and
| Technology, defined in NIST FIPS PUB 186, "Digital Signature
| Standard", published May, 1994 by the U.S. Dept. of Commerce.
| [DSS]
Digital Signature Standard (DSS)
A standard for digital signing, including the Digital Signing
Algorithm, approved by the National Institute of Standards and
| Technology, defined in NIST FIPS PUB 186-2, "Digital Signature
vvvvvvvvvvvvv ^^
Standard", published January, 2000 by the U.S. Dept. of Commerce
| [DSS]. A significant update has been drafted and published in
| March 2006. DSS-3]
(26e) update/clarification
vvvvvvv
MD5
| MD5 is a secure hashing function that converts an arbitrarily long
data stream into a hash of fixed size (16 bytes). [MD5]
---
MD5
| MD5 is a hashing function that converts an arbitrarily long data
| stream into a hash of fixed size (16 bytes). Due to significant
| progresses in cryptanalysis, at the time of publication of this
| document, MD5 no longer can be considered a 'secure' hashing
| function. [MD5]
(26f) update/clarification
SHA
The Secure Hash Algorithm is defined in FIPS PUB 180-2. It
produces a 20-byte output. Note that all references to SHA
actually use the modified SHA-1 algorithm. [SHA]
---
SHA
The Secure Hash Algorithm is defined in FIPS PUB 180-2. It
produces a 20-byte output. Note that all references to SHA
| (without a numerical suffix) actually designate the SHA-1
| algorithm. [SHS]
(27) Appendix C
(27a) "Expanded Key Material"
Do we really still need this column in the second table ?
It was only significant for historical encryption algorithms now
considered to weak to be practically useful and hence no more listed
in the current version of this table; all current entries are equal
to the corresponding entries in the "Key Material" column.
(27b) columnar alignment
I suggest to strictly use decimal alignment in the numerical
columns of the second and the third table in Appendix C.
Should the conclusion be made to retain the "Expanded Key Material"
column in the second table, it might be improved to this more
pleasant layout:
Key Expanded IV Block
Cipher Type Material Key Material Size Size
NULL Stream 0 0 0 N/A
RC4_128 Stream 16 16 0 N/A
3DES_EDE_CBC Block 24 24 8 8
AES_128_CBC Block 16 16 16 16
AES_256_CBC Block 32 32 16 16
---
| Key Expanded IV Block
| Cipher Type Material Key Material Size Size
| ------------ ------ -------- ------------ ---- -----
| NULL Stream 0 0 0 N/A
| RC4_128 Stream 16 16 0 N/A
| 3DES_EDE_CBC Block 24 24 8 8
| AES_128_CBC Block 16 16 16 16
| AES_256_CBC Block 32 32 16 16
otherwise, it could be simplified as:
| Key IV Block
| Cipher Type Material Size Size
| ------------ ------ -------- ---- -----
| NULL Stream 0 0 N/A
| RC4_128 Stream 16 0 N/A
| 3DES_EDE_CBC Block 24 8 8
| AES_128_CBC Block 16 16 16
| AES_256_CBC Block 32 16 16
Similarly, the third table should be facelifted as:
MAC Algorithm mac_length mac_key_length
NULL N/A 0 0
MD5 HMAC-MD5 16 16
SHA HMAC-SHA1 20 20
SHA256 HMAC-SHA256 32 32
---
| MAC Algorithm mac_length mac_key_length
| -------- ----------- ---------- --------------
| NULL N/A 0 0
| MD5 HMAC-MD5 16 16
| SHA HMAC-SHA1 20 20
| SHA256 HMAC-SHA256 32 32
(28) Appendix E.1 -- textual improvements
(28a) 6th paragraph
v
| A TLS server can also receive a ClientHello containing version number
smaller than the highest supported version. If the server wishes to
negotiate with old clients, it will proceed as appropriate for the
highest version supported by the server that is not greater than
ClientHello.client_version. For example, if the server supports TLS
1.0, 1.1, and 1.2, and client_version is TLS 1.0, the server will
| proceed with a TLS 1.0 ServerHello. If server supports (or is willing
^
to use) only versions greater than client_version, it MUST send a
"protocol_version" alert message and close the connection.
--- vvv
| A TLS server can also receive a ClientHello containing a version
number smaller than the highest supported version. If the server
wishes to negotiate with old clients, it will proceed as appropriate
for the highest version supported by the server that is not greater
than ClientHello.client_version. For example, if the server supports
TLS 1.0, 1.1, and 1.2, and client_version is TLS 1.0, the server will
| proceed with a TLS 1.0 ServerHello. If the server supports (or is
^^^^^
willing to use) only versions greater than client_version, it MUST
send a "protocol_version" alert message and close the connection.
(28b) 7th paragraph
v
| Whenever a client already knows the highest protocol known to a
server (for example, when resuming a session), it SHOULD initiate the
connection in that native protocol.
--- vvvvvvvvv
| Whenever a client already knows the highest protocol version known to
a server (for example, when resuming a session), it SHOULD initiate
the connection in that native protocol.
(28c) 8th paragraph
Note: some server implementations are known to implement version
negotiation incorrectly. For example, there are buggy TLS 1.0 servers
that simply close the connection when the client offers a version
newer than TLS 1.0. Also, it is known that some servers will refuse
| connection if any TLS extensions are included in ClientHello.
[...]
---
Note: some server implementations are known to implement version
negotiation incorrectly. For example, there are buggy TLS 1.0 servers
that simply close the connection when the client offers a version
newer than TLS 1.0. Also, it is known that some servers will refuse
| the connection if any TLS extensions are included in ClientHello.
^^^^
[...]
(29) References
(29a) demote [DES] to Informative -- due to lack of Historical :-)
Rationale: FIPS PUB 46-3 has been formally withdrawn May 19, 2005.
(29b) rational quotation
For the entries
[DSS] , [SHA] , [DSS-3] , [PKCS6] , [PKCS7] , [RSA] , and [TCP]
s/,"/",/
(29c) SHS
I strongly suggest to rename the ref. tag '[SHA]' to '[SHS]', for the
sake of terminological consistency. Also, the publication date should
be updated to account for the Change Note adding SHA-224 support.
Finally, there's spurious punctuation.
Incorporating all proposed changes:
v vv
[SHA] NIST FIPS PUB 180-2, "Secure Hash Standard," National
Institute of Standards and Technology, U.S. Department of
Commerce., August 2001.
--- v ^^ ^ vv
| [SHS] NIST FIPS PUB 180-2, "Secure Hash Standard", National
Institute of Standards and Technology, U.S. Department of
Commerce, August 2002.
^ ^
(29d) update
[AEAD] has been publised as RFC 5116, January 2008.
Ooouuuggghhh! That's it.
Kind regards,
Alfred.
--
+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. |
| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 |
| D-71254 Ditzingen | E-Mail: ah at TR-Sys.de |
+------------------------+--------------------------------------------+
_______________________________________________
TLS mailing list
TLS at ietf.org
https://www.ietf.org/mailman/listinfo/tls
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.
