Subject: Re: [TLS] Interest in draft-sullivan-tls-exported-authentication

From: Nick Sullivan <[email-masked]>
Date: Tue, 14 Mar 2017 01:00:22 +0000

All,

I have updated the draft in preparation for the IETF 98:
https://tools.ietf.org/html/draft-sullivan-tls-exported-authenticator-01

The details of the protocol haven't changed, but I've included some
security considerations after speaking with Karthikeyan Bhargavan and
others about the cryptographic soundness of the construction.

Nick

On Tue, Jan 3, 2017 at 8:59 PM Joseph Salowey <[email-masked]> wrote:

> There seemed to be support for draft-sullivan-tls-exported-authentication
> (https://tools.ietf.org/html/draft-sullivan-tls-exported-authenticator-00)
> in Seoul.   Since there has not been much discussion of this draft on the
> list we are giving the working group a chance to review the draft before
> calling for adoption later this month.
>
> Cheers,
>
> J&S
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Brian Sniffen <[email-masked]>
Date: Mon, 13 Mar 2017 23:13:55 -0400

Can you help me understand what this means?

      servers that are authoritative for multiple domains the same
      connection but do not have a certificate that is simultaneously
      authoritative for all of them

I'm sure there's a word or two missing between "domains" and "the" in
the first line, but I'm not sure what they are.

More generally, it's great to see a replacement for renegotiation.  Can
you expand (maybe just here?) on the last paragraph of the security
considerations?  I think you mean that the sender of an authenticator
can't tell when it was received & understood.  But I'm not sure the
receiver can tell when it was sent---say, in the case of a smartcard
insertion, or access to a key from satisfying some local attestation
scheme, whether that key access precedes or follows the sending of a
request.

-Brian

-- 
Brian Sniffen
Akamai Technologies

---

From: Nick Sullivan <[email-masked]>
Date: Wed, 15 Mar 2017 19:57:22 +0000

Hi Brian,

Thanks for your comments. Answers inline.

> the first line, but I'm not sure what they are.

This should be:
servers that are authoritative for multiple domains but do not
have a certificate that is simultaneously authoritative for all of them

A common example is an HTTPS reverse proxy that sits in front of
domain1 and domain2, has a certificate for each, but not a single
certificate
that covers both.

> scheme, whether that key access precedes or follows the sending of a

The application protocol can and should do the accounting for which
exported authenticators are created and when they are accepted.
The authenticating application can choose its own context id when
creating the authenticator and the reciever can use it to map the opaque
blob back to the same context id.

Here's a simple example:
- Party 1 creates an authenticator A1 = authenticate(id1, cert chain, key)
- Party 1 sends A1 to Party 2 as part of the application protocol (say as
an H2 frame)
- Party 2 receives and validates A1, obtaining id1 and cert chain
- Party 2 sends back an ACK message such as (id1, valid) at the Application
layer.

At this point, both parties know the authentication status of the
connection and the TLS layer does not. The application keeps track of the
accounting, the TLS layer just mints and validates
authenticators. This enables applications like HTTP/2 to use TLS
certificates for
features that would have previously used renegotiation.

Nick

> >> There seemed to be support for
> draft-sullivan-tls-exported-authentication
> >> (
> https://tools.ietf.org/html/draft-sullivan-tls-exported-authenticator-00)