Re: RFC 7217: random but stable addresses (take 2)

[Tom Cosgrove]

>>> Christian Weisgerber 14-Jul-17 23:04 >>>
>
> > secondly, im always wary of truncating hash output in case it throws
> > away some of the guarantees it's supposed to provide. if you cut
> > sha512 output down to an 8th of its size, is it 8 times easier to
> > calculate a collision, or more than 8 times easier? sha384 being a
> > truncation of sha512 kind of argues against this though.
>
> NIST FIPS 180-4 (the SHA-2 standard) says:
>
>   Some application may require a hash function with a message digest
>   length different than those provided by the hash functions in this
>   Standard. In such cases, a truncated message digest may be used,
>   whereby a hash function with a larger message digest length is
>   applied to the data to be hashed, and the resulting message digest
>   is truncated by selecting an appropriate number of the leftmost
>   bits. [...]
>
> (For some reason though the same standard specifies "SHA-512/t"
> hash functions, which are SHA-512 truncated to t bits, to use
> different initial hash values.  Maybe some mathematical rigor thing
> to distinguish truncation by the user from truncation inside the
> function?)

It is fine to truncate the output of a (good) hash function - see
this answer from Thomas Pornin on crypto.SE: 
https://crypto.stackexchange.com/a/163

However, when defining a new hash function as the truncation of the
output of an existing one (e.g. when using SHA256 to create a drop-in
replacement for a system that used SHA1 or MD5), it is considered
important to use a different set of IV constants - see this set of
slides from NIST: 
http://csrc.nist.gov/groups/ST/hash/documents/Kelsey_Truncation.pdf

No doubt I'll be shot down for the rest, but anway:

Obviously when truncating output down to 48 bits, the birthday attack
is only of the order of 2^24 bits, so finding colliions is not difficult.
But anyway, our output is public, and someone wishing to collide with us
doesn't have to use our mechanism, so collision resistance (in the usual
sense) is immaterial.

And nor (for the same reasons) are we worried about second preimage resistance.

So really, we're just using the hash function here as a PRF, to generate
random-looking but deterministic output from a given set of inputs.

In which case it doesn't really matter whether we use SHA512 or SipHash.

SipHash has some nice properties, but they're generally around the performance
side of things.  SHA512 is probably the more conservative choice, and
absolutely fine here.

Tom

Re: RFC 7217: random but stable addresses (take 2)

[Christian Weisgerber]

David Gwynne:


> secondly, im always wary of truncating hash output in case it throws away 
> some of the guarantees it's supposed to provide. if you cut sha512 output 
> down to an 8th of its size, is it 8 times easier to calculate a collision, or 
> more than 8 times easier? sha384 being a truncation of sha512 kind of argues 
> against this though.

NIST FIPS 180-4 (the SHA-2 standard) says:

  Some application may require a hash function with a message digest
  length different than those provided by the hash functions in this
  Standard. In such cases, a truncated message digest may be used,
  whereby a hash function with a larger message digest length is
  applied to the data to be hashed, and the resulting message digest
  is truncated by selecting an appropriate number of the leftmost
  bits. [...]

(For some reason though the same standard specifies "SHA-512/t"
hash functions, which are SHA-512 truncated to t bits, to use
different initial hash values.  Maybe some mathematical rigor thing
to distinguish truncation by the user from truncation inside the
function?)

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: RFC 7217: random but stable addresses (take 2)

[Florian Obser]

On Fri, Jul 14, 2017 at 11:06:49AM +1000, David Gwynne wrote:
> 
> > On 14 Jul 2017, at 06:30, Christian Weisgerber  wrote:
> > 
> > On 2017-07-13, Florian Obser  wrote:
> > 
> >> It switches the hash function to SipHash24 from sha512 as suggested by dlg
> > 
> > It's for from clear to me whether SipHash is suitable for crypto
> > operations, and which ones, other than the hash tables it was
> > designed for.
> 
> the abstract on the siphash paper says:
> 
> "SipHash is a family of pseudorandom functions optimized for short inputs. 
> Target applications include network traffic authentication and hash-table 
> lookups protected against hash-flooding denial-of-service attacks."
> 
> i somehow have the impression that it's use for hash tables was a convenient 
> bonus rather than a specific design target of the algorithm. it was handy 
> that it is good at spreading bits from a small input into its output.
> 
> > 
> > We went with SHA-512 for RFC 1948 TCP initial sequence number
> > generation, which is arguably performance-sensitive, while RFC 7217
> > addresses are certainly not.  I think we should use a SHA-2-family
> > function such as SHA-512 here.
> 
> i dont mind which way we go, but i would like to make two (possibly invalid) 
> arguments. 
> 
> firstly, we're generating public information. if anyone wants to "collide" 
> with us, the can just copy and use the same ip, regardless of how we got 
> there. as long as the key is strong enough we should be able to prevent 
> prediction of other soii based addresses. if we're trying to protect against 
> recovery of information, specifically the mac address, we could just not feed 
> that into the hash. use the name of the interface instead, which is what 
> netstart uses to assign addresses too.
> 
> secondly, im always wary of truncating hash output in case it throws away 
> some of the guarantees it's supposed to provide. if you cut sha512 output 
> down to an 8th of its size, is it 8 times easier to calculate a collision, or 
> more than 8 times easier? sha384 being a truncation of sha512 kind of argues 
> against this though.

My understanding of siphash is, too, that we are probably fine with
using it, but then what do I know about hash functions... And since we
are arguing about it and this is not performance critical at all we
shouldn't half-arse it and just go with sha512.

> 
> with regard to the code, siphash implied a length for soiikey which makes the 
> sysctl handling a lot easier. if (when?) we go back to sha512 id like to see 
> a fixed key length remain. we can make it bigger, but just keep it one size.

Yes, there is no point for a user to set a key of a specific length.
It's a randomly generated opaque blob.

I'll send an updated diff shortly addressing all the input so far, thanks!

-- 
I'm not entirely sure you are real.

Re: RFC 7217: random but stable addresses (take 2)

[Florian Obser]

On Thu, Jul 13, 2017 at 08:30:55PM -, Christian Weisgerber wrote:
> On 2017-07-13, Florian Obser  wrote:
[...]
> > +# Apply soiikey.conf settings.
> > +soiikey_conf() {
> > +   stripcom /etc/soiikey.conf |
> > +   while read _line; do
> > +   sysctl -q "net.inet6.ip6.soiikey=$_line"
> > +   done
> > +}
> 
> I think .conf is a strange choice of name for what is not a
> configuration file but effectively a private key, cf.
> 
> /etc/{iked,isakmpd}/private/local.key
> /etc/ssh/ssh_host__key
> 

Ugh, yes, brain fart

> > +SOOIs use the whole 64 bit of the host part while SLAAC addresses are
> > +formed from MAC addresses and have 48 bits of entropy at most.
> 
> 46 bits.
> (The first bit of a MAC address is 0 for unicast addresses, the
> second is 0 for "universally administered" addresses, i.e., those
> that are uniquely assigned to a device by its manufacturer.)

Yes, I know, that's why I used "at most", and yes, you cannot actually
reach it.
The point is to give the casual reader ball park figures:

128 bit: Yeah, I'm not going to try
64 bit: Probably fine, doesn't cost me any sleep
48 bit: Hmm...
24 bit: Hold my beer and watch this, I can send a million packets with
my phone!

I'm afraid if we put in 46 people will start to wonder why 46 while
they might have heard that a mac is 48 bits. Anyway, I'll try to come
up with wording to avoid exact numbers.

> 
> -- 
> Christian "naddy" Weisgerber  na...@mips.inka.de
> 

-- 
I'm not entirely sure you are real.

Re: RFC 7217: random but stable addresses (take 2)

[Ted Unangst]

David Gwynne wrote:
> secondly, im always wary of truncating hash output in case it throws away 
> some of the guarantees it's supposed to provide. if you cut sha512 output 
> down to an 8th of its size, is it 8 times easier to calculate a collision, or 
> more than 8 times easier? sha384 being a truncation of sha512 kind of argues 
> against this though.

on this point, all the bits are supposed to be equally good. you can take as
many as you want, and just like that, you have an X bit hash.

Re: RFC 7217: random but stable addresses (take 2)

[David Gwynne]

> On 14 Jul 2017, at 06:30, Christian Weisgerber  wrote:
> 
> On 2017-07-13, Florian Obser  wrote:
> 
>> It switches the hash function to SipHash24 from sha512 as suggested by dlg
> 
> It's for from clear to me whether SipHash is suitable for crypto
> operations, and which ones, other than the hash tables it was
> designed for.

the abstract on the siphash paper says:

"SipHash is a family of pseudorandom functions optimized for short inputs. 
Target applications include network traffic authentication and hash-table 
lookups protected against hash-flooding denial-of-service attacks."

i somehow have the impression that it's use for hash tables was a convenient 
bonus rather than a specific design target of the algorithm. it was handy that 
it is good at spreading bits from a small input into its output.

> 
> We went with SHA-512 for RFC 1948 TCP initial sequence number
> generation, which is arguably performance-sensitive, while RFC 7217
> addresses are certainly not.  I think we should use a SHA-2-family
> function such as SHA-512 here.

i dont mind which way we go, but i would like to make two (possibly invalid) 
arguments. 

firstly, we're generating public information. if anyone wants to "collide" with 
us, the can just copy and use the same ip, regardless of how we got there. as 
long as the key is strong enough we should be able to prevent prediction of 
other soii based addresses. if we're trying to protect against recovery of 
information, specifically the mac address, we could just not feed that into the 
hash. use the name of the interface instead, which is what netstart uses to 
assign addresses too.

secondly, im always wary of truncating hash output in case it throws away some 
of the guarantees it's supposed to provide. if you cut sha512 output down to an 
8th of its size, is it 8 times easier to calculate a collision, or more than 8 
times easier? sha384 being a truncation of sha512 kind of argues against this 
though.

with regard to the code, siphash implied a length for soiikey which makes the 
sysctl handling a lot easier. if (when?) we go back to sha512 id like to see a 
fixed key length remain. we can make it bigger, but just keep it one size.

> 
>> +# Apply soiikey.conf settings.
>> +soiikey_conf() {
>> +stripcom /etc/soiikey.conf |
>> +while read _line; do
>> +sysctl -q "net.inet6.ip6.soiikey=$_line"
>> +done
>> +}
> 
> I think .conf is a strange choice of name for what is not a
> configuration file but effectively a private key, cf.
> 
> /etc/{iked,isakmpd}/private/local.key
> /etc/ssh/ssh_host__key

id also like to see key in the name, not conf.

> 
>> +SOOIs use the whole 64 bit of the host part while SLAAC addresses are
>> +formed from MAC addresses and have 48 bits of entropy at most.
> 
> 46 bits.
> (The first bit of a MAC address is 0 for unicast addresses, the
> second is 0 for "universally administered" addresses, i.e., those
> that are uniquely assigned to a device by its manufacturer.)
> 
> -- 
> Christian "naddy" Weisgerber  na...@mips.inka.de
> 

Re: RFC 7217: random but stable addresses (take 2)

[Christian Weisgerber]

On 2017-07-13, Florian Obser  wrote:

> It switches the hash function to SipHash24 from sha512 as suggested by dlg

It's for from clear to me whether SipHash is suitable for crypto
operations, and which ones, other than the hash tables it was
designed for.

We went with SHA-512 for RFC 1948 TCP initial sequence number
generation, which is arguably performance-sensitive, while RFC 7217
addresses are certainly not.  I think we should use a SHA-2-family
function such as SHA-512 here.

> +# Apply soiikey.conf settings.
> +soiikey_conf() {
> + stripcom /etc/soiikey.conf |
> + while read _line; do
> + sysctl -q "net.inet6.ip6.soiikey=$_line"
> + done
> +}

I think .conf is a strange choice of name for what is not a
configuration file but effectively a private key, cf.

/etc/{iked,isakmpd}/private/local.key
/etc/ssh/ssh_host__key

> +SOOIs use the whole 64 bit of the host part while SLAAC addresses are
> +formed from MAC addresses and have 48 bits of entropy at most.

46 bits.
(The first bit of a MAC address is 0 for unicast addresses, the
second is 0 for "universally administered" addresses, i.e., those
that are uniquely assigned to a device by its manufacturer.)

-- 
Christian "naddy" Weisgerber  na...@mips.inka.de

Re: RFC 7217: random but stable addresses (take 2)

[Florian Obser]

On Thu, Jul 13, 2017 at 05:59:24PM +0200, Alexander Bluhm wrote:
> On Thu, Jul 13, 2017 at 03:43:50PM +, Florian Obser wrote:
> > It switches the hash function to SipHash24 from sha512 as suggested by dlg
> 
> Is is performance critical?  Then siphash would be better.

no

> 
> Is is a security concern?  Is is a problem that someone could try

maybe..

> to calculate our secret when he knows a bunch of our IP addresses?
> Then sha512 would be better.

if you know the key and the mac you can track a host when it moves to
a different prefix.

> 
> I don't know wether the algorithm is relevant here.  So I would
> have chosen sha512.

sha512 is certainly the conservative choice. note that we are only use
64 bit so the digest is a wee bit to big ;)

I'm happy to bikeshed this for a bit since it kinda defeats the
purpose if we need to change the hash function later.

dlg?

> 
> bluhm
> 

-- 
I'm not entirely sure you are real.

Re: RFC 7217: random but stable addresses (take 2)

[Alexander Bluhm]

On Thu, Jul 13, 2017 at 03:43:50PM +, Florian Obser wrote:
> It switches the hash function to SipHash24 from sha512 as suggested by dlg

Is is performance critical?  Then siphash would be better.

Is is a security concern?  Is is a problem that someone could try
to calculate our secret when he knows a bunch of our IP addresses?
Then sha512 would be better.

I don't know wether the algorithm is relevant here.  So I would
have chosen sha512.

bluhm

RFC 7217: random but stable addresses (take 2)

[Florian Obser]

this has all the bells and whistles notably the installer and
documentation for the net.inet6.ip6.soiikey sysctl are missing.

the sysctl implementation is from dlg, all the mistakes are probably
tweaks by me ;)

It switches the hash function to SipHash24 from sha512 as suggested by dlg

Comments, tests, improvments, OKs?

diff --git etc/rc etc/rc
index 48e5671335f..fda8a620bbb 100644
--- etc/rc
+++ etc/rc
@@ -47,6 +47,14 @@ update_limit() {
done
 }
 
+# Apply soiikey.conf settings.
+soiikey_conf() {
+   stripcom /etc/soiikey.conf |
+   while read _line; do
+   sysctl -q "net.inet6.ip6.soiikey=$_line"
+   done
+}
+
 # Apply sysctl.conf(5) settings.
 sysctl_conf() {
stripcom /etc/sysctl.conf |
@@ -60,6 +68,7 @@ sysctl_conf() {
update_limit -n openfiles;;
esac
done
+   soiikey_conf
 }
 
 # Apply mixerctl.conf(5) settings.
@@ -154,6 +163,11 @@ make_keys() {
fi
 
ssh-keygen -A
+
+   if [[ ! -f /etc/soiikey.conf ]]; then
+   openssl rand -hex 16 > /etc/soiikey.conf && \
+   chmod 600 /etc/soiikey.conf && soiikey_conf
+   fi
 }
 
 # Re-link libraries, placing the objects in a random order.
diff --git sbin/ifconfig/brconfig.h sbin/ifconfig/brconfig.h
index ee68feb411b..09c871b352b 100644
--- sbin/ifconfig/brconfig.h
+++ sbin/ifconfig/brconfig.h
@@ -73,7 +73,7 @@ void switch_portno(const char *, const char *);
"\024\1UP\2BROADCAST\3DEBUG\4LOOPBACK\5POINTOPOINT\6NOTRAILERS" \
"\7RUNNING\10NOARP\11PROMISC\12ALLMULTI\13OACTIVE\14SIMPLEX"\
"\15LINK0\16LINK1\17LINK2\20MULTICAST"  \
-   "\23INET6_NOPRIVACY\24MPLS\25WOL\26AUTOCONF6"
+   "\23INET6_NOPRIVACY\24MPLS\25WOL\26AUTOCONF6\27INET6_NOSOII"
 
 void printb(char *, unsigned int, unsigned char *);
 
diff --git sbin/ifconfig/ifconfig.8 sbin/ifconfig/ifconfig.8
index cac8eafc2cb..30721e41ad4 100644
--- sbin/ifconfig/ifconfig.8
+++ sbin/ifconfig/ifconfig.8
@@ -1070,6 +1070,7 @@ protocol when supported by the access point.
 .Op Oo Fl Oc Ns Cm autoconfprivacy
 .Op Cm eui64
 .Op Cm pltime Ar n
+.Op Oo Fl Oc Ns Cm soii
 .Op Oo Fl Oc Ns Cm tentative
 .Op Cm vltime Ar n
 .Ek
@@ -1127,6 +1128,21 @@ Fill the interface index
 automatically.
 .It Cm pltime Ar n
 Set preferred lifetime for the address.
+.It Cm soii
+Enable persistent Semantically Opaque Interface Identifiers (SOIIs),
+as per RFC 7217, for link local and SLAAC addresses on the interface.
+These identifiers are enabled by default.
+The purpose of these identifiers is to make discovery of hosts by
+scanning a whole prefix more difficult.
+SOOIs use the whole 64 bit of the host part while SLAAC addresses are
+formed from MAC addresses and have 48 bits of entropy at most.
+In reality entropy can be  as low as 24 bit.
+See RFC 8064 for details.
+.It Cm -soii
+Disable IPv6 persistent Semantically Opaque Interface Identifiers on the
+interface.
+Currently configured addresses will not be removed until they become
+invalid.
 .It Cm tentative
 Set the IPv6 tentative address bit.
 .It Cm -tentative
diff --git sbin/ifconfig/ifconfig.c sbin/ifconfig/ifconfig.c
index d99bcb34871..bd7ce506398 100644
--- sbin/ifconfig/ifconfig.c
+++ sbin/ifconfig/ifconfig.c
@@ -388,6 +388,8 @@ const structcmd {
{ "eui64",  0,  0,  setia6eui64 },
{ "autoconfprivacy",-IFXF_INET6_NOPRIVACY,  0,  setifxflags },
{ "-autoconfprivacy",   IFXF_INET6_NOPRIVACY,   0,  setifxflags },
+   { "soii",   -IFXF_INET6_NOSOII, 0,  setifxflags },
+   { "-soii",  IFXF_INET6_NOSOII,  0,  setifxflags },
 #ifndef SMALL
{ "hwfeatures", NEXTARG0,   0,  printifhwfeatures },
{ "metric", NEXTARG,0,  setifmetric },
diff --git sbin/slaacd/control.c sbin/slaacd/control.c
index 76b0f3b15ea..4f38d26331c 100644
--- sbin/slaacd/control.c
+++ sbin/slaacd/control.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git sbin/slaacd/engine.c sbin/slaacd/engine.c
index e02cb6ec3d0..cc7abd68512 100644
--- sbin/slaacd/engine.c
+++ sbin/slaacd/engine.c
@@ -70,6 +70,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -180,6 +181,7 @@ struct address_proposal {
uint8_t  prefix_len;
uint32_t vltime;
uint32_t pltime;
+   SIPHASH_KEY  soiikey;
 };
 
 struct dfr_proposal {
@@ -205,8 +207,10 @@ struct slaacd_iface {
uint32_t if_index;
int  running;
int  autoconfprivacy;
+   int  soii;
struct ether_addrhw_address;
struct sockaddr_in6  ll_address;
+   SIPHASH_KEY