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

[Graham Klyne <[e-mail]>]

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?

#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.
>