Subject: [Hipsec] New milestones

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 06 Oct 2005 08:58:32 +0300

Folks,

FYI: the new milestones are finally available at the official IETF site:
http://www.ietf.org/html.charters/hip-charter.html

Cheers,

Gonzalo

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

---

From: Julien Laganier <[email-masked]>
Date: Fri, 7 Oct 2005 10:59:06 +0200

On Thursday 06 October 2005 07:58, Gonzalo Camarillo wrote:
> Folks,
>
> FYI: the new milestones are finally available at the official IETF
> site: http://www.ietf.org/html.charters/hip-charter.html

Folks,

Considering these milestones:

Oct 05      WGLC the HIP registration extensions specification 
--------------------------------------------------------------

=> I believe the current document is ready for WGLC. 

Oct 05      WG LC on the basic HIP rendezvous mechanism specification 
---------------------------------------------------------------------

=> I believe the current document is ready, apart from the references 
in which I think we should remove RFC1498 'On the naming and binding 
of network destinations' and RFC3007 'Secure DNS Dynamic Update'. If 
nobody objects I will shortly resubmit a new version with these 
changes made, then we can proceed with WGLC.

Oct 05      WGLC the HIP DNS resource record(s) specification
-------------------------------------------------------------

=> I believe the current document is nearly ready apart from minor 
details. If nobody objects, I will shortly resubmit a new version 
making the following change so that we can issue WGLC:

o In the resolver queries examples of section 3 (Usage Scenarios), 
explain that implementation using IPs addrs in APIs will typically 
request A/AAAA RR first, while those using HIT in APIS will typically 
request HIPHI RR first.

o HIPHI and HIPRVS RRs should be defined for all classes (like
  IPSECKEY RR)

o The HIT algorithm is now defined by the KHI prefix. Hence we should
  remove the HIT algortithm field from the HIPHI RR. Then we need to 
  make the HIT field mandatory in HIPHI RR. Hence a verifier would
  always known the prefix of the KHI/HIT, and so the hash method. 

This change need to be made because if SHA1 became insecure for 
generating KHIs, then we have to allocate another prefix for stronger 
KHIs. And if the HIPHI RR encodes neither of the Context ID nor hash 
method, then we would also be forced to define another RR to store 
the HIPHI information.

o The HIPHI RR will have an explicit HIT length field; the current 
text seems to be confusing because it uses the <character string> 
encoding (which has a leading byte for the length of the string). I 
think it is better to use an explicit byte for length, followed by 
HIT. 

The HIPHI RR would then be changed from:

    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 algorithm |  PK algorithm |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+             HIT               |
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               /
   /                          Public Key                           /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|

To:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  PK algorithm |   HIT length  |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+             HIT               |
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               /
   /                          Public Key                           /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|

Thoughts, objections?

--julien

---

From: Lars Eggert <[email-masked]>
Date: Fri, 7 Oct 2005 11:09:16 +0200

> Oct 05      WGLC the HIP registration extensions specification

I agree.

> Oct 05      WG LC on the basic HIP rendezvous mechanism specification

Yup. These are not cited and probably left over from my original  
draft. (FYI, fenner's xml2rfc validator will find uncited references:  
http://rtg.ietf.org/~fenner/ietf/xml2rfc-valid/)

Lars
--
Lars Eggert                                     NEC Network Laboratories

---

From: Julien Laganier <[email-masked]>
Date: Fri, 7 Oct 2005 10:59:06 +0200

Folks,

    0                   1                   2                   3

To:

    0                   1                   2                   3

Thoughts, objections?

--julien

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 7 Oct 2005 13:10:44 +0200

> Oct 05      WGLC the HIP DNS resource record(s) specification

Sounds fine.

> o HIPHI and HIPRVS RRs should be defined for all classes (like

Yes.

> method, then we would also be forced to define another RR to store

Right.

> think it is better to use an explicit byte for length, followed by

Sounds good.  Will the HIT be in plain binary then, i.e.,
16 bytes for current HITs?

--Pekka

---

From: Julien Laganier <[email-masked]>
Date: Fri, 7 Oct 2005 13:55:56 +0200

On Friday 07 October 2005 13:10, Pekka Nikander wrote:
>
> > o The HIPHI RR will have an explicit HIT length field; the
> > current text seems to be confusing because it uses the <character
> > string> encoding (which has a leading byte for the length of the
> > string). I think it is better to use an explicit byte for length,
> > followed by HIT.
>

Yes.

Thanks.

--julien