Subject: [P2PSIP] 10.3.1 Self-Generated Credentials

From: jc <[email-masked]>
Date: Wed, 16 Sep 2009 22:30:39 -0700

Hi,
States "MAY contain any user name of the user choice",  this is  
subjectAltName?

Julian

---

From: jc <[email-masked]>
Date: Thu, 17 Sep 2009 02:08:28 -0700

I looked at some other areas and the problem is the draft doesn't  
clearly state fields that X509 certificates MUST contain or  
misrepresents them case-wise.

For instance:

7.  Certificate Store Usage
user name
Node-ID

12.5.1. Authorization
User name
Node-ID
Serial

There are several other references as well. Since this is a string  
variable inside of an X509 certificate the names need to be case  
normalized.

Julian

> States "MAY contain any user name of the user choice",  this is  

User name or user name?

>
> Julian
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 17 Sep 2009 06:50:59 -0700

These aren't fields in the certificate. The relevant field is either DN or
subjectAltName (I don't have the draft in front of me to remember what
we decided).

-Ekr

On Thu, Sep 17, 2009 at 2:08 AM, jc <[email-masked]> wrote:
> I looked at some other areas and the problem is the draft doesn't clearly
> state fields that X509 certificates MUST contain or misrepresents them
> case-wise.
>
> For instance:
>
> There are several other references as well. Since this is a string variable
> inside of an X509 certificate the names need to be case normalized.
> Julian
>

---

From: jc <[email-masked]>
Date: Thu, 17 Sep 2009 14:08:07 -0700

If it is simply subjectAltName then I guess the question is how is  
data stored here? It may hold multiple Node-ID's, a single user name,  
and other elements so it MUST be a dictionary or key/value pairs or  
some other storage.

Julian

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 17 Sep 2009 14:09:29 -0700

Certs can have multiple SAN fields

Ek

On Sep 17, 2009, at 2:08 PM, jc <[email-masked]> wrote:

> data stored here? It may hold multiple Node-ID's, a single user  
> name, and other elements so it MUST be a dictionary or key/value  
> pairs or some other storage.
>
> Julian
>

---

From: jc <[email-masked]>
Date: Thu, 17 Sep 2009 14:21:55 -0700

Right thanks, however these SAN fields aren't in the draft and MUST be  
for implementation.

Certificate example:

NID_subject_alt_name "node_id:0123456789"
NID_subject_alt_name "node_id:0123456987"
NID_subject_alt_name "user_name:[email-masked]"

Julian

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 17 Sep 2009 14:43:20 -0700

It is in the draft in s 10.3. nodeids are expressed as Uris. User  
names are rfc822names

Ekr

On Sep 17, 2009, at 2:21 PM, jc <[email-masked]> wrote:

> Right thanks, however these SAN fields aren't in the draft and MUST  
> be for implementation.
>
> Certificate example:
>

---

From: Michael Chen <[email-masked]>
Date: Thu, 24 Sep 2009 07:31:09 -0700

Julian,

In our implementation, we search for rfc822Name format in all X509 
fields in the following order:

  CN
  emailAddress
  <future fields per this draft>

Placing the "name@domain" in the CN of the certificate yields smaller 
X509 structure that uses no V3 extensions, and it defines both the 
overlay name ("domain" part) and the AoR.  It's perfect for a small 
self-sign certificate.

--Michael

---

From: ekr <[email-masked]>
Date: Thu, 24 Sep 2009 08:07:01 -0700

On Thu, Sep 24, 2009 at 7:31 AM, Michael Chen <[email-masked]> wrote:
> Julian,
>
> In our implementation, we search for rfc822Name format in all X509 fields in
> the following order:
>
>  CN

This seems like it is not compliant with the current draft.

>  emailAddress

This is definitely not compliant and I don't see why it would be OK under
any circumstances.

-Ekr

---

From: "David A. Bryan" <[email-masked]>
Date: Thu, 24 Sep 2009 12:49:34 -0400

Michael,

I haven't had a chance to go back and reread the section in RELOAD or
fully think about this particular issue too much yet (so I certainly
have no opinions about the "right" way), but since this decision is
coming from an actual implementation, can you share a bit why you made
the decision you did? Was it motivated by a problem with the proposal
in the draft? An optimization to improve the current draft after
trying the other way? Or was it just that you did it that way before
the draft, etc.?

Obviously since we are still working on getting things right with the
draft, nothing is set in stone quite yet, and it's always good to hear
from implementors about why they made the decisions they did when they
differ from the draft, so that we make sure we really are getting the
best ideas. (especially here, where it seems, unfortunately, that
there are only a few folks trying to implement RELOAD, or at least
willing to talk about their implementation experience)

Also, anything else you have done differently/found awkward/etc. in
the current draft? It's not really so much a question of "compliance"
with the current draft right now -- now is the time to discuss
differences and find and address as many shortcomings in the current
draft proposal as possible, so we get as many ideas as possible and
the best protocol, then move it forward...

My 2 cents

David (as individual)

---

From: jc <[email-masked]>
Date: Thu, 24 Sep 2009 12:36:13 -0700

On Sep 24, 2009, at 7:31 AM, Michael Chen wrote:

> Placing the "name@domain" in the CN of the certificate yields  
> smaller X509 structure that uses no V3 extensions, and it defines  
> both the overlay name ("domain" part) and the AoR.  It's perfect for  
> a small self-sign certificate.
>

The "emailAddress" field is non-compliant with the draft.  Why are you  
referring to X509 v3 extensions? Would you care to share the whats and  
whys of your usage?

Thanks,
Julian

---

From: "neil.young" <[email-masked]>
Date: Thu, 24 Sep 2009 23:01:59 +0200

Probably the discussion you raised is worth a separate thread. I'm 
currently in the situation to evaluate whether RELOAD is the way to go 
or not (for our project). The scattered postings in this group may lead 
to the conclusion, that RELOAD has no relevance at all. I would be glad 
to hear, that this isn't the case.

Regards

---

From: Michael Chen <[email-masked]>
Date: Thu, 24 Sep 2009 21:35:35 -0700

David,

It all started way way back in late 2007 with this section of the draft:

http://www.p2psip.org/drafts/draft-bryan-p2psip-reload-02.html#sec-cert-security

  The contents of the certificate include:

    * A public key provided by the user.
    * Zero, one, or more user names that the DHT is allowing this user
      to use. For example, "[email-masked]". Typically a certificate
      will have one name. In the SIP usage, this name corresponds to the
      AOR.

Nothing explicit about which part of the X509 certificate should hold 
the AOR, just "name".

As a convenient, we used JDK program keytool to generate self-signed 
certs instead of the more confusing openssl. It just so happens that JDK 
keytool encodes only DN (common name, etc), no X509 v3 extensions fields 
like subjectAltName and emailAddress (it is still this way with JDK 6). 
We simply put the AOR in the "least inappropriate" field, Common Name.  
Then we moved on and never thought about it much.

I believe it will remove a great deal of confusion if you guys create a 
sample self-signed cert and put the output of the following OpenSSL 
command in the appendix:

    openssl x509 -text -in my_sip_cert.pem

I also want to point out that even with the most simple encoding (JDK 
keytool), a 1024 bit RSA public key certificate takes up 619 bytes. A 
production strength 2048 bit RSA cert is 880 bytes. If a peer can only 
be reached via UDP, the overhead of DTLS + Reload Signature on message 
leaves very little room for the relevant data fragment (e.g. 1500 packet 
size), which means UDP transport may be very inefficient.  Transport 
overhead should be a separate discussion thread.

Thanks

--Michael

---

From: jc <[email-masked]>
Date: Thu, 24 Sep 2009 23:04:01 -0700

On Sep 24, 2009, at 9:35 PM, Michael Chen wrote:

> I also want to point out that even with the most simple encoding  
> (JDK keytool), a 1024 bit RSA public key certificate takes up 619  
> bytes. A production strength 2048 bit RSA cert is 880 bytes. If a  
> peer can only be reached via UDP, the overhead of DTLS + Reload  
> Signature on message leaves very little room for the relevant data  
> fragment (e.g. 1500 packet size), which means UDP transport may be  
> very inefficient.  Transport overhead should be a separate  
> discussion thread.

In my RELOAD implementation a 2048 bit RSA public key is  691 bytes  
long, see output below. Do you have statistics that show the current  
fragmentation algorithm to be sub-optimal?
Julian

Running 1 test case...
......................+++
........................+++
debug: RSA* junglecat::rsa::generate_key_pair(): Succeeded generating  
RSA key.
..............................+++
..............+++
debug: RSA* junglecat::rsa::generate_key_pair(): Succeeded generating  
RSA key.
debug: X509_NAME* junglecat::x509::allocate_common_name(const char*):  
Allocated
debug: X509_NAME* junglecat::x509::allocate_common_name(const char*):  
Allocated
debug: X509* junglecat::x509::generate_certificate(RSA*, RSA*, const  
char*, const char*, unsigned int, const EVP_MD*): Success
Certificate:
     Data:
         Version: 3 (0x2)
         Serial Number: 1253857645 (0x4abc596d)
         Signature Algorithm: sha1WithRSAEncryption
         Issuer: CN=common_name_issuer
         Validity
             Not Before: Sep 25 05:47:25 2009 GMT
             Not After : Sep 25 06:47:25 2009 GMT
         Subject: CN=common_name
         Subject Public Key Info:
             Public Key Algorithm: rsaEncryption
             RSA Public Key: (2048 bit)
                 Modulus (2048 bit):
                     00:ab:54:2c:7b:9a:d8:3c:4b:b8:08:46:04:ee:02:
                     51:8a:94:4c:62:58:d0:ed:50:f8:2f:5a:43:b2:b0:
                     aa:1a:7c:46:32:ad:93:b3:80:1b:dd:62:d7:72:14:
                     aa:0e:43:7c:6b:00:a6:56:f3:62:ed:b5:d4:ff:c4:
                     da:72:6c:ff:8c:75:a2:8a:0c:e9:fb:9d:f0:f3:6f:
                     d8:65:1e:85:7b:7c:91:cc:b3:8a:eb:f7:ff:1d:c7:
                     e0:9f:e5:d3:e0:d4:23:3a:e9:0a:9c:be:f7:fc:44:
                     59:3f:03:19:65:8c:fd:07:bd:40:c0:40:3c:04:8e:
                     46:5c:13:1a:85:68:d8:48:01:f9:03:75:98:e9:1f:
                     a7:bb:d7:75:c7:dc:6b:3c:eb:6e:6c:ee:21:73:94:
                     66:dd:d6:4a:13:79:7b:19:91:75:f8:14:0e:ba:dd:
                     01:79:83:0e:3f:e1:9a:10:ea:98:cc:ae:d5:41:d7:
                     2d:33:0e:ab:6c:be:49:d3:cd:dd:fe:f4:5e:0c:ef:
                     b8:cb:ae:bf:80:e4:cf:9e:66:86:42:2a:1c:3a:ca:
                     d0:d5:ab:ad:34:ba:eb:6e:2d:33:86:4e:29:e8:1b:
                     cb:ee:f4:d5:8f:2c:d1:f6:10:a6:84:4b:4f:05:2d:
                     17:31:09:03:bd:9e:63:32:0f:14:ae:a6:0c:74:aa:
                     0a:d3
                 Exponent: 65537 (0x10001)
     Signature Algorithm: sha1WithRSAEncryption
         52:2a:cd:4d:f3:cc:c1:94:5e:5e:09:63:34:f6:fb:9b:c0:52:
         dc:98:90:30:88:44:bd:f6:73:0a:e2:ed:6c:f1:bc:26:f0:d9:
         72:c0:a7:d1:79:85:8d:f1:eb:4c:cc:d1:b0:73:fa:8f:de:e1:
         81:9d:32:fa:c6:c3:eb:37:5e:7f:30:c6:7e:a2:34:e0:d1:9d:
         af:a2:e7:00:59:68:eb:7c:f6:c1:6d:18:0e:f5:14:5e:cc:c9:
         f2:07:f1:60:a3:b4:a3:28:89:23:93:ac:14:d4:1e:69:f5:c7:
         b8:90:68:b7:f2:bc:70:6c:2b:7e:01:48:34:77:ae:67:b2:ff:
         0f:b7:15:c6:42:4c:9f:c6:dd:02:ed:06:9b:04:60:4a:74:52:
         ee:03:29:0e:e3:75:62:07:92:a3:48:f6:a4:f5:bb:8c:09:b0:
         cf:71:12:24:63:33:0f:9f:97:d4:ab:01:da:d7:d8:7f:c8:17:
         94:0e:70:03:7a:f0:5e:14:8b:ec:c8:11:d9:b4:b4:74:2c:4e:
         0c:56:35:c7:0f:b0:9e:6a:df:b2:63:68:3e:05:53:05:86:7c:
         45:82:a4:94:93:12:8e:b4:a2:0d:5f:29:d8:7d:52:d3:ab:8f:
         d4:cf:6f:26:b7:36:f6:5f:a4:c7:64:da:a2:ec:da:74:3b:e5:
         8d:2a:7b:21

X509 structure size: 92
RSA structure size: 88
len:691

*** No errors detected

---

From: Michael Chen <[email-masked]>
Date: Wed, 30 Sep 2009 10:50:28 -0700

Julian,

I have no scientific data, just a personal concern. Consider a Reload 
STORE request with your 691 byte cert, the total fat (non-payload) on 
the wire for a UDP/DTLS transport is:

  DTLS header (13 bytes)
  Reload header
    Forward header (38 bytes)
    Destination list (18 bytes, single hop)
  Reload Message
    STORE (SIP_REGISTRATION)
      AOR
      RSA Signature (256 bytes)
  Reload Security Block
    Certificates (691 bytes)
    Signer ID (20+ bytes)
    RSA Signature (256 bytes)
  DTSL MAC and padding (20+ bytes)

These are rough numbers, and it total 1292 bytes excluding the AOR.  It 
is very close to the 1500 byte network packet size (MTU).

--Michael

jc wrote:
>> production strength 2048 bit RSA cert is 880 bytes. If a peer can 
>> only be reached via UDP, the overhead of DTLS + Reload Signature on 
>> message leaves very little room for the relevant data fragment (e.g. 
>> 1500 packet size), which means UDP transport may be very inefficient. 
>>  Transport overhead should be a separate discussion thread.
>
> *
> *
> *Running 1 test case...*
> *......................+++*
> *........................+++*
> *debug: RSA* junglecat::rsa::generate_key_pair(): Succeeded generating 
> RSA key.*
> *..............................+++*
> *..............+++*
> *debug: RSA* junglecat::rsa::generate_key_pair(): Succeeded generating 
> RSA key.*
> *debug: X509_NAME* junglecat::x509::allocate_common_name(const char*): 
> Allocated*
> *debug: X509_NAME* junglecat::x509::allocate_common_name(const char*): 
> Allocated*
> *debug: X509* junglecat::x509::generate_certificate(RSA*, RSA*, const 
> char*, const char*, unsigned int, const EVP_MD*): Success*
> *Certificate:*
> *    Data:*
> *        Version: 3 (0x2)*
> *        Serial Number: 1253857645 (0x4abc596d)*
> *        Signature Algorithm: sha1WithRSAEncryption*
> *        Issuer: CN=common_name_issuer*
> *        Validity*
> *            Not Before: Sep 25 05:47:25 2009 GMT*
> *            Not After : Sep 25 06:47:25 2009 GMT*
> *        Subject: CN=common_name*
> *        Subject Public Key Info:*
> *            Public Key Algorithm: rsaEncryption*
> *            RSA Public Key: (2048 bit)*
> *                Modulus (2048 bit):*
> *                    00:ab:54:2c:7b:9a:d8:3c:4b:b8:08:46:04:ee:02:*
> *                    51:8a:94:4c:62:58:d0:ed:50:f8:2f:5a:43:b2:b0:*
> *                    aa:1a:7c:46:32:ad:93:b3:80:1b:dd:62:d7:72:14:*
> *                    aa:0e:43:7c:6b:00:a6:56:f3:62:ed:b5:d4:ff:c4:*
> *                    da:72:6c:ff:8c:75:a2:8a:0c:e9:fb:9d:f0:f3:6f:*
> *                    d8:65:1e:85:7b:7c:91:cc:b3:8a:eb:f7:ff:1d:c7:*
> *                    e0:9f:e5:d3:e0:d4:23:3a:e9:0a:9c:be:f7:fc:44:*
> *                    59:3f:03:19:65:8c:fd:07:bd:40:c0:40:3c:04:8e:*
> *                    46:5c:13:1a:85:68:d8:48:01:f9:03:75:98:e9:1f:*
> *                    a7:bb:d7:75:c7:dc:6b:3c:eb:6e:6c:ee:21:73:94:*
> *                    66:dd:d6:4a:13:79:7b:19:91:75:f8:14:0e:ba:dd:*
> *                    01:79:83:0e:3f:e1:9a:10:ea:98:cc:ae:d5:41:d7:*
> *                    2d:33:0e:ab:6c:be:49:d3:cd:dd:fe:f4:5e:0c:ef:*
> *                    b8:cb:ae:bf:80:e4:cf:9e:66:86:42:2a:1c:3a:ca:*
> *                    d0:d5:ab:ad:34:ba:eb:6e:2d:33:86:4e:29:e8:1b:*
> *                    cb:ee:f4:d5:8f:2c:d1:f6:10:a6:84:4b:4f:05:2d:*
> *                    17:31:09:03:bd:9e:63:32:0f:14:ae:a6:0c:74:aa:*
> *                    0a:d3*
> *                Exponent: 65537 (0x10001)*
> *    Signature Algorithm: sha1WithRSAEncryption*
> *        52:2a:cd:4d:f3:cc:c1:94:5e:5e:09:63:34:f6:fb:9b:c0:52:*
> *        dc:98:90:30:88:44:bd:f6:73:0a:e2:ed:6c:f1:bc:26:f0:d9:*
> *        72:c0:a7:d1:79:85:8d:f1:eb:4c:cc:d1:b0:73:fa:8f:de:e1:*
> *        81:9d:32:fa:c6:c3:eb:37:5e:7f:30:c6:7e:a2:34:e0:d1:9d:*
> *        af:a2:e7:00:59:68:eb:7c:f6:c1:6d:18:0e:f5:14:5e:cc:c9:*
> *        f2:07:f1:60:a3:b4:a3:28:89:23:93:ac:14:d4:1e:69:f5:c7:*
> *        b8:90:68:b7:f2:bc:70:6c:2b:7e:01:48:34:77:ae:67:b2:ff:*
> *        0f:b7:15:c6:42:4c:9f:c6:dd:02:ed:06:9b:04:60:4a:74:52:*
> *        ee:03:29:0e:e3:75:62:07:92:a3:48:f6:a4:f5:bb:8c:09:b0:*
> *        cf:71:12:24:63:33:0f:9f:97:d4:ab:01:da:d7:d8:7f:c8:17:*
> *        94:0e:70:03:7a:f0:5e:14:8b:ec:c8:11:d9:b4:b4:74:2c:4e:*
> *        0c:56:35:c7:0f:b0:9e:6a:df:b2:63:68:3e:05:53:05:86:7c:*
> *        45:82:a4:94:93:12:8e:b4:a2:0d:5f:29:d8:7d:52:d3:ab:8f:*
> *        d4:cf:6f:26:b7:36:f6:5f:a4:c7:64:da:a2:ec:da:74:3b:e5:*
> *        8d:2a:7b:21*
>
> *X509 structure size: 92*
> *RSA structure size: 88*
> len:691
>
> **** No errors detected*
> *
> *

---

From: jc <[email-masked]>
Date: Wed, 30 Sep 2009 11:09:33 -0700

This is greater than the MTU of an xbox 360 but less than your averge  
router at 1492. Doesn't DTLS in OpenSSL already have the real path MTU  
after the handshake? If not I know it can do this for you. You can use  
that MTU and fragment your packets.

Julian

Sent from my iPhone

On Sep 30, 2009, at 10:50 AM, Michael Chen <[email-masked]>  
wrote:

> Julian,
>
> I have no scientific data, just a personal concern. Consider a  
> Reload STORE request with your 691 byte cert, the total fat (non- 
> payload) on the wire for a UDP/DTLS transport is:
>
> DTLS header (13 bytes)
> Reload header
> These are rough numbers, and it total 1292 bytes excluding the AOR.   
> It is very close to the 1500 byte network packet size (MTU).
>
> --Michael
>
> jc wrote:
>>
>> long, see output below. Do you have statistics that show the  
>> current fragmentation algorithm to be sub-optimal?
>> Julian
>>
>> *
>> *
>> *Running 1 test case...*
>> *debug: RSA* junglecat::rsa::generate_key_pair(): Succeeded  
>> generating RSA key.*
>> *debug: RSA* junglecat::rsa::generate_key_pair(): Succeeded  
>> generating RSA key.*
>> *debug: X509_NAME* junglecat::x509::allocate_common_name(const  
>> char*): Allocated*
>> *debug: X509_NAME* junglecat::x509::allocate_common_name(const  
>> char*): Allocated*
>> *debug: X509* junglecat::x509::generate_certificate(RSA*, RSA*,  
>> const char*, const char*, unsigned int, const EVP_MD*): Success*
>> *Certificate:*
>> *    Data:*
>> *        Version: 3 (0x2)*

---

From: Michael Chen <[email-masked]>
Date: Wed, 30 Sep 2009 19:25:15 -0700

Julian,

My point is that what's left for Reload payload is 1492-1292 = 200 
bytes. Many Reload messages will have to be fragmented.

--Michael

---

From: jc <[email-masked]>
Date: Wed, 30 Sep 2009 21:08:43 -0600

> bytes. Many Reload messages will have to be fragmented.

I don't see the problem because TLS over TCP will be doing the same.  
You will most likely be fragmenting 100% of all application level  
messages and some percentage of RELOAD messages. Also DTLS has a bit  
better performance than TLS over TCP.

>
> --Michael
>
> jc wrote:
>> This is greater than the MTU of an xbox 360 but less than your  
>> averge router at 1492. Doesn't DTLS in OpenSSL already have the  
>> real path MTU after the handshake? If not I know it can do this for  
>> you. You can use that MTU and fragment your packets.
>>
>> Julian
>>
>> Sent from my iPhone
>>
>> On Sep 30, 2009, at 10:50 AM, Michael Chen  
>> <[email-masked]> wrote:
>>
>>> Julian,
>>>
>>> These are rough numbers, and it total 1292 bytes excluding the  
>>> AOR.  It is very close to the 1500 byte network packet size (MTU).
>>>
>>> --Michael
>>>
>>> jc wrote:
>>>>
>>>>> (JDK keytool), a 1024 bit RSA public key certificate takes up  
>>>>> 619 bytes. A production strength 2048 bit RSA cert is 880 bytes.  
>>>>> If a peer can only be reached via UDP, the overhead of DTLS +  
>>>>> Reload Signature on message leaves very little room for the  
>>>>> relevant data fragment (e.g. 1500 packet size), which means UDP  
>>>>> transport may be very inefficient.  Transport overhead should be  
>>>>> a separate discussion thread.
>>>>
>>>> In my RELOAD implementation a 2048 bit RSA public key is  691  
>>>> bytes long, see output below. Do you have statistics that show  
>>>> the current fragmentation algorithm to be sub-optimal?
>>>> Julian
>>>>
>>>> *
>>>> *
>>>> *Running 1 test case...*