Dear Denis,

Thank you very much for your kind mail.

Unfortunately, I think there might be some confusion:

  - DTLS is Stenberg-style security;
  - HMAC is Ovsienko-style security,
      - it has four variants (7298, 7298bis, DKC, Stenberg)
          - two of which have fatal flaws (7298 and 7298bis).

I am really sorry for causing confusion by using both DTLS and
Stenberg-style for what is the same thing, and for furthering this
confusion for using "Stenberg variant" for one variant of the HMAC
protocol.

> Another fact is, in early 2016 you were promoting the pre-IETF Babel
> work before and at the Babel BoF and claimed that besides the HMAC (then
> RFC 7298) approach to Babel security there was another viable
> alternative, namely, "Stenberg-style security". You were promoting the
> idea that the Babel WG should evaluate both mechanisms and choose the
> best.

> * Q1: Do you acknowledge these two facts and do you agree they are
>   directly related? (yes/no, please explain if "no")

Yes, besides HMAC I have been advocating DTLS, also known as
Stenberg-style security.  Markus Stenberg is a competent security
expert, and I always try to listen to his advice.

> The specification of "Stenberg-style security" for Babel was never
> published. It is June 2018 and I have never seen it, although I asked
> to.

It was presented at IETF 101 in March 2018 (at which you were present).
The draft lives here:

  https://github.com/jech/babel-drafts/tree/master/draft-decimo-babel-dtls

I am not an author.  Please ask the authors, not me, about why it hasn't
been published yet.

> * Q2: In 2016 did you know "Stenberg-style security" for Babel did not
>   exist as a workable WG item in the first place? (yes/no)

DTLS, also known as Stenberg-style security, has been implemented by
Antonin Décimo and independently reimplemented by David Schinazi during
the spring of 2018.  It took somewhat longer than expected, for various
reasons that are none of your business (such as Antonin wanting to pass
his exams).

> * Q3: Why were you promoting a WG option that either you didn't verify
>   exists in the first place (if "no" above) or you definitely knew does
>   not exist (if "yes" above)? Please explain.

I knew it didn't exist at the time.  I was confident we could make it
happen.  Antonin and David have made it happen, which shows that I was
right.

> At some point between 2016 and 2017 you stopped mentioning
> "Stenberg-style security" and began to promote DTLS for Babel
> security. The first "running code" prototypes (not implementations)

The two are the same thing.  Sorry again for the confusion.

> * Q4: In 2016-2018 did you know a specification for the "DTLS" Babel
>   security did not exist as a workable WG item? (yes/no)

Stenberg-style security and DTLS are the same thing, so my answer to Q2
applies.

> * Q5: same as Q3

Stenberg-style security and DTLS are the same thing, so my answer to Q3
applies.

> * Q6: Do you agree your long-time presenting effort had created and
>   maintained an impression that the "alternative" security option was
>   viable and workable by the Babel WG, regardless of its actual status
>   at the time? (yes/no, please explain if "no")

Yes, I did believe that DTLS was viable, and did my best to communicate
this fact to the list.  As explained in my answer to Q2 above, I maintain
that I was right.

> * Q7: If "yes" to Q6, was this impression what you intentionally were
>   trying to achieve? (yes/no, please explain if "no")

Yes.

> * Q8: If "yes" to Q6, do you agree this impression has been influencing
>   decision making in both Babel and Homenet WGs? (yes/no, please explain
>   if "no")

I do not know.  Please ask the WG participants.

> * Q9: Do you agree the end effect was that the work on HMAC Babel
>   security was held back in the Babel WG? (yes/no, please explain if
>   "no")

No.  I have been actively promoting the HMAC work ("Ovsienko-style"), just
as I have been promoting the DTLS work ("Stenberg-style").

The HMAC work has been held up because 7298bis had fatal flaws.

> * Q10: After the WG decision about HMAC (which was in line with your
>   latest position at the time) are you still maintaining that choosing
>   between HMAC and DTLS would benefit the Babel WG? (yes/no, please
>   explain if "yes")

I would like see both HMAC and DTLS published as Standards Track
documents.  It will be a lot of work, but I am confident that we will
manage it.

I would prefer that we didn't choose between the two -- I want to have
both.  As stated publicly at the microphone at IETF 101 in London, should
we be forced to choose, I would support HMAC.  Of course, I may change my
opinion in the future, it depends on how HMAC and DTLS will develop.

> * Q11: If "no", could you explain why did not you denounce the idea on
>   the mailing list with appropriate comments?

I do not understand the question.  It is not my role to "denounce"
anything or anyone, I merely express my opinions, just like any other WG
member.

> * Q12: Do you agree, in the sense of your own long time "DTLS or HMAC"
>   idea and the claimed viability of DTLS, that the most consistent next
>   step would be to work towards the adoption of a DTLS Babel security
>   mechanism document? (yes/no, please explain if "no")

The DTLS draft hasn't been published yet (by no fault of mine), so it is
premature to discuss its adoption.  I am doing my best to push for its
publication in time for Montréal.

> * Q13: If "yes", could you explain in detail why you started to draw so
>   much attention to HMAC after the WG decision and do not bring up DTLS
>   anymore?

We (me and two students) have spent the last month working on HMAC.
I have been trying my best to share our work with the list, which
I believe is acceptable procedure.  Please describe your complaint
precisely.

> * Q14: Could you clarify in proper technical terms what exact technical
>   problem you suddenly started to solve and why?

There are two serious technical issues with rfc7298:

  - it is vulnerable to replay, as described in my mail of 10 May 2018;
  - it blackholes a peer after it loses its state, up to ANMTimeout.

Both of these problems are believed to be solved by our current HMAC work,
which is being debugged right now.  We intend to write it down as soon as
we've pushed the code to github, but we cannot make any promises since the
Montréal cutoff date is very soon.

> I have a few more pending comments to make on your older messages,
> including outstanding non-security technical issues in the Babel WG
> documents. I hope to send them separately later.

I am always happy to listen to your advice.  Please be aware that we are
working really hard right now to get the HMAC work published before
Monday's cutoff date, and therefore I might not reply straight away.

Regards,

-- Juliusz

_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Reply via email to