From: Dave Garrett <davemgarrett@gmail.com>
To: tls@ietf.org
Date: Wed, 6 Jul 2016 20:24:46 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <CAOgPGoA2RmAUMR=4bOOwepSSdrJ2tUGD1B+hieQzZaRVnwXo=A@mail.gmail.com>
 <A2C29D69-FF97-4C16-941B-87C0022C6362@gmail.com>
 <CAF8qwaC+iXoJ_Z9xuB4UqR4-7EmXUmr2pRRcBDxtDP-eZ8LzAg@mail.gmail.com>
In-Reply-To: <CAF8qwaC+iXoJ_Z9xuB4UqR4-7EmXUmr2pRRcBDxtDP-eZ8LzAg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201607062024.46745.davemgarrett@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/mSJizmCXsij0PQ1d-hBiyMuUpE0>
Subject: Re: [TLS] judging consensus on keys used in handshake and data
 messages
Precedence: list

On Wednesday, July 06, 2016 06:19:29 pm David Benjamin wrote:
> I'm also curious which post-handshake messages are the problem. If we were
> to rename "post-handshake handshake messages" to "post-handshake bonus
> messages" with a distinct bonus_message record type, where would there
> still be an issue? (Alerts and application data share keys and this seems
> to have been fine.)

Recasting all the post-handshake handshake messages as not something named "handshake" does make a degree of sense, on its own. (bikeshedding: I'd name it something more descriptive like "secondary negotiation" messages or something, though.) Even if this doesn't directly help with the issue at hand here, does forking these into a new ContentType sound like a useful move, in general?


Dave