Re: [lamps] Benjamin Kaduk's Discuss on draft-ietf-lamps-rfc5751-bis-10: (with DISCUSS and COMMENT)

Jim Schaad <ietf@augustcellars.com> Thu, 05 July 2018 17:18 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87CAE130DE1; Thu, 5 Jul 2018 10:18:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6uJQ91Einy2K; Thu, 5 Jul 2018 10:18:34 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 774B11274D0; Thu, 5 Jul 2018 10:18:33 -0700 (PDT)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 5 Jul 2018 10:14:58 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: 'Benjamin Kaduk' <kaduk@mit.edu>, 'The IESG' <iesg@ietf.org>
CC: <draft-ietf-lamps-rfc5751-bis@ietf.org>, 'Russ Housley' <housley@vigilsec.com>, <lamps-chairs@ietf.org>, <housley@vigilsec.com>, <spasm@ietf.org>
References: <153079945499.11322.17868589339590763702.idtracker@ietfa.amsl.com>
In-Reply-To: <153079945499.11322.17868589339590763702.idtracker@ietfa.amsl.com>
Date: Thu, 5 Jul 2018 10:18:04 -0700
Message-ID: <00a901d41484$2494b0f0$6dbe12d0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
Thread-Index: AQIi+HNCTYWwO8773Uu0GB5YWNsIoKPi5myA
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/NnJzHHPaOxrMPrvgZCrxI6qzAfQ>
Subject: Re: [lamps] Benjamin Kaduk's Discuss on draft-ietf-lamps-rfc5751-bis-10: (with DISCUSS and COMMENT)
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Jul 2018 17:18:37 -0000


> -----Original Message-----
> From: Benjamin Kaduk <kaduk@mit.edu>
> Sent: Thursday, July 5, 2018 7:04 AM
> To: The IESG <iesg@ietf.org>
> Cc: draft-ietf-lamps-rfc5751-bis@ietf.org; Russ Housley
> <housley@vigilsec.com>om>; lamps-chairs@ietf.org; housley@vigilsec.com;
> spasm@ietf.org
> Subject: Benjamin Kaduk's Discuss on draft-ietf-lamps-rfc5751-bis-10: (with
> DISCUSS and COMMENT)
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-lamps-rfc5751-bis-10: Discuss
> 
> 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 https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc5751-bis/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> This is not necessarily a flaw in the document, I just want to ensure that the
> decision to use the phrase "for political reasons" to describe a technical
> decision made in an IETF-stream RFC is a decision that is consciously
> approved by the IESG.  (I could not find any precedent for such a usage.)

>From my point of view this is a "political" decision.  To the best of my knowledge there is nobody who has ever found any technical reason to say that any of the NIST curves are in any way problematic.  Despite the mistrust by some, they are still required in many situations.  

> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I suspect it's too late for changing this to be a good idea, but using
> "authenticated enveloped" and in the same breath talking about how it does
> not provide proof of origination ("wait, isn't that authentication?), but it does
> provide "a level of authentication", is kind of confusing for the reader.  Could
> "integrity protection" be used to distinguish the AEAD property from proof-
> of-origin authentication?

I have lamented in the past that this is was called "authenticated encryption" rather than "integrity protected encryption" but that ship has sailed a long time ago.  If nothing else the name change would have reduced the number of times that I needed to explain to people that authenticated encryption does not imply proof of origination. 

> 
> Similarly, it might be helpful to use the term "AEAD" before the security
> considerations section.
> 
> Should the Abstract/Introduction mention that AEAD encryption provides
> non-malleability?

I don't think that is the correct thing.  I would add the following sentence to the abstract.

Authenticated Encryption provides both message integrity and data confidentiality.

> 
> Section-by-Section comments follow.
> 
> Section 1
> 
> nit: Does FAX need to be all-caps?

Probably not, but that is the was it was and is the way that I normally use it when not a verb.

> 
> Section 1.1
> 
>    In order to create S/MIME messages, an S/MIME agent MUST follow the
>    specifications in this document, as well as the specifications listed
>    in the Cryptographic Message Syntax document [CMS], [RFC3370],
>    [RFC4056], [RFC3560], and [RFC5754].
> 
> nit: is that "[CMS] documents" plural?

It depends on what you mean by CMS documents.  There is one syntax document [CMS] and then a number of associated documents which describe how to use various cryptographic algorithms with CMS.

> 
> I have been observing growing unease with Postel's Principle over time; it's
> less clear that blindly repeating it is the best position to take.

And.....

> 
> Section 1.2
> 
> BER does not appear to be used in the body text?

And neither is DER.  Not sure that I want to remove them anyway as they are concepts that people need to understand to talk to others about ASN.1 and CMS

> 
> Section 1.5
> 
> I recognize this is historical text, but to modern readers, there is not a single
> "the AES symmetric encryption algorithm" -- there are CBC modes and GCM
> modes, and v4.0 distinguishes between them.  Should this text get clarified
> about the difference?

I don't believe that this needs to be clarified.  But that may be because of how I approach things thing.  The block encryption algorithm is completely different to me than the mode.  

> 
> Section 2.5.2
> 
>    The OIDs that correspond to algorithms SHOULD use the same OID as the
>    actual algorithm, except in the case where the algorithm usage is
>    ambiguous from the OID.  For instance, in an earlier specification,
>    rsaEncryption was ambiguous because it could refer to either a
>    signature algorithm or a key encipherment algorithm.  In the event
>    that an OID is ambiguous, it needs to be arbitrated by the maintainer
>    of the registered SMIMECapabilities list as to which type of
>    algorithm will use the OID, and a new OID MUST be allocated under the
>    smimeCapabilities OID to satisfy the other use of the OID.
> 
> (nit?) "the other use" implies there will only ever be one other (two total),
> which is perhaps needlessly limiting.

Given that I cannot think of a case where this a been a problem yet, I am not too worried about the language possibly being restrictive here.  

> 
> Section 2.7.2
> 
> With "Algorithms such as RC2"; "Algorithms such as TripleDES", I'm not sure
> what to make of "such as" in these statements -- what are the attributes that
> would qualify for sufficient similarity to match the "such as", other than
> equality?

I would probably put DES in the same category as RC2 and Camellia in the same category as TripleDES.  The first category is basically - this is better than nothing but is not secure.  The second category is basically it is not known to be unsecure, but neither is it something that we recommend as using any more.  (In this case 64-bit blocks vs 128-bit blocks).

> 
> Section 3.1
> 
>    In order to protect outer, non-content-related message header fields
>    (for instance, the "Subject", "To", "From", and "Cc" fields), the
>    sending client MAY wrap a full MIME message in a message/rfc822
>    wrapper in order to apply S/MIME security services to these header
>    fields.  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.
> 
> nit: I'm not sure this last sentence is grammatical.  Do we want "between the
> locations", or "a visible distinction be made for the different possible
> locations of the header", or something else?

See the response to Ben

> 
> Section 3.1.2
> 
>    In the case where S/MIME implementations can determine that all
>    intended recipients are capable of handling inner (all but the
>    outermost) binary MIME objects SHOULD use binary encoding as opposed
>    to a 7-bit-safe transfer encoding for the inner entities.
> 
> nit: I think that some words got dropped in here; the sentence doesn't really
> parse.  I guess there's a missing "implementations" in "implementations
> SHOULD use"?

I have no problem with that - fixed.

> 
> Section 3.3
> 
>    but not signed messages does not provide for data integrity.  The
>    Enveloped-Only structure does not support authenticated symmetric
>    algorithms, use the .Authenticated Enveloped structure for these
>    algorithms.  [...]
> 
> nit: Is the '.' in ".Authenticated" correct?  (Also, that sentence looks like a
> comma splice.)

Already fixed

> 
> Section 3.5.3.2
> 
> I agree with Adam that there should be some notation in the table or
> adjacent to it that some algorithms are present only for historical
> compatibility and should be considered
> deprecated/insecure/risky/whatever.

Already fixed

> 
> Section 6
> 
>    Some cryptographic algorithms such as RC2 offer little actual
>    security over sending plaintext.  Other algorithms such as TripleDES,
>    provide security but are no longer considered to be state of the art.
>    S/MIME requires the use of current state of the art algorithms such
>    as AES and provides the ability to announce starter cryptographic
>    capabilities to parties with whom you communicate. [...]
> 
> I can't figure out what "starter" means, here.

Good question - gone.

> 
>    Modification of the ciphertext in EnvelopedData can go undetected if
>    authentication is not also used, which is the case when sending
>    EnvelopedData without wrapping it in SignedData or enclosing
>    SignedData within it.  This is one of the reasons for moving from
>    EnvelopedData to AuthEnvelopedData as the authenticated encryption
>    algorithms provide the authentication without needing the SignedData
>    layer.
> 
> nit: I think a comma before "as the" would help the last sentence.

Done

> 
> When talking about compression oracles, do we want to explicitly say that a
> common way to do so is to compress attacker-controlled data in the same
> corpus as the attacker's target data?
> 
>    mail clients deal with HTML and multipart/mixed messages.  Clients
>    MUST require that a text/html content type is a complete HTML
>    document (per [RFC1866]).  Clients SHOULD treat each of the different
>    pieces of the multipart/mixed construct as being of different
>    origins.  Clients MUST treat each encrypted or signed piece of a MIME
>    message as being of different origins both from unprotected content
>    and from each other.

I put this in as part of a response to EKR's AD review.  I will be honest in that I am completely unsure how one would do a compression attack as it assumes that you are going to do iterative things which is not the normal S/MIME way of thinking.  Also the fact that almost nobody has implemented compression is also a factor.

> 
> Do we need to cite RFC 6454 for the specific "web origin" concept (as
> opposed to just the normal English usage of the word)?

At this point in time I don't know that the idea of "web origin" is going to match what is needed for S/MIME.  I would prefer to punt this to a new document which addresses the problem directly

> 
> Appendix B
> 
>    This appendix contains a number of references to documents that have
>    been obsoleted or replaced, this is intentional as frequently the
>    updated documents do not have the same information in them.
> 
> nit: comma splice

Not sure that I agree - but fixed

> 
> Appendix B.2
> 
>    -  Hash functions used to validate signatures on historic messages
>       may longer be considered to be secure.  (See below.)  While there
>       are not currently any known practical pre-image or second pre-
>       image attacks against MD5 or SHA-1, the fact they are no longer
>       considered to be collision resistant the security levels of the
>       signatures are generally considered suspect.  [...]
> 
> nit: there seems to be (at least) a missing verb in this last sentence.

              While there are not currently any known practical pre-image or second pre-image attacks against MD5 or SHA&nbhy;1, the fact they are no longer considered to be collision resistant implies that the security levels of the signatures are generally considered suspect.

> 
>       [...] If a message is
>       known to be historic, that it it has been in the possession of the
>       client for some time, then it might still be considered to be
>       secure.
> 
> nit: maybe "and it has been"
> 

Fixed