Re: [TLS] Revision 10: possible attack if client authentication is allowed during PSK

[Ilari Liusvaara <[e-mail]>]

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