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

[Ilari Liusvaara <[e-mail]>]

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