Re: Eric Rescorla's No Objection on draft-ietf-hip-rfc4423-bis-19: (with COMMENT)

--===============4210750203512910232==
Content-Type: multipart/alternative; boundary="000000000000076577057efaf086"

--000000000000076577057efaf086
Content-Type: text/plain; charset="UTF-8"

On Tue, Jan 8, 2019 at 9:50 AM Tom Henderson <[email protected]> wrote:

> On 1/8/19 5:57 AM, Eric Rescorla wrote:
>
> >     The second preimage attack resistance is 96 bits, plus whatever work
> >     is needed to generate the keys.
> >
> > I agree that this is in RFC 7343, but it doesn't seem to be stated
> > anywhere in this document, and  given that this text talks about both 64
> > bit and >= 100 bit hash functions, I'm not sure how to get it from this
> > text, which is in context quite confusing/
>
> I agree that the text could be clarified; I will try to suggest
> something more.
>
> >
> >     There isn't any mechanism defined to extend this, such as the CGA
> >     Hash Extension, but it seems to me that HIP could be extended in a
> >     similar way.  My recollection is that the WG had thought 96 bits to
> >     be strong enough preimage resistance.
> >
> > Generally, we are targeting the 128-bit security level for new
> deployments
> >
>
> Can you provide a reference for the 128-bit recommendation?
>

I don't believe there is a policy, but for instance, see:
https://tools.ietf.org/html/rfc7525#section-4.1



> Also, how are legacy uses like SEND/CGA handling this new target (or are
> they just considered legacy at this point)?
>

As far as I understand it, they are legacy.

-Ekr


> - Tom
>

--000000000000076577057efaf086
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr">On Tue, Jan 8, 2019 at 9:50 AM Tom Hender=
son &lt;<a href=3D"mailto:[email protected]">[email protected]</a>&gt; wrote:<br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex">On 1/8/19 5:57 AM, Er=
ic Rescorla wrote:<br>
<br>
&gt;=C2=A0 =C2=A0 =C2=A0The second preimage attack resistance is 96 bits, p=
lus whatever work<br>
&gt;=C2=A0 =C2=A0 =C2=A0is needed to generate the keys.<br>
&gt; <br>
&gt; I agree that this is in RFC 7343, but it doesn&#39;t seem to be stated=
 <br>
&gt; anywhere in this document, and=C2=A0 given that this text talks about =
both 64 <br>
&gt; bit and &gt;=3D 100 bit hash functions, I&#39;m not sure how to get it=
 from this <br>
&gt; text, which is in context quite confusing/<br>
<br>
I agree that the text could be clarified; I will try to suggest <br>
something more.<br>
<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0There isn&#39;t any mechanism defined to extend thi=
s, such as the CGA<br>
&gt;=C2=A0 =C2=A0 =C2=A0Hash Extension, but it seems to me that HIP could b=
e extended in a<br>
&gt;=C2=A0 =C2=A0 =C2=A0similar way.=C2=A0 My recollection is that the WG h=
ad thought 96 bits to<br>
&gt;=C2=A0 =C2=A0 =C2=A0be strong enough preimage resistance.<br>
&gt; <br>
&gt; Generally, we are targeting the 128-bit security level for new deploym=
ents<br>
&gt; <br>
<br>
Can you provide a reference for the 128-bit recommendation?<br></blockquote=
><div><br></div><div>I don&#39;t believe there is a policy, but for instanc=
e, see: <br></div><div><a href=3D"https://tools.ietf.org/html/rfc7525#secti=
on-4.1">https://tools.ietf.org/html/rfc7525#section-4.1</a></div><div><br><=
/div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Also, how are legacy uses like SEND/CGA handling this new target (or are <b=
r>
they just considered legacy at this point)?<br></blockquote><div><br></div>=
<div>As far as I understand it, they are legacy.</div><div><br></div><div>-=
Ekr</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
- Tom<br>
</blockquote></div></div></div>

--000000000000076577057efaf086--


--===============4210750203512910232==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec

--===============4210750203512910232==--