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

Benjamin Kaduk <kaduk@mit.edu> Thu, 05 July 2018 21:27 UTC

Return-Path: <kaduk@mit.edu>
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 927D6130DD3; Thu, 5 Jul 2018 14:27:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 tb8d1LmWiEoE; Thu, 5 Jul 2018 14:27:24 -0700 (PDT)
Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58430124D68; Thu, 5 Jul 2018 14:27:24 -0700 (PDT)
X-AuditID: 12074423-60bff700000039bd-ad-5b3e8d3b140d
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id AE.85.14781.B3D8E3B5; Thu, 5 Jul 2018 17:27:23 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w65LRLkW023471; Thu, 5 Jul 2018 17:27:22 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w65LRGLF001123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 5 Jul 2018 17:27:19 -0400
Date: Thu, 5 Jul 2018 16:27:16 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Jim Schaad <ietf@augustcellars.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-lamps-rfc5751-bis@ietf.org, lamps-chairs@ietf.org, SPASM <spasm@ietf.org>, Russ Housley <housley@vigilsec.com>, Eric Rescorla <ekr@rtfm.com>
Message-ID: <20180705212716.GQ60996@kduck.kaduk.org>
References: <153079945499.11322.17868589339590763702.idtracker@ietfa.amsl.com> <00a901d41484$2494b0f0$6dbe12d0$@augustcellars.com> <CABcZeBM8TPnQCb_JkE3CEGE2rSCNLEUkRAtAu8iui09YRJJPhg@mail.gmail.com> <00ac01d41488$a71cfe70$f556fb50$@augustcellars.com> <CABcZeBNnSJwqSpxB_kTDnB41PNT7ORWWmW-Z7dTD42jeE+r7-w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CABcZeBNnSJwqSpxB_kTDnB41PNT7ORWWmW-Z7dTD42jeE+r7-w@mail.gmail.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJKsWRmVeSWpSXmKPExsUixG6nomvdaxdtsPISq8XtH7uZLVa8Psdu 8erFTXaLGX8mMlusnv6dzeLy3LVsFvOuJTuwe2ycM53NY8mSn0wekx+3MXusuvOFNYAlissm JTUnsyy1SN8ugSvj8fZVjAUbKiraW34zNjDeiO5i5OSQEDCRaOt9yNbFyMUhJLCYSaJr9W4W CGcDo0T3ppesEM4VJom1m+YDlXFwsAioSKw4WgXSzQZkNnRfZgaxRQTUJbauvskEYjMLHGeU mLU4FcQWFkiTmP92AxuIzQu07e+7M4wQM08wSXzt3wyVEJQ4OfMJC0SzlsSNfy+ZQHYxC0hL LP/HARLmFAiUOL93B1iJqICyxN6+Q+wTGAVmIemehaR7FkL3AkbmVYyyKblVurmJmTnFqcm6 xcmJeXmpRbpmermZJXqpKaWbGMGh7qK8g/Fln/chRgEORiUeXgZpu2gh1sSy4srcQ4ySHExK orz+7UAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrx7A4FyvCmJlVWpRfkwKWkOFiVx3pxFjNFC AumJJanZqakFqUUwWRkODiUJ3jfdQI2CRanpqRVpmTklCGkmDk6Q4TxAw3+A1PAWFyTmFmem Q+RPMepy/Hk/dRKzEEtefl6qlDjvK5AiAZCijNI8uDmgFCWRvb/mFaM40FvCEKN4gOkNbtIr oCVMQEsmCoAtKUlESEk1MDKG+UQKu7Vuzrqs/+r3o8J531bM2Ss5J6E5uuE/+5uY3oafP9Mk /W9tbm6YWbNn2URmv2a36dNup8xPeNm/Y9+0r9kT7vbPmxVWpRXDEMh89FDUqdQFX17paLw1 XOwfwMGWV3y3Zz1DqlmM0/zfqTqHwyU3an57Ye8sX3vdUt7konqdqmUKtxJLcUaioRZzUXEi AGjns4IsAwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/KrfPf9FB42nkr4Q-9LIDTp9NIsU>
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 21:27:28 -0000

In particular, on the call, we had multiple conflicting
interpretations/guesses as to what the political decision was, so the
current text is at best unclear.  But I think Ekr's point about the text
perhaps not even being needed is also pretty accurate.

-Benjamin

On Thu, Jul 05, 2018 at 11:23:48AM -0700, Eric Rescorla wrote:
> Sorry, I'm still confused. I believe that standard IETF policy is to prefer
> the CFRG curves going forward, with protocols needing various levels of
> support for the NIST curves. I think that that's uncontroversial and only
> depends on the fact that the CFRG curves are more modern, but there are
> environments where the NIST curves are needed. I guess any point in this
> space is political in the sense that it's more about balancing competing
> interests than any particular technical decision, but lots of things are
> like that. What makes this special?
> 
> As a side note, who actually is claiming that the NIST curves aren't secure?
> 
> -Ekr
> 
> 
> On Thu, Jul 5, 2018 at 10:50 AM, Jim Schaad <ietf@augustcellars.com> wrote:
> 
> >
> >
> >
> >
> > *From:* Eric Rescorla <ekr@rtfm.com>
> > *Sent:* Thursday, July 5, 2018 10:23 AM
> > *To:* Jim Schaad <ietf@augustcellars.com>
> > *Cc:* Benjamin Kaduk <kaduk@mit.edu>; The IESG <iesg@ietf.org>;
> > draft-ietf-lamps-rfc5751-bis@ietf.org; lamps-chairs@ietf.org; SPASM <
> > spasm@ietf.org>; Russ Housley <housley@vigilsec.com>
> > *Subject:* Re: Benjamin Kaduk's Discuss on draft-ietf-lamps-rfc5751-bis-10:
> > (with DISCUSS and COMMENT)
> >
> >
> >
> >
> >
> >
> >
> > On Thu, Jul 5, 2018 at 10:18 AM, Jim Schaad <ietf@augustcellars.com>
> > wrote:
> >
> >
> >
> > > -----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>; 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/stat
> > ement/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.
> >
> >
> >
> > What is a political decision?
> >
> >
> >
> > - Supporting the NIST curves?
> >
> > - Supporting the CFRG curves?
> >
> > - Supporting both?
> >
> >
> >
> > -Ekr
> >
> >
> >
> > [JLS]  Do you remove the NIST curves or at least demote the requirements
> > to implement them as there are people who believe that they are not secure.
> >
> >
> >
> > Jim
> >
> >
> >
> >
> >
> >
> > >
> > >
> > > ----------------------------------------------------------------------
> > > 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
> >
> >
> >
> >