IETF Logo Mail Archive

Re: [MMUSIC] k= and draft-ietf-mmusic-rfc4566bis

Eric Rescorla <ekr@rtfm.com> Tue, 12 September 2017 22:34 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E274133169 for <mmusic@ietfa.amsl.com>; Tue, 12 Sep 2017 15:34:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 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_LOW=-0.7] 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 YF8h5l7TUSqB for <mmusic@ietfa.amsl.com>; Tue, 12 Sep 2017 15:34:06 -0700 (PDT)
Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 E46B4133164 for <mmusic@ietf.org>; Tue, 12 Sep 2017 15:34:05 -0700 (PDT)
Received: by mail-oi0-x232.google.com with SMTP id z73so33112378oia.2 for <mmusic@ietf.org>; Tue, 12 Sep 2017 15:34:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8U8YlFcuVMtLqRSnuNUWPKY73ABYMNG6h9VI1Lj8T8s=; b=WqNoz8lhmy6qGoZqKOcPVVXZNzGviA1ZgBzmQQP6orli07uClFwEyArZP2uEoDM5nN ctI92d2zLDyNpwOYtjSp0JhyP1Z4V/D67oXsIaYJd85DFqRnXs1fVS4TPF3FRBbPKFko CQfRrvl79Lu6w8gSbHFUlX6JUqS+4ztqtqb+voToadoEF5KW3sRAdcG93cn4RNffRd2J BeN3UpPLPNyB7b71bsi1nbSBDV9xf1oQQ7XuiztSEfb8pj56NMmNPqnyPI4eH5A3CC8j xsVZRJidowLcI7bPz5gSHbjBOc7nTCZORPsgzn15CksmxnUC1bi4SdmhNGlXt8UOI60a YW4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8U8YlFcuVMtLqRSnuNUWPKY73ABYMNG6h9VI1Lj8T8s=; b=QGkG/9XRc1rJRerTm2edUId1kR6sBXy5q97HxydxeCErxMQrKGijmJ8IzhQXX6GEY0 aoW0PyM9a8lNkStho/zYLLpBI6lBeRZLXmuV7U2Ta3GL39v6JTtI4ilEKnC7G+CFQott zvrXl5KkMen7ty4YnzZJ7JqgAsAGKi7e8qDU53BUuzWZiEegKvBO6MD7e5664SMJX+Yt QwSM3B2C+HusrmZ7yyvqISL+99N/kUvsWJusytwW/a7NAXmq6zDx58fB5LZLW+vJ2Pb7 8CBAuT3ESBjGVuhA19lhJjiPEXD/Hg6XAK47aT4H4+gvpHxbB3E5jyqbLF+lNehkv7em jQqw==
X-Gm-Message-State: AHPjjUhHP8UOQSUZzgEJ1Bs8uEid6ZnolOCRgfVOsYd9iKf4Rk1Sxjf6 8AnbujvxF7/RvI4V9wNSlK1EaBH7Dsse
X-Google-Smtp-Source: AOwi7QCSghfN3wVYmy5KAJeSd+eJ3bEqYRMYnrzoCsJFnnSOFNvZo2PYabuOpvJYZmjK4oXfZEuh5rPAuWAwns88A8Q=
X-Received: by 10.202.224.130 with SMTP id x124mr15428755oig.100.1505255645267; Tue, 12 Sep 2017 15:34:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.168.10.71 with HTTP; Tue, 12 Sep 2017 15:33:24 -0700 (PDT)
In-Reply-To: <D2EF444B-7855-4DC9-9BA1-93E295ADA202@csperkins.org>
References: <619B81B4-C645-4F2F-9B4B-A4D1D95AC440@iii.ca> <CAA4Mczv3Fo=KDu3mqv1KSjO98LcdHnHX5X9rMaaQi7ofVGBNRA@mail.gmail.com> <D1D3622B-443F-4610-AB6C-370A6A70DCAC@csperkins.org> <a9fb09c2-1df6-adb7-5037-4c3c20172a3e@ntlworld.com> <FE94E577-EAD6-4A62-82FB-F317C3AACBC9@iii.ca> <391958c8-7881-1223-f8c1-44ba55138af6@alum.mit.edu> <D2EF444B-7855-4DC9-9BA1-93E295ADA202@csperkins.org>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 12 Sep 2017 15:33:24 -0700
Message-ID: <CABcZeBMjTXbhUo8K+-KmRWMU+W4bV=hGLWmmOerhQvs1XzHgrg@mail.gmail.com>
To: Colin Perkins <csp@csperkins.org>
Cc: Paul Kyzivat <pkyzivat@alum.mit.edu>, mmusic WG <mmusic@ietf.org>
Content-Type: multipart/alternative; boundary="001a113d376a085f10055905a4e4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/lXYlNNQvgvw6pFRPBbXAn-ifctQ>
Subject: Re: [MMUSIC] k= and draft-ietf-mmusic-rfc4566bis
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Sep 2017 22:34:08 -0000

This seems like a fine resolution to me.

On Tue, Sep 12, 2017 at 2:32 PM, Colin Perkins <csp@csperkins.org> wrote:

>
> > On 12 Sep 2017, at 16:42, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
> >
> > On 9/12/17 10:03 AM, Cullen Jennings wrote:
> >> First, I don't feel strongly about this and glad to go with whatever
> Colin wants ... but what I was thinking ....
> >> k= is still defined by RFC4566 and things that implement RFC4566 still
> use it. I don't think we have an IANA table for this but if we do, the IANA
> registry still lists it with the reference for it as RFC4566.
> >> This bis draft becomes a new RFCAAAA and RFCAAAA does not mention k=
> one way or another. If something that implements RFCAAAA receives a k=
> line, it gets treated just like any other unknown line and is ignored.
> >> There not enough advice on how to use the k= stuff to expect
> interoperable implementation of any type of security that the IETF would
> currently consider acceptable to publish as a standard. Anyone who uses k=
> is very unlikely to be upgrading their software to RFCAAAA. I just don't
> see anything good that comes of putting this in the new RFC and it just
> adds to the confusion of how to secure RTP.
> >
> > One thing: if all mention of k= is removed from the bis, then in the
> (far) someone who is defining a new line might choose k= for it.
> (Admittedly this is pretty far fetched.)
> >
> > I think a cleaner way to handle this would be to deprecate k= in the bis.
>
> I’d not object if the text in 4566bis was changed to:
>
> ================
> 5.12.  Encryption Keys ("k=")
>
>       k=<method>
>       k=<method>:<encryption key>
>
>
>   The “k=“ line is obsolete and MUST NOT be used.
>
> 5.13.  Attributes (“a=“)
> …
> ================
>
> …or something similar. I just don’t think we can remove it entirely.
>
>
> --
> Colin Perkins
> https://csperkins.org/
>
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>

v2.23.0 | Report a Bug | By Email