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

David Schinazi <dschinazi.ietf@gmail.com> Sat, 02 February 2019 00:40 UTC

Return-Path: <dschinazi.ietf@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49B3A1312DF; Fri, 1 Feb 2019 16:40:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43VpLKXu8oTz; Fri, 1 Feb 2019 16:40:32 -0800 (PST)
Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D95B91312B9; Fri, 1 Feb 2019 16:40:28 -0800 (PST)
Received: by mail-pg1-x52b.google.com with SMTP id z10so3704234pgp.7; Fri, 01 Feb 2019 16:40:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4/33flhkB2g5g3s5OE6Dk9pIHTV4ZtVQF4mlOlkcyIw=; b=HZyW3S9L9H1wQ5MH9tuvYs1BU2xnCPzbwi2WraQqfgKKuvlO/m2LeN6CVOgLH6lgTj xaoM6oQXOl42ohYPWjFdqzwFfru6zROin7V8MFyHDdDmQXko7UQxiZUm9zTAFOxvpmOQ VFvIH4GMTW5fYd64a1JTYQeW8D/M4pg3AZsFOphyTXR3G9Dyek1eKfr8ihOULyc/i5al mM5SVOfl3tl7ec9cepYUCN7p2r/shof//eZzOWLWZ9iW9ADCzmSqvS9fgmXECNAXA4F4 zpT28KtEGQcso8qblaXDPqIxjmbDrec1X7SJcUJ2VwcJFb3tp4k2jkQGH0hVQ/rGTNf5 dxtw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4/33flhkB2g5g3s5OE6Dk9pIHTV4ZtVQF4mlOlkcyIw=; b=q5pHxMEkHkqMkjboPoCGOAwfoeaPgYa2Q/b2cj5msLUzIB0PJEtfIj142StFBc+fna FrWmJelSsDYKxdX3lqbAggsiP6M028Ad0gK+CrN69ZcA5kU1NshqFmsErpOWuOGYPIiG /repdjkxuZGptZ6jzISGJRhZH0g3zW0SsYRsi4aqPwa1R35zJZUFYixvx1feGK9s8TvG 7kztvPadOuJRb2jETEsWYqY8/d3FMF9Y3UPNKAmLhL8SzOtazFoMTqLIa93Z8hoDwKOq CHCkktQn2zksUaBVO9AuVsbGTSaJZnbiKBL7oIJY97pVgHePN4Lgd+cWisavSVjOGauQ nU3A==
X-Gm-Message-State: AHQUAuaCdNpxfWkLljpM4HcWpQuT+cMla7j6cWNx3FwqvjWEt9T4LqeT 7KmuQdP23wucyKBBAZKjbLIEnExQEnfQStlxmaAh7lTR
X-Google-Smtp-Source: AHgI3IZbw1zapvNJ6/1yJd/Mn813XywLbDfxOFWc7zmus2nooyfDVXmbe7qHPVHUos/hV5ur9nb+zfRU6g8QQZf1Zdk=
X-Received: by 2002:a65:6099:: with SMTP id t25mr135342pgu.448.1549068028305; Fri, 01 Feb 2019 16:40:28 -0800 (PST)
MIME-Version: 1.0
References: <154881379920.7794.15439486195773911279@ietfa.amsl.com>
In-Reply-To: <154881379920.7794.15439486195773911279@ietfa.amsl.com>
From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Sat, 2 Feb 2019 09:40:17 +0900
Message-ID: <CAPDSy+6KNeNE1xifU4sONBZbmNJn_=QCZzHk0X-vu50T6zgfDw@mail.gmail.com>
To: Sean Turner <sean@sn3rd.com>
Cc: secdir@ietf.org, draft-ietf-babel-dtls.all@ietf.org, ietf@ietf.org, Babel at IETF <babel@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008f67190580de815e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/XrSfjtkwW2bokpzDl_kB2z3ZDbE>
Subject: Re: [secdir] Secdir early review of draft-ietf-babel-dtls-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 02 Feb 2019 00:40:41 -0000

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 <sean@sn3rd.com> 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
<https://tools.ietf.org/html/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
>
>