Re: [TLS] proposal to encrypt ContentType for TLS 1.3

[Fabrice Gautier <[e-mail]>]

On Mon, Jul 7, 2014 at 2:01 PM, Martin Thomson <[e-mail]> wrote:
> On 7 July 2014 13:29, Fabrice Gautier <[e-mail]> wrote:
>> If I'm reading this properly, there would be two types of records on
>> the wire: TLSCiphertext and TLSPlaintext.
>> However, I don't see a very reliable, documented way to distinguish
>> between the two on the wire.
>
> TLSPlaintext records appear before a ChangeCipherSpec and
> TLSCiphertext records appears afterwards.  That is pretty unambiguous.
>
> Yes, this does mean that it's going to be self-evident in individual
> frames, interpreted individually, which is exactly Martin Rex's
> objection.
>
>> - In DTLS, records maybe dropped, received out of order, received
>> multiple times, etc, so TLSPlaintext and TLSCiphertext records aybe
>> intermixed, without a clear switchover point. This would make
>> efficient DTLS difficult.
>
> Doesn't the explicit sequence number in DTLS do that job adequately?
> Yes, you don't know until you get the packet containing CCS (or a
> retransmit thereof), but there's a fairly narrow range of values where
> it could appear.

How do you reliably get the sequence number out of the records, if you
don't know which format is that record in ?

By extension of the current proposal, I am assuming the DTLS records
on the wire would look like this before CCS:
   type (1 byte) | version (2 bytes) | epoch (2 bytes) | seq_num (6
bytes) | length (2 bytes) | xxx...

and after CCS, records would look like:
   version | epoch | seq_num | length | xxx...
or like this if version is removed:
  epoch | seq_num | length | xxx..

In practice the actual values of type, version and epoch mean that the
value of the first byte will disambiguate the format in (almost) all
cases, but that ought to be documented in the RFC.