Re: [DNSOP] The DNSOP WG has placed draft-mglt-dnsop-dnssec-validator-requirements in state "Call For Adoption By WG Issued"

Daniel Migault <mglt.ietf@gmail.com> Wed, 06 May 2020 16:16 UTC

Return-Path: <mglt.ietf@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2A53A0BBF for <dnsop@ietfa.amsl.com>; Wed, 6 May 2020 09:16:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Dim7JYjehDCd for <dnsop@ietfa.amsl.com>; Wed, 6 May 2020 09:16:15 -0700 (PDT)
Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (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 AF2DF3A0BE3 for <dnsop@ietf.org>; Wed, 6 May 2020 09:16:08 -0700 (PDT)
Received: by mail-ua1-x92c.google.com with SMTP id i5so714099uaq.1 for <dnsop@ietf.org>; Wed, 06 May 2020 09:16:08 -0700 (PDT)
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=euyeWDkf8YQisTqtEfVurQ4zV4pSNP4ImBvYQN2HjyA=; b=N2ZkgdMyizkcnOKO5/S2FOQrrvd6ExdS1xj0a4kfPXMqgKUvrRb3Cwg9Ti1iM191wd DdPnt4wKQei2qB0LiWYPgvqxKUGI2BGaYx7nTn6yFNOdXm7Jsyn3FDqNoBD5FWSdOQg2 L3kaFntWujDuEFmlwZgisApPdG5iZbUxOLM9qYe4FKXM1zsi0FweT7+zPJrkDfarFMBi d/grfoglk7YMvRMLiUtDiwWXo4n6sgdpvVFBVlwx2sfeWL3VRrb2lHu3tKxbPSO3o/D5 pI0vk7OFYLCRTya2tgD94OdNh5Cmkiq4ISxBqLHjPpaDxrpm4raT3UfbiYpUHbnsz9v6 Q6OQ==
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=euyeWDkf8YQisTqtEfVurQ4zV4pSNP4ImBvYQN2HjyA=; b=s/0LkhHqv3saqDjcD7KyTcYmTFPhOwhjU2GsD0XY+gZoR81I92HBae7xskAzVXH173 aFosJXFZBXcwB734vNj2vuAkIJVJYOVMV5BlC77LmVI5/eKTGDMkMcKPLNmMxWDxT8O/ Z/tkryw5q5bgelM1icZcN9JlfgqbmF5A/uqG8Okswe3MCi2oGKRtO7ioqcXOMlCH1ri7 v96UHzRjA35bcX6m5dC8u3pSUeYwCrocD/VgvkbCT7QVEKrZ2IZ1c1nobsPMtId1LSbR fu48p2CqiedfoEpEhLcWvT0SOxWu5WPWexPHhrr0LabWjjYFWSsPH1Dwn17b/NaImC9X ZXOA==
X-Gm-Message-State: AGi0PuaIx8oSq9074alucLDgZLcX7JbBixp0LLdvZBOppaXnVvJuzFe4 CQgG5E960Av4IXA5aDVo75VZ2fJTBEZpyY7X/kU=
X-Google-Smtp-Source: APiQypKgU7fZ6cdWXTeOgUt54Rr6NcSmh96KStX+Wx5FIG/2LYfHPAcELFnzEUhg6dlmir557tWuLwIi+F8eVv/0hL8=
X-Received: by 2002:a9f:222c:: with SMTP id 41mr7771501uad.88.1588781767577; Wed, 06 May 2020 09:16:07 -0700 (PDT)
MIME-Version: 1.0
References: <158861946403.9316.9132034162941715598@ietfa.amsl.com> <CA+nkc8Bd+X9vfMq-Fzm6x1BbkiYGxh_TaxTwRXGj+2bXF+w-aw@mail.gmail.com> <CA+nkc8Bp_Js5_PF3PPPjtSuEetUwZpNxjJie5UXkD_3X-HRASg@mail.gmail.com> <SA0PR15MB379199F512D21F540C066464E3A70@SA0PR15MB3791.namprd15.prod.outlook.com> <CADZyTknCkTb9upGNLt-SF_13=Q-+P+D5vk_5uV61hBwGZttJJw@mail.gmail.com> <CA+nkc8Dk65zUgjUdmfvHK=WTzpAAfYdFEYKsVp8km5Lme=PMWw@mail.gmail.com>
In-Reply-To: <CA+nkc8Dk65zUgjUdmfvHK=WTzpAAfYdFEYKsVp8km5Lme=PMWw@mail.gmail.com>
From: Daniel Migault <mglt.ietf@gmail.com>
Date: Wed, 06 May 2020 12:15:56 -0400
Message-ID: <CADZyTkkT-kSwq_VSOsYNG65a9KZedd-G6byfDz4D0DGR=ozUeg@mail.gmail.com>
To: Bob Harold <rharolde@umich.edu>
Cc: dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e2209905a4fd14dc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/s15xeyWus_67pvtTlwTnOu2nmF4>
Subject: Re: [DNSOP] The DNSOP WG has placed draft-mglt-dnsop-dnssec-validator-requirements in state "Call For Adoption By WG Issued"
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 May 2020 16:16:20 -0000

On Tue, May 5, 2020 at 2:53 PM Bob Harold <rharolde@umich.edu> wrote:

>
> On Tue, May 5, 2020 at 12:02 PM Daniel Migault <mglt.ietf@gmail.com>
> wrote:
>
>> Hi Bob,
>>
>> I apology the previous email has just been sent unexpectedly.
>>
>> Thanks for the comments. The new version of the file is available here
>> [1] and a diff is available at [2].
>>
>> I propose the following text for clarification. Feel free to let me know
>> if that addresses your concern.
>>
>> OLD:
>> Not updating the configuration file prevents a failed synchronization to
>> to the absence of write permission that are hardly in the control of the
>> software."
>>
>> NEW
>> Avoiding the configuration file to be updated prevents old configuration
>> file to survive to writing error on read-only file systems.
>>
>
> I understand that we do not want the system to fail due to missing write
> permissions.  It seems like this could be handled two ways:
> 1. Just keep in memory, and do not try to write a new configuration.  That
> works, until the old trust anchor is removed, then it fails if the service
> is restarted.
> 2. Attempt to write a new configuration, but keep going even if that
> fails.  If the write succeeds, then this works even after the old trust
> anchor is removed.
>
> I would prefer the second method.  I think that is what some software
> already does.  (BIND?)
>
>
Thank you for your feed backs, though this may be changed, in the current
document we encourage to have an instantiation process that performs some
validation and checks before the service is started. One of these checks is
to ensure the configuration is up-to-date. With such process in place, we
expect that every instance of the service is appropriately provisioned. A
concrete (simple) deployment can always retrieve the service from a repo or
perform a check for updates.

With that set, 1 or 2 would work the same. The reason I would maybe prefer
1) over 2) is that 1 is known to carry the old configuration which will
force the necessary check at startup. On the other hand 2) works fine
unless KSK roll over happens and a write error happens. This means that
most of the time this will work fine and this is what makes it dangerous in
my opinion.

But again, I am happy to update this with what the WG thinks it mostly
appropriated. I have raised the following issue:
https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/issues/1










> --
> Bob Harold
>
>
>>
>> Please inline other comments.
>>
>> Yours,
>> Daniel
>>
>> [1]
>> https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/blob/master/draft-mglt-dnsop-dnssec-validator-requirements.mkd
>> [2]
>> https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/commit/f8ab674b12442aff6ba3c72a3ca8f795f24b2df9#diff-c7cc8f0bdd4d7cce2082828d70d2bf35
>>
>>
>> On Tue, May 5, 2020 at 11:52 AM Daniel Migault <daniel.migault=
>> 40ericsson.com@dmarc.ietf.org> wrote:
>>
>>> Hi Bob,
>>>
>>> Thanks for the comments. The new version of the file is available here
>>> [1] and diff can be seen at [2].
>>>
>>> I propose the following text. Does it clarify the concern ?
>>> Avoiding the configuration file to be updated prevents old configuration
>>> file to survive to writing error on read-only file systems.
>>>
>>>
>>> "Not updating the configuration file prevents a failed
>>>    synchronization to to the absence of write permission that are hardly
>>>    in the control of the software."
>>>
>>> <mglt>
>>> </mglt>
>>>
>>> [1]
>>> https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/blob/master/draft-mglt-dnsop-dnssec-validator-requirements.mkd
>>> [2]
>>> https://github.com/mglt/draft-mglt-dnsop-dnssec-validator-requirements/commit/f8ab674b12442aff6ba3c72a3ca8f795f24b2df9#diff-c7cc8f0bdd4d7cce2082828d70d2bf35
>>>
>>> ------------------------------
>>> *From:* Bob Harold <rharolde@umich.edu>
>>> *Sent:* Monday, May 4, 2020 4:29 PM
>>> *To:* Daniel Migault <daniel.migault@ericsson.com>
>>> *Subject:* Fwd: [DNSOP] The DNSOP WG has placed
>>> draft-mglt-dnsop-dnssec-validator-requirements in state "Call For Adoption
>>> By WG Issued"
>>>
>>> Minor nits:
>>>
>>> 7.  Trust Anchor Related Recommendations
>>>
>>> Last sentence, last few words:
>>> "in section Section 8" > "in Section 8"
>>>
>>> <mglt>
>>> addressed
>>> </mglt>
>>>
>>> 7.2.1.  Automated Updates to DNSSEC Trust Anchors
>>>
>>> "TA updates is" > "TA updates are"
>>>
>>> <mglt>
>>> addressed
>>> </mglt>
>>>
>>> "but due to human" > "due to human"
>>>
>>> <mglt>
>>> addressed
>>> </mglt>
>>>
>>> 7.2.2.  Automated Trust Anchor Check
>>>
>>> "Not updating the configuration file prevents a failed
>>>    synchronization to to the absence of write permission that are hardly
>>>    in the control of the software."
>>>
>>> <mglt>
>>> I propose the following text. Does it clarify the concern ?
>>> Avoiding the configuration file to be updated prevents old configuration
>>> file to survive to writing error on read-only file systems.
>>> </mglt>
>>>
>>> Seems confusing, please rewrite.
>>>
>>> "The TA can be queries" > "The TA can be queried"
>>>
>>> <mglt>
>>> addressed
>>> </mglt>
>>>
>>> "does not only concerns" > "does not only concern"
>>> <mglt>
>>> addressed
>>> </mglt>
>>> "if the mismatch result" > "if the mismatch resulted"
>>> <mglt>
>>> addressed
>>> </mglt>
>>>
>>> 8.  Negative Trust Anchors Related Recommendations
>>>
>>> "disable the signature check for that key the time" > "disable the
>>> signature check for that key until the time"
>>> <mglt>
>>> addressed
>>> </mglt>
>>>
>>> "This does not prevents" > "This does not prevent"
>>> <mglt>
>>> addressed
>>> </mglt>
>>> "either an attack or a failure into" > "either an attack or a failure in"
>>> <mglt>
>>> addressed
>>> </mglt>
>>> 10.1.  Automated Reporting
>>>
>>> "will take the appropriated steps" > "will take the appropriate steps"
>>> <mglt>
>>> addressed
>>> </mglt>
>>> --
>>> Bob Harold
>>>
>>>
>>> ---------- Forwarded message ---------
>>> From: *Bob Harold* <rharolde@umich.edu>
>>> Date: Mon, May 4, 2020 at 4:28 PM
>>> Subject: Re: [DNSOP] The DNSOP WG has placed
>>> draft-mglt-dnsop-dnssec-validator-requirements in state "Call For Adoption
>>> By WG Issued"
>>> To: IETF DNSOP WG <dnsop@ietf.org>
>>>
>>>
>>> Looks useful, I will review.
>>>
>>> --
>>> Bob Harold
>>>
>>>
>>> On Mon, May 4, 2020 at 3:13 PM IETF Secretariat <
>>> ietf-secretariat-reply@ietf.org> wrote:
>>>
>>>
>>> The DNSOP WG has placed draft-mglt-dnsop-dnssec-validator-requirements in
>>> state Call For Adoption By WG Issued (entered by Tim Wicinski)
>>>
>>> The document is available at
>>>
>>> https://datatracker.ietf.org/doc/draft-mglt-dnsop-dnssec-validator-requirements/
>>>
>>>
>>
>> --
>> Daniel Migault
>> Ericsson
>>
>

-- 
Daniel Migault
Ericsson