[openssl-dev] Can I haz TLS 1.3 ?

[Richard Levitte]

It's not specific to devops. Here, a quick history lesson:

https://english.stackexchange.com/questions/20356/origin-of-i-can-haz

Cheers
Richard 

Ted Marynicz <ted.marynicz at gmail.com> skrev: (4 oktober 2017 10:53:35 CEST)
>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
>>
>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.