Subject: [Hipsec] 5201-bis -- HOST_ID format for RSA/DSA Identities

From: Robert Moskowitz <[email-masked]>
Date: Fri, 19 Oct 2012 08:05:53 -0400

There has been a side converstation going on about the use of DNSKEY RR 
format for RSA/DSA HOST_IDs per sec 5.2.9.

I am bringing the discussion to a larger audience so we can get a 
'decide' and put this one to bed.

Historically speaking, this was a good quick choice made at a lobby 
meeting way back when (Andrew, I believe you were part of the meeting, 
do you remember what year it was?  :) ).  It had everything needed to 
define the Host ID and had existing code not tied into 'certficate 
stuff'.  While we were developing HIP, we decided to ignore RFC 4043, as 
we are NOT using DNSKEY RR to store HIP information, only how to format 
it.  We have our own RR.

Now it is choice time.  Do we stay the course as currently shown in 
5.2.9 or do we use:

RFC3279 as mentioned below

or do we follow with those that are following us with

draft-ietf-tls-oob-pubkey-04.txt

Do either of these provide all that we need for RSA/DSA Host ID 
representation and are they more compact?

Note that for ECDSA (and ECDH in HIP DEX) we use a very simple format 
that carries the (x,y) coordinate for the key (compact notation WOULD be 
nicer for DEX, but there seems to be security concerns around it).

-------- Original Message --------  That started to discussion from Miika...

Hi René,

sorry for the belated response. I recall that we discussed about the use
of SRV records but I do not have a recollection of the DNSKEY issue you
mentioned.

On 09/23/2012 07:16 PM, René Hummen wrote:
> Hi Miika,
>
> I found one more issue that I did not yet report to the mailing list. As
> I am not completely sure about the consequences of this issue and the
> necessary changes, I would like some feedback from you first. Is it
> still worth mentioning this at such a late state of the standardization
> process?
>
> Thanks for having a look at the following few line!
>
> René
>
> --------------------- TEXT FOR WG ----------------------
>
>
> While going through draft-ietf-hip-rfc5201-bis-09, I stumbled across an
> old issue that came up in a discussion with Stefan Götz at our
> chair. The issue concerns the serialization format for HI public keys.
>
>
>         5.2.9
>         <http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-09#section-5.2.9>.
>         HOST_ID
>
> "The Host Identity is derived from the DNSKEY format for RSA and DSA. For these, the Public Key field of the RDATA part fromRFC 4034  <http://tools.ietf.org/html/rfc4034>  [RFC4034  <http://tools.ietf.org/html/rfc4034>] is used."
>
>
> This implies that public keys in HIP are stored in the "DNSKEY RDATA
> Wire Format" as defined in RFC 4043 Section 2.1 [1].
>
> However, RFC 4043 Section 2 states:
> "The DNSKEY RR is not intended as a record for storing arbitrary public
> keys and MUST NOT be used to store certificates or public keys that do
> not directly relate to the DNS infrastructure."
>
> While HIs can be stored in DNS, they do not have a direct relation to
> the DNS infrastructure. Still there seems to be no harm in using this
> serialization format in practice.  The question is, do we want to move
> to a different serialization format? A good candidate seems to be
> ASN.1/DER encoding as detailed in RFC 3279 with a compact binary
> representation for data in a cryptographic context.
>
> BR,
> René
>
>
> [1] http://tools.ietf.org/html//rfc4034#section-2.1
>

---

From: Andrew McGregor <[email-masked]>
Date: Sat, 20 Oct 2012 10:21:48 +1300

As best I can recall, it was either Pittsburgh in 2000 or Minneapolis in 2001.

If you follow the reference chains, you find that draft-ietf-tls-oob-pubkey-04.txt ends up pointing to RFC 3279 anyway, so really it comes down to, do we use DNS formatting or x509 formatting?

Since parsing and formatting code for both is pretty much ubiquitous and the packet space is dominated by the key itself, I see no real reason to change.  That DNSKEY is supposed only to be used for DNSSEC is a distraction, we have our own RR and reusing the wire format is merely a convenience.

Andrew

On 20/10/2012, at 1:05 AM, Robert Moskowitz <[email-masked]> wrote:

> There has been a side converstation going on about the use of DNSKEY RR format for RSA/DSA HOST_IDs per sec 5.2.9.
> 
> I am bringing the discussion to a larger audience so we can get a 'decide' and put this one to bed.
> 
> Historically speaking, this was a good quick choice made at a lobby meeting way back when (Andrew, I believe you were part of the meeting, do you remember what year it was?  :) ).  It had everything needed to define the Host ID and had existing code not tied into 'certficate stuff'.  While we were developing HIP, we decided to ignore RFC 4043, as we are NOT using DNSKEY RR to store HIP information, only how to format it.  We have our own RR.
> 
> Now it is choice time.  Do we stay the course as currently shown in 5.2.9 or do we use:
> 
> Do either of these provide all that we need for RSA/DSA Host ID representation and are they more compact?
> 
> Note that for ECDSA (and ECDH in HIP DEX) we use a very simple format that carries the (x,y) coordinate for the key (compact notation WOULD be nicer for DEX, but there seems to be security concerns around it).
> 
> 
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Fri, 19 Oct 2012 15:28:04 -0700

> 
> Since parsing and formatting code for both is pretty much ubiquitous
> and the packet space is dominated by the key itself, I see no real
> reason to change.  That DNSKEY is supposed only to be used for DNSSEC
> is a distraction, we have our own RR and reusing the wire format is
> merely a convenience.

+1

- Tom

---

From: Miika Komu <[email-masked]>
Date: Sat, 20 Oct 2012 18:04:44 +0300

Hi,

>> is a distraction, we have our own RR and reusing the wire format is

fine by me as well.

---

From: Tobias Heer <[email-masked]>
Date: Sat, 20 Oct 2012 23:21:08 +0200

Am 20.10.2012 17:04 schrieb "Miika Komu" <mkomu
<[email-masked]>@<[email-masked]>
>>> is a distraction, we have our own RR and reusing the wire format is

I agree. +1.

Tobias
> Hipsec <[email-masked]>@ <[email-masked]>ietf.org <[email-masked]>
> https <https://www.ietf.org/mailman/listinfo/hipsec>://<https://www.ietf.org/mailman/listinfo/hipsec>
www.ietf.org <https://www.ietf.org/mailman/listinfo/hipsec>/<https://www.ietf.org/mailman/listinfo/hipsec>
mailman <https://www.ietf.org/mailman/listinfo/hipsec>/<https://www.ietf.org/mailman/listinfo/hipsec>
listinfo <https://www.ietf.org/mailman/listinfo/hipsec>/<https://www.ietf.org/mailman/listinfo/hipsec>
hipsec <https://www.ietf.org/mailman/listinfo/hipsec>

I

---

From: Robert Moskowitz <[email-masked]>
Date: Sat, 20 Oct 2012 20:50:29 -0400

On 10/20/2012 05:21 PM, Tobias Heer wrote:
> <mailto:[email-masked]>@ <mailto:[email-masked]>cs.hut.fi 
> <mailto:[email-masked]>>:
> >
> > Hi,
> >
> >

All we need is for the Ericsson people to chime in and we have pretty 
much all the original developers.

As Andrew, I remember the meeting where we chose DNSKEY format.  I 
remember the lobby, but could not place the meeting date, but Andrew was 
busy coding already so he is a reliable source of when we did this.

There was a attitude of avoiding x509ish things, plus DNSKEY format was 
more readable than ASN.1.  Don't know if that what others were thinking, 
but I sure was!

I would rather leave it as is.  No real justification to switch, and it 
keeps ASN.1 out of the basic parameters.  Only if you are supporting 
real certs will you be working with ASN.1.

---

From: Miika Komu <[email-masked]>
Date: Sun, 21 Oct 2012 15:37:43 +0300

Hi,

> much all the original developers.

sure, but I think we can just proceed because the decision was actually 
not to change anything. The discussion was more about the justification 
for the original decision. Let's keep rolling, no need to create 
unnecessary dependencies along the road.

---

From: René Hummen <[email-masked]>
Date: Sun, 21 Oct 2012 15:19:13 +0200

On 20.10.2012, at 23:21, Tobias Heer <[email-masked]> wrote:
> Am 20.10.2012 17:04 schrieb "Miika Komu" <[email-masked]>:
> >
> > Hi,
> >
> >

I originally brought up the issue because I was not sure if 5201-bis was conflicting with the statement in RFC 4043. Now that things are clarified, it's fine by me.

--
Dipl.-Inform. Rene Hummen, Ph.D. Student
Chair of Communication and Distributed Systems
RWTH Aachen University, Germany
tel: +49 241 80 21429
web: http://www.comsys.rwth-aachen.de/team/rene-hummen/