Subject: [TLS] suggested changes for rfc4346-bis-00

From: Brad Hards <[email-masked]>
Date: Fri, 17 Mar 2006 19:16:17 +1100

G'day all,

These are mostly editorial. Happy to discuss any that aren't obvious.

Brad

--- draft-ietf-tls-rfc4346-bis-00.orig  2006-03-16 21:19:19.000000000 +1100
+++ draft-ietf-tls-rfc4346-bis-00.txt   2006-03-16 21:56:08.000000000 +1100
@@ -224,11 +224,11 @@

    One advantage of TLS is that it is application protocol independent.
    Higher level protocols can layer on top of the TLS Protocol
-   transparently. The TLS standard, however, does not specify how
+   transparently. However the TLS standard does not specify how
    protocols add security with TLS; the decisions on how to initiate TLS
    handshaking and how to interpret the authentication certificates
    exchanged are left up to the judgment of the designers and
-   implementors of protocols which run on top of TLS.
+   implementors of the protocols which run on top of TLS.

 1.1 Differences from TLS 1.1
    This document is a revision of the TLS 1.1 [TLS1.1] protocol which
@@ -290,10 +290,10 @@
    between this protocol and SSL 3.0 are not dramatic, but they are
    significant enough that the various versions of TLS and SSL 3.0 do
    not interoperate (although each protocol incorporates a mechanism by
-   which an implementation can back down prior versions. This document
+   which an implementation can back down to prior versions). This document
    is intended primarily for readers who will be implementing the
    protocol and those doing cryptographic analysis of it. The
-   specification has been written with this in mind, and it is intended
+   specification has been written with these users in mind, and it is 
intended
    to reflect the needs of those two groups. For that reason, many of
    the algorithm-dependent data structures and rules are included in the
    body of the text (as opposed to in an appendix), providing easier
@@ -307,12 +307,12 @@
 4. Presentation language

    This document deals with the formatting of data in an external
-   representation. The following very basic and somewhat casually
-   defined presentation syntax will be used. The syntax draws from
-   several sources in its structure. Although it resembles the
+   representation. This section presents the very basic and somewhat casually
+   defined presentation syntax which will be used. The syntax draws from
+   several sources in its structure. Note that although it resembles the
    programming language "C" in its syntax and XDR [XDR] in both its
    syntax and intent, it would be risky to draw too many parallels. The
-   purpose of this presentation language is to document TLS only, not to
+   purpose of this presentation syntax is to document TLS only, not to
    have general application beyond that particular goal.

@@ -951,11 +951,7 @@

    version
        The version of the protocol being employed. This document
-       describes TLS Version 1.1, which uses the version { 3, 2 }. The
-       version value 3.2 is historical: TLS version 1.1 is a minor
-       modification to the TLS 1.0 protocol, which was itself a minor
-       modification to the SSL 3.0 protocol, which bears the version
-       value 3.0. (See Appendix A.1).
+       describes TLS Version 1.2, which uses the version { 3, 3 }.

    length
        The length (in bytes) of the following TLSPlaintext.fragment.
@@ -1110,8 +1106,8 @@
    The MAC is generated as described in Section 6.2.3.1.

    IV
-       Unlike previous versions of SSL and TLS, TLS 1.1 uses an explicit
-       IV in order to prevent the attacks described by [CBCATT].
+       As of TLS 1.1, an explicit IV is used in order to prevent
+       the attacks described by [CBCATT].
        We recommend the following equivalently strong procedures.
        For clarity we use the following notation.

@@ -1122,7 +1118,7 @@
            plaintext prior to encryption of the first cipher block
            of the record.

-       In prior versions of TLS, there was no IV field and the CBC residue
+       For TLS before version 1.1, there was no IV field and the CBC residue
        and mask were one and the same. See Sections 6.1, 6.2.3.2 and 6.3,
        of [TLS1.0] for details of TLS 1.0 IV handling.
_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls