[tram] Alexey Melnikov's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT)

Alexey Melnikov <aamelnikov@fastmail.fm> Wed, 18 April 2018 16:29 UTC

Return-Path: <aamelnikov@fastmail.fm>
X-Original-To: tram@ietf.org
Delivered-To: tram@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D8BA31242F7; Wed, 18 Apr 2018 09:29:22 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alexey Melnikov <aamelnikov@fastmail.fm>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-tram-stunbis@ietf.org, Gonzalo.Camarillo@ericsson.com, Tolga Asveren <tasveren@rbbn.com>, tram-chairs@ietf.org, tasveren@rbbn.com, tram@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.78.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152406896286.13830.7440801444130192741.idtracker@ietfa.amsl.com>
Date: Wed, 18 Apr 2018 09:29:22 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/mqF-bQqkPV-vCbQANMIv3j-1JBo>
Subject: [tram] Alexey Melnikov's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT)
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 18 Apr 2018 16:29:23 -0000

Alexey Melnikov has entered the following ballot position for
draft-ietf-tram-stunbis-16: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I would like to discuss several issues with the document (which look easy to
fix to me) before recommending its approval for publication as an RFC:

1) 14.3.  USERNAME

   The USERNAME attribute is used for message integrity.  It identifies
   the username and password combination used in the message-integrity
   check.

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

I am trying to understand if there was a particular reason why you didn't use
UsernameCasePreserved (or its case insensitive alternative) profile here which
was specifically designed for usernames?

   A compliant implementation MUST
   be able to parse UTF-8 encoded sequence of less than 763.

I am confused by this statement: you already have 509 bytes above.
Is "no" missing above?

14.4.  USERHASH

   The USERHASH attribute is used as a replacement for the USERNAME
   attribute when username anonymity is supported.

   The value of USERHASH has a fixed length of 32 bytes.  The username
   and the realm MUST have been processed using the OpaqueString profile
   [RFC8265] before hashing.

As above: why didn't you use UsernameCasePreserved profile which was
specifically designed for usernames?

2) 14.9.  REALM

   The REALM attribute may be present in requests and responses.  It
   contains text that meets the grammar for "realm-value" as described
   in [RFC3261] but without the double quotes and their surrounding
   whitespace.  That is, it is an unquoted realm-value (and is therefore
   a sequence of qdtext or quoted-pair).  It MUST be a UTF-8 [RFC3629]
   encoded sequence of less than 128 characters (which can be as long as
   509 bytes when encoding them and a long as 763 bytes when decoding
   them),

(Here and similar text in several other sections)
Can you please elaborate on how you came up with values 509 and 763?
And why you need more space for decoding than for encoding of UTF-8.

   and MUST have been processed using the OpaqueString profile
   [RFC8265].

3) 14.16.  ALTERNATE-DOMAIN

   The value of ALTERNATE-DOMAIN is variable length.  It MUST be a UTF-8
   [RFC3629] encoded sequence of less than 128 characters (which can be

Ekr already pointed this out, but I want to expand on this: you need to say
whether this allows U-label (which are UTF-8) or A-labels (which are ASCII
only). If you only allow Punycode encoded A-labels, this field doesn't need to
be UTF-8, it only need to be ASCII.

As far as I remember ASCII domain names are limited to 255 bytes.

   as long as 509 bytes when encoding them and as long as 763 bytes when
   decoding them).

4)

10.  ALTERNATE-SERVER Mechanism

   If the transport protocol uses TLS or DTLS, then the
   client looks for an ALTERNATE-DOMAIN attribute.  If the attribute is
   found, the domain MUST be used to validate the certificate using the
   recommendations in [RFC6125].

When you reference RFC 6125 you need to provide more details:

a) Are you expecting support for DNS-ID, CN-ID or both? I assume you don't
support SRV-ID/URI-ID (saying so explicitly would be great too). b) Are you
expected to allow wildcards in DNS-IDs/CN-IDs? If yes, you need to say so.

There is one more reference to RFC 6125 in the document, you should make a
similar change there as well.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I am agreeing with DISCUSS/comments from Adam.

Additionally, I have the following comments:

9.2.4.  Receiving a Request

   o  If the value of the USERNAME or USERHASH attribute is not valid,
      the server MUST generate an error response with an error code of
      401 (Unauthenticated).  This response MUST include a REALM value.
      It is RECOMMENDED that the REALM value be the domain name of the
      provider of the STUN server.

You include this sentence here and at the beginning of this section,
but not above (in at least 2 other places) where REALM is also mentioned?
Just mention the advice once earlier in this section?

14.10.  NONCE

   Note that this means that the NONCE attribute
   will not contain actual the surrounding quote characters.

This doesn't look right. Either drop "actual" or move it after "the"?