Subject: Re: [weirds] Security Service Summary

From: Edward Lewis <[email-masked]>
Date: Thu, 1 Nov 2012 09:19:50 -0400

At 14:24 +0000 10/30/12, Hollenbeck, Scott wrote:

>Data Integrity: we have not identified a requirement to provide this 
>service. There may, however, be a requirement to provide some sort 
>of response element that confirms that an element has been 
>"validated" or "verified", which some people will likely confuse 
>with a data integrity service. QUESTION: how do we want to approach 
>this?

I would suggest dividing this in two.

Data Integrity: <if defined, it would say that the source of the 
information, such as the registry database, would provide ancillary 
data like a digital signature to allow verification that the data 
received originated with the true source>

Data Accuracy: a field the carries ancillary information indicating 
whether and when a value was out-of-band validated/verified.

I'd categorize the former as a security-related requirement of the 
effort, the latter as a data-feature requirement.

PS - In the back of my mind is again DNS.  DNS is not a client-server 
protocol, it is a client-cache-server protocol.  The intermediate 
cache is a core element to the protocol, hence we do have, in 
DNSSEC-thought, to deal with the difference between end-to-end and 
hop-by-hop security.  In DNSSEC, data integrity is not channel 
security because the cache could mess with the data.  Channel 
security is not transitive - as in A=B, B=C, ergo A=C.  For DNS A=B 
and B=C might still yield A=/=C.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

2012...time to reuse those 1984 calendars!

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 1 Nov 2012 14:05:06 +0000

> -----Original Message-----
> From: Edward Lewis [mailto:[email-masked]]
> Sent: Thursday, November 01, 2012 9:20 AM
> To: Hollenbeck, Scott
> Cc: [email-masked]
> Subject: Re: [weirds] Security Service Summary
> 
> >service. There may, however, be a requirement to provide some sort of
> >response element that confirms that an element has been "validated" or
> >"verified", which some people will likely confuse with a data
> integrity
> >service. QUESTION: how do we want to approach this?
> 

Agreed. I'll split the topics for discussion in Atlanta.

Scott

---

From: Francisco Arias <[email-masked]>
Date: Mon, 5 Nov 2012 14:34:23 -0800

Hi Scott,

Please see below.

On 10/30/12 7:24 AM, "Hollenbeck, Scott" <[email-masked]> wrote:

>Authentication: We have a requirement to specify an HTTP-based
>authentication mechanism. QUESTION: which one? HTTP basic? HTTP digest?
>HTTP basic could be used with https (see data confidentiality below).

Why only one authentication mechanism?

>Availability: we have a DDoS security consideration that can be addresses
>with a normative reference to RFC 4732. We have a requirement to support
>query and display of contact entities for abuse reporting.

Regarding the abuse contact, I don't think this is an Availability
requirement. I think that is only a data element in the response.

>RFC 3707 says that when a value in an answer to a query is given, the
>protocol MUST be capable of tagging the value with the following labels:
>
>1. do not redistribute
>2. special access granted
>
>QUESTION: Is this a requirement for RDAP?

I haven't seen the need for this, therefore I'd suggest this is not a
requirement for RDAP.

>"verified", which some people will likely confuse with a data integrity

As I said in another email the "validated" or "verified" elements are just
that, there is no procotol work here and no security requirement.

>Non-repudiation: we have not identified a requirement to provide this
>service.

I'm not aware of this being used by a registry but Peter mentioned there
were some registries.

__

Francisco.