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

Rohan Mahy <rohan.mahy@gmail.com> Sun, 07 October 2018 15:05 UTC

Return-Path: <rohan.mahy@gmail.com>
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 64AFD130E07; Sun, 7 Oct 2018 08:05:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 jbyIhF0sXOrd; Sun, 7 Oct 2018 08:05:50 -0700 (PDT)
Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (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 C844F124BE5; Sun, 7 Oct 2018 08:05:49 -0700 (PDT)
Received: by mail-vs1-xe2f.google.com with SMTP id v18-v6so10034278vsl.11; Sun, 07 Oct 2018 08:05:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+NB5S96RBzORSKszq/CID0DapxuJDeC6WpeuENIadVU=; b=s7YkbxaUvw7CjSZWmXq4yGyhPrwF0/Dwucyz1Mv1POVx8RDPD+LOkVipd2d6/UMXCY hvpmJ+6X5h0nKRXv7VIUPqPreXBPZrhvYIvo3a0nKU8gGN2yTc+26tsk+G9QlfsaGSQC 7QlCGjlK+YuRIkU1n7i03hoG7dLgTMPeE2Z6Cxr/qGqukxKb9rpqY7oRFIIXVU6DOGCq tnzyrNhQLXVSm3jlmgPNKdFMHZ7GIRGfvIOmu9sSCcpiwbBQtGh12xtV/IDi7d+Ya6xo dgmv4Q+0KT39OMK2cSMC3CBGk9ZT6wz8zGsMZ/KRqlfL4mHG3Kz0BFQWMhMz7inAPUT6 U5TQ==
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=+NB5S96RBzORSKszq/CID0DapxuJDeC6WpeuENIadVU=; b=ot7WKQedcgQKqOOXyM/oxXUI53s8cW4RVwh56z20AXgd2xVG5tWbyUhjCEYmwt+gTB CHut37ak0gUxLgJr9IiMO9dS2Pt84VC/xJxwB6FByoNC5HTJSLcgHFyuSP4FY2aV9ogf 8RWFQoX/r0EpV7UdkfPommIAJSErlJeIgpinM5M6HMQPR1PcS9J3OR/aAwZDZl2bPxWY XKQYtyjM41GniC5rcepOIzVy69oMj1FROtUbjA+CkMi4GMXkz6ju8sRoF1d9yqzNQreX Byrl9FcNCzt4+Sm6yp6EPFiowUgRyW4v/QffrlCyXn8kW1guCuqXNWwNsfjsDQKAZjr8 RMQg==
X-Gm-Message-State: ABuFfohj7jYpH+46v/a/4SbaBlsis8o2ocKgkymXDSywenstfBpDKJKo v0StG2o+1vjqBovXqmZMu3Nl0n+xvJlJhYksTBE=
X-Google-Smtp-Source: ACcGV60C5DFBYX0MG5GYsytJ/7VJhXimsDbD+MCv5Xt5+6ikhfHJybmZmKBmrnyTO8uW7Mi75AB4B8kEEa+jd24UQ6U=
X-Received: by 2002:a67:47d8:: with SMTP id b85mr7228539vsg.184.1538924748606; Sun, 07 Oct 2018 08:05:48 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <49512499-0e71-1f5b-e12c-213a3dd88d91@petit-huguenin.org>
From: Rohan Mahy <rohan.mahy@gmail.com>
Date: Sun, 7 Oct 2018 08:05:36 -0700
Message-ID: <CAKoiRuacSP_FuXouxfSbbZ5fN_9O1gxBPwUomranS_Cz5YawMA@mail.gmail.com>
To: Marc Petit-Huguenin <marc@petit-huguenin.org>
Cc: Benjamin Kaduk <kaduk@mit.edu>, 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
Content-Type: multipart/alternative; boundary="000000000000fa11ba0577a4d603"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/ZcZ-tga_cRS4_I-auN2yxEh04PY>
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 15:05:53 -0000

[snip]
>> 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).

Probably too late now, but if you wanted to be able use a stuns: URI safely
with an IP address, you could use a fingerprint URI parameter to prevent
MITM. This would work as long as you received the URI over an authenticated
channel (ex: https:, sip: + S/MIME, and possibly sips:).
Thanks,
-rohan

On Sun, Oct 7, 2018 at 5:48 AM Marc Petit-Huguenin <marc@petit-huguenin.org>
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."
>
> >
> > -Benjamin
> >
> >> Section 6.2.3 is unrelated - it is about IP addresses provisioned
> locally (not received from the server), and a matching certificate
> containing IPAddress.  I'll make that more explicit after I receive your
> response on the subject above.
> >>
> >> Also it seems that your DISCUSS is not related to that issue at all,
> would it be possible to clear it?
> >>
> >> Thanks.
> >>
> >> On 06/18/2018 10:45 AM, Adam Roach wrote:
> >>> Gonzalo:
> >>>
> >>> TL;DR -- unless someone can find evidence indicating what the WG
> intended, I believe we are waiting on you and Simon.
> >>>
> >>> I had two responses in my most recent message. I presume the first
> should be uncontroversial.
> >>>
> >>> The second point pertains to how the working group intended to treat
> IP addresses in STUNS URIs. The document right now is ambiguous and
> self-contradictory. If this has been discussed in the past, then the
> document simply needs to be updated to reflect the outcome of that
> conversation. If not, then I believe the WG needs to have a conversation
> about what is intended.
> >>>
> >>> As it stands, the document will lead to various notions about whether
> (and how) IP addresses can be used, which will be an interop nightmare.
> >>>
> >>> /a
> >>>
> >>> On 6/18/18 05:41, Gonzalo Camarillo wrote:
> >>>> Marc, Adam,
> >>>>
> >>>> what is the status of this discussion?
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Gonzalo
> >>>>
> >>>> On 21/05/2018 9:11 PM, Adam Roach wrote:
> >>>>> Sorry for taking so long to get back to you on this. Two responses
> below
> >>>>> -- everything else looks good.
> >>>>>
> >>>>> On 5/3/18 6:37 PM, Marc Petit-Huguenin wrote:
> >>>>>> On 04/23/2018 03:37 PM, Marc Petit-Huguenin wrote:
> >>>>>>>>
> ---------------------------------------------------------------------------
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> §17.3.1:
> >>>>>>>>
> >>>>>>>>>    IANA is requested to update the names for attributes 0x0002,
> 0x0003,
> >>>>>>>>>    0x0004, 0x0005, 0x0007, and 0x000B, and the reference from
> RFC 5389
> >>>>>>>>>    to RFC-to-be for the following STUN methods:
> >>>>>>>> ...
> >>>>>>>>>    0x0003: (Reserved; prior to [RFC5389] this was CHANGE-REQUEST)
> >>>>>>>> The attribute 0x0003 is registered by RFC 5780, and should not be
> >>>>>>>> removed by this document.
> >>>>>>> Fixed.
> >>>>>
> >>>>> Thanks for the change, but the new text still asks IANA to update the
> >>>>> table so that 0x0003 points to *this* document, instead of
> continuing to
> >>>>> point to RFC 5780. Since this document does not do anything with
> >>>>> CHANGE-REQUEST, this update does not seem correct.
> >>>>>
> >>>>>
> >>>>>>>>
> ---------------------------------------------------------------------------
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> §6.2.3 says:
> >>>>>>>>
> >>>>>>>>>    Alternatively, a
> >>>>>>>>>    client MAY be configured with a set of IP addresses that are
> >>>>>>>>> trusted;
> >>>>>>>>>    if a certificate is received that identifies one of those IP
> >>>>>>>>>    addresses, the client considers the identity of the server to
> be
> >>>>>>>>>    verified.
> >>>>>>>> Presumably, this means the server supplies a certificate with
> >>>>>>>> SubjectAltName
> >>>>>>>> containing an iPAddress? Please add text to clarify whether
> that's the
> >>>>>>>> intention.
> >>>>>>>>
> >>>>>>>> If that *is* the intended meaning, then this behavior in §8.1
> seems
> >>>>>>>> unnecessarily restrictive:
> >>>>>>>>
> >>>>>>>>>    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.
> >>>>>>>> Presumably, this is done because certs with iPAddress-form
> >>>>>>>> SubjectAltNames are
> >>>>>>>> pretty rare (although CAB Forum baseline requirements do
> explicitly
> >>>>>>>> allow
> >>>>>>>> their issuance) -- but if the text in §6.2.3 is based on allowing
> >>>>>>>> the use of
> >>>>>>>> such certs in a TURN deployment, then it seems that URI resolution
> >>>>>>>> should be
> >>>>>>>> also.
> >>>>>>>>
> >>>>>>> I am not sure what was the intent there, so I'll work on that
> later.
> >>>>>> We addressed all the other comments, but it would be great if you
> >>>>>> could suggest some text to address that one.
> >>>>> I'm not sure what was meant either!
> >>>>>
> >>>>> I think we need to untangle what the working group meant to say
> >>>>> regarding "trusted IP addresses," the way this protocol is intended
> to
> >>>>> use certs, and whether the prohibition on using IP addresses in
> "stuns"
> >>>>> URIs derives from cert handling or if it has a completely different
> >>>>> rationale behind it; and, if the former, ensure that those things
> that
> >>>>> are prohibited or allowed in certs are similarly prohibited or
> allowed
> >>>>> in URIs.
> >>>>>
> >>>>> I can suggest some *behavior*, but unless there is some record of
> what
> >>>>> the WG meant, any such behavior would need to be discussed by the
> >>>>> working group, and a consensus would need to be declared by the
> chairs.
> >>>>>
> >>>>>
> >>>>> /a
> >>>>>
> >>>
> >>
>
>
> --
> Marc Petit-Huguenin
> Email: marc@petit-huguenin.org
> Blog: https://marc.petit-huguenin.org
> Profile: https://www.linkedin.com/in/petithug
>
>