Re: [tram] Genart telechat review of draft-ietf-tram-stunbis-16

Marc Petit-Huguenin <petithug@acm.org> Mon, 23 April 2018 17:11 UTC

Return-Path: <petithug@acm.org>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0698C12D87A; Mon, 23 Apr 2018 10:11:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.442
X-Spam-Level:
X-Spam-Status: No, score=-0.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkzJ_X5hXz-7; Mon, 23 Apr 2018 10:11:04 -0700 (PDT)
Received: from implementers.org (unknown [92.243.22.217]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CFF312D7F1; Mon, 23 Apr 2018 10:11:04 -0700 (PDT)
Received: from [IPv6:2601:648:8301:730f:fdb6:1cc8:478a:5b55] (unknown [IPv6:2601:648:8301:730f:fdb6:1cc8:478a:5b55]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id A952CAE844; Mon, 23 Apr 2018 19:11:00 +0200 (CEST)
From: Marc Petit-Huguenin <petithug@acm.org>
To: "Dale R. Worley" <worley@ariadne.com>
Cc: gen-art@ietf.org, draft-ietf-tram-stunbis.all@ietf.org, ietf@ietf.org, tram@ietf.org
References: <8736zmd62d.fsf@hobgoblin.ariadne.com>
Message-ID: <0de8c1fd-ab42-6ea2-e04e-eba05f5848df@acm.org>
Date: Mon, 23 Apr 2018 10:10:58 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <8736zmd62d.fsf@hobgoblin.ariadne.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8SJmvjBhWeUVNUIZyXuhSAgyRXqRQ0Vf6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/Bx4TGNN_SJ8NJe0ZjPwYqj5r0eA>
Subject: Re: [tram] Genart telechat review of draft-ietf-tram-stunbis-16
X-BeenThere: tram@ietf.org
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." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Apr 2018 17:11:06 -0000

On 04/22/2018 07:12 PM, Dale R. Worley wrote:
> My apologies for not responding to this sooner:
> 
> Marc Petit-Huguenin <marc@petit-huguenin.org> writes:
>>> 17.1.  STUN Security Features Registry
>>>
>>>    A STUN Security Feature set defines 24 bit as flags.
>>>
>>>    IANA is requested to create a new registry containing the STUN
>>>    Security Features that are protected by the bid down attack
>>>    prevention mechanism described in section Section 9.2.1.
>>>
>>>    The initial STUN Security Features are:
>>>
>>>    Bit 0: Password algorithms
>>>    Bit 1: Username anonymity
>>>    Bit 2-23: Unassigned
>>>
>>> Beware that the assignment of features to bits in the security feature
>>> value has changed!  Bit numbers are assigned from the left/high-order
>>> end -- see figure 2 in the draft.  So the *values* for these bits are:
>>>
>>> 0x400000   Bit 0: Password algorithms
>>> 0x200000   Bit 1: Username anonymity
>>>
>>> But the values assigned in -15 were:
>>>
>>>    0x000001: Password algorithms
>>>    0x000002: Username anonymity
>>
>> Hmm, that was not the intent, and not how I read the text. Even in
>> Figure 2 less significant bits are on the right.  So the intent is
>> real tat bit0=0x001, bit1 = 0x002, and so on.  All we do is about
>> interoperability, so I added some text that makes that less ambiguous.
> 
> (The latest posted version is still -16, so I haven't seen the changes
> you refer to.)

Sorry, I should have pasted the text.  But the point is moot, see below.

> 
> In reference to the statements:
> 
>>>    The initial STUN Security Features are:
>>>
>>>    Bit 0: Password algorithms
>>>    Bit 1: Username anonymity
>>>    Bit 2-23: Unassigned
> 
> I've skimmed the text again, and it appears that this passage is the
> only one that allocates the functions "password algorithms" and
> "username anonymity" to specific bits of the security feature value.
> Thus, it's critical what "bit 0" means in this context.
> 
> Searching for "0" in the document, I can find no outright definition of
> the meaning of "bit 0".  However, there are 10 figures in the document,
> and 8 of them show the numbering of the bits of various fields, with bit
> "0" being the *high-order*, *most-significant*, "left"-most bit of the
> field, bit "1" the next-highest-order bit, etc.  This numbering seems to
> be conventional in RFCs.

I did some research and you were right, starting from the left side is more common.  My main counter-example is in fact in STUN itself as figure 3:

                       0                 1
                       2  3  4 5 6 7 8 9 0 1 2 3 4 5
                      +--+--+-+-+-+-+-+-+-+-+-+-+-+-+
                      |M |M |M|M|M|C|M|M|M|C|M|M|M|M|
                      |11|10|9|8|7|1|6|5|4|0|3|2|1|0|
                      +--+--+-+-+-+-+-+-+-+-+-+-+-+-+

And as the base64 encoding is done on an array of bytes and not an integer, it is in fact simpler to define it that way. The new text in section now reads:

   Bits are assigned starting from the most significant side of the bit
   set, so Bit 0 is the leftmost bit and Bit 23 the rightmost bit.

I also updated the example in Appendix B.1.

-- 
Marc Petit-Huguenin
Email: marc@petit-huguenin.org
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug