[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"?
- [tram] Alexey Melnikov's Discuss on draft-ietf-tr… Alexey Melnikov
- Re: [tram] Alexey Melnikov's Discuss on draft-iet… Marc Petit-Huguenin