On Mon, Oct 9, 2017 at 7:57 PM, Benjamin Kaduk <kaduk@xxxxxxx> wrote: > On Sun, Oct 08, 2017 at 10:08:26PM -0700, Martin Thomson wrote: >> >> The requirements in Section 5.3 on TLS use are unnecessarily strict. It's >> great to recommend the use of TLS 1.2, but given that the document has no real >> requirement on any particular version of TLS, the use of "MUST" here is not > > 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. +1 and this has pretty much been standard practice on all protocols using TLS for at least the last 3 years. RFC7525 has been a requirement on most protocols using TLS since it was published. This is a protocol that will carry sensitive data and strict requirements are necessary. Examples of data that might be exchanged with this protocol include threat actor information or indicators of compromise. Strict security is necessary and completely expected by those deploying this protocol. > >> 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. +1. In the case of this protocol, there is no tolerance for replay attacks. Many other protocols use TLS and will have similar requirements. This is likely to be a theme. The performance gain isn't worth the tradeoffs - of defining a profile, risking configuration mistakes, the careful analysis, and weighing the security considerations. The 0-RTT decision in the TLS WG has a big impact on other protocols using it. Kathleen > > -Ben > >> lengthy list of requirements around certificate validation only risk creating a >> conflict with advice in other RFCs. Many, if not all, of these requirements -- Best regards, Kathleen