Subject: [babel] rather than ripemd160...

From: Dave Taht <[email-masked]>
Date: Mon, 26 Nov 2018 04:43:34 -0800

I have been fiddling with the hmac-challenge branch and deeply unhappy
at the prospect of how much cpu this may end up consuming on the cheap
MIPs routers common today (which are, admittedly, rapidly being
replaced by cheap ARM ones).  (let's not talk about dtls)

Anyway, the default hash function is sha256 in the hmac-challenge
branch. I approve, there's hardware support for it, and if someone
breaks it, civilization collapses, so an alternate hmac is a "good to
have", and what's in that branch... is ripemd160.

Both blake and siphash seem like a superior choice for an alternate
hmac function to ripemd160. In particular blake is subject of its own
RFC, and comes in several clean highly optimized versions for x86 and
arm architectures.

https://blake2.net/ -

https://www.131002.net/siphash/siphash.pdf ?

-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 26 Nov 2018 14:06:37 +0100

> have", and what's in that branch... is ripemd160.

From a standardisation point of view:

  - HMAC-SHA256 is Mandatory to Implement;
  - implementation may implement other MAC algorithms, and since no
    algorithm identifier is carried on the wire, doing that requires no
    further standardisation action.

From the point of view of the implementation, we need to clean up this
code to remove the dependency on OpenSSL.  When we do that, we'll probably
remove the HMAC-RIPEMD160 code, and leave just SHA256.  (Don't hold your
breath, though -- it's exam season for both the girls and myself.)

If we add another HMAC algorithm, we'll want to do it in agreement with
Toke, so that both implementations implement the same set of HMAC algorithms.

> Both blake and siphash seem like a superior choice for an alternate hmac
> function to ripemd160. In particular blake is subject of its own RFC,
> and comes in several clean highly optimized versions for x86 and arm
> architectures.

I hold no opinion on that at the current time, I'd need to consult my
colleagues.

-- Juliusz

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Mon, 26 Nov 2018 14:24:07 +0100

Juliusz Chroboczek <[email-masked]> writes:

> If we add another HMAC algorithm, we'll want to do it in agreement
> with Toke, so that both implementations implement the same set of HMAC
> algorithms.

Bird already supports HMAC using MD5, SHA1, SHA256, SHA384 and SHA512,
which is inherited by the Babel implementation. I am planning to add
blake2s to that when I get around to revising the HMAC patch (see
below).

> I hold no opinion on that at the current time, I'd need to consult my

I happen to share Dave's concern about sha256. And basically all the
crypto people I've been talking to have been of the opinion that blake2s
is the way to go for low-powered devices. So I am definitely planning to
add an implementation of that to Bird, and may even make it the default
for Babel.

I'm not sure if we *can* make it MTI in the spec as well (does it need
to be defined by a standards track RFC for us to do that?), but if we
can, I think we should seriously consider it...

-Toke

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 26 Nov 2018 14:46:25 +0100

> I'm not sure if we *can* make [blake2s] MTI in the spec as well (does it
> need to be defined by a standards track RFC for us to do that?), but if
> we can, I think we should seriously consider it...

Opinions?

---

From: Dave Taht <[email-masked]>
Date: Mon, 26 Nov 2018 05:46:36 -0800

> add an implementation of that to Bird, and may even make it the default

Well, I'd like to benchmark blake2b some also. The trendline IS
towards 64bits and mips is dying...

What's their definition of "low powered"? While blake2s is claimed to
work on 8 bit boxes, I don't see any of those on the internet. I
certainly see (as examples)
the esp32 (https://en.wikipedia.org/wiki/ESP32) as something that
would be cool to run babel on. (that one claims sha2 accelleration
also).

> I'm not sure if we *can* make it MTI in the spec as well (does it need

I'd like two hmacs to be MTI. As for the default... benchmarks on
cheap hardware are needed.

> can, I think we should seriously consider it...

I like having a backup plan so that in the rubble of civilization for
sha256's breakage, we can at least route packets.

https://tools.ietf.org/html/rfc7693 is informational. Is that good enough?

-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Mon, 26 Nov 2018 14:51:31 +0100

> https://tools.ietf.org/html/rfc7693 is informational. Is that good

That's what I'm not sure about; it's neither standards track nor backed
by a working group. So someone with more knowledge of IETF process than
me needs to weigh in here :)

-Toke

---

From: Markus Stenberg <[email-masked]>
Date: Mon, 26 Nov 2018 15:53:34 +0200

>> we can, I think we should seriously consider it...

I like Blake (family of) hash functions so on that front +1; however, no idea how bureaucracy works.

Dave had a good point as well though, comparing -2s and -2b performance on some set of hardware (e.g. arm, mips, intel) might be in order before picking between the two. I am not convinced -2s is the way _forward_. Even now most of hardware in my home is already 64bit ..

-Markus

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Mon, 26 Nov 2018 14:59:20 +0100

Markus Stenberg <[email-masked]> writes:

> Dave had a good point as well though, comparing -2s and -2b
> performance on some set of hardware (e.g. arm, mips, intel) might be
> in order before picking between the two. I am not convinced -2s is the
> way _forward_. Even now most of hardware in my home is already 64bit
> ..

Right, sure. I guess I can start by putting both into Bird, and we can
benchmark that...

-Toke

---

From: Dave Taht <[email-masked]>
Date: Mon, 26 Nov 2018 06:21:26 -0800

To me this leaves the biggest problem remaining is key rotation. Me
being me, and remembering just how hard it was to get dnssec working
on systems lacking reliable time,
I worry about that part. What we settled on for dnsmasq-dnssec was to
write the current time to flash every day (or few hours), boot up
without dnssec enabled long enough to
get an ntp server... and rely on key rollover taking hours or days to
*usually* get a correct result. RTCs with batteries are usually not
included.

that's still fragile (imagine a power failure lasting days, or a box
being down for several days for repair. It happens).

In the case of routing... if you don't have the correct time... and
you can't get a route so you can get the correct time from ntp... then
what? Do we make GPSes MTI also?

Setting that aside for the moment, having a standardized file format
for babel keys would be a boon and boost interoperability between
bird/babel and other possible implementations.
You would merely declare a key name in the main conf for bird or
babel, and reference it in a separate file with a format like this:

KEY  START_DATE END_DATE TYPE VALUE
name\wrfc3339\wrfc3339\wsha256|blake2s\wvalue

https://tools.ietf.org/html/rfc3339

administrators would push out this one standard format file to
routers, strongly suggesting that UTC times be used universally and
that key rollover should be staged over hours or days lest
connectivity be lost. Other sanity checks like ensuring there is some
form of persistent and correct time on routers using authentication
are also needed.

alternatives might include certs and other stuff that bears drinking about.

-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 26 Nov 2018 16:10:41 +0100

> Dave had a good point as well though, comparing -2s and -2b performance
> on some set of hardware (e.g. arm, mips, intel) might be in order before
> picking between the two.

HMAC only protects the control traffic, not the data traffic.  I'm not
convinced that performance is particularly critical here.

-- Juliusz

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 26 Nov 2018 11:44:23 -0800

A draft that proposed pair-wise key management was proposed here <https://tools.ietf.org/html/draft-mahesh-karp-kmprp-00>.  It does not address the question of timestamp, but is something that could be exchanged as part of key rollover to allow routers to calculate the delta. Including the original authors of the draft.

> On Nov 26, 2018, at 6:21 AM, Dave Taht <[email-masked]> wrote:
> 
> _______________________________________________
> babel mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/babel

Mahesh Jethanandani
[email-masked]

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 26 Nov 2018 19:47:59 +0000

FYI. IETF policies re "downrefs" in standards track RFCs is described in
https://tools.ietf.org/html/rfc3967 (and updated by https://tools.ietf.org/html/rfc8067).
In short, it's not prohibited, but careful review is required. 
Note RFC3967 Section 2 first bullet

   There are a number of circumstances in which an IETF document may
   need to make a normative reference to a document at a lower maturity
   level, but such a reference conflicts with Section 4.2.4 of
   [RFC2026].  For example:

   o  A standards track document may need to refer to a protocol or
      algorithm developed by an external body but modified, adapted, or
      profiled by an IETF informational RFC, for example, MD5 [RFC1321]
      and HMAC [RFC2104].  Note that this does not override the IETF's
      duty to see that the specification is indeed sufficiently clear to
      enable creation of interoperable implementations.

Barbara

> > https://tools.ietf.org/html/rfc7693 
is informational. Is that good
> enough?
> 
> That's what I'm not sure about; it's neither standards track nor backed by a
> working group. So someone with more knowledge of IETF process than me
> needs to weigh in here :)
> -Toke
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_babel&d=DwICAg&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=-
> 6LF6X6DzeRccquqfCJFAeSx31uwzB0oM82nApUzuPo&s=1QakSDy0dO0qZVEb
> YiyJb6tj_NKEToWqiVanTi-rv6k&e=

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Mon, 26 Nov 2018 21:59:41 +0100

>       enable creation of interoperable implementations.

Ah, so HMAC itself is already an informational RFC? Great, let's do
blake2, then! :D

-Toke

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Mon, 26 Nov 2018 22:10:56 +0100

> on systems lacking reliable time,

The Babel HMAC extension as currently specified does not rely on wall
clock time in any way, so not really sure how a comparison to dnssec is
relevant?

>From the point of view of each routing daemon this would just make Babel
a special snowflake.

What we can do is to specify the format in the information model if a
cross-implementation format is really needed (which I'm not really
convinced of, either)...

-Toke

---

From: Dave Taht <[email-masked]>
Date: Mon, 26 Nov 2018 14:03:53 -0800

> clock time in any way, so not really sure how a comparison to dnssec is

More below. Relative time is ok, too. 3000 seconds from now, start
rolling over. Stop signing records with the old key as soon as
everyone you can currently hear uses the new key, 6000 seconds from
now, retire the old key unconditionally.

> From the point of view of each routing daemon this would just make Babel

ok. That leaves how to get new keys into nodes running different
daemons. Anyone for IKEv2?

My out of bound way is via scp and ssh.

Also the present babeld cannot rewrite it's entire config file (so far
as I know). I think bird can... but I don't trust it.

As for the key format, I wanted a way to test keys and key rollover in
the existing daemons to verify this bit would work, and also measure
the cpu overhead and failure modes, like those I describe below.

> cross-implementation format is really needed (which I'm not really

To quote from appendix A:

"In order to perform key rotation, the new key is added to all the
nodes; once this is done, both the old and the new key are sent in all
packets, and packets are accepted if they are properly signed by
either of the keys. At that point, the old key is removed."

My key points made here are "the new key is added to *all* the
nodes"... which may or may not be up over the course of days, or weeks
for whatever definition of "all" you have ... "Once this is done" -
how can you tell? -  "and packets are accepted if they are properly
signed by either of the keys" hopefully you log this ... "the old key
is removed".

perhaps "deprecated, no longer actively used for signing, then removed
after a suitable period"?

So, if you do a key rotation and X routers are offline or inaccessible
at that particular time... they are going to stay inaccessible
forevermore, unless rekey'd via sneakernet, climbing on trees, and
other forms of manual intervention.

The case where you want to immediately remove a key is in the event of
a security breach.

I tried to use the example of dnssec as one way key rotation (on
admittedly a much bigger scale) that got done right, but the new keys
were distributed a good year beforehand.

https://kb.isc.org/docs/aa-00822

...

also "old and new key are sent" should be "old & new keys are used for signing".

...

-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Mon, 26 Nov 2018 23:22:05 +0100

> now, retire the old key unconditionally.

Well, you would handle this by whatever mechanism you use to configure
your routers in the first place...

> My out of bound way is via scp and ssh.

I think Juliusz' insistence that we shouldn't reinvent key distribution
is wise. See above; you need to configure the daemons in the first place
anyway...

> as I know). I think bird can...

Yup, a 'bird reconfigure' will re-read the entire config file and apply
it if it parses successfully.

> but I don't trust it.

Your trust issues are probably best resolved between you and your daemon ;)

> after a suitable period"?

Hmm, having a way to mark a key as "verify only" may be useful for
simpler monitoring. But really, you *could* derive the same information
from the opposite bit (track how many neighbours don't sign with the new
key yet). So then it becomes more of an efficiency issue (you could save
one signature on the wire during rotation). Not sure if it's worth
specifying another bit in the spec for this? Or if such a configuration
mode should even be in the spec at all?

> other forms of manual intervention.

Presumably your key rotation policy would take into account the outage
schedules of the routers in your network? :)

-Toke

---

From: David Schinazi <[email-masked]>
Date: Tue, 27 Nov 2018 13:42:54 -0800

I feel strongly against making anything but SHA-256 mandatory to implement.
It will delay publication and not improve the interoperability story. That
said, I agree that the Blake2 family is a good fit here so it would be nice
to have bird and babeld support them - but they do not need to be in the
spec.

David

On Mon, Nov 26, 2018 at 12:59 PM Toke Høiland-Jørgensen <[email-masked]>
wrote:

> Babel-users mailing list
> [email-masked]
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users

---

From: David Schinazi <[email-masked]>
Date: Tue, 27 Nov 2018 13:53:44 -0800

Maybe I'm misunderstanding, but I think this issue is not comparable to
DNSSEC. The key difference here (no pun intended) is that you can operate
Babel-HMAC with multiple keys at the same time. So your rollover becomes a
simple two step process:
0) all routers are functioning with OLD_KEY configured
1) go into all routers one by one and configure them to use both OLD_KEY
and NEW_KEY
2) go into all routers one by one and configure them to only use NEW_KEY
3) profit

You don't need any notion of time, or any added complexity to the spec.

If some of the routers are down during step (1), you get to decide whether
to either wait for them to come back, or skip them and effectively
disconnect them from the network based on the urgency of your key rollover.
Anything beyond that becomes a key management problem that is specific to
your deployment, not to the routing protocol you use.

---

From: Dave Taht <[email-masked]>
Date: Tue, 27 Nov 2018 19:29:49 -0800

David Schinazi <[email-masked]> writes:

> I feel strongly against making anything but SHA-256 mandatory to
> implement. It will delay publication and not improve the
> interoperability story. That said, I agree that the Blake2 family is a
> good fit here so it would be nice to have bird and babeld support them
> - but they do not need to be in the spec.

Are we weeks, months, or years away from publication? Do we have
time to, like, actually code up, and test interoperability, performance,
and methods, before prague?

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Wed, 28 Nov 2018 12:39:05 +0100

David Schinazi <[email-masked]> writes:

> implement.

> It will delay publication

Not if there's already a draft we can simply refer to (like with
SHA-256); I do agree that we shouldn't be trying to pull Blake through
the IETF process if there isn't...

> and not improve the interoperability story.

Why not? If it's not MTI you risk the case where you get to pick between
"good performance on weak devices" and "interoperability with RFC-only
implementations".

-Toke

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Wed, 28 Nov 2018 12:40:57 +0100

Dave Taht <[email-masked]> writes:

> Are we weeks, months, or years away from publication? Do we have time
> to, like, actually code up, and test interoperability, performance,

Seeing as we already have prototype implementations in both babeld and
bird, I don't see why not; if someone volunteers to do the testing (*hint*) ;)

-Toke

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 28 Nov 2018 13:09:35 +0100

> "good performance on weak devices" and "interoperability with RFC-only

Is there any evidence that there are devices that can reasonably run Babel
and that are too weak to use SHA256 for protecting control traffic?

I don't have an ARM device handy right now, but a 450MHz MIPS 24Kc is able
to SHA256 on the order of 16MB/s.  That's 10000 full-size frames per second,
or on the order of 600000 Babel updates per second.

My suggestion is to implement whatever the list recommends (Blake2B or 2S)
in both BIRD and babeld, but to keep the status quo (SHA256 is MTI) in the spec.

-- Juliusz

---

From: Dave Taht <[email-masked]>
Date: Wed, 28 Nov 2018 08:51:16 -0800

> or on the order of 600000 Babel updates per second.

Sigh. Benchmarks. In particular I loathe benchmarks that do just one
small thing repeatedly, fully in i and dcache and claim "that's how fast
it is". No, you go and measure the impact on the total system, under a
real workload, changing whether you have hmac on or off, to draw a conclusion.

In the crypto case especially, people are really fond of 
large block sizes, and not fond of showing lots of very small
ones. startup overhead can be significant. It takes a really long time
to sha1 one byte.

Hardware crypto offloads for packets, from userspace, as another
example, are generally a lose, due to the kernel/userspace transition
required.

Lastly...

Routers *are* doing other things besides exchanging routes, like moving
packets around and dns, dhcp, and so on. Complex systems have emergent
properties that don't show up without "all up testing", which often
results in "RUD" - rapid unscheduled dissassembly. 

I already showed with the rtod experiments that a sufficient number of
routes can disable the dns and dhcp daemons, on a low end router.

Your typical low end router forwards packets until it runs out of cpu,
which is usually well below line rate. Processing packets locally eats
even more cpu.

We also tried in the last battlemesh we went at, to coax those trying to
measure convergence times to also measure them under heavy load. I don't
know if toke's preso on the second+ long delays that network experienced
fully registered (but we went off and fixed wifi regardless). I would
rather like to make battlemesh this year... with working hmac, unicast,
kick-arse wifi, and other whizbang new features and bugfixes.

...

I'm trying to redteam these ideas. If a given attacker hits me with
10,000 babel packets a second, unauthed, do I die? If I try valiantly to
verify these packets and fail, do I die sooner? If I figure out I'm
under attack from this particular box, can I blackhole all/most its packets
and move on, and not die at all? (RRL in bind is an example)

And honestly, all I'm pushing for at the moment is a way to do key
rotation, and it would be good to be able to have two algorithms to
evaluate. 

> in both BIRD and babeld, but to keep the status quo (SHA256 is MTI) in the spec.

I can live with that, but would prefer to have running code to deploy at
some scale, and measure.

---

From: David Schinazi <[email-masked]>
Date: Wed, 28 Nov 2018 09:41:23 -0800

> "good performance on weak devices" and "interoperability with RFC-only

Where are these "RFC-only implementations" of Babel?
Remember the IETF does not have a protocol police, MTI is purely guidance.
Implementors build what they (or their customers) need for their use-case.
Implementors will add Blake if they need it, not based on whether it's MTI
or not.
Lastly, remember that this is a security solution, so you do NOT want to
interoperate with a future theoretical implementation, because that will
not have the keys. Adding any new node in the network will require a
provisioning step, and that step ensures the new node supports the
required features.

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Wed, 28 Nov 2018 21:17:15 +0100

> Where are these "RFC-only implementations" of Babel?

Anyone who does a from-scratch implementation from the RFC, without
being part of the working group process, or looking at the existing
implementations.

> Remember the IETF does not have a protocol police, MTI is purely
> guidance. Implementors build what they (or their customers) need for
> their use-case. Implementors will add Blake if they need it, not based
> on whether it's MTI or not.

If it's MTI, they can't claim compliance with the RFC until it's in
there. So the "we need this box checked" type of product development
will benefit from this; and while sure, theoretically MTI is a hint,
it's a pretty strong one...

> Lastly, remember that this is a security solution, so you do NOT want
> to interoperate with a future theoretical implementation, because that
> will not have the keys. Adding any new node in the network will
> require a provisioning step, and that step ensures the new node
> supports the required features.

You can usually control the config, but not necessarily the features
implemented by the device...

-Toke

---

From: Dave Taht <[email-masked]>
Date: Wed, 28 Nov 2018 13:56:17 -0800

Have I been enough of a PITA this month?

Section 4 of rfc6126bis-07 states:

   Both the source and destination UDP port are set to a well-known port
   number.  A Babel packet MUST be silently ignored unless its source
   address is either a link-local IPv6 address or an IPv4 address
   belonging to the local network, and its source port is the well-known
   Babel port.

Aside from the fact that all versions of babel prior to now enforced
this requirement that the source and destination port numbers be the
same, which is a major consideration, that idea leaked into the hmac
implementation which does a:

  DO_HTONS(&port, (unsigned short)protocol_port);
  if ((err = blake2s_init_key(&S, key->len, key->value, BLAKE2S_DIGEST_LENGTH)) < 0) goto fail;
  /* Hash the pseudo header. */
  if ((err = blake2s_update(&S, src, 16)) < 0) goto fail;
  if ((err = blake2s_update(&S, &port, 2)) < 0) goto fail;
                                ^^^^^
  if ((err = blake2s_update(&S, dst, 16)) < 0) goto fail;
  if ((err = blake2s_update(&S, &port, 2)) < 0) goto fail;
                                ^^^^

the DTLS branch, on the other hand, mandates that ephemeral ports be
used for DTLS communications. Section 2.1 of
https://tools.ietf.org/html/draft-ietf-babel-dtls-02

   The node acting as DTLS client initiates its DTLS connection from an
   ephemeral UDP port.  Nodes SHOULD ensure that new client DTLS
   connections use different ephemeral ports from recently used
   connections to allow servers to differentiate between the new and old
   DTLS connections.

The rub, here, ultimately, is that I could see HMAC being used to
protect multicast and DTLS used to protect unicast, in which case,
allowing for ephemeral src ports generally in the bis version
would be helpful. I do not see how requiring a fixed src port helps
anything? (besides backward compatability)

Selfishly, I have to admit, that by using an ephemeral udp port for
route transfers and a different, either ephemeral or 6696 for hello/ihu
- fq_codel automagically distinguishes between these two very different
types of traffic and in congested network conditions will drop routes
far more often than hellos.

A backwards compatible mechanism would be to try hellos/ihus from an
ephemeral port and note when you don't get one back, upon starting an
association. A key indicator to other routers no longer respecting the
fixed src port rule would be recieving such.

...

As a side note, I had suggested using UDP-lite for development purposes
or dtls communications. It's easier to use a different protocol than it
is to get a new port number out of iana...

I was queried as to why udp-lite, and my answer that I never got around
to saying was that once you have an HMAC, you don't need a CRC, and
also, to my knowledge, udp-lite is very widely deployed, just not used.
It is the same in all other respects to udp. On a single hop over ipv6,
udp-lite "just works" on the versions of linux and bsd I've tried over
the past 5 years. It's impossible to compile out in linux (although
netfilter support for it can be), for example.

---

From: David Schinazi <[email-masked]>
Date: Wed, 28 Nov 2018 14:49:52 -0800

Hi Dave,

The Babel over DTLS spec states that
- unicast traffic is sent over DTLS, where DTLS client uses an ephemeral
port, and DTLS server uses a well-known port different from 6696
- multicast traffic still uses 6696 for source and destination

I don't see any issues with protecting Hellos with HMAC and everything else
with DTLS.

David

---

From: Dave Taht <[email-masked]>
Date: Wed, 28 Nov 2018 22:12:33 -0800

>> on whether it's MTI or not.

It is generally my experience that anything that's a MAY or
SHOULD... doesn't get implemented.

RIPEMD is an artifact of the original hmac RFC.

>> supports the required features.

Upgrading any old node to an alternate algorithm is considerably
more difficult. 2 HMAC algorithms with a different design history is
comforting.

---

From: Dave Taht <[email-masked]>
Date: Wed, 28 Nov 2018 22:14:07 -0800

Mahesh Jethanandani <[email-masked]> writes:

> A draft that proposed pair-wise key management was proposed here. It
> does not address the question of timestamp, but is something that
> could be exchanged as part of key rollover to allow routers to
> calculate the delta. Including the original authors of the draft.

I'm sorry but adding this level of complexity is not in the cards
from my perspective. Layering key exchange over a different out of band
medium, being a slip of paper, a telephone call, ssh or https seems
saner.

---

From: Dave Taht <[email-masked]>
Date: Wed, 28 Nov 2018 22:28:50 -0800

>> or on the order of 600000 Babel updates per second.

I've been meaning to poke into this a while:

https://code.fb.com/connectivity/open-r-open-routing-for-modern-networks/

But I do take your point. It would be good to know that on a given
10,000 route 200 router babel network that hashing overhead accounted
for .0X% of the 100% of cpu in use.

You are reasonable to assume that sha256 would be low overhead relative
to other factors, I think. Still, would like to go measure.

Aside: Where does the 300ms figure for re-attempting a challenge and
response come from?

---

From: Dave Taht <[email-masked]>
Date: Wed, 28 Nov 2018 22:33:22 -0800

David Schinazi <[email-masked]> writes:

> - unicast traffic is sent over DTLS, where DTLS client uses an
> ephemeral port, and DTLS server uses a well-known port different from
> 6696
> I don't see any issues with protecting Hellos with HMAC and everything
> else with DTLS.

Yes, the current spec will work. I was trying to solve a different
rate control problem by allowing ephemeral ports elsewhere.

a better method to negotiate a more relaxed approach to using ephemeral
ports, and not needed to be in the spec, either, would be to try an ack
request from an ephemeral port.

Has anyone put in for an official dtls port number from IANA?

---

From: Ted Lemon <[email-masked]>
Date: Thu, 29 Nov 2018 13:55:46 -0500

> medium, being a slip of paper, a telephone call, ssh or https seems

FWIW, for homenet the thought was to use HNCP to distribute keys amongst
routers.   This doesn't solve the general problem, but illustrates your
point, Dave, that this is something that can be provisioned out of band.
(In the HNCP case we're talking about public keys for DTLS, not shared
secrets, of course).   This seems like a better choice than a complicated
pairwise key management strategy for HMAC.

---

From: Markus Stenberg <[email-masked]>
Date: Fri, 30 Nov 2018 10:48:14 +0200

Here's some raw numbers (clickbait):

- my Macbook (sanity check)
- Turris Omnia (2016 highend)
- Buffalo WZR-600DHP (2012 midend)

https://github.com/fingon/go-hashperf

TL;DR (probably the interesting part):

2012 midend home router does 40 bytes:
- 37.5k pps of SHA256
- bit over 40k pps of Blake2B
- 91k pps of Blake2S

Setup overhead disappears both in SHA256 and Blake2 at ~500 byte mark (500 and 1200 bytes roughly equal MB/s); with 200 byte packets setup still wastes ~1/4 of performance (both SHA256 and Blake2) and even more with 40 byte packets.

With these numbers, I withdraw my support of including anything else than SHA256 as MTI. I think specifying Blake2B or 2S as well makes sense (mostly for crypto robustness reasons for having alternative that is specified) but making it MAY-SHOULD seems sensible to me.

The code is there, go ahead to test on your own routers if you care. I didn't bother testing arm64 in the end, as those are even faster than arm (the ridiculous blake2s number of 460k pps for Blake2s on Turris Omnia convinced me that it is not really worth it to test on faster hardware).

-Markus

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Fri, 30 Nov 2018 11:41:00 +0100

> - bit over 40k pps of Blake2B

That's is awesome, thanks for doing this!

> Setup overhead disappears both in SHA256 and Blake2 at ~500 byte mark
> (500 and 1200 bytes roughly equal MB/s); with 200 byte packets setup
> still wastes ~1/4 of performance (both SHA256 and Blake2) and even
> more with 40 byte packets.
>
> With these numbers, I withdraw my support of including anything else
> than SHA256 as MTI. I think specifying Blake2B or 2S as well makes
> sense (mostly for crypto robustness reasons for having alternative
> that is specified) but making it MAY-SHOULD seems sensible to me.

I can probably live with that :)

> The code is there, go ahead to test on your own routers if you care. I
> didn't bother testing arm64 in the end, as those are even faster than
> arm (the ridiculous blake2s number of 460k pps for Blake2s on Turris
> Omnia convinced me that it is not really worth it to test on faster
> hardware).

Yeah, 460k pps ought to be enough for everyone ;)

-Toke

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 30 Nov 2018 12:23:52 +0100

> I can probably live with that :)

Excellent, it looks like we're converging.  Thanks to both of you for the
informative and kind discussion.

At this stage, I see four possibilities:

  (1) leave the document as it is;
  (2) add a mention that implementation of Blake2S is RECOMMENDED (SHOULD);
  (3) add a mention that implementation of Blake2B is RECOMMENDED;
  (4) add a mention that implementation of both 2B and 2S is RECOMMENDED.

I am in favour of (1), since I am convinced that SHA256 is fast enough for
all reasonable devices.  (2) makes sense to me, and I won't oppose it.
I'll need some convincing in order to do (3) or (4), since Blake2B does
not appear bring any significant speed advantage over SHA256.

In either case, I'm planning to implement SHA256, Blake2B and Blake2S in
the reference implementation.

-- Juliusz

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Fri, 30 Nov 2018 14:22:44 +0100

> not appear bring any significant speed advantage over SHA256.

I'm in favour of (2).

> the reference implementation.

Cool. I'll do the same in Bird, then :)

-Toke

---

From: Markus Stenberg <[email-masked]>
Date: Fri, 30 Nov 2018 15:39:38 +0200

> On 30 Nov 2018, at 13.23, Juliusz Chroboczek <[email-masked]> wrote:

I do not actually recommend 2B based on the numbers. By looking at them, you notice that the setup time for 2B is higher and even on 64bit platform the gain is not insane even on large operations (25%ish, perhaps). -2BP is what I have and will recommend for large bulk hashing (-P variant allows for paralllelization of hashing to multiple cores), but for smaller stuff it seems Blake2S is faster on both 32 and 64bit.

As they are all based on same cryptographic base, it is likely that if weakness is found in one, it is present in others. That said, as BLAKE algorithm was at the time of SHA-3 contest analyzed to be strictly superior to SHA-2 in some features, it seems unlikely. But you never know.

The above discussion cuts out options 3 and 4 for me.

I am mostly indifferent between 1 and 2; SHA256 (especially with hardware acceleration) is probably faster than Blake (even with just Intel optimized assembler it is 60-70% of Blake 2B), and if we’re talking millions of pps (acceleration present) it is entirely academic anyway for a routing protocol. The tinfoil hat argument for 2 is that it provides fallback if SHA256 breaks down somehow in the future. So I have SLIGHT preference for 2 but am happy enough with 1 as well.

Cheers,

-Markus