IETF Logo Mail Archive

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

Martin Thomson <martin.thomson@gmail.com> Mon, 07 July 2014 22:55 UTC

Return-Path: <martin.thomson@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 5EE591B28C8 for <tls@ietfa.amsl.com>; Mon, 7 Jul 2014 15:55:22 -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 OF_Tid3SEzHj for <tls@ietfa.amsl.com>; Mon, 7 Jul 2014 15:55:21 -0700 (PDT)
Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EB4E1B28A5 for <tls@ietf.org>; Mon, 7 Jul 2014 15:55:20 -0700 (PDT)
Received: by mail-wi0-f171.google.com with SMTP id n15so25916wiw.4 for <tls@ietf.org>; Mon, 07 Jul 2014 15:55:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mxYXkMJXNixz9NvULHNTImxWnvAZ7vXWasZaElSrrVo=; b=tik4OkztSM2cqFyJIZXq9LFFc8LE11KEkTPtoPLKO+Nz4zB4Vs3XxHORH5+Z0OdgAI L0EpyP9HCUph5dr4zBOmOiepx1sQ+lsTE/iyz6j0oGwqP5kYz6VC+jdQAgGhAKR31EG9 6WppYJPLa/FOrlV4nb8AEy5l4VEvUyAz/VteomHc3c2luY4ZxlrDh/e9Z2+TGG3kY/Bb 1FPCn3i1R8XF+fetan4j7fMt7vJs3HFqbf7dOMpbRux9Z03oC9olyP7eKLilpdx3z2sb NzkX4ywNMhtvi0uPOtbQ1PS2xmed9feZc1pLHWB33xxjGdHbO0J9n1hPXX9dEEVbhJHl CxLQ==
MIME-Version: 1.0
X-Received: by 10.180.212.68 with SMTP id ni4mr39856492wic.64.1404773719545; Mon, 07 Jul 2014 15:55:19 -0700 (PDT)
Received: by 10.194.110.6 with HTTP; Mon, 7 Jul 2014 15:55:19 -0700 (PDT)
In-Reply-To: <CANOyrg9R8U9qkeGZ80pFNBAO_md9SejKsczNpaqV5OK3dEpMiA@mail.gmail.com>
References: <53B331A5.2040908@fifthhorseman.net> <CANOyrg-_xTvdrCdJDhttNMNL=LFPPsC4e_aKWnaJKWbaNDgp+A@mail.gmail.com> <CABkgnnUFuhyaD2eAqk80RaRV_VQt7XdhbDsg5hXQOpHuyvCk7Q@mail.gmail.com> <CANOyrg9R8U9qkeGZ80pFNBAO_md9SejKsczNpaqV5OK3dEpMiA@mail.gmail.com>
Date: Mon, 07 Jul 2014 15:55:19 -0700
Message-ID: <CABkgnnX2k0THS9XZf4rAPbb=_xS=UiTcxZSaa8dnaAqZaxi00Q@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Fabrice Gautier <fabrice.gautier@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KNrInot_Y6oPEhd676R3P5qdkEA
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:55:22 -0000

On 7 July 2014 15:41, Fabrice Gautier <fabrice.gautier@gmail.com> wrote:
>> 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 ?

   The epoch number is initially zero and is
   incremented each time a ChangeCipherSpec message is sent.

The overlap between the epoch you are likely to encounter (0x0001) and
the content type/upper byte of version is zero.

After that, it's all version-free and there is no ambiguity at all.

Which also leads me to conclude that DTLS-SRTP might be OK here, if we
constrain the epoch.

v2.23.0 | Report a Bug | By Email