Re: [Dime] Eric Rescorla's No Objection on draft-ietf-dime-rfc4006bis-08: (with COMMENT)

Yuval Lifshitz <> Thu, 24 May 2018 14:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DF009127078 for <>; Thu, 24 May 2018 07:12:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id s4VRl4IYS0K5 for <>; Thu, 24 May 2018 07:12:25 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4F55A124D6C for <>; Thu, 24 May 2018 07:12:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s2048; t=1527171144; bh=MsaREu7U7MFLxMLx9bEMs9f/QSLDGDe+OJrFIqFK4Ek=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject; b=cRKhw0LpWH++Vf+egdDeOx5IFshYtD+sjsgi/vvYtSB7KuPXUrY+COf/QgQrby1PXFrvjmhjXmfyqJ3qZr1DLdwfZPUMYkTL3lXhJn45m2TbGoPje4kRe5FgZ0VJycgPmA0b9ctGfD9gyalNNfAQtgHzNjQOTOHwIeob/oq7wY8n4HKoOMdiYfG8xd5cMMOwfDuy6y8J6RtH0DsuhoVFIRwWv67phuuf07KI0vPKE2i6U2ZC9T07ansO/X8cO2w1RUMquyjXK+5GOzTf1Dn1nWM0evEyRkOxB5zQBHkDCxRzCRCR9ceP99sH4IF287pzsmOl6/ZETHAaoGoUc5uQvA==
X-YMail-OSG: 9Gx4F5cVM1kjxGMdlsT1ktqwHywek6BvPfjyPlLUCjD3DNdTVi2YDmGZEovGGyo taHPczQNo6oaayPxYoK.m2lxEI6z0ex.Fwr66LauImqRKcomJDKC.jSoN0LRXEAv3ofmI1IoiUza 3g2ggH1rXgfbUHXs9JqHmJsx4701ku3qhXiNPT3DdIbNz9aC2WJiv4F6ECyTnpwzwpm6cWfG8Jtw 2xXXEnE5WYzxdOfIMDgZpT3UQ2ZLFOtoktW5VtUfseW0o9fKO7qVbpgalx3Zfy2BgFNcC4c588bm d13eFvyicgouerJk6upt4pcxOHcnhpBYpmHMbfrNsLWkTTpVo4BxKy9Nygh6u_Wcx3c53eKRw7Eb EoMQ4c0hRKrCy0Jj4bqpUxTkgAkDWmX0EXxSSo8Vq3VvirS9laIKUgC0pko.BGjF2Xy0GGLUs8I5 CeSIZipY29gFAw1ZTlVlOhsWABqQFevv96_l1H2.oAab9f1Wpx0Cfi5hv7tXIYWMG6aZ5YjOLcAV 2_swqs9Y7zim1KkRYk3c7e2k6M2E5e5BdNSAA.W07sIZ1_EtbK.WGeSsC9OWEYEu2XffRYZLAs73 fKF3ryQZDFT7cy3LfWixqwsF18hN_4OuO4qvvyna2XsaMYYd4ohMCSVUvE5cqsVgNQ.wHLuJO7bV tDfKwBIQWibfLH6.3YkM.vxDkaA--
Received: from by with HTTP; Thu, 24 May 2018 14:12:24 +0000
Date: Thu, 24 May 2018 14:12:20 +0000 (UTC)
From: Yuval Lifshitz <>
To: Eric Rescorla <>
Cc: The IESG <>,,,
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_4959598_653131198.1527171140074"
X-Mailer: WebService/1.1.11871 YMailNorrin Mozilla/5.0 (X11; Fedora; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.117 Safari/537.36
Archived-At: <>
Subject: Re: [Dime] Eric Rescorla's No Objection on draft-ietf-dime-rfc4006bis-08: (with COMMENT)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 24 May 2018 14:12:28 -0000

    On Thursday, May 24, 2018, 4:58:44 p.m. GMT+3, Eric Rescorla <> wrote:  

On Thu, May 24, 2018 at 6:53 AM, Yuval Lifshitz <> wrote:

 more inline
    On Thursday, May 24, 2018, 4:18:06 p.m. GMT+3, Eric Rescorla <> wrote:  

On Wed, May 23, 2018 at 11:33 PM, Yuval Lifshitz <> wrote:

    On Thursday, May 24, 2018, 6:41:17 a.m. GMT+3, Eric Rescorla <> wrote:  
 Eric Rescorla has entered the following ballot position for
draft-ietf-dime-rfc4006bis-08: No Objection

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 statement/discuss-criteria. html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here: doc/draft-ietf-dime- rfc4006bis/

------------------------------ ------------------------------ ----------
------------------------------ ------------------------------ ----------

Rich version of this review at:

I only gave this a light read. Some minor comments below.

S 1.2.
>        deduction of credit from the end user account when service is
>        completed and refunding of reserved credit that is not used.
>      Diameter Credit-control Server  A Diameter credit-control server acts
>        as a prepaid server, performing real-time rating and credit-
>        control.  It is located in the home domain and is accessed by

a definition of "home domain" would be useful

[yuval] base spec define "home realm" we should probably change to that

S 2.
>      credit-control application.
>      When an end user requests services such as SIP or messaging, the
>      request is typically forwarded to a service element (e.g., SIP Proxy)
>      in the user's home domain.  In some cases it might be possible that
>      the service element in the visited domain can offer services to the

also define visited domain, or at least point to a reference.

[yuval] base spec defined "local realm" for that. will fix

S 3.1.
>                                  [ CC-Correlation-Id ]
>                                  [ User-Equipment-Info ]
>                                  [ User-Equipment-Info-Extension ]
>                                  *[ Proxy-Info ]
>                                  *[ Route-Record ]
>                                  *[ AVP ]

Please expand AVP on first use.

[yuval] it is in the base spec

I'm sure it is, but you should still expand it. 
[yuval] sure we can (it would be a bit awkward though, in the world of "Diameter" it will be like explaining what TCP stands for...)
[yuval] in the list, but not marked as "well known". OTOH, that document gives some freedom to the RFC editor. Given that the first couple of occurrences of AVP in the spec are in titles and inside ABNF, there isn't a reasonable place to expand that. If someone tries to read any Diameter application spec, without the base one they would probably run into other issues as well

S 4.
>      control client requests credit authorization from the credit-control
>      server prior to allowing any service to be delivered to the end user.
>      In the first model, the credit-control server rates the request,
>      reserves a suitable amount of money from the user's account, and
>      returns the corresponding amount of credit resources.  Note that

Sorry, reserves the balance or the amount reserved?

[yuval] not sure what is not clear?

As I said above, do you return the balance or do you return the amount of credit that has been reserved.
[yuval] return the reserved amount

OK, the text should say it.
[yuval] ok. will rephrase


S 14.
>      Even without any modification to the messages, an adversary can
>      eavesdrop on transactions that contain privacy-sensitive information
>      about the user.  Also, by monitoring the credit-control messages one
>      can collect information about the credit-control server's billing
>      models and business relationships.

I'm having trouble reading these two paragraphs. Are they about what
happens if TLS isn't used?

[yuval] will clarify. see here: lbertz02/rfc4006bis/issues/51

This doesn't seem dramatically clearer. What sort of an adversary can do that?
[yuval] in some cases e2e security is not possible, this is what this section is addressing, the github issue is to clarify that


______________________________ _________________
DiME mailing list listinfo/dime