On May 1, 2014, at 1:10 PM, Mike Jones <[email protected]> wrote:
Yes, I realize that I haven't revised the security considerations yet. I
started to do it and realized that it was a more intricate exercise than I'd
originally anticipated, so decided to get the -26 drafts out with the easy
stuff first, for working group review. These mostly address comments by you,
Scott, Hannes Tschofenig (which was actually a comment on JWT, but that applied
to JOSE as well), and Antonio Sanso.
WORKING GROUP: I would appreciate any specific suggestions on additions that
you'd like to have made to the security considerations section at
http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-26#section-8.
I also realize that I still need to write the note to David McGrew.
Kathleen, can you point us to the XML equivalents of certificate thumbprints
that you used? That could be interesting. FYI, I also submitted an individual
-00 JSON thumbprint draft last month at
http://tools.ietf.org/html/draft-jones-jose-jwk-thumbprint-00 (because the need
for a JSON-based thumbprint came up in practice), but I'm not proposing that we
try to jam it into JWS at this point. It's fine for that to be work after a
recharter, should the WG want to take it up.
Best wishes,
-- Mike
-----Original Message-----
From: Kathleen Moriarty [mailto:[email protected]]
Sent: Thursday, May 01, 2014 10:47 AM
To: Mike Jones
Cc: [email protected]
Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms
Hi Mike,
Thanks for posting the updated draft. At a minimum, the security
considerations update still needs to be updated. I'd like an okay from Jim,
the document shepherd when he thinks this is all ready in case I am missing any
other open issues. The rest is in-line as this seems to summarize all of the
issues and there were discussions in other threads that I would prefer to not
see them get lost.
On Thu, May 1, 2014 at 3:09 AM, Mike Jones <[email protected]> wrote:
The algorithm name “RSA-OAEP-256” for RSAES OAEP using SHA-256 and
MGF1 with
SHA-256 has been added at
http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-26#sect
ion-4.3,
per your request, Kathleen.
-- Mike
From: jose [mailto:[email protected]] On Behalf Of Mike Jones
Sent: Friday, April 25, 2014 6:38 PM
To: Kathleen Moriarty; Jim Schaad
Cc: [email protected]; [email protected]
Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms
Thanks, Kathleen. Comments are inline, marked “Mike>”…
-----Original Message-----
From: jose [mailto:[email protected]] On Behalf Of Kathleen
Moriarty
Sent: Friday, April 25, 2014 2:07 PM
To: Jim Schaad
Cc: Mike Jones; [email protected];
[email protected]
Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms
Sorry for the delay in my response. I'll answer in-line below.
Thanks!
On Thu, Apr 17, 2014 at 5:20 PM, Jim Schaad <[email protected]> wrote:
From: jose [mailto:[email protected]] On Behalf Of Mike Jones
Sent: Thursday, April 17, 2014 10:46 AM
To: Kathleen Moriarty; [email protected]
Cc: [email protected]
Subject: Re: [jose] AD review of draft-ietf-jose-json-web-algorithms
Thanks for taking the time to do the review, Kathleen. Responses are
inline, flagged by “Mike>”. I also pasted your follow-on note in and
responded to it as well.
From: Kathleen Moriarty [mailto:[email protected]]
Sent: Thursday, April 17, 2014 7:51 AM
To: [email protected]
Cc: Mike Jones; [email protected]
Subject: AD review of draft-ietf-jose-json-web-algorithms
Hello Mike & JOSE members,
I am working my way through the requested reviews to progress the
JOSE
drafts and can see a lot of work has been done, thank you. As I read
through the Algorithms (JWA) draft there are some changes that will
need to be made to avoid problems during the IESG review. This is a
pretty big change for the draft, but will help make the review and
approval faster.
Typically, the lists of algorithms are handled through a draft update
as opposed to creating an IANA registry. A good example is a recent
update of a draft in the IPSECME working group so you can see the
structure and the precedence for this model.
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-esp-ah-reqts
Mike> So you’re suggesting that future JWA drafts might obsolete the
Mike> current
one, much like draft-ietf-ipsecme-esp-ah-reqts will obsolete RFC
4835,
which obsoleted RFC 4305, etc.? If so, could work on revising the
JWA
draft accordingly and send proposed changes to the working group.
KM> I am not sure where Jim's response is, but I have been looking
into this. My initial message came after some conversations with
Sean. In response to your posts, I reached out to a couple of other
ADs who may have had concerns and *think* we are okay as long as the
registries will be used with a designated expert review to add to the
registry. If a draft is required for an update, that would cause
problems as opposed to a draft with no registries. Sorry for the confusion
here.
Mike> Jim’s response is at
http://www.ietf.org/mail-archive/web/jose/current/msg04071.html,
starting with “[JLS] Kathleen, I don’t know that I agree with this
statement. There are a number of different places where IANA
registries are used for the purpose of having lists of algorithms.”
All the registries established already require expert review, as
described at
http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-25#section-7.
So it sounds like we should be OK. That’s good. Thanks for working
the issue.
Now for other edits and questions:
Section 3.6 - Can you explain why would this be included? If you are
not going to sign, I am not sure why one would use JOSE at all.
Mike> This is included to enable representing content that is
Mike> optionally
signed in protocols using JWS. Having this means that whether or not
the content is signed, it can use a uniform representation, which is
easy to parse. This is in production use, for instance, to enable
OAuth authorization request messages that are optionally signed.
Sometimes content need not be signed at the JWS level because it’s
integrity protected by other protocol layers – in particular, often
by
the use of TLS. Another use case is where signing adds additional
optional value, but where there’s no harm in using unsigned content –
for instance, while normal OAuth requests are inline and unsigned, a
registered extension enables request parameters to be passed by
reference, rather than by value; the object referenced containing the
parameters is a JWS; the JWS can optionally be signed. The current,
carefully refined treatment of “none” is the result of substantial
mailing list discussions and discussions on working group calls.
While a less parallel treatment of unsigned JWSs was proposed in
http://trac.tools.ietf.org/wg/jose/trac/ticket/36, this alternative
syntax was rejected by the working group in favor of the current approach.
KM> I responded to Vladamir on this one and would just like to know if
there is WG consensus behind the decision. Can you point me to
discussions on this?
Mike> Brian Campbell did a good job summarizing the consensus in his
Mike> note
http://www.ietf.org/mail-archive/web/jose/current/msg04082.html. Jim
Schaad documented the consensus in his note closing issue #36 at the
end of http://trac.tools.ietf.org/wg/jose/trac/ticket/36.
Mike> This was extensively discussed on a thread titled “[jose] #36:
Algorithm "none" should be removed” between 7/31/13 and 8/22/13 and
then also on a follow-up thread named “[jose] Text about applications
and "alg":"none"” between 9/3/13 and 9/9/13. The latter thread
resulted from an action items from the preceding interim working group
call (the agenda for which was published at
http://www.ietf.org/proceedings/interim/2013/08/19/jose/agenda/agenda-interim-2013-jose-5).
Mike> The text agreed to by the working group that Brian referred to
Mike> was
added in draft-ietf-jose-json-web-algorithms-16, published on 9/15/13.
Jim closed the issue on 10/28/13.
My read of the threads and issue tracker was that implementations won out to
close this discussion, but that there was no consensus. There were many
involved in the discussion that provided arguments and support for not
including alg none. I'll support this as a WG decision based on
implementations, as that's how I read it. I appreciate all of the feedback on
actual use of this as it will be helpful in case this comes up during last call.
Section 5.2 - The write up of this section seems a bit more
complicated than necessary. It seems it would have just been simpler
to state that the sizes vary as required by the algorithms and key
lengths used rather than providing the differences from one to the next.
Can you simplify this?
After looking through some of the mailing list discussions, it seems
there was already agreement to slim this and other sections down by
pointing to the draft-mcgrew-aead-aes-cbc-hmac-sha2
http://www.ietf.org/mail-archive/web/jose/current/msg02276.html
Can I get an update as to where that stands, referencing what you can
from that draft as opposed to duplicating text? Thanks!
Mike> Sure. The key part of the message you cited is “Once the
Mike> McGrew
Mike> draft
has been refactored to separate the description of the calculation
steps (which JOSE is using) from the AEAD representation steps (which
JOSE is not using), and to include test vector values that show
results without performing the AEAD representation concatenations, I
agree that we'll be able to just reference it, rather than
duplicating
it.” The problem is that the refactoring was never done. The
algorithm description in
draft-mcgrew-aead-aes-cbc-hmac-sha2 is written in such a way that the
ciphertext C, as described, also includes the IV value as a prefix
and
the authentication tag T as a suffix, rather than treating each of
those as separate values. The test vectors do the same. Yes, David
added appendix B saying that the values could be treated as separate,
but the write-up does no favors to implementers, as both the core
algorithm description and the test vectors assume they are combined.
(I personally know that working out how to treat them as separate
from
David’s current draft is a tedious and error-prone exercise, having
had to do so to tease them apart for the current JWA write-up.)
David
has been asked about doing the refactoring several times by multiple
parties, but he’s a busy guy, and I don’t think it’s ever reached the
top of his queue. As it is, the JWA description is clear and
semantically equivalent and implementers have shown that they can
successfully build it. Finally, we wouldn’t want to take a normative
dependency upon a draft that appears to have been largely abandoned
(or at least neglected), as doing so could indefinitely stall
publication of RFC versions of the JOSE specs.
[JLS] I always considered this to be a sufficient refactoring to use
the mcgrew draft as a basis. I did not have the same type of
problems
with breaking the test vectors apart that you seem to have had.
KM> OK, has anyone reached out to Dave McGrew to discuss? How can we
clear this up?
Mike> I’d had in-person and phone conversations with him about it last
Mike> year,
but not much happened as a result.
Mike> I wrote more about your question at
http://www.ietf.org/mail-archive/web/jose/current/msg04074.html in
which I pointed out errors and sources of confusion in David’s draft
that would complicate life for developers and possibly result in
incorrect implementations; Jim responded at
http://www.ietf.org/mail-archive/web/jose/current/msg04075.html. I’ll
send a note to David pointing these out and offering to produce
proposed changes for him to incorporate, but unless he either decides
to devote bandwidth to advancing the draft (it’s already expired once)
or is willing to delegate it to us to do so, I think we don’t have
much choice but to continue to have a complete and accurate
description of the algorithms in the JWA doc, and let his draft
advance at its own pace. I’ll note that we also don’t have a
publication vehicle for the draft to become an RFC, because it’s not in any
working group, nor does it have AD sponsorship that I’m aware of.
Thank you, please keep us posted on the status/progress so we know how to move
forward.
Security Considerations: While it is true the content is covered in
other places, this section could benefit from improvement before it
goes to the SecDir review. The second sentence in the first
paragraph
says the
following:
Among these issues are
protecting the user's private and symmetric keys, preventing
various
attacks, and helping the user avoid mistakes such as inadvertently
encrypting a message for the wrong recipient.
It would be helpful if you could expand the text and make it more
descriptive and applicable to this document. For example, shouldn’t
the first section say user’s private asymmetric and symmetric keys?
I
assume that is what was intended with private, but it reads funny to
me without that. The only ‘attack’ or caution mentioned in the
document is for the application to prevent a user from selecting the
wrong key. Please include some attacks that developers and
implementers should be aware and cautioned on, or state that specific
attacks and considers are detailed in the subsections to follow.
Mike> OK, I can work on expanding that. There are some other attacks
mentioned in the other drafts, such as timing attacks, which can
probably at least be mentioned here. I’ll send draft text to the
list
and consult with you before doing anything to the actual drafts.
Specific suggestions from working group participants would also be
highly appreciated.
The Security Considerations section requires updating, let me know when this
has been done. Thanks!
KM> Great, thank you!
I think that's it for now. Although I do need to look through some
more of the previous conversations on the mailing list and in the
issue tracker.
I see there are some open discussions, like the one Richard raised
yesterday that need to be resolved in the document as well before we
move forward with this one. Thanks for all of your effort on this draft!!
Mike> Per my note
http://www.ietf.org/mail-archive/web/jose/current/msg04061.html, I
don’t believe that that particular issue is open. It had been
extensively discussed within the working group multiple times and the
issue was explicitly closed by the chairs, leaving the status quo in
place in which there are required algorithms for interoperability reasons.
I'm going to add one more question to the review as I had the same
thought as Scott & Burt in their review of JWA (and also in JWS).
Why
are there no other options in addition to SHA1? The response to
Scott
pointed back to early WG decisions, but I have heard this concern
from
others and have it myself, so I am not sure this one is resolved.
I'd like to revisit it.
http://www.ietf.org/mail-archive/web/jose/current/msg04020.html
Mike> If adding a new “RSA-OAEP-256” algorithm identifier for “RSAES
Mike> with
Optimal Asymmetric Encryption Padding using the MGF1 mask generation
function and the SHA-256 hash function” would make a number of people
more comfortable, including you, there’s nothing wrong with doing so.
However, it’s also not clear that it would be of much short-term
practical benefit because, at least as of the implementation survey
done in July 2012, many crypto libraries don’t expose a way to get at
this algorithm combination.
However, the same argument could be made about RSASSA-PSS, which we
did add identifiers for in the end. In short, I don’t think anyone
in
the working group would stridently object if you asked for this
additional algorithm identifier to be added. Your call…
KM> I'd say to add it. I'll have a similar comment for the JWS draft
for SHA256 support on thumbprints.
Mike> OK – I’ll add it.
Thanks, and I see Scott's review and okay as well, which is helpful.
Mike> Per your JWS comment, SHA-1 thumbprints are widely deployed.
Mike> I’m
aware of no SHA-256 certificate thumbprint deployments. I’ll note
that even if SHA-1 were completely broken, that wouldn’t be a security
issue because it’s just being used to generate a digest of publicly
available certificate information. It’s not being used to cryptographically
obscure anything.
(But that’s actually a discussion for another draft. J)
This is in place for the XML equivalents and should be possible for JSON. I
used this at least 2 years ago in the XML Oxygen editor. I believe this has
been brought up before in terms of JSON, so I am not the first. But it is
another draft... I'd like to get through these all soon :-)
--
Best regards,
Kathleen
Thanks a
bunch,
-- Mike
--
Best regards,
Kathleen
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
Thanks
again,
--
Mike
Thanks for your help!!
--
Best regards,
Kathleen
