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

Fabrice Gautier <fabrice.gautier@gmail.com> Mon, 07 July 2014 22:41 UTC

Return-Path: <fabrice.gautier@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 925C21B28A5 for <tls@ietfa.amsl.com>; Mon, 7 Jul 2014 15:41:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVlieZIQkZH2 for <tls@ietfa.amsl.com>; Mon, 7 Jul 2014 15:41:42 -0700 (PDT)
Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 200981B281C for <tls@ietf.org>; Mon, 7 Jul 2014 15:41:41 -0700 (PDT)
Received: by mail-wi0-f169.google.com with SMTP id hi2so219091wib.0 for <tls@ietf.org>; Mon, 07 Jul 2014 15:41:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=CppT5t9V10Dqg/2BGauqE8XcmKeqMsks091AYUtW7h8=; b=PByFCJAaLm9PeQgspDi4862y8PETyzXmQzJvVYp3xy16BvCfz8lOlIapO9jD0DSBdx KFM2Srk6TpApRHukLO4hs9HT4soXtKwbyGZ2g4D1hTKM1SUOfC+QbLYHpJgzeugd4Xsg 36yMIpzWLswvsrvJyX3t6TH81B8+In+jjYITbhsZ7QscsbSvLXfS6hiVzvXC2WVxw8Cp q3gEhBV95BwzrNuEu+evblej7Rc8PVukkxp1fnP9D3d+Fg79fmezOxKCK2o1w96r3TMX 4xc2aBIE0GEk+9oZ4+1Jtb/eLYPpt+RDlGmteKeAO4bmPlarDcWVBN/taomCCceeT40S vXlQ==
X-Received: by 10.194.110.161 with SMTP id ib1mr26718wjb.129.1404772900681; Mon, 07 Jul 2014 15:41:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.217.38.82 with HTTP; Mon, 7 Jul 2014 15:41:20 -0700 (PDT)
In-Reply-To: <CABkgnnUFuhyaD2eAqk80RaRV_VQt7XdhbDsg5hXQOpHuyvCk7Q@mail.gmail.com>
References: <53B331A5.2040908@fifthhorseman.net> <CANOyrg-_xTvdrCdJDhttNMNL=LFPPsC4e_aKWnaJKWbaNDgp+A@mail.gmail.com> <CABkgnnUFuhyaD2eAqk80RaRV_VQt7XdhbDsg5hXQOpHuyvCk7Q@mail.gmail.com>
From: Fabrice Gautier <fabrice.gautier@gmail.com>
Date: Mon, 7 Jul 2014 15:41:20 -0700
Message-ID: <CANOyrg9R8U9qkeGZ80pFNBAO_md9SejKsczNpaqV5OK3dEpMiA@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/rIhSAxkw6V7VoUvP1lcJF97HIIw
Cc: IETF TLS WG <tls@ietf.org>
Subject: Re: [TLS] proposal to encrypt ContentType for TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Jul 2014 22:41:43 -0000

On Mon, Jul 7, 2014 at 2:01 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
> On 7 July 2014 13:29, Fabrice Gautier <fabrice.gautier@gmail.com> 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.