Hi Philipp,
On Sun, Mar 26, 2023, at 10:05 PM, Phillip Hallam-Baker via Datatracker wrote:
Reviewer: Phillip Hallam-BakerReview result: Serious Issues
Thanks for your feedback. We are uncertain about what serious issues you see in the current draft. We believe that the Security Considerations of draft-ietf-calext-jscontact (which draft-ietf-calext-jscontact-vcard refers to) already address the points of your review. If you see something not covered, could you please let us know?
The small problem is that the draft does not consider the question ofgeneration loss when converting between formats repeatedly. Consider the casethat Alice sends Bob's contact to Carol. We can imagine conversions from vCardto JSON and back and the result is not necessarily what was started with and insome cases this matters. The possibility that Carol ends up communicating withsomeone who is not Bob is always a consideration.
Indeed draft-ietf-calext-jscontact-vcard allows implementations to choose other conversion rules than what we describe in the document. This is on purpose. We do also believe that the defined rules are generally a good choice and prevent implementations from inadvertently changing the contents of the converted contact data.
As for implementations purposefully changing contact data such as names and other content during conversion, the Security Considerations (section 5 in draft-ietf-calext-jscontact ) already state:
"The data being stored and transmitted may be used in systems with real-world consequences. For example, a malicious actor might provide JSContact data that uses the name of another person but insert their contact details to impersonate the unknown victim. Such systems must be careful to authenticate all data they receive to prevent them from being subverted and ensure the change comes from an authorized entity."
and
"This document only defines the data format; such considerations are primarily the concern of the API or method of storage and transmission of such files."
In extension, this also applies to converted JSContact data.
The bigger problem is that neither draft considers the security role thatcontact exchanges play when the contacts contain public keys. And what is thevalue of a contact that does not? Very little in my view.
We believe this also is addressed in the Security Considerations cited before.
There certainly is value in the cryptographic sound exchange of contact data, but we do not believe this should be part of the data format. Instead, a protocol should be defined in a separate RFC and this also may register new JSContact properties at IANA, should that be required.
Regards,
Robert
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
