[Babel-users] hmac merge

[Dave Taht]

I'm willing (since I have that whole merge in my head still) - to try
to merge up hmac-challenge if that will help move things along. ?

Well, my take on it was that the hmac codebase was very difficult to
move forward
in its current state and needed a rebase on head for it to move forward. I'm
pretty good at hairy merges, and it only cost me half of fifth of
(admittedly good) vodka,
which I will try to extract from you the next time we meet.

I'm very keen on having authentication available as an option.

My principal worry is that it's going to be massively cpu intensive,
and here I am regularly blowing things up and measuring things a
lot...

I was pleased to see that armv8 and current intel processors have some
major sha1 instructions that speed up many benchmarks by 5x or more,
but mips... mips... sigh.

and ripe160, not so much.

I have not inspected the protocol much, what are the odds that all the
auth could be offloaded into the kernel (ebpf)

On Mon, Nov 12, 2018 at 7:52 AM Juliusz Chroboczek <jch at irif.fr> wrote:
>
> > In looking over the bird patch, it looks like I merged the wrong
> > thing.
>
> Yes, it looks like it.  hmac-challenge is the right code.
>
> Weronika, perhaps you could rename the branch hmac to something less
> exciting?
>
> Dave, please be aware that the HMAC code is not quite finished yet.  Once
> we got a working prototype, we focused on getting the protocol
> specification in time for IETF-102 and before the girls' internship ended.

Yep. My impression was that they had to move on and that they are no
longer on the project.

(a side note, in current modern american "politically correct" english
you can't use the word "girls" anymore. Ladies or Women. There's a
whole new generation of easily offended millenials that care. I left
the country in 2006 and came back to be lectured on this subject
multiple times. Even in spanish "chicas" is becoming verboten. I have
to reach for george carlin's wonderful riffs on the use of soft
language just to cope)

> In particular, we need to do some restructuring to current master (passing
> an interface pointer to a number of functions that lost access to the
> interface structure in the unicast refactoring) before we can merge HMAC.

I *think*, in the fixups in the merge, I had that covered.

>
> The following features are supported by the protocol but not by the
> implementation :
>
>   - graceful key rotation (ability to add/remove keys at runtime);

>From what I understand you need to be able to insert a key via the tcp
interface or config file
and retire a key over time (either with a hard deadline or after
everybody shifts over for long enough)

I was pleased that the recent dns key rollover worked so well. Still,
given how often things go down,
I can see it taking *months* before it would be safe to rotate a key.

>   - graceful deployment (ability to send signed packets but accept
>     unsigned ones).

yea, just hit that. :) I assume this would be a conf option, like "graceful"?

I still had a dream of being able to gradually shift a network over to
authed, or have authed and unauthed bits.



> > I do have one objection to the codebase, in that it pulls in
> > libgcrypt, ssl, and pthreads... about 5MB? of libs... for two hash
> > functions.
>
> Yeah, we should just include an implementation of SHA-256 in the code.

no RIPE?

>
> -- Juliusz
>
>


-- 

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