Re: [secdir] Secdir review of draft-ietf-sidr-res-certs

Paul Hoffman <paul.hoffman@vpnc.org> Thu, 10 March 2011 19:30 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70E9D3A6828; Thu, 10 Mar 2011 11:30:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.952
X-Spam-Level:
X-Spam-Status: No, score=-101.952 tagged_above=-999 required=5 tests=[AWL=0.647, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWfmMDCE7cRg; Thu, 10 Mar 2011 11:30:27 -0800 (PST)
Received: from hoffman.proper.com (unknown [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id 14CC73A6826; Thu, 10 Mar 2011 11:30:26 -0800 (PST)
Received: from sn87.proper.com (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p2AJVhi7082352 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 10 Mar 2011 12:31:43 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Message-ID: <4D79271E.6080707@vpnc.org>
Date: Thu, 10 Mar 2011 11:31:42 -0800
From: Paul Hoffman <paul.hoffman@vpnc.org>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: Sam Hartman <hartmans-ietf@mit.edu>
References: <tslhbbag9m1.fsf@mit.edu> <4D791B26.8020001@vpnc.org> <tsl4o7ag5fw.fsf@mit.edu>
In-Reply-To: <tsl4o7ag5fw.fsf@mit.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-sidr-res-certs@tools.ietf.org, ietf@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Secdir review of draft-ietf-sidr-res-certs
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Thu, 10 Mar 2011 19:30:28 -0000

On 3/10/11 11:07 AM, Sam Hartman wrote:
>>>>>> "Paul" == Paul Hoffman<paul.hoffman@vpnc.org>  writes:
>
>      Paul>  On 3/10/11 9:37 AM, Sam Hartman wrote:
>      >>  The document also requires that relying parties reject
>      >>  certificates that include unknown extensions. The rationale
>      >>  explained in section 8 is that it is undesirable to have a
>      >>  situation where if an RP implemented more extensions it would
>      >>  reject certificates that a more minimal RP would accept.  In
>      >>  other words the profile picks security and minimalism over
>      >>  extensibility.
>
>      Paul>  This statement is too narrow, and it causes your analysis to
>      Paul>  come to a too narrow conclusion. The profile picks security
>      Paul>  and minimalism over extensibility *of this profile only*. If a
>      Paul>  flaw is later found that requires an extension, that extension
>      Paul>  will be written up in a standards-track document that will
>      Paul>  obsolete this profile. An implementation that conforms to that
>      Paul>  new profile will use the extension. Thus, errors can be
>      Paul>  corrected with new profiles, and the RPKI will have multiple
>      Paul>  profiles running on it, just as the Internet has multiple
>      Paul>  versions of some protocols running on it.
>
>
> Paul, that's a great argument for why it's OK to prohibit issuing
> certificates with new extensions in this profile.
> We absolutely can change CA behavior with a new profile.
>
> However, I don't think your argument makes sense for RP behavior.
> Under this profile, if an RP is presented with a certificate issued
> under a new RPKI profile, it will reject that certificate.
>
> So, it sounds a lot like you'd need to upgrade all the RPs that might
> need to rely on a particular resource certificate before  you could
> issue that certificate under a new profile.
> Given that resource certificates can be used by a lot of RPs--for
> example anyone who needs to verify origins of a route presumably--that's
> a long wait.
> I think that's unjustified.
>
> One of us is clearly missing something. I would be happy if it's me.

I don't think either of us is missing something, we just disagree about 
what needs to happen if a fix that changes the semantics of the certs 
needs to be made to the system as a whole. For changes that don't change 
the semantics, you change an existing extension or other part of the 
certificate; for changes that need to change the system's semantics, you 
change the certificates in a way that relying parties that don't 
understand the change won't accept the certificate.

Maybe you and I are envisioning different choices being made about those 
changes. I trust the IETF not to make a change that will cause a lot of 
relying parties to fail unless the IETF really thinks that is necessary; 
you may have less faith than I do. (You were on the IESG, so you get to 
be in the sausage-making more than I have...)