Subject: Re: [Hipsec] DNS draft, new pre-version

From: Julien Laganier <[email-masked]>
Date: Fri, 17 Feb 2006 09:17:43 +0100

On Friday 17 February 2006 01:11, you wrote:
> I have been implementing the DNS draft and have a few comments.
> Overall I think the draft is in good shape.

Hi Jeff, thanks for your review, this is certainly useful.

> The "PK length" field is 8 bits and thus limits (wire-encoded) key
> sizes to < 256 bytes. - With RSA encoding, that means you can't use
> a key size of 2048 bits. There is a note in section 5.5 about
> relaxing the 4096-bit size limit, but that doesn't make sense with
> only 8 bits for "PK length". - DSA eats up quite a bit more space,
> and a 512 bit DSA key (213 bytes) approaches the max. A 1024-bit
> DSA key occupies 405 bytes, so is not possible (et vaan osaa!)
>
> FWIW, in most interops we use 1024-bit RSA keys (132 bytes) which
> fit just fine in the current DNS specification.

My mistake. I'll make the PK length 2 bytes long, that should be 
sufficient.

> Also, as we await IANA allocation of the RR type, any guidance on a
> RR type for experimentation? (e.g., 49 is the next available after
> DNSKEY)

I think 55 might be better, so that in case another RFC defining new 
RR types is published before hip-dns, we don't collide.

> Minor edits:
> section 4.1
> s/may also contains/may also contain/
> section 4.2
> s/attempt to communicate/attempts to communicate/
> section 5
> s/optionnally/optionally/

Done.

> section 7
> - the examples need to be updated with valid HITs (0x40...) and the
> base64 HIs don't seem to be valid

I'll do it.

Thanks.

--julien

_______________________________________________
Hipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hipsec

---

From: "Ahrenholz, Jeffrey M" <[email-masked]>
Date: Thu, 16 Feb 2006 16:11:02 -0800

I have been implementing the DNS draft and have a few comments. Overall I think the draft is in good shape.

The "PK length" field is 8 bits and thus limits (wire-encoded) key sizes to < 256 bytes.
- With RSA encoding, that means you can't use a key size of 2048 bits.
  There is a note in section 5.5 about relaxing the 4096-bit size limit, but that doesn't make sense with only 8 bits for "PK length".
- DSA eats up quite a bit more space, and a 512 bit DSA key (213 bytes) approaches the max.
  A 1024-bit DSA key occupies 405 bytes, so is not possible (et vaan osaa!)

FWIW, in most interops we use 1024-bit RSA keys (132 bytes) which fit just fine in the current DNS specification.

Also, as we await IANA allocation of the RR type, any guidance on a RR type for experimentation? (e.g., 49 is the next available after DNSKEY)

Minor edits:
section 4.1

section 7
- the examples need to be updated with valid HITs (0x40...) and the base64 HIs don't seem to be valid

-Jeff

---

From: Michael Richardson <[email-masked]>
Date: Fri, 17 Feb 2006 11:28:16 -0500

>>>>> "Ahrenholz," == Ahrenholz, Jeffrey M <[email-masked]> writes:
    Ahrenholz> I have been implementing the DNS draft and have a few
    Ahrenholz> comments. Overall I think the draft is in good shape.

    Ahrenholz> The "PK length" field is 8 bits and thus limits
    Ahrenholz> (wire-encoded) key sizes to < 256 bytes.  - With RSA
    Ahrenholz> encoding, that means you can't use a key size of 2048
    Ahrenholz> bits.  There is a note in section 5.5 about relaxing the

  That would be unacceptable to me.
 
  Why not eliminate the length, move the RSA field to the end of the
packet, and instead, encode the number of rendezvous servers that you
will have and/or the number of bytes that it the portion will take.

  btw, if there is any value in having the rfc4025 .xml file, let me
know. It's online still.

- -- 
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Julien Laganier <[email-masked]>
Date: Mon, 20 Feb 2006 13:51:33 +0100

Michael and others,

On Friday 17 February 2006 17:28, Michael Richardson wrote:
>
> >>>>> <[email-masked]> writes:
>
>     Ahrenholz> encoding, that means you can't use a key size of
> 2048 Ahrenholz> bits.  There is a note in section 5.5 about
> relaxing the
>
>   Why not eliminate the length, move the RSA field to the end of
> the packet, and instead, encode the number of rendezvous servers
> that you will have and/or the number of bytes that it the portion
> will take.

Right now I increased the public key length field to 16 bits, so the 
(unintentional) 256 bytes size limit is removed:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  HIT length   | PK algorithm  |          PK length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                           HIT                                 ~
   |                                                               |
   +                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     |                                         |
   +-+-+-+-+-+-+-+-+-+-+-+                                         +
   |                           Public Key                          |
   ~                                                               ~
   |                                                               |
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                                                               |
   ~                       Rendezvous Servers                      ~
   |                                                               |
   +             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             |
   +-+-+-+-+-+-+-+

If we move the public key field at the end like you are proposing, the 
advantage would be that because the rendezvous servers' FQDN are 
self-describing (implicit length), we could remove PK length field 
while not adding rendezvous server field length:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  HIT length   | PK algorithm  |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                                                               |
   ~                                                               ~
   |                         HIT                                   |
   +                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                   |                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                           +
   |                                                               |
   ~                       Rendezvous Servers                      ~
   |                                                               |
   +                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     |                                         |
   +-+-+-+-+-+-+-+-+-+-+-+                                         +
   |                                                               |
   ~                                                               ~
   |                          Public Key                           |
   +                                                               +
   |                                                               |
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |                               
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               

The later looks nicer, but I don't have a strong opinion on the 
question. Hence I'll be happy to implement whatever the WG think is 
better.

--julien