Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-pki-profiles-19: (with DISCUSS and COMMENT)

Sean Turner <sean@sn3rd.com> Wed, 04 January 2017 23:57 UTC

Return-Path: <sean@sn3rd.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 9F3801294BE for <sidr@ietfa.amsl.com>; Wed, 4 Jan 2017 15:57:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-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 XS9pmxCn435K for <sidr@ietfa.amsl.com>; Wed, 4 Jan 2017 15:56:59 -0800 (PST)
Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 18BCB129440 for <sidr@ietf.org>; Wed, 4 Jan 2017 15:56:59 -0800 (PST)
Received: by mail-qk0-x22c.google.com with SMTP id n21so417484679qka.3 for <sidr@ietf.org>; Wed, 04 Jan 2017 15:56:59 -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=ISJfG8uwjRXmGTuFfInsxWKCRHstlQmbC3dHUOFSOXA=; b=jZncyFyFpVD67RT5J9N+yrBKhJXUSFbg6i79EnbkLtL/RdLoYBNJw+MQNYdvjHDUfM figoG+YGYhCFlhbCQym6VjhOGCS9VRLYzAL/1MmgtJduPbRBVDUv8dR1PH9Q9oC1X88d KDNe020NvnopdeMM8sWOo6JbiEZrOx3iQXcbg=
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=ISJfG8uwjRXmGTuFfInsxWKCRHstlQmbC3dHUOFSOXA=; b=C8/xhY1SJ9WgjSIGOVSDX5ZaSrise4zhEeqJj6UyrDrs1n6cYGoQGOB5kopiuZ54Au ds18XC/d40+3OT2cMImCL3q5m3DEiSTfxN+gpU4N3h0hTljF2ZW/mSai8MnNsqyLCpSV pDqu+2m8rxJuuCC+5Oa499SLq1Rs5viUZXXuhsxQD6a6yXfHmbgxuFkRCswn923uMYDI DwUygjAzThJyAYr5EixpsYGgZjnh5AMU8K+169J2yYa0ljZvmdT0DXMXEFRE0e4328KQ QNnhrhaLsG9Czt6t1Amzd44uwexqS1DynqCYgUkcsGZNmDdwJczvy5tINrCzn2ErC9rN 0MJQ==
X-Gm-Message-State: AIkVDXKUXaTTSzrj9MMyiVoxPVCB5S9gl2ZLL2mBwzIjEAlxA7AQ4w9eMC5FvnLMEP0qPw==
X-Received: by 10.55.200.195 with SMTP id t64mr64931658qkl.294.1483574218048; Wed, 04 Jan 2017 15:56:58 -0800 (PST)
Received: from [172.16.0.92] (pool-173-73-120-80.washdc.east.verizon.net. [173.73.120.80]) by smtp.gmail.com with ESMTPSA id 5sm47053274qts.47.2017.01.04.15.56.56 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 04 Jan 2017 15:56:56 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Sean Turner <sean@sn3rd.com>
In-Reply-To: <0811b400-fc2a-8675-7b74-4b549940de65@cs.tcd.ie>
Date: Wed, 04 Jan 2017 18:56:54 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <E797A202-BF76-4D41-8679-D939E7CC44B1@sn3rd.com>
References: <148353788046.13042.160471261406266.idtracker@ietfa.amsl.com> <20170104200413.1DFD04581178@minas-ithil.hactrn.net> <99955d9c-4771-dd45-f019-313661631e87@cs.tcd.ie> <20170104221557.73CF84581C4F@minas-ithil.hactrn.net> <0811b400-fc2a-8675-7b74-4b549940de65@cs.tcd.ie>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/NTKAjt0tq9rfrBL24j_HStYe3h4>
Cc: Rob Austein <sra@hactrn.net>, Chris Morrow <morrowc@ops-netman.net>, sidr-chairs@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-sidr-bgpsec-pki-profiles@ietf.org, sidr@ietf.org
Subject: Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-pki-profiles-19: (with DISCUSS and COMMENT)
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: Wed, 04 Jan 2017 23:57:06 -0000

Jumping here

> On Jan 4, 2017, at 18:11, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
> 
> Hiya,
> 
> On 04/01/17 22:15, Rob Austein wrote:
>> At Wed, 4 Jan 2017 20:57:24 +0000, Stephen Farrell wrote:

> (1) 3.1.1: Why MUST a CA ensure that the CA name and
> Subject name combination is unique? I don't see what'd
> break in BGPsec if that rule is omitted, but maybe I'm
> missing something. 

This might OBE based on the hack/burn of this section, but are you talking about the last sentence?

>>> On 04/01/17 20:04, Rob Austein wrote:
>> ...
>>>> This draft is a profile of RFC 6487, which is itself a profile of RFC
>>>> 5280.  All of the above is pretty much verbatim from RFC 6487.
>>> 
>>> Hmm. I wonder if that's the best plan, especially if there's
>>> no interop justification for some of it.
>> 
>> The theory, such as it is, goes:
>> 
>> * RPKI is a tightly constrained profile of X.509v3, with almost
>>  everything either required or forbidden, to reduce the number of
>>  grey areas.
>> 
>> * The BGPSEC profile is a minimal set of changes and extensions to the
>>  RPKI profile: same overall goal, slightly different constraints.

Yep that’s it: constraining the constrained.

>>> I note that 6487 says "In the RPKI, the subject name is determined
>>> by the issuer, not proposed by the subject" but that seems a bit
>>> weird for routers, where I would guess there'll be more diversity in
>>> terms of key/CSR generation code.
>> 
>> Well, strictly speaking the subject name is always selected by the
>> issuer in X.509, but I know what you mean.
>> 
>> RFC 6487 is weird about this because various parties were extremely
>> concerned to avoid anything that could be construed as certification
>> of real-world identity, ie, they did not want to find themselves in
>> the mainstream PKI business.  So RPKI uses meaningless names and has
>> the ability to enforce that, hence the text you note in RFC 6487.
> 
> I'd say any concerns that the web PKI CAs might have had ought
> now be ameliorated (or OBE, give letsencrypt), so not trodding
> on mainstream CA business is probably not as much as concern
> as was the case at the start of the RPKI work.
> 
>> 
>> RFC 6487 6.1.1 does in fact allow the subject to include a subject
>> name in the PKCS #10 request, but the text is loaded with weasel
>> words.  Speaking as someone who has implemented all of this, I find
>> the RFC 6487 constraints on subject name in PKCS #10 requests a bit
>> excessive, but that's not the document currently under discussion.
> 
> Well, except that this draft does re-iterate some of those now
> clearly weird MUSTs.
> 
>> 
>>> (Correct me if I'm wrong but I'm not sure if it's possible to
>>> conform to these requirements with e.g. openssl, or is it?)
>> 
>> The OpenSSL command line tool would probably fight hard against either
>> omitting the subject field from the PKCS #10 request or allowing it to
>> be NULL.  The former (field absent) is not even syntactically legal
>> X.509.  The latter (present but NULL) is legal but kind of unusual:
>> RFC 5280 4.1.2.6 allows it in certificates if a critical, non-empty
>> subjectAltName extension is present, RFC 2986 is silent on the subject
>> and is only informational in any case.
>> 
>> I'm pretty sure that the OpenSSL library would allow the
>> present-but-NULL form, but haven't tested it (recently? ever? don't
>> recall...).
>> 
>> In practice, I don't think any of the RKI CA implementations reject
>> PKCS #10 requests for having a non-NULL subject, they just ignore it.
>> 
>> All of this is still a problem with RFC 6487, which we should have
>> caught five years ago.  Oops.  Not sure what the best approach is when
>> trying to sub-profile a profile with a known wart like this.

The only thing I want to what Rob has mentioned is that this constraint to use common name and serial number has been around since mid-2011.  In contrast to many other groups I’ve worked with there was no desire to support everything and the kitchen sink only to find out later that there were a whole lot of implementation pitfalls to be had with T61String, BMPString, or how IDNA2008 vs IDNA2003 might affect comparisons.  I remember trying to get people to provide input to tell me that more was needed, I gave up at some point because all I got in response was crickets.  Now that might have been for a lot of reasons, but I/we certainly asked.

> Fair point.
> 
> So assuming there isn't a chorus of WG participants asking to
> remove the weird constraints then I'd say the right thing must
> be to not re-iterate any weirdness from 6487 but to only inherit
> that by reference. That way, if/when we modify 6487, we won't
> have to do the same with this, and maybe also hit problems
> with these constraints being enforced by code in two places.
> 
> I think the only such text I saw (that re-iterates 6487) was
> in 3.1.1 but there might I guess be more.

That text has basically been unchanged since the -01 of the individual draft circa 2011.  I can have a look at 3.1.1 and scrub out what’s repeated from 6487, but then I’ll get a chorus of “but there’s no context, I can’t understand it.” But, to get through this hurdle, what I think we’re talking about is deleting the first sentence and everything after “note”, i.e., 

   Common name encoding options that are supported are
   printableString and UTF8String.  For BGPsec Router Certificates, it
   is RECOMMENDED that the common name attribute contain the literal
   string "ROUTER-" followed by the 32-bit AS Number [RFC3779] encoded
   as eight hexadecimal digits and that the serial number attribute
   contain the 32-bit BGP Identifier [RFC4271] (i.e., the router ID)
   encoded as eight hexadecimal digits.  If there is more than one AS
   number, the choice of which to include in the common name is at the
   discretion of the Issuer. If the same certificate is issued to more
   than one router (hence the private key is shared among these
   routers), the choice of the router ID used in this name is at the
   discretion of the Issuer.

>>>>> And I'd wonder if router cert revocation will be more common than
>>>>> for other resource certs, in which case an OCSP-like system could be
>>>>> needed - did the WG consider that?
>>>> 
>>>> Not as such.  Fair question, but the architecture kind of assumes that
>>>> the RPKI RP process is separable from the BGPSEC implementation per
>>>> se, BGPSEC just consumes the output of that process.
>>> 
>>> I'd wonder if that means some revocation request protocol will be
>>> needed later. But it's fine to not try define that now.
>> 
>> Fair point.
>> 
>>> More to the point is whether or not the WG have thought about the
>>> revocation support in the RPKI and whether or not that seems also
>>> ok for BGPsec. (I'm unsure myself, but mostly due to the number of
>>> moving parts in the RPKI.)
>> 
>> Has been discussed, somewhat noisily.  Ask a SIDR WG chair if you want
>> an opinion on WG consensus.  My own take is that router keys probably
>> get whacked on roughly the same kind of timescale as other RPKI keys,
>> so if the revocation mechanism is good enough for everything else,
>> it's probably good enough for router keys.  YMMV.
> 
> Fair enough. Again, assuming that there's no chorus wanting
> change, I'll clear this point as well.

Again, definitely no chorus or even drunk carolers :)

spt

> Cheers,
> S.
> 
>> 
>>>> Most likely implementation technique does all the RPKI stuff per se on
>>>> a separate box and just stuffs the resulting raw keys into the router
>>>> using the rpki-rtr protocol, so the router itself probably would not
>>>> have the information needed to play OCSP even if it wanted to do so,
>>>> which it probably doesn't.  
>>> 
>>> So if that's a widely shared view of WG participants then it'd be
>>> good to see it described somewhere to help implementers. (It may
>>> be in the -overview document which I've yet to read.)
>> 
>> It's sort of in RFC 6810 (rpki-rtr).  The update to RFC 6810 is
>> stalled because I dropped the ball last year.
>> 
>>>> Requiring the routers to speak OCSP seems
>>>> like a potentially dangerous layering violation.
>>> 
>>> Not sure about a layering violation but I can see it'd likely be
>>> problematic;-)
>> 
>> I had front-row tickets to the "let's stuff routing policy data into
>> the DNS!" show back in the '90s.  My main take-away from that mess was
>> a fear of real-time circular dependencies.