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

Donald Eastlake <> Wed, 06 February 2019 21:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 963BE130ECD; Wed, 6 Feb 2019 13:53:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QgycOMS8T2Zu; Wed, 6 Feb 2019 13:53:29 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A22D412D4F3; Wed, 6 Feb 2019 13:53:29 -0800 (PST)
Received: by with SMTP id v23so14716746otk.9; Wed, 06 Feb 2019 13:53:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aL3e9FlL4g1tQTHJ8bXBoWVMpBBe52/FdYjb6XiJpSU=; b=lw9wQHo/PVmPBUwBToZm0PgoMiTvsVEB2gbQ4T0FM8InRv3O/E5t+9uH4jPL68+xsk stet0LaxJBtFB6VdJh855nl3LT3jFUr8m3AAX8JvuoaAG7OkPv2Jl9+6Re/KcD4ojyaC PXFwYEUG9ScDfI8YwuJbsgnGpGNnu3AoVeOwHD+O5kzKbfxFc2vRP95uNrQSgEjiI/Mr jI4gk2p3AKurfekkaYMZ9RR7WlKcORthshDVTL6DlJ0Lytl4bdUdEw3O9CMBwxnHUug7 fJK9jIj5LF7T9+isIuYrB3VpciGGZq7ydjnFHTFyuF8y5Fw5g/YSPEvoibB/Uh/kRLlT LJNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aL3e9FlL4g1tQTHJ8bXBoWVMpBBe52/FdYjb6XiJpSU=; b=dKBcvzc7m+Yl0ttVbDH9nPLAIyvna2eYRacBZ5gs5fEAYBLLGa8Y0J+9G0bdUSv6Cb a0P7l8hw04jbMXFo1U3fa7djBOMF6Ydnq5kUfbQJ172+DLdknJ2YNLMhgdu9021HdQmE qmPvNzLAxyTVQAxC+3Le9bCsNoqlan7KFXI+5ryIM0VP6grUvJrCBFIqdsTO1bbLFjfc Uh72g4FUWog7wshY2WtRd+LDW98yqdW0EX+bzincS3/bYWMxlmXBdZprzvj8T5a4gvG8 bYVH/FYosqLc4VzUx5kDdkrZogzT526Wk59qZrVOb0UEZ0F1N42/wumvsX6R6FpW11gP Z7Xw==
X-Gm-Message-State: AHQUAuaN/Nm5bWYL2lIUUVQ9ipS6eovYLjBOgiOW5LKp+Bo9RjjECTLr Z+9z3mDR83/8SOgNPPoCtNfsWrsD2N2TdhbnOOU=
X-Google-Smtp-Source: AHgI3IZE1zeKkDDJ5BhPmU4dZh9dFTRG/m9WdNTeQP0UpD21mqRO5fDrWKhhwZZC2ZVzU3uKDxRVFPefIXjKD03ZxHE=
X-Received: by 2002:a54:4e95:: with SMTP id c21mr752379oiy.118.1549490008712; Wed, 06 Feb 2019 13:53:28 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Donald Eastlake <>
Date: Wed, 6 Feb 2019 16:53:16 -0500
Message-ID: <>
To: David Schinazi <>
Cc: Sean Turner <>,,, IETF Discussion <>, Babel at IETF <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [secdir] Secdir early review of draft-ietf-babel-dtls-03
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 06 Feb 2019 21:53:32 -0000


See below.

On Fri, Feb 1, 2019 at 7:40 PM David Schinazi <> wrote:
> Thanks for the review Sean!
> I've updated the doc with your comments:
> Detailed responses inline.
> David
> On Wed, Jan 30, 2019 at 11:03 AM Sean Turner <> 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...

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

>> Cheers,
>> spt
>> [0]
>> [1]