Re: [lamps] Last Call: <draft-ietf-lamps-rfc5751-bis-07.txt> (Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification) to Proposed Standard

[Sean Turner <[e-mail]>]

> On Apr 15, 2018, at 17:45, Jim Schaad <[e-mail]> wrote:
>> -----Original Message-----
>> From: Tim Hollebeek <[e-mail]>
>> Sent: Sunday, April 15, 2018 8:32 AM
>> To: [e-mail]; IETF-Announce <[e-mail]>
>> Cc: [e-mail]; [e-mail];
>> [e-mail]; [e-mail]; [e-mail]
>> Subject: RE: [lamps] Last Call: <draft-ietf-lamps-rfc5751-bis-07.txt>
>> (Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
>> Message Specification) to Proposed Standard
>> 
>> I just read the whole draft and have the following comments.  Overall, the
>> draft seems to be in excellent shape.
>> 
>> I apologize if any of these were discussed earlier in the process, before
> I
>> started following this draft.  More than happy to create a pull request
> with
>> the changes once I get some feedback on these.
>> 
>> Section 2.1:
>> 
>> Is it worth adding "SHOULD support SHA-3" ?
> 
> At the time this document cleared WGLC the answer was definitely no.  For
> those people who believe in having consistency in all of the hash algorithms
> the answer would still be no as there are no SHA-3 signature algorithms that
> are currently either MUST or SHOULDs.  The answer would be different if
> Ed448 was in that list.
> 
> I think that this means the answer is still no.

+1

>> Section 2.7.2. "All algorithms that use 112-bit keys are considered by
> many
>> to be weak encryption."
>> 
>> Is the LENGTH of the key, or the STRENGTH of the key intended?
>> 
>> If the former, are there other examples of 112-bit keys other than two key
>> 3DES (~80 bits of strength)?
>> If not, why not say two key 3DES to be explicit?
>> 
>> If the latter, what's the rationale for considering 112 bits of strength
>> weak for symmetric algorithms in a standard where RSA-2048 is considered
>> strong?
>> 
>> I don't find "considered by many" to be a useful statement.  After all,
> the
>> world is considered by many to be flat.

:). Yeah not my best weasel words.

> This should have been caught and updated when the security considerations
> text was updated to address the same problem.
> 
> I have modified my copy to read
> 
>                Algorithms such as RC2 are considered to be weak encryption
> algorithms.
>                Algorithms such as TripleDES are not state of the art and
> are considered to be weaker algorithms than AES.
>                A sending agent that is controlled by a human SHOULD
>                allow a human sender to determine the risks of sending data
> using a
>                weaker encryption algorithm before sending the data, and
> possibly allow
>                the human to use a stronger encryption algorithm such as AES
> GCM or AES CBC even if there is a possibility 
> 	  that the recipient will not be able to process that algorithm.

lgtm

> Jim
> 
> 
>> 
>> -Tim
>> 
>>> -----Original Message-----
>>> From: Spasm [mailto:[e-mail]] On Behalf Of The IESG
>>> Sent: Friday, April 13, 2018 5:21 PM
>>> To: IETF-Announce <[e-mail]>
>>> Cc: [e-mail]; [e-mail];
>>> [e-mail]; [e-mail]; [e-mail]
>>> Subject: [lamps] Last Call: <draft-ietf-lamps-rfc5751-bis-07.txt>
>>> (Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
>> Message
>>> Specification) to Proposed Standard
>>> 
>>> 
>>> The IESG has received a request from the Limited Additional Mechanisms
>> for
>>> PKIX and SMIME WG (lamps) to consider the following document: -
>>> 'Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
>>>   Message Specification'
>>>  <draft-ietf-lamps-rfc5751-bis-07.txt> as Proposed Standard
>>> 
>>> The IESG plans to make a decision in the next few weeks, and solicits
>> final
>>> comments on this action. Please send substantive comments to the
>>> [e-mail] mailing lists by 2018-04-27. Exceptionally, comments may
> be
>> sent
>>> to [e-mail] instead. In either case, please retain the beginning of
>> the
>>> Subject line to allow automated sorting.
>>> 
>>> Abstract
>>> 
>>> 
>>>   This document defines Secure/Multipurpose Internet Mail Extensions
>>>   (S/MIME) version 4.0.  S/MIME provides a consistent way to send and
>>>   receive secure MIME data.  Digital signatures provide authentication,
>>>   message integrity, and non-repudiation with proof of origin.
>>>   Encryption provides data confidentiality.  Compression can be used to
>>>   reduce data size.  This document obsoletes RFC 5751.
>>> 
>>> 
>>> 
>>> 
>>> The file can be obtained via
>>> https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-bis/
>>> 
>>> IESG discussion can be tracked via
>>> https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-bis/ballot/
>>> 
>>> 
>>> No IPR declarations have been submitted directly on this I-D.
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Spasm mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/spasm
>