Re: [babel] Roman Danyliw's Discuss on draft-ietf-babel-dtls-07: (with DISCUSS and COMMENT)

[Roman Danyliw <[e-mail]>]

Hi David!

From: David Schinazi [mailto:[e-mail]]
Sent: Friday, August 9, 2019 7:40 PM
To: Roman Danyliw <[e-mail]>
Cc: The IESG <[e-mail]>; [e-mail]; Donald Eastlake <[e-mail]>; babel-chairs <[e-mail]>; Babel at IETF <[e-mail]>
Subject: Re: Roman Danyliw's Discuss on draft-ietf-babel-dtls-07: (with DISCUSS and COMMENT)

We've now submitted -08 which contains the changes discussed below.

Thanks,
David

On Thu, Aug 8, 2019 at 5:44 PM David Schinazi <[e-mail]<mailto:[e-mail]>> wrote:
Thanks for your review Roman! We've made changes on our git repository
<https://github.com/jech/babel-drafts> and will submit a revised draft shortly.

Detailed responses inline.

Thanks,
David

On Wed, Aug 7, 2019 at 12:26 PM Roman Danyliw via Datatracker <[e-mail]<mailto:[e-mail]>> wrote:
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(1) Section 1. These are different than the ones listed in Section 6 of
draft-ietf-babel-rfc6126bis and Section 1 of draft-ietf-babel-dtls.  As DTLS
and HMAC are mitigations for attacks in draft-ietf-babel-rfc6126bis, they
really should be harmonized.

We've fleshed out the text in draft-ietf-babel-rfc6126bis and kept the reference
in draft-ietf-babel-dtls.

(2) Section 2.1.  Per “Implementations MUST support authenticating peers
against a local store of credentials”, what does that credentialing look like?
Is it certificates, PSK, etc?  What validation procedure is being used for this
authentication?

I'll respond to this point on Ben's DISCUSS since I think you're both asking
for the same thing.

[Roman] Concur that Ben and I are raising the same concern.  I appreciate the explanation you provided in:

https://mailarchive.ietf.org/arch/msg/babel/HuoEG7HG_rSfs3rCFZo2ZYdCl_I

Ben’s recommendation to explicitly note that this authentication needs to be solved in external profiles would address my concern too:

https://mailarchive.ietf.org/arch/msg/babel/5AnLlaHPTEsBJpV7WVrZLpw07ls

(I don’t know if you were waiting on Ben for anything else, but …) I didn’t see this discussion about profiles in the new -08 text.



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(3) Abstract.  Per “Babel does not contain any means … [to] protect messages”,
be more precise in the definition of protect (i.e., integrity and
confidentiality)

Agreed, fixed.

(4) Section 1.2.  Per “A comparison of Babel security mechanisms and their
applicability can be found in [RFC6126bis]”, where in
draft-ietf-babel-rfc6126bis does this comparison occur.  The references to HMAC
and TLS are in a single paragraph in in Section 6/Security Considerations which
roughly reiterate the one sentence statements written here.

We've fleshed out the text in draft-ietf-babel-rfc6126bis and kept the reference
in draft-ietf-babel-dtls.

(5) Section 2.1.  Per “When a node receives a new DTLS connection, it MUST
verify that the source IP address is an IPv6 link-local address …”, what
happens if IPv4 is in use?

This was an oversight. The text now also discusses IPv4.

(6) Section 2.1. Per “Nodes MUST only negotiate DTLS version 1.2 or higher”,
this is stricter than RFC7525 cited in the Security Consideration later in the
draft.  That’s fine, but please reiterate that in Section 5.

Done.

(7) Section 2.6  Suggest being clearer that this is a deployment not an
implementation issue. s/Implementations<http://s/Implementations> MAY implement both Babel over DTLS and
unprotected Babel./ /A node MAY run both Babel over DTLS and unprotected Babel./

Agreed. We added your new sentence but also kept the old one since both are true.

(8) Section 2.6, Per “However, accepting unprotected Babel packets … loses the
security properties of Babel over DTLS”.  This seems misleading.  The security
properties of “Babel over DTLS” as a protocol are stated in Section 1.2.  In
this section there is discussion of the security properties of the node (and
the resulting neighbor table).  These are different.  The issue seems to be
that a node is building a neighbor table with updates from sources which need
to be trusted to different degrees.

Agreed. We've reworked that paragraph.

(9) Section 5.  Per “Confidential interaction between two Babel peers requires
Datagram Transport Layer Security (DTLS) with a cipher suite offering
confidentiality protection.  The guidance given in [RFC7525] MUST be followed
to avoid attacks on DTLS.”, the first sentence is true, but incomplete, in that
we’d also want cipher suites with a strong key exchange algorithm, etc.
Section 4.2 of RFC7525, which is cited as a MUST, provides a list of
recommended ciphers suites.  Do we need this first sentence?

Fair enough, We've removed that sentence.

(10) Editorial
-- Section 2.1.  Expand “IHU” on first use

Done

-- Section 3.  Nit. s/ciphers/ciphersuites/<http://s/ciphers/ciphersuites/>

Done

[Roman] Thanks for all of the changes above!

Regards,
Roman