On Sun, Nov 01, 2015 at 04:36:43AM +0900, Eric Rescorla wrote: > > I've been planning to do a big rewrite of the security "analysis" sections > and while I don't think it's worth having a real analysis in the protocol > (the literature is going to do a much better job here than we can), this > seems like exactly the kind of thing that we do want to capture to > explain the design and for future extensions.
What I think is also very important with regards to security is explaining the properties of interfaces to applications. E.g. I want to be able to find answer to "Can I authenticate a client by reading value off TLS-EXTRACTOR and signing it?"[1][2] in the final RFC. Or "Can I key something non-TLS off TLS-Extractor" (yes). And with regards to protocol analysis, the thing that nails you with highest probability (after known bad ideas) is some oddball feature that nobody really analyzes (or analyzes in non-realistic ways, for this documenting assumptions at external interface is VERY useful). These often allow taking cracks in one part of the protocol and then amplifying those to actual attacks. [1] The answer being: Yes, but: - You also need ciphersuite if you need cross-collision resistance (TLS certificate auth would be vulernable to CC if another PRF- hash with 256 or 384 bit output was added). - In versions previous to TLS 1.3, you need extended_master_secret negotiated (because otherwise TLS-Extractor outputs aren't nonces). [2] While TLS does have built-in client certificate authentication, application-layer certificate authentication can be much more flexible, doing things that are just plain infeasible to do in TLS layer (like fine-grained authentication). -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
