Tasks Assignments in the Sprint Planning

No one should be assigning tasks to Developers, especially the Scrum Master.  The Scrum Guide has this statement in the section that describes the Sprint Planning event (I added the emphasis)

Topic Three: How will the chosen work get done?

For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less. How this is done is at the sole discretion of the Developers. No one else tells them how to turn Product Backlog items into Increments of value.

If the Developers choose to assign tasks during Sprint Planning, that is their choice.  But no one else should assign them work.  

In my experience with successful teams, assigning the work for an entire Sprint before work begins usually ends up causing problems.  The Daily Scrum is for the Developers to plan their work for the day or until their next Daily Scrum (i.e. accounting for weekends or holidays).  So the assignments made during Sprint Planning often change based upon who is available to do work when it is needed. Letting the Developers develop a plan and then pull work onto themselves is a much better way to adapt to changes as information is received.  Otherwise you are using methods from the older styles of project management, such as waterfall development.  While those styles can work in some situations and for some organizations, they do not lend themselves to be able to quickly adapt to changes. 

I hope you could help me with this debate I've been having with my team Scrum Master about assigning tasks to the devs in the middle of the sprint planning

Wouldn't it be better if the Developers decided during the Sprint which of them actions an item from the Sprint Backlog?

Bear in mind that a Sprint Backlog is an emergent body of work -- a forecast of what the Developers think they need to achieve the Sprint Goal. In Sprint Planning they cannot be certain about which tasks are even required.

Why don't you talk about this in retrospect?

But the most crucial element is to comprehend WHY the Scrum master is allocating tasks, and if he is operating exactly like a conventional project manager in a waterfall project, why this bunch of people are calling themselves "Scrum team".

Once you have the answers, you have two options: either accept the fact that in reality, nothing like Scrum actually occurs in your team and that Scrum may not be the best option for your business and  continue working in the current environment as a usual IT team with so called Scrum master being just a team manager.

Or help Scrum master to understand Scrum better. You could  facilitate meetings and training sessions to help the scrum master understand Scrum better; which is something you can do as a developer Scrum team member.

I would suggest you bring this up in the let the retrospective as Nicholas Gabrichidze suggested and guide the team to explore what Daniel Wilhite presented. It's always good to let the team have a healthy discussion and suggest to "let's see what the scrum guide says" rather than preach them. Trust me !