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

Kathleen Moriarty <> Thu, 26 February 2015 16:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id F382C1A90C1 for <>; Thu, 26 Feb 2015 08:54:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id k9cR7YKnzlIe for <>; Thu, 26 Feb 2015 08:54:47 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1E5061A893F for <>; Thu, 26 Feb 2015 08:54:47 -0800 (PST)
Received: by labgd6 with SMTP id gd6so12218474lab.8 for <>; Thu, 26 Feb 2015 08:54:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ckztwbm04I7C8l9RKe+G4/g4a4UZ3nB7Q89+S7Edh1c=; b=qgFmn2A4IAIvdCLvqVlwWLVatU4r3Sv0ldRBQtchubI81Hy41PFPmF63eZS3/MVTlW YQY6Gnj7zawATUerZcfw8igQZ/GOC4UldggdX2a7GHLQ03gLKxpSo8xChtuZKIOotwwv SIhxd27zUn/kUUrAwPQzK+cnh2+SROm+TGjqcCNe9Y1pt5Mh1twZxR6VFmfCBfrKHLww ONImobL80UeMzLYqUThdiyUlz5y+eJun/VfLXUK4dk5GFM0rqQF/Th37VBHTLPgsuo1H 65ClEgrhmqCYzLqQ3MV7aehvGznTqHaOVDGMI/Tt+lQ/qzudHJLsIC0Kn23jYTzE/dQK CuZw==
MIME-Version: 1.0
X-Received: by with SMTP id dt9mr8813495lbc.56.1424969685565; Thu, 26 Feb 2015 08:54:45 -0800 (PST)
Received: by with HTTP; Thu, 26 Feb 2015 08:54:45 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Thu, 26 Feb 2015 11:54:45 -0500
Message-ID: <>
From: Kathleen Moriarty <>
To: Justin Richer <>
Content-Type: multipart/alternative; boundary="001a11c36986ec861a0510009b16"
Archived-At: <>
Cc: "<>" <>
Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-dyn-reg-management
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 26 Feb 2015 16:54:53 -0000

Hi Justin,

Thanks for the quick response.

On Thu, Feb 26, 2015 at 11:40 AM, Justin Richer <> wrote:

> On Feb 26, 2015, at 11:04 AM, Kathleen Moriarty <
>> 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:
> 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

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

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:
> 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


Best regards,