Subject: Re: [dispatch] Discussion and Schedule for draft-secure-credential-transfer-01

From: Eric Rescorla <[email-masked]>
Date: Sun, 7 Nov 2021 11:03:27 -0800

I have reviewed this draft. I have provided a number of technical
comments below, but to answer the relevant DISPATCH questions:

1. I do not think that this work is ready for IETF. You present a
   specific technical solution. I have concerns about that solution, I
   but I also don't really understand the requirements. If we were to
   work on this, I think we'd first need to see them laid out.

2. Once that happens, this should probably go to SECDISPATCH.

OVERALL COMMENTS
I'm having trouble understanding the threat/deployment model of
this system. As I understand the situation for the simple case:

- The sender generates a random Secret and uses it to encrypt
  the credential for the Receiver.

- The sender stores the encrypted credential on the Relay server,
  and learns the URL (provided by the server)

- The sender sends the Secret and the URL to the receiver via
  some (unspecified) secure channel.

My first question here is why the sender doesn't just use the
secure channel that it uses to send the Secret/URL to the receiver
to send the credential? These credentials don't generally seem
that large.

I don't really think it's a reasonable assumption that
you have this kind of secure channel. Indeed, establishing
peer authentication and shared cryptographic keys seems like
the most challenging part of this entire space, so it's somewhat
odd to just assume a solution. As a concrete example, a huge
fraction of the complexity in Firefox Sync is associated with
trying to bootstrap a relatively short secret into a strong
encryption key. Therefore, I think this document really does
need to try to address this point; it may also turn out that
once you have, you have also solved whatever problem motivated
the use of the Relay.

I'm not sure why you are defining a specific API for this
system; the Relay seems primarily responsible for allowing
one side to store values and the other side to receive them.
What functionality does it require that couldn't be provided
via WebDAV [RFC 4918]. I see two main pieces:

- Creation of the URL. This seems like it could be done by the client.

- Notification. This is a useful function, but seems separable
  into a distinct notification server.

This comment also applies the the Mailbox-Correlation-ID,
which seems like it could just be in the URL.

DETAILED COMMENTS
- It's not clear to me why the URL has to be secret. Is
  this an access control measure because it is intended
  as a capability URL? Presumably the Secret is sufficient
  to protect against decryption.

- A lot of the metainformation seems to be in the clear
  rather than encrypted. This seems very unsafe, as one
  could mount cut-and-paste attacks.

- Instead of inventing your own encrypted payload format,
  why not just use CBOR or JOSE?

- In the stateful case, it's not clear to me what prevents
  substitution attacks. For instance, can the Relay take
  the sender's first message and provide it to the receiver
  as the sender's third message? Is this just down to
  the internal message context? If so, that's pretty brittle.

On Fri, Oct 22, 2021 at 11:31 AM Matthew Byington <mbyington=
[email-masked]> wrote:

> Hello Dispatch,
>
> Recently, we published a new draft to IETF entitled
> "draft-secure-credential-transfer”.
>
> The current revision is 01.
>
> I am sending this email to the Dispatch distribution in order to kick off
> a discussion around the draft, and establish the appropriate working group.
>
> The working group may be an existing working group or we may endeavor to
> create a new one. If the dispatch team could assist us with this decision
> that would be great.
>
> A link to our draft is here:
> https://www.ietf.org/archive/id/draft-secure-credential-transfer-01.html
>
> The required participants for the initial discussion would be, at a
> minimum, the full list of authors:
>
> Dmitry Vinokurov
> Apple Inc
> Email: [email-masked]
>
> Matt Byington
> Apple Inc
> Email: [email-masked]
>
> Ben Chester
> Apple Inc
> Email: [email-masked]
>
> Matthias Lerch
> Apple Inc
> Email: [email-masked]
>
> Crystal Qin
> Alphabet Inc
> Email: [email-masked]
>
> Adam Bar-Niv
> Alphabet Inc
> Email: [email-masked]
>
> Nick Sha
> Alphabet Inc
> Email: [email-masked]
>
> Thank you,
> Matt Byington
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>