On Mon, Oct 9, 2017 at 9:11 PM, Martin Thomson <martin.thomson@xxxxxxxxx> wrote: > On Tue, Oct 10, 2017 at 10:57 AM, Benjamin Kaduk <kaduk@xxxxxxx> wrote: >> I think that one could make the case that using TLS 1.2 (or higher) greatly >> facilitates having a secure system, and so it could plausibly be required >> by a consuming protocol. > > The problem here is that the protocol is actually HTTP. And that > protocol has requirements already. A recommendation to use TLS 1.2 is > fine, but that is already part of RFC 7525. > >>> needed. Similarly, the prohibition on the use of 0-RTT is groundless. The >> >> I am a little surprised to hear you say that this prohibition is "groundless". >> Given that we require consumers of TLS 1.3 0-RTT data to explictly specify >> an application profile for how it may be used, with the intent to induce >> a careful analysis of the security considerations for sending early data >> messages, it seems quite reasonable to me that a protocol author might >> wish to defer such a painstaking analysis and take the easy choice of >> prohibiting early data. > > This is quite explicitly using HTTP, which has a profile (work in > progress). If that profile is somehow inadequate, then a case should > be made in the draft explaining why (hence the choice of the word). A > reference to TLS 1.3 also has the unfortunate effect of delaying > publication of this draft. Can you provide a pointer? The profile is likely inadequate for this and many other uses of HTTP/TLS if early data is permitted. 0RTT has a large impact across many protocols including those that use HTTP/TLS. If there is no normative language, then it can continue on to be published with the draft for TLS 1.3 being used. This is an application where security is very important, so decisions like this that can be made now should be prior to implementers testing TLS 1.3. Best, Kathleen -- Best regards, Kathleen