Subject: [P2PSIP] draft-ietf-p2psip-base-12 (3)

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 06 Dec 2010 14:12:29 -0800

More questions, comments and nits:

A.13. Section 5.3.1.1 "...ResourceIds are variable length, up to 255 bytes (2048
bits)..."

Because Destination has a length field defined as an uint8 that effectively
limits the size of DestinationData to 255 bytes, and because ResourceId is
prefixed by one byte indicating the length, the ResourceId length is limited to
254 bytes, or 2032 bits.

A.14. Section 5.3.2  "uint32 length;"

I can assume that this length covers the Header, MessageContents and Signature,
but I would guess that this was useful when Message was sent without
FramingHeader over TCP (same than for the relo_token used to disambiguate STUN
packets).  Now that this is useless, can't this length been only Header and
MessageContents, so it is possible to find the boundary between MessageContents
and Signature without having to parse MessageContents at all?

A.15. Section 5.3.4 "HashAlgorithm hash_alg;"

What are the algorithms that should be supported?
Is the hash only used to identify the certificate in SecurityBlock.certificates?
Also the text says that "[t]he certificate_hash contains the hash of the
certificate object."  Are we talking about the hash of the DER encoded
certificate, as stored in GenericCertificate.certificate?

A.16. Section 5.5.1.1. "IceCandidate candidates<0..2^16-1>;"

Because there must be at least one candidate, should this be:

IceCandidate candidates<1..2^16-1>;

A.17. "config_data (type==config)"

The definition of this field is "[t]he contents of the configuration document",
but 10.1 says that a file "...can contain multiple 'configuration' elements...".
 So should not this field be in fact defined as "One XML configuration
production.  This MUST be encoded with UTF-8 and assume a default namespace of
...", like for the kinds value?  And in this case what about the signature
element in the XML fragment?

A.18. Section 5.6.2 "...not all aspects of the header apply to both types of
transports."

It would be great if this could be explained a little bit more.  For example I
assume that on a reliable link, the receiver still need to send the Ack for each
frame received (to calculate the RTO), but what about the content of the
ack_sequence and received fields?

A.19. Section 5.6.3.1.1, last paragraph

This paragraph described a lockstep algorithm, but if it is the case then there
is no need for the received field, as we would always know that the previous
messages have been received.

A.20. Section 5.7, "If the message is not fragmented, then both the first and
last fragment are set to 1..."

If the first fragment bit is set to 1 when the message is fragmented and is also
set to one when the message is not fragmented, then it is always set to 1, so
what is the point of having it in the first place?

A.21. Section 10.1. "<kind name='sip-registration'><data-model>..."

Why do we need to repeat the data-model and access-control that were already in
the IANA registry?  Or is it a way to override the IANA definitions as the
example would suggest? (as the registration for SIP-REGISTRATION is using
DICTIONARY and USER-NODE-MATCH).

A.22. Section 10.1. "sequence: a monotonically increasing sequence number
between 1 and 2^32"

According to section 5.3.2 and 5.3.2.1, it should be between 0 and 2^16-2 (65534).

A.23. Section 10.1. "root-cert  This element..."

I guess that the encoding to use is base64, but it is said nowhere.

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.

Note that there is other places in the RELAX NG document where the type can be
improved (initial-ttl, etc...)

A.25. Section 10.1.1. 'access-control-type |= "user-match-with-anon-create"'

This control type is never defined in the document.

A.26. Section 10.1.1. 'kind-names |= "sip-registration"'

the sip-registration kind is not defined in this document.  OTOH,
certificate-by-node and certificate-by-name are defined, but not listed here.

A.27. Section 10.1.1. 'self-signed-digest-type |= "sha1"'

Section 10.1. says that '[v]alid values for this parameter are "SHA-1" and
"SHA-256"'.

A.28. Section 10.1.1 last paragraph "such an XML configuration file sent over
email."

Because the signatures on the XML document are done on exact byte string and
because emails servers are known to mess with end of lines, we will see
configuration documents that cannot be verified after been sent by email (what
was wrong with using XML-sig anyway?).

A.29. Section 13.15 "destination: a hex-encoded Destination List object"

A Destination List object is never formally defined in the whole document, so is
it just Destination objects packed together, or is it in fact a "Destination
destination_list<0..2^16-1>" ?  In other words, does it start with a length field?

Nits:
- ----

- - Section 5.7 After "Where these values are:"

s/resource/resource_id/

- - Section 6.4.1.2. "...that the storing peer is not require to perform this
verification."

s/require/required/

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

---

From: jc <[email-masked]>
Date: Mon, 6 Dec 2010 17:34:36 -0500

On Dec 6, 2010, at 5:12 PM, Marc Petit-Huguenin <[email-masked]> wrote:

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

2040 bits.

> Is the hash only used to identify the certificate in SecurityBlock.certificates?

No, it is used for AOR storage among other things.

> certificate, as stored in GenericCertificate.certificate?

The binary representation, yes.

> IceCandidate candidates<1..2^16-1>;

The storage is still <0 .. 2 ^ 16 - 1> but your also correct.

> ...", like for the kinds value?  

It's an XML document with unlimited configuration elements possible.

> And in this case what about the signature

???

> what is the point of having it in the first place?

I think you misread. There are two fragment flags, begin and end.

> was wrong with using XML-sig anyway?).

Why would an email server alter an "attachment"? Don't send them in the body.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> 
> iEYEARECAAYFAkz9X8sACgkQ9RoMZyVa61db8wCfY920Y+l8ho7H6crmx+Bwbczi
> VOMAn2jqKBSRaf96sNh1P0L34debXb96
> =/8Wr
> -----END PGP SIGNATURE-----
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 06 Dec 2010 15:21:20 -0800

On 12/06/2010 02:34 PM, jc wrote:
> 
> 
> On Dec 6, 2010, at 5:12 PM, Marc Petit-Huguenin <[email-masked]
> <mailto:[email-masked]>> wrote:
> 

[...]

>> No, it is used for AOR storage among other things.

My question was about Signature in SecurityBlock, not in StoredData, so let me
rephrase it:

What is the certificate_hash value in SecurityBlock used for?

[...]

>> I think you misread. There are two fragment flags, begin and end.

Here's the quotes:

Section 5.3.2: "If the high bit (0x80000000) is set, it indicates that the
message is fragmented."
Section 5.7: "If the message is not fragmented, then both the first and last
fragment bits are set to 1..."

[...]

>> Why would an email server alter an "attachment"? Don't send them in the

Some email servers do alter attachments, it's a fact (and the reason why pcap
files have to be gzipped before been sent by email), but in fact I just wanted
to express that basing a signature on an XML fragment without canonicalization
was perhaps not a good idea.

[...]

- -- 
Marc Petit-Huguenin

---

From: jc <[email-masked]>
Date: Mon, 6 Dec 2010 18:30:27 -0500

Sent from my iPhone

>> what is the point of having it in the first place?

Because it IS the first and last fragment.

> iEYEARECAAYFAkz9b+4ACgkQ9RoMZyVa61emFQCfaHnoKXXtbBmgVcEBDmUYFytD
> CFwAoIKbTDa7BjW1twZRTVDt+m3OEGYJ
> =Kz5R

---

From: jc <[email-masked]>
Date: Mon, 6 Dec 2010 18:31:52 -0500

Sent from my iPhone

On Dec 6, 2010, at 6:21 PM, Marc Petit-Huguenin <[email-masked]> wrote:

> Some email servers do alter attachments, it's a fact

That isn't in the SMTP standard so how is that our problem?

> (and the reason why pcap

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 06 Dec 2010 15:45:57 -0800

>>>> More questions, comments and nits:

[..]

>> Because it IS the first and last fragment.

The question is not about the last fragment bit, but about the first bit, which
is defined as "fragmented" in the first quote and as "first fragment" in the
second quote below.  If the first definition is correct, then it is redundant,
as I explained above.  If the second definition is correct, then the first
definition must be fixed.

> Section 5.3.2: "If the high bit (0x80000000) is set, it indicates that the

I quoted it wrong:

"If the high bit (0x80000000) is set, it indicates that the message is a fragment."

Not "the first fragment"

- -- 
Marc Petit-Huguenin