[openssl-dev] Can I haz TLS 1.3 ?

[Ted Marynicz]

Haz?

Is that some kind of devops-speak I am not (yet) aware of?

Ted
(a grand-father)

On 3 October 2017 at 18:36, Salz, Rich via openssl-dev <
openssl-dev at openssl.org> wrote:

> Some people have asked why TLS 1.3 isn’t available yet.  This might help;
> it’s a draft of a posting for my company’s blog.
>
>
>
>
>
> Can I Haz TLS 1.3 ?
>
>
>
> Everybody wants to be able to use TLS 1.3. Among the reasons are:
>
>                 It’s faster – being able to reconnect to a server you’ve
> previously used, and saving a full round-trip latency is impressive.
>
>                 It’s more reliable – the protocol has been cleaned up and
> simplified. For example, the related concepts of sessions, tickets, and
> pre-shared keys are merged and treated consistently. To a protocol
> designer, it is much more elegant, and therefore much easier to implement
>
>                 It’s more secure – Many world-class cryptographers have
> been involved in the protocol design, analyzed it, and tried to break it.
>
>
>
> TLS has been in the “last call” for several weeks now.  What does that
> mean, and what’s holding it up?
>
>
>
> The IETF is the organization that defines most of the standards that
> define how the Internet works. They cover everything from naming (DNS) to
> routing around firewalls, up to and including HTTP. The documents, known as
> RFCs, are created by working groups, passed to a steering committee for
> review, and then published as “Internet Standards.”
>
>
>
> Participation in a working group (WG) is, by design, very easy and not a
> lot of overhead.  You just have to join a mailing list.  Every WG has a
> mailing list and there are currently more than 110 working groups hosted at
> the IETF. Each one has a status page, that shows their charter (what they
> are working on), the current sent of documents, and pointers to the mailing
> lists.  For the TLS working group, that page is at
> https://datatracker.ietf.org/wg/tls/documents/.
>
>
>
> Future RFC’s start as Internet-Drafts. Each draft usually goes through
> multiple revisions, as the working group members comment on it, other
> feedback is addressed, and so on.  At some point, the authors or editors
> will post a new draft.  By convention, every working group draft is named
> “draft-ietf-{WGNAME}-{subject}-{nn}” where {WGNAME} is the name of the
> working group, {subject} is the name of the document, and {nn} is the
> revision number.  For example, “draft-ietf-tls-tls13-21” is the 21st
> draft of the TLS 1.3 specification from the TLS working group.
>
>
>
> When the working group thinks a document is done, it enters WGLC, working
> group last call.  This period, usually lasting a couple of weeks, is the
> last chance to make editorial or serious factual fixes.  Since most people
> are deadline-driven, this is usually when many on the WG wake up and read
> the drafts. After WGLC, it goes to the IESG (technical leadership
> basically) for review.  As I said, TLS 1.3 has been in WGLC for weeks.  So
> why can’t we use it yet?
>
>
>
> First, the different drafts don’t interoperate. Each represents a
> different milestone on the way to the full specification, and a flag in the
> header identifies which draft is being used. OpenSSL, used by most of the
> servers on the Internet, is currently at draft-21. Chrome and Firefox, two
> of the most popular browsers on the Internet, are staying at draft-18; they
> don’t want to upgrade until we have the final version. (I think that’s
> silly, but I don’t work for either browser.)
>
>
>
> Tests run by various companies, including Google, Mozilla, and Facebook,
> indicate that the “failure rate” of TLS 1.3 is disturbingly high. It
> appears that network hardware such as routers, gateways, load balancers and
> the like, are blocking TLS 1.3 packets because they don’t recognize the
> protocol. They are doing “fail closed” and block the connections because
> they don’t understand it, rather than assuming it’s safe to forward. The
> IETF often uses the term “middlebox” to describe such hardware that
> operates between endpoints, and this type of behavior that blocks new
> protocols as “ossificiation.”  The various companies, and no doubt others,
> are trying experiments to tweak the protocol to lower the failure rate. For
> example, in some circumstances it might be acceptable to make a TLS 1.3
> message look like a TLS 1.2 message (after you’ve already committed to
> doing TLS 1.3).
>
>
>
> So far nobody has released any details. When it happens, it will be on the
> TLS-WG mailing list, which you can find at the page I referenced above.
> Until then, because of the draft differences, it’s impractical to run even
> limited deployment tests unless you’re willing to work with bleeding edge
> releases and undocumented flags. That’s unfortunate, and we all hope that
> the situation will be improved by the next IETF meeting in November. Until
> then, we just have to sit tight and wait.
>
>
>
> --
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20171004/cbe8b183/attachment-0001.html>