RE: AERO/OMNI dropping support for SEND/CGA

[Vasilenko Eduard <[e-mail]>]

It is funny how CGA purpose is justified: "for the case if RSA would fail". (in SeND RFC)
It is the redundant algorithm to the normal RSA open key cryptography in SeND.
I have the temptation to ask: what if CGA would fail too? May be 3rd redundant cryptography is needed? (Sarcasm).

The essence of CGA algorithm:
It is based on the fact that original owner does not care about IID – it could be hash, but intruder would need exact IID.
If one would ask Sec of leading Zero in the hash, then legal host would need initially 2^(16*Sec) time to generate IID.
But Intruder would need 2^(59+16*Sec).

It is like block-chain - much more time and resources needed than any open key cryptography:
1. a lot of hashes to generate IID -> very expensive
2. in the case of collision (DAD?) - change "modifier" (parameter) and calculate again -> time consuming

I am not so optimistic about quantum. I believe that this hype is ground-less.
Analog computer is something very powerful for special tasks - was popular in 1970x.
It could be revived on the next level of performance. That’s it.
Ed/
> -----Original Message-----
> From: ipv6 [mailto:[e-mail]] On Behalf Of Alexandre Petrescu
> Sent: 2 декабря 2020 г. 21:14
> To: [e-mail]
> Subject: Re: AERO/OMNI dropping support for SEND/CGA
> 
> 
> 
> Le 01/12/2020 à 10:06, Vasilenko Eduard a écrit :
> > Hi Fred,
> > SeND needs a refresh. CGA looks ridicules now in principle. You should not use
> it.
> 
> I am not sure what in CGA might need ridiculuous?
> 
> Probably the old crypto algorithms involved?
> 
> > I am not sure: does it make sense to develop something else instead (based on
> ecliptic curves).
> 
> If there is something new to be developped it would need to take into account
> the 'post-quantum' crypto, i.e. algorithms whose output would resist brute force
> attacks performed by forthcoming quantum computers.
> 
> These stronger algorithms would run on classical computer still.
> 
> > As Fernando pointed many times: many things in ND could be resolved only by
> digital signature (he calls it "untrusted model").
> 
> YEs yes.
> 
> Alex
> 
> > But as we see: market has rejected PKI. Digital signature is not useful without
> proper key management.
> > IMHO: it is better to keep digital signature as a separate standard.
> > Therefore, if you have cycles for separate OMNI addendum, then it is better to
> have it for completeness. If not - not much to lose now.
> > But make sure that Open Key Cryptography and PKI (!) would be possible to
> add later.
> > What if something would be innovated in PKI and it became popular?
> > Reminder: PKI is needed not just for ND. Enterprises have the big pressure to
> protect all applications by TLS.
> > Your vertical would probable lead on PKI adoption.
> >
> > As an alternative: you could talk with IT and Security people in your vertical: if
> they believe in massive deployment of PKIs then you have to have Digital
> Signature for ND.
> > It would still not guaranty that it would be used, because hosts would need
> support for it at ND level, but it is already the good situation to try.
> > Hence again, better to keep it in separate specification.
> >
> > Eduard
> >> -----Original Message-----
> >> From: ipv6 [mailto:[e-mail]] On Behalf Of Templin (US),
> >> Fred L
> >> Sent: 1 декабря 2020 г. 1:12
> >> To: [e-mail]
> >> Subject: AERO/OMNI dropping support for SEND/CGA
> >>
> >> Folks, this is a big decision point for the AERO/OMNI drafts but I am
> >> preparing to drop support for SEND/CGA (RFC3971; RFC3972). This means
> >> that IPv6 ND message authentication on OMNI interfaces will use a
> >> simple HMAC the same as is done for Teredo (RFC4380; RFC6081). If
> >> anyone knows why that might cause problems, it would be best to speak up
> now.
> >>
> >> Fred
> >>
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> [e-mail]
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------