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

Colm MacCárthaigh <colm@allcosts.net> Mon, 14 July 2014 17:51 UTC

Return-Path: <colm@allcosts.net>
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 C15541A8BB7 for <tls@ietfa.amsl.com>; Mon, 14 Jul 2014 10:51:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level:
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 HmRta5QL_7VW for <tls@ietfa.amsl.com>; Mon, 14 Jul 2014 10:51:33 -0700 (PDT)
Received: from mail-ob0-f170.google.com (mail-ob0-f170.google.com [209.85.214.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0BE81A854D for <tls@ietf.org>; Mon, 14 Jul 2014 10:51:33 -0700 (PDT)
Received: by mail-ob0-f170.google.com with SMTP id wp4so2607132obc.15 for <tls@ietf.org>; Mon, 14 Jul 2014 10:51:33 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=iHSmabkMCRr8jEk30ceRJkCG6ZbKm8MDg/kJqmKOzX4=; b=NgAtjo0lTHzbnItRJRU8CJDQSOB6AbUxCK2ftldjInQacTReF8WLMWYETWljvfe/PQ 6HNL/+JeZq7JuYSDFlIKAX/RY24FclqCbedmFMOZIGUp5wo+WYkPST5FOMFggY7A0nKz n0Lp+2VawJSrFtjmqOijAa+dZE8RF1qIQIyUf7gJAwE81qRO/Tlq4AHg+2PkJe+j3eGi iWzT00sCOwv+GOuPbvIPZs2LBQBztzzqnWmEtWGi1x6ZLflvN6kWw/7QzptqOVMS1geu 99FAmPDx81JXtrLXgDrCsFuhoFU5GQaCQ+GfiY7UFxwUIlR0LRWC+Lgp71ZGSYBo98xk SOKA==
X-Gm-Message-State: ALoCoQkiDP3NoedblGxcU1yClwCCXCmNn/nBNIoYOWvMgukZ86jDPLelcjn7lz80MmIquR8hctIr
MIME-Version: 1.0
X-Received: by 10.60.145.196 with SMTP id sw4mr5001484oeb.72.1405360293244; Mon, 14 Jul 2014 10:51:33 -0700 (PDT)
Received: by 10.76.10.198 with HTTP; Mon, 14 Jul 2014 10:51:33 -0700 (PDT)
In-Reply-To: <20140714161000.B229C1ADA7@ld9781.wdf.sap.corp>
References: <53C3E973.4070504@fifthhorseman.net> <20140714161000.B229C1ADA7@ld9781.wdf.sap.corp>
Date: Mon, 14 Jul 2014 10:51:33 -0700
Message-ID: <CAAF6GDeB+-_a1iHybQU33c1WrfBS7Op+_sSzbF-_8ukXJ+NC+A@mail.gmail.com>
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= <colm@allcosts.net>
To: mrex@sap.com
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/WFs-T2PTSpdN1M_7nMzAWuGTAEk
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, 14 Jul 2014 17:51:35 -0000

On Mon, Jul 14, 2014 at 9:10 AM, Martin Rex <mrex@sap.com> wrote:
> I meant to say that it is a feature of TLS to be able to distinguish
> handshake phase from application data phase on the outside.

During the week of heartbleed, I wrote a silly kernel module that does
this. I've just put it on GitHub for reference:

https://github.com/colmmacc/nf_conntrack_tls

I wouldn't recommend actually using the module, as it was an emergency
temporary measure borne out of necessity and in general; moving input
processing risks to the kernel is an especially bad idea. But I've
uploaded it as an example of where having the record type in the plain
did help; it allows a middle-layer to do sufficient protocol
validation to protect against a record-level flaw in the application's
record processing (such as Heartbleed).

Even having done that, this still seems like a mis-feature; especially
considering how bad leaking the alert type has been over the years.

-- 
Colm