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

Colm MacCárthaigh <> Mon, 14 July 2014 17:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C15541A8BB7 for <>; Mon, 14 Jul 2014 10:51:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.678
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HmRta5QL_7VW for <>; Mon, 14 Jul 2014 10:51:33 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D0BE81A854D for <>; Mon, 14 Jul 2014 10:51:33 -0700 (PDT)
Received: by with SMTP id wp4so2607132obc.15 for <>; Mon, 14 Jul 2014 10:51:33 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 with SMTP id sw4mr5001484oeb.72.1405360293244; Mon, 14 Jul 2014 10:51:33 -0700 (PDT)
Received: by with HTTP; Mon, 14 Jul 2014 10:51:33 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Mon, 14 Jul 2014 10:51:33 -0700
Message-ID: <>
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= <>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [TLS] proposal to encrypt ContentType for TLS 1.3
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 14 Jul 2014 17:51:35 -0000

On Mon, Jul 14, 2014 at 9:10 AM, Martin Rex <> 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:

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.