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

[Adam Roach <[e-mail]>]

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