Why use HTTPS in the DP-3T Protocol?
TLS connections have 3 important, distinct properties:
- privacy, i.e. protection against eavesdropping
- authentication, to make sure the parties communicating are really who they pretend to be
- integrity, meaning the data cannot be modified during transmission
It seems your opponents argue only against the first one, but the other two are critical for most applications. For DP-3T in particular, lack of authentication would mean an attacker could intercept a transmission and drop it while the application would think the code has been transmitted successfully.
And more generally, TLS nowadays is cheap and easy to setup. You would need a very good reason not to use it rather than one to use it. In fact, at least for iOS, it is explicitly required that an app uses transport security, and exceptions must be justified.
Along with cybercriminals willing to do wiretapping over wireless networks, today's complicated networks typically carry a great number of different surveillance middleboxes for different purposes. Those devices not only eavesdrop, but can sometimes modify the transmitted data in arbitrary ways, intentionally or unintentionally.
E.g. a DPI equipment installed by an ISP can be set up to replace the Web site advertisement with the ISP's ads. If configured in a wrong way, this equipment would then also replace unrelated parts of Javascript or XML code in the data streams transmitted by mobile apps or Web sites.
This is just one example.
Therefore, the contemporary threat model for Web sites and mobile apps just assumes encrypted HTTPS as transport. HTTPS is rather easy to set up these days, it comes for free and eliminates such a great number of opaque and complex threats and potential bugs that it's easier and much more reliable — from the operational standpoint — to set it up than to not.
The opponents maintain that using HTTPS is obfuscating the app, that the app should behave transparently and send all the traffic over HTTP so they can see what they are sending, because the data is "anonymous" anyway.
I'm going to assume the boldfaced "they" refers to the end user, and not to the developers (because if it does refer to the developers, then this is a straightforward problem of not using appropriate debugging techniques such as server-side logging).
Realistically, how many of your end users are going to be running Wireshark or a similar piece of software? Of those that are technically proficient enough to run Wireshark, how many are seriously going to find HTTPS traffic suspicious? It's quite possibly the second most popular (layer 7) protocol in the world (after SMTP, I would tend to imagine), and as you say, the DP-3T protocol explicitly requires its use. Anyone who would find it suspicious is unlikely to know enough about networking technology to use Wireshark in the first place. In my opinion, the use of unsecured HTTP is more likely to provoke suspicion than the use of HTTPS.
On the other hand, it's quite possible to hide data in unencrypted network streams using any number of different forms of steganography (in this case, by hiding some data in the purportedly "random" ephemeral IDs that are used by DP-3T, and/or in the secret key when it gets uploaded for an infection report; both of those are opaque blobs of binary data with no meaningful structure for the user to introspect). So the fact that the technical end user is capable of monitoring your app's traffic doesn't actually help all that much with trust anyway.
In any event, we can clearly see that:
- This doesn't convince non-technical users of anything.
- It's unlikely to be effective in convincing technical users that your app is safe, and might convince them that your app is unsafe or at least poorly-designed.
- As described in multiple other answers, TLS does other things besides confidentiality, and that may compromise the security of your implementation in other ways.