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

Marc Petit-Huguenin <marc@petit-huguenin.org> Sun, 07 October 2018 12:48 UTC

Return-Path: <marc@petit-huguenin.org>
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 3129C130E1E; Sun, 7 Oct 2018 05:48:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.107
X-Spam-Level:
X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 IEzsipSXdv0m; Sun, 7 Oct 2018 05:48:01 -0700 (PDT)
Received: from implementers.org (unknown [92.243.22.217]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0245130E1A; Sun, 7 Oct 2018 05:48:00 -0700 (PDT)
Received: from [IPv6:2601:648:8400:8e7d:6571:21bd:7029:6ef2] (unknown [IPv6:2601:648:8400:8e7d:6571:21bd:7029:6ef2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 296C8AE009; Sun, 7 Oct 2018 14:47:55 +0200 (CEST)
To: Benjamin Kaduk <kaduk@mit.edu>
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
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>
From: Marc Petit-Huguenin <marc@petit-huguenin.org>
Openpgp: preference=signencrypt
Autocrypt: addr=marc@petit-huguenin.org; prefer-encrypt=mutual; keydata= mQINBE6Mh9wBEADrUEDZChteJbQtsHwZITZExr7TAqT7pniNwhBX3nFgd+FrV3lsLKJ1rym2 52MAYpubXEJZGzMp6uCCAnROWbtmQbOm8z/jHnjxHhPqfuYCYPpAQqu8K/Sc194Rp37krMwB jz32yr7+gvWLzRgQGKIh9d2mzy8QLMETVWWQWGb6fEfpOxXo0wumN1rc/275kZwOu44JIPGg zbgwZdnEqYOUUa18K9MXeRDoWbwDISP30CvKuZDwD14lbBE3o7tBQrU9uoMhE7eFlTjbsCox qoubI2tZSuOTF8mRXjPmNrRGtf9mYkQnOB7y6qy/QxmOVMq4IRtHzOYIm/EZ6NTodcpZQHOM 2v6B6YK9uKrYrapSpJzn4f9oU7alT31Y3o2hOlxAWDQ16+Dd1MOPYsKQXOwY1/ihm4PTjiJ8 ud8yPzy7c+BSVs5wkBU6QuLNIgZHrrxdn+KxM+F/oAVtfzO7XzVoeOcXyWi3/CHL5pgoBruY enIF/RrRuplpy09pvZjmFPNfqKBYJGnqpQuqsQwO7LsFqDqfY2EuHg+KsGN1XuN+jxXc48/1 gCnKw7ALSPWEb7g25wD6KfiZTAcyRTG8LePNFQKhw61LbIWmkw9EaVLyXvwPTc1iCSc0dDT/ pcT/z+8xrWOyWGZNZAjR584NlDpKollbItcxYtFcYZkvTCmOVwARAQABtC1NYXJjIFBldGl0 LUh1Z3VlbmluIDxtYXJjQHBldGl0LWh1Z3VlbmluLm9yZz6JAjsEEwEIACUCGyMGCwkIBwMC BhUIAgkKCwQWAgMBAh4BAheAAhkBBQJX8tdbAAoJECnERZXWan7EiNkQAIbS72cyalFjxQ1l vEW9S8NjjwIMbb5+NC2XqDakAmZq+Aav/Yfk8aEc+eAWBboVC3NBBjYojMRXK1XEnD7xPQ1X rWd23TDibKajy/2fo/MS9/s6uPFOAINi1ykOMq8ShxMHcIPC/dvVt59a7DV1KPGlnUheNR7N 4rIbkL5KndatD38yTGkyKsFvVKTHJn3y5zqHTGP0BjE1rxsGEBn4h+EzxVCIMVFQUeMVPKPV dlQY9fxdicSGPK2WKo1KL3CVpnYTuNCAVIGA9DPTXPPKvEte+/+xv10I03pj4w87iMUZt7Ca FTO55Gsf8hZvmpuB224yzrAbquA450EUVcQ7KAPcHrph5KAu0d3nwrjrUDn/RWWbyRiVrPtf hmnAAhkSv7oOxzyMdLvqt7XKGKbABhrl1ZRF8QbquOkyu8n3Bz2Osgw7JyFn9N6svlFPmpML UTEi64NewvN6zszKs/zBS6bn7na75gxHNvjSZpSF6uSLYgmKbyG8vkY/i0s0e0njjOHcpNx1 0mNZ+wOoCgHtSCZFyv14ncioJTiSjtZCs+srW9PFlbOg73C1Op42xV5Y+dh/mCC+rweKtB3t yTAy52v8vPG0VjsLS52x6yUsoDjYV33AmTEaWmGzN5t8BX/qh7pgNIEd9TEwrR3B4LjqMmUk XXWSJG5IM8Zr2OE/t2vyuQINBE6Mh9wBEAC/i4Lh4XEgwi/yHr3XLx/+f38ztn5rrk8XRsK2 WUpu5evxw9iK2oelqWtS71XkW57EavJOjvP4t8FWqRKED5jWN741n12iW/EeLx3KoHMcPTfY 4WWvprxiZPfnCIpQ8j8x0QQSA+Hf96BSkAkOGNkiJDuus5z4XwTktn9gFOwLVx4VRMo+lrCy um6BDHI+4/sOWnrNp2WptI4YKM/uA0HpuLpPKLra0ZW6Bp2TewNpAjbst/VHjqewab0PeSCn CQiHkqIibdgOATT0K6KoVtMxp/WPRSfVImfWCHjT2G7HFMcb6w/jlPSb+u4VtL9yn76CCg8F SqTtzFuqPtbXkhrdSgks/grxiQryMXwpO0uSuUgZ3u2TSs+65Bl2CM5cq+2aBIER5qhpnCv7 B00uHuoNqUEK0VEpLKcqi2ZeVM5oO8iOaBgS9Gh082HQ5JDijEV2J5e4rwXjbRnJ4hqpTjSy caW8HnPI+4S0aqVxbnqW7T6l/xnn7ivK3aPqaRKqUSedHCU3oHIU31n0o5+f5htQeDs/Tpzn ARHkyzu9vZ9CvQXk8daZorA+j/38q6mWU6Mw8FRIu1qPQDmqljobk3vC9BZRSJOn3P8jNMM7 w1j+7Da3rxGBylfa3fmHPyY7dvdyeLmsq7egzTJkpAMN55Qat7iuXeeCdBQLAFHLBP1tvwAR AQABiQIfBBgBCAAJAhsMBQJX8tdcAAoJECnERZXWan7EkMgP/isd3lrSsm/8t+U44LY0/x67 cPmiKa9biveywJZ9Y+Zu/pUP44dP670mY7PmEDGC6lRiPKGmhf7vqq6JJFOqX64VWePQ9QZp kkzAUmIJwQ2Kmcmfrs0J5w2Lf5qaNji25fQYbon0eUFy6eN3BNRSIcg0+OsH7HubTWfpZeJu B7V7k8OFt2+HDx7aNdNutDJIu4V25AzGfonARQzJK62cmB0pwYXpcyDO152OwP12XbpXxXA1 xHGYQBRL98pSbMU5xsMw8j9VQHQRS94aT9Qqnz9SrYuISnMV2WGyIE0rAY3GGz3IcN5LVE1N vSP51ih+YJg/qsBYs8obbfEIZelOuznWf120RgV7P+7ZWCSBohmchuyELQzl9D7FXfulkXA3 RapKQcGJMVPIHYgnlvmE0OXfJl1z09nYRQHitoQhWtviHWl7x/KL42aUzHirLR61iVA2kqkO BhU+u+g2w8qrZj+lJfXIxlbVyLOuBVqkfcK28AR9RriB4Q5hvbDeQJMgfZsV2hBt7huBOqkH nnbSCguqfnmwLGkxoM7RVjCQwvC1M57uwdKMlsTVaBP0RreZnrDngLamK+ibXYe7p8pPAWD9 cuHvkkjML7cIfuvbScDYRmGzia3V9+LVzQCm+q/6xUY1SZvrDz7OaJOy3Xb1d+aPhYaNC0TQ 7IqA1dx8rZYQ
Message-ID: <49512499-0e71-1f5b-e12c-213a3dd88d91@petit-huguenin.org>
Date: Sun, 7 Oct 2018 05:47:54 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <20180909014711.GT73164@kduck.kaduk.org>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="YUbsRsAxd584CUGEYo73oJTHyKcYdFXZN"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/AJzXIkb3MPDnUqZ7LLfRoLoflxY>
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 12:48:03 -0000

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