Subject: Re: [babel] Secdir early review of draft-ietf-babel-dtls-03

From: David Schinazi <[email-masked]>
Date: Sat, 2 Feb 2019 09:40:17 +0900

Thanks for the review Sean!

I've updated the doc with your comments:
https://github.com/jech/babel-drafts/commit/e202f664712772a4db2bd88c5665ba3193cd4c99

Detailed responses inline.

David

On Wed, Jan 30, 2019 at 11:03 AM Sean Turner <[email-masked]> wrote:

> Reviewer: Sean Turner
> Review result: Has Nits
>
> Hi,
>
> David wanted to make it really easy on me and get as much early input as he
> could get by sending a msg to the TLS list asking for comments [0].
> Version
> -02 addressed those comments.
>
> I'm no babel expert, but I did take the time to read/skim the base protocol
> document to get more familiar with it as well as re-read the babel-tls
> draft.
> The tl;dr here is that babel is multicast but DTLS is not so changes to
> babel
> are needed.
>

To clarify, the changes to make Babel work over unicast have all gone into
the base spec: draft-ietf-babel-rfc6126bis
<https://tools.ietf.org/html/draft-ietf-babel-rfc6126bis>

> Here are my comments in no particular order.  No show stoppers here.
>
> 0) Since DTLS is in the RFC Editor's Abbreviations List - I think you can
> get
> away with: Babel Routing Protocol over DTLS But, that's up to you.
>

I personally prefer spelling it out, but I don't feel too strongly about it.

> 1) (IEGS food fight alert) I see that the updates header updates 6126bis.
> Not
> sure how this will fly in the face of the draft IESG Statement [1].
>

Thanks for pointing this out. We'll follow any guidance the IESG gives us
during their review.

> 2) (This might just be document organization) The applicability section
> kind of
> jumped out at me because there's also an applicability draft.  Further, it
> and
> 6126bis says the HMAC mechanism is preferred.  I'd just drop the entire
> section
> ;)
>

The authors felt we should insist that HMAC is better suited for many
deployments
as it better fits with the traditional Babel multicast model. The
applicability draft
focuses on Babel itself.

> 3) s2.1 - maybe add a pointer to the IANA considerations section.
>

Done

4) s2.1 - Because you're doing client authentication do you need say
> anything
> about the type of cert, whether certificate_authorities,
> signature_algorithms_cert, signature_algorithms should be sent (for 1.3
> connections)?
>

We've had this conversation on the Babel mailing list, and we landed on
having the
babel-dtls draft not define any of these, punting that to the usage
profiles drafts.
For example, the Babel Homenet profile draft will define all of these.

> 5) s4 - add that IANA is requested to point to this specification for the
> reference.
>

Done

6) AppA - I think you might need to tweak the last sentence in light 1.3?

Unfortunately DTLS 1.3 hasn't been published yet, and I'd rather not make
assumptions on what the RFC will say (even though we're pretty sure the
handshake won't change between the current draft and RFC). If it gets
published as RFC before this document does, I'll make these changes.

Cheers,
> spt
>
> [0] https://mailarchive.ietf.org/arch/msg/tls/tIaK0rgm5zCVuYmLm5qsCIvKXKw
> [1] https://mailarchive.ietf.org/arch/msg/ietf/-1u_1-peHKAmUDuLyGAJYu0fPCE
>
>

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 02 Feb 2019 02:17:52 +0100

> Unfortunately DTLS 1.3 hasn't been published yet,

May I most humbly request an explanation?  Is that about TLS False Start
being made obsolete by TLS 1.3?

(Note that I'm not particularly convinced about this paragraph, since
I don't think that paying one extra RTT at neighbour acquisition is at all
prohibitive.)

-- Juliusz

---

From: David Schinazi <[email-masked]>
Date: Sat, 2 Feb 2019 10:24:10 +0900

Hi Juliusz,

TLS 1.3 changed the handshake, making false start irrelevant.
In 1.3, the first flight of server-client packets contains the Finished
message,
so there is no opportunity to start early as there is in 1.2.

https://tools.ietf.org/html/rfc6347#section-4.2.4
https://tools.ietf.org/html/draft-ietf-tls-dtls13-30#section-5.6

David

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 6 Feb 2019 16:53:16 -0500

Hi,

See below.

On Fri, Feb 1, 2019 at 7:40 PM David Schinazi <[email-masked]> wrote:
>> could get by sending a msg to the TLS list asking for comments [0].  Version
>> document to get more familiar with it as well as re-read the babel-tls draft.
>> The tl;dr here is that babel is multicast but DTLS is not so changes to babel
>> are needed.
>
>> 0) Since DTLS is in the RFC Editor's Abbreviations List - I think you can get

While my feeling is not that strong, I also favor spelling it out.

>> 1) (IEGS food fight alert) I see that the updates header updates 6126bis.  Not

I think this draft should not say that it updates 6126bis. However, I
am of that opinion not because of IESG policy but because 6126bis
normatively references this draft; therefore, readers of 6261bis will
be automatically directed to the RFC this draft become when published.

>> 2) (This might just be document organization) The applicability section kind of
>> jumped out at me because there's also an applicability draft.  Further, it and
>> 6126bis says the HMAC mechanism is preferred.  I'd just drop the entire section
>> ;)
>
> The authors felt we should insist that HMAC is better suited for many deployments
> as it better fits with the traditional Babel multicast model. The applicability draft
> focuses on Babel itself.
>
>> 4) s2.1 - Because you're doing client authentication do you need say anything
> We've had this conversation on the Babel mailing list, and we landed on having the
> babel-dtls draft not define any of these, punting that to the usage profiles drafts.

Given the advanced state of the DTLS 1.3 draft in the IETF process, I
suggest consideration be given to referencing that draft rather than
RFC 6347 and making corresponding minor changes in this draft...

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 [email-masked]

---

From: Sean Turner <[email-masked]>
Date: Wed, 6 Feb 2019 18:29:02 -0500

David,

Thanks for following up.  I am personally happy with your suggested resolutions.

spt

> On Feb 1, 2019, at 19:40, David Schinazi <[email-masked]> wrote:
>

---

From: David Schinazi <[email-masked]>
Date: Wed, 6 Feb 2019 15:53:39 -0800

Thanks Donald and Sean.

> RFC 6347 and making corresponding minor changes in this draft...

I'd rather not create a blocking relationship at this point in time.
I personally commit that when babel-dtls makes it to AUTH48, if DTLS 1.3 is
published then I'll make the changes to babel-dtls to reference it.

Thanks,
David