Re: [Rum] Benjamin Kaduk's Discuss on draft-ietf-rum-rue-09: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

Hi Brian,

Also inline

On Fri, Dec 24, 2021 at 03:58:21PM -0500, Brian Rosen wrote:
> Benjamin
> 
> Thanks for the close read of this document.  Comments inline
> 
> > On Dec 16, 2021, at 2:52 AM, Benjamin Kaduk via Datatracker <[e-mail]> wrote:
> > 
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-rum-rue-09: Discuss
> > 
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> > 
> > 
> > Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
> > for more information about how to handle DISCUSS and COMMENT positions.
> > 
> > 
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-rum-rue/
> > 
> > 
> > 
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> > 
> > Thanks for writing this document; it's an important topic and I look
> > forward to seeing interoperability in this space.
> > 
> > However, I don't think this document is quite ready for publication yet,
> > as it has a number of internal inconsistencies (and at least one
> > external inconsistency with IETF procedures) that would get in the way
> > of interoperable implementation.
> > 
> > (1) The procedure for substituting an entryPoint from the provider list into
> > the OpenAPI interface description for obtaining configuration data
> > appears to be incompatible with BCP 190.  Though there's not quite
> > enough detail for me to be able to tell exactly what behavior is
> > intended, the procedure of "replace localhost in the template with the
> > value from provider discovery" seems like it implies that the value from
> > provider discovery is just a hostname, and that we are requiring the RUM
> > services to be accessible via HTTP at path /rum/v1 on that machine.  The
> > URI path namespace is under control of the owner of the host, and we
> > cannot assert that we will occupy that portion of the namespace.  The
> > current version of BCP 190, RFC 8820, does allow us to say (effectively)
> > "delegate a subtree of the path namespace to the protocol" by letting
> > the owner of the host pick what base path to use for the protocol (even
> > that would not have been allowed by its predecessor, RFC 7320), but we
> > do need to let that host-specific path prefix be indicated somehow,
> > whether by URL template or allowing a base path to be indicated in the
> > provider discovery process.
> There is no restriction that the provider discovery returns a host name.  It’s string substitution that will be used for the entry points of the interface.  It could be "interface.external.example.com/rum/rue/opemapi/generic <http://interface.external.example.com/rum/rue/opemapi/generic>”.  Whatever the string is, it’s substituted for “localhost” and that is used to find the server and define the entry points.  After that string substitution, the path will end in, for example, “../rum/v1/ProviderConfig”.  I think that should be 8820 compatible.  I edited the descriptions of the mechanism to describe the parameters as strings to make it obvious that it is string substitution.  
> 
> I hope that’s enough to address the concern.

Yes, that should work; thanks for the clarification.

> > 
> > (2) There are a lot of inconsistencies about the parameters and data
> > format of the various API responses as specified in prose, OpenAPI
> > description, and examples.  In particular, we also fail to make a clear
> > statement about whether the prose or the OpenAPI description is
> > normative and takes precedence in case of disagreement.
> > 
> > I'll list a bunch of things here; I made a fairly careful reading but am
> > not willing to assert that this is a comprehensive listing.  (A number
> > of them also get comments in the section-by-section comments; sorry
> > about that duplication.)
> I am sorry we made these many uncaught mistakes.  I’m having someone else go through and see if we can find more of them.

Thanks.  (In reading the other ADs' reviews, I see that my list was
definitely not comprehensive, since I missed the case mismatch on "v1" vs
"V1" :)

> > Sections 9.2.1 and 9.2.2 list configuration data items in the
> > "configuration data for new user sign up and dial around" and
> > "configuration data for the RUE" configuration retrieval APIs, and per
> > the note at the end of §9.2 they include the REQUIRED data items.
> > However, there are a couple data items that are mentioned elsewhere in
> > the document as if they are always going to be present, but are not
> > present in these lists of required configuration parameters.  In
> > particular we talk about the "provider-domain" as coming from the
> > configuration, and it appears in examples, but is not mentioned in the
> > prose or OpenAPI format description.
> This is an error.  It appears to be the result of several changes to the interface that resulted in the OpenAPI localhost substitution discussed above.  
> Somehow, we deleted provider-domain.
> I replaced it in both the description and the OpenAPI yaml.
> 
> 
> > The prose (and some examples) refer to an "outbound-proxies" RUE
> > configuration element, but §9.2.2 and the OpenAPI description list the
> > singular "outbound-proxy" (and with the corresponding difference in
> > format/structure).
> Fixed.  It should be proxies plural throughout now.
> 
> > 
> > The prose mentions "credentials" from the configuration, but no
> > parameter of that name appears (there is some mention of password under
> > "carddav" but that seems insufficiently generic to match all instances;
> > sip-password also exists).
> The first instance of credentials said:
>        The registrar MAY authenticate using SIP digest authentication. The credentials to be used (username and password) MUST be supplied within the credentials
> This is standard sip terminology.  The configuration has the username (constructed from the phone number and the provider-domain) and the sip-password (or as described in the sip-password description) are the credentials. 

Okay, we can keep with the standard terminology.  I would suggest, then,
that all instances of "credentials" (with quotes, usually as '''matching
"credentials" from the configuration''') be modified to use an unquoted
word, so as to avoid implying that there is a JSON element by that name.

> It does occur to me, although no one raised in in reviews, that sometimes there is an actual username that is used, instead of the phone number.  I added that as optional (use the phone number if it’s not present), and reworded the text.
> > 
> > "display-name" appears in the example in Figure 5 but is not listed in
> > §9.2.2
> Fixed
> > 
> > The prose for the provider configuration resource indicates that the
> > dialAround property is mandatory (it is not marked as "(OPTIONAL)"), but
> > the OpenAPI specification does not list this property as required.
> Fixed.
> > 
> > The prose for the provider configuration's "signup" property says that
> > it is an array of JSON objects, but the OpenAPI description says that it
> > is just a single object (not an array).  Likewise for "dialAround" and
> > "helpDesk”.
> Fixed.  Should have been arrays
> > 
> > The prose for "phone-number" specifies E.164 format, but the OpenAPI
> > description does not.
> Fixed
> 
> > 
> > "carddav" is triply inconsistent: the prose says username, password, and
> > domain name are separated by "@" (presumably, in a single string), but
> > the example only shows username and domain name in user@domain form, and
> > the OpenAPI description says it should be an object with separate
> > properties for username/password/domain, as well as an additional
> > "sendLocationWithRegistration" property that is probably not supposed to
> > be a child of "carddav”.
> Fixed
> > 
> > (repeating from the previous), the "sendLocationWithRegistration"
> > property is listed as belonging to the "carddav" object in the OpenAPI
> > description, though the prose and example indicate it should be a
> > property of the toplevel configuration object.
> Fixed
> > 
> > The prose and OpenAPI description indicate that "ice-servers" is an
> > array of strings, but the example has an array of objects that use the
> > dictionary key to indicate whether each URI is a TURN or STUN server.
> Fixed
> > 
> > 
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> > 
> > There are a number of references to "the configuration" in the body text
> > prior to §9.2 where the configuration service is discussed.  E.g., the
> > first paragraph of §5.1 gives a hard requirement for registration and
> > then makes a conditional reference to "the configuration" without any
> > prose discussing how configuration retrieval interacts with
> > registration.  it may be useful to have a brief introductory mention of
> > the data flow involving registration and configuration retrieval and how
> > the two initialization processes (don't) interact.
> I added some text in the top of the SIP Signaling section.
> 
> > 
> > I have a high-level comment or two about password usage in this
> > document.  I recognize that we're constrained in practice by the current
> > state of SIP specification and the deployed ecosystem, but while
> > username/password may currently be the lowest common denominator for
> > authentication, it's far from best current practice.  In a scenario
> > like the one here, where the RUE is a dedicated (often hardware)
> > product talking over a fixed protocol to a nearly fixed small set of
> > providers, there's plenty of scope for using strong cryptography to
> > authenticate the RUE, including public-key cryptography where the
> > verifier does not need to store any per-user secret information.  At
> > present, Digest seems to be the strongest mechanism in the registry for
> > usage with SIP, but I would advise assuming that that will change in the
> > future and writing the spec and implementation in a way that is
> > compatible with stronger authentication schemes.
> We had a big discussion on the use of OAuth, which is specified for use in SIP.  While there were strong proponents of supporting OAuth, it failed to gain consensus.  It’s just not how SIP is deployed.
> I could rename the username/password things to try to anticipate some more robust mechanism, but the text has to change anyway and it didn’t seem worth it.  A really, really important characteristic of a device like this is if power fails, and is restored, calls can arrive.  This means you cannot require any user interaction on a power start.  This really is at odds with how a lot of mechanisms work.  We thought about installing certs and using mutual auth.  Again NO sip systems we know do that.  Installing certs securely with no user interaction is hard.  There was no consensus to try to do that here.  I personally don’t like the security situation we have, but we don’t have any alternatives we could realistically deploy.

Indeed, compatibility with the deployed reality trumps ideological purity
(though that doesn't keep us from documenting the weaknesses of what's
deployed).  Thanks for confirming.

> > 
> > Furthermore, this document in several places (I note a few in the
> > per-secton comments) recommends or even requires the reuse of a
> > username/password pair across multiple services.  Best practices are to
> > use any given password at exactly one service.  In this regard one can
> > roughly model the password as analogous to a pre-shared key -- it is
> > useful for authenticating a peer in the sense that if the value is known
> > only to two entities, and the party you're communicating with proves
> > that they know the value, they must be the only other party that knows
> > the secret value.  But once you reuse the password at multiple services,
> > that logic falls apart, as the party you're communicating with could be
> > the user, or it could be another service that shares the secret.
> > Granted, when used with digest the password itself is not sent to the
> > server for every authentication, but the server typically has access to
> > it at some point, and even possession of the password hash in a
> > verification database allows for offline brute-force attack, which has
> > become comparatively cheap in recent years and even the availability of
> > dedicated hardware for password cracking.
> We could force the secondary services to have separate passwords.  Since they all come from the same config, they are all supplied by the default provider, and they all identify the same user, albeit on different service deployments, we didn’t think there really was much difference.  The one place I would be very reluctant to force separate credentials is stun/turn, were it’s just too common to use the same credentials.  There is no value in protecting, say the configuration service independently of the sip service or the turn service.  It really doesn’t matter at all.  

The main value in separate passwords for the secondary services would be
that compromise of one such service does not imply full compromise of the
"account".  As above, though, what people are willing to deploy is the main
consideration for me -- I don't feel a need to "require" something with an
RFC 6919 "MUST (BUT WE KNOW YOU WON'T)".

> > 
> > In particular, SHA-512 is not considered to be a best-practice hash
> > function for password hashing, since it is highly parallelizable and not
> > "memory-hard".  RFC 9106 specifies Argon2 (via the IRTF CFRG), the
> > winner of the password hashing competition; it is the state of the art
> > for password hashing, and even prior to that publication we had scrypt
> > available in RFC 7914 that is a significant improvement on the SHA-2
> > family of functions.  That said, it's not currently listed in the IANA
> > registry for hash algorithms for HTTP (and SIP) digest authentication,
> > so I am not sure that we can usefully advocate for its usage at the
> > present time.
> We only very recently deprecated RC4, and I’d bet 99,99% of sip services deployed still use it.  I was able to make this spec use SHA-512, but that’s the very best we can do in a profile.  We could try to get some of the SIP guys to put through an RFC to support Argon2, but that would have to happen before this doc could use it.

Agreed.

> 
> > 
> > Section 4
> > 
> > Thanks for mandating RFC 7525 compliance.  I note that
> > draft-ietf-uta-rfc7525bis is in progress in the UTA WG.  Though it will
> > probably be published after this document, it may be a useful
> > informative reference with forward-looking guidance on how to best
> > secure TLS.
> I’ll try to remember that for when this doc gets an update.
> 
> > 
> >   All text data payloads not otherwise constrained by a specification
> >   in another standards document MUST be encoded as Unicode UTF-8.
> > 
> > I think we'd typically reference RFC 8259 here.
> I’m worried that there might be some incompatibility between 8259 and OpenAPI.  OpenAPI references 
> https://datatracker.ietf.org/doc/html/draft-wright-json-schema-00 <https://datatracker.ietf.org/doc/html/draft-wright-json-schema-00>!!!!
> The text is specific to string content and not JSON format.

It seems likely that I got my RFC numbers confused here and I meant to say
3629 for UTF-8 itself.  Sorry about that.

The 8259 reference might still be relevant, as JSON Schema still uses JSON
(but, predating 8259, it references 7159 instead), but I didn't look for an
appropriate place to put it.

> > 
> > Section 5.1
> > 
> >   The registrar MAY authenticate using SIP digest authentication.  The
> >   credentials to be used (username and password) MUST be supplied
> >   within the credentials section of the configuration and identified by
> >   the realm the registrar uses in a digest challenge.  This username/
> > 
> > Which entity is authenticating to which other entity here?  The phrasing
> > "<X> MAY authenticate" implies that it is X that is authenticating to
> > some other entity, but that does not seem to correspond to my model of
> > the flow here, where the RUE is authenticating to the registrar.  If the
> > flow is to be the other way, we would say "the registrar MAY
> > authenticate the RUE using SIP digest authentication”.
> I'll make that change.  The registrar authenticates the RUE
> > 
> > Also, I note that (HTTP) SCRAM authentication has superior security
> > properties to Digest, but unfortunately I don't see any evidence that
> > its use for SIP is defined yet.
> Yeah, yet another weakness.
> 
> > 
> > Section 5.2.1
> > 
> >   The SIP URIs in the To field and the Request-URI MUST be formatted as
> >   specified in subsection Section 5.4 using the destination phone
> >   number, or as SIP URIs, as provided in the configuration
> >   (Section 9.2).  [...]
> > 
> > I'm not sure that I'm unpacking this properly.  (The construction "the
> > SIP URIs MUST be formatted as [...], or as SIP URIs", makes me wonder
> > if there are somehow non-SIP URIs involved even though we start off with
> > "the SIP URIs".)  Is the idea that I either take the URI directly from
> > the configuration ("as-is") or I format it as per §5.4 but not anything
> > else?
> There are two ways you specify the From and To header fields in SIP when you are using telephone numbers and not usernames.  
> One is a SIP URI sip:[e-mail];user=phone.  
> The other is a TEL URI: tel:[phone]. 
> Phone number and domain come from the configuration.  Does that help?

Uh...maybe.
Do we need to s/or as SIP URIs/or as TEL URIs/?  I don't see how the
current text allows the TEL version that you describe.

I'd also consider making the "as provided in the configuration" clause a
separate sentence, like "the phone number and domain (if applicable) are
provided in the configuration (Section 9.2)".

> > 
> > Section 5.2.2
> > 
> >   party telephone number.  In two-stage dial-around, the To URI is the
> >   front door URI (see Section 9.2) of the dial-around provider and the
> >   domain of the URI is the provider domain from the configuration.  The
> > 
> > Is "the URI" in "the domain of the URI" referring to "the To URI", or
> > some other URI (the Request-URI, perhaps)?
> Yeah, that’s pretty awkward.  I shortened it to:
> In two-stage dial-around, the To URI is the front door URI (see Section 9.2) of the dial-around provider.
> > 
> > 
> > The prose lists the call originator as (VRS user) [phone], but
> > the URIs in Figure 1 that are not the call recipient appear as
> > [phone]; are those numbers supposed to be different like that?
> I fixed the telephone numbers being wrong.  The deletion of the dashes follows text in 5.4

Right, I just meant the actual numbers.  Thanks.

> > 
> > Section 5.2.3
> > 
> >   owner".  The URI MAY be an HTTPS URI or Content-Indirect URL.  The
> >   latter is defined by [RFC2392] to locate message body parts.  This
> > 
> > RFC 2392 seems to define a "Content-ID" URI (with "cid" scheme) but not
> > a "Content-Indirect" URL.
> Fixed.  I can’t tell you how many times I have made that mistake.
> 
> > 
> > Section 5.2.5
> > 
> >   Implementations MUST implement Additional Data, [RFC7852].  RUE
> >   devices MUST implement Data Provider, Device Implementation and
> >   Owner/Subscriber Information blocks.
> > 
> > The string "Device Implementation" does not seem to appear in RFC 7852,
> > though "Device Information" does.
> Fixed
> 
> > 
> > Section 7.1
> > 
> >   of an email address.  If the request triggers a challenge for digest
> >   authentication credentials, the RUE MUST continue using matching
> >   "credentials" from the configuration.  If no matching credentials are
> >   configured, the RUE MUST use the SIP credentials from the
> >   configuration.  [...]
> > 
> > Do we really want a MUST-level requirement to reuse the SIP credentials?
> > Best practices for credentials are to have a 1:1 relationship between
> > credentials and where they are used and this sort of reuse is basically
> > the polar opposite.
> See above.
> 
> > 
> > Section 9.1
> > 
> >   non-mandatory-to use functions and SHALL NOT delete any objects,
> >   members of objects or functions.  This means an implementation of a
> >   specific major version and minor version is backwards compatible with
> >   all minor versions of the major version.  [...]
> > 
> > (This might all be covered by Rob's discuss point; I will read the
> > replies on that thread and you don't need to duplicate content here for
> > my benefit.)
> > This statement doesn't seem to contain enough information to be useful.
> > I think that a statement about backwards (or forwards) compatibility
> > should be specific about whether it applies to the implementation of the
> > client or the web service, and that backwards compatibility would
> > require that the implementation in question interoperate with a peer at
> > any same or previous minor version.  Just saying "compatible with all
> > minor versions of the major version" would also make a statement about
> > forward compatibility, which I think is allowable under these rules for
> > what is allowed to change in minor versions, and it would be useful to
> > make a statement about forward compatibility.
> I added: "Either may have any higher or lower minor revision and interoperate with its counterpart with the same major version."  
> after "Backwards compatibility applies to both the server and the client."
> 
> I think that avoids having to talk about forwards compatibility.  
> > 
> > Section 9.2
> > 
> >   The interface to obtain configuration data is described by an OpenAPI
> >   [OpenAPI] interface description.  In that interface description, the
> >   "servers" component is specified as "localhost".  The entry point
> >   obtained from the provider list (Section 9.1) is sutituted for
> >   "localhost" to obtain the server prefix of the interface.  [...]
> > 
> > I note that the OpenAPI description for /Versions has an override for
> > "servers", and the value listed there does not include the string
> > "localhost".  Some clarity that it is also expected to be affected by
> > this kind of substitution seems in order.
> That’s an error.  Changed the server override in Versions to:
>       - url: https://localhost/rum
> 
> > 
> > 
> >   In both the queries, an optional parameter may be provided to the
> >   interface which is an API Key.  The implementation MAY have an API
> >   Key obtained from the provider and specific to the implementation.
> >   The method the API Key is obtained is not specified in this document.
> >   The provider MAY refuse to provide service to an implementation
> >   presenting an API Key it does not recognize.
> > 
> > I note that the IETF does have a standard for conveying authorization
> > information on the web -- OAuth 2.0.  It may not be a direct "drop-in"
> > fit here, due to the need for a preexisting relationship with an
> > authorization server, but perhaps it is worth mentioning as an option
> > in addition to this provider-specific "API key" protocol?
> This isn’t a user authorization.  It’s a developer authorization.
> OAuth can’t be used, because the developer can’t provide credentials when the device connects.

Oh, that kind of API key.  Then we get to pull in the security
considerations for attempting to keep secret a value that's shipped in the
software binary and sent on the wire (something that repeatedly doesn't
happen for the official mobile apps for popular services)...

> > 
> >   Also in both queries, the RUE device provides a required parameter
> >   which contains an instance identifier.  This parameter MUST be the
> >   same value each time this instance (same implementation on same
> >   device) queries the interface.  This MAY be used by the provider, for
> >   example, to associate a location with the instance for emergency
> >   calls.
> > 
> > Is there any cryptography to provide assurance that the instance
> > identifier is indeed always used only by the one single instance?  The
> > description here sounds roughly like a bearer token, which is far from
> > best practice for this sort of thing.  Indeed, in other contexts a given
> > instance is often identified solely by its public key, and must
> > authenticate with the corresponding private key in order to act as the
> > identified instance.
> No, and I don’t think it’s needed,  A typical use case here is a device in your home and one on your phone that has the same credentials and phone number.  We just need to differentiate them. It’s not a security property.
> The consequences of confusion is fairly low.  As stated above, we did go through some discussions of provisioning private keys to each device and gave up due to the complexity vs the sophistication of the user.  There really isn’t any reasonable plug and play mechanism here.  We can’t use anything like Acme.  

Thanks for the background; I don't see a need to re-hash that.

Though the description above makes me wonder if the instance ID is scoped
to a given user/credentials?  That would be better in some ways, I think.

> > 
> >   The configuration API also provides the same version mechanism as
> >   specified above in Section 9.1.  The version of the configuration
> >   service MAY be different than the version of the provider list
> >   service.
> > 
> > Not only that, but the services are expected to be versioned
> > independently, so there is no particular relationship between version
> > X.Y of the one and version X.Y of the other…right?
> That’s correct
> > 
> > Actually, having gone and looked further, the OpenAPI document seems
> > to indicate that there's a single /Versions resource common across the
> > /Providers, /ProviderConfig, and /RueConfig APIs, which makes me
> > confused as to how the versions of the two services might actually be
> > different (let alone versioned independently).
> There are two services (the provider list service and the configuration service).
> The former has one entry point, the latter has two: the provider config and the device config.
> 
> The two services have different versions.  The two entry points in the configuration service have the same version.

That looks like the key insight that I was missing.  Any chance we could
get that sentiment expressed in the document?

> The way this mechanism is designed, you can make an implementation that works on several (or all) major versions and any minor version of each major version.
> For server implementation, if it support multiple versions, each one has a separate URI (the version is in the URI).  The client composes the URI it wishes to use by looking at the Versions entry point for the service to find a compatible version and uses that and uses the version to choose an Open API yaml (and the code the yaml generates).
> 
> > 
> > Section 9.2.1
> > 
> >      -  uri: a URI to the website for creating a new account in the
> >         supported language.  The new user signup URI may only initiate
> >         creation of a new account.  Various vetting, approval and other
> >         processes may be needed, which could take time, before the
> >         account is established.  The result of creating a new account
> >         would be a username and password, which would be manually
> > 
> > I strongly suggest using a more generic phrasing (e.g., "would be
> > account credentials (e.g., username and password)") to allow for
> > seamless transition to stronger authentication technologies without
> > specification change.
> Done
> 
> > 
> > Section 9.2.2
> > 
> >   *  lifetime: (optional) Specifies how long (in seconds) the RUE MAY
> >      cache the configuration values.  Values may not be valid when
> >      lifetime expires.  If the RUE caches configuration values, it MUST
> >      cryptographically protect them.  [...]
> > 
> > In other contexts, "cryptographically protect" would mean to encrypt,
> > cryptographically sign, or compute a keyed MAC over the data.  If the
> > intent here is just to record a cryptographic checksum of the data,
> > that's probably better stated in terms of a checksum.
> > 
> > In particular, this current text gives no indication of what threat the
> > cryptography is supposed to protect against, so implementations are
> > unlikely actually provide uniform protection against the intended
> > threat.
> I added some text so it now reads:
> it MUST cryptographically protect them against unauthorized disclosure (e.g. by other applications on the platform the RUE is built on). 

Thanks!

> > 
> >   *  sip-password: (optional) a password used for SIP, STUN and TURN
> >      authentication.  The RUE device retains this data, which must be
> >      stored securely.  [...]
> > 
> > Akin to the above, this doesn't indicate what threat "stored securely"
> > is intended to protect against.  While I would *hope* that "protect
> > passwords" is instinctive to developers, I wouldn't want to rely on it.
> I added the same text to that.
> 
> > 
> >      password MUST be used.  If it was never supplied, the password
> >      used to authenticate to the configuration service is used for SIP,
> >      STUN and TURN.
> > 
> > In the general case, this directive is a gaping security hole (exposing
> > the RUE's SIP credentials to arbitrary external STUN/TURN servers, for
> > example).  I think we must qualify that the reuse of credentials is only
> > for the servers listed in the "ice-servers" configuration directive.
> > (And ideally we would not encourage reuse of credentials at all.)
> Edited to say “is used for SIP, as well as STUN and TURN servers mentioned in this configuration."

Thanks.

> > 
> >   *  carddav: (optional) A username, password and domain name
> >      (separated by ""@"") identifying a "CardDAV" server and account
> >      that can be used to synchronize the RUE's contact list with the
> >      contact list managed by the provider.  If username or password are
> >      not supplied, the main account credentials are used.
> > 
> > There are three data items but only one separator listed.  Is this
> > really to be "username@password@domain"?
> > It would be great if we could make ourselves more generic than
> > username+password as credentials, and (as mentioned previously) avoid
> > reuse of credentials.
> I fixed this to have separate fields in an object in the config.
> I don’t know any other usable authentication mechanism for cardav in this environment, but I’m far from an expert.

I suspect that I'm even farther from expert than you are...

> > 
> >   *  ice-servers: (optional) An array of URLs identifying STUN and TURN
> >      servers available for use by the RUE for establishing media
> >      streams in calls via the provider.
> > 
> > Is any given entry required to offer both STUN and TURN services, or can
> > a server provide just one or the other?  Both this text and my
> > understanding of the OpenAPI description seem to indicate that this is a
> > flat list intermingling STUN and TURN servers, but the example in Figure
> > 5 seems to show each element of the array being a JSON object that
> > contains one or more of the keys "stun" and "turn".  The structure in
> > that example would obviate any confusion about which services are
> > offered, and is probably preferred.
> I fixed the OpenApi to use the strings (“stun” and “turn”).
> 
> > 
> > Section 9.2.3
> > 
> >       "contacts": "https://red.example.net:443/contacts/1dess45awd",
> > 
> > I suggest putting a bit more entropy in the URL, in the vein of
> > https://www.w3.org/2001/tag/doc/capability-urls/ (even if this resource
> > is likely to require the username+password authentication discussed
> > earlier).
> Made it a V4 UUID (3617b719-2c3a-46f4-9c13-538f7efd0b21)
> > 
> >       "carddav": "[e-mail]" ,
> > 
> > The prose indicates this should contain a password as well as the
> > username and domain name that are present.  How is the password
> > specified?
> This is fixed to have separate fields for domain, username and password
> > 
> > Section 9.3
> > 
> > Given the "are formally specified" language, I expect that the intent is
> > for the OpenAPI description to be normative and take precedence in case
> > of conflict with the prose/examples.  It's probably worth stating that
> > explicitly.
> Done.
> 
> > 
> >          - in: query
> >            name: instanceId
> >            schema:
> >              type: string
> >            required: true
> >            description: Unique string for this implementation
> >                         on this device
> > 
> > Is this self-assigned by the client or assigned by some external
> > authority?  The allocation procedure is important for ensuring that the
> > instance IDs are actually globally unique (with high probability).
> > (Note that this parameter is used in both /ProviderConfig and
> > /RueConfig.)
> Self assigned by the client.  There is no dependence on this for Provider config.
> 
> I’ll suggest it be something like a UUID.
> > 
> > Section 10.2
> > 
> > The rest of the document does not appear to contain any text covering
> > the usage of the "rue-owner" purpose value.  Should we say something
> > about when it's used and what semantics it conveys?
> See Section 5.2.3. I added a cross reference.
> 
> > 
> > Section 11
> > 
> > I think we should make some statement that incorporates by reference the
> > security considerations of the protocols being profiled.  There are
> > perhaps too many to list individually, so something like "this document
> > requires implementation and use of a number of other specifications in
> > order to fulfil the RUE profile; the security considerations described
> > in those documents apply accordingly to the RUE interactions" would
> > probably work.
> Done
> 
> > 
> > It is perhaps obvious, but when a CA participates in a conversation they
> > have access to the content of the conversation even though it is
> > nominally a conversation between the two endpoints.  I think we should
> > still state this explicitly, and perhaps note that there is an
> > expectation that the CA will keep the communication contents in
> > confidence, often backed by contractual or legal requirements.
> Done
> 
> > 
> > There's probably also something useful to say to compare the privacy
> > properties of one-stage vs two-stage dial-around, in terms of which
> > entities have access to information about the communicating endpoints.
> Well the only difference is the CA has access to the called party number, but they usually have access to that anyway because of how dropped calls are handled.

Okay.

> 
> > I am not entirely sure if the referenced documents already cover this,
> > but having the provider maintain the user's contacts database means that
> > there is increased risk surface for unauthorized disclosure of that
> > information (compared to it being maintained locally).
> Yeah, but:
> Locally maintained contacts are really hard to handle when you change devices
> Locally maintained contacts don’t sync across devices.
> I’ll put something here if you really think we need it, but getting the providers to manage contacts was a very hard fight that only recently became common (the US regulator now requires it).  Before, it was a vendor lock in.

I'll defer to your domain expertise.

Thanks for all the other good stuff (above and below) that I didn't reply
on.  I look forward to the -10 (in the new year, presumably).

-Ben

> > 
> > Since different providers (within a given country) may have different
> > policies, we might want to caution RUE implementations to have a user
> > interaction step before proceeding to actually register with any given
> > provider.
> Done
> 
> > 
> > NITS
> > 
> > No need to reply to any of these; if you disagree, that's fine.
> > 
> > Section 5.2.1
> > 
> >   Negotiated media MUST follow the guidelines specified in Section 6 of
> >   this document.
> > 
> > If they MUST be followed, are they really guidelines, or requirements?
> Changed to requirements
> 
> > 
> > Section 5.2.3
> > 
> >   To identify the owner of a RUE, the initial INVITE for a call from a
> >   RUE, or the 200 OK accepting a call by a RUE, identifies the owner by
> > 
> > I think s/the 200 OK accepting a call by a RUE/the 200 OK a RUE uses to
> > accept a call/ would avoid ambiguity about whether this binds as
> > (accepting a (call by a RUE)) vs ((accepting [of] a call) by a RUE).
> Done
> 
> > 
> > Section 9.1
> > 
> >   provider names for a country code suitable for display, with a
> >   corresponding a entry point to obtain information about that
> >   provider.
> > 
> > s/corresponding a/corresponding/
> Fixed
> 
> > 
> > Section 9.2
> > 
> >   HTTPs web service.  There are two entry points.  One is used without
> >   user credentials or parameters, the response includes configuration
> >   data for new user sign up and dial around.  The other uses the
> > 
> > Comma splice.
> Did something, but maybe not what you wanted
> 
> > 
> > Section 9.2.2
> > 
> >   *  videomail: (optional) An SIP or HTTPS URI that can be called to
> >      retrieve video mail messages.
> > 
> > Can an HTTPS URI really "be called"?  (This text also appears in §9.3.)
> Changed to “used"
> > 
> > 
> > 
>