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
> >
>
>
>