Re: [calsify] Secdir last call review of draft-ietf-calext-jscontact-vcard-06

[Daniel Migault <[e-mail]>]

Thanks Phillip for this security review as always very complete. I just
want to clarify why the third party you request the contact information may
not be trustworthy. I am wondering if that  is because you actually are not
sure how the contact has been provisioned, or if there are any other
reasons. Typically, the information may not be registered by yourself,
not by the owner of the information - i.e. the contact -yourself or an app
that becomes rogue or later known as insecure.

I agree with Robert that significant effort has been spent to ensure the
conversion remains as smooth as  possible. My understanding is rather
partial or legacy implementation will remove information.

Exchanging this information in a trustworthy manner is not part of the data
model, but that does not hurt mentioning it.

Yours

On Sun, Mar 26, 2023, 16:05 Phillip Hallam-Baker via Datatracker <
[e-mail]> wrote:

> Reviewer: Phillip Hallam-Baker
> Review result: Serious Issues
>
> This draft does not contain a substantive security considerations which is
> arguably OK insofar as it links to the main spec which does have one and
> addresses the issue of serialization/deserialization security adequately.
>
> The small problem is that the draft does not consider the question of
> generation loss when converting between formats repeatedly. Consider the
> case
> that Alice sends Bob's contact to Carol. We can imagine conversions from
> vCard
> to JSON and back and the result is not necessarily what was started with
> and in
> some cases this matters. The possibility that Carol ends up communicating
> with
> someone who is not Bob is always a consideration.
>
> The bigger problem is that neither draft considers the security role that
> contact exchanges play when the contacts contain public keys. And what is
> the
> value of a contact that does not? Very little in my view.
>
> The contacts catalogs/address book is in my view the overlooked control
> point
> for interoperable, end-to-end secure messaging. If Alice has Bob's contact
> information in her personal contacts catalog, she can communicate with him
> without the need to rely on any other party. If not, she is reliant on a
> third
> party which is always trustED but not always trustWORTHY.
>
> All I need to establish interoperable messaging with Alice is the ability
> to
> click on a link in my contacts catalog and have it spawn off the messaging
> application Alice uses whether that is Zoom, Signal, Skype or
> CALEA-Express.
>
> The drafts don't consider this dimension at all which is a problem because
> exchange of contact information carries an implicit authentication even if
> there is no cryptographic integrity or authentication means. If Alice
> gives Bob
> her contact information, Bob is going to assume it trustworthy and
> authentic
> regardless of whether the channel itself offers any security controls.
>
> One of the best arguments for creating a JSON format for contact
> information in
> my view is precisely so that they can be wrapped in a JSON-friendly envelop
> format such as JOSE or DARE. This is exactly what I plan to do, rather than
> specify my own contact information format, I simply define a contact
> assertion
> whose payload is a JSON contact. So if Alice and Bob meet in person, they
> can
> effect an authenticated contact exchange with a 2^240 work factor by means
> of a
> QR code exchange.
>
> Obviously, the security considerations section for THAT exchange needs to
> be
> considerably more comprehensive and consider the validation of credentials,
> yadda yadda because it is asserting a high assurance exchange. But even
> where
> no authentication etc. is considered, there must be a disclaimer to state
> that
> these questions have not been considered.
>
>
>