On Thu, Apr 13, 2017 at 09:29:27PM -0700, Joseph Salowey wrote: > Hey Folks, > > At the IETF 98 meeting in Chicago there was support in the room to adopt > draft-sullivan-tls-exported-authenticator [0]. We are looking for feedback > on adopting this draft form the list. Please respond if you support the > draft and are willing to review it. If you object to its adoption, please > let us know why. Please respond to the list by 20170501 >
Looking at the draft and reviewing it: - Section 1: The section should also say a bit why not to use post-handshake authentication. Which is not available at all for server, won't work properly with multiplexed connections, etc... - Section 2: Probable typo: "encryped" (in last line of first paragraph on page 3). - Section 2: I think there should be "(for TLS 1.3)" after reference to the TLS 1.3 draft in definition of handshake context. Otherwise it will read oddly after draft reference gets replaced by reference to the RFC. - Section 2: I think the finished MAC key length should always follow the PRF hash. TLS 1.2 with EMS requires well-defined PRF hash anyway, and some cipher- suites have SHA-1 as HMAC hash. - Section 2 I think giving random number as example of request context is bad, and one should instead give some sequence number (with possible gaps) as example. These things do not have to be random, and generating sequence numbers in connection context is much easier than random numbers. - Section 2: The spec should be clear if message headers are included or not (the hashes seem injective either way). If message headers are included, perhaps wrap the context into synthethic hash message like with first CH when retrying handshake in TLS 1.3. One could even reuse the message type (#254). - Section 4: Nitpick: The framework is usually called SIGMA, not SIGMAC (reference). - Section 4: The last two security considerations look pretty hard to understand, and overly long. As I understand it, those paragraphs mean something like: ---------------------- Authenticators are independent and unidirectional, and as consequence: * It is difficult to formally prove an endpoint is jointly authoritative over multiple certificates instead of individually authoritative over each. * There is no feedback on if authenticator was processed, at what point of connection it was processed nor if it was accepted. Any such feedback needs to be implemented at application layer.if required. ---------------------- (As note, the TLS-built-in authentication fails most of the second part as well, for various reasons. - Section 4: Perhaps add consideration that this SHOULD be implemented inside TLS library (or at least as an library), even if it is possible to implement outside it. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
