Re: [stir] certificates: short-lived or status

Tony Rutkowski <tony@yaanatech.com> Thu, 16 March 2017 03:13 UTC

Return-Path: <tony@yaanatech.com>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8AC130141 for <stir@ietfa.amsl.com>; Wed, 15 Mar 2017 20:13:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.088
X-Spam-Level: ***
X-Spam-Status: No, score=3.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, HTTPS_HTTP_MISMATCH=1.989, MIME_HTML_ONLY=0.723, MISSING_MIMEOLE=1.899, SPF_PASS=-0.001] autolearn=no autolearn_force=no
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 10FBM14DPadA for <stir@ietfa.amsl.com>; Wed, 15 Mar 2017 20:13:58 -0700 (PDT)
Received: from mil-admin2.yaanatech.net (38-110-174-11-static.dzbja.com [38.110.174.11]) by ietfa.amsl.com (Postfix) with ESMTP id 171E912F257 for <stir@ietf.org>; Wed, 15 Mar 2017 20:13:58 -0700 (PDT)
Received: from extmail1.yaanatech.com (12-12-158-76-static.dzbja.com [12.12.158.76]) by mil-admin2.yaanatech.net (Postfix) with ESMTP id C619C732; Thu, 16 Mar 2017 03:13:57 +0000 (UTC)
Received: from [192.168.1.183] (pool-70-106-242-209.clppva.fios.verizon.net [70.106.242.209]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by extmail1.yaanatech.com (Postfix) with ESMTP id 65F1258090; Thu, 16 Mar 2017 03:13:57 +0000 (UTC)
Date: Wed, 15 Mar 2017 23:13:53 -0400
Message-ID: <eb8ece83-e982-4d6a-ab61-4f5124cf420d@email.android.com>
X-Android-Message-ID: <eb8ece83-e982-4d6a-ab61-4f5124cf420d@email.android.com>
In-Reply-To: <06463D70-4B38-48A0-A653-1CBF7EC70292@att.com>
From: Tony Rutkowski <tony@yaanatech.com>
To: "DOLLY, MARTIN C" <md3135@att.com>
Cc: "Peterson, Jon " <jon.peterson@neustar.biz>, Richard Barnes <rlb@ipv.sx>, stir@ietf.org
Importance: Normal
X-Priority: 3
X-MSMail-Priority: Normal
MIME-Version: 1.0
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/2Z6Z1xoMyuMgKStUAgxDe0W1bm4>
Subject: Re: [stir] certificates: short-lived or status
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Mar 2017 03:13:59 -0000

What threat of punishment? There is none in the proposed rules.

On Mar 15, 2017 7:58 PM, "DOLLY, MARTIN C" <md3135@att.com> wrote:
That's why we have governance and the threat of punishment by the Feds 

Martin C. Dolly

Lead Member of Technical Staff

Core & Government/Regulatory Standards

AT&T

Cell: +1.609.903.3360

Email: md3135@att.com

 


On Mar 15, 2017, at 7:47 PM, Richard Barnes <rlb@ipv.sx> wrote:

So you're trusting the folks issuing certificates to be perfectly reliable, and service providers never to use a cert for a number that's been ported away?

On Wed, Mar 15, 2017 at 7:42 PM, DOLLY, MARTIN C <md3135@att.com> wrote:
I do not see the need for short lived certs for a TN call setup service

Martin C. Dolly

Lead Member of Technical Staff

Core & Government/Regulatory Standards

AT&T

Cell: +1.609.903.3360

Email: md3135@att.com

 


On Mar 15, 2017, at 7:37 PM, Richard Barnes <rlb@ipv.sx> wrote:

I would note that "freshness" is but one aspect of a certificate that you need OCSP for.  The far more common use in the WebPKI is when the CA simply screws up.

In any case, to recap the experience from the Web PKI, the trade-off space has basically the following shape:

1. Do a live query [draft-ietf-stir-certificates-ocsp]
2. Make something with a short lifetime
2.a. Mandatory OCSP stapling
2.b. Short-lived certificates [draft-peterson-stir-certificates-shortlived]

The trade-off is basically between the sender/signer having to do queries (to refresh OCSP or get a new cert) and recipient/verifier having to do queries (to fetch OCSP).  (2.a) is a bad deal unless you have some legacy need to use OCSP; otherwise it's just bloat relative to (2.b).

If you ask web people, you're likely to get a pretty strong preference for (2), i.e., putting the burden on the sender, because (a) it's more predictable and (b) it's offline with respect to call time, and thus much less performance sensitive.  The web started out with (1) and it has turned out to be totally unworkable, because the CAs can't operate OCSP servers that are good enough to avoid seriously degrading the performance of browsing experience.

The main push-back we get from server operators about (2) is that it requires outbound connections from web servers -- load and downtime never come up as issues.  Outbound connections shouldn't be an issue for STIR signers, since they're likely to be making outbound connections all the time anyway.  Even if not, it's a simple firewall rule to write to let out connections to your CA.

--Richard


On Wed, Mar 15, 2017 at 4:33 PM, Peterson, Jon <jon.peterson@neustar.biz> wrote:

In reaction to the IESG review, and as well, to our own general sense that we're still not ready to mandate any particular direction, we ended up pulling the real-time status check of OCSP out of the last version of stir-certificates. Figuring out how we want to manage certificate freshness, especially in light of certificates assigned to telephone numbers, is probably the last bit about the core STIR work, before we go on to extensions and so forth, that we need to tackle.

I'd like to spend some meeting time talking about two approaches, as well as any better ideas anybody comes up with for this. The first is roughly what was in the stir-certificates document previously, which is now captured in:


The other is an approach based on short-lived certificates, which would likely rely on ACME or something similar. I've mocked up a discussion draft for that:


... though it is still fairly content-free at the moment. 

I think reviewing what we've done with stir-certs and these two approaches warrants some face-time discussion. Thoughts here on the list beforehand are welcome too.

Thanks,

Jon Peterson
Neustar, Inc.



_______________________________________________
stir mailing list
stir@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_stir&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=p0Tz67-L9Fy0iCB4NsaQL-xivtUT_OhohUYV7gr17x0&s=xBPq9-hmuqFdGVD3GNxGolnkagSy3snLiWRrLaXOzX4&e=" rel="nofollow">https://www.ietf.org/mailman/listinfo/stir


_______________________________________________
stir mailing list
stir@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_stir&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=p0Tz67-L9Fy0iCB4NsaQL-xivtUT_OhohUYV7gr17x0&s=xBPq9-hmuqFdGVD3GNxGolnkagSy3snLiWRrLaXOzX4&e=" rel="nofollow">https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_stir&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=p0Tz67-L9Fy0iCB4NsaQL-xivtUT_OhohUYV7gr17x0&s=xBPq9-hmuqFdGVD3GNxGolnkagSy3snLiWRrLaXOzX4&e=