Re: [TLS] padding bug

[[e-mail] (Martin Rex)]

Brian Smith wrote:
>
> Regarding the particulars of the ID:
> 
> Section 3.1. (Rehandshake Issues) seems overly complex. I think this
> extension should be connection-level, not session-level.

The reason why this draft needs to be complex, is that the TLS
protocol is signficantly underspecified for rehandshakes (aka renegotiation).
rfc5746 fixes only the renegotiation security vulnerability,
it does not remove all of the underspecifed areas.

When a paricular PDU content change is part of a TLS cipher suite
and negotiated through the cipher suite ID, then the PDU change
from current to new will happen with "ChangeCipherSpec" (seperate
for each direction of the communication).

PDU changes based on TLS protocol version and based on TLS extensions,
however, usually apply to ServerHello already.  There currently
is also no distinction between changes to Handshake message PDUs
(or addition, insertion or reording of Handshake message PDUs),
and changes to the Record Layer PDU -- the latter being subject of
Peter's proposal to fix the mac-pad-encrypt for Blockciphers with CBC.

Personally, I since believe it would be sensible to specify/define at
the TLS protocol level that any changes to the record layer PDU,
_independent_ of how they're negotiated (cipher suite, compression algs,
TLS extension) ought to universally apply to the first message following
ChangeCipherSpec.

Currently, this is undefined/unspecified in TLS.

Question to implementors:  The GenericBlockCipher PDU for TLSv1.0
and TLSv1.1 differs.  Do you know what your implementation currently
does should the TLS protocol version changes on a rehandshake/renegotiation
between TLSv1.0 and TLSv1.1 (up or down), why it behaves like it does,
and where this is specified?  ;-)


-Martin