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

[Benjamin Kaduk <[e-mail]>]

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