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

From: Joseph Salowey <[email-masked]>
Date: Thu, 13 Apr 2017 21:29:27 -0700

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

Cheers,

J&S

[0] https://datatracker.ietf.org/doc/html/draft-sullivan-
tls-exported-authenticator

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 14 Apr 2017 14:44:25 +0300

> 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

---

From: Andrei Popov <[email-masked]>
Date: Fri, 14 Apr 2017 17:45:08 +0000

I’ve been reviewing this draft and support its adoption.

Cheers,

Andrei

From: TLS [mailto:[email-masked]] On Behalf Of Joseph Salowey
Sent: Thursday, April 13, 2017 9:29 PM
To: [email-masked]
Subject: [TLS] Call for adoption of draft-sullivan-tls-exported-authenticator

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

Cheers,

J&S

[0] https://datatracker.ietf.org/doc/html/draft-sullivan-tls-exported-authenticator<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-sullivan-tls-exported-authenticator&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C3af55cf776c54cf655b308d482eeea57%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636277410028932388&sdata=2glZJH1PFo355%2F94VkAj0gW6McjSayD%2BV%2FGdtjcWL0o%3D&reserved=0>

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 14 Apr 2017 13:23:46 -0500

I've also been reviewing this draft and support its adoption.

-Ben

On 04/14/2017 12:45 PM, Andrei Popov wrote:
> *From:* TLS [mailto:[email-masked]] *On Behalf Of *Joseph Salowey
> *Sent:* Thursday, April 13, 2017 9:29 PM
> *To:* [email-masked]
> *Subject:* [TLS] Call for adoption of
> draft-sullivan-tls-exported-authenticator
>
>  
>
> 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
>
> Cheers,
>
> J&S
>
>  
>
> [0] https://datatracker.ietf.org/doc/html/draft-sullivan-tls-exported-authenticator
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fdatatracker.ietf.org-252Fdoc-252Fhtml-252Fdraft-2Dsullivan-2Dtls-2Dexported-2Dauthenticator-26data-3D02-257C01-257CAndrei.Popov-2540microsoft.com-257C3af55cf776c54cf655b308d482eeea57-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C636277410028932388-26sdata-3D2glZJH1PFo355-252F94VkAj0gW6McjSayD-252BV-252FGdtjcWL0o-253D-26reserved-3D0&d=DwMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=HBD5TP2klpHW87xZgRdBnrJrcdrhC_hYFP8g0-u1_EQ&s=-7lDewEzRZt9Aps2-M0w7jj6Kwmt-Rf-tvBzcNRqlgs&e=>
>
>
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Patrick McManus <[email-masked]>
Date: Fri, 14 Apr 2017 15:48:06 -0400

I have read this draft and believe the final consensus version of this
function will be of high value to the HTTP ecosystem in particular - I
support TLS-WG adopting it.

On Fri, Apr 14, 2017 at 12:29 AM, Joseph Salowey <[email-masked]> wrote:

> 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
>
> Cheers,
>
> J&S
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 15 Apr 2017 16:41:52 +0300

> Looking at the draft and reviewing it:

Another edge-case I figured:

How do certificate type extensions (#9, #19 and #20) work with exported
authenticators?

Where other extensions are either meaningless or are edditional info,
certificate types actually change the format of the first certificate,
which the library needs to understand in order to extract the SPKI for
validating the following CertificateVerify.

-Ilari

---

From: Victor Vasiliev <[email-masked]>
Date: Tue, 18 Apr 2017 11:29:31 -0400

I've read the draft, and I support its adoption.  I believe that the
mechanism
is sound for its stated use.

I have some minor concerns about the wording in the draft, though.  First,
the
draft describes the authenticators as sent "out-of-band", while my
understanding is that they are always intended to be sent in-band as
application data.  If they were truly sent out-of-band, there would be some
questions about the security analysis, because that would imply those could
be
sent unprotected.  Hence, I suggest the draft to adapt the premise that
exported authenticators MUST be sent as application data within the same
connection.  This might simplify your security proofs too.

The second issue I have is with the question of when does authentication
succeed.  In TLS, by the time any party can send application data, normally
(with exception of server-to-client data in client auth case) both parties
know
that the other side has authenticated them.  Here, a new identity is
introduced
while application data can be already in flight, and it's not clear to me
when
the sender of the exported authenticator can act assuming the peer has
accepted
its new identity.  My current understanding is that this issue is deferred
to
the application layer, but it would be nice to discuss those considerations
explicitly.

The last question I have is how does this interact with the state of TLS
connection.  Does accepting a new identity mean that the entire connection
now
has that identity too?  Does this mean that the session tickets issued after
the library receives the authenticator are valid for the new identity?
Does it
make the tickets sent previously on that connection valid for the new
identity?

Also, what is the distinction between "jointly authoritative for A and B"
and
"individually authoritative for A and individually authoritative for B"?

  -- Victor.

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 18 Apr 2017 19:33:27 +0300

On Tue, Apr 18, 2017 at 11:29:31AM -0400, Victor Vasiliev wrote:
> know that the other side has authenticated them. 

I don't think that is actually true for client authentication (even in-
handshake).

> Here, a new identity is introduced while application data can be already
> in flight, and it's not clear to me when the sender of the exported
> authenticator can act assuming the peer has accepted its new identity.
> My current understanding is that this issue is deferred to the application
> layer, but it would be nice to discuss those considerations explicitly.

IMO, the application layer is the only layer that actually knows the
relevant state.

> now has that identity too?  Does this mean that the session tickets issued
> after the library receives the authenticator are valid for the new
> identity? Does it make the tickets sent previously on that connection valid
> for the new identity?

I believe this is up to the application.

(And even in case of TLS authentication, I think some of these are
"implementation-dependent".

> and "individually authoritative for A and individually authoritative for
> B"?

Pretty much the whole paragraph mentioning that reads like some mumbo-
jumbo to me (not a good sign).

-Ilari

---

From: Nico Williams <[email-masked]>
Date: Tue, 18 Apr 2017 13:13:33 -0500

> let us know why. Please respond to the list by 20170501

I support adoption.

---

From: Nick Sullivan <[email-masked]>
Date: Tue, 18 Apr 2017 21:56:28 +0000

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-masked]>
wrote:

> feedback
Can do.

> Probable typo: "encryped" (in last line of first paragraph on page 3).
Fixed.

> after draft reference gets replaced by reference to the RFC.
Good catch.

> 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)

> numbers in connection context is much easier than random numbers.
Ok.

> 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?

> 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.

> As I understand it, those paragraphs mean something like:

Yes, it was hard to read. Thanks for the summary, I've re-written it to be
more clear in the PR.

> library (or at least as an library), even if it is possible to implement

 Updated text.

---

From: Nick Sullivan <[email-masked]>
Date: Tue, 18 Apr 2017 22:18:03 +0000

On Sat, Apr 15, 2017 at 6:42 AM Ilari Liusvaara <[email-masked]>
wrote:

> adopt

I think it would be fair to only support server-generated exported
authenticators with the certificate_type negotiated by the TLS handshake.
If the client sent a list of server_certificate_types in its client hello,
then only authenticators of that type can be used (with the chosen type
included an extension to the certificate message). Similarly, if the
server's EE message contains a single client_certificate_type, that would
be the only type supported by client-generated exported authenticators. I
can add text to this effect (
https://github.com/grittygrease/tls-exported-authenticator/issues/12).

---

From: Nick Sullivan <[email-masked]>
Date: Tue, 18 Apr 2017 22:22:42 +0000

Thanks for the review. I'm open to adding text indicating that the exported
authenticator SHOULD be sent using an application protected by the TLS
stream in question, but I don't want to remove the possibility of sending
the data over a secure secondary channel, depending on the application.

Nick

On Tue, Apr 18, 2017 at 8:29 AM Victor Vasiliev <[email-masked]> wrote:

> questions about the security analysis, because that would imply those
> could be
>> [0]
>> https://datatracker.ietf.org/doc/html/draft-sullivan-tls-exported-authenticator
>>

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 19 Apr 2017 08:47:52 +0300

> https://github.com/grittygrease/tls-exported-authenticator/issues/12).

There are two bad problems with this:

- The certificate types in TLS 1.3 are a bad hack just for bare minimum
  support for RPK. Using the thing for client post-handshake auth is
  completely unworkable. And adding new certificate types is pretty
  much only workable in special applications[1].

- Relying on TLS capability negotiation is fundamentally problematic.
  There capabilties may not match. And things get downright unworkable
  when things like signature algorithms are considered.

[1] The recent ITS stuff might be one of these applications. Basically,
you can only handle one certificate per type, any more and one gets
issues. And one certificate per type impiles that one does not need
post-handshake authentication.

-Ilari