Re: [Spasm] Let's focus
Richard Barnes <rlb@ipv.sx> Fri, 27 May 2016 14:43 UTC
Return-Path: <rlb@ipv.sx>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98E4B12D682 for <spasm@ietfa.amsl.com>; Fri, 27 May 2016 07:43:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.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 RS8ytvL8zq5A for <spasm@ietfa.amsl.com>; Fri, 27 May 2016 07:43:14 -0700 (PDT)
Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (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 488E712DABD for <spasm@ietf.org>; Fri, 27 May 2016 07:43:13 -0700 (PDT)
Received: by mail-vk0-x229.google.com with SMTP id r140so146270614vkf.0 for <spasm@ietf.org>; Fri, 27 May 2016 07:43:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=jn+gCwosRYZYIUu3WyXfMIW4dJMMEZa07U35hz9CKKw=; b=QkZICcb9nSbMKBPn9A0mT0SD9kjmCOiRBc+skUK5qUjK93/Om7XHi1qH92LkDHjRGg ysmmN2qFv4V2CSlHeenVVgJuFeUbea/06DcWC0mBpfWvqZxtWRWxOBkInhkY9lo2OVL0 23qrT17Sk4i3xeQ2aWESwB+aXtkyD+mgt9n83scqMrDxEdfrXtsGRJbvUJQCkDfdfbiS /hSH3bs2DvABha/3eBynUAGel1HE99BKoztYy3bv/MeMEMEZ/YJ9hZ7xUbCyW5fcqVdW +fAWMdE0EGj/IwiKfrGpurA64kmyqChhIBqRzCNKAT26e0upWV5jQw0MxebUiA7ClKb8 8B4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=jn+gCwosRYZYIUu3WyXfMIW4dJMMEZa07U35hz9CKKw=; b=A4RlJs9Rsgo8GfzjaRDPvpdhZ/EBXLx2O+XQbrJxHPlqBiPvve9JIqUxcPj4XlVcmo maEAy1j+JTjwY0O4WcPNM+hfJvXkxmaU0c/C0ZJ2pW7JAhoYRZcBiFfHAG89cz8jCJqc KRiZnb44HfmuoDjLBA7cOK1WNg3dhtisiryk/bEpq/pyJ5AiXG6otwur6LzTSbCB8w6e yYEX9uY9XNXEesBDTnWYII9p+a0UHGAkA2jBgPFuNFp/o+mUb7mobFLtusfY/d7L+YyS vTxyytP/TYsov+JD9teInq4D19yWNAuZflF5f0IkZbJrOJzeFonypUeRcze7bj6XUWij mhHQ==
X-Gm-Message-State: ALyK8tKGaxH+gB6Glepf/ytR97w/nwgBmGgQ6gKxSjumgc1M8xcX7bf85ivY+CJgwMyjpkUfQaRtxcCcLuSKJg==
MIME-Version: 1.0
X-Received: by 10.176.4.102 with SMTP id 93mr8664954uav.125.1464360192151; Fri, 27 May 2016 07:43:12 -0700 (PDT)
Received: by 10.31.48.71 with HTTP; Fri, 27 May 2016 07:43:12 -0700 (PDT)
In-Reply-To: <030101d1b81f$a08edff0$e1ac9fd0$@gmail.com>
References: <CAL02cgSHWvmmhCqv1Dz8wfiGsOqOXWNi150suR-5xqt3F8ppcw@mail.gmail.com> <57475B33.3070201@cs.tcd.ie> <CAL02cgQD_xF8tTF_e_X7P3RxQ7tO2QLW=72ismrna4jSNKo8aQ@mail.gmail.com> <57484F1F.3030809@cs.tcd.ie> <CAL02cgRykHANki6=yMpEtL3JK52psvGzt61sWCFPjGEQe+JvPg@mail.gmail.com> <030101d1b81f$a08edff0$e1ac9fd0$@gmail.com>
Date: Fri, 27 May 2016 10:43:12 -0400
Message-ID: <CAL02cgT=Szg=gYJY1B-N=ZrUhOooXdEjfqB2DJLuSZYDtZAFKQ@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: Santosh Chokhani <santosh.chokhani@gmail.com>
Content-Type: multipart/alternative; boundary="94eb2c000bec139c710533d3ed97"
Archived-At: <http://mailarchive.ietf.org/arch/msg/spasm/_gJTeUjxc2kmDcRyWPb9slUF47o>
Cc: spasm@ietf.org, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Subject: Re: [Spasm] Let's focus
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 May 2016 14:43:16 -0000
On Fri, May 27, 2016 at 9:56 AM, Santosh Chokhani < santosh.chokhani@gmail.com> wrote: > I agree. This is unlikely to be deployed. > > > > It would be better for us to see how MSFT and NSS handles EKU in > intermediate certificates and bite the bullet and document it and may be > work around the edges if there are security holes and implementers wish to > close them. > To be clear, if you want to cover the browser/OS space, you basically have the following major RP stacks: - Microsoft - Apple - mozilla::pkix - NSS - OpenSSL / BoringSSL Speaking for the mozilla::pkix and NSS side of things, we would be unlikely to implement anything without a pretty significant security benefit. --Richard > *From:* Spasm [mailto:spasm-bounces@ietf.org] *On Behalf Of *Richard > Barnes > *Sent:* Friday, May 27, 2016 9:48 AM > *To:* Stephen Farrell <stephen.farrell@cs.tcd.ie> > *Cc:* spasm@ietf.org > *Subject:* Re: [Spasm] Let's focus > > > > > > > > On Fri, May 27, 2016 at 9:43 AM, Stephen Farrell < > stephen.farrell@cs.tcd.ie> wrote: > > > Hiya, > > > On 27/05/16 14:04, Richard Barnes wrote: > > On Thu, May 26, 2016 at 4:23 PM, Stephen Farrell < > stephen.farrell@cs.tcd.ie> > > wrote: > > > >> > >> Hiya, > >> > >> On 26/05/16 21:04, Richard Barnes wrote: > >>> Hey all, > >>> > >>> I'm concerned that the proposed scope [1] for this WG is (1) too broad, > >> and > >>> (2) inconsistent with the participation so far. > >>> > >>> The breadth concern is evident in the ambiguity of the name "Some?" > This > >>> group should identify some concrete, practical problems in the Internet > >>> they need to solve, describe them, and demonstrate that they have the > >> right > >>> set of stakeholders to develop, implement, and deploy a solution. > >> > >> Well we can bikeshed names for sure but moving on... > >> > >>> > >>> I'm personally most concerned about the "fix the EKUs" milestone, at > >> least > >>> as it's realized in [2]. > >> > >> Yeah, me too. The discussion around that has been eerily reminiscent of > >> some of the less productive things from the "late" PKIX period. > >> > >>> From the perspective of someone who works a lot > >>> in the Web PKI, this sounds like a request for a feature that has > >> negative > >>> value. The incremental value of the proposed feature would be to allow > >>> "everything but X" CAs. Recent experience in the Web PKI has driven > home > >>> how harmful it can be to have divergent sets of RPs relying on the same > >>> PKI, so allowing CAs to be more unconstrained is moving in the wrong > >>> direction. > >> > >> Fair point. If the WG is chartered I think it'd have to decide if > >> that's ok or not. > > > > > > You've kinda got the cart before the horse here. If this use case isn't > > good, then there's no point to having the milestone. > > Sorry, I wasn't clear. What I meant was that if this use-case is > included in a charter, then the WG will need to figure out if > "everything but X" CAs is a good/bad idea to support when trying > to solve for the use case. > > > > > > > > >> (Stefan's 1-bit counter-proposal didn't have the > >> same property though or am I wrong?) > >> > >>> I'm not dogmatic on this, but in order to be persuaded, I would > >>> need to see active interest from some real CAs, and from the logs of > this > >>> list, I'm not seeing anyone who's a current participant in the Web PKI > >>> (apologies if I've failed to recognize someone). > >> > >> It'd be good to see that kind of interest in the EKU work yes. Absent > >> that, I would guess deployment won't happen. > >> > > > > Again, I think demonstrating interest from the relevant community is > needed > > *before* chartering. The underlying principal of BoFs, etc., is that > spec > > here get developed by the people that are going to use them / be affected > > by them. If those people aren't here, we shouldn't charter work. > > Fully agree. > > Earlier though we did say on this list that we only want to charter work > where we do think it'll likely be implemented and likely deployed. If > there's a proposed work item in the current charter text where we do not > think that applies, then it ought be deleted. (Which is what I think > Russ was saying in his mail too.) > > So for item#2 in the current draft charter, can people say if they think > the results of that work is/is-not likely to be deployed? > > > > On this particular point: I haven't talked to anyone else about this, but > my personal view is that this is very unlikely to get deployed. In > addition to changes to CA and RP code, it would require substantial > rewriting of the BRs, the related audit standards, and root program > policies. So it would need to have some significant benefit to offset that > significant cost, and I'm just not seeing that. > > --Richard > > > > > > > Cheers, > S. > > > > > > > --Richard > > > > > >>> > >>> I'm also concerned about the "SRV for cert stores" milestone, though I > >>> admit I'm not as deep in this space. Looking at the proposed doc, it > >> seems > >>> like the SRV adds any value over just looking stuff up at a well-known > >> URI, > >>> e.g., adding a "x5c" attribute to a WebFinger resource. Anything that > >>> requires special DNS magic (and SRV counts) is going to face > significant > >>> deployment barriers. So I would be happier if this were a "define a > >> simple > >>> cert discovery mechanism for S/MIME" milestone, rather than being bound > >> to > >>> a specific mechanism. > >> > >> From my POV, that's yet another experiment in the public-key-retrieval- > >> to-support-e2e-messaging-security set of experiments that included the > >> openpgp-dane one recently approved. (And I'd be fine with more of those > >> experiments too for reasons stated during the IETF LC of the dane work.) > >> > >>> > >>> Overall, it seems like this group should focus on moving the ball > forward > >>> with regard to making S/MIME deployable in today's Internet -- fixing > >>> papercuts around AEAD, i18n, and cert discovery. The PKIX stuff is > >>> unrelated and addresses an entirely different constituency. > >> > >> I'm personally if the work here isn't all one effort but a small set of > >> sorta-diverse efforts. So long as they're likely to be deployed that is. > >> If that's not likely, then I'd be for dropping them from the charter. > >> > >> Cheers, > >> S. > >> > >>> > >>> --Richard > >>> > >>> > >>> [1] https://datatracker.ietf.org/doc/charter-ietf-spasm/ > >>> [2] https://tools.ietf.org/html/draft-housley-spasm-eku-constraints-01 > >>> [3] https://tools.ietf.org/html/draft-bhjl-x509-srv-00 > >>> > >>> > >>> > >>> _______________________________________________ > >>> Spasm mailing list > >>> Spasm@ietf.org > >>> https://www.ietf.org/mailman/listinfo/spasm > >>> > >> > >> > > > > > > > > _______________________________________________ > > Spasm mailing list > > Spasm@ietf.org > > https://www.ietf.org/mailman/listinfo/spasm > > > > >
- [Spasm] Let's focus Richard Barnes
- Re: [Spasm] Let's focus Wei Chuang
- Re: [Spasm] Let's focus Stephen Farrell
- Re: [Spasm] Let's focus Richard Barnes
- Re: [Spasm] Let's focus Stephen Farrell
- Re: [Spasm] Let's focus Richard Barnes
- Re: [Spasm] Let's focus Santosh Chokhani
- Re: [Spasm] Let's focus Richard Barnes