Re: Protocol Action: 'The Transport Layer Security (TLS) Protocol Version 1.3' to Proposed Standard (draft-ietf-tls-tls13-28.txt)

[Spencer Dawkins at IETF <[e-mail]>]

On Wed, Mar 21, 2018 at 11:39 AM, Eggert, Lars <[e-mail]> wrote:

> No more chasing TLS draft versions.
>

One of the TSV ADs is happier than the SEC ADs about that ...

Spencer


>
> Lars
>
> Begin forwarded message:
>
> *From: *The IESG <[e-mail]>
> *Subject: **Protocol Action: 'The Transport Layer Security (TLS) Protocol
> Version 1.3' to Proposed Standard (draft-ietf-tls-tls13-28.txt)*
> *Date: *March 21, 2018 at 10:02:02 GMT
> *To: *"IETF-Announce" <[e-mail]>
> *Cc: *[e-mail], [e-mail], [e-mail],
> [e-mail], The IESG <[e-mail]>,
> [e-mail]
> *Reply-To: *[e-mail]
>
> The IESG has approved the following document:
> - 'The Transport Layer Security (TLS) Protocol Version 1.3'
>  (draft-ietf-tls-tls13-28.txt) as Proposed Standard
>
> This document is the product of the Transport Layer Security Working Group.
>
> The IESG contact persons are Kathleen Moriarty and Eric Rescorla.
>
> A URL of this Internet Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/
>
>
>
>
> Technical Summary
>
>   This document specifies version 1.3 of the Transport Layer Security
>   (TLS) protocol.  TLS allows client/server applications to communicate
>   over the Internet in a way that is designed to prevent eavesdropping,
>   tampering, and message forgery.
>
> Working Group Summary
>
>  The document is the work product of the members of the TLS
>  WG.  There is strong consensus in the working group for this
>  document.  The area that was most controversial was around
>  the inclusion of a 0-RTT mode that has different security
>  properties than the rest of TLS.  s1.3 lists the major differences
>  from TLS1.2, as agreed by the contributors; we do not think
>  that the RFC needs to list the changes that occurred between
>  each draft.
>
>  The draft has had 3 WGLCs to address various issues and the
>  chairs assessment was fair in each of these discussions.  At this
>  point there are no known outstanding issue.
>
>  While I personally do not agree with inclusion of 0-RTT because
>  there are bound to be successful attacks against the mitigations
>  in the future, I do agree with the chair's assessment of the WG
>  consensus and am pleased with the additional text on mitigating
>  the associated risks with 0-RTT.
>
> Document Quality
>
>  There are over 10 interoperable implementations of the
>  protocol from different sources written in different
>  languages.  The major web browser vendors and TLS
>  libraries vendors have draft implementations or have
>  indicated they will support the protocol in the future.  In
>  addition to having extensive review in the TLS working
>  group, the protocol has received unprecedented security
>  review by the academic community.  Several TRON (TLS
>  Ready or Not) conferences were held with academic
>  community to give them a chance to present their
>  findings for TLS.  This has resulted in improvements to
>  the protocol.  There was also much consideration and
>  discussion around any contentious points, resolved through
>  polls and working group last calls.
>
>  Please note that ID-nits complains about the obsoleted/
>  updated RFCs not being listed in the abstract. This is
>  intentional because the abstract is now a concise and
>  comprehensive overview and is free form citations, as
>  per RFC7322.
>
> Personnel
>
>   The Document Shepherd is Sean Turner.
>   The responsible AD is Kathleen Moriarty.
>
>   The IANA Expert(s) for the registries
>   in this document are
>     Yoav Nir <[e-mail]>,
>     Rich Salz <[e-mail]>, and
>     Nick Sullivan <[e-mail]> .
>
> IANA Note
>
>  This document requests the creation of the TLS SignatureScheme
>  Registry with values assigned via Specification Required [RFC8126].
>
>  This document requests the reference for several registries be
>  updated to point to this document.  The registries include:
>  - TLS Cipher Suite Registry, updated via via Specification Required
> [RFC8126]
>  - TLS ContentType Registry, future values allocated via Standards Action
> [RFC8126]
>  - TLS Alert Registry, future values allocated via Standards Action
> [RFC8126]
>  - TLS HandshakeType Registry, future values allocated via Standards
> Action [RFC8126]
>  - TLS ExtensionType Registry, the policy is changed in
> ietf-tls-iana-registry-updates and this will be reflected in version 25 of
> the draft
>
>
> RFC Editor Note
>
> Please ensure a reference is added prior to final publication for the
> text added in section
> E.6. PSK Identity Exposure
> of draft-ietf-tls-tls13
>
>
>