Subject: [IPsec] IPSECKEY Resource Record Parameter for EdDSA

From: Robert Moskowitz <[email-masked]>
Date: Thu, 10 Oct 2019 16:11:44 -0400

Is there an update for EDDSA (RFC 8420) for the ipseckey RR?

https://www.iana.org/assignments/ipseckey-rr-parameters/ipseckey-rr-parameters.xhtml 

IANA is not showing it, so perhaps it is in a draft somewhere?

Thanks

---

From: Paul Wouters <[email-masked]>
Date: Thu, 10 Oct 2019 16:33:24 -0400

Not yet,

Also my idea was the skip ECDSA (8-11) and only do one for DigitalSignatures (14) style pubkey (RFC 7427)

Paul

Sent from my iPhone

> On Oct 10, 2019, at 16:11, Robert Moskowitz <[email-masked]> wrote:
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 10 Oct 2019 16:52:58 -0400

ok

At some point I am going to need one, as 8005 references IPSECKEY for 
its RR and I am using EdDSA for the tm-rid work.

Since we have a PK length field, that can separate Ed25519 from Ed448.

Right now we are framing our hackathon effort so will just use 
something.  Like 4.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 11 Oct 2019 11:26:48 +0200

> IANA is not showing it, so perhaps it is in a draft somewhere?

I haven't done this.
It's marked IETF Review, so a document is needed (but necessarily standards
track).
What's your use case today?  Surely not tm-rid?

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Fri, 11 Oct 2019 11:44:04 +0200

> its RR and I am using EdDSA for the tm-rid work.

I was surprised at the 8005 reference to IPSECKEY, since it seemed wrong that
a IPSECKEY RR would point at some machine that was going to answer with HIP
and not IKEv2...  but now I see that you have your own RR, but share the
algorithm numbers with IPSECKEY.

It seems that your tm-rid work can just amend this IANA registry.
If you had a WG, you could ask for an early allocation.  I don't think that
the IPSEC WG chairs could ask for an early allocation for you at this point,
alas.

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 11 Oct 2019 09:28:36 -0400

> What's your use case today?  Surely not tm-rid?

Yes it is tm-rid.  Look for a revision to

https://datatracker.ietf.org/doc/draft-moskowitz-hip-hhit-registries/

Any observer should have access to the HI on observing the HIT in the 
RemoteID Basic Message.  This is needed to validate the signature in the 
Authentication Message.

Only an authorized observer can query the USS for more information (as 
Stu alluded to) about the UAV.  In the ASTM docs we cannot release yet 
(grumble) they propose both SAML and JSON for the query for these 
details by an authorized observer.

Thus only the HI/HIT will be returned in the DNS query.  RVS is normally 
restricted information.

Bob

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 11 Oct 2019 09:35:03 -0400

> algorithm numbers with IPSECKEY.

there was an attitude to not maintain 2 separate number spaces.  Now I 
have to live with that (how would I handle the ECDH Identities for 
HIP-DEX which I do not belive IKE has anything similar?)

> the IPSEC WG chairs could ask for an early allocation for you at this point,

The way I see it, rfc 8420 'requires' this allocation.  I suspect 
whatever works for 8420 will work for draft-moskowitz-hip-new-crypto.

So I am being 'nice' and asking the owners of the IPSECKEY namespace to 
fix what I see as a shared problem.  I really don't want to go down a 
path of having a tm-rid wg doing the allocation.

Bob