Thanks for the review. Comments/questions inline. I put together a pull request with your suggested changes here if you would like to review: https://github.com/grittygrease/tls-exported-authenticator/pull/11
On Fri, Apr 14, 2017 at 4:44 AM Ilari Liusvaara <[email protected]> wrote: > 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... > Can do. > > - Section 2: > > Probable typo: "encryped" (in last line of first paragraph on page 3). > Fixed. > > - 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. > Good catch. > > - 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. > This was noted before. It's tracked as issue #7 ( https://github.com/grittygrease/tls-exported-authenticator/issues/7) > > - 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. > Ok. > > - 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). > The text uses a plain Hash, not a Transcript-Hash, so there should be no confusion about including message headers. What is the motivation for incorporating message headers? > > - Section 4: > > Nitpick: The framework is usually called SIGMA, not SIGMAC (reference). > The reference here is to the 2016 paper which describes the SIGMA Compiler, which I've seen referenced as SIGMAC, vs. the original SIGMA paper. > > - 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. > Yes, it was hard to read. Thanks for the summary, I've re-written it to be more clear in the PR. > > > - 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. > Updated text. > > > -Ilari > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
