[Anima] No certs for noreply (was: Re: Russ: Re: rfc822Name use in Autonomic Control Plane) document

Toerless Eckert <tte@cs.fau.de> Sun, 28 June 2020 17:01 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 605FF3A0DD9 for <anima@ietfa.amsl.com>; Sun, 28 Jun 2020 10:01:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.651
X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 8z6s7rKsHBSJ for <anima@ietfa.amsl.com>; Sun, 28 Jun 2020 10:01:34 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23CA93A0DD7 for <anima@ietf.org>; Sun, 28 Jun 2020 10:01:33 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 83403548011; Sun, 28 Jun 2020 19:01:28 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 7C52D440043; Sun, 28 Jun 2020 19:01:28 +0200 (CEST)
Date: Sun, 28 Jun 2020 19:01:28 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Russ Housley <housley@vigilsec.com>
Cc: Brian Carpenter <brian.e.carpenter@gmail.com>, Michael Richardson <mcr+ietf@sandelman.ca>, Ben Kaduk <kaduk@mit.edu>, anima@ietf.org, barryleiba@computer.com
Message-ID: <20200628170128.GB16571@faui48f.informatik.uni-erlangen.de>
References: <9584c5cd-c68d-ddc3-0704-da672842e359@gmail.com> <FB6127DD-A111-4E40-A095-5E3C03AA6660@vigilsec.com> <9406.1592756905@localhost> <3A92516D-B980-4231-9059-EF7234BA8610@vigilsec.com> <20200627054056.GA35664@faui48f.informatik.uni-erlangen.de> <FF181E1F-2B93-47BB-AB45-7F66D880108B@vigilsec.com> <0bec7478-2661-71fe-2263-d0f5d3e75ba9@gmail.com> <020EE6AB-26B3-419B-8D5D-F573891E7293@vigilsec.com> <20200628000654.GD41058@faui48f.informatik.uni-erlangen.de> <7A22A1E0-D5E6-408F-8D15-31E09BCCF849@vigilsec.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <7A22A1E0-D5E6-408F-8D15-31E09BCCF849@vigilsec.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/diMvX39sKhJMulux_lF_KcxiZko>
Subject: [Anima] No certs for noreply (was: Re: Russ: Re: rfc822Name use in Autonomic Control Plane) document
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 28 Jun 2020 17:01:36 -0000

On Sun, Jun 28, 2020 at 10:36:34AM -0400, Russ Housley wrote:
> > You also did not repy to my expamples about other systems where
> > email addresses are primarily used for non-mailbox purposes
> > but still encoded in rfc822Name. I have seen no outlawing of
> > this practice through IETF documents.
> It is clear that noreply@example.com has the syntax of an email address, but there is not corresponding mailbox.  For that reason, it should not appear in a certificate.  It is the the email address of the subject of the certificate.

Ok, i think this simple example allows me maybe to understand the process better.

So, if i was to write a target normative RFC explaining for example 
certificates for "customer communications" departments of example.com that would
result in creation of certs with rfc822Name noreply@example.com.

This draft passes 5 years through WG and all IETF/IESG review except SEC review.

What now are the criteria by which your opinion should be vetted as a blocker
for IESG approval of the document ?

I for once received numerous email in private that it is impossible to argue
opinions of security people in IETF technically, just because of the weight that their
names carry with IESG, so i shouldn't even try technical arguments. And i fear this is
true, and some of the other emails here (not from you) also indicate this to me.

If not, then i would like to hear what you think the process should be.

If this is  the process, then i should obviously stop making technical
arguments, accept defeat and move on. Hopefully we will at least be allowed
to document in the RFC how easier implementable and deployable solutions
where unacceptable due to ... understanding of the required semantic of
rfc822Name content. Otherwise we would loose the whole discussion here.

I already feel that the process is injust because i seem to
have to prove that what we are doing is not in violation of RFC/semantics,
which to me sounds like i have to prove our draft is "innocent", whereas
i was under the assumption that the burden of proof was opposite.

Wrt to the technical argument:

noreply@example.com is an interesting example, because i hate receiving these
emails, so i would LOVE to see a normative RFC saying that these type of
email addresses MUST NOT get certificates. However, technically i think that
is not defensible, because obviously (to me) its perfect valid for a
mailbox to not receive or not to send emails. Its to me just a controlled subject
with a name/address.

And customer harrasment departments are of course also
interested to be protected from phishing and the like, so they will
of course also use certificates for mails from noreply@example.com as soon
as enough customers would understand security (*sigh*). And i am willing
to take any bet with you, that there will be nothing from the IETF that
normatively says this should not be done. 

> Russ