Mike, When do you expect to have this ready? And assuming the shepherd agrees it's ready for AD review...
Thanks, Kathleen On Thu, Nov 12, 2015 at 9:31 PM, Mike Jones <[email protected]> wrote: > Thanks, James. I’ll cover that case in the rewritten security > considerations. But at least in that case it “fails safe” by rejecting the > JWS due to the apparently bad signature. (That’s what the first sentence of > paragraph three of the current security considerations section is about; > I’ll try to make that clearer.) > > > > -- Mike > > > > From: Manger, James [mailto:[email protected]] > Sent: Thursday, November 12, 2015 6:23 PM > To: Mike Jones; Jim Schaad; [email protected] > > > Subject: RE: [jose] JWS Unencoded Payload Option spec addressing shepherd > comments > > > >> Do see any other cases in which there is a problem to address other than >> when the producer is intentionally emitting “b64”:true but signing as if >> “b64” was false? > > > > YES. > > The producer intentionally creates a proper "b64":false message, but one of > the recipients (that the producer might not have known about) hasn’t > implemented the new spec. That is less likely for a symmetric MAC that will > typically only be shared by 2 parties. But it is quite realistic for an > asymmetric digital signature that can, by design, be verified by anyone. > > > >> In my analysis, if the recipient rejects a signature that it doesn’t >> understand, I didn’t consider that a security problem. Do you agree with >> that? > > > > YES, as long as it rejects the signature because the crypto doesn’t verify, > not just because the content will generally look wrong. > > > > -- > > James Manger > > > > From: jose [mailto:[email protected]] On Behalf Of Mike Jones > Sent: Friday, 13 November 2015 12:50 PM > To: Jim Schaad <[email protected]>; [email protected] > Subject: Re: [jose] JWS Unencoded Payload Option spec addressing shepherd > comments > > > > OK, I can take a stab at rewriting it that way. > > > > It’s not that I think there isn’t ever a problem but I do think that there > are lots of real cases in which there’s only a problem if the producer is > intentionally creating a JWS designed to confuse – in which case the > producer is an attacker. Do see any other cases in which there is a problem > to address other than when the producer is intentionally emitting “b64”:true > but signing as if “b64” was false? > > > > The current security considerations text was intended to do a case analysis > of when there is and isn’t a problem, breaking things down by who implements > the extension and who doesn’t. In my analysis, if the recipient rejects a > signature that it doesn’t understand, I didn’t consider that a security > problem. Do you agree with that? > > > > While, yes, in retrospect I wish we’d talked about in person too, in > fairness, I did write to the list in my November 2nd note that “I will add > the thoughts above to the Security Considerations section”, and that’s what > I did, keeping the factual content, but attempting to change the tone from > e-mail conversational to factual. > > > > But I’ll try it your way instead, while also keeping the case analysis where > appropriate. In the meantime, please let me know your thoughts on the two > questions I asked above. > > > > -- Mike > > > > From: Jim Schaad [mailto:[email protected]] > Sent: Thursday, November 12, 2015 2:24 PM > To: Mike Jones; [email protected] > Subject: RE: [jose] JWS Unencoded Payload Option spec addressing shepherd > comments > > > > Mike, > > > > I wish that we had talked about this last week at the F2F meeting. > > > > This does not read like a security consideration, it read like an email that > is sent to the list saying that there is nothing to talk about here and it > can be completely ignored. If that is the way that you feel about this, you > need to get census that there is no problem and kill the text. > > > > How I would approach writing this consideration is as follows: > > > > 1. Describe what the problem is. While both James and I provided one > scenario that was easy to understand, it should not be thought of as the > only case that there is a problem. The basic description of the problem is > that there are now two different strings that will generate the same > signature value, without there being a weakness in the hash algorithm. > > 2. Describe the set of things that can be done to address this problem. > > a. Use the “crit” parameter > > b. Use a profile of the application that states there is only one > possible value > > c. Make sure that all implementations support the b64 parameter > > > > Jim > > > > > > > > > > > > From: jose [mailto:[email protected]] On Behalf Of Manger, James > Sent: Wednesday, November 11, 2015 4:21 PM > To: Mike Jones <[email protected]>; [email protected] > Subject: Re: [jose] JWS Unencoded Payload Option spec addressing shepherd > comments > > > > Mike, thanks for trying to explain with a page of Security Considerations > the ambiguity arising since existing (OLD) JWS implementations will silently > ignore the "b64":false signal. > > > > It is still wrong. The extra text starts by saying “there is no security > problem… since the signature will fail” when "b64":false is ignored, but > then ends by saying "crit":["b64"] is necessary when "b64":false is ignored. > It cannot be both! > > > > There is no security problem if a JWS correctly created using "b64" > > with a "false" value is received by an implementation not supporting > > the "b64" Header Parameter, since the signature will fail to verify > > and the JWS will therefore be rejected. > > … > > Only if the application dynamically switches between "false" and > > "true" values for "b64" (something NOT RECOMMENDED in Section 6), > > would it be necessary for the application to require the use of > > "crit" with a value of "["b64"]" in such application contexts. > > > > > > The signature can, in fact, still verify when "b64":false is ignored — > giving the verifier the wrong content. > > We could have chosen a different signing input to avoid all ambiguity, but > decided against that (as it was aesthetically nice to keep a lower-layer > invariant somewhere inside JWS implementations of > signing-up-to-the-2nd-dot). > > We could have required "crit":["b64"], but would prefer to avoid the extra > handful of bytes (and probably aren’t that confident that everyone > implements "crit" properly anyway). > > We could leave it to users to avoid the ambiguity at higher layers by having > totally separate contexts that do & don’t use "b64":false, trying to help > them get it right with advice about “application profiles”, “application > context”, a “NOT RECOMMENDED”, and 5 extra Security Considerations > paragraphs (though what “application” means here is not that clear). > > > > To me, this is a design failure. > > > > > > > > The extra text about trust is dangerous. > > > > If the trust established by > > verifying the signer's key does not actually establish that the > > creator is a trusted party, then this case in which JWS libraries > > supporting and not supporting the extension may respectively > > interpret the attacker's payload as being encoded or unencoded is the > > least of the application's worries. > > > > CAs issuing certificates to millions of HTTPS web sites (used to verify the > signer’s key) absolutely DO NOT establish that the creator (web site) is a > trusted party, merely what the creator’s name is. Misinterpreting what a > signer means is bad regardless of trust. > > > > -- > > James Manger > > > > > > From: jose [mailto:[email protected]] On Behalf Of Mike Jones > Sent: Thursday, 12 November 2015 2:37 AM > To: [email protected] > Subject: [jose] JWS Unencoded Payload Option spec addressing shepherd > comments > > > > Draft -04 of the JWS Unencoded Payload Option specification addresses the > shepherd comments. Thanks to Jim Schaad for his careful review. The > primary change was adding additional security considerations text, including > describing when “crit” should be used. > > > > The specification is available at: > > · > https://tools.ietf.org/html/draft-ietf-jose-jws-signing-input-options-04 > > > > An HTML formatted version is also available at: > > · > http://self-issued.info/docs/draft-ietf-jose-jws-signing-input-options-04.html > > > > -- Mike > > > > P.S. This note was also published at http://self-issued.info/?p=1474 and as > @selfissued. > > > > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose > -- Best regards, Kathleen _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
