Re: [tram] Adam Roach's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Sun, 07 October 2018 20:27 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0676A1292AD; Sun, 7 Oct 2018 13:27:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 zk7Xml7cDapu; Sun, 7 Oct 2018 13:27:35 -0700 (PDT)
Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 E5CE2124D68; Sun, 7 Oct 2018 13:27:34 -0700 (PDT)
X-AuditID: 1209190f-2bfff700000069a2-6c-5bba6c34c5cc
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 0F.67.27042.53C6ABB5; Sun, 7 Oct 2018 16:27:33 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w97KRRhS006411; Sun, 7 Oct 2018 16:27:28 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w97KRJFo031990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 7 Oct 2018 16:27:23 -0400
Date: Sun, 7 Oct 2018 15:27:19 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Marc Petit-Huguenin <marc@petit-huguenin.org>
Cc: Adam Roach <adam@nostrum.com>, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>, The IESG <iesg@ietf.org>, tram-chairs@ietf.org, draft-ietf-tram-stunbis@ietf.org, Tolga Asveren <tasveren@rbbn.com>, tram@ietf.org
Message-ID: <20181007202719.GD56675@kduck.kaduk.org>
References: <152403138853.31946.14807823535362928987.idtracker@ietfa.amsl.com> <27cb2f70-d907-b61f-bb5a-6b19053238fe@petit-huguenin.org> <1e8cd5de-06de-6745-fc4d-d15fcdd0b4d9@petit-huguenin.org> <df27ff82-bb5a-8c83-f119-a6f4e9f65a53@nostrum.com> <a5da7dc3-472c-8dcf-27e0-7e334d6590f6@ericsson.com> <5ff10fb0-301e-5d97-01b0-f15296bae0d3@nostrum.com> <b845eb08-7974-ec9d-0a98-e04d6071b2e1@petit-huguenin.org> <20180909014711.GT73164@kduck.kaduk.org> <49512499-0e71-1f5b-e12c-213a3dd88d91@petit-huguenin.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <49512499-0e71-1f5b-e12c-213a3dd88d91@petit-huguenin.org>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNKsWRmVeSWpSXmKPExsUixG6nomuasyva4MNfNYs9fxexW3Ruucxm sWn5SiaLGX8mMlusPX6T0WL98m/sFst/rmSz+LD2ApsDh8evr1fZPJYs+cnkMWvnExaP46ev s3rsmTOJMYA1issmJTUnsyy1SN8ugSvjweapbAXXpSvuHTrK2sC4T7SLkZNDQsBEYu/fKUwg tpDAYiaJ533ZXYxcQPYGRonzh96wQzhXmCS+TpvO3MXIwcEioCIxZZYZSAMbkNnQfZkZxBYR MJQ4v+g6M0g9s8BfRokv236ygSSEBVIkjj6YwATSywu0bfeaTIiZnSwSXYcus4PU8AoISpyc +YQFxGYW0JHYufUOG0g9s4C0xPJ/HBBheYnmrbPBdnEKuEn8b94LZosKKEvs7TvEPoFRcBaS SbOQTJqFMGkWkkkLGFlWMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Zro5WaW6KWmlG5iBMULpyT/ DsY5Dd6HGAU4GJV4eBmCd0ULsSaWFVfmHmKU5GBSEuU9sWFntBBfUn5KZUZicUZ8UWlOavEh RgkOZiUR3k9BQDnelMTKqtSifJiUNAeLkjjvhJbF0UIC6YklqdmpqQWpRTBZGQ4OJQne21lA ewSLUtNTK9Iyc0oQ0kwcnCDDeYCGvwCp4S0uSMwtzkyHyJ9i1OVoe3p9BrMQS15+XqqUOG8i SJEASFFGaR7cHFCak8jeX/OKURzoLWFeu2ygKh5gioSb9ApoCRPQkt8JO0CWlCQipKQaGK0X u10XUk7Mt7ydG5zOu2P288N1c84LstiGLH47Z9fhqIsh53ftCQgKNJxsnvR3tmLyMktBI6U3 s/0Kg92/8VZ/nfRP0HC6tN7Km18aXjKq+ZqvW2EXdf9Ndck/o3oeDyf52EW9G4Jn1ylkPn/6 WCJsBkNIfM6X5nPlrcKrXLbqmvwqnv5lkhJLcUaioRZzUXEiAGItZmBOAwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/fjC_30nEWn-MSy9luo7E00QoIxM>
Subject: Re: [tram] Adam Roach's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT)
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Oct 2018 20:27:37 -0000

Hi Marc,

On Sun, Oct 07, 2018 at 05:47:54AM -0700, Marc Petit-Huguenin wrote:
> Hi Benjamin,
> 
> See inline.
> 
> On 09/08/2018 06:52 PM, Benjamin Kaduk wrote:
> > Hi Marc,
> > 
> > On Sat, Sep 08, 2018 at 02:59:41PM -0700, Marc Petit-Huguenin wrote:
> >> Hi Adam,
> >>
> >> Apologies for the delay in working on that.
> >>
> >> For the first issue, the fix is in my copy of the draft.
> >>
> >> As for the second issue, Section 8.1 says:
> >>
> >> 'A "stuns" URI
> >>  containing an IP address MUST be rejected, unless the domain name is
> >>  provided by the same mechanism that provided the STUN URI, and that
> >>  domain name can be passed to the verification code.'
> >>
> >> That text was never about IP addresses in certificates, but about the way a STUN (or TURN really, but that draft does not care about TURN) server IP address is passed to a WebRTC browser.  RFC 7064 permits to store an IP address directly inside a stun URI, and RFC 7350 extended that to stuns URI, and in fact the text above is directly copied from RFC 7350.
> >>
> >> The idea is that a stun URI can be provisioned by a JavaScript program
> >> downloaded by a WebRTC browser as part of the initialization of a WebRTC
> >> application.  A security assumption is that using a stuns URI that
> >> contains an API address is safe if the Javascript program was downloaded
> >               ^^^
> > (I assume this is autocorrect picking the wrong thing to fix a typo and
> > should be "IP Address")
> 
> Yes.  But no auto-correct feature was to blame in that case.
> 
> > 
> >> using https, that the hostname verification for the https certificate
> >> implies that the stuns URI embedded in the document are receiving
> >> adequate protection and can be used without worrying about the lack of
> >> certificate verification for the stuns URI.
> >>
> >> Now that is an assumption that we made, and we'd very much like to hear
> >> if that assumption is incorrect.
> > 
> > Note that I may be lacking full context, but based just on your description
> > above and § 8.1 of the -18, I am concerned about your statement "without
> > worrying about the lack of certificate verification for the stuns URI".  My
> > understanding is, that given a stuns URI with an IP address for the host
> > and some domain name specified by the same mechanism that provided the URI,
> > is that this domain name would then be used as input to the servername
> > verification process for the new connection using this stuns URI.  Your
> > statement that I quote here makes it sound like no certificate verification
> > is done on this second connection, which would seem to make it vulnerable
> > to a MITM attack (and thus be a bad idea).
> 
> You are right.  I am not sure if there is an easy way to fix that but if someone figure that out it can be spelled out in a separate draft.  Meanwhile I updated the text in the new version of the draft as follow:
> 
> "If the <host> part of a "stun" URI contains an IP address, then this
>  IP address is used directly to contact the server.  A "stuns" URI
>  containing an IP address MUST be rejected."

Thanks, this is an okay way to address my concern.  (I think it would also
be fine to allow "stuns" URIs with IP addresses, if they are obtained over
secure transport and accompanied by a hostname to use in certificate
validation, but I can understand if you don't want to try to capture the
subtleties of that in a document at this stage of processing.)

-Benjamin