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

Eric Rescorla <ekr@rtfm.com> Mon, 02 September 2019 00:09 UTC

Return-Path: <ekr@rtfm.com>
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 0DD051200E0 for <tls@ietfa.amsl.com>; Sun, 1 Sep 2019 17:09:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 csArww2v7SMU for <tls@ietfa.amsl.com>; Sun, 1 Sep 2019 17:09:35 -0700 (PDT)
Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 440F5120142 for <tls@ietf.org>; Sun, 1 Sep 2019 17:09:35 -0700 (PDT)
Received: by mail-lj1-x231.google.com with SMTP id l14so11228725lje.2 for <tls@ietf.org>; Sun, 01 Sep 2019 17:09:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zbgKQ8fhjuJbGVA1Y3Lm9eMz8BbkexnGqWBh8pIUD+U=; b=Jj4sD45ydFqwKsFqISeEupyHpMvDd9bagtGTyEKN2w+huQpG0SSZBDh86GR4DkMVSq Bqrlnz+NUVfbI4Cm6D3x+y0A9H81sxWCUP1wDNMqJ8EkVvoVzUDHttfSCsG4XuXuxvUL Gh57bsWA3AjkN+uyGwTIzqvGKvpCtSvvGjA/Y6PEdiFAn/4xcOUNhHvefcTxABnMIK4B 9/nqwcxSyAZ9+OJUCoGtSFTG1cfAuJPxMjjJuJCLO253SPR8Ix2bCScL/+heBLqEyD8H bYBLvTFYBITh5T1S6s0Bmv3FAtPZ840WOAiTondLYO8r1GGyc4jRdCU7EJCxhO2aL3aY tw+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zbgKQ8fhjuJbGVA1Y3Lm9eMz8BbkexnGqWBh8pIUD+U=; b=MaUgU1uaGFDWHrd7WwwPBDyroIF5Iswbr2pJgO0GAV7lTxuOAlA6s7IyPGjqFYOZjF nLPrpegyOJLEAvzN1p5O7SQiCaFue9hIL69XsUoWffZV+xWzyzTf3KHqMeKqza6t+66B R1LA+4WpMZBDM2E8SDALJtXJfJsNUIvWLuKQXDsilOzBMf4UMQUQUx9i00W6C16c01w+ kpwmJd1OQJ3Jokd6jQLlnK/L+TuMHJVtPKladSN4c4VU7sIUEvk4kQPVYCQTdQuDyZJz gNz8fjbEplhUpQF4XavhEG7VVVdrwJZrJyeW0L1Z+XtLw4KXgPVBAdLpUxjDe9yOPzDL fwQA==
X-Gm-Message-State: APjAAAXHi2ytSz6tHkPFqAwDo9oQMCUB3qf0BmVjGZbjl9bcy2waeF7X NgCol4P8In7WOHFdhQl4I/bKjKSmhvw0WCI5vsy4mg==
X-Google-Smtp-Source: APXvYqzJ4LJ8yW7Qhlwx1crXFWvyhsa6YK7fDRymRdN0KxOPA9UonAfCw6WEYobKzDCgJIeaWaG0LuCVOeaPlF5ZQ14=
X-Received: by 2002:a2e:b0e6:: with SMTP id h6mr13778556ljl.18.1567382973599; Sun, 01 Sep 2019 17:09:33 -0700 (PDT)
MIME-Version: 1.0
References: <20190830222401.GR84368@kduck.mit.edu> <948a07a6-87b1-9f91-d0a6-fa83a7a25e3d@cs.tcd.ie> <20190901235840.GN27269@kduck.mit.edu>
In-Reply-To: <20190901235840.GN27269@kduck.mit.edu>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 1 Sep 2019 17:08:57 -0700
Message-ID: <CABcZeBNuTcLSrvrhxmpOPKBxPab1UZPs4t5jc-ie8GzMqmUkLA@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005e62d6059186c91c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/H7QqHAsmF4RBE0HzJrBUxVQ6vg0>
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: Mon, 02 Sep 2019 00:09:43 -0000

On Sun, Sep 1, 2019 at 4:59 PM Benjamin Kaduk <kaduk@mit.edu>; wrote:

> 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.
>

It's of course worth noting that extensions in general are not subject to
any kind of IETF approval, but merely to Specification Required.  Only the
Recommended flag requires IETF approval.

This document is different in that it registers a Handshake Type, and those
are subject to Standards Action, so one might argue that a higher degree of
analysis is required. I'm not sure how practical that would be in this
case. One compromise would perhaps be to demonstrate that this did not
weaken TLS itself?

I would be interested in Richard Barnes's thoughts.

-Ekr


> -Ben
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>