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

[Donald Eastlake <[e-mail]>]

Hi,

See below.

On Fri, Feb 1, 2019 at 7:40 PM 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.

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

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

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   [phone] (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 [e-mail]

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