[TLS] questions regarding draft-ietf-tls-rfc2246-bis-13.txt

Sami Lehtinen <sjl@ssh.com> Thu, 12 January 2006 07:01 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwwSP-0003Ai-BO; Thu, 12 Jan 2006 02:01:13 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwwSD-000361-8j for tls@megatron.ietf.org; Thu, 12 Jan 2006 02:01:02 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26453 for <tls@ietf.org>; Thu, 12 Jan 2006 01:59:40 -0500 (EST)
Received: from fw.hel.fi.ssh.com ([195.20.116.97]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EwwZF-00021H-HS for tls@ietf.org; Thu, 12 Jan 2006 02:08:19 -0500
Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.16) with SMTP id k0C70gjR024601 for <tls@ietf.org>; Thu, 12 Jan 2006 09:00:42 +0200 (EET)
Received: (qmail 27649 invoked from network); 12 Jan 2006 07:00:42 -0000
Received: from unknown (HELO ?127.0.0.1?) ([10.1.0.48]) (envelope-sender <sjl@ssh.com>) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for <tls@ietf.org>; 12 Jan 2006 07:00:42 -0000
Message-ID: <43C5FF00.5040704@ssh.com>
Date: Thu, 12 Jan 2006 09:02:24 +0200
From: Sami Lehtinen <sjl@ssh.com>
User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051020)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: tls@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Content-Transfer-Encoding: 7bit
Cc:
Subject: [TLS] questions regarding draft-ietf-tls-rfc2246-bis-13.txt
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Sender: tls-bounces@lists.ietf.org
Errors-To: tls-bounces@lists.ietf.org

Hello,

In section 6.2.3.2. CBC block cipher:

    The encrypted data length (TLSCiphertext.length) is one more than the
    sum of TLSCompressed.length, CipherSpec.hash_size, and
    padding_length.

Should this be:

    The encrypted data length (TLSCiphertext.length) is one more than the
    sum of CipherSpec.block_length, TLSCompressed.length,
           ^^^^^^^^^^^^^^^^^^^^^^^^^
    CipherSpec.hash_size, and padding_length.

to accommondate for the explicit IV?

Also, there is conflicting text regarding message precedence (handshake 
vs. application data):

In section 6.2.1. Fragmentation:

  Note: Data of different TLS Record layer content types MAY be
        interleaved. Application data is generally of higher precedence
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        for transmission than other content types and therefore handshake
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        records may be held if application data is pending.  However,
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

and in 7.4.1.1. Hello request:

        with a no_renegotiation alert. Since handshake messages are
                                             ^^^^^^^^^^^^^^^^^^^^^^
        intended to have transmission precedence over application data,
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        it is expected that the negotiation will begin before no more
        than a few records are received from the client. If the server

Which text is correct? In RFC 2246, the text is

  Note: Data of different TLS Record layer content types may be
        interleaved. Application data is generally of lower precedence
        for transmission than other content types.

and text to the same effect is also in section 7.4.1.1 of RFC2246.

P.S: with regard to the recent charter changes, is there going to be any 
kind of RFC of TLS 1.1?

-- 
sjl@ssh.com

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls