Re: Last Call: <draft-nandakumar-rtcweb-stun-uri-05.txt> (URI Scheme for Session Traversal Utilities for NAT (STUN) Protocol) to Proposed Standard

[Harald Alvestrand <[e-mail]>]

On 08/15/2013 04:05 PM, Graham Klyne wrote:
> Harald,
>
> Briefly:
>
> 1. Thanks for the reference,
>
> and
>
> 2. I misunderstood what you meant by "This is a format for a piece of
> data".  In light of your clarification, I withdraw my comments 3 & 4. 
> Identification of the STUN service would appear to be a perfectly
> reasonable use.
>
> ...
>
> So the remaining issues from my questions are whether the intended
> highly constrained use of these services justifies allocating a URI
> scheme.
>
> If the community consensus is that it is of sufficient value, I might
> suggest an annotation to the scheme registration along the lines of:
>
> "This URI scheme is intended for use in very specific NAT traversal
> environments, and should not be used otherwise on the open Web or
> Internet."
>
> Would such a comment run contrary to your expectations for its use?

I would prefer to run the comment as "This scheme is intended for use in
specific environments that involve NAT traversal. Users of the scheme
need to carefully consider the security properties of the context in
which they are using it."

Echoing the warning in the STUN scheme - "use this when you know what
you're doing only".

Frankly, like Hadriel indicated, I have no idea whether it will be
useful in other contexts or not, and I'm hesitant to put language that
seems to claim that we've evaluated all possible contexts and say that
there aren't other contexts in which it can be useful.


>
> #g
> -- 
>
>
> On 15/08/2013 11:04, Harald Alvestrand wrote:
>> On 08/15/2013 11:04 AM, Graham Klyne wrote:
>>> Hi Harald,
>>>
>>> On 14/08/2013 19:49, Harald Alvestrand wrote:
>>>> On 08/13/2013 12:14 AM, Graham Klyne wrote:
>>> [...]
>>>>> But, in a personal capacity, not as designated reviewer, I have to
>>>>> ask *why*
>>>>> this needs to be a URI.  As far as I can tell, it is intended for
>>>>> use only in
>>>>> very constrained environments, where there seems to be little
>>>>> value in having
>>>>> an identifier that can appear in all the contexts where a URI may be
>>>>> recognized.
>>>>>
>>>>> The criteria for new URI schemes in
>>>>> http://tools.ietf.org/html/rfc4395 include:
>>>>>
>>>>> "New URI schemes SHOULD have clear utility to the broad Internet
>>>>> community,
>>>>> beyond that available with already registered URI schemes."
>>>>> -- http://tools.ietf.org/html/rfc4395#section-2.1
>>>>>
>>>>> This "utility to the broader community" is not clear to me, but I
>>>>> don't fully
>>>>> understand the intended scope of this protocol, so I could be missing
>>>>> something.  So, in declaring consensus for this specification, I
>>>>> would request
>>>>> that this aspect at least be considered.
>>>>
>>>> I can only give  my personal opinion....
>>>>
>>>> 1) This is a format for a piece of data. This data cannot be
>>>> expressed using any
>>>> existing URI scheme - indeed, I don't think there exists another
>>>> well-defined
>>>> textual representation of this piece of data.
>>>>
>>>> 1) This is defining an identifier that will be used in W3C-defined
>>>> APIs. W3C
>>>> tends to use URIs every time they want a self-defining piece of
>>>> data with a
>>>> clearly defined structure.
>>>> In the particular API where this is wanted, one wants to have STUN
>>>> URIs, TURNS
>>>> URIs and TURN URIs passed over the same interface. Thus, keeping
>>>> with the W3C
>>>> tradition of URIs seems reasonable.
>>>>
>>>> I think this answers the question about "utility to the broader
>>>> community" to my
>>>> satisfaction - your mileage may differ, of course.
>>>
>>> Some thoughts occur to me:
>>>
>>> 1. My reading was that this is a generic NAT traversal protocol, so the
>>> requirement here is not Web/W3C specific.  But you do say "used in
>>> W3C-defined
>>> APIs"...
>>
>> Truth in advertising: One W3C-defined API.
>> The specific reference:
>>
>> http://dev.w3.org/2011/webrtc/editor/webrtc.html#dictionary-rtciceserver-members
>>
>>
>>>
>>> 2. If this is being driven by W3C activities, this should probably
>>> be flagged
>>> with W3C TAG.  I'll raise it there.
>>>
>>> 3. URIs are not generally used as *data* formats, but rather as
>>> identifiers
>>> for resources.  Web architecture and REST principles tend to discourage
>>> information encoded in URIs in favour of data representation
>>> formats.  Cf.
>>> http://www.w3.org/TR/webarch/#uri-opacity,
>>> http://www.w3.org/2001/tag/doc/metaDataInURI-31.html
>>
>> Well, it is. The data encoded is the identification of a STUN server,
>> which is a
>> resource.
>>
>>>
>>> 4. If the purpose here is simply to encode data, then there does
>>> already exist
>>> a suitable URI scheme, viz data:.  A new content type can be defined to
>>> actually encode the required data, and the whole be wrapped in a
>>> data: URI.
>>> This approach has the advantage that alternative mechanisms (other
>>> than URIs)
>>> can be used to transfer the traversal data if required (though that
>>> may be
>>> moot in the very restricted intended scope of deployment for stun:,
>>> etc.)
>>
>> Yes, but why?
>>
>>>
>>>>>
>>>>> ...
>>>>>
>>>>> Further, according to http://tools.ietf.org/html/rfc5389 it
>>>>> appears that there
>>>>> are security considerations with regard to the STUN protocol that
>>>>> it should
>>>>> not be used in isolation:
>>>>> [[
>>>>>    Classic STUN also had a security vulnerability -- attackers could
>>>>>    provide the client with incorrect mapped addresses under certain
>>>>>    topologies and constraints, and this was fundamentally not
>>>>> solvable
>>>>>    through any cryptographic means.  Though this problem remains with
>>>>>    this specification, those attacks are now mitigated through the
>>>>> use
>>>>>    of more complete solutions that make use of STUN.
>>>>>
>>>>>    For these reasons, this specification obsoletes RFC 3489, and
>>>>> instead
>>>>>    describes STUN as a tool that is utilized as part of a complete
>>>>> NAT
>>>>>    traversal solution.
>>>>> ]]
>>>>> -- http://tools.ietf.org/html/rfc5389#section-2
>>>>>
>>>>> It seems to me that creating a URI for STUN could encourage its
>>>>> use in
>>>>> environments outside the "more complete solutions that make use of
>>>>> STUN".
>>>>> This seems to be further reason that STUN[S] should not be a URI
>>>>> scheme.
>>>>>
>>>>> I have also suggested that, if registered, the URI scheme
>>>>> registration should
>>>>> carries a "health warning" to this effect, and that it is not
>>>>> suitable for
>>>>> general use that is not part of a "complete NAT traversal
>>>>> solution".  But I
>>>>> also recognize that I do not fully grasp the security
>>>>> implications, and that
>>>>> if those that do know better can agree that there is no potential
>>>>> for creating
>>>>> security risks here, this suggestion may be unnecessary.
>>>>
>>>> This URI scheme does not represent STUN. It represents
>>>> configuration data that
>>>> is used to initialize a protocol machine that utilizes STUN.
>>>>
>>>> This configuration data has to be passed no matter what the format
>>>> of the data
>>>> is - whether it be URI or not.
>>>>
>>>> Thus, I do not think the argument raised is really relevant to the
>>>> context. The
>>>> data will be passed, and registering an URI scheme will cause no
>>>> more and no
>>>> less data to be passed.
>>>>
>>>> Again, my opinion.
>>>>
>>>
>>> If the URI is used only in very constrained contexts, then I agree.
>>>
>>> But the whole point of using a URI is that, due to URI opacity, it
>>> can be used
>>> a a range of contexts where URIs are used.  If it cannot properly be
>>> used in
>>> those other contexts, I have to question if it really is a URI, as
>>> opposed to
>>> a string that happens to look like a URI.
>>
>> The subject of "if it really is an URI" has plagued the whole URI
>> space since
>> day one. My current opinion is that if it looks like an URI, and parses
>> according to the URI spec, it should probably be called an URI.
>>
>> So far, we know of one context where we need this (RTCWEB). It's the
>> first
>> context I know of where the Web and STUN intersect. It's not certain
>> that it'll
>> be the last one.
>>
>>>
>>> I also note that this looks as if it may fall foul of the "confidential
>>> metadata" practice noted in the W3C TAG finding about metadata in URIs
>>> (http://www.w3.org/2001/tag/doc/metaDataInURI-31.html#hideforsecurity)
>>
>> That's why we took the "credentials" part out of the URI scheme.
>>