Channel Bindings for TLS 1.3
draft-ietf-kitten-tls-channel-bindings-for-tls13-16

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: The IESG <iesg@ietf.org>, alexey.melnikov@isode.com, draft-ietf-kitten-tls-channel-bindings-for-tls13@ietf.org, kitten-chairs@ietf.org, kitten@ietf.org, paul.wouters@aiven.io, rfc-editor@rfc-editor.org
Subject: Protocol Action: 'Channel Bindings for TLS 1.3' to Proposed Standard (draft-ietf-kitten-tls-channel-bindings-for-tls13-16.txt)

The IESG has approved the following document:
- 'Channel Bindings for TLS 1.3'
  (draft-ietf-kitten-tls-channel-bindings-for-tls13-16.txt) as Proposed
  Standard

This document is the product of the Common Authentication Technology Next
Generation Working Group.

The IESG contact persons are Paul Wouters and Roman Danyliw.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-kitten-tls-channel-bindings-for-tls13/

Ballot Text

Technical Summary

   This document defines a channel binding type, tls-exporter, that is
   compatible with TLS 1.3 in accordance with RFC 5056, On Channel
   Binding. It also updates default channel binding used by SCRAM-*
   and GS2-* families of SASL mechanism when they are used over TLS 1.3+.

Working Group Summary

   This document was not particularly controversial in the KITTEN WG.
   The IETF Last Call prompted a significant amount of discussion when
   forwarded to the TLS WG list, resulting in this document no longer having
   an Updates: relationship with RFC 8446 and the addition of a section
   discussing the impact of using a TLS-Exporter value that does not change
   over the lifetime of the TLS connection when there are multiple distinct
   authentication protocols consuming the channel binding value.

Document Quality

   A couple people indicated plans to implement.
   Jonathan Hoyland was the main reviewer to raise the topic of
   non-uniqueness when channel bindings are reused within a TLS connection.
   He has indicated that the new text resolves his concerns adequately.

Personnel

   Alexey Melnikov is the document shepherd.
   Paul Wouters is the responsible AD.

RFC Editor Note