Minutes for JOSE at IETF-90
minutes-90-jose-2

JOSE WG @ IETF 90
2014-07-21 (1300-1500)

The meeting was called to order by the co-chairs, Jim Schaad and Karen
OÕDonoghue. Peter Yee graciously agreed to take minutes. The note well was
reviewed, and there were no proposed changes to the agenda.

Agenda:  https://www.ietf.org/proceedings/90/agenda/agenda-90-jose
Chair slides: https://www.ietf.org/proceedings/90/slides/slides-90-jose-1.pdf

2. Open issues on four core documents (Chairs)
draft-ietf-jose-json-web-algorithms-31
draft-ietf-jose-json-web-encryption-31
draft-ietf-jose-json-web-key-31
draft-ietf-jose-json-web-signature-31

All documents have been reviewed by Kathleen Moriarty (Security AD).  There
are two issues remaining:
1) the reference draft-mcgrew-aead-aes-cbc-hmac-sha2 instead of repeating
text in the jose documents; and
2) the clarity of the wording: or use a JSON parser that returns only the lexically
last duplicate member name, as specified in Section 15.12 (The JSON Object) of
ECMAScript 5.1 [ECMAScript]
At this point the documents can go to last call, and we will resolve those
remaining topics at that time.

3. Cookbook (Matt Miller)
draft-ietf-jose-cookbook-03

Matt Miller updated the draft cookbook.  Brian Campbell and others have done
example verifications.  Brian Campbell has also provided some text updates that
Matt hasnÕt had a chance to insert yet, but he will do so shortly (timeframe is
tbd).  Then the document will be ready for WGLC.

4. JSON Web Key Thumbprint (Mike Jones)
draft-jones-jose-jwk-thumbprint-00
Slides: https://www.ietf.org/proceedings/90/slides/slides-90-jose-0.pdf

Mike Jones presented his draft on JWK thumbprints. There has been a need
identified for a thumbprint for keys that were in non-X.509 format.  This
wouldnÕt be added to the current documents, but as an adjunct.  The draft uses
SHA-256 over JWK with required key fields in UTF-8 format, with fields placed
in lexicographical order.  Ordering of characters requiring escaping is the only
tricky area Ð some sort of canonicalization would have to be done.  Or the
problem could be solved by not allowing the use of escaped characters in field
names.

Discussion:
Carsten Bormann suggested the JSON WG could solve this problem.
The JSON WG chair (Matt Miller) noted that this issue has been discussed before
but there was insufficient energy to work on the problem and no consensus was
forthcoming.
Carsten Bormann believes that a single solution for all JSON-using WGs would
be best, hence arguing for the JSON WG to solve it canonically.
Mike Jones brought up the point that so far tag values are all ASCII and donÕt
run into the problem.
Carsten Bormann likes a rule for canonicalization that says use the shortest
representation and where there are case issues, always require upper case.  A
pointer to RFC 7159 would help somewhat.
Phil Hunt says that the PRECIS WG has an algorithm that produces comparable
strings.
Mike Jones says weÕve been pretty clear that names should not be transformed
for comparison.
Matt Miller: bringing in PRECIS beyond what weÕve done with password
transforms is not a good idea.
Mike Jones: Security AD says that because no strings (except for passwords) are
intended for human consumption, nor are they normally generated by human,
we donÕt have a real problem here.
Jim Schaad: another solution: you could just omit anything that is escaped from
your output, since the mapping isnÕt guaranteed to be unique.
Mike Jones: I prefer undefined representation (possibly to be defined later)
than using that scheme.
Matt Miller: thatÕs an interesting an idea.  Or we could just use a whitelist Ð
whatever is registered for a given key is acceptable, anything else is not.
Jim Schaad: question: youÕre using required fields from the JWK.  That means
you may be missing some of the constraints I might want to put on the
JWK.  Why isnÕt that a problem?
Mike Jones: this is just about identifying the key, not conveying all of the
metadata values that may accompany the key.  With the thumbprint, you should
be able to retrieve the key and get all of those constraints.
Jim Schaad: you might have two JWKs with the same key value but different
constraints.
Mike Jones: the CFRG says that using a key for two different algorithms/uses is
not good hygiene.
Matt Miller: limiting the thumbprint to very specific fields seems like a good
idea to me.
Mike Jones, continuing: can we add a charter item for this and move it into the
WG?  It would seem like something that could move through the WG very
quickly.
Jim Schaad: The chairs and AD need to verify whether this work is within the
scope of the WG.
Kathleen Moriarty: how many reviewers would there be?  Miller is willing to do
so.  Lukewarm support from the WG for taking this on.
Karen OÕDonoghue: perhaps we should take this to the list.  In any event, the
chairs and Security AD will discuss it further.
Mike Jones: I have received enough input to do another revision of the draft.

Actions going forward:
-	Mike Jones will update the draft
-	The chairs will query the working group about taking up this work.

5. JOSE vs. Constrained Node Networks (Carsten Bormann)
https://www.ietf.org/proceedings/90/slides/slides-90-jose-2.pdf

Carsten Bormann provided an introduction to CBOR. Moving from places, to
people, to things, the expectation is for 50 billion nodes by 2020.  Node size,
cost, and complexity are all going down.  Nodes are in the 10KB data, 100 KB
code size (quite constrained) to the 50 KB data, 250 KB code size (not so
constrained).  Chip-level improvements are used to improve cost and power
usage, not performance.  These nodes use Low-power and lossy networks (LLN)
of about 100 Kb/s bandwidth (at a high loss) and 100-byte packet size.  The
point is that these types of nodes require a recalibration of what we consider
normal.  Code, state, packet transmission, and listening are all ÒcostlyÓ.  Crypto,
by comparison to network usage, is almost negligibly expensive.  The IETF
already has many relevant WGs: LWIG, 6Lo*, 6TiSCH, ROLL, CoRE, DICE, and
ACE.  In improving the situation at the application layer, compressed HTTP is
not a particularly viable solution Ð the gains arenÕt sufficient.  CoAP provides a
more tailored solution, with simple headers and requests.  CoAP is RESTful and
can proxy to HTTP.  Security is not optional for CoAP, which runs over DTLS 1.2
(and perhaps 6LoWPAN-GHC) at the 128-bit security level.  ECC (P-256) is
being embraced for its efficiency.  The constrained node engineers have been
considering suitable data formats.  JSON was considered.  Conside Binary Object
Representation (sort of a binary JSON) uses the data model of JSON with binary
representations for bit efficiency.  CBOR is a fairly compact representation
compared with other standardized formats.  So, if CBOR is the answer, what
about security for it?  The thought is that JOSE could be adapted for
CBOR.  Requirements include dealing with very small payloads, minimization of
power usage for transmission/reception, minimization of RAM usage, and
simple code (owing to the lack of code space).  Things to avoid: base64 and
JSON-encoding of data.  The ÒproposalÓ is COSE, in which each use of JOSE is
replaced by a CBOR equivalent.  Review and investigation are welcomed.

Discussion:
Mike Jones: would you use the registered algorithm names directly from JOSE?
Bormann: we donÕt want to re-invent anything, but it might be a good idea to
assign numbers to those names as a more compact representation.  Those
things are third-order optimizations, however.
Jones: Tim Bray has asked on the list if the benefits were sufficient to justify the
work.  Perhaps a side-by-side comparison would be useful.
Bormann: Tim is probably from the Big Iron world where this is far less
beneficial.  In the constrained node world, CBOR is more impactful.
Jones: the network-use minimization is a compelling argument.
OÕDonoghue: what are your plans?
Bormann: we want to implement it in order to find out how well it works in
practice.  We also need to do a deep look at the security properties to determine
if something breaks when switching to COSE from JOSE.  Perhaps this WG or a
new one would be the right place to standardize these efforts.
Jones: the security efforts in JOSE should apply fine to COSE if itÕs just a binary
mapping being done.  Many of those efforts were around delimited strings or
making sure that concatenations didnÕt have odd behaviors.

Action: None at this time. Please report back on progress.

Meeting adjourned: 14:00 EDT