Re: [TLS] Call for adoption of draft-sullivan-tls-exported-authenticator

[Nick Sullivan <[e-mail]>]

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 <[e-mail]>
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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>