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

From: Sami Lehtinen <[email-masked]>
Date: Thu, 12 Jan 2006 09:02:24 +0200

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?

-- 
[email-masked]

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: jimmy <[email-masked]>
Date: Thu, 12 Jan 2006 15:28:53 +0530

> Hello,
...
>        interleaved. Application data is generally of higher precedence

I too had pointed this out in an earlier mail, but got no replies. It 
seems in a previous thread in this list Eric had replied to someone 
posing a similar query. He had actually mentioned data had lower 
precedence (similar to what's in tls1.0 & the earlier tls1.1_drafts.

So, it's a bit confusing. tls1.1 is in the rfc editor queue, so is that 
why no clarifications are coming in (are these going to be addressed in 
tls 1.2?)

-jb

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 12 Jan 2006 07:41:06 -0800

jimmy <[email-masked]> writes:

> Sami Lehtinen wrote:
>> Hello,
> ...
>> Also, there is conflicting text regarding message precedence
>> (handshake vs. application data):
> So, it's a bit confusing. tls1.1 is in the rfc editor queue, so is
> that why no clarifications are coming in (are these going to be
> addressed in tls 1.2?)

This will be clarified in TLS 1.1 "Authors 48 hours"

-Ekr

---

From: jimmy <[email-masked]>
Date: Thu, 12 Jan 2006 21:47:33 +0530

> This will be clarified in TLS 1.1 "Authors 48 hours"

thankyou Eric, but which one will it be. does it mean application data 
gets higher precedence?

-jimmy

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 12 Jan 2006 08:35:30 -0800

> thankyou Eric, but which one will it be. does it mean application data

There should be no change from the 2246 language.

-Ekr

---

From: Sami Lehtinen <[email-masked]>
Date: Fri, 13 Jan 2006 10:46:15 +0200

Eric Rescorla wrote:
[application data/handshake precedence]
> There should be no change from the 2246 language.

Thank you, Eric.

Any take on my other question about the TLSCipherText.length?

-- 
[email-masked]