Re: [sidr] Erratum for RFC6486? (manifests)

"Murphy, Sandra" <Sandra.Murphy@parsons.com> Fri, 26 July 2013 16:29 UTC

Return-Path: <prvs=0919bc7b90=sandra.murphy@parsons.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 95F6021F9A7E for <sidr@ietfa.amsl.com>; Fri, 26 Jul 2013 09:29:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.499
X-Spam-Level:
X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zmD6p8FHq+O for <sidr@ietfa.amsl.com>; Fri, 26 Jul 2013 09:29:39 -0700 (PDT)
Received: from txdal11mx03.parsons.com (txdal11mx03.parsons.com [206.219.199.111]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB2821F8E70 for <sidr@ietf.org>; Fri, 26 Jul 2013 09:29:39 -0700 (PDT)
Received: from pps.filterd (txdal11mx03 [127.0.0.1]) by txdal11mx03.parsons.com (8.14.5/8.14.5) with SMTP id r6QGK67l017804; Fri, 26 Jul 2013 11:29:35 -0500
Received: from m4.sparta.com (m4.sparta.com [157.185.61.2]) by txdal11mx03.parsons.com with ESMTP id 1duuwtr8rw-1 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 26 Jul 2013 11:29:34 -0500
Received: from Beta5.sparta.com ([10.62.8.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id r6QGTXd6006161; Fri, 26 Jul 2013 11:29:33 -0500
Received: from CVA-HUB001.centreville.ads.sparta.com ([10.62.108.11]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id r6QGTSvJ010206; Fri, 26 Jul 2013 11:29:28 -0500
Received: from CVA-MB002.centreville.ads.sparta.com ([fe80::6046:a82a:c500:c9ad]) by CVA-HUB001.centreville.ads.sparta.com ([fe80::8ca8:7aea:3db9:1972%11]) with mapi id 14.02.0342.003; Fri, 26 Jul 2013 12:28:40 -0400
From: "Murphy, Sandra" <Sandra.Murphy@parsons.com>
To: Tim Bruijnzeels <tim@ripe.net>, Stephen Kent <kent@bbn.com>
Thread-Topic: [sidr] Erratum for RFC6486? (manifests)
Thread-Index: AQHOgghlQeiQIrI2D06jymIcofxCv5lpZzCAgALQaICACv5qXQ==
Date: Fri, 26 Jul 2013 16:28:40 +0000
Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F6749C7967@CVA-MB002.centreville.ads.sparta.com>
References: <A4234F86-EC27-4EB5-B988-D61019E80A7B@ripe.net> <51E6D5FF.6030802@bbn.com>, <23E19953-DFC2-4331-B497-60BC0FFDEB37@ripe.net>
In-Reply-To: <23E19953-DFC2-4331-B497-60BC0FFDEB37@ripe.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.62.8.137]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-07-26_07:2013-07-26, 2013-07-26, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=5.55111512312578e-17 kscore.compositescore=0 circleOfTrustscore=0.922245805066741 compositescore=0.0543551683579278 urlsuspect_oldscore=0.228934748274223 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=6008 rbsscore=0.0543551683579278 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.3 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1307260112
Cc: "sidr@ietf.org list" <sidr@ietf.org>
Subject: Re: [sidr] Erratum for RFC6486? (manifests)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Fri, 26 Jul 2013 16:29:44 -0000

>Sandy, I am not sure, but this may be short topic for 
>one of the sessions. Especially if we want to say anything 
>about best practices for CAs.
....
>That said I think there are quite a few details left that are worth discussing.


The conversation stopped with that, which means people lost interest, or 
they're waiting for the discussion.

So I added it to the agenda.

(And baring any response about time constraints from presenters or those interested in a discussion, the talks will be bound to agenda slots by Monday.)

--Sandy, speaking as co-chair


________________________________________
From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Tim Bruijnzeels [tim@ripe.net]
Sent: Friday, July 19, 2013 8:34 AM
To: Stephen Kent
Cc: Murphy, Sandra; sidr@ietf.org list
Subject: Re: [sidr] Erratum for RFC6486? (manifests)

Hi Steve,

I think we agree for the most part on the idea to remove the restriction for single use EE certificate. To quote and answer to the end of your mail first:

Sandy, I am not sure, but this may be short topic for one of the sessions. Especially if we want to say anything about best practices for CAs.

> So, while I believe that there is no need to change the 5.1 text based on the
> RP concern you cited, I support a change to that text to allow CAs more
> flexibility in managing the EE cert validity in manifests, and to remove the
> single-use vs. sequential-use EE cert distinction.
>
> Would you like to propose and share text for the suggested change? We may have to
> issue a new RFC, updating 6486, since this does represent a technical change to
> how we say a CA should behave.

I proposed to change this text in section 5.1:

         In the case of a "one-time-use" EE certificate, the validity
         times of the EE certificate MUST exactly match the thisUpdate
         and nextUpdate times of the manifest.

         In the case of a "sequential-use" EE certificate, the validity
         times of the EE certificate MUST encompass the time interval
         from thisUpdate to nextUpdate.

To:

         The validity times of the EE certificate MUST encompass the time
         interval from thisUpdate to nextUpdate.


That said I think there are quite a few details left that are worth discussing.


> Section 5.1 of RFC 6486 is titled "Manifest Generation Procedure." This it is a set of directions to the CA creating the manifest, not directions to an RP verifying a
> manifest. Section 6 is the discussion of what a relying party is supposed to do with a manifest. My quick re-read of Section 6 does not call for an RP to check that the validity time is consistent with the single-use vs. sequential-use EE cert criteria in 5.1. So, the primary concern you cited, i.e., that an RP cannot know which test to apply, is not a valid
> reason to change this text.

Although I agree in general with the approach to "be strict in what you send, and liberal in what you accept" I just found this instance confusing. It was not 100% clear to me if I should care as an RP.

In any case, I am happy to remove this check, and only care about valid, stale, invalid..


> I agree that the invalid vs. stale disparity that arises because of the directions to
> CAs on manifest EE cert generation is an awkward one.

> Your example of a manifest with
> a planned daily update, but a cert that is valid for a week, is an reasonable operational
> model. If RPs continue to fetch data based on what has changed, then a manifest that is
> slated to change, but doesn't, doesn't impose an addition sync load. If an RP were to
> fetch data based on when it says it will expire, then this might be less desirable. So
> we might take that into consideration when suggesting this model.


As I understand there are three cases with regards to stale and invalid based on time (ignoring other cases):

-1 Manifest is current
       = now is after thisUpdate and before nextUpdate &&
       = now is within EE Certificate validity time

-2 Manifest is stale
       = now is after nextUpdate
       = now is within EE Certificate validity time

-3 Manifest is invalid
       = now is outside of (after) EE Certificate validity time

The current text allows for all three states to exist for multi-use EE certificates, but only 1 and 3 can exist for single use. I want remove this restriction, because RP treatment of "stale" is different from "invalid", and as a CA I want to be able influence this.


> If we had guidelines for best practices for pub point management, with suggested
> rates of change, we might better understand the possible impact of this operational
> model. For example, if the recommended frequency of CRL issuance is daily, then the
> manifest ought to change daily as well, the there's a decent chance that the CRL and
> the manifest are either both stale or current.

I agree that best practices would be good, both for CA and RP.

Is this something to discuss shortly?

As a start…

W.r.t. RP:
 - I would advise against fetching new manifests based on the expiry of the EE cert if that date is after the nextUpdate.
 - I would advice that RPs fetch new data at least in advance of the
 - I think RPs are free to poll more frequently
 ….

W.r.t. CAs:
 - I would advise to limit the nextUpdate time to a window that forms the 'optimal compromise' between:
        - being overrun by RPs trying to get new data
        - workload of generating new certificates
        - too slow propagation times for new products - to -router

  - The RIR implementations all use 24 hours I think, this seems reasonable.

  - I would advise that longer EE certificate time should be used to prevent that manifests are immediately invalid if RPs
    only fetch close to the nextUpdate time, and are unsuccessful for whatever reason

Al that is best current practice for the current implementation.

I think that a faster notification mechanisms and propagation times are a real need expressed by operators and should be addressed in future work.

Tim



_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr