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

From: Metin Savignano <[email-masked]>
Date: Tue, 5 Jan 2021 14:11:21 +0100

Hi all,

Thank you very much for your replies and insights.

I’d like to comment back as follows:

> 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.

My memory can deceive, but I believe that when 3DES was recommended in 2004, and AES-CBC in 2010, these ciphers have already been in use for a while, didn’t they?

3DES was recommended in RFC 2633, and AES-CBC was included as SHOULD in RFC 3851, so these ciphers have been kind of announced before. AES-GCM block mode, however, is not announced or even mentioned in earlier publications, so comes as a surprise in RFC 8551.

My problem with AES-GCM is that we’ve run a few tests, and the mail clients we used were all unable to decrypt AES-GCM encrypted emails:
Outlook 2016 
Apple Mail on macOS 10.14.6 
Apple Mail on iOS 13.6 
Thunderbird 68.11.0
Considering the fact that you it’s not normally known what the other side supports, the advice to always send the best would now effectively disable encrypted communication with most clients for the moment being. Definitely something no one wants to explain their users.

> 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.

That’s correct, but as I understand the definition of SHOULD, it is relatively strong and should be ignored only in very specific cases for good reasons. However, trying to be compatible with other mail clients is by no means a specific scenario but the general scenario.

So all we can do for now is to implement AES-GCM for incoming emails only. But we can’t say we follow RFC 8551 without breaking compatibility.

From a PRACTICAL (= implementation) point of view, this IS a problem.

> 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

I can say for myself that these versions are the easiest for me to understand:

> MAYBE (less wordy):
> given the presumption that a client implementing

and

> OR (even less wordy):
> assuming a client implementing

The last one is the clearest to me. I’d suggest an edit here.

Take care
Metin

> Am 23.12.2020 um 19:11 schrieb Sean Turner <[email-masked]>:
> 
> 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.
>> 
>> 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
>>> 
>>> 
>>>> 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.
>> 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.
>> 
>>>> 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).
>> 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.
>>>> 
>>>> 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
>> Best Regards,
>> 
>> Alexey
>> 
>> 
>> 
>> _______________________________________________
>> Spasm mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/spasm
>

---

From: Russ Housley <[email-masked]>
Date: Wed, 6 Jan 2021 11:10:32 -0500

The IETF is moving toward AEAD algorithms, and it will take a while for the products to add this capabaility.  The AES-CBC is retained as a SHOULD requirement for transition.

Russ

> On Jan 5, 2021, at 8:11 AM, Metin Savignano <[email-masked]> wrote:
> 
> Hi all,
> 
>> Am 23.12.2020 um 19:11 schrieb Sean Turner <[email-masked] <mailto:[email-masked]>>:
>> 
>>> On Dec 8, 2020, at 12:48, Alexey Melnikov <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Hi Metin,
>>> 
>>>>> Von: Metin Savignano <[email-masked] <mailto:[email-masked]>>
>>>>> An: [email-masked] <mailto:[email-masked]>
>>>>> 
>>>>> Dear authors,
>>>>> 
>>> [email-masked] <mailto:[email-masked]>