Re: [TLS] proposal to encrypt ContentType for TLS 1.3
Martin Thomson <martin.thomson@gmail.com> Tue, 01 July 2014 22:31 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 86C061A03FD
for <tls@ietfa.amsl.com>; Tue, 1 Jul 2014 15:31:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_74=0.6,
SPF_PASS=-0.001] autolearn=no
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 PC-1RdXGcpuD for <tls@ietfa.amsl.com>;
Tue, 1 Jul 2014 15:31:26 -0700 (PDT)
Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com
[IPv6:2a00:1450:400c:c05::234])
(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
(No client certificate requested)
by ietfa.amsl.com (Postfix) with ESMTPS id 752331A0ABA
for <tls@ietf.org>; Tue, 1 Jul 2014 15:31:26 -0700 (PDT)
Received: by mail-wi0-f180.google.com with SMTP id hi2so8601945wib.7
for <tls@ietf.org>; Tue, 01 Jul 2014 15:31:25 -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=rST06LKp5ghXjpmmjpEExD1pWFHH5EafbnhvdxnLtMY=;
b=nwFfF0Dff5ylzGcEb3MfFg44an14T7EuqnuBoFjWuUJg+aY2yof2/tQ8AIcJ0+YXw8
NwsXMdIJ27XFQWwwl0py/Fm01dNJF57ATxleD9ZajkitYaHD8SJ8oAN2Bzj4OpYYtjCN
gEvrOkCUsY+ouAAzLL7KkLDDEabVGRrDMblRUmI/tvbUIOuMEuDi2VXq2Vm8fqV+FoqN
lG8W+C6DDpNSysjXP3eHtQHhF4GFNuNzmACcE9fuVEWa81ICzA9hwMJ4jm5Q03fpk2aS
7OGzSfhNHvozyp19qh0syBWUFSqHQtLNHAat9z531v6ZFyRMv6YigxEMzL3sEgkena6N
EXQA==
MIME-Version: 1.0
X-Received: by 10.180.107.138 with SMTP id hc10mr15554694wib.47.1404253884993;
Tue, 01 Jul 2014 15:31:24 -0700 (PDT)
Received: by 10.194.110.6 with HTTP; Tue, 1 Jul 2014 15:31:24 -0700 (PDT)
In-Reply-To: <53B331A5.2040908@fifthhorseman.net>
References: <53B331A5.2040908@fifthhorseman.net>
Date: Tue, 1 Jul 2014 15:31:24 -0700
Message-ID: <CABkgnnWFsqvNSNU3xnxMB-5QmaOhGYb8YA4JC1W1YgjFO5adxg@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Z1Fa8OJuhym5EvMS-1FL9iGFn4g
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: Tue, 01 Jul 2014 22:31:27 -0000
On 1 July 2014 15:09, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote: > If this change is made, it's also relatively easy to just drop the TLS > version field for each encrypted TLS record layer fragment. I'd like to see that happen. I think that the bit that causes me a little concern is that content type shifts around, with a special case. If you have a special case like that, then there isn't much of a difference between moving it while under encryption to moving it always (other than the need to keep ClientHello clean. But that doesn't seem like the right answer either. It's more disruptive, but if the definition of the AEAD cipher were to encompass the entire struct, then you could define NULL_NULL in a way that placed content type in the old location. I don't know if that is any better, though it would probably be the way I'd structure software that processed the record layer. Then you have a different structure in place of TLSCipherText on which the construction depends on the cipher. NULL_NULL can define something that looks like legacy TLS: ContentType, Version, Payload.length, Payload.data. Ciphersuite constructions can define something like this: Payload.length, Nonce, Encrypted { ContentType, Payload.data }; with variance discouraged, but possible.
- [TLS] proposal to encrypt ContentType for TLS 1.3 Daniel Kahn Gillmor
- Re: [TLS] proposal to encrypt ContentType for TLS… Martin Thomson
- Re: [TLS] proposal to encrypt ContentType for TLS… Eric Rescorla
- Re: [TLS] proposal to encrypt ContentType for TLS… Martin Thomson
- Re: [TLS] proposal to encrypt ContentType for TLS… Colm MacCárthaigh
- Re: [TLS] proposal to encrypt ContentType for TLS… Martin Rex
- Re: [TLS] proposal to encrypt ContentType for TLS… Geoffrey Keating
- Re: [TLS] proposal to encrypt ContentType for TLS… Fabrice Gautier
- Re: [TLS] proposal to encrypt ContentType for TLS… Martin Thomson
- Re: [TLS] proposal to encrypt ContentType for TLS… Fabrice Gautier
- Re: [TLS] proposal to encrypt ContentType for TLS… Martin Thomson
- Re: [TLS] proposal to encrypt ContentType for TLS… Daniel Kahn Gillmor
- Re: [TLS] proposal to encrypt ContentType for TLS… Martin Rex
- Re: [TLS] proposal to encrypt ContentType for TLS… Daniel Kahn Gillmor
- Re: [TLS] proposal to encrypt ContentType for TLS… Martin Rex
- Re: [TLS] proposal to encrypt ContentType for TLS… Watson Ladd
- Re: [TLS] proposal to encrypt ContentType for TLS… Colm MacCárthaigh