Re: [TLS] FYI: new TLS HandshakeType allocation, from draft-ietf-perc-srtp-ekt-diet

Benjamin Kaduk <> Sun, 01 September 2019 23:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 052641200E0 for <>; Sun, 1 Sep 2019 16:58:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NO_DNS_FOR_FROM=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gxXPlln_Em8a for <>; Sun, 1 Sep 2019 16:58:52 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4091E1200CD for <>; Sun, 1 Sep 2019 16:58:52 -0700 (PDT)
Received: from ([]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id x81NwfJK024315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 1 Sep 2019 19:58:45 -0400
Date: Sun, 01 Sep 2019 18:58:41 -0500
From: Benjamin Kaduk <>
To: Stephen Farrell <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <>
Subject: Re: [TLS] FYI: new TLS HandshakeType allocation, from draft-ietf-perc-srtp-ekt-diet
X-Mailman-Version: 2.1.29
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: Sun, 01 Sep 2019 23:58:54 -0000

On Sat, Aug 31, 2019 at 12:25:02AM +0100, Stephen Farrell wrote:
> Hiya,
> On 30/08/2019 23:24, Benjamin Kaduk wrote:
> > Hi all,
> > 
> > New values for core types like TLS HandshakeType and ContentType don't
> > happen very often, so I thought people might be interested to know that
> > draft-ietf-perc-srtp-ekt-diet (currently in IESG evaluation) is allocating
> > a HandshakeType, to carry key information used to encrypt SRTP media key
> > material.
> > Obviously "it's never too late to change until the RFC is published", but I
> > think there would need to be some pretty serious issues in order to change
> > it at this point, so this is expected to just be an "FYI".
> I guess I ought read the draft properly, but a scan
> of the draft doesn't seem to show any references to
> the kind of analyses that were done for tls1.3. I'm
> not clear why that's ok. Is there a reason why that
> is ok?

I don't remember hearing about substsantial formal analysis, though I do
note that the draft acknowledges that (at best) it has the security
properties of a shared symmetric group key, given the nature of the setup.
I think we may need to be in Viktor's "raise the ceiling, not the floor"
mindspace here.

> It was great that many people worked to do security
> proofs for tls1.3. It'd be a shame to lose that via
> extensions that are less well analysed.

My crystal ball went missing, but I kind of expect lots of pitchforks if
the security ADs tried to insist on formal analysis of any TLS extension,
especially ones produced from non-security-area groups.