Subject: [lamps] Fwd: Possible inconsistencies or ambiguities in RFC 8551

From: Metin Savignano <[email-masked]>
Date: Mon, 7 Dec 2020 10:06:37 +0100

Hi,

referring to my email quoted below of 7th August, may I ask if and how I would get a reply? I haven’t seen one, and I am wondering if I would have to look at some other place?

Thanks
Metin

> Anfang der weitergeleiteten Nachricht:
> 
> Von: Metin Savignano <[email-masked]>
> Betreff: Possible inconsistencies or ambiguities in RFC 8551
> Datum: 7. August 2020 um 13:01:53 MESZ
> An: [email-masked]
> 
> Dear authors,
> 
> First of all, thank you very much for your work to create a new and better version of S/MIME! 
> 
> As an author of an S/MIME app, we are working through RFC 8551 to determine the changes we have to implement in order to fully comply to the S/MIME 4.0 specs.
> 
> However, I’ve come to a point where I seem unable to understand what the RFC actually recommends with regard to the backward compatibility. I’ve also discussed this with another software developer, but we both weren’t sure how to read it. It would be awesome if you could help me with a clarification.
> 
> In the relevant scenario, the sending agent wants to send encrypted email to a recipient with unknown capabilities.
> 
> With regard to backward compatibility, RFC 8551 states in section 1.4:
> 
>    S/MIME version 4.0 agents ought to attempt to have the greatest
>    interoperability possible with agents for prior versions of S/MIME.
> 
> Although this is a very general statement, I believe it is contradictory to the description about how to decide which content encryption cipher to use in section 2.7.1.2:
> 
>    If the following two conditions are met, the sending agent SHOULD use
>    AES-256 GCM, as AES-256 GCM is a stronger algorithm and is required
>    by S/MIME v4.0:
>    -  The sending agent has no knowledge of the encryption capabilities
>       of the recipient.
> 
>    -  The sending agent has no knowledge of the version of S/MIME used
>       or supported by the recipient.
> 
> I don’t understand why we should choose AES-256-GCM if we don’t know about the recipients capabilities and S/MIME version. 
> 
> For example, if the recipient uses an S/MIME 3.2 compliant software, as I understand RFC 5751, that software need not know about AES-256-GCM. The GCM block mode is not even mentioned in earlier S/MIME versions. 
> 
> As a consequence, doesn’t the selection of AES-256-GCM contradict the "attempt to have the greatest interoperability possible with agents for prior versions of S/MIME“? 
> 
> The common capability in both S/MIME versions would be AES-128-CBC, wouldn’t it?
> 
> 
> Also, I do not really understand the following sentence:
> 
>    If the sending agent chooses not to use AES-256 GCM in this step,
>    given the presumption is that a client implementing AES-GCM would do
>    both AES-256 and AES-128, it SHOULD use AES-128 CBC.
> 
> It appears to me as if this sentence was grammatically either wrong or uses a construct that I don’t understand (I’m not a native speaker). I don’t understand what "given the presumption is that a client implementing AES-GCM would do both AES-256 and AES-128“  is meant to tell me in that context. Also, I’m not sure if the word „client“ is meant to refer to the sending or receiving client. At first, I thought it’s the receiving client, but after re-reading a few times, I’m unsure if it’s the sending agent, because I don’t understand why I should make presumptions about the receiving client implementing AES-GCM when I don’t know anything about it.
> 
> I would recommend that this sentence maybe rephrase to make it more understandable for non-native speakers.
> 
> What I would have expected in section 2.7.1.2:
> 
> To maintain "greatest interoperability possible with agents for prior versions of S/MIME“, the RFC would select AES-128-CBC if the recipient’s capabilities and S/MIME version aren’t known.
> 
> Where am I off the track?
> 
> 
> Thanks a lot!
> 
> Metin Savignano
> 
> 
> 
> 
> 
> 
>

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 8 Dec 2020 17:48:39 +0000

Hi Metin,

I am not an author/editor of RFC 8551, but I will reply with my opinions 
in order to stimulate some discussion of issues that you've raised.

On 07/12/2020 09:06, Metin Savignano wrote:

> Hi,
>
> referring to my email quoted below of 7th August, may I ask if and how 
> I would get a reply? I haven’t seen one, and I am wondering if I would 
> have to look at some other place?
>
> Thanks
> Metin
>
>
>> *Von: *Metin Savignano <[email-masked] <mailto:[email-masked]>>
>> *Betreff: **Possible inconsistencies or ambiguities in RFC 8551*
>> *Datum: *7. August 2020 um 13:01:53 MESZ
>> *An: [email-masked] <mailto:[email-masked]>
>>
>> Dear authors,
>>
>> As an author of an S/MIME app, we are working through RFC 8551 to 
>> determine the changes we have to implement in order to fully comply 
>> to the S/MIME 4.0 specs.
>>
>> However, I’ve come to a point where I seem unable to understand what 
>> the RFC actually recommends with regard to the backward 
>> compatibility. I’ve also discussed this with another software 
>> developer, but we both weren’t sure how to read it. It would be 
>> awesome if you could help me with a clarification.
>>
>> In the relevant scenario, the sending agent wants to send encrypted 
>> email to a recipient with unknown capabilities.
>>
>> Although this is a very general statement, I believe it is 
>> contradictory to the description about how to decide which content 
>> encryption cipher to use in section 2.7.1.2:
>>
>> I don’t understand why we should choose AES-256-GCM if we don’t know 
>> about the recipients capabilities and S/MIME version.

I agree with you that text from Sections 1.4 and 2.7.1.2 is contradictory.

>> For example, if the recipient uses an S/MIME 3.2 compliant software, 
>> as I understand RFC 5751, that software need not know about 
>> AES-256-GCM. The GCM block mode is not even mentioned in earlier 
>> S/MIME versions. As a consequence, doesn’t the selection of 
>> AES-256-GCM contradict the "attempt to have the 
>> greatest interoperability possible with agents for prior versions of 
>> S/MIME“?

Yes, there is contradiction in the RFC as written.

I think some implementations would value interoperability with earlier 
versions of S/MIME higher than security and others would choose the 
opposite. Text in 2.7.1.2 seems to be written with the latter case in mind.

For new implementations or implementations more concerned with security, 
using more modern crypto algorithms can be a good default.

>> It appears to me as if this sentence was grammatically either wrong 
>> or uses a construct that I don’t understand (I’m not a native speaker).
You are right, the above seems wrong. I think "is" needs to be dropped 
after "presumption".
>> I don’t understand what "given the presumption is that a client 
>> implementing AES-GCM would do both AES-256 and AES-128“  is meant to 
>> tell me in that context. Also, I’m not sure if the word „client“ is 
>> meant to refer to the sending or receiving client. At first, I 
>> thought it’s the receiving client, but after re-reading a few times, 
>> I’m unsure if it’s the sending agent, because I don’t understand why 
>> I should make presumptions about the receiving client implementing 
>> AES-GCM when I don’t know anything about it.
I think the text is trying to say that as the client supports AES, it is 
likely to support AES-128 CBC.
>> To maintain "greatest interoperability possible with agents for prior 
>> versions of S/MIME“, the RFC would select AES-128-CBC if the 
>> recipient’s capabilities /and/ S/MIME version aren’t known.
>>

Best Regards,

Alexey

---

From: Sean Turner <[email-masked]>
Date: Wed, 23 Dec 2020 13:11:55 -0500

Hi! Sorry it’s taken me forever to get to this.

I just want to be clear that the proposal here is not trying to change, what I believe and somebody else should correct me if they think otherwise, the consensus decision that GCM is the MUST.

The meta point here is that as S/MIME has moved from RC4 to tripleDES (RFC 3851 v3.1), from tripleDES to AES-CBC (RFC 5751), and now from AES-CBC to AES-GCM (RFC 8751) the logic has been the same:

   If you do not know what the receiving side
   supports send the best you got.

There is no negotiation so better to err on the side of caution (for human controlled agents) even (s2.7.2) "if there is a possibility that the recipient will not be able to process that algorithm."

I would not read the paragraphs in question as a cookbook to get the most interoperability. If we want that, then we either switch to plaintext or we would need to decide on which version to most interoperable with. I would hazard a guess that that CBC based on v3.2 wouldn’t be the choice but instead tripleDES based on v3.1/v3.0.

You should also note that there is a big out in s2.7.1 in the last paragraph. All of 2.7.1.* is a SHOULD.

WRT the ambiguity between s1.4 and s2.7.1.2, I am not so sure there is one as I consider s1.4 to be feel good deployment consideration text lacking any requirements. It provides some history for readers unaware of it. But, that “ought” in s1.4 only applies some of the times, e.g., if this is a high security environment maybe do not use RC4 as specified in v2.

I could go either way on removing the “is”. I think it is wordy, but not necessarily wrong. Then again I am no grammar scholar. I would certainly not object to an editorial errata if the WG felt it necessary. Some options:

ORIGINAL (wordy):
given the presumption is that a client implementing 
MAYBE (less wordy):
given the presumption that a client implementing
OR (even more wordy):
given that the presumption is that a client implementing
OR (even less wordy):
assuming a client implementing

Alexey is right in that what it is trying to say is that if a client supports AES it’s like to also support CBC. That is there so that implementations do not choose tripleDES, which was the old SHOULD-.

spt

> On Dec 8, 2020, at 12:48, Alexey Melnikov <[email-masked]> wrote:
> 
> Hi Metin,
> 
> I am not an author/editor of RFC 8551, but I will reply with my opinions in order to stimulate some discussion of issues that you've raised.
> 
>>> For example, if the recipient uses an S/MIME 3.2 compliant software, as I understand RFC 5751, that software need not know about AES-256-GCM. The GCM block mode is not even mentioned in earlier S/MIME versions.  As a consequence, doesn’t the selection of AES-256-GCM contradict the "attempt to have the greatest interoperability possible with agents for prior versions of S/MIME“?
> I think some implementations would value interoperability with earlier versions of S/MIME higher than security and others would choose the opposite. Text in 2.7.1.2 seems to be written with the latter case in mind.
> 
> For new implementations or implementations more concerned with security, using more modern crypto algorithms can be a good default.
> 
>>> It appears to me as if this sentence was grammatically either wrong or uses a construct that I don’t understand (I’m not a native speaker).
> You are right, the above seems wrong. I think "is" needs to be dropped after "presumption".
>>> I don’t understand what "given the presumption is that a client implementing AES-GCM would do both AES-256 and AES-128“  is meant to tell me in that context. Also, I’m not sure if the word „client“ is meant to refer to the sending or receiving client. At first, I thought it’s the receiving client, but after re-reading a few times, I’m unsure if it’s the sending agent, because I don’t understand why I should make presumptions about the receiving client implementing AES-GCM when I don’t know anything about it.
> I think the text is trying to say that as the client supports AES, it is likely to support AES-128 CBC.
>>> 
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm