Dave Taht writes:
> On Mon, Nov 26, 2018 at 1:10 PM Toke Høiland-Jørgensen wrote:
>>
>> Dave Taht writes:
>>
>> > 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,
On Mon, Nov 26, 2018 at 1:10 PM Toke Høiland-Jørgensen wrote:
>
> Dave Taht writes:
>
> > 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,
>
> The Babel HMAC
"STARK, BARBARA H" writes:
> 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
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
> 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
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),
Markus Stenberg writes:
> On 26 Nov 2018, at 15.46, Juliusz Chroboczek wrote:
>>> 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...
>>
> 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?
___
Babel-users mailing list
Juliusz Chroboczek writes:
>> 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.
>
>
> 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.
From a standardisation point of
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
My followup just created a FOR_ALL_INTERFACES_UP macro which led to
even less code. :)
Elsewhere I've been dithering. The proof of concept for uthash in
resend, was quite satisfying but far too much unneeded overhead (56
bytes per entry on 64 bits!! + the malloc overhead!), so I have been
looking
Hi Dave,
we could get away with dropping the continue statement altogether and
keeping the comparison as it is. This looks a little clearer to me.
Based on you work, please find below my suggestion
Cheers
Christof
---
message.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
13 matches
Mail list logo
