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

[Gonzalo Camarillo <[e-mail]>]

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
>