Early Review of draft-ietf-babel-dtls-03

Request Review of draft-ietf-babel-dtls
Requested rev. no specific revision (document currently at 10)
Type Early Review
Team Security Area Directorate (secdir)
Deadline 2018-11-25
Requested 2018-10-23
Requested by Donald Eastlake
Authors Antonin D├ęcimo, David Schinazi, Juliusz Chroboczek
Draft last updated 2019-01-29
Completed reviews Rtgdir Early review of -00 by Tony Przygienda (diff)
Secdir Early review of -03 by Sean Turner (diff)
Rtgdir Last Call review of -06 by Henning Rogge (diff)
Genart Last Call review of -05 by Dan Romascanu (diff)
Secdir Last Call review of -07 by Sean Turner (diff)
This is a fairly short draft. It would be nifty if it could be reviewed before the BABEL WG meeting Wednesday afternoon in Bangkok but I realize that is an unreasonably short time so have set a more relaxed deadline.
Assignment Reviewer Sean Turner 
State Completed
Review review-ietf-babel-dtls-03-secdir-early-turner-2019-01-29
Reviewed rev. 03 (document currently at 10)
Review result Has Nits
Review completed: 2019-01-29



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.

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.

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].

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 ;)

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

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)?

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

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


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