Re: [TLS] [Errata Rejected] RFC6176 (5520)

Eugène Adell <eugene.adell@gmail.com> Tue, 16 October 2018 22:06 UTC

Return-Path: <eugene.adell@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A73130E51; Tue, 16 Oct 2018 15:06:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 mne8n59p_kIR; Tue, 16 Oct 2018 15:06:36 -0700 (PDT)
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 B005F130E4B; Tue, 16 Oct 2018 15:06:35 -0700 (PDT)
Received: by mail-wr1-x42d.google.com with SMTP id q5-v6so27344781wrw.12; Tue, 16 Oct 2018 15:06:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5DRaMZb+8eyiUGToE/O391Y4w1SrgM4c0YW+qgAtK4o=; b=pk4zDpHhP/gaYzg0EzWrosPK/yU53VzdulSgDQYnBe1+ta7d7brEvco/KUFueFhQ5p 7drb1UkW6ZpoK3/iQxvJIE4pf+AVs3mnEdT4j+0toPvj4ywP//PJdGHyZGgithW+I+7n n9jugmyowQ7eVrXoODmGTa6WtrFMV+pVdgjCtNPoZ74/XQtudx01pTHXYANEYr8d847S wZLeQWTVHjE48ial8XoS5v03dl264UvYWIcfRnBPRggpEbdaR3ERnYN1enpqu+I0uoyu y43kUsMdqYHPY+4ofU9ldnraWmKsQRReYl0WqNBP3ioIbeMu4sUejlkxQCGZVrNECd7A ++nQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5DRaMZb+8eyiUGToE/O391Y4w1SrgM4c0YW+qgAtK4o=; b=NqbSsGiXv1SH+utixLsn5JuhCiQiuK7ZcyoCdJCrdl4n+uDd7+YzrmfFX9GW2p5Orh yF8YSWntKgBWBdIhMmWrZNgPzwYVYAuJrN6bwcHpTzOZ2F/rwguvW7YcUB05jExrhD8s g542dleeU0XVADHClzAuw+yQYStD+K5EzeXmA6+WTjt5H4IUSyY5KUTkhDDaDz5f75yH sKYBi7R/pG45vqCG0N9ru7HbDWitIcE18Ryd4EpcxIKTF/q9uP9BpLCJfFp3k8ARMeTO t9Jvtr7Yy/axqKuLPzyvrfw/6hY7soNaEY3Sjoj0xnWbi7tnz8YTHmett9E9kEgLe8Zv i8jg==
X-Gm-Message-State: ABuFfojgNOojKURO3n74iM+sYM7nnojDn+EwzBqmDzSy/Htd0BGWaX5w ECZ0/63FiuZx8YZpxNQVh+IUDgLxAha5uWHkjojWvCLy
X-Google-Smtp-Source: ACcGV63H0JQYk7tO+C/o78XZBcGWHuOBjDeinAoqbsUw2bJp68TD434YeGPjf+AGQ8A8McU1ZDwhM8jYPk1jcCALSpY=
X-Received: by 2002:adf:8206:: with SMTP id 6-v6mr20312475wrb.160.1539727593921; Tue, 16 Oct 2018 15:06:33 -0700 (PDT)
MIME-Version: 1.0
References: <20181011132641.BC838B804DC@rfc-editor.org> <87va62zapo.fsf@mid.deneb.enyo.de>
In-Reply-To: <87va62zapo.fsf@mid.deneb.enyo.de>
From: =?UTF-8?Q?Eug=C3=A8ne_Adell?= <eugene.adell@gmail.com>
Date: Wed, 17 Oct 2018 00:06:22 +0200
Message-ID: <CALY=zUezaSeOdD1dbdj=kSkpZmuJKHdTZ0dgp9sHUhmFhY1+fA@mail.gmail.com>
To: fw@deneb.enyo.de
Cc: turners@ieca.com, Tim Polk <tim.polk@nist.gov>, iesg@ietf.org, TLS WG <tls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000049621705785fc48f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/AwsopkWsa7QgtPXiO8_PIditZUI>
Subject: Re: [TLS] [Errata Rejected] RFC6176 (5520)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Oct 2018 22:06:39 -0000

@Florian

The document is about the SSL 2.0 security deficiencies, particularly the
ones that brought its prohibition. The solutions to these deficiencies
might also have their own problems, as it's often the case in security
related topics which look like a never-ending debate (a problem, a
solution, a new problem), and they would logically be discussed in their
own threads or we would easily make anachronistic comments. The mitigation
of a root authority has a huge impact, and requires time to solve, that's
what said at that time, although it happened much later to some issuers.
In practice we see that direct signed certificates for Internet use were
abandoned, without anyone returning back to them. Also, the HSMs are
getting more widely used, and it gives more protection to the keying
material (which is an answer to the "overexposed keys").


@Ryan

Thanks. There's also that link
https://www.ietf.org/blog/iesg-processing-rfc-errata-ietf-stream/ which is
almost saying the same. But at the same time RFC6176 is not exactly a
protocol description, it's a limited update to existing protocols that had
warned us this update would be published one day. Submitting an update for
a non technical part of this RFC doesn't make much sense too, maybe no more
than a rejected errata.

Le mar. 16 oct. 2018 à 08:12, Florian Weimer <fw@deneb.enyo.de>; a écrit :

> * RFC Errata System:
>
> > Corrected Text
> > --------------
>
> >    o  The root certificate authority keys are overexposed. The server
> >       sends only one certificate signed by a root certificate authority,
> >       which means a frequent use of this authority keys for signing new
> >       certificates. This use can lead to key loss and the compromise of
> >       all certificates previously signed including the root certificate.
> >
> > Notes
> > -----
> > Adding a deficiency.
> > Recent history showed that well-known authorities could loose their keys
> and it had a wide impact on security.
> > SSL 2.0 limits the certificate handshake message to one single
> certificate, thus making it impossible to send a certificate chain.
> > A certificate chain doesn't completely prevent key loss, but it gives
> more protection to the root certificate keys which can be stored and hidden
> until we need them again, which is much less often than without chaining.
> >
> >
> >
> >  --VERIFIER NOTES--
> >    This isn't an error in the original document. It's new text you want
> to add.
>
> I think it's also historically incorrect.  More security problems were
> caused by the ability to introduce arbitrary intermediate certificates
> by CAs than by too many direct signing operations with a root CA key.
> At least for web use, the original model (which does not allow
> delegation of trust on the CA side) might actually have been more
> approriate.  (On the RA side, delegation is of course technically
> possible under any model, and it had its share of problems, too.)
>