Re: [art] not an erratum in RFC 6376, was Argh!!!! onto https://www.rfc-editor.org/errata.php

"Murray S. Kucherawy" <superuser@gmail.com> Thu, 21 March 2024 01:25 UTC

Return-Path: <superuser@gmail.com>
X-Original-To: art@ietfa.amsl.com
Delivered-To: art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 582D2C14F6B5 for <art@ietfa.amsl.com>; Wed, 20 Mar 2024 18:25:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.104
X-Spam-Level:
X-Spam-Status: No, score=-7.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GrKZ8zvFZQet for <art@ietfa.amsl.com>; Wed, 20 Mar 2024 18:25:55 -0700 (PDT)
Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (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 80B13C14F6EE for <art@ietf.org>; Wed, 20 Mar 2024 18:25:55 -0700 (PDT)
Received: by mail-ej1-x62a.google.com with SMTP id a640c23a62f3a-a469dffbdfeso16313666b.0 for <art@ietf.org>; Wed, 20 Mar 2024 18:25:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710984352; x=1711589152; darn=ietf.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=+bkWqGqTPLgjy6HcFID/qcjLKtAG7FsfU3IZezyxsHQ=; b=HAjninDEUx+AeUdXgvJ9Up1yeP6JidkMfc3SCSS/OMn2BZItQqR7tpJo/+OtTw4EB8 x0JOzxgNcqzgGfxh1dfGKOXzi4kuimr/AwyUjRNsIB/FmiVeqq7sRYPavKdUlC5QYsq9 PGZ0ruBwl75edM+HPM0uHrbvJndoqCFP0tR5QxbP8TkrRWtiBMwh2VSFZIjgWq1QhJuc deySJkjgsuTs/Mmpnk74jzS/1ZfWoXeXvWbumo3fYtx5sUXSvtpJjLbGu7+5BVcx6jSm yLtNFdcTzgOc/JV666HTTp5t30eTN08Uyg6WIY4nyQgRx8x0HSL0LuJZ5ZI7EBm47jKy n/8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710984352; x=1711589152; h=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=+bkWqGqTPLgjy6HcFID/qcjLKtAG7FsfU3IZezyxsHQ=; b=A0VlqscslaJgTox+3fTKR1/Zbt8IHrUtet5x653sXAa1qWqm0NomYH7RWhsrrHNWRK lZilv8ppj4fckHhxgMy1p5d0zFRB/9GetupJV4JEiwbr99R9QUAd7Jp/RJAoypgkHnnH C5cW8NlOVDWPsRtW4xUrw61eYJGyZojmQLMapgyo73LqBnuODRmhwEm/nESqpsETNb9B VFN+Cnq2zExEkNfwln1Xdi/FnwwBQA0FU83oL36jt6Wf9NCvrQrThw6JMn8AJfyDbdgl ZCRMGOVPFAcqkk5DKux+D8aER6GQ0kg3/4KRC1YaXcKhsExNjVUu+jw0PGN9tev4dim8 DOwA==
X-Gm-Message-State: AOJu0YwMwyOUf+FB0uGK7rygmkkcpXWrCXWkRIY5gggOAj/PMUcbbVmp t3IAcu7oJ2NZAzPlIlSba3AgCElf86GFhRbSwAw5acAcFhZ3c15ep3cgmcvObHCpAwtofX+v+KQ jqnQZgVAPIwEG6f8RESOyMkYh5o0myBgh3hAO3g==
X-Google-Smtp-Source: AGHT+IGaLSHr1mkslnOZipAbIyJyK4866h5S/K85IJzWbWmbd34Ui3y04+EEA3yjSmog6s1Uwd/4Wrwuf4WwzPGaNdk=
X-Received: by 2002:a17:906:354f:b0:a46:dea8:b106 with SMTP id s15-20020a170906354f00b00a46dea8b106mr4228667eja.5.1710984352341; Wed, 20 Mar 2024 18:25:52 -0700 (PDT)
MIME-Version: 1.0
References: <20240320211242.57E4085CEF48@ary.qy> <20240320223000.GvPm_uV2@steffen%sdaoden.eu>
In-Reply-To: <20240320223000.GvPm_uV2@steffen%sdaoden.eu>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Thu, 21 Mar 2024 11:25:40 +1000
Message-ID: <CAL0qLwbR6P4WQUqT9jMNpRWvXbcg5Zow-rybKD3PKB+nsi_GUA@mail.gmail.com>
To: art@ietf.org
Content-Type: multipart/alternative; boundary="00000000000089a727061421963b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/bWsYeXtRmVlZhXVZEC-uZywSSXY>
Subject: Re: [art] not an erratum in RFC 6376, was Argh!!!! onto https://www.rfc-editor.org/errata.php
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Mar 2024 01:25:59 -0000

On Thu, Mar 21, 2024 at 8:30 AM Steffen Nurpmeso <steffen@sdaoden.eu> wrote:

> But .. that is what happens in real life software?  Maybe one
> should even add a paragraph stating that, and mention the Sendmail
> milter protocol, which possibly is the culprit of what happens.
> (Though _why_ that is, since the other possibilities would have
> worked out just equally well?  Ie, literal bytes or simple
> stripping.  I cannot tell, i was not around anything email around
> 2006-2011 when that seems to have been developed.)
>
> I did ask on -dkim@ and implemented as written and said, but DKIM
> verification fails for such multiline headers from milter
> communication if RFC 6376 is followed exactly.  (Thankfully DKIM
> has a certificate test mode built-in, otherwise some reputation
> downgrade (if at all possible in my case) would surely have kicked
> in!  It is a great standard!)
>

milter provides multiline headers separated by LFs, not CRLFs.  I don't
recall why it was done this way, but that's how it's been since the
beginning.  This is in the milter API documentation, which is (or used to
be) packaged in the sendmail source tarball.  You can find it online too;
for example:

https://www.ibm.com/docs/en/aix/7.2?topic=functions-xxfi-header-callback-function

libopendkim is meant to work in any environment, so it makes no assumptions
and expects RFC-compliant input.   Therefore, opendkim (the filter, which
uses the milter API to act on messages in transit) has to convert those LFs
to CRLFs before passing multi-line headers to the library if you want
things to work properly.  If you don't, there's a good chance the header
value won't be canonicalized properly and you're going to have problems.

The library has a flag you can set to convert bare CRs and LFs to CRLFs if
you want it to do that, but that's a convenience feature meant to deal with
broken customers; as John correctly points out, it is undefined what one is
supposed to do when encountering those in the wild.  The risk here is that
if you have it do that conversion, but what goes out over the wire is not
also converted the same way, the signature will never verify.

-MSK