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

Benjamin Kaduk <kaduk@mit.edu> Sun, 01 September 2019 23:58 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 052641200E0 for <tls@ietfa.amsl.com>; Sun, 1 Sep 2019 16:58:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxXPlln_Em8a for <tls@ietfa.amsl.com>; Sun, 1 Sep 2019 16:58:52 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4091E1200CD for <tls@ietf.org>; Sun, 1 Sep 2019 16:58:52 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (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, 1 Sep 2019 18:58:41 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: tls@ietf.org
Message-ID: <20190901235840.GN27269@kduck.mit.edu>
References: <20190830222401.GR84368@kduck.mit.edu> <948a07a6-87b1-9f91-d0a6-fa83a7a25e3d@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <948a07a6-87b1-9f91-d0a6-fa83a7a25e3d@cs.tcd.ie>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/jKtHlpAOwMJ1imr9yEpizRBf-ZU>
Subject: Re: [TLS] FYI: new TLS HandshakeType allocation, from draft-ietf-perc-srtp-ekt-diet
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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: 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.

-Ben