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

From: Marc Petit-Huguenin <[email-masked]>
Date: Sat, 05 Feb 2011 08:32:31 -0800

On 01/18/2011 10:22 AM, Marc Petit-Huguenin wrote:
> Inline.
> 
> On 01/18/2011 05:21 AM, Eric Rescorla wrote:
> 
>> On Dec 6, 2010, at 2:12 PM, Marc Petit-Huguenin wrote:
>>> 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?
>>>
> 
>> I think it's a mistake to assume we'll never want messages to be
>> self-contained/unframed.
>> Is there a real advantage to this  breaking change?
> 
> A little easier to parse the message, but you are right that a message can be
> unframed.

The signature can be generated without parsing the message contents, as stated
in section 5.3, but it cannot be verified without parsing them, as the length of
"message_body" and "extensions" are needed to find the beginning of
SignatureBlock.  There is a similar issue in StoredData, where length is equally
useless, as StoredDataValue had to be parsed to verify the signature (and this
cannot be done without knowing the DataModel used).  That's not really an issue
because anyway MessageContents and StoredDataValue had to be parsed (with the
knowledge of the DataModel) after the signature is verified, but that prevent a
clear separation of layers in software.

BTW I was not able to find text explaining what to do if the message level
signature fails.  Should the message be dropped (and so be retransmitted) or
should an error be sent back?

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

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 8 Feb 2011 16:48:37 -0700

> 
>> 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.

Changed 

>> 
>> Note that there is other places in the RELAX NG document where the type can be
>> improved (initial-ttl, etc...)
> 
> I'll leave this to Cullen.

Glad to make any changes but I'm not sure there is much to be gained from trying to fully enforce all the rules in the text in the RelaxNG. 

>> A.26. Section 10.1.1. 'kind-names |= "sip-registration"'
>> 
>> the sip-registration kind is not defined in this document.  OTOH,

Fixed - good catch 

>> certificate-by-node and certificate-by-name are defined, but not listed here.
> 
> A cullen problem.
> 

added

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 8 Feb 2011 16:51:15 -0700

> should an error be sent back?

The code I have seems like it just drops it but I don't really care which way we decide to go on this.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 8 Feb 2011 16:31:22 -0800

My general feeling is not to be too prescriptive on it. Let's define a code and then say that you can go
either way. Basically, there are two reasons why signatures can be broken: damage in transit or 
a bogus signature at the sender. It's hard to tell which is more likely...

-Ekr