Re: [sidr] wglc for draft-ietf-sidr-adverse-actions-00

Christopher Morrow <morrowc.lists@gmail.com> Tue, 25 October 2016 15:03 UTC

Return-Path: <christopher.morrow@gmail.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 818351296A9; Tue, 25 Oct 2016 08:03:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 1RwVpgtAF3OA; Tue, 25 Oct 2016 08:03:03 -0700 (PDT)
Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (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 9B8731296B2; Tue, 25 Oct 2016 08:03:03 -0700 (PDT)
Received: by mail-qk0-x235.google.com with SMTP id o68so262290586qkf.3; Tue, 25 Oct 2016 08:03:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=sgTZNXtyuvkwmXi7tyLcF9lW1xhVtibK7WAxc8wCKrQ=; b=ZocR4tEzaI/6qEEAVKXlpGlWElB5zxHyCTMec/afvaLd9TaBYkm3hRe5iK5B7y6fRJ Gj2HafCQ4QUPTyCMINckLCSDWvSsbfmIiNNUq5YOEgV2y8Occygep3UbFiueRdEL2bHB 76+SVzwcGm7sLgKc5TQfb/Ah3G/NlmtZPRbbVLjZUaAEuUdU/wf68zyNyow6ij1NCaeA u495eWlnEn97Qbez3poDeKJasv95CAudAB/xgUqe8QQtsXCgTo2tUT7Fe8LaJzhglY0V bGs1iFyAEiI/Wy4VodnnRKWo1yS1amMXBGhGwOpb1PnuTuTqGQkSjWV71uXYltAm+l23 Vz9Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=sgTZNXtyuvkwmXi7tyLcF9lW1xhVtibK7WAxc8wCKrQ=; b=Rin6/Fby8iP01i8uP/FwuJOTaQCltkEHCFZpjVvEo4Cmf1k3lg79q19ljg9F74rH5F DfHa4h5jRFIhQLQQX0Oo7OKiM/V+ixxr122Z+nWqQDBT36SK612DPTdodZuBJ15AvJWA 82EMqmd8uglBbbqGOeWJwVjdNi9HD2VRcIGEq2iQhi0mAURgQIz1T2bd6JoAb/Qb/cZL K4AwHQG1CyEJyhSWP8N2LHyW1QRj23uTaSClIS3fig0CcjvjlOBY+oXymVixdXZk8lTS 7VOHQAWnVXnF3esXw7b1kHwlr2I2DQSLemuxmVCBtGnT6EvFm8quy67fcDoHOSpObLBR 44nw==
X-Gm-Message-State: ABUngvfEy3j2dEVz5fIETMMmYc5aU2B3XTgTz79fXhkQhJsFdgAtrzc8oBCEofLKGoQDFH/SICgH+nadeQq2lg==
X-Received: by 10.55.3.140 with SMTP id 134mr22303065qkd.65.1477407782450; Tue, 25 Oct 2016 08:03:02 -0700 (PDT)
MIME-Version: 1.0
Sender: christopher.morrow@gmail.com
Received: by 10.140.105.244 with HTTP; Tue, 25 Oct 2016 08:03:01 -0700 (PDT)
In-Reply-To: <99a31951-b095-eaee-0c44-9358ce2d989a@bbn.com>
References: <8E32FD39-FD20-455C-8BEC-5752DE9C8531@tislabs.com> <DC08C8ED-E611-4D95-A557-3EE74633F9A4@ripe.net> <99a31951-b095-eaee-0c44-9358ce2d989a@bbn.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
Date: Tue, 25 Oct 2016 11:03:01 -0400
X-Google-Sender-Auth: RYP6oMd9wg0MQYQx6B2pyl-nDLo
Message-ID: <CAL9jLaZK_Bv93PHrSLbG96_HigLU9wcojRMjBp-f+Vexrbfa8Q@mail.gmail.com>
To: "sidr@ietf.org" <sidr@ietf.org>
Content-Type: multipart/alternative; boundary=001a114c99680fc658053fb1ce61
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/1xTTodVvkRnmW-h2OuhsdzMceBU>
Cc: "sidr-chairs@ietf.org" <sidr-chairs@ietf.org>, "sidr-ads@tools.ietf.org" <sidr-ads@tools.ietf.org>
Subject: Re: [sidr] wglc for draft-ietf-sidr-adverse-actions-00
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Oct 2016 15:03:08 -0000

Howdy folks!
This WGLC ended up being a bit more of a long discussion than I
anticipated... I think since this WGLC there have been 2 document updates
to catch comments/concerns/etc and I think deal with them properly.

I don't see anymore chatter for this document after 9/2/2016, so I think we
should move this document forward to IESG.. I'll be sending along a pub
request today.

-chris

On Tue, Jul 19, 2016 at 10:00 AM, Stephen Kent <kent@bbn.com> wrote:

> Tim,
>
>
>
> Thanks for taking the time to read and comment on the document.
>
>
>
> I will change CA certificate analysis to be section 2.1, and make the CRL
> section b 2.3, as per your request. The Manifest section will remain 2.2,
> ROAs will become 2.4, GB will become 2.5, and Router Certificates will
> remain 2.6. This will require a lot of changes to the pointers within and
> between sections, but we aim to please :-).
>
>
>
> A-5.4.1: I agree that reducing the set of  resources in a CA certificate
> may be done for legitimate reasons, even if the INR holder does not agree
> with the reduction. Nonetheless, this is an adverse action from the
> perspective of the INR holder. It’s important to note that there are cases
> when this reduction is the result of an attack against or an error by the
> parent CA. Thus I believe it is important to retain this action in the
> list.
>
>
>
>
>
> A-5.4.2: I’ll delete this action.
>
>
>
> A-5.4.5: I agree that this may be hard to distinguish from a legitimate
> key rollover, except that a key rollover would have both old and new CA
> keys present simultaneously. I’ll add a note to this effect.
>
>
>
> I disagree with your suggestion that we remove the modification,
> revocation, and injection actions for Manifests, ROAs, and Router
> Certificates. First, remember that adverse actions include errors by CAs,
> and transient attacks against CAs. In the former case the private key is
> clearly available and the CA may also control the repository. In the latter
> case note that an attacker need not need learn the private key’s value;
> he/she needs only the ability to cause an HSM to use the key. Also, an
> attacker need not control the repository to effect these actions; an RP
> might be misdirected to a different set of files via a routing system
> attack (ironic?) or a DNS attack.
>
>
>
> Recall that the goal of this document is to document, as best we can, a
> wide range of actions that are adverse, irrespective of whether we can
> prevent or detect such actions. Your message noted that RRDP may make it
> easier for RPs to detect some of these actions; I suggest you add
> references to the relevant sections of this document as further motivation
> for transitioning to RRDP.
>
>
>
> Finally, when we revised an earlier version of the document we decided to
> include every action in the same order in each section (except for GB
> records, where it would be trivial), to make it easier for a reader to see
> that we were addressing the same issues for each object.
>
> Steve
>
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>
>