Subject: [Last-Call] Genart last call review of draft-ietf-regext-login-security-05

From: Brian Carpenter via Datatracker <[email-masked]>
Date: Sat, 02 Nov 2019 20:49:20 -0700

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

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.

I also think a short discussion of adding & removing versions is
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.

FYI, there are some other extension design considerations in
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).

---

From: "Gould, James" <[email-masked]>
Date: Tue, 5 Nov 2019 18:58:54 +0000

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

[email-masked] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email-masked]>

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" <[email-masked]> wrote:

    Review Date: 2019-11-03

    IESG Telechat date:

    --------

    Minor issues:

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

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.

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

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.

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

    Nits:

    -----

    "1.  Introduction

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 6 Nov 2019 08:37:34 +1300

James,

Comments in line:

Yes, that makes sense. I think that because this section occurs *before* the technical details it isn't quite clear what "version" means - I certainly had to come back to this section after reading the whole text. But you probably don't want to mention loginSec-0.x, hence the examples I suggested. 

> 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?

Making it clear that it's a policy choice is an improvement, yes. But I still think that it would be useful to indicate a timescale. I've seen migration overlaps ranging anywhere from seconds to years in different protocols and I really have no idea where this one lies on that spectrum.

> 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 secur…

Of course. But the specific case of a security-driven update is special and may be much more urgent than normal policy. That's why I'd be inclined to mention it. Not a big deal, however.

Regards
   Brian Carpenter