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

[Alissa Cooper]

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  
> 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
>> jgo...@verisign.com 
>> 
> 
>> 703-948-3271
>> 12061 Bluemont Way
>> Reston, VA 20190 
>> Verisign.com  
>> 
>> On 11/2/19, 11:49 PM, "Brian Carpenter via Datatracker"  
>> 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
>> .
>> 
>> 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 
>> 

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

[Brian E Carpenter]

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
> jgo...@verisign.com 
> 

> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190 
> Verisign.com  
> 
> On 11/2/19, 11:49 PM, "Brian Carpenter via Datatracker"  
> 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
>     .
> 
> 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 

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

[Gould, James]

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

jgo...@verisign.com 




703-948-3271

12061 Bluemont Way

Reston, VA 20190



Verisign.com 



On 11/2/19, 11:49 PM, "Brian Carpenter via Datatracker"  
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

.



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).
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Brian Carpenter via Datatracker]

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
.

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

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art