Re: [Tsv-art] [tram] Tsvart last call review of draft-ietf-tram-turnbis-25

Joe Touch <touch@strayalpha.com> Tue, 18 June 2019 14:32 UTC

Return-Path: <touch@strayalpha.com>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA41C1201D0; Tue, 18 Jun 2019 07:32:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.208
X-Spam-Level:
X-Spam-Status: No, score=-1.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 zf8erNt-3uwp; Tue, 18 Jun 2019 07:32:42 -0700 (PDT)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 3BB3A1201DB; Tue, 18 Jun 2019 07:32:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=3ve/+S8iwukY0Ts4KWkcVbqQItLjzoFX0nsApsE1UqE=; b=0u7QQui3zBidpOc10gYvEq5lA +tCNn6+2UROxcmo6Ppoj79B0IFBBUAEn1yR01KlkP74iIyib+hXp+u/0XDIVofWed1VttcK0JNyBd dFybGrrpqKxsChu2I9DO0eVN3mjy0B8bwoFfIkEZU5xlhYNf73JV5EFfFA0xkthHo6y1u+Vdznrur nh66kyN1TB+pvpm//v9I+a1sOvu5zyPZQ7SHg2Y3JEEkjmpM+2TWek78PMmBiCsM/gqMusexPbk7d 4kG3vFVOYNEA6M15jKyoYxOxMK09AwlIo4f6E5STN4rzWkUxvO0otOByFEgGLv2WJe8aFk5WAae2I APicZHyLA==;
Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:52060 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <touch@strayalpha.com>) id 1hdFA5-001h37-Hh; Tue, 18 Jun 2019 10:32:41 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_7AB12BEB-7235-4197-A789-215EED9C16C3"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joe Touch <touch@strayalpha.com>
In-Reply-To: <HE1PR0701MB2522C0A1063877D45985619795EA0@HE1PR0701MB2522.eurprd07.prod.outlook.com>
Date: Tue, 18 Jun 2019 07:32:35 -0700
Cc: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>, "tsv-art@ietf.org" <tsv-art@ietf.org>, "draft-ietf-tram-turnbis.all@ietf.org" <draft-ietf-tram-turnbis.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, Brandon Williams <brandon.williams@akamai.com>, "tram@ietf.org" <tram@ietf.org>
Message-Id: <BD41AC2D-3925-4E11-B1EC-AD24680376AE@strayalpha.com>
References: <155971464360.28104.6837263931145163343@ietfa.amsl.com> <F306B122-79F3-4C7A-8CE2-1C094D9F0FCC@strayalpha.com> <DM5PR16MB1705A4C370C4405AFFD63546EA100@DM5PR16MB1705.namprd16.prod.outlook.com> <5F2F8A3B-2887-4107-81E2-B4E222A4044E@strayalpha.com> <DM5PR16MB1705BD4E31370D2F5A179F17EA130@DM5PR16MB1705.namprd16.prod.outlook.com> <2C6B5776-CB95-4607-8D0C-07FDE2F6D515@strayalpha.com> <DM5PR16MB1705638AD29F3288E4AC0952EAED0@DM5PR16MB1705.namprd16.prod.outlook.com> <HE1PR0701MB252250AE4E7C158F985B0CC895ED0@HE1PR0701MB2522.eurprd07.prod.outlook.com> <D9A01E28-F9FB-4C86-AFD3-A2BA8D89C340@strayalpha.com> <a3bbeb17-e768-9ab2-9f34-3d179fa8fe38@akamai.com> <E41C125D-F3B4-475E-8AD0-124F531F1DC9@strayalpha.com> <DM5PR16MB170564C0438321CC3FDD0ACFEAEF0@DM5PR16MB1705.namprd16.prod.outlook.com> <4C41A2BC-0CBC-42D5-B313-22F9A9D51F6E@strayalpha.com> <DM5PR16MB1705874C023145D26DCB58E6EAEE0@DM5PR16MB1705.namprd16.prod.outlook.com> <edcd66c2-0dfb-8f89-d6a3-53482c433d4e@strayalpha.com> <DM5PR16MB17057CCD4D2543D84254EFD1EAEB0@DM5PR16MB1705.namprd16.prod.outlook.com> <HE1PR0701MB2522DCB2459055A6319C439B95EA0@HE1PR0701MB2522.eurprd07.prod.outlook.com> <DM5PR16MB1705E3EF8260B456A9B02C10EAEA0@DM5PR16MB1705.namprd16.prod.outlook.com> <HE1PR0701MB2522C0A1063877D45985619795EA0@HE1PR0701MB2522.eurprd07.prod.outlook.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
X-Mailer: Apple Mail (2.3445.9.1)
X-OutGoing-Spam-Status: No, score=-0.5
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/CTxpH6T4X3cWbXsXmrncUnr3DD0>
Subject: Re: [Tsv-art] [tram] Tsvart last call review of draft-ietf-tram-turnbis-25
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Jun 2019 14:32:50 -0000


> On Jun 18, 2019, at 6:47 AM, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
> 
>> [TR] The comment from Joe is : if TCP-AO is used, application data is authenticated in the TCP leg but the data can be faked when relayed from the server to the peer using UDP. I tried to address this comment by saying if secure application data (SRTP) is used message authentication is available at the application layer even if UDP does not support authentication option.
>> 
> Sure, but this is equivalent to the case of TURN over TCP/TLS that also only have the security model to the middle. So pointing that aspect out is fine, but I think TURN is quite clear on that client to peer security are the responsibility of the end-to-end application using TURN. Like the statement in the Third paragraph of 20.1.4:
> 
>    These attacks are more properly mitigated by application-layer
>    authentication techniques.  In the case of real-time traffic, usage
>    of SRTP [RFC3711] prevents these attacks.

FWIW, even with this statement, if you’re going to talk about preserving IP options and settings then it’s equally important to discuss how you preserve or interfere with TCP options and settings - and maybe other layers like TLS too - in the same place in the document.

It’s not just whether this is a security issue; it’s that the semantics are broken in half.

Joe