Compress(plaintext) and Plaintext have the same information content. So the attacker hasn't revealed anything. Still not a security risk.
--Richard On Thu, Jun 27, 2013 at 11:43 AM, Peck, Michael A <[email protected]> wrote: > “zip” indicates whether the authenticated encryption is applied to > Plaintext vs Compress(Plaintext).**** > > ** ** > > By stripping “zip” an attacker could make the message appear to > successfully decrypt to Compress(Plaintext) rather than Plaintext?**** > > ** ** > > I suppose whether that could lead to something bad would be implementation > dependent, but anything that can lead to ambiguity about the contents of > the original plaintext doesn’t seem like a good idea.**** > > ** ** > > Mike**** > > ** ** > > *From:* [email protected] [mailto:[email protected]] *On Behalf > Of *Richard Barnes > *Sent:* Thursday, June 20, 2013 6:01 PM > *To:* Mike Jones > *Cc:* Jim Schaad; [email protected] > > *Subject:* Re: [jose] Field Matrix**** > > ** ** > > There was no such decision. Quoting directly from the minutes:**** > > """**** > > ** Crit Text**** > > ** ** > > Two questions were raised for dealing with the cirt field. Does the crit > field need to be signed and do the members listed in the crit field need to > be signed.**** > > ** ** > > There was no consensus in the group at this time as we adjourned for the > day**** > > """**** > > ** ** > > In order for the attack you describe to be an actual security risk, it > would need to be the case that the parameters in "crit" were > security-critical, as opposed to things that would simply cause incorrect > processing. One can certainly imagine parameters that would fall in the > latter bin; my current favorite example is a "part" parameter that would > allow fragmentation / reassembly. Because such parameters exist, it's > possible to use "crit" safely without integrity protection.**** > > ** ** > > Can we at least agree that integrity protecting "zip" is unnecessary? The > only thing that stripping / changing "zip" causes is a processing failure, > not a security compromise.**** > > ** ** > > --Richard**** > > ** ** > > ** ** > > On Thu, Jun 20, 2013 at 5:01 PM, Mike Jones <[email protected]> > wrote:**** > > There was a working group decision at the Denver meeting that “crit” must > be integrity protected. The reason for this is straightforward.**** > > **** > > If not integrity protected, an attacker could strip the “crit” field, > defeating the semantic requirement that implementations must reject the > input if a “crit” value is used that is not understood. Thus, the spec > requires that this field be integrity protected whenever used.**** > > **** > > -- Mike*** > * > > **** > > *From:* [email protected] [mailto:[email protected]] *On Behalf > Of *Richard Barnes > *Sent:* Thursday, June 20, 2013 1:52 PM > *To:* Jim Schaad > *Cc:* [email protected] > *Subject:* Re: [jose] Field Matrix**** > > **** > > You can eliminate the "protection required" field, because there aren't > any of those. **** > > **** > > Or there shouldn't be: The only security case we have is algorithm > dependent ("alg" must be protected if "alg" == "PS256", "PS512"). The only > fields for which the specs currently require integrity protection are "zip" > and "crit". Neither of these have the property that changing them would > cause a security violation, except in some application-dependent sense. So > the choice of integrity protection should be left to applications, not > fixed in the spec.**** > > **** > > --Richard**** > > **** > > On Thu, Jun 20, 2013 at 2:54 PM, Jim Schaad <[email protected]> > wrote:**** > > <no hat>**** > > **** > > Having just started looking at a design implementation, I am now more than > ever interested in seeing this matrix of fields. At the present time I > think the following columns are probably of interest:**** > > **** > > Name, must understand, use required, common vs specific, protection > required**** > > **** > > I was just looking at the alg and enc fields for JWE and realized that one > was specific – so it should be one location – and one was common – so it > should be in a different location. And then I needed to start thinking > about where it goes in terms of compacted vs one recipient vs two > recipients.**** > > **** > > Do you have an idea of when this matrix might show up?**** > > **** > > Jim**** > > **** > > **** > > ** ** >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
