Subject: [P2PSIP] Isssues not fixed in draft-ietf-p2psip-base-13

From: Cullen Jennings <[email-masked]>
Date: Mon, 14 Mar 2011 18:43:37 -0600

There are a few things that did not get fixed in the -13 draft. Some due to just not sure how to fix them yet and some due to lack of time. The remanning open items are 

We need to update a few things to clarify usage when certificates have multiple node-id. Proposal is to say that, in cases other than when signaling a bootstrap peer, the first message is an Attach. The node-id used in the SignerIdentity of the Attach would indicate the node-id that this connection represented. The SignerIdentity still has to be one of the node-is in the certificate or the message is rejected. The same approach works for the non certificate based security modes. I realize this paragraph is clear as mud - we will work on better text. I may have misunderstood some of the email on this but I think this is the proposal from Marc, Bruce, and EKR. 

In section 6.3.4, it is not specified how to encode i into the hash. I'm proposing treating it as a uint32 and hashing that. 

> A.39. Section 6.2.2
> 
> I am not really sure to understand how the "exists=False" are synthesized when
> doing a Fetch on an array.  For example if a Store was made for an object with
> an index of 0xfffffffe, and the Fetch requests the whole array, will the answer
> contains 4294967294 "exists=False" objects? 

Proposal: Yes

> Also how are this synthesized elements signed?

Proposal: 
The "opaque value<0..2^32-1>;" would just indicate a 0 byte long binary blog and be encoded per normal. 

> A.40. Section 6.4.3.2
> 
> If exist is False, should the hash_value be the hash value of an empty byte
> array (i.e. da39a3ee5e6b4b0d3255bfef95601890afd80709 for SHA-1) or be omitted?

Proposal: 
empty byte array ... keep the code path all the same with no special rules for exists == False. Keep in mind that you need to "sign" a delete of an entry and have that interact properly when a partitioned overlay merges"

> A.43. Section 10.1 Element signature
> 
> What certificate should be used to compute (and verify) the signature for the
> whole configuration file?

Proposal: 
Add a <config-signer> to the configuration that is much like the  <kind-signer> but says who can sing the configuration file. IN the case of the first time you get a configuration file, that could come at same time as enrollment and be secured that way. 

> A.47. Section 6.3
> 
> The four policies defined in p2psip-base consistently says that "[a] given value
> MUST be written (or overwritten) if and only if the request is signed ..."
> Additional access control policies defined elsewhere use similar wording.
> 
> But should not the StoredData signature be used instead of the request
> signature?  When replicating the data, the signer of the StoreRequest will be
> different from the signer of the original request and so the test will no longer
> work.  Section 6.4.1.1 says that "[a] peer MUST [check that] [e]ach element is
> signed by a credential which is authorized to write this kind at this
> Resource-ID.", which seems to confirm that this is the element's signature that
> must be checked, not the request's.

So the elements sig need to be checked for sure. The questions is should the request sig also be checked before that. Unless we can say how to check it, seems like bad idea. Proposal: remove this or clarify. 

> A.38. Section 5.5.1.1. 'rel_addr_port corresponds to the rel-addr and rel-port
> productions.  Only present for type "relay".'
> 
> In ICE, the rel address and port are also present for srflx and prflx candidates.

my brain hurts. Proposal: go for beer

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 15 Mar 2011 10:23:05 -0700

Please see below for additional items that are not fixed in -13.  I'll respond
in separate emails to your proposals.

> my brain hurts. Proposal: go for beer

A.12 Section 10.3 states that "[t]he SubjectAltName field in the certificate
contains the following values: One or more Node-IDs...", but nowhere it is said
how to request multiple Node-IDs.  Is it an URL parameter of the POST request?
An attribute in the Certification Request object?

EKR: "Good question. This is an issue that's simply not addressed in the draft.,
but presumably we'll need to do something like this, yeah. My taste would be for
it to be a URL in the POSt."

CJ: "It's not really defined in this draft how to have Certificates with
multiple node-id. There are some arguments about if multiple node ids are useful
or not - The goal here is just to make sure that option is left open if a future
extension does this. A parameter on the post URL sounds like a good approach."

A.24. Section 10.1.1. "| attribute id { xsd:int }),"

Does not match 13.6, that is saying that this is an unsigned integer.  Should
probably use xsd:unsignedInt instead.

(the private kind ids, 4026531844 and up, cannot be used with this definition).

- -- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 15 Mar 2011 10:53:00 -0700

On 03/14/2011 05:43 PM, Cullen Jennings wrote:
> 
> There are a few things that did not get fixed in the -13 draft. Some due to
> just not sure how to fix them yet and some due to lack of time. The remanning
> open items are
> 
> 
> We need to update a few things to clarify usage when certificates have
> multiple node-id. Proposal is to say that, in cases other than when signaling
> a bootstrap peer, the first message is an Attach. The node-id used in the
> SignerIdentity of the Attach would indicate the node-id that this connection
> represented. The SignerIdentity still has to be one of the node-is in the
> certificate or the message is rejected. The same approach works for the non
> certificate based security modes. I realize this paragraph is clear as mud -
> we will work on better text. I may have misunderstood some of the email on
> this but I think this is the proposal from Marc, Bruce, and EKR.

Here's my proposal:

Section 3.2.1:

"  o  Establish a connection with an arbitrary peer in the overlay
      (perhaps based on network proximity or an inability to establish a
      direct connection with the responsible peer).  In this case, the
      client will rely on RELOAD's Destination List feature to ensure
      reachability.  The client can initiate requests, and any node in
      the overlay that knows the Destination List to its current
      location can reach it, but the client is not directly reachable
      using only its Node-ID.  If the client is to receive incoming
      requests from other members of the overlay, the Destination List
      required to reach it must be learnable via other mechanisms, such
      as being stored in the overlay by a usage.  If the certificate used
      by the client contains multiple Node-IDs, the client MUST immediately
      send a Ping request with a wildcard Node-ID, so the client and peer
      can learn each other Node-Id."

Section 5.1

"  o  The first entry on the destination list is an ID for which the
      peer is responsible.  A peer is always responsible for the wildcard
      Node-ID."

Section 5.1.1

"  o  If the entry is a Resource-ID, then it MUST be the only entry on
      the destination list.  If there are other entries, the message
      MUST be silently dropped.  Otherwise, the message is destined for
      this node and it passes it up to the upper layers.
   o  If the entry is the wildcard Node-ID, the message is destined for
      this node and it passes it up to the upper layers."

Section 5.3.4:

"    enum { reservedSignerIdentity(0),
            cert_hash(1), cert_hash_node_id(2) (255)} SignerIdentityType;

     struct {
       select (identity_type) {
         case cert_hash:
           HashAlgorithm      hash_alg;              // From TLS
           opaque             certificate_hash<0..2^8-1>;

         case cert_hash_node_id:
           HashAlgorithm      hash_alg;              // From TLS
           opaque             certificate_hash<0..2^8-1>;
           NodeId             node_id;

         /* This structure may be extended with new types if necessary*/
       };
     } SignerIdentityValue;

     struct {
       SignerIdentityType     identity_type;
       uint16                 length;
       SignerIdentityValue    identity[SignerIdentity.length];
     } SignerIdentity;

     struct  {
        SignatureAndHashAlgorithm     algorithm;   // From TLS
        SignerIdentity                identity;
        opaque                        signature_value<0..2^16-1>;
     } Signature;

   The signature construct contains the following values:

   algorithm
      The signature algorithm in use.  The algorithm definitions are
      found in the IANA TLS SignatureAlgorithm Registry.  All
      implementations MUST support RSASSA-PKCS1-v1_5 [RFC3447]
      signatures with SHA-256 hashes.

   identity
      The identity used to form the signature.

   signature_value
      The value of the signature.

   The identity format can take two forms, depending if the certificate
   contains one or more Node-IDs.  If the certificate contains only one
   Node-ID, the cert_hash is used The hash_alg field is used to indicate the
   algorithm used to produce the hash.  The certificate_hash contains
   the hash of the certificate object (i.e., the DER-encoded
   certificate).

   If the certificate contains more than one Node-ID, the cert_hash_node_id
   form is used, with node_id containing the Node-ID selected."

- -- 
Marc Petit-Huguenin

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 15 Mar 2011 11:19:11 -0700

> just not sure how to fix them yet and some due to lack of time. The remanning

[...]

>> A.39. Section 6.2.2
>> 
>> I am not really sure to understand how the "exists=False" are synthesized
>> when doing a Fetch on an array.  For example if a Store was made for an
>> object with an index of 0xfffffffe, and the Fetch requests the whole array,
>> will the answer contains 4294967294 "exists=False" objects?
> 
> Proposal: Yes
> 
> Proposal: The "opaque value<0..2^32-1>;" would just indicate a 0 byte long
> binary blog and be encoded per normal.
> 

My proposal is to get rid of the synthesized elements.  A Fetch returns the
array with holes in it but returns the exists=False elements that were sent.

This solves a lot of issues (who sign them?  What is the storage_time and
lifetime of a synthesized element?)

- -- 
Marc Petit-Huguenin

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 15 Mar 2011 11:29:48 -0700

[...]

>> A.47. Section 6.3
>> 
>> The four policies defined in p2psip-base consistently says that "[a] given
>> value MUST be written (or overwritten) if and only if the request is signed
>> ..." Additional access control policies defined elsewhere use similar
>> wording.
>> 
>> signature?  When replicating the data, the signer of the StoreRequest will
>> be different from the signer of the original request and so the test will
>> no longer work.  Section 6.4.1.1 says that "[a] peer MUST [check that]
>> [e]ach element is signed by a credential which is authorized to write this
>> kind at this Resource-ID.", which seems to confirm that this is the
>> element's signature that must be checked, not the request's.
> 
> So the elements sig need to be checked for sure. The questions is should the
> request sig also be checked before that. Unless we can say how to check it,
> seems like bad idea. Proposal: remove this or clarify.

Well, both need to be verified, the request when it is received and the element
just before been inserted in the storage.  When a peer receives a Store request
because of replication, it will receive a Store request that will probably have
a different SignerIdentity for the request and for the elements to store.  So my
proposal is this:

Section 6.3.1:

"  In the USER-MATCH policy, a given value MUST be written (or
   overwritten) if and only if the value is signed with a key
   associated with a certificate whose user name hashes (using the hash
   function for the overlay) to the Resource-ID for the resource.
   Recall that the certificate may, depending on the overlay
   configuration, be self-signed."

Section 6.3.2:

"  In the NODE-MATCH policy, a given value MUST be written (or
   overwritten) if and only if the value is signed with a key
   associated with a certificate whose Node-ID hashes (using the hash
   function for the overlay) to the Resource-ID for the resource."

Section 6.3.3:

"  The USER-NODE-MATCH policy may only be used with dictionary types.
   In the USER-NODE-MATCH policy, a given value MUST be written (or
   overwritten) if and only if the value is signed with a key
   associated with a certificate whose user name hashes (using the hash
   function for the overlay) to the Resource-ID for the resource.  In
   addition, the dictionary key MUST be equal to the Node-ID in the
   certificate."

Section 6.3.4:

"  In the NODE-MULTIPLE policy, a given value MUST be written (or
   overwritten) if and only if the value is signed with a key
   associated with a certificate containing a Node-ID such that
   H(Node-ID || i) is equal to the Resource-ID for some small integer
   value of i.  When this policy is in use, the maximum value of i MUST
   be specified in the kind definition."

- -- 
Marc Petit-Huguenin

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 15 Mar 2011 11:50:37 -0700

On Mar 15, 2011, at 11:19 AM, Marc Petit-Huguenin wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

Hi Marc,

I think I'm the person who put this text in originally but it's been a while so I'm trying to reconxtruct
my reasoning.

Let's ignore arrays for a second and just talk about simple elements. A requester asks for
objects with resource-ids A, B, and C, but B doesn't exist and so he just gets A and C. Now
he has to remember what he asked for and do some set intersection to see what was and
wasn't returned. By contrast, if you get back an answer for every request, then it's simpler to
understand the response. I'm not saying that it's impossible to do the former, but the latter
is easier.

Now, when we come to arrays, life is more complicated, since I might ask for either
element i or elements i..j. We could have the rule that we never return synthesized
elements for arrays, or that we only do so for explicit as opposed to range queries,
or that we always do. All of these are consistent, I think.

Anyway, you may or may not find the original rationale compelling--I'm not sure if I still do--but
IIRC that was the reason.

-Ekr

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 15 Mar 2011 12:35:36 -0700

> understand the response. I'm not saying that it's impossible to do the former, but the latter

Aaaah.  My reading of the spec was that elements were synthesized only for
arrays.  Now I get it.  "exists=False" is used in fact for two different
functions: to remove an existing element, and as a placeholder for no-existence
when retrieving data.

In this case I withdraw my proposal to get rid of them, but I still have the
question about the signer of the synthesized element (also the storage_time and
lifetime to use).

> IIRC that was the reason.

Yeah, and removing an element could have been done by updating it with
lifetime=0, which would have permit to remove the "exists".

Anyway, let's keep things as they are.

- -- 
Marc Petit-Huguenin

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 15 Mar 2011 17:41:03 -0700

I found two more issues not fixed in -13 that were in my list but were also
reported previously to the mailing-list by someone else.  Instead of repeating,
here's the last message exchanged on each of these subjects:

http://www.ietf.org/mail-archive/web/p2psip/current/msg05792.html

http://www.ietf.org/mail-archive/web/p2psip/current/msg05564.html

- -- 
Marc Petit-Huguenin

---

From: Michael Chen <[email-masked]>
Date: Wed, 30 Mar 2011 19:05:27 -0800

Hi,

While looking at the diff between base-12 and 13, I spotted couple simple problems:

1) Section 5.5.1.2, the following sentence should get its own "o" bullet. There 
should be altogether 4 bullets:

   o  If the peer is overloaded or detects some other kind of error, it
       MAY generate an error instead of an AttachReqAns.

Also, in my proposed language for this section, I have one sentence right before 
the "*" bullets that is not included in base-13:

+     The tie-breaker heuristic is to compare the Node-IDs of both
+     peers as unsigned integers, and

No where in this draft talks about one Node-ID "smaller" or "larger" than 
another Node-ID. I thought this language or something similar can help 
implementors understand the heuristic better. Wrong implementation of this 
comparison defeats the heuristic completely.

2) Please remove the extra "x" letter in my name in paragraph right above 
Section 15.

Thanks

Michael Chen

On 3/14/2011 4:43 PM, Cullen Jennings wrote:
> Add a<config-signer>  to the configuration that is much like the<kind-signer>  but says who can sing the configuration file. IN the case of the first time you get a configuration file, that could come at same time as enrollment and be secured that way.
>
>> A.47. Section 6.3
>>
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip
>
>