CFRG minutes
Orlando, March 15
Minutes by Paul Hoffman
Text from the slides are not reproduced in minutes; see
https://datatracker.ietf.org/meeting/86/materials.html#cfrg

JOSE Security, Jim Schaad
	Security Area wants CFRG to review security implications
	Want to be able to protect more than just OpenID tokens
	Two serialization formats
		OAuth started with a URL-safe serialization
		Adding JSON serialization
	Allows for detatched content
	Sometime are sloppy about differentiating between signatures and MACs
	When URLs are used to retrieve keys, they must be HTTPS, not HTTP
	ECDSA uses NIST curves
	Lots of ways to locate keys: URLs, embedded, by hash
	JSON parsers will stop even if there is additional information is left
	Hash is over Base64 of each part
		Hashing of encoded version of the content, not just the content
	Include RSA-PSS for recommended algorithms?
		Mike Jones: A survey was taken of all web development systems
			Survey said not common
	Not all keys are wrapped
	Dave McGrew: why would you need multiple authentication tags?
		Jim: You may not want to authenticate each signer, or you may want to
authenticate the group
			Future question about whether we lose security if we don't cover the
signature type in the signature
	Survey showed that GCM is not universally provided, so can also do CBC
plus HMAC
	There is a registry for what goes into the header fields
		Can also put in OIDs or URLs
	Signing keys can specify a single algorithim that the key can be used
with
	Emphasized that keys can have the same key-id
	Arguments within the group about how to transport secret material that
comes with a key
		If secret information is kept in body, can AES-CBC be used, or do we
need real key wrap?
	Sean Turner: CFRG should advise about algorithms, maybe other bugs can
be found
	The compact encoding is there to allow carrying as a URL
	Wants firm advice by the end of April, really hopefull before the IETG
in Berlin
	Mike: Matt Miller has a draft on how to carry keys for simple wrapping
		Wants to know which algorithms would work with this
	Kevin: CFRG might want to help with future-proofing
	If a bare key comes over HTTPS, we are trusting the key server to
correctly store and identify keys
	Kevin: prefer key wrap mode because it is more conservative and will
probably degrade more slowly
	Dan Harkins: SIV mode can be used to wrap keys and allows inclusion of
associated data
	Kevin: wants more discussion on the list soon

Adopting OCB draft
	draft-irtf-cfrg-ocb, which is now expired
	There has been a lot of discussion of the IPR
	Hum for adopting as a CFRG document, most wanted
	Will be updated

Crypto algorithm catalog draft
	Not making a lot of progress
	Will set up a wiki and will crowd-source the information
		Used to collect the data
		Could also be used to point to most current versions of algorithms
	Kerberos, TLS, IPsec folks should help populate this

Diffie Hellman checks in IKEv2

Hashed-based signatures
	Dave McGrew is working on a draft on this
	All signatures use esoteric mathematics
	Only depend on the one-way property of the hash function
	Original ideas were easy to break with brute force with substitutions
	None of the hashes have fallen in the one-way property
	Even in the secure mode, it is a one-time signature scheme
	Can hash over multiple bits instead of just one
	Solution: make a tree of one-time keys with labels
	Micali patented doing efficient memory management for the tree; patent
is expired
	Is most useful for systems where there are a small number of the
signatures
		Good for the top of a signature tree
	Number-proof signature

Other comments
	Now some work on TLS using RC4 when you see the same text repeatedly
		Dave McGrew: Dan Bernstein gave an overview earlier this week
	Tero Kivenen: LWIP WG wants to maybe use CMACs instead of hashes
	Quynh Dang: wants to move their draft to RG Last Call soon
	Hannes Tschofenig: People want to use suites that are in hardware
		TLS 1.2 went to single hash
		Maybe we want to use AES everywhere?
		Maybe useful for smart objects; many already have AES hardware
encryption
		Mike St. Johns: It's even worse, the hardware only does encrypt mode
			This affects the algorithms they want to be specified
	Mike: We should consider which key protection in hardware