Sachin, Mostly we agree or agree to talk. One question merits discussion.
You say "it entails that a secure port 'WILL' receive encrypted and plaintext data" I assumed (incorrectly, possibly) that in the security handshakes and data handling, each message is sent with full knowledge of whether the response will be encrypted or plaintext data. Then you choose which port to send each message on, based on whether you expect an encrypted or plaintext response. If so, no port would ever receive both encrypted and plaintext data. I don't see how anything works in the current paradigm if my assumption is false. I will mention that I'm dumbfounded to find that CoAP didn't put one unencrypted bit on the front of a packet that indicates whether the rest of the packet is encrypted or not. Many things would be simpler if they had, and I don't understand how one unencrypted bit of this sort would compromise security. But I'm not a security guy. John Light Intel OTC OIC Development -----Original Message----- From: Agrawal, Sachin Sent: Thursday, June 18, 2015 10:28 AM To: Light, John J; iotivity-dev at lists.iotivity.org Subject: RE: Proposal for IP Adapter and request for feedback Hi John, See below for my responses. Sachin From: Light, John J Sent: Thursday, June 18, 2015 6:15 AM To: Agrawal, Sachin; iotivity-dev at lists.iotivity.org Subject: RE: Proposal for IP Adapter and request for feedback Sachin, Thank you for describing so completely how secure communication works. I have some questions for you. 1. If IoTivity stack communicates all secure traffic on 5684, which is not set with REUSEADDR, how does a second instance (or a non-IoTivity CoAP app) work on the same device? With the described usage, the second instance (and other secure CoAP applications) will fail. I don?t believe we have the right to gain exclusive use of the secure CoAP port. <<SA: Second instance picks up another un-used port for secure communication. Although, I do tend to agree with your opinion that ?it maybe wrong behavior to use ?5684? exclusively.>> 2. You say ?if another Iotivity stack is started on the same platform, it?s secure port will be different?. I don?t see how this works in the code. If I have missed something, it still raises the question of why you use 5684 on the first instance of IoTivity, when you can?t use it for the second and third? If we can securely communicate without exclusive use of 5684 on the second and third instances, why can?t that also work on the first? <<SA: Answered above>> I assumed (incorrectly, possibly) that the two CoAP ports were both used for discovery and initial connection, 5683 for non-secure, 5684 for secure. By always unicasting to dynamic port assignments (secure and non-secure), all CoAP-based applications can share the same two ports simultaneously. <<SA: I agree with you here, but as always 'devils are in the details'. So I would suggest that let's discuss all use-case scenarios (including 'collections') and then move ahead, if we see this is the best path forward>> I assumed (incorrectly, possibly) that a CoAP application that wishes to communicate securely would discover using 5684 instead of 5683, allowing the receiving device to understand the desire for security at the earliest possible moment. <<SA: Yes. But this is not current Iotivity behavior.>> I assumed (incorrectly, possibly) that a multicast message will be sent from the port the multicast receiver should respond to, allowing simple use of dynamic unicast ports for all purposes other than discovery. <<SA: If we work with this assumption, it entails that a secure port 'WILL' receive encrypted and plaintext data. I do not believe this is the way 'https' works.>> After you provide answers to the two questions above, I will abandon my incorrect assumptions. John Light Intel OTC OIC Development
