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

Alissa Cooper <alissa@cooperw.in> Thu, 19 April 2018 01:56 UTC

Return-Path: <alissa@cooperw.in>
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 D0DD8127333; Wed, 18 Apr 2018 18:56:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=RRHRHo9Z; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=mxAmEf7k
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 bCBTE1iUx_M2; Wed, 18 Apr 2018 18:56:09 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 406AE1271DF; Wed, 18 Apr 2018 18:56:09 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id A64F02106C; Wed, 18 Apr 2018 21:56:08 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 18 Apr 2018 21:56:08 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=/Ee29HHGChw58tkSfYsIHW6nGY92QyEwJBHkdPY+cck=; b=RRHRHo9Z BvZuw3oL2594cssUayvyiJlrqOkRH7thiKUvOxMCxDoJouI6QMo8mYHUZLQB4F7q jjqEjtZGAM/pHcachrZNgewttmH5siEP3LOdSTlSPerlyz6iQlI8F03+WWCZ/vCl Qi+r53wBU1fzOKiP3q6O9uka7u1z9A+5RQXn3dgpsbJaoB/CFNzp+EpIlbCR7L+F mMLylEJXW8fcLqqbVFk5Yacg38Gl4fS/FnhKeCC18wN0yq+PyY1XNWATWcNwZYUe fJTehQh6QRJ1HVga9HDskkRKov6KQIXaHPMxgp/wh4XdXfbh3Bsq4oXdV77ISgbi W53rhfFAm1Ab0A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=/Ee29HHGChw58tkSfYsIHW6nGY92Q yEwJBHkdPY+cck=; b=mxAmEf7kzAhnq9E145kKzseTAJic1XWTF01BzuUk9WhM9 xs8VsUP8I5twekFukW/NPaGKO5IrFtgXvETEU7NRu3grQwxNoIMNxT17BR5pMmGZ D2cwXdC2ZUqLycHW5JXgFMJRdhIE/CiCn01mqAg3WaJ+rFRT0NLOpN7MPbYYe5Hp SsZKLr5kJzl5RoheCv6Na0G70fKHfo0aG3RD3T1xLrVpXoM84nBcBwlnmgFF1p++ Jm1Ty0iGWHtnJoZ0IJWTxou1BMIFl5MXexN1XAYSu8kWk41mzm/Tz8L6aX44Z0hV Hhs2SfBS9BYRLfae/vRwKr9GooCGmGLdRt6H0/AoQ==
X-ME-Sender: <xms:OPfXWqUjE5bhLC1O9T_jlUz7XZ1HQHVWxCONEt8TlVnftxn6suL-YA>
Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.67]) by mail.messagingengine.com (Postfix) with ESMTPA id EC6D9E4483; Wed, 18 Apr 2018 21:56:07 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_E5B8D961-58EC-432A-B12A-130E25C06D00"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <d7edd60c-634b-1f2e-0482-0cd706c48b92@petit-huguenin.org>
Date: Wed, 18 Apr 2018 21:56:07 -0400
Cc: Dale Worley <worley@ariadne.com>, IETF Gen-ART <gen-art@ietf.org>, draft-ietf-tram-stunbis.all@ietf.org, tram@ietf.org
Message-Id: <5D4C0196-8073-4174-A10B-8690637310B8@cooperw.in>
References: <152237792217.20556.13689609450529144296@ietfa.amsl.com> <d7edd60c-634b-1f2e-0482-0cd706c48b92@petit-huguenin.org>
To: Marc Petit-Huguenin <marc@petit-huguenin.org>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/GnlUYXtLwL--igw9ZikR2ALRUsE>
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: Thu, 19 Apr 2018 01:56:13 -0000

Dale, thanks for your reviews. Marc, thanks for your response. I have entered a No Objection ballot.

Alissa

> On Apr 16, 2018, at 5:49 PM, Marc Petit-Huguenin <marc@petit-huguenin.org> wrote:
> 
> Thanks again for the review.  Comments inline.
> 
> On 03/30/2018 04:45 AM, Dale Worley wrote:
>> Reviewer: Dale Worley
>> Review result: Ready with Nits
>> 
>> I am the assigned Gen-ART reviewer for this draft.  The General Area
>> Review Team (Gen-ART) reviews all IETF documents being processed by
>> the IESG for the IETF Chair.  Please wait for direction from your
>> document shepherd or AD before posting a new version of the draft.
>> 
>> For more information, please see the FAQ at
>> <https://wiki.tools.ietf.org/area/gen/wiki/GenArtfaq>.
>> 
>> Document:  draft-ietf-tram-stunbis-16
>> Reviewer:  Dale R. Worley
>> Review Date:  2018-03-29
>> IETF LC End Date:  2018-02-20
>> IESG Telechat date:  2018-04-19
>> 
>> Summary:
>> 
>>       This draft is basically ready for publication, but has nits
>>       that should be fixed before publication.
>> 
>> The only interesting item concerns section 17.1, where the assignment
>> of meanings to bits in the "security feature set" value is different
>> from the assignment in -16.  This is either non-upward-compatible with
>> -16, or there is an error in either -16 or -17.
>> 
>> ----------------------------------------------------------------------
>> 
>> There is an issue that shows up in several places:  The NAT may
>> forward the request using an IP family that is different from the IP
>> family that it received the request using.  This means that the
>> "source IP family of the request" may depend on whether one is
>> speaking of the client or the server.  The draft is cognizant of this,
>> and mentions its consequences in sections 6.3.3 and 12.  But this also
>> has consequences for ALTERNATE-SERVER:  Section 14.15 says "The IP
>> address family MUST be identical to that of the source IP address of
>> the request." even though that family might not be usable by the
>> client.  The draft doesn't seem to explicitly say that this comes from
>> address-switching by the NAT.  It would help if there was a
>> higher-level discussion of this matter, pointing to the various
>> consequences.
> 
> I still do not have text about that but, as this is blocking this response since 2 weeks now, I am releasing it as is and will come back to that after I process the other reviews that accumulated during my time traveling around Europe.
> 
>> 
>> 3.  Terminology
>> 
>> This section needs to be updated to reference RFC 8174, including
>> updating the paragraph (especially the final two lines) to read as
>> specified in RFC 8174:
>> 
>>      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
>>      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
>>      "MAY", and "OPTIONAL" in this document are to be interpreted as
>>      described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
>>      appear in all capitals, as shown here.
> 
> Updated.
> 
>> 
>> 6.2.2.  Sending over TCP or TLS-over-TCP
>> 
>>   o  if multiplexing other application protocols over that port, has
>>      finished using that other protocol, and
>> 
>> The two clauses don't match in grammatical number.  This should be
>> either
>> 
>>   o  if multiplexing other application protocols over that port, has
>>      finished using those other protocols, and
>> 
>> or
>> 
>>   o  if multiplexing another application protocol over that port, has
>>      finished using that other protocol, and
> 
> Updated using the former.
> 
>> 
>> 9.2.4.  Receiving a Request
>> 
>>      *  If the request contains neither PASSWORD-ALGORITHMS nor
>>         PASSWORD- ALGORITHM, then the request is processed as though
>>         PASSWORD- ALGORITHM were MD5 (Note that if the original
>>         PASSWORD-ALGORITHMS attribute did not contain MD5, this will
>>         result in a 400 Bad Request in a later step below).
>> 
>> There are two places where s/PASSWORD- ALGORITHM/PASSWORD-ALGORITHM/.
> 
> Already fixed following a previous review.
> 
>> 
>> 14.3.  USERNAME
>> 
>>   The value of USERNAME is a variable-length value containing the
>>   authentication username.  It MUST contain a UTF-8 [RFC3629] encoded
>>   sequence of less than 509 bytes, and MUST have been processed using
>>   the OpaqueString profile [RFC8265].  A compliant implementation MUST
>>   be able to parse UTF-8 encoded sequence of less than 763.
>> 
>> The final "763" is grammatically incorrect.  I think you intend
>> s/763/763 bytes/, to parallel other items.
> 
> Fixed.
> 
>> 
>> 14.4.  USERHASH
>> 
>>   userhash = SHA-256(Opaque(username) ":" Opaque(realm))
>> 
>> I believe that this should be
>> 
>>   userhash = SHA-256(OpaqueString(username) ":" OpaqueString(realm))
> 
> Fixed.
> 
>> 
>> 14.5.  MESSAGE-INTEGRITY
>> 
>>   Petit-Huguenin, et al.  Expires September 6, 2018 [Page 40]
>> 
>>   Internet-Draft Session Traversal Utilities for NAT (STUN) March 2018
>> 
>> This bit of text appears as body text in the middle of page 40.
> 
> Already fixed following a previous review.
> 
>> 
>> 14.6.  MESSAGE-INTEGRITY-SHA256
>> 
>>   The MESSAGE-INTEGRITY-SHA256 attribute contains an HMAC-SHA256
>>   [RFC2104] of the STUN message.  The MESSAGE-INTEGRITY-SHA256
>>   attribute can be present in any STUN message type.  The MESSAGE-
>>   INTEGRITY-SHA256 attribute contains an initial portion of the HMAC-
>>   SHA-256 [RFC2104] of the STUN message.  The value will be at most 32
>>   bytes and MUST be a positive multiple of 4 bytes.  The HMAC MUST NOT
>>   be truncated below a minimum size of 16 bytes.  The value must be the
>>   full 32 bytes unless the STUN Usage explicitly specifies that
>>   truncation is allowed.  STUN Usages may specify a minimum length
>>   longer than 4 bytes.
>> 
>> This seems to be less clear than it could be.  (And my apologies, some
>> of the redundancy was my suggestion!)  Perhaps this is an improvement:
>> 
>>   The value will be at most 32 bytes, MUST be at least 16 bytes, and
>>   MUST be a multiple of 4 bytes.  The value must be the full 32 bytes
>>   unless the STUN Usage explicitly specifies that truncation is
>>   allowed.  STUN Usages may specify a minimum length longer than 16
>>   bytes.
> 
> Applied.
> 
>> 
>> 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.
> 
> 
> -- 
> Marc Petit-Huguenin
> Email: marc@petit-huguenin.org <mailto:marc@petit-huguenin.org>
> Blog: https://marc.petit-huguenin.org <https://marc.petit-huguenin.org/>
> Profile: https://www.linkedin.com/in/petithug <https://www.linkedin.com/in/petithug>
> 
> _______________________________________________
> tram mailing list
> tram@ietf.org <mailto:tram@ietf.org>
> https://www.ietf.org/mailman/listinfo/tram <https://www.ietf.org/mailman/listinfo/tram>