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

Adam Roach <> Mon, 21 May 2018 18:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 22D5712E8C6; Mon, 21 May 2018 11:11:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ggd5mfCy_IWe; Mon, 21 May 2018 11:11:36 -0700 (PDT)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2603312D7EF; Mon, 21 May 2018 11:11:36 -0700 (PDT)
Received: from Svantevit.local ( []) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id w4LIBWa4055327 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 21 May 2018 13:11:34 -0500 (CDT) (envelope-from
X-Authentication-Warning: Host [] claimed to be Svantevit.local
To: Marc Petit-Huguenin <>, The IESG <>
Cc:, Tolga Asveren <>,,,
References: <> <> <>
From: Adam Roach <>
Message-ID: <>
Date: Mon, 21 May 2018 13:11:27 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [tram] Adam Roach's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 21 May 2018 18:11:38 -0000

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.