Re: [Sidrops] Martin Vigoureux's No Objection on draft-ietf-sidrops-rtr-keying-03: (with COMMENT)

Sean Turner <sean@sn3rd.com> Wed, 13 February 2019 02:26 UTC

Return-Path: <sean@sn3rd.com>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B877130E2E for <sidrops@ietfa.amsl.com>; Tue, 12 Feb 2019 18:26:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 JnTNToZUAUeu for <sidrops@ietfa.amsl.com>; Tue, 12 Feb 2019 18:26:07 -0800 (PST)
Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 735FC130EE1 for <sidrops@ietf.org>; Tue, 12 Feb 2019 18:26:04 -0800 (PST)
Received: by mail-qk1-x729.google.com with SMTP id m9so498101qkl.4 for <sidrops@ietf.org>; Tue, 12 Feb 2019 18:26:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dl7yb0gpGA/pgQiz+GiO2xlLtYF1WaGJV4xpKP+s5Gw=; b=Pgx/PS9LGwEWskesPOFNZL8WSaeuDcfCv+XQt0RadhLrEyaJe9fEy2oDSWnA8QMtAE Y3peF4qV1zcp+PiUxLmglPImCK5FoQ39byX5XduXB7YyMZkSNT8kdzs9iQvBu8Ovf8Gk avjJ4rQO5kNfNldv46qSX5QziPG/OyEzlOpWA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dl7yb0gpGA/pgQiz+GiO2xlLtYF1WaGJV4xpKP+s5Gw=; b=UCP1C0MtRvQmCxkad6sHMPxqTD9nBHByjq66ZczUhtfbPoZkCyBMpgwXATehvk2MVu uYsdML6W2jXS81zpUW+a2nAhIeF/YaQFqWYNqeYP5V0yewc/PlApU8y5528aZQLCGTWl yFtxa88hhh46NLvk6g+f0uHzKw2xSb7bbOfjdvD8DOFdqYnV1C06nMKcXtiQ3e3P6HtR gh/nrOnHCF5zP4NGKJxbCwH6Tg0f5dzKwAbZ34Q8BqqKecUdAkFbEDLYPt30svtl+JZQ HtmYqWCVBTA4qGTu0St6OseGoFCdcPdFHjd0dESN3AqFq+bhIizCzOmC4go5A8bIkQJS PH+g==
X-Gm-Message-State: AHQUAua4BpQbwG+9utzI8k2mMr2V9ruTYxix/MmLwWcfwvv0ugdIdUZy zDX3YNx4eni3wiO4SIx5t+UMDg==
X-Google-Smtp-Source: AHgI3IZc7O/Tm7KAWTJG9Kik+wQlrAeYkIFFN/xbDgSiCrP6eGnsXYPsOY5cOuq7ohlOwIZRHQRMXQ==
X-Received: by 2002:a37:cf56:: with SMTP id e83mr1690510qkj.101.1550024763451; Tue, 12 Feb 2019 18:26:03 -0800 (PST)
Received: from [172.16.0.18] ([96.231.217.246]) by smtp.gmail.com with ESMTPSA id b22sm8339880qtc.23.2019.02.12.18.26.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Feb 2019 18:26:02 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Sean Turner <sean@sn3rd.com>
In-Reply-To: <154833578539.25088.8998015406968018020.idtracker@ietfa.amsl.com>
Date: Tue, 12 Feb 2019 21:26:02 -0500
Cc: The IESG <iesg@ietf.org>, draft-ietf-sidrops-rtr-keying@ietf.org, Chris Morrow <morrowc@ops-netman.net>, sidrops-chairs@ietf.org, sidrops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <69FC2470-F679-4911-A8DB-6A0518FE87B0@sn3rd.com>
References: <154833578539.25088.8998015406968018020.idtracker@ietfa.amsl.com>
To: Martin Vigoureux <martin.vigoureux@nokia.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/sWC5dGYpP-Sm1Xu9DCVGwG3oZmc>
Subject: Re: [Sidrops] Martin Vigoureux's No Objection on draft-ietf-sidrops-rtr-keying-03: (with COMMENT)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Feb 2019 02:26:15 -0000


> On Jan 24, 2019, at 08:16, Martin Vigoureux <martin.vigoureux@nokia.com> wrote:
> 
> Martin Vigoureux has entered the following ballot position for
> draft-ietf-sidrops-rtr-keying-03: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-sidrops-rtr-keying/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Hello,
> 
> thank you for this Document.
> I only have a couple of questions:
> 
>  In the operator-generated method, the operator SHOULD extract the
>  certificate from the PKCS#7 certs-only message, and verify that the
>  private key it holds corresponds to the returned public key.
> 
>  The router SHOULD extract the certificate from the PKCS#7 certs-only
>  message and verify that the public key corresponds to the stored
>  private key.
> 
> I believe SHOULD applies to extract and to verify, correct?
> But I wonder why isn't that a MUST, or asked differently, what could happen
> wrong if that verification was not done?
> 
> Thank you

Yes.  This is kind of a sanctity check before the router starts signing things.  If the CA/operator somehow blows it and returns the wrong certificate the router will catch this mistake.  If CA/operator somehow blows it and returns the wrong certificate (and never actually posts the right one) and the router doesn’t do this check then relying parties will not be able to verify the BGPsec messages.  It’s kind of like be good to neighbors ;). It’s really why it’s a SHOULD and not a MUST.

spt