Subject: Re: [TLS] draft-sullivan-tls-exported-authenticator-00

From: William Whyte <[email-masked]>
Date: Tue, 1 Nov 2016 04:41:44 -0400

I'm confused by the line "These messages are not encrypted", because on a
plain reading it could mean that the authenticator is sent outside the
encrypted TLS session. That would be bad because it would mean that clients
that wanted to authenticate themselves but to the server only wouldn't be
able to use this mechanism. I assume that's not the intent? If that isn't
the intent, suggest rephrasing as "These messages are not encrypted, other
than the encryption provided on transmission by the TLS session".

Cheers,

William

On Mon, Oct 31, 2016 at 5:29 PM, Nick Sullivan <[email-masked]>
wrote:

> <https://tools.ietf.org/html/
> <https://tools.ietf.org/html/draft-sullivan-tls-exported-authenticator-00>
> draft-sullivan-tls-exported-authenticator-00>
> <https://tools.ietf.org/html/draft-sullivan-tls-exported-authenticator-00>
>
> I just posted a new Internet-Draft called "Exported Authenticators in TLS"
> in the TLS working group.
>
> The intent of this draft is to enable participants in a TLS connection to
> prove ownership of additional certificates. This differs from previous
> proposals (https://tools.ietf.org/html/draft-sullivan-tls-post-
> handshake-auth-00) in that these proofs are not sent as part of the TLS
> connection, but instead exported so that they can be sent out of band (as
> part of an application layer message, for example).
>
> This proposal should enable a radical simplification of the Secondary
> Certificate Authentication in HTTP/2 proposal (
> https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs-01),
> and should generally be a useful tool for binding a certificate ownership
> proof to a TLS connection.
>
> Nick Sullivan
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: Andrei Popov <[email-masked]>
Date: Tue, 1 Nov 2016 17:17:39 +0000

Yes, this line has confused me as well.

Cheers,

Andrei

From: TLS [mailto:[email-masked]] On Behalf Of William Whyte
Sent: Tuesday, November 1, 2016 1:42 AM
To: Nick Sullivan <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] draft-sullivan-tls-exported-authenticator-00

I'm confused by the line "These messages are not encrypted", because on a plain reading it could mean that the authenticator is sent outside the encrypted TLS session. That would be bad because it would mean that clients that wanted to authenticate themselves but to the server only wouldn't be able to use this mechanism. I assume that's not the intent? If that isn't the intent, suggest rephrasing as "These messages are not encrypted, other than the encryption provided on transmission by the TLS session".

Cheers,

William

On Mon, Oct 31, 2016 at 5:29 PM, Nick Sullivan <[email-masked]<mailto:[email-masked]>> wrote:
<https://tools.ietf.org/html/<https://tools.ietf.org/html/draft-sullivan-tls-exported-authenticator-00>draft-sullivan-tls-exported-authenticator-00><https://tools.ietf.org/html/draft-sullivan-tls-exported-authenticator-00>
I just posted a new Internet-Draft called "Exported Authenticators in TLS" in the TLS working group.

The intent of this draft is to enable participants in a TLS connection to prove ownership of additional certificates. This differs from previous proposals (https://tools.ietf.org/html/draft-sullivan-tls-post-handshake-auth-00) in that these proofs are not sent as part of the TLS connection, but instead exported so that they can be sent out of band (as part of an application layer message, for example).

This proposal should enable a radical simplification of the Secondary Certificate Authentication in HTTP/2 proposal (https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs-01), and should generally be a useful tool for binding a certificate ownership proof to a TLS connection.
Nick Sullivan

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 1 Nov 2016 20:57:36 +0200

> than the encryption provided on transmission by the TLS session".

What I think it means that the authenticator is not encrypted before
handing it to the application for transport (most probably ultimately
ending inside the TLS connection itself, which does encrypt it on the
wire).

Also, the message emitted is formatted as follows, right?

- Byte 0x0B (CERTIFICATE code)
- 3-byte length of Certificate message
- Standard TLS 1.3 Certificate message payload
- Byte 0x0F (CERTIFICATE_VERIFY code)
- 3-byte length of CertificateVerify message
- Standard TLS 1.3 CertificateVerify message payload
- Byte 0x14 (FINISHED code)
- 3-byte length of Finished message
- Standard TLS 1.3 Finished message payload

-Ilari

---

From: William Whyte <[email-masked]>
Date: Tue, 1 Nov 2016 16:17:13 -0400

That makes sense, but it'd be good to clarify the text. Thanks!

William

-- sent from my phone