[TLS] rfc 6520 TLS heartbeat feature

[Jitendra Lulla]

Hi,

As tls 1.3 is being worked upon, older work like rfc 6520 and any enhancements 
to it may not be as important.

Also, particularly the TLS heartbeat feature, which has become famous for wrong 
reasons, is disabled by the SSL implementations eg OpenSSL.

I tried to uncover an issue below pertaining to the heartbeat messages here:

https://www.mail-archive.com/openssl-dev@openssl.org/msg47273.html

Experts struggle to find any significant use of this feature for both the TLS 
and DTLS. 

I am planning to propose enhancements which will include restricted issuance of 
the heartbeat requests (wrt size and frequency)  to avoid the exploit mentioned 
in the link above. A stronger standard will trigger bug/vulnerability free 
implementations. 

I would like to know if  enhancements to this rfc are welcomed or it is there 
to be abandoned completely? 

In other words, is it worth spending time?

Thanks
Jitendra





___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS 1.3 draft 22 middlebox interaction

[R du Toit]

Thank you for the thoughtful responses so far.  I have been working in the 
middlebox arena for more than 20 years, and I am also concerned about the state 
of certain implementations.  I would like to think that the TLS stack that my 
team and I maintain have no serious security flaws, but vulnerabilities in TLS 
stacks have shown that even people with the best of intentions get things wrong 
at times.  Security conscious middlebox vendors would certainly like to fix 
their bugs, while at the same time improving interoperability with TLS 1.3.  
The middlebox in my original post, for example, has already fixed the 0-RTT 
draft-22 interop issue.

 

Anyway, that is my way of saying that there are many people like myself 
following the TLS WG email threads, and we all want to help make TLS a success 
for consumers and enterprises.  It would be good if middlebox vendors could 
actually participate in experiments - especially to iron out some of the corner 
cases.

 

I also want to reply to some specific comments:

 

>> If you're a protocol enforcing middlebox (ugh, these shouldn't exist) you 
>> should get out of the way.

Middleboxes often need to decide if they want to be a MITM or not on a 
per-session basis.  This requires parsing the CH as if the middlebox is a TLS 
server.  It should always be safe to parse the CH, but while the middlebox is 
in this “server phase” it might receive unexpected data before TLS versions 
have been negotiated, or before the middlebox has even decided to terminate the 
TLS session.  I agree that the middlebox should not try to enforce protocol 
checks beyond what is certain.  Up until TLS 1.3, any record that follows a CH 
before SH is received was a protocol error.  It was also a possible indication 
of attack.  For example, many simple attack scripts looking to exploit 
Heartbleed would send a heartbeat record immediately after the CH, without 
waiting for a reply from the server.  I agree that the right place to fix 
Heartbleed is on the server, however there are still vulnerable servers out 
there, and this sort of protocol validation does in fact help.

 

>> Someday the TLSWG will design TLS 1.4 which, like TLS 1.3, has free reign to 
>> change everything past the ServerHello again.

The questions here were actually with regards to 0-RTT data, which occurs 
before the ServerHello.  If the middlebox supports only TLS 1.2, and it 
terminates TLS, is it correct for the middlebox to break the connection when it 
sees 0-RTT data?  Will this be counted as a middlebox “causing” a failure, 
because it does not seem like there is another option for the middlebox if it 
is terminating the TLS session.

 

>> If any of these happens, you are dealing with Undefined Behavior ...

Indeed, and I can imagine other fields being overloaded.  Who would have 
thought at the time that cipher-suites would one day be used as backwards 
compatible signals that can propagate through poorly implemented middleboxes; 
"random" bytes already have special meaning; unknown record types were used in 
attacks; etc.

 

>> However, note that none of the above actually covers 0-RTT. This is because 
>> no earlier version envisioned anything like 0-RTT.

Exactly!

 

--Roelof

 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Preliminary data on Firefox TLS 1.3 Middlebox experiment

[Eric Rescorla]

On Tue, Dec 5, 2017 at 1:35 PM, Eric Rescorla  wrote:

> Hi folks,
>
> I now have some preliminary numbers to share with the group based on
> our Firefox experiments. The executive summary is that our data
> confirms Google's results. More detail below.
>
>
> EXPERIMENTAL DESIGN
> This is a forced experiment in which each client tries all the
> variants. The experiment is deployed via a system add-on (a remotely
> deployable, centrally managed piece of JavaScript code), and then
> takes measurements by trying to do an XHR to a given URL
> (https://mail.google.com/robots.txt) with a specific set of flags. We
> do the following three measurements:
>
> - TLS 1.2
> - TLS 1.3 draft-18
> - TLS 1.3 draft-18 with (approximately) PR#1092 ("7e02")
>
> We take five trials for each measurement, randomly shuffling the
> measurement order and then repeating the shuffled pattern five
> times. Each trial is done with a different connection and we declare
> "success" when any of the five trials succeeds.
>
>
> RESULTS
> This experiment was run on a 2% sample of the Firefox Beta population
> who have locale set to en-US, which we selected because of very
> high GMail blocking rates in some locales, which is a potential
> confounding factor. The experimen started 11/27 and has been running
> through today.
>
> This gave us an initial population of 161578, of whom 160809 (99.5%
> completed the experiment and reported results). This produced the
> following results:
>
>  Success  Failure  Fail Rate
> 
>
> TLS 1.2   158260 2549  .0158
> TLS 1.3-18158194 4743  .0291
>

Oops. This first number should be 156066. This is what happens when you cut
and paste from your notebook.

-Ekr


TLS 1.3-Experiment158194 2615  .0163
>
> For the statistics minded, the difference between -18 and 1.2 is
> significant at p < .001 and the 95% confidence interval of the failure
> rate difference is .0122-.0143 (using R's prop.test). There is no
> significant difference between 1.2 and 1.3-experiment (p = .36).
>
> We've got a -22 experiment in flight now, but it will only be on
> Nightly, so this is probably the strongest data we will have for
> a while.
>
> -Ekr
>
>
> ADDITIONAL DETAILS
> The relevant NSS version: https://dxr.mozilla.org/
> mozilla-beta/source/security/nss/lib/ssl
> Experimental code: https://github.com/mozilla/one-off-system-add-ons/tree/
> master/addons/tls13-middlebox-ghack
> iPython Notebook with analysis: https://gist.github.com/ekr/
> 598208b5399faf303453b10cb11647bf
>
>
>
>
>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Preliminary data on Firefox TLS 1.3 Middlebox experiment

[Eric Rescorla]

Hi folks,

I now have some preliminary numbers to share with the group based on
our Firefox experiments. The executive summary is that our data
confirms Google's results. More detail below.


EXPERIMENTAL DESIGN
This is a forced experiment in which each client tries all the
variants. The experiment is deployed via a system add-on (a remotely
deployable, centrally managed piece of JavaScript code), and then
takes measurements by trying to do an XHR to a given URL
(https://mail.google.com/robots.txt) with a specific set of flags. We
do the following three measurements:

- TLS 1.2
- TLS 1.3 draft-18
- TLS 1.3 draft-18 with (approximately) PR#1092 ("7e02")

We take five trials for each measurement, randomly shuffling the
measurement order and then repeating the shuffled pattern five
times. Each trial is done with a different connection and we declare
"success" when any of the five trials succeeds.


RESULTS
This experiment was run on a 2% sample of the Firefox Beta population
who have locale set to en-US, which we selected because of very
high GMail blocking rates in some locales, which is a potential
confounding factor. The experimen started 11/27 and has been running
through today.

This gave us an initial population of 161578, of whom 160809 (99.5%
completed the experiment and reported results). This produced the
following results:

 Success  Failure  Fail Rate

TLS 1.2   158260 2549  .0158
TLS 1.3-18158194 4743  .0291
TLS 1.3-Experiment158194 2615  .0163

For the statistics minded, the difference between -18 and 1.2 is
significant at p < .001 and the 95% confidence interval of the failure
rate difference is .0122-.0143 (using R's prop.test). There is no
significant difference between 1.2 and 1.3-experiment (p = .36).

We've got a -22 experiment in flight now, but it will only be on
Nightly, so this is probably the strongest data we will have for
a while.

-Ekr


ADDITIONAL DETAILS
The relevant NSS version:
https://dxr.mozilla.org/mozilla-beta/source/security/nss/lib/ssl
Experimental code:
https://github.com/mozilla/one-off-system-add-ons/tree/master/addons/tls13-middlebox-ghack
iPython Notebook with analysis:
https://gist.github.com/ekr/598208b5399faf303453b10cb11647bf
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Closing on PSS. PR#1114

[Nikos Mavrogiannopoulos]

On Mon, 2017-12-04 at 17:24 -0800, Eric Rescorla wrote:
> Hi folks,
> 
> I've put together a PR that attemps to address the PSS issue.
> 
> See:
> https://github.com/tlswg/tls13-spec/pull/1114
> 
> 
> Because there are platforms which don't have any support for PSS in
> the cert validator, at all, it seems like we MUST be able to express
> the following:
> 
> 1. I accept PSS in CV, but nowhere in certificates, and the SPKI
>MUST be of type rsaEncryption (because this is what Chrome
>can do on some platforms).
> 
> Going forward, we want to be able to express:
> 
> 2. I accept PSS in CV *and* everywhere in the certificate chain
>(otherwise PSS certificates are dead)
> 
> 3. I accept EdDSA in CV but not for signing certificates
>(note that this is subtly different from the PSS case because
>you would need an EdDSA SPKI)
> 
> 4. I accept EdDSA in CV and everywhere in the cert chain

I do not see why specific platform considerations should lead such a
major protocol change, at the cost of the platforms which can
accomodate the requirements. I believe that such major moves for
compatibility for specific platforms should be explicitly expressed in
the WG charter.

regards,
Nikos

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls