Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-dyn-reg-management

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 2 Mar 2015 11:07:48 -0500

Hi,

I'd like to see if we can get last call started on this one soon.

My questions are not all specific to this draft and I won't hold up this
draft for answers that are broader.

For this one, if the duplicate TLS text can be addressed, that would be
helpful.

Then, I'll also need to know more on my questions from the shepherd report
in my initial message.  I think this should be easy to resolve so we can
progress the draft.

Thanks,
Kathleen

On Thu, Feb 26, 2015 at 11:54 AM, Kathleen Moriarty <
[email-masked]> wrote:

> Hi Justin,
>
> Thanks for the quick response.
>
> On Thu, Feb 26, 2015 at 11:40 AM, Justin Richer <[email-masked]> wrote:
>
>> On Feb 26, 2015, at 11:04 AM, Kathleen Moriarty <
>> [email-masked]> wrote:
>>
>>
>> Hello,
>>
>> I reviewed draft-ietf-oauth-dyn-reg-management, which reads well and I
>> just have a few questions and suggestions below that would be good to
>> address prior to IETF last call.
>>
>> Section 1.3
>> Bullet D might be easier to read as a list within the bullet.
>>
>>
>> OK, I’ll try that and see how it renders in the various output formats.
>> Lists-within-lists don’t always play nice in my experience, hence the
>> paragraph format, but we’ll see what it looks like. I agree that it’s an
>> intimidating block of information there. :)
>>
>>
> Thanks for playing with this, it might help.
>
>>
>> Section 2
>> This is something I don't recall offhand and may be in place in another
>> draft, so a pointer would be great.  Is there an MTI set for one of the
>> recommended cipher suites in the TLS & DTLS BCP to ensure interoperability
>> (but also allow for algorithm agility)?  If not and there is a reason,
>> please explain.
>> See section 4: https://datatracker.ietf.org/doc/draft-ietf-uta-tls-bcp/
>> This is not the right draft to add this content, but I'd like to know if
>> it is covered somewhere or doesn't need to be for some reason.  TLS
>> requirements should point to that draft (assuming one exists) so there is
>> only one place to update if needed for any specific requirements to OAuth.
>>
>>
>> This is a copy of the text found in
>> https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-24#section-5
>>
>
> Yes, I realized that when I read it, thanks.
>
>>
>> We basically just want to say “use an encrypted channel” and point to the
>> best guidance there is out there at the time. There shouldn’t be any
>> specific requirements for OAuth. Maybe in the future the IETF could have a
>> standard single reference for transport protection that can be included
>> a-la the 2119 definitions?
>>
>
> I brought this up as I read a few drafts for last week's telechat, one was
> the BCP for TLS.  As a result, it got me digging into a few drafts to see
> how it is getting used.  Hence, me noticing this possible issue in this
> review.
>
> The TLS protocol itself defines a large number of cipher suites for use
> that are registered with IANA (defined per version, but you have to dig
> into the referenced specs to see when each was added).
>
> Then a number of protocols that use TLS define an MTI to ensure interop
> between implementations, but typically have an explicit statement to allow
> for algorithm agility.  The recent drafts seem to select one of the
> recommended cipher suites from the list int he new TLS BCP.
>
> Does use of TLS show up in an earlier draft or published OAuth RFC where
> this would be appropriate to define?  How do implementations ensure interop
> now? Maybe that will help answer this question.
>
>
>> IANA Considerations:
>> The shepherd report says that there are no actions for IANA, so this
>> needs to be updated as the draft is the specification required to add two
>> new entries to an existing registry, established by the parent document.
>> It does require DE review on the mailing list: [email-masked]
>> If that has been done, then a pointer to the archive would be helpful.
>>
>> Thank you.
>>
>> --
>>
>> Best regards,
>> Kathleen
>>
>>
>> Thanks for the review,
>>  — Justin
>>
>>  _______________________________________________
>> OAuth mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>
>
> --
>
> Best regards,
> Kathleen
>

-- 

Best regards,
Kathleen

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 03 Mar 2015 10:50:07 +0100

Hi Kathleen,

the statement about the IANA actions in the shepherd writeup are indeed
incorrect. I updated the writeup.

>>         IANA Considerations:
>>         The shepherd report says that there are no actions for IANA,
>>         so this needs to be updated as the draft is the specification
>>         required to add two new entries to an existing registry,
>>         established by the parent document.  It does require DE review
>>         on the mailing list: [email-masked]
>>         <mailto:[email-masked]>

One question: I was assuming that we would use the review list when
requests come from outside the IETF since documents that go through the
IETF OAuth working group get detailed review anyway.

I am OK with always dropping a mail to the review lists whenever new
registry entries are created. Should we do that?

Ciao
Hannes

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 3 Mar 2015 08:00:10 -0500

Hi Hannes,

Sent from my iPhone

> On Mar 3, 2015, at 4:50 AM, Hannes Tschofenig <[email-masked]> wrote:
> 
> Hi Kathleen,
> 

Thank you!
> registry entries are created. Should we do that?

Yes, that's fine and is how I read the IANA considerations.   It does say a DE on that list needs to make a decision, so expert review is required.

Thanks,
Kathleen