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

Benjamin Kaduk <kaduk@mit.edu> Fri, 30 August 2019 23:05 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 D51261200A3 for <tls@ietfa.amsl.com>; Fri, 30 Aug 2019 16:05:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 dhYk9IeMvJRv for <tls@ietfa.amsl.com>; Fri, 30 Aug 2019 16:05:24 -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 2DAEA120073 for <tls@ietf.org>; Fri, 30 Aug 2019 16:05:23 -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 x7UN5JTY009593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 30 Aug 2019 19:05:21 -0400
Date: Fri, 30 Aug 2019 18:05:18 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Watson Ladd <watson@cloudflare.com>
Cc: tls@ietf.org
Message-ID: <20190830230518.GT84368@kduck.mit.edu>
References: <20190830222401.GR84368@kduck.mit.edu> <CAN2QdAFYnRZ8SQ10pdce4nDhUK53Q5T6Kvc_XrzYQR7s+QTeBg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAN2QdAFYnRZ8SQ10pdce4nDhUK53Q5T6Kvc_XrzYQR7s+QTeBg@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/fmHjWmVFsjGQpTHuvVfxeXJ9i18>
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: Fri, 30 Aug 2019 23:05:26 -0000

On Fri, Aug 30, 2019 at 03:57:23PM -0700, Watson Ladd wrote:
> On Fri, Aug 30, 2019 at 3:24 PM Benjamin Kaduk <kaduk@mit.edu>; 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".
> 
> Design issues: Am I reading the doc right, that this handshake message
> goes after the finished? And then contains a key that is used to
> decrypt another key that is then used to decrypt (some) traffic, but
> doesn't change the DTLS keys? Why is this a handshake message and not

I think that's "yes" on all counts.

> some protocol framing in the protocol carried over DTLS? It just seems
> funny to make it be a handshake type and not something else. It's
> entirely possible this makes more sense if you know about DTLS-SRTP
> which I do not very much.

I don't consider myself an SRTP expert, but I think to zeroth order you can
model DTLS-SRTP as being a single "hybrid" protocol that takes the DTLS
handshake for key exchange and slots in a SRTP message-protection layer
that is analogous to the traditional TLS Record layer.  RFC 5764 even has a
pretty picture: https://tools.ietf.org/html/rfc5764#section-4.1 .

If you consider the "DTLS-SRTP hybrid protocol", then this new
HandshakeType becomes a way for the handshake layer to supply cryptographic
input to the SRTP record layer, which is not so crazy of a request.

You're right, of course, that it could be done in some protocol framing at
the DTLS application data layer or within the SRTP framing layer, but I'm
pretty confident that the authors/WG have considered those options and
still picked this one.

That said, I'm pretty sure some people who are more familiar with that
history than me are on this list, and hopefully not afraid to chime in and
correct me or clarify as needed.

Thanks for looking,

Ben