Re: [Gen-art] Genart last call review of draft-ietf-regext-login-security-05

["Gould, James" <[e-mail]>]

Brian,



Thank you for your review and feedback.  My responses are embedded below.  I will include updates based on your feedback in draft-ietf-regext-login-security-06 at the conclusion of the last call.



--



JG







James Gould

Distinguished Engineer

[e-mail] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>



703-948-3271

12061 Bluemont Way

Reston, VA 20190



Verisign.com <http://verisigninc.com/>



On 11/2/19, 11:49 PM, "Brian Carpenter via Datatracker" <[e-mail]> wrote:



    Reviewer: Brian Carpenter

    Review result: Ready with Issues



    Gen-ART Last Call review of draft-ietf-regext-login-security-05



    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 treat these comments just

    like any other last call comments.



    For more information, please see the FAQ at

    <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.



    Document: draft-ietf-regext-login-security-05.txt

    Reviewer: Brian Carpenter

    Review Date: 2019-11-03

    IETF LC End Date: 2019-11-12

    IESG Telechat date:



    Summary: Ready with minor issues

    --------



    Minor issues:

    -------------



    I found section 2 "Migrating to Newer Versions of This Extension"

    a little hard to follow. Firstly, am I correct in assuming that

    "a new version" means a version number higher than 1.0, e.g.

    "loginSec-1.1"? That is probably the intended meaning, but I think

    it needs to be explicit. Maybe state that this document defines

    "loginSec-1.0" and future documents can define other minor and major

    versions such as "loginSec-1.1" or "loginSec-2.0".



JG - The "Migration to Newer Versions of This Extension" section was originally meant to address point version updates (e.g., loginSec-0.2, loginSec-0.3) prior to version loginSec-1.0, but Barry Leiba's review feedback recommended leaving it in the draft.  This section is applicable to any version change, including migrating from a pre-loginSec-1.0 version to loginSec-1.0 or a future update of loginSec-1.0 to loginSec-1.1.  I believe the language needs to remain generic to apply to both cases.



    Then "(for a temporary migration period)" is a bit vague. I think

    it would be useful to suggest the order of magnitude of the overlap

    period: days?, months?; hopefully not years.



JG - The migration period is up to server policy.  It could be made more explicit by changing it to read "(for a temporary migration period up to server policy)".  Do you agree with this change?



    I also think a short discussion of adding & removing versions is version

    needed in the Security Considerations, since the reason for a new

    version might be the discovery of a vulnerability in the current

    version. That's when a short migration period is desirable.



JG – I don’t see the linkage of adding & removing versions to the Security Considerations, since a version change may be due to multiple reasons (functional issue, functional enhancement, and security).  The length of time for the migration is up to server policy based on many factors outside of the protocol.



    FYI, there are some other extension design considerations in

    https://tools.ietf.org/html/rfc6709#section-4 .



JG – Thank you, I’ll be sure to review https://tools.ietf.org/html/rfc6709#section-4.



    Nits:

    -----



    "1.  Introduction



       This document describes an Extensible Provisioning Protocol (EPP)

       extension for enhancing the security of the EPP login command in EPP

       RFC 5730.  The enhancements include supporting longer passwords (or

       passphrases) than the 16-character maximum and providing a list of

       security events in the login response.  The password (current and

       new) in EPP RFC 5730 can be overridden..."



    "RFC 5730" should either be in parenthesis as "(RFC 5730)" or

    a reference "[RFC5730]" (twice).



    JG – I will change the RFC 5730 references in the Introduction to use links (xrefs).