On Wed, Aug 15, 2018 at 7:42 AM, Gould, James <[email protected]> wrote:
> Eric, > > Thank you for your review and feedback. I provide responses to your > feedback below. > > > — > > JG > > > > James Gould > Distinguished Engineer > [email protected] > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com <http://verisigninc.com/> > > On 8/15/18, 10:02 AM, "Eric Rescorla" <[email protected]> wrote: > > Eric Rescorla has entered the following ballot position for > draft-ietf-regext-allocation-token-09: 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-regext-allocation-token/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Rich version of this review at: > https://mozphab-ietf.devsvcdev.mozaws.net/D3061 > > > These are bearer tokens and therefore I believe transport encryption > needs to be required in S 7, not just listed as should (which isn't > even normative in this context). > > JG - "An Allocation Token should be considered secret information by the > client and should be protected at rest and in transit." can be changed to > "An Allocation Token should be considered secret information by the client > and SHOULD be protected at rest and MUST be protected in transit." > Yes, this seems like the minimum. ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > S 3.2.4. > > like [RFC5731], the command MUST contain a child > > <allocationToken:allocationToken> element for the client to be > > authorized to transfer and allocate the object. The > authorization > > associated with the Allocation Token is in addition to and does > not > > replace the authorization mechanism defined for the object's > > <transfer> request command. If the Allocation Token is invalid > or > > I'm having trouble processing this statement. Can you explain in more > detail what the two access control checks are here. > > JG - RFC 5731 includes support for an authorization info > (<domain:authInfo>) that is an existing credential stored in the server at > the time of the create command, which can be updated with an update > command, that is used by the gaining client (registrar) to authorize a > transfer request. The registrant should have access to the authorization > info from their sponsoring registrar to pass to the gaining registrar to > authorize the transfer request. The Allocation Token is not meant to > replace the RFC 5731 authorization info, but is meant as an additional > credential to authorize the "allocation" of the domain name. A registry > may hold premium domain names that have an authorization info value, and > leverage the transfer command for use in allocation with the use of the > additional allocation token. Let me know if you need any additional > clarification on this. Why is this just true for transfer and not the other commands? > S 7. > > specifications apply to this specification as well. > > > > The mapping acts as a conduit for the passing of Allocation > Tokens > > between a client and a server. The definition of the Allocation > > Token is defined outside of this mapping. The following are > security > > considerations in the definition and use of an Allocation Token: > > Do you want to use normative language here? > > JG - Are you requesting normative language such as "The definition of the > Allocation Token SHOULD be defined outside of this mapping". There are > cases when the allocation token is a non-complex string value that does not > require formal definition, so the normative SHOULD seems most appropriate > here. Do you agree? > I think you probably want this, yes. > S 7. > > 3. An Allocation Token should have a limited life with some > form of > > expiry in the Allocation Token if generated by a trusted 3rd > > third party, or with a server-side expiry if generated by > the > > server. > > 4. An Allocation Token should use a strong random value if it > is > > based on an unsigned code. > > What is an "unsigned code"? > > JG - An unsigned code is a non-complex string that the server generates > and stores with the domain name, which can be later validated during > allocation. > Where can I find a reference for this? -Ekr
_______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
