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

[Sean Turner <[e-mail]>]

David,

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

spt

> On Feb 1, 2019, at 19:40, David Schinazi <[e-mail]> wrote:
> 
> 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 <[e-mail]> 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
>  
> 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
>