RE: ESS-04 Comments

Jim,

I respectfully disagree with your recommended solution.  There are many ways
that a renegade entity can flood a mail box with messages.  There are many
easier ways to do this then to: intercept a message, decode it, add a bogus
signerInfo, sign the bogus signerInfo, re-encode it and then re-send it.  In
fact, your recommendation would make the flooding renegade entity's job
easier, because it could simply add a bogus signerInfo to every message
without even taking the time to calculate the signature value.  In summary,
I believe that the proposals in my enclosed message should be adopted.
Furthermore, I believe that the recipient should never reject a message
based solely on un-authenticated info.

- John Pawling


At 10:22 AM 3/16/98 -0800, Jim Schaad (Exchange) wrote:
> John,
>
> No this does address my problem.  It still means that I can flood your
> mailbox by intercepting all messages, adding a good signature and corrupting
> the one with the mlExpansionHistory in it.  While I agree that I don't like
> the fact that the MLA does not accept the data based on unauthenticatable
> information, that is exactly what you have in this case.  Having the MLA
> reject on unauthenticatable information is the ONLY way to fix this problem.
>
> jim
>
>
> -----Original Message-----
> From: jsp(_at_)jgvandyke(_dot_)com [mailto:jsp(_at_)jgvandyke(_dot_)com]
> Sent: Monday, March 16, 1998 9:54 AM
> To: ietf-smime(_at_)imc(_dot_)org
> Subject: RE: ESS-04 Comments
>
>
> Jim,
>
> You make an excellent point, but I don't agree with your specific
> recommendation because I don't believe that the MLA should reject a message
> based on unauthenticated information.  I believe that the best way to
> resolve this issue is to change ESS so that it requires that multiple
> mlExpansionHistory attributes must be processed similar to multiple
> eSSSecurityLabel attributes (except I don't believe that mlExpansionHistory
> attributes MUST always be critical).  In addition to my original comments, I
> propose the following changes to ESS, Sec 4.1:
>
> 1) Sec 4.1, 4th para, last sent: Please make the following change:
>
> OLD: "Not all of the SignerInfos need to include mlExpansionHistory
> attributes, but in all of the SignerInfos that do contain mlExpansionHistory
> attributes, the mlExpansionHistory attributes MUST be identical."
>
> NEW: "If any of the SignerInfos included in a SignedData object include an
> mlExpansionHistory attribute, then all of the SignerInfos in that SignedData
> object MUST include an mlExpansionHistory attribute and the value of each
> MUST be identical."
>
>
> 2) Sec 4.1, 5th para: Please make the following change:  This replaces my
> original comment 11:
>
> OLD: "A recipient SHOULD only process an mlExpansionHistory attribute if the
> recipient can verify the signature of the SignerInfo which covers the
> attribute. A recipient SHOULD NOT use an mlExpansionHistory attribute which
> the recipient cannot authenticate."
>
> NEW: "A recipient MUST verify the signature of the SignerInfo which covers
> the mlExpansionHistory attribute before processing it. A recipient MUST NOT
> process an mlExpansionHistory attribute which the recipient has not
> verified."
>
>
> These new comments combined with my original comments result in the
> following text for the last three paragraphs in Sec 4.1:
>
> "There can be multiple SignerInfos within a SignedData object, and each
> SignerInfo may include authenticatedAttributes. Therefore, a single
> SignedData object may include multiple SignerInfos, each SignerInfo having a
> mlExpansionHistory attribute. For example, an MLA can send a signed message
> with two SignerInfos, one containing a DSS signature, the other containing
> an RSA signature. If any of the SignerInfos included in a SignedData object
> include an mlExpansionHistory attribute, then all of the SignerInfos in that
> SignedData object MUST include an mlExpansionHistory attribute and the value
> of each MUST be identical.
>
> A recipient MUST verify the signature of the SignerInfo which covers the
> mlExpansionHistory attribute before processing it. A recipient MUST NOT
> process an mlExpansionHistory attribute which the recipient has not been
> verified.
>
> When receiving a message that includes an outer SignedData object, a
> receiving agent that processes mlExpansionHistory attributes MUST process
> the mlExpansionHistory attribute, if present, in each SignerInfo in the
> SignedData object for which it verifies the signature. This may result in
> the receiving agent processing multiple mlExpansionHistory attributes
> included in a single SignedData object. Because all mlExpansionHistory
> attributes must be identical, the receiving application processes the first
> mlExpansionHistory attribute that it encounters in a SignerInfo that it can
> verify, and then ensures that all other mlExpansionHistory attributes in
> signerInfos that it verifies are identical to the first one encountered.  If
> the mlExpansionHistory attributes in the signerInfos that it verifies are
> not all identical, then the receiving agent MUST stop processing the message
> and MUST notify the user or MLA administrator of this error condition."
>
>
> Does that sound meet your requirement?
>
> - John Pawling
>
>
>
> At 08:08 AM 3/16/98 -0800, Jim Schaad (Exchange) wrote:
> > John,
> >
> > I have a small problem with the following change.  While I agree that it is
> > correct, there is a possiblity that this can lead to exactly the situation
> > we were trying to avoid.  If A cannot verify B's signature and B cannot
> > verify A's signature.  What is to stop them from sending messages back and
> > forth if some other item (such as a gateway) is also sticking in
> signatures.
> > 11) Sec 4.1, 5th para: Please make the following change:
> >
> > OLD: "A recipient SHOULD only process an mlExpansionHistory attribute if
> the
> > recipient can verify the signature of the SignerInfo which covers the
> > attribute. A recipient SHOULD NOT use an mlExpansionHistory attribute which
> > the recipient cannot authenticate."
> >
> > NEW: "A recipient MUST verify the signature of the SignerInfo which covers
> > an mlExpansionHistory attribute before processing it. A recipient MUST NOT
> > process an mlExpansionHistory attribute which the recipient cannot
> > authenticate."
> >
> > We perhaps should add a sentence along the lines of "If an
> > mlExpansionHistory is found in a signature which cannot be verified, and no
> > matching mlExpansionHistory is found in a verifiable signature, the MLA
> > SHOULD stop processing."
> >
> > jim