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

[Brian Rosen <[e-mail]>]

Roman

Does the -10 version I submitted address your issues?

Brian


> On Dec 23, 2021, at 4:56 PM, Brian Rosen <[e-mail]> wrote:
> 
> Thank you for your comments.  Responses inline
> 
>> On Dec 15, 2021, at 5:07 PM, Roman Danyliw via Datatracker <[e-mail]> wrote:
>> 
>> Roman Danyliw 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:
>> ----------------------------------------------------------------------
>> 
>> ** Is there a reason that credential re-use is being suggested as a fall back. 
>> It seems risky to reuse the credentials across services.
> This is really how sip services commonly work and I’m reluctant to disallow what is widely implemented
> 
>> This fall-back also
>> appears to contradict the guidance in Section 5.1. which says “This
>> username/password combination SHOULD NOT be the same as that used for other
>> purposes, such as retrieving the RUE configuration”.
> I will change this to add "except as expressly described below”
> The configuration service is new, and thus we can say don’t reuse credentials for that.
> 
> 
>> See:
>> 
>> -- Section 7.1.  Per access to the CardDAV server, “[i]f no matching
>> credentials are configured, the RUE MUST use the SIP credentials from the
>> configuration.”
>> 
>> -- Section 9.2.2.  sip-password says “If it was never supplied, the password
>> used to authenticate to the configuration service is used for SIP, STUN and
>> TURN.”
>> 
>> -- Section 9.2.2.  carddav field says that “If username or password are not
>> supplied, the main account credentials are used. “
>> 
>> ** Is there a reason that a minimum transport requirements of using HTTPS is
>> not defined for accessing the SIP-supporting elements of this architecture.
> I’m confused by this.  HTTPS and SIP are mutually exclusive.  Did you mean TLS instead of HTTPS?
> But you said “minimum transport” and not “security” so I’m even more confused.  Sorry.
> 
> We specify RFC7525 and 8446 in General Requirements for TLS.
> 
>> 
>> -- Section 7.1.  Access to the CardDAV service?  Does the guidance in Section
>> 7.2 (The RUE stores/retrieves the contact list (address book) by issuing an
>> HTTPS POST or GET request.) imply that?
> There are two services: a contact list import and a CardDAV service, which is a contact sync.  Both are subject to the TLS requirements
>> 
>> -- Section 9.  Using the overall API? Does the guidance in Section 9.2 (A RUE
>> device may retrieve a provider configuration the using a simple HTTPs web
>> service) imply that?
> Again it’s an HTTPS service, so subject to the General Requirements TLS specs
>> 
>> -- Section 9.2.1.  For the URI configuration options noted in this section
>> (e.g., the uri in signup)?
> Same
>> 
>> ** Section 11.  There are more than 10 20 normative SIP protocol references in
>> this document.  Which of their security considerations apply?
> All of them.  That’s pretty normal sip stuff.
>> 
>> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> Thank you to Russ Mundy for the SECDIR review.
>> 
>> ** Section 2.  Thanks for defining all of this terminology up front.  As many
>> of these are components in the architecture, I would have benefit from a
>> diagram early in the document showing how these components integrate. **
> I am diagram challenged, but I will see what I can do.
> 
>> Section 5.1.  The paragraph starting with “The registrar MAY authenticate using
>> SIP digest authentication …”, should likely say that the technique for
>> provisioning the credentials is out of scope for this profile.
> Actually, they come in the configuration service.
> 
>> 
>> ** Section 8.  Typo. s/mechansism/mechanism/
> Fixed
> 
>> ** Section 9.1
>> IANA has established a registry that contains
>>  a two letter country code and an entry point string.
>> 
>> Recommend adding a forward reference to Section 10.1.
> Added
> 
>> 
>> ** Section 9.1.
>>  For example,
>>  if the entryPoint is "example.com <http://example.com/>", the provider list would be
>>  obtained from https://example.com/rum/V1/Providers <https://example.com/rum/V1/Providers>.
>> 
>> This example doesn’t match the syntax of Section 9.3.  “V1” here and “v1” in
>> Section 9.3.
> Fixed
>> 
>> ** Section 9.2.  It would be helpful in this narrative text for the input
>> values names to match the actual field names used in the API in Section 9.3. 
>> Specifically, “API Key” is “apiKey”, and “instance identifier” is “instanceId”
> Fixed. 
> 
>> 
>> ** Section 9.2.1.  Per the language value in the signup configuration option,
>> please provide a reference to the IAN language subtag registry
>> (https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry <https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry>).
> I put it inline as a link.  Should it be an actual reference?
> 
>> 
>> ** Section 9.2.2.  sendLocationWithRegistation is listed as a stand-alone field
>> here, but in Section 9.3, it is shown to be part of the carddav object.  Which
>> is correct?
> Ho, that’s an actual error.  It should be a separate field.  Fixed
>> 
>> ** Section 9.2.3.  Figure 4.  This example is not conformance to the previously
>> described syntax.  All of the values of the “uri” fields should be a URI, but
>> all of them are missing a scheme.
> Fixed
> 
>> 
>> ** Section 9.3.  [OpenAPI] needs to be a normative reference as its syntax is
>> needed to understand this section.
> Reluctantly fixed.  We have too many normative references :)