Re: [Secdispatch] Marking SPKAC as Historic

Eric Rescorla <ekr@rtfm.com> Wed, 16 November 2022 18:35 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: secdispatch@ietfa.amsl.com
Delivered-To: secdispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60FB6C14F742 for <secdispatch@ietfa.amsl.com>; Wed, 16 Nov 2022 10:35:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.896
X-Spam-Level:
X-Spam-Status: No, score=-6.896 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_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20210112.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsVyJIORRV1q for <secdispatch@ietfa.amsl.com>; Wed, 16 Nov 2022 10:35:12 -0800 (PST)
Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38DFAC14F74F for <secdispatch@ietf.org>; Wed, 16 Nov 2022 10:35:12 -0800 (PST)
Received: by mail-il1-x12c.google.com with SMTP id bp12so9584713ilb.9 for <secdispatch@ietf.org>; Wed, 16 Nov 2022 10:35:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ntR95KNDBRnTfYhvQ/I1+EbhaKc2cHui0BN1wTtango=; b=1zyHtlMzckeEfFBcq4L7OiOcNMjtiawwgqitcJmmFQRFbowhhyIetriADgz9uGRxQZ AmEOR9v90l3GBMPbeQZV6e/lKrvU4BDIlwcib3qMhZTtXoYNCmXPFBYPVKXwTD+eF2SP RoYCgWp6HYnPCYtK3qFKJ23t1FUab5owzUmDWuZcBKhvudCvcocB5iZuk4pYN3G2lMXA Kj/1GY+dfqlaZcIFIAm1+VNC0oWvshcbxlSxF5pNosoJw5AFv3WGC4YFHkE+pCUYbcmz lgWtomVkgAzRBvDYpnzoYbjTfoSltg6SBJ2sAwAGEIhw3SFgaROlSHhcQWyx5zdTq74a rTvA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ntR95KNDBRnTfYhvQ/I1+EbhaKc2cHui0BN1wTtango=; b=E7+vxGJRKHPSMor568MeiKx8HrZyGgUIi2GtfgDeNRf7+VOx3X4UnE6l9gf+IgRVah P6l/CIFpn8WUAODc3pJNrnDOhcH1Gm6M8uyweV8Eb+9l00+IeZ0CaAS8tSlTinxroFw9 CURml/1Lw6zwi309INIJMajhucGxazt6LIFJ43qnTZDjm5nG5jrlvOfLsRUJET8ByeiF 8YQZu9fGwTbB0Oxh/LXJ21IhH1h82ySy37NgbXwBfHv7Vr2aPniPdU8LGOIEdgUIT0EB lkZl65OqEk+zkXVSw2h3O/jXpEFGsf5913BCmBSHQJe+PURvTapWY3VGEDnfojUd/Xs6 RS8Q==
X-Gm-Message-State: ANoB5pl04U7TsbOYgt63Hezjl4o7tv2wCDga6hSSDW9x5twHuqxXIizh AMe6S/49qdvZbHde+8i5DDFl2Cn8+pHnEm/lFsrHftxORoPP9Xxs
X-Google-Smtp-Source: AA0mqf4lCwMBKLsyTBL8W0r6xVwB2+6H2J0mqrf0arAQxmuCRacbyHV/vpkBL3bKy+0HDxYLOsRJqAI2KI/5WhYY8L0=
X-Received: by 2002:a92:a007:0:b0:2f9:a2f3:9149 with SMTP id e7-20020a92a007000000b002f9a2f39149mr11850196ili.278.1668623710995; Wed, 16 Nov 2022 10:35:10 -0800 (PST)
MIME-Version: 1.0
References: <CAHbrMsAPOw-PRHOh9OO1fU3tkN2ywWvAihG-2xWyu_SPgTYzLQ@mail.gmail.com> <333D208F-05DF-44E3-95D1-D8B01E1BEA98@sharp.fm> <CABcZeBM573hZHwsDR9T3+WWdKzkk3abVefVuMnKDuf7hr9qOdQ@mail.gmail.com> <B6AC1A18-822B-4AA8-8116-12F1F8E7421B@sharp.fm>
In-Reply-To: <B6AC1A18-822B-4AA8-8116-12F1F8E7421B@sharp.fm>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 16 Nov 2022 10:34:33 -0800
Message-ID: <CABcZeBNG0ErdzQpo4Y6778Jg+esW=LzcAKckZ9ZOsZYExuAZRg@mail.gmail.com>
To: Graham Leggett <minfrin@sharp.fm>
Cc: Graham Leggett <minfrin=40sharp.fm@dmarc.ietf.org>, Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>, secdispatch@ietf.org, Roman Danyliw <rdd@cert.org>
Content-Type: multipart/alternative; boundary="0000000000008ee38205ed9abbd6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/SR3OJ4-zIDvbvVys1gVvn3tizO0>
Subject: Re: [Secdispatch] Marking SPKAC as Historic
X-BeenThere: secdispatch@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Security Dispatch <secdispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdispatch/>
List-Post: <mailto:secdispatch@ietf.org>
List-Help: <mailto:secdispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Nov 2022 18:35:14 -0000

It seems to me that there are several questions here.

First, whether the IETF should do something in this area at all. The
primary use case you are citing is for built-in cryptographic key
generation in browsers. For the reasons indicated in that TAG finding,
and others, such as the existence of WebAuthn, browser makers aren't
really that interested in having key generation baked into browsers.
(or, for that matter, TLS client auth). I agree that the format
of the CSR is not really that relevant to this question.

You're of course correct that one could write a WebExtension to do
this. The question then becomes whether there is in fact a critical
mass of people (extension authors, users, etc.) that makes it
worthwhile for the IETF to standardize work in this area. So far
we've heard from you, but in order for us to start something here,
we'd need some other people to speak up.


Second, we have the question of the format. You suggested two
main uses for this format:

1. Encapsulating CSRs.
2. Using it for other protocol bindings to the key (perhaps
   I misunderstood here).

For the reasons I indicated in a previous e-mail, SPKAC isn't
a good fit for the protocol binding case, which leaves us with
CSRs. But we already have a format for CSRs, which is to say
PKCS#10, which is conveniently already supported by CAs. So,
the question there is really why SPKAC is enough better to
make it worth having two things.

Finally, as others have noted, the burden of persuasion is on you
here: the IETF operates by rough consensus and the default is that
IETF does nothing here, and if you think it should be recommended,
then you need to convince people that it should; the test is not
whether you are persuaded that we should not recommend SPKAC.

-Ekr

On Wed, Nov 16, 2022 at 8:32 AM Graham Leggett <minfrin@sharp.fm> wrote:

> On 11 Nov 2022, at 21:48, Eric Rescorla <ekr@rtfm.com> wrote:
>
> This is not the only reason it was removed. For instance, here is the W3C
> TAG
> writeup of concerns around keygen:
> https://github.com/w3ctag/wiki/wiki/keygen
>
>
> The document above was source material for the draft. The key takeaways
> above are a) MD5 bad, and b) various concerns around user experience. What
> wasn’t shown was any concrete data to back up the claims around the user
> experience, given they were talking about something that had at the time
> been in production for twenty years. Weirdly, in all the analysis, “the
> format of the proof of possession message wasn’t written down anywhere” was
> never mentioned.
>
> The focus on “is this supported in web browsers” is largely irrelevant in
> 2022, because web browsers now have Native Messaging Browser Extensions as
> part of Web Extensions, which allow a webpage to access native code on a
> given machine. In addition, the days of “the certificate store is in the
> browser” is now gone, with the browsers deferring to the operating system’s
> certificate store.
>
> What this means is, a Web Extension can be built that solves the key
> distribution problem for all browsers today, and if the user experience is
> not up to scratch, someone else can write a better Web Extension. None of
> this needs cooperation from browser makers.
>
> What is important is this Web Extension and the better one that might
> replace it need a standard to follow. Every certificate authority public
> and private coming up with their own protocol is awful, that’s why
> standards exist.
>
> Which standard to follow? One that already exists, is already widely
> deployed, is already audited as part of crypto libraries, and has been in
> production on a wide range of operating systems for 25 years, or something
> brand new?
>
> Or to put it another way, why does a certificate authority have to spend
> hundreds of thousands / millions of dollars coming up with something new
> when they can spend nothing and use what is already there?
>
> This is why the question “if it is not recommended, why is it not
> recommended” is so important. If people are being asked to invest large
> amounts of money to replace something that already exists, it needs to be
> for a good reason.
>
> The only issue we’ve seen to date is “MD5 bad” and that’s been fixed. Is
> there anything else?
>
> More broadly, WebAuthn is the preferred solution for many if not most of
> the
> applications for which TLS client auth with keygen was used.
>
>
> WebAuthn appears to solve web login, which happens later.
>
> Regards,
> Graham
> —
>
>