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

Eric Rescorla <ekr@rtfm.com> Thu, 05 July 2018 17:24 UTC

Return-Path: <ekr@rtfm.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 6EFDF130F08 for <spasm@ietfa.amsl.com>; Thu, 5 Jul 2018 10:24:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 piNg6fDOf3Hf for <spasm@ietfa.amsl.com>; Thu, 5 Jul 2018 10:24:04 -0700 (PDT)
Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72683130DE1 for <spasm@ietf.org>; Thu, 5 Jul 2018 10:24:04 -0700 (PDT)
Received: by mail-yb0-x229.google.com with SMTP id r3-v6so3509939ybo.4 for <spasm@ietf.org>; Thu, 05 Jul 2018 10:24:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9gL+VCHgmWY3W//glWGuM6Z9jx+T2+BckvoxAZLhWoo=; b=TnRuDvDrOjcjVgaqwGkCc++3WoL1J7H1Agyb/CG6OaKTxlcONMUHlFnjo+MUbYYWqK Wv+ZouZsY2FczuQ/B66UjzWz4265iXCMoZf2eO5072w2xIXbuLikLGYHUfRyXKx9HWJP 1/MA8+wTIEvT814FvUsdH8aUOEl5V/OijupANtngBvhiWCGz3VjjEjyJWzqTVK2KpxV8 6dCnNy9sL9k9g5z+2EKCIhvZbtYyniFkOk2N2XSU+05acbvLt+7dUnIoiqywRZBlTSET FmvxLtlU5vvgILfcQQNveMbiVcliWO2pdfQk1VAaVD5fNAxrL9v2SHCVZpwT5kZNlfIl nyuw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9gL+VCHgmWY3W//glWGuM6Z9jx+T2+BckvoxAZLhWoo=; b=XunjI1vKgsjt7JHfLxl3dBlQ7Yp0I06cB/IL73sIWacBAJnZvuXDwKDFUgronrjJQu Vl9+aCmAqbvYWTtMgsaZ5wStvQ2VM3mRaYSlg2S6RC6udtgYZuHHpYcN6WuM/0iseR+R QABOAb3zdgUwgeu1pbYq2mbFHiQunrtP+KYv27eQCtfU9TlHQYlCpPwCoAju/EgqlOJJ EfPs2RGU6c5JzzSpLYMlDeXWT10VvZvH4++5BBdEVn/8XKW3CKvxrYO/IGNpXMsV3uTV +uQrqPIERsWPYxXSPgOD0rsgo4amvfNOwsF8uNxthC5c38prawL+HbOT1YsHz/7ut1lO fHqQ==
X-Gm-Message-State: APt69E02zxOo6OihS4AJmg0NE0O5Hi8D3G2vR3dsNYYhUceSdLJB9zSp 2o8c8kqYbRgVAB+rkkO4/7LVbDVJcVjrMSyxRp/N2Q==
X-Google-Smtp-Source: AAOMgpf8NyUebPaT7BSUJGPYefueH7eV6JVAIJp41E7a1TBIC3CzdmY5SlwCzw+oBZm64/F2NYwqnfCHFBAYpQ4ROEo=
X-Received: by 2002:a25:3496:: with SMTP id b144-v6mr3729963yba.275.1530811443596; Thu, 05 Jul 2018 10:24:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Thu, 5 Jul 2018 10:23:23 -0700 (PDT)
In-Reply-To: <00a901d41484$2494b0f0$6dbe12d0$@augustcellars.com>
References: <153079945499.11322.17868589339590763702.idtracker@ietfa.amsl.com> <00a901d41484$2494b0f0$6dbe12d0$@augustcellars.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 5 Jul 2018 10:23:23 -0700
Message-ID: <CABcZeBM8TPnQCb_JkE3CEGE2rSCNLEUkRAtAu8iui09YRJJPhg@mail.gmail.com>
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>
Content-Type: multipart/alternative; boundary="00000000000050658d057043d022"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/ydsexQvY8R_PYgWmt0o2dLCjpqI>
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:24:09 -0000

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

What is a political decision?

- Supporting the NIST curves?
- Supporting the CFRG curves?
- Supporting both?

-Ekr


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