Re: [clue] Eric Rescorla's No Objection on draft-ietf-clue-signaling-14: (with COMMENT)

Eric Rescorla <ekr@rtfm.com> Mon, 03 December 2018 00:49 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: clue@ietfa.amsl.com
Delivered-To: clue@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B063130DE8 for <clue@ietfa.amsl.com>; Sun, 2 Dec 2018 16:49:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.358
X-Spam-Level:
X-Spam-Status: No, score=-3.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable 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 XPXdict_L5sU for <clue@ietfa.amsl.com>; Sun, 2 Dec 2018 16:49:36 -0800 (PST)
Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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 B77E5130DE7 for <clue@ietf.org>; Sun, 2 Dec 2018 16:49:35 -0800 (PST)
Received: by mail-lj1-x233.google.com with SMTP id s5-v6so9710190ljd.12 for <clue@ietf.org>; Sun, 02 Dec 2018 16:49:35 -0800 (PST)
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=lIz6J9G0eYbc2M9X3ZH7sdoDACbNxip5j47WNRZe9CE=; b=0iqZT/raa3nJDPoMlBvMJjr10CJ3677187hwuaeY+5vor7SXjsLj0ZTIs4WJ6TOGy/ koibIccXtTHP8wbM1mC9FG28b4eWPasfIuFe61H3E5YxvKkrsJYyL5sZ4ggXDsyuc9zJ 21rix3LGv99YmSRb3f6EzZjCokLUCTgu78lmhtUJi8/ffbmxMlWD5WDsBb8EUGYM3p2H lwTPLBWXhx+VXh3BwGr2QOpUUOgToQBLoD1olZyrx3Hp1IJ+d74EZ/w5F30ZtGyd5k2s aNLQCdsrR+LsKuKeuBHbU0DiyBH0uRCRN0l8lf4ddDrnUnoMTL9eNNrVOvW4F8Y+c45B o88A==
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=lIz6J9G0eYbc2M9X3ZH7sdoDACbNxip5j47WNRZe9CE=; b=ICRBb2XCXESRiWOhiAO9T8oPo92LoQgF/ixWfk4IeiP2G4iKAseEEQoE31MIGEmumT P8J2AIrpPyib868RSt69VWpvgEUNrW/MRN7ct4HGsGswFj8YA/UcvXeHj1upaDKC3npT n1ZtRIZ40DConvQRGC2ycyyiUkkbMNm6W155lzYXQC0PcLiXCMjYm7yxIKKnRRca5rwE xPCHBh35VU/Iz6plORKs2BFuwXvDzDm0hMSnwqj04mYN12yl9bxT8JAxfKVJY2nA9Bks ZLnnN+km0OHwWJDNmAlBI9QxZwUnRkJugoH7bTQLYTN2XivpgPGWOV6QEAizg3D3cPdH fFFw==
X-Gm-Message-State: AA+aEWYOEFJFQkMbikuoqPdxJrMSc4qpQwfv0l3Ak/Sp0A0xh9Dff1k0 ZlkLTsDVyzyX5O6/fomWSva1kEG2lIqvC0njfpkORg==
X-Google-Smtp-Source: AFSGD/XQ3iTkTsgxqDriCxZaoEuwzQiobDxPuGrh47eHXLiLLOaOs7/648t0gVtu3BatSh+x5H/aFg5iCes+owl0iuc=
X-Received: by 2002:a2e:3218:: with SMTP id y24-v6mr9625231ljy.157.1543798174044; Sun, 02 Dec 2018 16:49:34 -0800 (PST)
MIME-Version: 1.0
References: <154268892146.26648.17870778354406192041.idtracker@ietfa.amsl.com> <6E58094ECC8D8344914996DAD28F1CCD18C762DF@DGGEMM506-MBX.china.huawei.com> <CABcZeBMcQxZuRUFx=tz==C5eCc8zNBrxkKaZfBa+gYnyaV3FOQ@mail.gmail.com> <6E58094ECC8D8344914996DAD28F1CCD18C7B5DE@DGGEMM506-MBS.china.huawei.com> <CABcZeBOPPojS2zsR6uZCagcs7yBBmtMW9rcyPw_gEK44u7GH1w@mail.gmail.com> <b9922f72-932c-a509-95c2-c86765d5ce6d@alum.mit.edu> <CABcZeBNb4nG7U9KdMLCT8f4oOYXqWydM_1JQPbfceSu31+Bg1A@mail.gmail.com> <e8a805d2-762d-6cd7-bed5-4518e943453c@alum.mit.edu> <8524dc46c43e4f5084fbbd2e566f9c28@XCH-RCD-016.cisco.com> <CABcZeBNwvzJ98qrCW6tiTozBsKiGJEnVi5MBQz32Udrizp180Q@mail.gmail.com> <1648CE33-0DFB-487A-9C11-F78945F30844@ericsson.com>
In-Reply-To: <1648CE33-0DFB-487A-9C11-F78945F30844@ericsson.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 02 Dec 2018 16:48:56 -0800
Message-ID: <CABcZeBMHgJeJKKZQV6d7MMbg=1ahxgKOOQ1gmnepnQUTsooVWw@mail.gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: rohanse2@cisco.com, clue@ietf.org, roni.even@mail01.huawei.com, IESG <iesg@ietf.org>, clue-chairs@ietf.org, draft-ietf-clue-signaling@ietf.org
Content-Type: multipart/alternative; boundary="000000000000c4e7e8057c138594"
Archived-At: <https://mailarchive.ietf.org/arch/msg/clue/-2HS_-zIN25lUsOo2XXHxdpKuqQ>
Subject: Re: [clue] Eric Rescorla's No Objection on draft-ietf-clue-signaling-14: (with COMMENT)
X-BeenThere: clue@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: CLUE - ControLling mUltiple streams for TElepresence <clue.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/clue>, <mailto:clue-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/clue/>
List-Post: <mailto:clue@ietf.org>
List-Help: <mailto:clue-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/clue>, <mailto:clue-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Dec 2018 00:49:41 -0000

On Sun, Dec 2, 2018 at 3:32 AM Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Hi,
>
>
>
> Would requiring SRTP be an option? Note that CLUE has been adopted (many
> years ago) in environments where usage of DTLS-SRTP is not defined.
>

That would unfortunately not solve the consent problem.

-Ekr


>
> Regards,
>
>
>
> Christer
>
>
>
> *From: *clue <clue-bounces@ietf.org> on behalf of Eric Rescorla <
> ekr@rtfm.com>
> *Date: *Tuesday, 27 November 2018 at 17.12
> *To: *Robert Hansen <rohanse2@cisco.com>
> *Cc: *"clue@ietf.org" <clue@ietf.org>, Roni Even <
> roni.even@mail01.huawei.com>, "iesg@ietf.org" <iesg@ietf.org>, "
> clue-chairs@ietf.org" <clue-chairs@ietf.org>, "
> draft-ietf-clue-signaling@ietf.org" <draft-ietf-clue-signaling@ietf.org>
> *Subject: *Re: [clue] Eric Rescorla's No Objection on
> draft-ietf-clue-signaling-14: (with COMMENT)
>
>
>
>
>
> On Tue, Nov 27, 2018 at 1:55 AM Rob Hanton (rohanse2) <rohanse2@cisco.com>
> wrote:
>
> We did have specific protections as mandantory to use in earlier drafts.
> From version 05:
>
>    ... discussion of video hammer attack ...
>    This attack can be prevented by ensuring that the media recipient
>    intends to receive the media packets.  Because of the way that CLUE
>    can increase the severity of this attack, as well as because of the
>    general increased awareness of the need to secure critical payloads,
>    a CLUE-capable device MUST secure all CLUE-controlled RTP "m" lines
>    using SRTP [RFC3711], and MUST support and use key negotiation and
>    receiver intent assurance via DTLS [RFC5763] on these "m" lines.  For
>    backwards compatibility, this is not a mandatory requirement for non-
>    CLUE-controlled "m" lines.
>
>
> https://datatracker.ietf.org/doc/draft-ietf-clue-signaling/05/?include_text=1
>
> This was then changed in version 06 and onwards following the discussion
> at IETF 92 and later where there was opposition to making the use of
> DTLS/SRTP mandatory to use. If I recall the two major concerns people had
> were:
> 1) This prevents implementations using a superior mechanism should one be
> developed
>
>
>
> I don't think this is a real objection, If a new mechanism should be
> developed, then presumably it would also be documented in an RFC and we
> could update this one.
>
>
>
> 2) This prevents two devices from the same vendor using some alternate
> means of authentication (potentially proprietary) that would reduce the
> need for DTLS/SRTP
> (Minutes: https://datatracker.ietf.org/doc/minutes-92-clue/ )
>
>
>
> It's not a matter of authentication. It's a matter of path validation. For
> instance, if you were to have a situation where you had a cryptographic key
> but it did not have an interactive handshake, that would not provide the
> correct function. By contrast, ICE would.
>
>
>
>
>
> So while everyone agreed that DTLS/SRTP should be mandatory to implement
> so it was always available, consensus ended up being removing the
> requirement to use DTLS/SRTP and instead having more generic language:
>
>    This attack can be prevented by ensuring that the media recipient
>    intends to receive the media packets.  As such all CLUE-capable
>    devices MUST support key negotiation and receiver intent assurance
>    via DTLS-SRTP [RFC5763] on CLUE-controlled RTP "m=" lines.  All CLUE-
>    controlled RTP "m" lines must be secured and implemented using
>    mechanisms such as SRTP [RFC3711].  CLUE implementations MAY choose
>    not to require the use of SRTP to secure legacy (non-CLUE-controlled)
>    media for backwards compatibility with older SIP clients that are
>    incapable of supporting it.
>
> https://datatracker.ietf..org/doc/draft-ietf-clue-signaling/?include_text=1
> <https://datatracker.ietf.org/doc/draft-ietf-clue-signaling/?include_text=1>
>
>
>
> Yes, but the problem is that this doesn't require any kind of consent
> validation at all, which creates an unacceptable amplification risk.
>
>
>
> It seems to me that there are a number of options here:
>
>
>
> 1. Require DTLS-SRTP
>
> 2. Require ICE
>
> 3. Require *some* path-validating consent mechanism
>
>
>
> However, just leaving the amplification attack does not seem OK.
>
>
>
> -Ekr
>
>
>
>
>
> All drafts have always had an exception for non-CLUE-controlled lines for
> backwards compatibility.
>
> Rob
>
> -----Original Message-----
> From: Paul Kyzivat <pkyzivat@alum.mit.edu>
> Sent: 26 November 2018 19:49
> To: Eric Rescorla <ekr@rtfm.com>
> Cc: Roni Even <roni.even@huawei.com>; IESG <iesg@ietf.org>; Daniel
> Burnett <danielcburnett@gmail.com>; clue@ietf.org;
> roni.even@mail01.huawei.com; clue-chairs@ietf.org;
> draft-ietf-clue-signaling@ietf.org
> Subject: Re: Eric Rescorla's No Objection on draft-ietf-clue-signaling-14:
> (with COMMENT)
>
> On 11/25/18 2:29 PM, Eric Rescorla wrote:
> >
> >
> > On Sun, Nov 25, 2018 at 9:35 AM Paul Kyzivat <pkyzivat@alum.mit.edu
> > <mailto:pkyzivat@alum.mit.edu>> wrote:
> >
> >     On 11/25/18 8:14 AM, Eric Rescorla wrote:
> >      >
> >      >
> >      > On Sat, Nov 24, 2018 at 9:41 PM Roni Even (A)
> >     <roni.even@huawei.com <mailto:roni.even@huawei.com>
> >      > <mailto:roni.even@huawei.com <roni.even@huawei..com> <mailto:
> roni.even@huawei.com>>> wrote:
> >      >
> >      >     Hi,____
> >      >
> >      >     The point that is made that in general CLUE is similar to no
> CLUE
> >      >     RTP media calls. The difference is that since the EP may open
> >     more
> >      >     than one RTP video channel there is a greater risk of sending
> >     more
> >      >     media to the victim.
> >      >
> >      >
> >      > Yes, but in order to have a useful countermeasure, that needs to
> be
> >      > mandatory, and yours is not.
> >
> >     But one of the goals of clue is to be backward compatible with
> regular
> >     sip calls. If we impose constraints on the media over and above those
> >     required for regular sip calls then we lose that.
> >
> >
> > ISTM that that's already not true for these media flows, because 4..4.1
> > requires them to be inactive and you need to use an SCTP/DTLS control
> > channel to negotiate them.
> > What I'm saying is that those other flows should also have a consent
> > check
>
> I was more concerned with the basic audio and/or video in the initial
> invite, before it is known whether the answerer supports clue. I don't have
> a particular problem with putting further restrictions on the clue
> controlled media.
>
>         Thanks,
>         Paul
>
>