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

[Marc Petit-Huguenin <[e-mail]>]

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

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: [e-mail]
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug