Re: [openssl-dev] Can I haz TLS 1.3 ?
On 3 October 2017 at 20:45, Hanno Böck wrote: > On Tue, 3 Oct 2017 17:36:03 + > "Salz, Rich via openssl-dev" wrote: > > So I heard chatter about this, but not much details. Which I find > unfortunate and a bit disturbing. (I'm aware of a single case with > bluetooth HW, but this sounds like this is much more common.) > > http://bluecoat.force.com/knowledgebase/articles/Technical_Alert/32878 Cheers Rich. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Can I haz TLS 1.3 ?
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 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@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 dif
Re: [openssl-dev] Can I haz TLS 1.3 ?
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@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
Re: [openssl-dev] Can I haz TLS 1.3 ?
Can the people involved in these Tests please speak up what's going on here? Particularly can you please name vendor names? Tbe TLSWG mailing list is probably a more effective place to have that discussion; I was just informing the OpenSSL community of the state of play ;) -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Can I haz TLS 1.3 ?
Hi, On Tue, 3 Oct 2017 17:36:03 + "Salz, Rich via openssl-dev" wrote: > 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 I heard chatter about this, but not much details. Which I find unfortunate and a bit disturbing. (I'm aware of a single case with bluetooth HW, but this sounds like this is much more common.) Can the people involved in these Tests please speak up what's going on here? Particularly can you please name vendor names? And quite frankly I think we need to have a discussion about those vendors. They're harming the Internet and they shouldn't be able to do so without consequences. TLS 1.3 is already built to workaround broken middleboxes (the whole new version negotiation and GREASE approach), yet it doesn't seem to help. If I may dream I'd like to see a situation where large TLS-friendly players (thinking Google, Cloudflare etc.) speak up and say that in the future they'll boycott vendors that deploy such Internet-breaking devices. -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
