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

Brian, thanks for your review. I can see where you’re coming from with the points you raise about migrating versions, but given the nature of this extension, it seems like an urgent security-related version update is quite unlikely. Therefore leaving the time scale up to server policy seems ok.

James, thanks for your response. I entered a DISCUSS ballot to chat about the extensibility with custom events.

Thanks,
Alissa

> On Nov 5, 2019, at 2:37 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> 
> James,
> 
> Comments in line:
> On 06-Nov-19 07:58, Gould, James wrote:
>> 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
>> jgould@Verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgould@Verisign.com>
> 
>> 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" <noreply@ietf.org> 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. 
> 
> 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. 
> 
>>     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?
> 
> 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.
> 
>>     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. 
> 
> 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
>   
>>     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).
> 
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art