Subject: [TLS] Fixing TLS

From: Peter Gutmann <[email-masked]>
Date: Tue, 12 Jan 2016 14:03:53 +0000

Martin's comment reminded me of the following that I've been meaning to
post...

In a recent discussion among some crypto folks, the topic of what TLS 1.3
could be came up.  Now by TLS 1.3 I mean TLS 1.3 as a simple upgrade path from
TLS 1.2, not the TLS 2.0-called-TLS 1.3 that it currently is.  The discussion
centered around the fact that we already have lots of analysis done for TLS
1.x, and it's not too hard to create a TLS 1.3 that fixes the TLS < 1.3
problems while being as compatible as possible with existing infrastructure.
So what this would do is take existing security analysis applied to TLS,
namely:

Bhargavan et al, "Proving the TLS handshake secure (as is)".

Brzuska et al, "Less is more: relaxed yet compatible security notions for key
exchange".

Dowling et al, "Modelling ciphersuite and version negotiation in the TLS
protocol".

Firing, "Analysis of the Transport Layer Security protocol".

Gajek et al, "Universally Composable Security Analysis of TLS".

Giesen et al, "On the security of TLS renegotiation".

Jager et al, "On the security of TLS-DHE in the standard model".

Krawczyk et al, "On the security of the TLS protocol".

(and probably several more) and use them to simplify TLS 1.2 to create an
improved TLS that leverages about 15 years of analysis, rather than creating
what's almost a new protocol based on bleeding-edge/experimental ideas,
mechanisms, and algorithms.

The discussion started out somewhat informally so by the time it got really
interesting it was too late to take notes, but I thought I'd try and recreate
the design points...

- Drop 99% of all cipher suites, leaving one traditional one (DHE + AES-CBC +
  HMAC-SHA2 + RSA-SHA2/PSK for auth) and one ECC one (ECDHE + AES-GCM + HMAC-
  SHA2 + ECDSA-SHA2/PSK for auth) as must's (with a strong preference for OCB
  instead of GCM as the AEAD if it were freely available).

- For the non-AEAD cipher, use EtM not MtE (so effectively making it AEAD as
  well).

- Get rid of the IPsec cargo-cult MAC truncation.

- For DHE, send the full set of parameters (X9.42), not p+g only (PKCS #3) to
  allow verification (for those who don't have a copy of X9.42, it requires
  the same verification steps as FIPS 186 does).  Also, mix the hash of the
  DHE values into the computed premaster secret to protect against use of
  manipulated curves.

- RSA-PSS, not PKCS #1 (with a subset arguing for PKCS #1 with the sig-check
  done as encode-then-compare, which fixes all known padding-manipulation
  issues).

- No compression or rehandshake.

- Replace the PRF with HKDF?  (No pressing need for this, but it would be part
  of the general cleanup).

Longer discussion points:

- The DHE/ECDHE parameters were a bit contentious.  For DHE the choice is
  between server-specified ephemeral parameters and IETF-blessed fixed ones.
  Arguments can be made either way, we had de facto IETF-blessed fixed DHE
  params in the form of the RFC 2409 ones, but that wasn't such a good idea.
  OTOH with ephemeral DHE params many implementations didn't check them, but
  then the spec never required any checking (or much of anything at all in
  regard to DHE use, which no doubt contributed to some of the dubious
  practices that have been found in the wild).  The situation wasn't helped by
  the use of the PKCS #3 representation, which the requirement to use the
  X9.42 form alongside the accompanying checks attempts to address.
  
- Similarly, for ECDHE the choice is between NIST and CFRG ones.  The CFRG
  ones are obviously better (for various values of better, see endless debates
  elsewhere), but some people will insist on only using something that's come
  from NIST (I'll reserve my opinion on that one, and wouldn't dream of
  stooping to phrases like "cargo cult protocol design"...).

Peter.

---

From: Dave Garrett <[email-masked]>
Date: Tue, 12 Jan 2016 12:02:26 -0500

> So what this would do is take existing security analysis applied to TLS,
[...]

Welcome to the TLS 1.2.1 proposal club. Unfortunately, we don't have snacks.

I'll be the bearer of bad news and tell you that your proposal has come up in multiple forms. I suggested a similar thing a while back and far before me others have as well. The chairs have, however, long declared consensus that we want to focus on a single new version not leaving out other more complex changes, namely latency improvements. The primary argument is that TLS version adoption rates are horrible and we would be far better suited to one major upgrade rather than incremental changes that would likely inhibit adoption of the more complex changes that we also need. (just a quick summary from my view; someone else can chime in here if they need to)

I can't dispute this position, though personally I think it's not the best move. That said, if we were going to do a more incremental TLS version, doing it along side HTTP/2 to avoid the messy TLS restrictions it ended up with would have been the way to go. That ship has sailed, and we're now well into TLS 1.3 development, so I guess I'm now on board with working to finalize the work that we're already doing (frankly, with a rename to TLS 2.0 being a good idea). If you can somehow drum up consensus to overturn the previous consensus, more power to you, but I think that's not likely to be the best route anymore.

Dave

---

From: Yoav Nir <[email-masked]>
Date: Tue, 12 Jan 2016 19:13:33 +0200

Hi, Peter

Ignoring for a moment the merits of this proposal vs the TLS 1.3 (or 2.0) that this WG is working on right now, why?

Other groups are not working on HTTP/1.2 or IKEv1.1 or any other $protocolv$(major-1).$(minor+1).

Any TLS library that exists now doesn’t have an implementation of either “your” TLS 1.3 or “our” TLS 1.3. To get either, you’ll need to get an upgraded version of your favorite library. So the upgrade path is no smoother for either protocol.   If this had been brought up before the work on the current draft started, maybe we would be convinced. As it is, I don’t see the point.

Yoav

> On 12 Jan 2016, at 4:03 PM, Peter Gutmann <[email-masked]> wrote:
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 12 Jan 2016 19:17:06 +0200

> So what this would do is take existing security analysis applied to TLS,

Don't forget that there is lots of "features" that are security
problems to deprecate. And that alone creates problems with software
trying to use those.
 
> mechanisms, and algorithms.

Bleeding edge ideas? They essentially re-invented SIGMA, which is over
10 years old. The basic framework for doing 0-RTT is the obvious one.
The only new algorithm prsent since TLS 1.2 is HKDF, which is just 5
years old. 

So I don't see anything "experimential" ideas, mechanisms or algorithms
in there
 
>   instead of GCM as the AEAD if it were freely available).

DHE has serious problems. While the present TLS 1.3 way of doing DHE
isn't totally horrible, advertise DHE and you can get downnegotiation to
TLS 1.2 DHE, and now you are screwed.

Also, AES-CBC has multitude of problems. And they actually dropped most of
the ciphersuites.

> - For the non-AEAD cipher, use EtM not MtE (so effectively making it AEAD as

Easier to define everything in terms of AEAD mode. Making generic
composition AES-CBC+HMAC-SHA2 isn't as easy as it seems (even pro
cryptographers may not get that right).

> - Get rid of the IPsec cargo-cult MAC truncation.

Finished hashes are no longer truncated (which turned to be a security 
problem).
 
>   DHE values into the computed premaster secret to protect against use of

The needed checks at that length are just too slow for realtime.

>   done as encode-then-compare, which fixes all known padding-manipulation

Well, the server sig for RSA is RSA-PSS (the recommendation about encode-
and-compare isn't the tho).

> - No compression or rehandshake.

They dropped those.

> - Replace the PRF with HKDF?  (No pressing need for this, but it would be part

They replaced it with just that.

>   X9.42 form alongside the accompanying checks attempts to address.

Dubious? I would say downright insecure (including some I would say F
grade in SSL labs is too generous).

>   stooping to phrases like "cargo cult protocol design"...).

There's also Brainpool (if you want to burn CPU, those are just
inefficient). :-)

-Ilari

---

From: Peter Bowen <[email-masked]>
Date: Tue, 12 Jan 2016 09:27:40 -0800

On Tue, Jan 12, 2016 at 9:02 AM, Dave Garrett <[email-masked]> wrote:
> I'll be the bearer of bad news and tell you that your proposal has come up in multiple forms. I suggested a similar thing a while back and far before me others have as well. The chairs have, however, long declared consensus that we want to focus on a single new version not leaving out other more complex changes, namely latency improvements.

Rather than talking about this as TLS 1.2.1 (or 1.3), is the smarter
way to go to document a profile of TLS 1.2 that covers almost all of
this.  From a quick read, existing RFCs and I-Ds cover most of this:
- RFC 5246 (TLS 1.2 & TLS_DHE_RSA_WITH_AES_128_CBC_SHA256)
- RFC 5487 (TLS_DHE_PSK_WITH_AES_128_CBC_SHA256)
- RFC 5289 (TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256)
- RFC 7366 (EtM)
- RFC 7627 (extended master secret)
- RF 4055 (RSA-PSS)

The gaps seem to be:
- No TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 cipher suite allocated
(BoringSSL has an implementation using cipher suite 0xca,0xfe)
- DH parameters -- the alternative would be using FFDH named groups
(draft-ietf-tls-negotiated-ff-dhe-10), right?

This would only leave "Get rid of the IPsec cargo-cult MAC truncation", right?

Thanks,
Peter

---

From: Watson Ladd <[email-masked]>
Date: Tue, 12 Jan 2016 09:29:16 -0800

> Any TLS library that exists now doesn’t have an implementation of either “your” TLS 1.3 or “our” TLS 1.3. To get either, you’ll need to get an upgraded version of your favorite library. So the upgr…

Not if TLS 1.2.1 is a subset of TLS 1.2, similar to the UTA profile.
In fact, that's what happened the last time this idea was raised: it
got kicked over to UTA.

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 12 Jan 2016 09:41:26 -0800

> TLS 1.2 DHE, and now you are screwed.

Nit: this shouldn't be possible with the anti-downgrade mechanism that was
introduced
in draft-11 because the server's signature will cover the random value. If
you area
aware of an issue here, I would appreciate more information.

-Ekr

---

From: Peter Bowen <[email-masked]>
Date: Tue, 12 Jan 2016 09:51:28 -0800

> (BoringSSL has an implementation using cipher suite 0xca,0xfe)

Correction: draft-mattsson-tls-ecdhe-psk-aead-03 defines this suite.
Still no cipher suite allocated, but there is an active draft.

---

From: Dave Garrett <[email-masked]>
Date: Tue, 12 Jan 2016 13:06:32 -0500

> Still no cipher suite allocated, but there is an active draft.

I have a short WIP PR for integrating these suites into the TLS 1.3 draft sitting on GitHub, by the way.

https://github.com/tlswg/tls13-spec/pull/381

Unless I'm misunderstanding the procedure here, though, that draft needs to progress to WG adoption before we're ready for it here. (hence the WIP label)

Dave

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 12 Jan 2016 10:13:01 -0800

On Tue, Jan 12, 2016 at 10:06 AM, Dave Garrett <[email-masked]>
wrote:

> Unless I'm misunderstanding the procedure here, though, that draft needs
> to progress to WG adoption before we're ready for it here. (hence the WIP
> label)

This matches my understanding of the policy.

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 12 Jan 2016 20:23:03 +0200

> aware of an issue here, I would appreciate more information.

Won't help here, since the server just doesn't support TLS 1.3. The
issue isn't that TLS 1.2 was negotiated, it is that the client is now
faced with old-style DHE.

-Ilari

---

From: David Benjamin <[email-masked]>
Date: Tue, 12 Jan 2016 18:25:12 +0000

> (BoringSSL has an implementation using cipher suite 0xca,0xfe)

0xca,0xfe has since been removed as nothing was using it. I'm not aware of
anything that ever shipped with it enabled.
https://boringssl.googlesource.com/boringssl/+/1feb42a2fbbd8c1a1ed945edb5836d69f7241cda

David

---

From: Bill Cox <[email-masked]>
Date: Tue, 12 Jan 2016 11:27:02 -0800

On Tue, Jan 12, 2016 at 9:02 AM, Dave Garrett <[email-masked]>
wrote:

> I'll be the bearer of bad news and tell you that your proposal has come up
> in multiple forms. I suggested a similar thing a while back and far before
> me others have as well. The chairs have, however, long declared consensus
> that we want to focus on a single new version not leaving out other more
> complex changes, namely latency improvements. The primary argument is that
> TLS version adoption rates are horrible and we would be far better suited
> to one major upgrade rather than incremental changes that would likely
> inhibit adoption of the more complex changes that we also need. (just a
> quick summary from my view; someone else can chime in here if they need to)
>
> I can't dispute this position, though personally I think it's not the best
> move. That said, if we were going to do a more incremental TLS version,
> doing it along side HTTP/2 to avoid the messy TLS restrictions it ended up
> with would have been the way to go. That ship has sailed, and we're now
> well into TLS 1.3 development, so I guess I'm now on board with working to
> finalize the work that we're already doing (frankly, with a rename to TLS
> 2.0 being a good idea). If you can somehow drum up consensus to overturn
> the previous consensus, more power to you, but I think that's not likely to
> be the best route anymore.
>

I'll just second what David said here.  0-RTT mode is here to stay, and I
don't see a simple upgrade path from TLS 1.2.  Speed matters, and 0-RTT is
a huge upgrade for users.  The trick is doing this securely...

My opinion counts little here, and TLS 1.3 is already nearly completely
defined, so I think it is too late for this discussion.  However, if it
were not...

A clean-slate TLS 2.0 which reuses as little as possible, and simplifies
life as much as possible, would have been preferable, IMO.  I look at the
QUIC crypto code and then go back to the TLS/SSL code, and there is a night
and day difference in complexity.  I think it is going to be painful for
some of us to watch the simple, clean QUIC crypto code move to the archives
and get replaced with TLS 1.3, which is surely going to be a substantial
bolt-on of code to the existing TLS 1.2 code base.  It takes a super-genius
just to see all the potential pitfalls in the TLS 1.2 code as it is.  I
think it will be even harder to analyze after the TLS 1.3 bolt-on.
Fortunately, we seem to have a large number of super-geniuses working in
TLS, much of the present company on this thread included :)  However, if I
personally were making changes to the code, it would be maybe 4X faster to
do it in QUIC crypto, and 4X more likely that I would not introduce a
critical bug in the process.

I think it is natural for many members of this email list to discount this
complexity issue in TLS 1.2/1.3, since many of the most brilliant
programmers see the existing code as not all that complex.  For regular
mortal programmers out there like me, we would very much appreciate a
clean-slate effort with minimal complexity, and there are a lot of lessons
you folks have learned over the years that could be included.

Maybe next time, in TLS 1.4? :-p

Bill

---

From: Dave Garrett <[email-masked]>
Date: Tue, 12 Jan 2016 14:39:15 -0500

> Maybe next time, in TLS 1.4? :-p

Personally, I hope this new version of TLS, save for possibly some minor update & extensions, is the final version. I hope that Google's efforts to get QUIC as-is specced out go quickly and smoothly, and that it can be used as a basis to develop an official total TCP/TLS replacement. (the early documentation for QUIC was horrible, but the current work is vastly improved) As far as I'm concerned, TLS 1.3 is a transitional measure which should only be used in the medium-term by those who adopt new tech very slowly, and in the long-term phased out entirely. It is a very important transitional measure that needs to be done with as high a security and performance as possible, but a finite one nonetheless. (well, arguably, pretty much everything is, given a long enough timeframe ;) We have to get through the short-term to get to the long-term, though.

Dave

---

From: Andrei Popov <[email-masked]>
Date: Tue, 12 Jan 2016 20:03:42 +0000

> I hope that Google's efforts to get QUIC as-is specced out go quickly and smoothly, and that it can be used as a basis to develop an official total TCP/TLS replacement.

If this were the path forward (and I doubt that it is), I would very much prefer Peter Gutman's evolutionary TLS 1.3.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Dave Garrett
Sent: Tuesday, January 12, 2016 11:39 AM
To: Bill Cox <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] Fixing TLS

On Tuesday, January 12, 2016 02:27:02 pm Bill Cox wrote:
> > I'll be the bearer of bad news and tell you that your proposal has 
> > come up in multiple forms. I suggested a similar thing a while back 
> > and far before me others have as well. The chairs have, however, 
> > long declared consensus that we want to focus on a single new 
> > version not leaving out other more complex changes, namely latency 
> > improvements. The primary argument is that TLS version adoption 
> > rates are horrible and we would be far better suited to one major 
> > upgrade rather than incremental changes that would likely inhibit 
> > adoption of the more complex changes that we also need. (just a 
> > I can't dispute this position, though personally I think it's not 
> > the best move. That said, if we were going to do a more incremental 
> > TLS version, doing it along side HTTP/2 to avoid the messy TLS 
> > restrictions it ended up with would have been the way to go. That 
> > ship has sailed, and we're now well into TLS 1.3 development, so I 
> > guess I'm now on board with working to finalize the work that we're 
> > already doing (frankly, with a rename to TLS
> > 2.0 being a good idea). If you can somehow drum up consensus to 
> > overturn the previous consensus, more power to you, but I think 
> > that's not likely to be the best route anymore.
> 
> I'll just second what David said here.  0-RTT mode is here to stay, 
> and I don't see a simple upgrade path from TLS 1.2.  Speed matters, 
> and 0-RTT is a huge upgrade for users.  The trick is doing this securely...
> 
> My opinion counts little here, and TLS 1.3 is already nearly 
> completely defined, so I think it is too late for this discussion.  
> However, if it were not...
> 
> A clean-slate TLS 2.0 which reuses as little as possible, and 
> simplifies life as much as possible, would have been preferable, IMO.  
> I look at the QUIC crypto code and then go back to the TLS/SSL code, 
> and there is a night and day difference in complexity.  I think it is 
> going to be painful for some of us to watch the simple, clean QUIC 
> crypto code move to the archives and get replaced with TLS 1.3, which 
> is surely going to be a substantial bolt-on of code to the existing 
> TLS 1.2 code base.  It takes a super-genius just to see all the 
> potential pitfalls in the TLS 1.2 code as it is.  I think it will be even harder to analyze after the TLS 1.3 bolt-on.
> Fortunately, we seem to have a large number of super-geniuses working 
> in TLS, much of the present company on this thread included :)  
> However, if I personally were making changes to the code, it would be 
> maybe 4X faster to do it in QUIC crypto, and 4X more likely that I 
> would not introduce a critical bug in the process.
> 
> I think it is natural for many members of this email list to discount 
> this complexity issue in TLS 1.2/1.3, since many of the most brilliant 
> programmers see the existing code as not all that complex.  For 
> regular mortal programmers out there like me, we would very much 
> appreciate a clean-slate effort with minimal complexity, and there are 
> a lot of lessons you folks have learned over the years that could be included.
> 

Dave

_______________________________________________
TLS mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2ftls&data=01%7c01%7cAndrei.Popov%40microsoft.com%7c882faa8317114da26f3e08d31b881439%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=mMYoE%2bpBJpL6NKES01ZsFsN%2bwsf%2f8G7OwBhRkfWWDpI%3d

---

From: Bill Cox <[email-masked]>
Date: Tue, 12 Jan 2016 12:12:39 -0800

On Tue, Jan 12, 2016 at 11:39 AM, Dave Garrett <[email-masked]>
wrote:

> Personally, I hope this new version of TLS, save for possibly some minor
> update & extensions, is the final version. I hope that Google's efforts to
> get QUIC as-is specced out go quickly and smoothly, and that it can be used
> as a basis to develop an official total TCP/TLS replacement. (the early
> documentation for QUIC was horrible, but the current work is vastly
> improved) As far as I'm concerned, TLS 1.3 is a transitional measure which
> should only be used in the medium-term by those who adopt new tech very
> slowly, and in the long-term phased out entirely. It is a very important
> transitional measure that needs to be done with as high a security and
> performance as possible, but a finite one nonetheless. (well, arguably,
> pretty much everything is, given a long enough timeframe ;) We have to get
> through the short-term to get to the long-term, though.
>
>
> Dave
>

I wish that were the plan (to upgrade QUIC crypto and eventually make that
the new crypto platform).  If I am not mistaken, QUICK crypto is going to
be archived, TLS 1.3 will replace the crypto code, and QUIC will remain the
transport layer.  So, maybe long-term you folks could do a clean-slate TLS
2.0?  That would would be awesome, IMO.

Bill

---

From: Dave Garrett <[email-masked]>
Date: Tue, 12 Jan 2016 15:14:13 -0500

On Tuesday, January 12, 2016 03:03:42 pm Andrei Popov wrote:
> On Tuesday, January 12, 2016 02:39:15 pm Dave Garrett wrote:

I was just chatting a bit off-list, and apparently I wasn't aware of QUIC's latest plans, so it's not as clear as I previously said. Unfortunately, it seems that they have yet to actually write anything down (a too frequent pattern with QUIC), so I can't really comment on what I'd like to see happen in this realm anymore.

In any case, ~whatever~ comes after TLS 1.3 will hopefully have some major changes. I have no idea what that will be, but TLS 1.3 comes first. That's a discussion for a future time.

Dave

---

From: Tony Arcieri <[email-masked]>
Date: Tue, 12 Jan 2016 12:18:04 -0800

> 2.0?  That would would be awesome, IMO.

Have you looked at OPTLS? It provides a clean "core" for TLS, and also
supports Diffie-Hellman authentication ala Trevor Perrin's protocol Noise.

If TLS 1.3 can shed the cruft, OPTLS seems like a nice direction to go for
"TLS 2.0"

-- 
Tony Arcieri

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 12 Jan 2016 12:18:11 -0800

On Tue, Jan 12, 2016 at 12:12 PM, Bill Cox <[email-masked]> wrote:

> transport layer.

This is my understanding as well, based both onconversations with the QUIC
folks, and Adam and Jana's public presentations. A number of us (MT, I,
Jana, Ian, AGL, Christian) have already started some initial conversations
at how to do that.

With that said, I don't think there's a plausible story in which QUIC
becomes the only
transport protocol in the world any time soon, so I don't think standalone
TLS 1.3
is going away.

-Ekr

---

From: Kurt Roeckx <[email-masked]>
Date: Tue, 12 Jan 2016 21:20:29 +0100

> a huge upgrade for users.  The trick is doing this securely...

And I think because it's seems non-obvious how to get that correct
implementations may delay implementing that part.

Kurt

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 12 Jan 2016 12:25:36 -0800

On Tue, Jan 12, 2016 at 12:18 PM, Tony Arcieri <[email-masked]> wrote:

>> I wish that were the plan (to upgrade QUIC crypto and eventually make
>> that the new crypto platform).  If I am not mistaken, QUICK crypto is going
>> to be archived, TLS 1.3 will replace the crypto code, and QUIC will remain
>> the transport layer.  So, maybe long-term you folks could do a clean-slate
>> TLS 2.0?  That would would be awesome, IMO.
>>
>
> "TLS 2.0

TLS 1.3 actually takes quite a bit of stuff from OPTLS (as you can see in
the most
recent OPTLS paper). To a great extent, the differences
are due to explicit WG decisions, specifically the following two decisions;

- Not to have an offline-signed DH credential
- To require signing on every public-key-based handshake.

IIRC there was pretty strong consensus for both these decisions, but if
there is
a lot of feeling to the contrary, presumably we could revisit these.

-Ekr

--

---

From: Dave Garrett <[email-masked]>
Date: Tue, 12 Jan 2016 15:33:59 -0500

> Jana, Ian, AGL, Christian) have already started some initial conversations

I'm quite interested to hear what the plans are there. I'd appreciate it if, whenever there is a fleshed-out starting point, an outline could be posted to this list to keep us in the loop with what's going to be the initial design. Not necessarily for debate here, but just so we can have an idea of where things are going.

> With that said, I don't think there's a plausible story in which QUIC becomes the only
> transport protocol in the world any time soon, so I don't think standalone TLS 1.3
> is going away.

Yes. Whatever the discussion for future work, TLS 1.3 is the current direction. One step at a time so we don't trip over our feet. ;)

Dave

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 12 Jan 2016 12:35:13 -0800

On Tue, Jan 12, 2016 at 12:33 PM, Dave Garrett <[email-masked]>
wrote:

> that
> I'm quite interested to hear what the plans are there. I'd appreciate it
> if, whenever there is a fleshed-out starting point, an outline could be
> posted to this list to keep us in the loop with what's going to be the
> initial design. Not necessarily for debate here, but just so we can have an
> idea of where things are going.
>

We definitely would post that somewhere, but thanks for the reminder to
send a pointer
to TLS WG.

-Ekr

> Yes. Whatever the discussion for future work, TLS 1.3 is the current
> direction. One step at a time so we don't trip over our feet. ;)
>
>
> Dave
>

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 13 Jan 2016 01:12:12 +0000

Yoav Nir <[email-masked]> writes:

>Ignoring for a moment the merits of this proposal vs the TLS 1.3 (or 2.0)
>that this WG is working on right now, why?

Embedded devices and similar systems with long-term requirements.  Most of my
user base is embedded (or non-embedded equivalents, systems that need to run
in a fixed configuration for a very long time after they're deployed).  As
I've mentioned in an earlier post, the median point on the bell curve is
probably around TLS 1.0/1.1.  These are systems with an expected lifetime of
10-20 years or more, deployment of new versions moves slowly and carefully so
the less radical changes you need to make the better, and most importantly you
can't roll out patches every month or two when the next attack on TLS is
published.

To expand on this, I'll take Ilari Liusvaara's comments:

>Bleeding edge ideas? They essentially re-invented SIGMA, which is over 10
>years old. The basic framework for doing 0-RTT is the obvious one. The only
>new algorithm prsent since TLS 1.2 is HKDF, which is just 5 years old.
>
>So I don't see anything "experimential" ideas, mechanisms or algorithms in
>there

When SSLv3 was introduced, it also used ideas that were 10-20 years old (DH,
RSA, DES, etc, only SHA-1 was relatively new).  They were mature algorithms,
lots of research had been published on them, and yet we're still fixing issues
with them 20 years later (DH = 1976, SSLv3 = 1996, Logjam = 2015).

TLS 2.0-called-1.3 will roll back the 20 years of experience we have with all
the things that can go wrong and start again from scratch.  SIGMA, at ten
years old, is a relative newcomer to DH's 20 years when it was used in SSLv3,
but in either case we didn't discover all the problems with it until after the
protocol that used it was rolled out.  We currently have zero implementation
and deployment experience with 2.0-called-1.3 [0], which means we're likely to
have another 10-20 years of patching holes ahead of us.  This is what I meant
by "experimental, bleeding-edge".

What TLS 1.3-which-is-1.3 should be is an LTS version that's essentially
what's already out there with the bugs fixed, and where you've got a pretty
good chance that you won't be rolling out hotfixes every other month to patch
the newly-discovered-vulnerability of the month (which, in the case of most
things that aren't web browsers and servers, is more or less impossible to
do).

(Which also means that the requirements for it should include explicit "don't
use MD5, don't use keys < 1024 bits, don't precompute DH and reuse the
values", all the other obvious-but-apparently-not-obvious-enough stupid that's
turned up recently).

TLS 2.0-called-1.3 seems to be doing the same thing that HTTPS 2 did,
targeting the specialised requirements of web servers/browsers and ignoring
everything else.  The HTTPS 2 WG's response to this at the time was "let them
eat HTTP 1.1", so that you've now got HTTP-for-Google (2.0) and HTTP-for-
everything-else (1.1).  Is the TLS equivalent going to be "let them eat TLS
1.1"?

(General note: That one short post has generated an enormous amount of email
 off-list as well as on, for all those waiting for replies to private mail,
 please be patient, I'm working through it...).

Peter.

[0] This all feels somewhat biblical, "you are 2.0 son of 1.2, but you will be
	known as 1.3".

---

From: Watson Ladd <[email-masked]>
Date: Tue, 12 Jan 2016 17:31:34 -0800

> can't roll out patches every month or two when the next attack on TLS is

So for your proposal to solve this problem, it needs to be more likely
to be secure then TLS 1.3. Of course, the slow rollout gives time to
thoroughly test massive changes, while large numbers of small changes
will not be a good idea.

> with them 20 years later (DH = 1976, SSLv3 = 1996, Logjam = 2015).

We all understand that the security of a protocol is not a function
not of the primitives but of the way the protocol works. The confusion
between export and nonexport DH shares was noted almost immediately in
SSLv3. Furthermore, 512 bit DH is weak: I don't know how this is a
discovery in 2015, given that the reasons for this were all worked out
in the early 90's. So no, Logjam is not a result of unknown issues
appearing after 20 years, but ignoring known issues.

> by "experimental, bleeding-edge".

There is an old joke about the resume with one years experience
repeated 20 times. All of the problems in TLS have been known for
decades, as I've repeatedly demonstrated on this list. All of them
were known to cryptographers at the time TLS was being designed and
deployed. It does not take deployment to trigger analysis.

> things that aren't web browsers and servers, is more or less impossible to

TLS 1.3 is being designed in cooperation with people who *actually
know cryptography* with computer-based models and theorem provers for
the entire protocol. Your proposal isn't, instead patching a
collection of known issues. But we already did that in UTA. I don't
see why we should believe your proposal solves it better.
> everything-else (1.1).  Is the TLS equivalent going to be "let them eat TLS

What features in TLS 1.3, other than 0-RTT (which is optional!) make
it unsuitable for embedded devices?

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 13 Jan 2016 10:53:36 +0100

On Tue, 2016-01-12 at 19:13 +0200, Yoav Nir wrote:
> Hi, Peter
> 
> Ignoring for a moment the merits of this proposal vs the TLS 1.3 (or
> 2.0) that this WG is working on right now, why?

Note that these are not security protocols and they don't benefit from
a formal analysis of a protocol. Such an analysis takes several years
to be done and it often applies to small parts of the protocol.
Switching to a new version invalidates all the existing analysis.

That is of course not necessarily bad, but as we are moving towards
formally verified protocols it is very bad to give these two options:
1. Stay with a formally verified but with known vulnerabilities
protocol
2. Switch to a new unknown protocol which has not been studied by as
many cryptographers but is _believed_ to solve the issues found in TLS.

> Any TLS library that exists now doesn’t have an implementation of
> either “your” TLS 1.3 or “our” TLS 1.3. To get either, you’ll need to
> get an upgraded version of your favorite library. So the upgrade path
> is no smoother for either protocol.   If this had been brought up
> before the work on the current draft started, maybe we would be
> convinced. As it is, I don’t see the point.

The main problem of TLS 1.2 is that it is vulnerable to cross-protocol
attacks and there is no way to mitigate that. There was such an attack
described in 2012 and another in 2015 [0]. Whether there will be a new
one in 2017 is an open question. Switching to a protocol like TLS 1.3
as it is today to fix that thing it is an overkill.

That is because TLS 1.3 is a rewrite of the protocol, and requires a
rewrite of the code base. Given that the majority of the issues in TLS
implementations are in the code bases and not in the protocol, it is
very risky to switch to such a new version just like that. For old
systems it most likely will never happen and they will remain
vulnerable.

[0]. https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf

regards,
Nikos

---

From: "SCHWARZ, Albrecht (Albrecht)" <[email-masked]>
Date: Wed, 13 Jan 2016 10:09:04 +0000

> Switching to a protocol like TLS 1.3 as it is today to fix that thing it is an overkill.

The primary purpose of a security protocol is to support security as best as possible. Knowing security gaps causes distrust in general. Probably not in the security protocol experts community, but in the overall communications and information technology industry.
The quantification of "overkill" should be rated from that trust perspective in my opinion.

Albrecht

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Nikos Mavrogiannopoulos
Sent: Mittwoch, 13. Januar 2016 10:54
To: Yoav Nir; Peter Gutmann
Cc: <[email-masked]>
Subject: Re: [TLS] Fixing TLS

> $protocolv$(major-1).$(minor+1).

Note that these are not security protocols and they don't benefit from a formal analysis of a protocol. Such an analysis takes several years to be done and it often applies to small parts of the protocol.
Switching to a new version invalidates all the existing analysis.

That is of course not necessarily bad, but as we are moving towards formally verified protocols it is very bad to give these two options:
1. Stay with a formally verified but with known vulnerabilities protocol 2. Switch to a new unknown protocol which has not been studied by as many cryptographers but is _believed_ to solve the issues found in TLS.

> convinced. As it is, I don’t see the point.

The main problem of TLS 1.2 is that it is vulnerable to cross-protocol attacks and there is no way to mitigate that. There was such an attack described in 2012 and another in 2015 [0]. Whether there will be a new one in 2017 is an open question. Switching to a protocol like TLS 1.3 as it is today to fix that thing it is an overkill.

That is because TLS 1.3 is a rewrite of the protocol, and requires a rewrite of the code base. Given that the majority of the issues in TLS implementations are in the code bases and not in the protocol, it is very risky to switch to such a new version just like that. For old systems it most likely will never happen and they will remain vulnerable.

regards,
Nikos

---

From: Hubert Kario <[email-masked]>
Date: Wed, 13 Jan 2016 12:44:24 +0100

On Tuesday 12 January 2016 15:14:13 Dave Garrett wrote:
> > > I hope that Google's efforts to get QUIC as-is specced out go
> > > quickly and smoothly, and that it can be used as a basis to
> > > develop an official total TCP/TLS replacement.> 
> > If this were the path forward (and I doubt that it is), I would very
> > much prefer Peter Gutman's evolutionary TLS 1.3.
> I was just chatting a bit off-list, and apparently I wasn't aware of
> QUIC's latest plans, so it's not as clear as I previously said.
> Unfortunately, it seems that they have yet to actually write anything
> down (a too frequent pattern with QUIC), so I can't really comment on
> what I'd like to see happen in this realm anymore.
> 
> In any case, ~whatever~ comes after TLS 1.3 will hopefully have some
> major changes. I have no idea what that will be, but TLS 1.3 comes
> first. That's a discussion for a future time.

I remember this one quote, not sure who is it attributed to, but it goes 
something like this:

"I don't know what will replace Ethernet, but I'm sure it also will be 
called Ethernet"

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Hubert Kario <[email-masked]>
Date: Wed, 13 Jan 2016 12:52:27 +0100

On Tuesday 12 January 2016 17:31:34 Watson Ladd wrote:
> >>Bleeding edge ideas? They essentially re-invented SIGMA, which is
> >>over 10 years old. The basic framework for doing 0-RTT is the
> >>obvious one. The only new algorithm prsent since TLS 1.2 is HKDF,
> >>which is just 5 years old.
> >>
> >>So I don't see anything "experimential" ideas, mechanisms or
> >>algorithms in there
> >>
> > When SSLv3 was introduced, it also used ideas that were 10-20 years
> > old (DH, RSA, DES, etc, only SHA-1 was relatively new).  They were
> > mature algorithms, lots of research had been published on them, and
> > yet we're still fixing issues with them 20 years later (DH = 1976,
> > SSLv3 = 1996, Logjam = 2015).
> between export and nonexport DH shares was noted almost immediately
> in SSLv3. Furthermore, 512 bit DH is weak: I don't know how this is a
> discovery in 2015, given that the reasons for this were all worked
> out in the early 90's. So no, Logjam is not a result of unknown
> issues appearing after 20 years, but ignoring known issues.
> 
> > TLS 2.0-called-1.3 will roll back the 20 years of experience we have
> > with all the things that can go wrong and start again from scratch.
> >  SIGMA, at ten years old, is a relative newcomer to DH's 20 years
> > when it was used in SSLv3, but in either case we didn't discover
> > all the problems with it until after the protocol that used it was
> > rolled out.  We currently have zero implementation and deployment
> > experience with 2.0-called-1.3 [0], which means we're likely to
> > have another 10-20 years of patching holes ahead of us.  This is
> > what I meant by "experimental, bleeding-edge".
> 

Exactly this: BEAST and Lucky 13 "possible" problem was described in the 
RFC itself. Same thing for the "new" Bicycle attack - described in the 
RFC for TLS 1.0 and repeated in each version since.

So lets not repeat those mistakes - if there are possible issues, lets 
fix those, now.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Dmitry Belyavsky <[email-masked]>
Date: Wed, 13 Jan 2016 15:11:47 +0300

Hello Hubert,

> So lets not repeat those mistakes - if there are possible issues, lets

But we should leave the description of the fixed problems somewhere to
avoid them in future.

---

From: Hubert Kario <[email-masked]>
Date: Wed, 13 Jan 2016 13:14:48 +0100

On Wednesday 13 January 2016 15:11:47 Dmitry Belyavsky wrote:
> > > not of the primitives but of the way the protocol works. The
> > > confusion between export and nonexport DH shares was noted almost
> > > immediately in SSLv3. Furthermore, 512 bit DH is weak: I don't
> > > know how this is a discovery in 2015, given that the reasons for
> > > this were all worked out in the early 90's. So no, Logjam is not
> > > a result of unknown issues appearing after 20 years, but ignoring
> > > known issues.
> > > 
> > Exactly this: BEAST and Lucky 13 "possible" problem was described in
> > the RFC itself. Same thing for the "new" Bicycle attack - described
> > in the RFC for TLS 1.0 and repeated in each version since.
> > 
> > So lets not repeat those mistakes - if there are possible issues,
> > lets fix those, now.
> 

yes, decisions and recommendations should have rationale attached to 
them. And especially for recommendations, I don't see why we couldn't 
incorporate them in the RFC - at least for one, if the rationale is 
proven wrong it will be easier to explain why the recommendation should 
be disregarded.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 13 Jan 2016 12:32:05 +0000

Hubert Kario <[email-masked]> writes:

>So lets not repeat those mistakes

Exactly, there are more than enough new ones for 2.0-called-1.3 to make that
we don't (necessarily) have to repeat existing ones (although I'm sure we will
in some cases).

And that's exactly my point, we're throwing away 20 years of refining TLS 1.x
and more or less starting again with 2.0-called-1.3, with a whole new set of
mistakes to make.  I really don't want to spend the next 20 years patching all
the holes that will be found in 2.0-called-1.3, I've already had enough of
that for the 1.x version.

TLS needs an LTS version that you can just push out and leave to its own
devices, for the same reason that other products also have LTS versions, that
lots of people have better things to do with their life than playing bugfix
whack-a-mole for the duration of it.

Peter.

---

From: Hubert Kario <[email-masked]>
Date: Wed, 13 Jan 2016 13:44:26 +0100

On Wednesday 13 January 2016 12:32:05 Peter Gutmann wrote:
> Exactly, there are more than enough new ones for 2.0-called-1.3 to
> make that we don't (necessarily) have to repeat existing ones
> (although I'm sure we will in some cases).
> 
> And that's exactly my point, we're throwing away 20 years of refining
> TLS 1.x and more or less starting again with 2.0-called-1.3, with a
> whole new set of mistakes to make.  I really don't want to spend the
> next 20 years patching all the holes that will be found in
> 2.0-called-1.3, I've already had enough of that for the 1.x version.

The only thing I saw in the "TLS 1.2.1" proposal that isn't already 
available is the longer Finished hash and a new signature type. 
Something that an extension can easily fix, rest is just a matter of 
setting a policy *and following it* with respect to used extensions and 
settings.

If you want to patch it up like this, please do. But TLS 1.3 fixes more 
problems.

> TLS needs an LTS version that you can just push out and leave to its
> own devices, for the same reason that other products also have LTS
> versions, that lots of people have better things to do with their
> life than playing bugfix whack-a-mole for the duration of it.

You're asking for impossible. The problems mentioned were not introduced 
into the protocols intentionally to make them obsolete, they are there 
because they weren't seen as big enough to fix. That's the mistake I say 
we should not repeat - "no issue left behind, no matter how small".
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 13 Jan 2016 13:16:32 +0000

> devices

So don't you have that with TLS 1.1 and appropriate cipher and option choices?

---

From: [email-masked] (Martin Rex)
Date: Wed, 13 Jan 2016 14:48:36 +0100 (CET)

> So don't you have that with TLS 1.1 and appropriate cipher and option choices?

Actually, you already have that with TLSv1.0 plus the known mitigations.

The only cryptographical improvement of TLSv1.1 over TLSv1.0 can be
sufficiently achieved with 1+(n-1) record splitting -- for those few
situations where this difference is meaningful at all.

Only web-browsers that will happily execute any attacker supplied
active-content plus the abuse of SSL known as SSL-VPNs need the
record-splitting mitigation for block-ciphers in TLSv1.0.

-Martin

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 14 Jan 2016 00:14:48 +0000

>So don't you have that with TLS 1.1 and appropriate cipher and option

That's the approach suggested previously by Peter Bowen, assemble it yourself
from a huge list of extensions.  The problem there is that you're after a
fixed, known-good config drawn from the maybe 10 extension-RFCs you'd need to
cover (from Peter's post + a few extra to cover new things), I don't want to
go through all of those and count up the possible options but I'm pretty sure
I'd need to resort to special notation to express the magnitude of
combinations once you plug them into the nCk formula.

Based on the feedback I've had, I'm kinda tempted to do a TLS 1.2 LTS draft
that specifices just a single boolean flag, "use this known-good configuration
and not the 6.023e23 other ones and you should be good for the next decade or
so".  That can then be baked into long-term systems and devices and left alone
while people get on with other things.

(Speaking of feedback, still got a bucketload of private email to respond to,
 including stuff from people I didn't know where on the list any more, turns
 out there's a lot more reading than writing, I'm working through it...).

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 14 Jan 2016 00:17:09 +0000

Nikos Mavrogiannopoulos <[email-masked]> writes:

>That is because TLS 1.3 is a rewrite of the protocol, and requires a rewrite
>of the code base. Given that the majority of the issues in TLS
>implementations are in the code bases and not in the protocol, it is very
>risky to switch to such a new version just like that.

+1.  This is exactly what the 1.2LTS approach (at least it has a name now :-)
is trying to address.

Peter.

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 14 Jan 2016 07:06:30 +0200

> while people get on with other things.

To actually fix the known problems with TLS 1.2, you would at minimum
need a new extension, since there is currently no way to fix the broken
server authentication.

Then there are the other security fix extensions (at least three already).
Those all would need to be impiled.

And then there is the TLS 1.2 Diffie-Hellman issue...

-Ilari

---

From: [email-masked] (Martin Rex)
Date: Thu, 14 Jan 2016 10:40:44 +0100 (CET)

Ilari Liusvaara wrote:
> Peter Gutmann wrote:
>> that specifices just a single boolean flag, "use this known-good
>> configuration and not the 6.023e23 other ones and you should be good
>> for the next decade or so".  That can then be baked into long-term
>> systems and devices and left alone while people get on with other things.
> 

One Boolean signaling is sufficent to fix all of the problems.
one SCSV in the Client->Server direction and a TLS extension Boolean
response in ServerHello.

> And then there is the TLS 1.2 Diffie-Hellman issue...

TLS 1.2LTS should fix them all at once, including:

   - promise to support minimum DHE key lengths >= 2048 bits
     whenever ClientHello includes DHE cipher suites

   - promise to support a certain small subset of EC curves
     and uncompressed point format whenever ClientHello includes
     ECDHE cipher suites (but may omit TLS extensions).

   - new/improved ServerKeyExchange handshake message, which
     does not only contain the reasonable set of DHE parameters,
     but also uses a digititally signed covering all prior
     handshake messages, not just the two hello randoms.

   - overriding any TLS record layer protocol version and
     ClientHello.client_version that is less than TLSv1.2

   - promise that digital signatures using SHA-256 are supported

   - fix the misunderstood semantics of the signature_algorithm extension
     so that it is only used as a hint to certificate selection,
     but *NEVER* seen as a hard requirement (or reason for server to
     abort the TLS handshake based on the signature of the server cert).

-Martin

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 14 Jan 2016 12:29:33 +0200

> one SCSV in the Client->Server direction and a TLS extension Boolean

Just stick it as an extension. Extensions have been required since TLS
1.0, its precessor SSL 3.0 is _dead_. And extension-intolerant servers
are just plain problems for everybody.

>      whenever ClientHello includes DHE cipher suites

The problem is that client that tries to be secure will just abort
if it receives DHE <2048 bits. Regardless if server accepted the
extension or not.

Then there's also similar problems with RSA. And then RSA PKCS #1
v1.5 encryption is on just about every "do not use!" list. Get it
wrong (good luck getting it right) and it is game over.

>      ECDHE cipher suites (but may omit TLS extensions).

You have EC formats extension already.

Or do you mean that there are broken endpoints that can't mix-and-
match ECDHE curves and signatures?

(I know about problems doing mix-and-match on hashes and curves
in ECDSA... TLS has currently no way to signal those limits).
 
>      handshake messages, not just the two hello randoms.

You mean fixing the DHE groups? Because the present arbitrary groups
are source of many problems.

This also causes problems for anyone trying to support DHE in TLS 1.3.

>    - promise that digital signatures using SHA-256 are supported

You mean upgrade the default SHA-1 to SHA-256?

>      abort the TLS handshake based on the signature of the server cert).

The client aborts if server certificate chain won't validate due to
bad algorithms, right?

And then:

- Imply Extended Master Secret.

- Require Renego fixes.

- Imply EtM on block modes.

(Any others?)

-Ilari

---

From: [email-masked] (Martin Rex)
Date: Thu, 14 Jan 2016 12:27:07 +0100 (CET)

Ilari Liusvaara wrote:
[ Charset UTF-8 unsupported, converting... ]
> are just plain problems for everybody.

Nope, TLS extensions (rfc3546, jun-2003) are not required, and were not part
of TLSv1.0 (rfc2246, jan-1999).  TLSv1.0 contains only a forward-compatibility
notice as a comment to the ClientHello PDU.  The same notice that was
retrofitted to the carefully hidden SSLv3 specification from November 1996
that was used as a starting point for the TLSv1.0 spec.

But we all know how little interop was tested for this forward compatibility
notice, similar to the untested protocol versions > { 3, 1 } (aka TLSv1.0).

> wrong (good luck getting it right) and it is game over.

Getting PKCS#1 v1.5 right is fairly easy, and requiring it should go into
TLS 1.2LTS as well.  How to do it right for signatures has been
described in PKCS#1 v2.0 (rfc2437, Oct-1998, Section 8.1.2) already,

It is a real pity that neither TLSv1.1 (rfc4346,apr-2006)
nor TLSv1.2 (rfc5246,aug-2008) did not prohibit the dangerous
PKCS#1 v1.5 processing entirely, because that's an extremly
low hanging fruit.

> You have EC formats extension already.

rfc4492 is severly broken, in that it specifies that a ClientHello
without the two TLS EC extensions indicates that the client supports
*EVERYTHING* in the rfc4492 spec (rather than a reasonable default
subset).  I hope that the IESG does not let such obvious breakage
enter the standards track.

> are source of many problems.

I would be OK with implying support for a reasonable small set of
(assumed) secure fixed groups.  But ServerKeyExchange for DHE needs
to be fixed to allow arbitrary groups as well.  They're a performance
problem, so I assume the marketplace will decide.  After the severe
problems of DHE had been publicly described on the TLS mailing
list in 2008, I decided that we will never support DHE in our
(then OEM) implementation, and never regretted that decision.
We've recently addes support for ECDHE, but will not support DHE.

> You mean upgrade the default SHA-1 to SHA-256?

Yup.  What TLSv1.2 (rfc5246) should have done in 2008 already.

> The client aborts if server certificate chain won't validate due to

The client remains free to perform local policy enforcement for any
*incoming* data from the server.

The extreme nuisance with rfc5246 is what Microsoft has shipped in SChannel,
where an extensionless ClientHello offering TLSv1.2 will cause a Microsoft
Server (2008&2012) to choke and abort the TLS handshake when the
server has only a server certificate signed with sha256withRSAEncryption,
wereas it will handshake successfully (and negotiate TLSv1.1) if the
very same client offers only TLSv1.1 or offers TLSv1.2 in an SSL Version 2
CLIENT-HELLO.

> - Imply Extended Master Secret.

wfm.

> - Imply EtM on block modes.

Personally, I do _not_ like this one.
DTLS implementers that followed the poor advise from the DTLS spec
might want this one, though.

I would strongly prefer (pad,mac,encrypt), as originally proposed by
Vaudenay, because it is safer and more secure in TLS.

EtM is bad for support, because it can more easily result in corrupted
plaintext while not showing up as error at the TLS level -- and the application
will not necessarily notice this.  I've already seen this happening in the real
world with AEAD (AES-GCM) in TLS (occasional encryption failures).

-Martin

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 14 Jan 2016 15:41:36 +0200

> [ Charset UTF-8 unsupported, converting... ]

Pfft...

> described in PKCS#1 v2.0 (rfc2437, Oct-1998, Section 8.1.2) already,

I was talking about encryption, not signatures. Those are used by
TLS_RSA_WITH_* ciphersuites. The encrpytion is very broken, the
signatures are at most slightly such.

(And those lists of crypto algorithms don't list RSA PKCS #1 v1.5
signatures the same as encryption).

> enter the standards track.

Does RFC4492bis fix that?
 
> We've recently addes support for ECDHE, but will not support DHE.

It currently allows arbitrary groups, and all the nasty problems that
come with those.

> world with AEAD (AES-GCM) in TLS (occasional encryption failures).

P-E-M would be yet another mode...

Then there is fun question of proving all this secure. I'm way less
comfortable with this than TLS 1.3 security-wise.

-Ilari

---

From: [email-masked] (Martin Rex)
Date: Thu, 14 Jan 2016 15:11:25 +0100 (CET)

Ilari Liusvaara wrote:
> Martin Rex wrote:

Encryption is a public key operation.

Maybe you're thinking of *de*cryption instead (aka Bleichenbacher)?
AFAIK, the Bleichenbacher countermeasure uses the fact that RSA
is homomorphic to multiplication.  Decoding the PKCS#1 v1.2 Blocktype 02
padding of the decrypted RSA premaster secret in constant time does
also not require rocket science.  But it seems sufficiently non-obvious
that example code might help.

> Does RFC4492bis fix that?

rfc4492bis can not fix that, unless a new signal is added that clients
can include in ClientHello and that enables servers to distinguish
rfc4492 peers from rfc4492bis peers.

-Martin