Re: [lamps] Ben Campbell's Yes on draft-ietf-lamps-rfc5751-bis-10: (with COMMENT)

Ben Campbell <> Wed, 04 July 2018 04:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 73A17130E3E; Tue, 3 Jul 2018 21:38:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.879
X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id u-GSD-9STNfA; Tue, 3 Jul 2018 21:38:26 -0700 (PDT)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2170E130E39; Tue, 3 Jul 2018 21:38:25 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id w644c8UW005825 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 3 Jul 2018 23:38:09 -0500 (CDT) (envelope-from
X-Authentication-Warning: Host [] claimed to be []
From: Ben Campbell <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_660B4620-685B-4D78-A1C9-31EAE19BFE01"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
Date: Tue, 03 Jul 2018 23:38:07 -0500
In-Reply-To: <047301d412ec$992cd120$cb867360$>
Cc: The IESG <>,, Russ Housley <>,,
To: Jim Schaad <>
References: <> <047301d412ec$992cd120$cb867360$>
X-Mailer: Apple Mail (2.3445.8.2)
Archived-At: <>
Subject: Re: [lamps] Ben Campbell's Yes on draft-ietf-lamps-rfc5751-bis-10: (with COMMENT)
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 04 Jul 2018 04:38:29 -0000

> On Jul 3, 2018, at 11:40 AM, Jim Schaad <> wrote:
>> -----Original Message-----
>> From: Ben Campbell <>
>> Sent: Monday, July 2, 2018 6:08 PM
>> To: The IESG <>
>> Cc:; Russ Housley
>> <>;;;
>> Subject: Ben Campbell's Yes on draft-ietf-lamps-rfc5751-bis-10: (with
>> Ben Campbell has entered the following ballot position for
>> draft-ietf-lamps-rfc5751-bis-10: Yes
>> When responding, please keep the subject line intact and reply to all email
>> addresses included in the To and CC lines. (Feel free to cut this introductory
>> paragraph, however.)
>> Please refer to
>> for more information about IESG DISCUSS and COMMENT positions.
>> The document, along with other ballot positions, can be found here:
>> ----------------------------------------------------------------------
>> ----------------------------------------------------------------------
>> I'm balloting "yes", but have some minor comments substantive comments
>> and a number of editorial comments. I mainly reviewed the diff from RFC
>> 5751.
>> Substantive Comments:
>> §2.3, 2nd to last paragraph: I don't understand what it means to say
>> recipients MAY enforce a "MUST be supported" requirement. Am I correct to
>> assume the "MUST use the weaker" only applies if the sender used both
>> key-wrap algorithms?
> No, it is possible that one could use a 128-bit content encryption algorithm, but use a 256-bit key wrap algorithm (or the reverse).  The text would apply in this case and allows for a recipient to avoid the MUST be the same length requirement if they wish.

Okay, I think the issue is the antecedent of “this” in “… MAY enforce this” is ambiguous. I read it as referring to the previous sentence’s statement that both key sizes MUST be supported.

>> §3.1.2, 2nd paragraph: The addition of "As a rule, ..." doesn't seem to add
>> information, but it does undermine the SHOULD that immediately follows.
>> (I'd count this as an editorial comment, but I think undermining a SHOULD is a
>> material issue.)
> There have actually been some people who have requested that this SHOULD be removed from the document altogether.  The feeling by some is that in the last 20 years the number of gateways which are not 8-bit compatible is now sufficiently small that there is no reason to even recommend that 7-bit transfer encoding be used here.  I don't really have any problems with undermining the SHOULD, but I would want to see some numbers about 8-bit ubiquity before removing the requirement completely.

I suggest that adding some text to that effect, even if you keep the SHOULD for now.


>> §1.5: I have trouble parsing the first paragraph. Is the comma in "... MUST
>> implement, key wrap algorithm... " intentional?
> Yes that comma is intentional.  However I am going to change it to a period.

Ah, I was trying to read it as “… algorithm was changed to a MUST-implement key wrap algorithm”. The problem was not the comma so much as “changed to a MUST implement”. I suggest  changing that to “changed to be MUST implement”. (I agree on the period.)


>> §3.1:
>> - first paragraph: "A MIME entity can be a sub-part, sub-parts of a
>>   MIME message, or the whole MIME message with all of its sub-parts."
>> I'm not sure how to parse the first comma. Is the intent of that part that the
>> entity can be sub-part or sub-parts of a message?
> Yes.  It can be one, two, a tree or the entire message.

How about “A MIME entity can one or more sub-parts of a MIME message, or a whole MIME message with all of its sub-parts”.

>> - 2nd to last paragraph: " It is up to the receiving client to decide how to
>> present
>>   this "inner" header along with the unprotected "outer" header.  It is
>>   RECOMMENDED that a distinction be made between the location of the
>>   header."
>> The last sentence partially contradicts the first one. Also, can the last
>> sentence be phrased in active voice, to strengthen the connection to the
>> client as the actor?
> Given the security difference between headers, it is RECOMMENDED that client provide a distinction between header fields depending on where they are located.
> Is that better?


>> - "A direct path needs to exist from the starting key to the key used
>>      as the content encryption key (CEK) which guarantees that no third
>>      party could have seen the resulting CEK."
>> Comma splice.
> How can it be a comma splice if there is no comma?

Ah, that was a copy-paste error. I meant this: "
 S/MIME implementations almost universally use ephemeral-static rather
   than static-static key agreement and do not use a shared secret for
   encryption, this means that the first precondition is not met.