Subject: Re: [regext] Privacy and HR considerations for draft-ietf-regext-verificationcode

From: Thomas Corte <[email-masked]>
Date: Wed, 2 Jan 2019 12:07:41 +0100

Hello,

On 12/26/18 15:32, Gould, James wrote:

> Do others in the working group believe that either the verification process of the VSP is in scope based on the current wording of the draft or that a consideration section can cover something that is outside the defined scope of the draft?

No, I agree that it's way out of scope. Gurshabad's proposed additions
are in my point of view an attempt to address *judicial* issues (ensuring
people's right to privacy, non-discrimination etc.) by adding wording to
a *technical* specification. Lawyers and politicians exist to deal with
such issues; engineers should not be required to waste their time with them.

Plus, even *if* such wording should end up in the draft, it would be
utterly pointless. Looking at the various implementations of EPP and EPP
extensions which are out in the open (especially for country code TLDs),
it's obvious that even the most basic technical requirements (such as
strict XML schema compliance) and MUST regulations are often ignored or
violated by many operators. I'd therefore be surprised if anyone who's
determined to "abuse" the extension for human rights violations would
care much about the proposed additions anyway.

Best regards,

Thomas

-- 
____________________________________________________________________
     |       |
     | knipp |            Knipp  Medien und Kommunikation GmbH
      -------                    Technologiepark
                                 Martin-Schmeißer-Weg 9
                                 44227 Dortmund
                                 Deutschland

     Dipl.-Informatiker          Tel:    +49 231 9703-0
     Thomas Corte                Fax:    +49 231 9703-200
     Stellvertretender Leiter    SIP:    [email-masked]
     Software-Entwicklung        E-Mail: [email-masked]

                                 Registereintrag:
                                 Amtsgericht Dortmund, HRB 13728

                                 Geschäftsführer:
                                 Dietmar Knipp, Elmar Knipp

---

From: Niels ten Oever <[email-masked]>
Date: Wed, 2 Jan 2019 16:17:31 +0100

Hi all,

I strongly support the inclusion of text in the draft. 

I think the differentiations that are being made here between 'technical' and 'policy', and 'technical' and 'judicial' here are merely rhetorical. No clear definition of the either terms and/or the difference have been offered thus far. Thus the argument to not include the text seems unfounded.

Next to that, I have not been able to locate the limitation for the use of MUST and MAY, as defined by John Levine, in RFC2119.

Best,

Niels

-- 
Niels ten Oever
Researcher and PhD Candidate
Datactive Research Group
University of Amsterdam

PGP fingerprint	   2458 0B70 5C4A FD8A 9488  
                   643A 0ED8 3F3A 468A C8B3

---

From: "Gould, James" <[email-masked]>
Date: Wed, 2 Jan 2019 16:44:26 +0000

Gurshabad,

For the defined purpose of draft-ietf-regext-verificationcode, the VSP needs to be defined as an entity, but the VSP's verification process is not defined and is out-of-scope.  The use of examples in an IETF draft does not classify as guidance.  The only obligation of the VSP within draft-ietf-regext-verificationcode is to generate a technically compliant verification code and to store the proof of verification and the generated verification code.  There is no concrete definition defined within draft-ietf-regext-verificationcode of: 
- the forms of verifications performed by a VSP, 
- the data that must be passed for verification, 
- how the verification data is processed,
- the data sources that are used to perform the verification,
- the interface(s) or protocol(s) used by a VSP, and 
- other policies and technical details of a VSP.  

The majority of your considerations (Privacy and identified paragraphs from the HR) is focused on the policies and interfaces / protocols of the VSP that is by design out-of-scope from draft-ietf-regext-verificationcode.  

My recommendation is to strictly focus your proposed considerations text on the scope of draft-ietf-regext-verificationcode, that includes the definition of the verification code (e.g., digitally signed, typed identifier that provides proof of verification) and the passing of the verification code between the client (registrar) and the server (registry) over EPP. 

    > I recommend that inclusion of these sort of elements be brought up to
    > the IETF-level.
    
    Not sure what you mean here. I think there is enough clarity from
    the chairs and the IESG that it is entirely up to the WG about what to
    include in the WG draft. [0][1][2]
  
Yes, it is my position that the proposed text included in your proposed sections as non-technical and focused on policy elements that the WG is not qualified to discuss and come to consensus on.  If you desire to have these sort of sections in WG drafts, it is best for it to be handled at the IETF-level and not at the WG-level.

Can you provide your latest proposed section(s) on the list for consideration by the WG?  

We also need to continue to hear from others in the working group.

Thanks,

—
 
JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

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

On 12/28/18, 5:49 AM, "Gurshabad Grover" <[email-masked]> wrote:

    On 26/12/18 8:02 PM, Gould, James wrote:
    > [...] The thread with Andrew Newton did not clarify the applicability of the Privacy Considerations, but addressed two technical issues related to fixing the described relationship of the client with the server, and fixing the inappropriate inclusion of a normative policy statement.  The clearly out of scope elements of the HR Considerations section include the following bulleted items that are only associated with the VSP, and have nothing to do with draft-ietf-regext-verificationcode. [...]     
    >  
    
    For the context of the considerations, let's look at some text from the
    draft:
    
    "The VSP has access to the local data sources and is authorized to
    verify the data. Examples include verifying that the domain name is not
    prohibited and verifying that the domain name registrant is a valid
    individual, organization, or business in the locality."
    
    "It is up to the VSP and the server to define the valid values for the
    "type" attribute. Examples of possible "type" attribute values include
    "domain" for verification of the domain name, "registrant" for
    verification of the registrant contact, or "domain-registrant" for
    verification of both the domain name and the registrant. The typed
    signed code is used to indicate the verifications that are done by the VSP."
    
    "The VSP MUST store the proof of verification and the generated
    verification code; and MAY store the verified data."
    
    So, the draft
    (1) describes the role of the VSP;
    (2) has guidance on what types of verification the VSP can perform; and
    (3) places certain obligations on the VSP.
    
    So, I think it's unfair to say that considerations that touch upon the
    VSP's role "have nothing to do with draft-ietf-regext-verificationcode."
    
    Re: text of the considerations...
    
    The proposed privacy considerations rely entirely on the draft and the
    guidance in RFC6973 (very commonly used across working groups to write
    privacy considerations). Specifically, the excerpts above and the
    following items in RFC6973:
    
    * "Are there expected ways that information exposed by the protocol will
    be combined or correlated with information obtained outside the
    protocol?" [3]
    
    * "Does the protocol provide ways for initiators to express individuals'
    preferences to recipients or intermediaries with regard to the
    collection, use, or disclosure of their personal data?" [4]
    
    The proposed text addresses these, and in fact, uses terminology from
    only the draft and RFC6973.
    
    Similarly, most HR considerations directly follow from the privacy
    considerations and rely on guidance in RFC8280. Specifically,
    
    * "Can your protocol contribute to filtering in such a way that it could
    be implemented to censor data or services?" [5]
    
    * "What is the potential for discrimination against users of your
    protocol?" [6]
    
    Open to further discussing the rationale behind the proposed text. Would
    also like to hear what others think.
    
    Thank you.
    Gurshabad
    
    PS.
    
    > I recommend that inclusion of these sort of elements be brought up to
    > the IETF-level.
    
    Not sure what you mean here. I think there is enough clarity from
    the chairs and the IESG that it is entirely up to the WG about what to
    include in the WG draft. [0][1][2]
    
    [0] https://youtu.be/LYYehA0LNRc?t=8690
    [1] https://www.ietf.org/mail-archive/web/regext/current/msg01991.html
    [2] https://www.ietf.org/mail-archive/web/regext/current/msg01993.html
    [3] https://tools.ietf.org/html/rfc6973#section-7.1
    [4] https://tools.ietf.org/html/rfc6973#section-7.2
    [5] https://tools.ietf.org/html/rfc8280#section-6.2.6
    [6] https://tools.ietf.org/html/rfc8280#section-6.2.13

---

From: "Gould, James" <[email-masked]>
Date: Wed, 2 Jan 2019 16:44:40 +0000

John,

The 2119 words MUST and MAY are used to signify requirements; although that does imply interoperability as well.  This statement is associated with making the verification code functional, since the verification code represents a signed and typed verification pointer, it must point to something.  The VSP is required, by the normative MUST, to store the proof of verification and the generated verification code, and can optionally, by the normative MAY, store the verified data.  The "; and MAY store the verified data" can be removed, since the proof of verification is the only requirement for the verification code to be a functional pointer.  

Do you agree that the "; and MAY store the verified data" text should be removed?    The statement would then read:

"The VSP MUST store the proof of verification and the generated verification code."

Thanks,
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

On 12/28/18, 2:45 PM, "regext on behalf of John Levine" <[email-masked] on behalf of [email-masked]> wrote:

    >verification code; and MAY store the verified data."
    
    The 2119 words MUST and MAY are about interoperation.
    
    Now that you point it out, this has nothing to do with interoperation
    unless compliance somehow affects interop.
    
    I would suggest removing that part, or at least making it
    non-normative since business practices are generally way out of scope
    for IETF specs.
    
    R's,
    John
    
    _______________________________________________
    regext mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/regext

---

From: "John R Levine" <[email-masked]>
Date: 2 Jan 2019 13:10:30 -0500

> The 2119 words MUST and MAY are used to signify requirements; although 
> that does imply interoperability as well.  This statement is associated 
> with making the verification code functional, since the verification 
> code represents a signed and typed verification pointer, it must point 
> to something.

I don't understand why.  The code is a signed token.  Imagine the registry 
goes back to the signer asks about token 123-foo666 and the answer is 
"We're the Ministry, we signed it, of course it's valid.  The details are 
secret."

While that would not be my favorite way to work, and I can easily imagine 
other scenarios with auditing and transparency business requirements, why 
wouldn't that interoperate?

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Adam Roach <[email-masked]>
Date: Wed, 2 Jan 2019 14:31:53 -0600

[as an individual]

On 1/2/19 12:10 PM, John R Levine wrote:
>> The 2119 words MUST and MAY are used to signify requirements; 
>> although that does imply interoperability as well.  This statement is 
>> associated with making the verification code functional, since the 
>> verification code represents a signed and typed verification pointer, 
>> it must point to something.
>
> I don't understand why.  The code is a signed token.  Imagine the 
> registry goes back to the signer asks about token 123-foo666 and the 
> answer is "We're the Ministry, we signed it, of course it's valid.  
> The details are secret."
>
> While that would not be my favorite way to work, and I can easily 
> imagine other scenarios with auditing and transparency business 
> requirements, why wouldn't that interoperate?

If we're concerned merely with interoperation, the same is true of most 
-- if not all -- normative keywords used in "Security Considerations" 
sections. Your position might (or might not) be correct, but the logic 
of "2119 language is only used for interoperabilty reasons" simply isn't 
true.

/a

---

From: "John R Levine" <[email-masked]>
Date: 2 Jan 2019 15:55:49 -0500

On Wed, 2 Jan 2019, Adam Roach wrote:
> If we're concerned merely with interoperation, the same is true of most -- 
> if not all -- normative keywords used in "Security Considerations" sections. 
> Your position might (or might not) be correct, but the logic of "2119 
> language is only used for interoperabilty reasons" simply isn't true.

I think there's a difference -- in security sections the goal is usually 
to prevent leakage or spoofing or something else that would allow a 
malicious party to interoperate with a victim.  One part of good interop 
is not to interoperate with attackers.  But that's not what's going on 
here.  The signature shows that the token is valid, and unless I'm missing 
something, whatever you might learn from the thing the token represents is 
outside the scope of EPP.

Regards,

---

From: "Gould, James" <[email-masked]>
Date: Wed, 2 Jan 2019 21:55:48 +0000

John,

To remove any concerns related to the inclusion of VSP policy in draft-ietf-regext-verificationcode, the sentence " The VSP MUST store the proof of verification and the generated verification code; and MAY store the verified data." can be removed.  If there are no objections to the removal of this sentence, it will be removed in the next version of the draft.  
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

On 1/2/19, 3:56 PM, "regext on behalf of John R Levine" <[email-masked] on behalf of [email-masked]> wrote:

    
    Regards,

---

From: "John R Levine" <[email-masked]>
Date: 2 Jan 2019 17:08:42 -0500

> To remove any concerns related to the inclusion of VSP policy in draft-ietf-regext-verificationcode, the sentence " The VSP MUST store the proof of verification and the generated verification code;…

That's OK with me.  I'm not totally opposed to it but without some hint 
about what an interoperating system would do with the object the token 
points to, I think it's confusing.  As you can see, it confused me.

Regards,