IETF Logo Mail Archive

Re: [Secdispatch] Marking SPKAC as Historic

Eric Rescorla <ekr@rtfm.com> Fri, 11 November 2022 19:48 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 B2736C1522D0 for <secdispatch@ietfa.amsl.com>; Fri, 11 Nov 2022 11:48:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 z7X3FEB5kk7a for <secdispatch@ietfa.amsl.com>; Fri, 11 Nov 2022 11:48:44 -0800 (PST)
Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 C8666C1522B0 for <secdispatch@ietf.org>; Fri, 11 Nov 2022 11:48:44 -0800 (PST)
Received: by mail-io1-xd33.google.com with SMTP id s10so4284787ioa.5 for <secdispatch@ietf.org>; Fri, 11 Nov 2022 11:48:44 -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=A1NeN+VYZCBAvWRQhgrETLqx+yDKj4KPHtKKJ67vnvU=; b=V+r8SNWPLSW1eHtpeWt9SWNgbYZlKfa9ODqP4dPund1a0OrqsnsEHX7D6KMzZA5X8B WlKbzk+d1oUmSWHS9f5u9Y84lr3k60tJRYg1vQCddRLppgIrJ92FsCLbmSQFNSdi2CnW CKhaz+bATvDW5b5zwuCU2T14ot/BtZddevdOaFnT4jnojJt/SfAeocCOxWvXKPVW3vYm wEGIeYxV5HZ11HCNeQ/09XZg8fw2HrWbuDaYBpSbEMY3zGO6W3WZiy3Y3OH25C/2CTVA 64IuCLeq/9B5nCH2XB8Im3gNj4yWuqpoFuBSEEC2iXk9+aSwMk1As5epvjMHo5o91D4Z fhtg==
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=A1NeN+VYZCBAvWRQhgrETLqx+yDKj4KPHtKKJ67vnvU=; b=UZ2G6hX6i0H5n2NbII05UOmZrsuMNYYwjzOwyaY0DE72/4mkn54WY13O/ZO1lmP4/b DzQf3tk23Hfa1Wsw8D2IlTEx7n72720n3dz03tS+9l2hXik3W2qcghSj/9DhldQSCv2O 5+hOdb+N617SxYjhnEZQ5PR5H5MEBp3vHKNBACFI4mOT03A81jgMFuF8/fpC47bpBPuy uykGp8FX8V+YDBKEiKYyCur+YRyqhRDJ+5Ai4X6XoI1rOryNXYFbep6DqpNF5J5e8/3y 27XyyDz/joGSKGFZxv3LR9leXrGIBP9vTJXzvtxVImvbiwxhOl2FuyWf0EYdf3c80T8w G/pw==
X-Gm-Message-State: ANoB5plH/qoz9E26Xh20NfIyyChdmd/OuaCwhIqNYzTmvBAELhQ6Hl9T U92FZ6Eyci4dubKE4fHiqwCTEo1RMvjriITfgvbmbA==
X-Google-Smtp-Source: AA0mqf6BL2uH9v1vuhmeqhzbMByUk8C0sPElUEMiGvpYQsb4QQd8fJut/xe+E6Cwt/qFuNFRURvEp8fcl/FW6PYCWss=
X-Received: by 2002:a5e:d608:0:b0:6ca:31f8:b792 with SMTP id w8-20020a5ed608000000b006ca31f8b792mr1745919iom.1.1668196123893; Fri, 11 Nov 2022 11:48:43 -0800 (PST)
MIME-Version: 1.0
References: <CAHbrMsAPOw-PRHOh9OO1fU3tkN2ywWvAihG-2xWyu_SPgTYzLQ@mail.gmail.com> <333D208F-05DF-44E3-95D1-D8B01E1BEA98@sharp.fm>
In-Reply-To: <333D208F-05DF-44E3-95D1-D8B01E1BEA98@sharp.fm>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 11 Nov 2022 11:48:07 -0800
Message-ID: <CABcZeBM573hZHwsDR9T3+WWdKzkk3abVefVuMnKDuf7hr9qOdQ@mail.gmail.com>
To: Graham Leggett <minfrin=40sharp.fm@dmarc.ietf.org>
Cc: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>, secdispatch@ietf.org, Roman Danyliw <rdd@cert.org>
Content-Type: multipart/alternative; boundary="000000000000617c0705ed372dd4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/OThQGN0CtXfg2G-sH5Rh3BU5e30>
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: Fri, 11 Nov 2022 19:48:49 -0000

On Fri, Nov 11, 2022 at 7:05 AM Graham Leggett <minfrin=
40sharp.fm@dmarc.ietf.org> wrote:

> On 10 Nov 2022, at 19:59, Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>
> wrote:
>
> > Marking a document Historic at the time of publication is unusual, but
> it seems logical when we are (finally) describing a format that has seen
> little use since the 90s and is not recommended today.
>
> To clarify, the protocol saw extensive use by certificate authorities
> public and private until the mid 2010s.
>
> Can you cite sources for this not being recommended today?
>
> The removal of keygen from browsers was based on a keygen bug where MD5
> had been hard coded, which is a problem at a local implementation level.
> SPKAC as purely a message format supports any valid key and hash, and does
> not suffer any limitation imposed by MD5. The bug is here:
>
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=13518
>
> "The only supported signature algorithm is the outdated and insecure
> md5WithRSAEncryption.
>

> The element should at least have an optional signature algorithm, with the
> option to use the more secure sha1WithRSAEncryption and
> sha256WithRSAEncryption. Even better would be if md5WithRSAEncryption was
> not
> supported or at least not the default - but that might of course cause
> problems for legacy implementations.”
>

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

More broadly, WebAuthn is the preferred solution for many if not most of the
applications for which TLS client auth with keygen was used.


Our draft has a MUST level requirement not to hardcode hashes:
>
>   "New protocols using the SPKAC protocol MUST NOT mandate the use of a
>    fixed message-digest algorithm, and existing protocols using the
>    SPKAC protocol SHOULD be updated to ensure the message-digest used is
>    not fixed to a given digest."
>
> I am not finding any other reasons in the archives for not recommending
> this today.
>

See my message on this topic upthread, which lists some other reasons why we
probably would not recommend this for general use.

https://mailarchive.ietf.org/arch/msg/secdispatch/tEWgesFpYfAOV6gcXtjaJ654vYQ/

-Ekr

Regards,
> Graham
> —
>
> _______________________________________________
> Secdispatch mailing list
> Secdispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/secdispatch
>

v2.23.0 | Report a Bug | By Email