Subject: [TLS] Rethink TLS 1.3

From: Watson Ladd <[email-masked]>
Date: Fri, 21 Nov 2014 16:57:53 -0800

Was the TLS 1.3 draft written by a cryptographer? No.
Has it been reviewed by cryptographers? Unclear.
Are the mechanisms secure? Unknown.
Is it easy to analyze TLS 1.2? No.
Was TLS 1.2 secure? No.
Has TLS 1.3 fixed flaws in TLS 1.2? Some: session_hash remains
unincluded, but the record layer is finally fixed.
How long will it take to analyze TLS 1.3? If past experience is any
guide, a decade.

Can we fix problems in deployed protocols? No.
Will TLS 1.3 be deployed? Yes.

Putting this together, it seems clear that substantially more
attention needs to be paid to TLS 1.3 before we deploy it. A delay is
inevitable. Even if we decide not to proceed with OPTLS, we need to
make sure that there is a substantial degree of analysis of the
protocol before, not after, it is deployed, and that it is designed to
help, not hinder, analysis.

The current draft is not in a state where it describes a protocol that
we can analyze or implement. The sooner it gets to that state, the
sooner we can start seriously finding problems or showing there are
none. But we shouldn't expect that this process will be overnight:
it's much faster to start with a good protocol and serialize each of
the messages, instead of starting with mystery, figuring out what it
actually does, and trying to show the result is correct (and
discovering it isn't).

Sincerely,
Watson Ladd

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 21 Nov 2014 17:10:50 -0800

> unincluded, but the record layer is finally fixed.

We have a pull request up for session hash up at:

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

As I said in Honolulu, I've been planning to incorporate this next week.
It would be great if you could take a look and send comments.

> we can analyze or implement.

If there are specific things in the draft that you don't believe can
be implemented (and that aren't otherwise called out in TODOs or
Github issues) I would greatly appreciate it if you would let me
know either on list or by filing issues.

Best,
-Ekr

---

From: Henrick Hellström <[email-masked]>
Date: Sat, 22 Nov 2014 12:31:54 +0100

> unincluded, but the record layer is finally fixed.

I think such discussions would benefit from the basic premise that 
"secure" is a relative notion. It is completely pointless to ask if a 
protocol is secure or not secure, unless you first present an exhaustive 
list of security claims. That is, you can't ask if TLS 1.3 is secure or 
not, without first describing what security is to be expected from 
different scenarios.

In a sense, *every* protocol has the potential of becoming broken, 
unless it is unambiguously defined what is proper and improper usage of 
the protocol.

---

From: Watson Ladd <[email-masked]>
Date: Sat, 22 Nov 2014 14:15:30 -0800

On Sat, Nov 22, 2014 at 3:31 AM, Henrick Hellström <[email-masked]> wrote:
> I think such discussions would benefit from the basic premise that "secure"
> is a relative notion. It is completely pointless to ask if a protocol is
> secure or not secure, unless you first present an exhaustive list of
> security claims. That is, you can't ask if TLS 1.3 is secure or not, without
> first describing what security is to be expected from different scenarios.

It's clear what the security claims of TLS are be: a TLS connection
between two parties ensures that data sent between them isn't
intercepted or manipulated, and that they are who they claim to be.
This is a fairly standard notion, clearly present in research by the
late 80's, and intuitively sensible.

Of course, past versions of TLS haven't provided it.

>
> In a sense, *every* protocol has the potential of becoming broken, unless it
> is unambiguously defined what is proper and improper usage of the protocol.
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Henrick Hellström <[email-masked]>
Date: Sun, 23 Nov 2014 01:33:56 +0100

> Of course, past versions of TLS haven't provided it.

OK, but in such case, the problem with BEAST would be the browser 
implementation dependent violation of same-origin policy constraints, 
and not part where the CBC state is predicted. Your requirements imply a 
strict same-origin policy. If such a policy is violated, the problem is 
that SSL/TLS is used in a scenario that transcends its security claims, 
and not that the protocol is flawed.

---

From: Hanno Böck <[email-masked]>
Date: Sun, 23 Nov 2014 01:46:20 +0100

On Sat, 22 Nov 2014 14:15:30 -0800

> intercepted or manipulated, and that they are who they claim to be.

I think it's really a bit more tricky than that.

Adding to these one should probably add some confidentiality claims.
However what are the confidentiality claims of TLS? I don't really know.

If I grab my mail through imap or pop3 I can probably assume that my
password and the content of my comm is safe. However if I surf to
https blog X then probably the pure size of my connection packets will
reveal which article on X I'm reading right now.
The CRIME attack has revealed how powerful sidechannels can be.

So what exactly are the confidentiality claims of TLS?

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: [email-masked]
GPG: BBB51E42

---

From: Henrick Hellström <[email-masked]>
Date: Sun, 23 Nov 2014 02:21:27 +0100

> However what are the confidentiality claims of TLS? I don't really know.

IND-CCA2 would cover a lot, in terms of both confidentiality and 
integrity, even under partial chosen plain text or chosen cipher text.

---

From: Ralph Holz <[email-masked]>
Date: Sun, 23 Nov 2014 14:27:25 +0100

I'd disagree with the notion of "it is clear what TLS supports" - there is
no threat model describing the strength of an attacker (and there never has
been). It's not even clear what TLS means by "authentication".

As a possible step forward, we could say TLS supports authentication as
Lowe's injective agreement - a fairly strong definition yet one matching
intuitive expectation.

On 22 November 2014 at 23:15, Watson Ladd <[email-masked]> wrote:

> "secure"
> unless it

---

From: Jeffrey Walton <[email-masked]>
Date: Sun, 23 Nov 2014 16:40:32 -0500

> been). It's not even clear what TLS means by "authentication".
+1.

The charter could be a bit more clear about the security goals and
objectives. The current charter is more like a TODO or task list. The
task list is good, but the overall goals and objectives would be even
better.

Watson's statement about "interception free connection (sic)" caught
my eye. That's never been a goal (cf.,
http://datatracker.ietf.org/wg/tls/history/).

In fact, the IETF seem to accommodate interception in its standards,
which makes me wonder if its an unwritten agenda. For example, Public
Key Pinning opaquely accommodates interception by allowing attackers
to break pinsets (cf. Section 2.7 of
https://tools.ietf.org/html/draft-ietf-websec-key-pinning-21). And the
ability to surreptitiously break a pinset is not listed in security
considerations.

Interception support is so pervasive at times I'm wondering when the
PKIX WG is going to allocate INTERCEPTION as a certificate Key Usage.

---

From: Nico Williams <[email-masked]>
Date: Mon, 24 Nov 2014 04:17:46 -0600

> late 80's, and intuitively sensible.

It's the standard Internet threat model.  Aside from needing to be
updated for massive adversay capabilities, the standard Internet threat
model has held up well.  What hasn't held up is TLS:

> > unless it is unambiguously defined what is proper and improper usage
> > of the protocol.

We don't have a crystal ball.  All we have is fairly decent (but almost
certainly incomplete) public understanding of cryptography, and a
fairly decent idea of today's applications' needs.  We can imagine the
near future and plan accordingly, but further out we run into trouble.

I don't think we necessarily need, e.g., an explicit statement that
resistance to BEAST/CRIME style attacks is required: the standard
Internet threat model implies it.  Though it doesn't hurt to list all of
TLS's (and other protocols') vulnerabilities, of course...  It also
helps to design application protocols where BEAST/CRIME type attacks are
of little use.  I.e., we need better session continuation for HTTP than
plain cookies.  But we can't make that happen from the TLS layer, and we
must act accordingly (besides, improving HTTP session continuation has
proven to be a very difficult task).

Nico
--

---

From: Henrick Hellström <[email-masked]>
Date: Mon, 24 Nov 2014 11:30:58 +0100

On 2014-11-24 11:17, Nico Williams wrote:
> Internet threat model implies it.

Actually, no, it doesn't. The Internet threat model is based on the 
premise that both ends are uncompromised. If the client is allowing 
third party javascript to connect to arbitrary HTTPS servers, 
impersonating the client that runs the script, that client is compromised.

---

From: Nico Williams <[email-masked]>
Date: Mon, 24 Nov 2014 04:37:48 -0600

> been). It's not even clear what TLS means by "authentication".

This is true, and it is partly why we need algorithm agility: to
trade-off performance/cost for security in a context-sensitive manner.

Network security is an extension of physical security (if your hardware
or the software it runs aren't secure...).  If we assume physical
security (a big assumption) then we can get perfect security at very
high cost: e.g., every communicating pair of nodes meets physically to
securely exchange one time pads.  But we know that's too costly (it
doesn't scale, for one), so out the window goes perfection.  Everything
we're doing (DNSSEC, DPRIV, CT, ...) is just an exercise in
asymptotically approaching perfection.

> Lowe's injective agreement - a fairly strong definition yet one matching

That's implied in the Internet threat model, really.  We should make
some things more explicit, of course (e.g., we need liveness).  Of
course, in some cases we are willing to trade some features off (e.g.,
certificate status freshness tolerance vs. performance, or 0-RTT early
data transmission).

See above about trade-offs.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 24 Nov 2014 04:42:29 -0600

> impersonating the client that runs the script, that client is

The Internet threat model always will have to assume local security.

We're designing TLS.  We are not really in a prosition to dictate to
applications that they must not use cookies (though we can and must
state clearly what applications can expect from TLS), especially not
since we can (and must) make TLS 1.3 resistant to BEAST/CRIME style
attacks (we shouldn't make apps change unnecessarily).  This is NOT a
defense of the web security model, BTW, please don't mistake it as such.

Nico
--

---

From: Henrick Hellström <[email-masked]>
Date: Mon, 24 Nov 2014 11:53:17 +0100

> defense of the web security model, BTW, please don't mistake it as such.

Yes, but the point I am trying to make, is that if the implied goal is 
to make TLS resilient even against BEAST/CRIME style attacks, the threat 
model should be defined accordingly. It makes little sense to ask for 
cryptographic review of the protocol, if it is inherently unclear 
exactly what kind of threats the protocol is designed to withstand.

---

From: Nico Williams <[email-masked]>
Date: Mon, 24 Nov 2014 04:59:50 -0600

On Mon, Nov 24, 2014 at 11:53:17AM +0100, Henrick Hellström wrote:
> Yes, but the point I am trying to make, is that if the implied goal
> is to make TLS resilient even against BEAST/CRIME style attacks, the
> threat model should be defined accordingly. It makes little sense to
> ask for cryptographic review of the protocol, if it is inherently
> unclear exactly what kind of threats the protocol is designed to
> withstand.

BEAST/CRIME are dramatic demonstrations of the capabilities of attackers
in the Internet threat model.

---

From: Nico Williams <[email-masked]>
Date: Mon, 24 Nov 2014 05:15:53 -0600

Or, to put it differently, we need to state an Internet threat model
succintly.  The thing that has been missing from it is massive
capabilities on the part of some attackers.

If we have to publish a new standard Internet threat model, then we
should do so.

Nico
--

---

From: Florian Weimer <[email-masked]>
Date: Mon, 24 Nov 2014 13:06:47 +0100

> in the Internet threat model.

I really doubt that when people talked about the Internet threat model 
ten, fifteen years ago, they had adaptive chosen plaintext attacks in 
mind.  For example, they are not discussed in 
<http://tools.ietf.org/html/draft-rescorla-sec-cons-05> (as far as I can 
tell).  If such attacks are covered by the Internet threat model today, 
the model has evolved considerably.

-- 
Florian Weimer / Red Hat Product Security

---

From: [email-masked] (Martin Rex)
Date: Mon, 24 Nov 2014 17:56:01 +0100 (CET)

Nico Williams wrote:
> Henrick Hellström wrote:

Nope.  BEAST, CRIME and Poodle are pretty boring demonstrations of the
ridiculous insecurity of WebBrowsers in their default configuration.

As I've previously mentioned, TLSv1.2 has an explicit product warning
label against such Browser fallacies, and explicitly rules out BEAST,
CRIME and Poodle from the attack model against which TLSv1.2 and
all prior TLS and SSL protocol versions provide protection.

The vulnerability of Web Browsers that attacks like BEAST, CRIME and Poodle
exploit is called "Cross-Site-Request-Forgery" (CSRF) vulnerability, e.g.:

   https://www.isecpartners.com/media/11961/csrf_paper.pdf

and as long as a Browser keeps providing authentication facilities
for requests supplied by attackers, the vulnerability is wide open,
independent of the TLS protocol version that is used (SSLv3, TLSv1.0,
TLSv1.1, TLSv1.2 or TLSv1.3).  Often, browsers will voluntarily supply
attackers access to CSRF for non-disclosing authentication schemes,
including TLS client certificate authentication.  So while current
disclosing authentication schemes make the problems worse, replacing
disclosing authentation schemes would only make boring demonstrations
like BEAST and Poodle less likely, but would not address and fix the
real problem (CSRF) at all.

For many programmatic clients and servers, attacks like BEAST and Poodle
are completely irrelevant, because the vast majority of these will neither
execute attacker-supplied active content, nor will they provide
Cross-Site-Request-Forgery facilities to attackers for free.

If there is anything wrong, then it is the current (lack of)
"Web Security Model" as it exists in common Web Browsers and as
it exists on a growing number of Web Servers.

-Martin

---

From: Nico Williams <[email-masked]>
Date: Mon, 24 Nov 2014 11:00:05 -0600

On Mon, Nov 24, 2014 at 01:06:47PM +0100, Florian Weimer wrote:
> I really doubt that when people talked about the Internet threat
> model ten, fifteen years ago, they had adaptive chosen plaintext
> attacks in mind.  For example, they are not discussed in
> <http://tools.ietf.org/html/draft-rescorla-sec-cons-05> (as far as I
> can tell).  If such attacks are covered by the Internet threat model
> today, the model has evolved considerably.

They are active attacks by an attacker with full control of the network
between the end-points under attack.  Therefore they fall squarely under
the traditional Internet threat model.  We have to take into account
even attacks that today seem difficult to mount (as this one seemed not
that long ago), but we can't predict future new active attacks.  And yet
new future active attacks will still be active attacks.

I'm not saying that the Internet threat model doesn't require updating
(it does, at least as to massive adversary capabilities).  I'm saying we
shouldn't blame TLS's shortcommings on the Internet threat model.  The
latter is very high-level, and can't cover every eventually in its small
print, but in its high-level view, adaptive chosen plaintext attacks
were covered.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 24 Nov 2014 11:02:59 -0600

> ridiculous insecurity of WebBrowsers in their default configuration.

Yes, they were that too.  And by then we knew well about adaptive
plaintext attacks.  Still, they also were demonstrations that the
network has to be assumed to be under control of the adversary, and IMO
they were dramatic at that.  If anyone still doubted the adversary's
control of the network before BEAST, no one does now.

Nico
--

---

From: [email-masked] (Martin Rex)
Date: Mon, 24 Nov 2014 18:13:20 +0100 (CET)

Nico Williams wrote:
> Martin Rex wrote:

5 years ago there was an exhausting discussion in this WG about how to
fix the TLS renegotiation issue.  The problem had been considered so huge,
that a secret group (Project Mogul) had been setup to design (and have
patches shipped) before the issue was publicly described.

BEAST and Poodle require *MORE* control over the endpoint as a prerequisite
for the attack than what a successful TLS renegotiation attack will provide.

Please stop claiming that providing so much control to an attacker
as something that is (or should be) normal, rather than considering
providing so much control to attackers as what it really is:
a huge and gaping vulnerability in Web-Browsers and in the
(lack of a) Web Security Model.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Mon, 24 Nov 2014 18:26:31 +0100 (CET)

Watson Ladd wrote:
> Henrick Hellström <[email-masked]> wrote:
>>

Actually, all versions of TLS, including SSLv3 still provide the
properties you've just described today.

Every problem that has been described so far was an (ab)use of the
orginal SSL&TLS protocols beyond its stated design goals based on
flawed assumptions what TLS should additionally provide or what
the above should be interpreted to cover as well.

-Martin

---

From: Nico Williams <[email-masked]>
Date: Mon, 24 Nov 2014 11:29:44 -0600

> patches shipped) before the issue was publicly described.

Renego, incidentally, was a feature of TLS that was originally not part
of the spec, but grew ad-hoc.  This is one of the ways in which we
failed SSL and its users: we didn't analyze the protocol as-used.

> for the attack than what a successful TLS renegotiation attack will provide.

So what?

> (lack of a) Web Security Model.

I'm claiming that we're not in a position in this WG to fix the web
security model to use something better than cookies and other bearer
tokens.  I wish we were, but we're clealy not.  There's proof of this in
the pudding.

There were several efforts in the last few years, in the WEBSEC and
HTTPauth WGs to do something about that, and those efforts failed.
HTTPbis is very active, but they are not doing something about this
either (unless that's changed recently; I don't follow HTTPbis closely).

Many things were tried, including some that were -IMO- pretty good
ideas, like origin-bound-cookies (which was good in large part because
it implied minimal or no real changes to HTTP stacks).

That means that TLS 1.3 simply MUST be resistant to various cookie
recovery attacks.  Those attacks have to be active attacks (therefore
foreseen by the Internet threat model) of the adaptive chosen plaintext
or similar varieties.  Fortunately we know how to beat them, therefore
we don't have to go fix the web security model *even though* we all
would like to also do that anyways.

BTW, I'd like to be wrong about this.  I'd like us to get so incensed
over web cookies that we get that part of the web security model fixed,
full stop!

Having attempted -and failed- to provide an alternative to web cookies
myself, I'm wondering how else we might fix them...  Dirk Balfanz's
latest proposal is OK with me, but I am so traumatized (in a way) by
BEAST that I'm inclined to accept just about any improvements as to web
cookies, especially ones where big players will do the work to get
started on deployment.

Nico
--

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 24 Nov 2014 12:32:17 -0500

> Every problem that has been described so far was an (ab)use of the orginal
> SSL&TLS protocols beyond its stated design goals based on flawed
> assumptions what TLS should additionally provide or what the above should
> be interpreted to cover as well.

Are you advocating that saying "you're doing it wrong" is a more correct approach rather than trying to address the problems at the TLS definition, usage model, and protocol?

	/R$

---

From: Watson Ladd <[email-masked]>
Date: Mon, 24 Nov 2014 09:35:20 -0800

> ridiculous insecurity of WebBrowsers in their default configuration.

So it's possible to get my Paypal login cookie if I browse to a
malicious site on a fully patched browser? Because that's what BEAST
enabled. Are you saying it's fine that SSL v3.0 leaks one byte per
connection? Because that's POODLE. All of this was known in 2004, and
not fixed in TLS 1.2: no action was taken on publicising the
vulnerabilities, and in the case of some of the CBC mode issues,
vulnerable options were left in. If the web browser is inherently
insecure because it runs javascript, where's the exploit?

> all prior TLS and SSL protocol versions provide protection.

If TLS provided a secure channel as defined in
https://eprint.iacr.org/2002/059, then the browser wouldn't have a
problem. Workarounds around the lack of an easily provided property
are never a good idea, unless you know exactly what the problems are.
Why are you so dead set against making TLS useful for browsers?
Providing the right properties isn't that hard: the correct thing to
do looks very similar to the wrong thing, except it's correct.

What are the exact security claims of SSLv3.0? Or TLSv1.0?

>    https://www.isecpartners.com/media/11961/csrf_paper.pdf

Just because you don't like the Web Security Model doesn't mean it
doesn't exist. In fact, if you read the link you posted you would see
very simple solutions to the CSRF problem, that work unless the
"secure channel" isn't.  By contrast, a web application that uses
cookies for authentication, and is reachable over TLS 1.0 with an
unpatched browser or RC4, is completely vulnerable, and can do nothing
to solve the problem.

Don't believe there is a difference? Go extract an authentication
cookie from a CSRF vulnerable endpoint. You can easily hit the
endpoint and trigger actions, but you won't get the cookie, and so
can't attack other endpoints. CSRF is a confused-deputy issue: a
capability based model would solve it. But we can't end CSRF without
making it impossible to do things like isolate user accounts from
content as protection against XSS, or federate authentication.
Capability

This isn't even about browsers: TLS based VPN solutions also have to
worry about BEAST. Something as simple as programmatic
username-password authentication can be broken if the client
automatically retries on failure. POODLE leaks one byte after a
certain number of connections are broken: are you sure your code never
retries on failure?

We could fix all of this by providing an actually secure protocol.
What's the disadvantage?

Sincerely,
Watson Ladd

---

From: Brian Smith <[email-masked]>
Date: Mon, 24 Nov 2014 11:27:12 -0800

> patches shipped) before the issue was publicly described.

In terms of deployment of the solution, that approach wasn't
successful, as the secure renegotiation extension is far from
ubiquitous. The secret group designed a solution to solve the
renegotiation flaw but not the quite similar Triple Handshake flaw. It
would be interesting to know if somebody had proposed a (rejected)
solution for the renegotiation flaw that would have also fixed the
Triple Handshake flaw. In particular, we should recognize that the
"conservative" approach of making minimal changes to address
individual issues has negative consequences. Further, the
renegotiation flaw, BEAST, CRIME, Triple Handshake, etc. all should be
seen as evidence that the development model for TLS should shift to
one that is likely to preempt unknown attacks, instead of one that
reacts to attacks.

> (lack of a) Web Security Model.

Attackers having that level of control is normal for people who build
software for the web, which is a very large group of people in the TLS
community. Ultimately, this means that adaptive chosen plaintext
attacks and other negative consequences of the web security model are
well within scope.

Cheers,
Brian

---

From: Nico Williams <[email-masked]>
Date: Mon, 24 Nov 2014 13:58:42 -0600

On Mon, Nov 24, 2014 at 11:27:12AM -0800, Brian Smith wrote:
>                 [...]. In particular, we should recognize that the

Yes, and the session hash I-D takes that approach.

> one that is likely to preempt unknown attacks, instead of one that

Well, yes, but I think we need to subject TLS 1.3 to the sort of
security analysis that is generally done for cryptographic algorithm
contests.

And the I-D and RFC really needs to include a security analysis where
conceivable attacks are described, with text explaining why the attack
does not work on TLS 1.3.  Appendix F is a bit light-weight at this
point.

We can easily provide this for all attacks that have worked in the past
against TLS and similar protocols.  Finding new attacks is the fun
(difficult) part.

> attacks and other negative consequences of the web security model are

And should be.  Since otherwise the applicability of TLS would be quite
constrained, and it'd be quite difficult to ensure that all uses of TLS
are within those constraints.

To make TLS 1.3 useful it must be secure relative to adaptive chosen
plaintext attacks, and anyways, we can't fix the web security model at
this layer.

Nico
--

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 24 Nov 2014 15:02:00 -0500

> ability to surreptitiously break a pinset is not listed in security

https://tools.ietf.org/html/draft-ietf-websec-key-pinning-21#section-2.7

reads:

2.7.  Interactions With Preloaded Pin Lists

   UAs MAY choose to implement additional sources of pinning
   information, such as through built-in lists of pinning information.
   Such UAs should allow users to override such additional sources,
   including disabling them from consideration.

   The effective policy for a Known Pinned Host that has both built-in
   Pins and Pins from previously observed PKP header response fields is
   implementation-defined.

Can you explain how this can be used by an attacker to break a pinset?

	--dkg

---

From: Yoav Nir <[email-masked]>
Date: Mon, 24 Nov 2014 22:41:44 +0200

> On Nov 24, 2014, at 10:02 PM, Daniel Kahn Gillmor <[email-masked]> wrote:
> 

I think Jeffrey meant section 2.6:

                                         It is acceptable to allow Pin
   Validation to be disabled for some Hosts according to local policy.
   For example, a UA may disable Pin Validation for Pinned Hosts whose
   validated certificate chain terminates at a user-defined trust
   anchor, rather than a trust anchor built-in to the UA (or underlying
   platform).

This is not some unwritten agenda of the IETF. This section was discussed extensively. Browser vendors (among others) felt that Key Pinning could not be deployed without the sentence above. The working group did consider adding an optional “strict” directive that would prohibit such behavior (and make such websites unaccessible from behind an intercepting proxy), but ultimately rejected this option as vendors (not the IETF) decided they didn’t want to implement this.
 
Yoav

---

From: Hubert Kario <[email-masked]>
Date: Tue, 25 Nov 2014 15:46:46 +0100

On Monday 24 November 2014 09:35:20 Watson Ladd wrote:
> > ridiculous insecurity of WebBrowsers in their default 
configuration.https://tcms.engineering.redhat.com/case/295339/
> not fixed in TLS 1.2

are you suggesting that AEAD ciphers are vulnerable to them? based on what 
mechanism?

I mean, sure they are not mandatory or the only TLS 1.2 compatible ciphers, 
but there are there...

-- 
Regards,
Hubert Kario

---

From: Watson Ladd <[email-masked]>
Date: Tue, 25 Nov 2014 07:14:38 -0800

> I mean, sure they are not mandatory or the only TLS 1.2 compatible ciphers,

Fixed means fixed, not "you get to play choose your own ciphersuite,
where most of the options are wrong". It means aggressively removing
ciphers and protocols known to be weak. Instead of considering the job
done when secure options have been added, we should consider it done
when the insecure options have been removed.

Sincerely,
Watson Ladd

---

From: Hubert Kario <[email-masked]>
Date: Tue, 25 Nov 2014 16:25:14 +0100

> when the insecure options have been removed.

But then you have ADH and AECDH ciphers which can be used securely (and have 
their valid uses) but are insecure for the web use case.

as long as TLS will remain a general protocol, there will be "pick and choose" 
involved

and I prefer situation with one protocol that has some problems than 20 
protocols, each with its own set of idiosyncrasies
-- 
Regards,
Hubert Kario

---

From: Bodo Moeller <[email-masked]>
Date: Tue, 25 Nov 2014 17:26:41 +0100

> model has held up well.  What hasn't held up is TLS:

This is sort of true, and sort of isn't.

If you look at RFC 3552 ("The Internet environment has a fairly well
understood threat model. In general, we assume that the end-systems
engaging in a protocol exchange have not themselves been compromised.
Protecting against an attack when one of the end-systems has been
compromised extraordinarily difficult. [...] By contrast, we assume that
the attacker has nearly complete control of the communications channel over
which the end-systems communicate.") and the goals of TLS according to RFC
5246 ("Cryptographic security: TLS should be used to establish a secure
connection between two parties"), it's true that this can be read as
covering all kinds of attacks, because it is sufficiently vague. But then
if you look at the *specific* examples of attacks in RFC 3552, it becomes
quite clear that classes of attacks including BEAST weren't really
considered back then.

I don't agree with claims elsewhere in this thread that such attacks
violate the premise of RFC 3552 of end-systems being uncompromised.  If a
system is designed to tunnel externally provided data (some of which may be
provided by an attacker) through TLS, this makes it vulnerable to BEAST,
but I think it's a far fetch to call such a system "compromised" by
design.  Yes, "Cross Site Request Forgery" style attacks can be used to
exploit the security weaknesses, but if the protocols were offering secure
channels according to an appropriate definition, then the weaknesses
wouldn't be an issue (even if the attacker can use scripting languages to
partially remote-control the systems under attack).  [Also, if you believe
that POODLE *requires* this attack setting, you just lack imagination. The
*full* POODLE attack assume this setting, but if an attacker can obtain
just a single byte of your password, that's a breakage too.  Cf.
https://www.iacr.org/cryptodb/archive/2003/CRYPTO/1069/1069.pdf for
inspiration for a setting not involving any Javascript or other scripting
language.]

As we know from the cryptographic literature, however, properly formalizing
the needed security properties can be as hard as (or even harder than)
achieving them.  Everyone reading papers dealing with formal security
proofs for cryptographic schemes will, on occasion, have run into some
formally defined security notion that looks quite reasonable at first, but
on closer inspection turns out to have problems -- e.g., assumes something
that is in fact unsatisfiable, or insufficient, or even both.  The security
claims that TLS should fulfill, for example, may seem somewhat clear, but
only if you don't actually go into all the details.

Accordingly, I don't think it is meaningful to blame *either* the threat
model *or* TLS for the shortcomings.  The lack of clearness about the
security goals can reasonably be blamed on both.

Bodo

---

From: Joseph Salowey <[email-masked]>
Date: Tue, 25 Nov 2014 13:10:44 -0800

This thread is wandering a bit off topic.  TLS 1.3 is a work in progress.
If you have suggestions on how to improve it please create a Pull Request (
https://github.com/tlswg/tls13-spec) or post the specific details to the
list.  Keep in mind that the discussions on starting over with TLS 1.3 are
not in scope as the Working Group has consensus to follow the current
path.  Also, as the Working Group removes and deprecates less secure
protocol options we need to keep in mind the reality of current
deployments.  Deprecating or removing widely deployed options requires
careful consideration, since these actions may result in a protocol that is
unusable and/or not deployable.

Cheers,

Joe

---

From: Watson Ladd <[email-masked]>
Date: Tue, 25 Nov 2014 14:19:53 -0800

On Nov 25, 2014 1:10 PM, "Joseph Salowey" <[email-masked]> wrote:
>
> This thread is wandering a bit off topic.  TLS 1.3 is a work in
progress.  If you have suggestions on how to improve it please create a
Pull Request (https://github.com/tlswg/tls13-spec) or post the specific
details to the list.  Keep in mind that the discussions on starting over
with TLS 1.3 are not in scope as the Working Group has consensus to follow
the current path.  Also, as the Working Group removes and deprecates less
secure protocol options we need to keep in mind the reality of current
deployments.  Deprecating or removing widely deployed options requires
careful consideration, since these actions may result in a protocol that is
unusable and/or not deployable.

We should never have gotten ourselves into the position of having widely
deployed broken protocols.  Now that we are in that position, we need to
start depreciating post haste, and ensuring we have safe alternatives,
including timing attack resistant ciphers. The sooner we start, the sooner
we finish.

As for improvents, how about finding an existing, conservatively designed
signature based key agreement mechanism with the right properties, and
using it? The current proposal has two distinct client auth mechanisms, one
in the handshake and the other in update.

Making sure the actual proposal is in the draft, and not spread out across
pull requests would make life a lot easier for analyzing the protocol.

It would also be nice to know how each past attack is addressed, or not.
Appendix F needs to incorporate many more implementation dependent issues,
which luckily have been related mostly to now removed options.

Parsing TLS is one of the biggest issues in implementations. I can't
promise to write the tool to auto-generate the parser, but we should be
sufficiently chastised by all those who tried and failed to parse TLS
records with handwritten C to consider not doing it ourselves.

Quality implementations need to be available: currently there are very few,
possibly none, even for TLS 1.2. I understand two implementations of TLS
1.3 are in progress, but one is slow and the other built on NSS. The more
we can simplify the protocol, the better.

We should actively resist adding features unless they are well-understood.
When it comes to TLS 1.2 we need to produce a document explaining which
combinations of features and extensions are safe. There are no less then
four or five ways to deal with Triple Handshake. Implementations need to
disable application access to TLS unique unless one of those fixes is in
use.

TLS implementations tend to be part of the TCB. This means they need to be
simple to make them easy to audit.

None of the above is in the charter.  All of it is far more important for
security then 0 RTT.

Sincerely,
Watson Ladd

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 26 Nov 2014 02:46:46 -0500 (EST)

----- Original Message -----
> in the handshake and the other in update.

That does not need to be in TLS 1.3. New ciphersuites can be defined independently.

> records with handwritten C to consider not doing it ourselves.

Where does this come from? TLS is one of the easiest protocols to parse.

regards,
Nikos

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 26 Nov 2014 12:41:57 +0200

> in the handshake and the other in update.

The parts of TLS 1.3 that worry me the most are:

- Ensuring that implementations don't screw up the 2RTT case.
- Certificate authentication.

And yes, both worry me much more than key exchange.

Both are quite nasty problems, because it is difficult to capture
those in security model. And without security model, there can be no
security proof.

The certificate authentication is practicularly nasty because of the
interactions with TLS 1.2 certificate authentication (see the recent
message) and interactions with applications.

And yes, the current server authentication, the current client
authentication and the proposed client authentication via update all
have problems here.

E.g. With current scheme, trying to resume client-authenticated session
can go wrong. And the new scheme can have weird interactions with
applications if client authenticates midway.

-Ilari

---

From: Watson Ladd <[email-masked]>
Date: Wed, 26 Nov 2014 16:03:21 -0800

> That does not need to be in TLS 1.3. New ciphersuites can be defined independently.

Options add complexity, and while OPTLS had some compelling
advantages, it's likely that whatever scheme ultimately is adopted
will be good enough.

Right now TLS 1.3 makes many big changes from TLS 1.2. This increases
the minimum complexity of an implementation that has to do both.
Adding a simpler option doesn't help matters, unless a complex option
is removed. The result of this complexity is that it is harder to test
the code that runs, and harder to analyze the implementation for
correctness.

> Where does this come from? TLS is one of the easiest protocols to parse.

OpenSSL couldn't parse an echo request correctly. Many of recent CVEs
in OpenSSL have been related to corner cases in parsing. Microsoft got
bitten by a memcpy that didn't check its length. If it was easy to
parse, we wouldn't have parser bugs when parsing it. CVE-2014-3466
looks like a GnuTLS parser issue to me, and there are plenty of others
to pick from.

Who wrote the buggy code? Well, one Nikos Mavrogiannopoulos according
to git-blame. Maybe parsing TLS with handwritten C is not so easy,
after all.

Sincerely,
Watson Ladd

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 27 Nov 2014 10:04:48 +0100

On Wed, 2014-11-26 at 16:03 -0800, Watson Ladd wrote:

> OpenSSL couldn't parse an echo request correctly.

This is a TLS extension and is known to be unnecessarily complex. It
proves nothing about the TLS parsing complexity that you mention.

>  Many of recent CVEs

I believe you try to generalize based on your very limited view. Of
course there will be bugs, and I guess there will be more by that author
but there will not be any protocol that cannot be implemented
incorrectly. However, you cannot prove your point in the complexity of
TLS record parsing, by pointing to one parsing bug in the 14 years of a
project. What does it make you think this is a recurring issue?

regards,
Nikos

---

From: Watson Ladd <[email-masked]>
Date: Thu, 27 Nov 2014 15:01:13 -0800

> proves nothing about the TLS parsing complexity that you mention.

The construct of a heartbeat payload is a vector. It's simpler, not
more complex, than many structures in TLS.

> project. What does it make you think this is a recurring issue?

The fact that every single implementation I can think of has had RCE
or memory leak resulting from parsing errors, and usually quite a few?
This doesn't sound like an easy task: it seems downright difficult if
a lot of talented people can't do it. The Tor project is working on
writing parser generators that can deal with the sort of structure we
seem driven to produce in binary protocols for precisely this reason.

Contrast TLS to this http://curvecp.org/packets.html, or
https://tools.ietf.org/html/rfc2812#section-2.3.1. In the first case I
chop out a header, and the rest is a message content: because
everything is fixed width except the last field, no tricky issues. In
the second case I can use yacc.

It's probably too late now, but we need to at least not make the problem worse.

Sincerely,
Watson Ladd

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 28 Nov 2014 11:18:41 +0100

> more complex, than many structures in TLS.

Then you may not have seen many structures in TLS. The heartbeat
structure is unlike _any_ other structure in TLS. 
   struct {
      HeartbeatMessageType type;
      uint16 payload_length;
      opaque payload[HeartbeatMessage.payload_length];
      opaque padding[padding_length];
   } HeartbeatMessage;

So you have a length, and two payloads. One is padding with separate non
explicit length, defined as "padding_length = TLSPlaintext.length -
payload_length - 3", and the other is supposed to have the previously
mentioned length. That construction is unique on the TLS protocol, and
has interesting properties, such as the padding length affecting the
TLSPlaintext.length it depends on it. It is no surprise it has caused
bugs.

A simple structure according to the TLS rules is:
   struct {
      HeartbeatMessageType type;
      opaque payload<0..2^16-1>;
   } HeartbeatMessage;

With the latter you can reuse any parser already created for TLS
messages, and you have no interplay between different lengths. The
former requires a special parser. So really have you actual read, or
tried to implement the documents that you claim are simple or complex?

regards,
Nikos

---

From: "Ryan Sleevi" <[email-masked]>
Date: Fri, 28 Nov 2014 03:19:53 -0800

>  It's probably too late now, but we need to at least not make the problem

Watson,

I don't think this argument is particularly germane, fruitful, or frankly,
entirely well reasoned. Your argument that it's a protocol issue because
there are implementation issues lacks consideration that implementation
issues exist regardless of the protocol. At best, you're writing a screed
against parsers in C, and while I suspect you'll find a receptive audience
to this particular idea, the TLS WG is not the place for it.

As a simple counter-point to your reasoning, consider the many (MANY) RCE
bugs in msasn1.dll or cryptologic bugs such as the (poorly named and
technically inaccurate) BERserker bug in NSS. ASN.1 is very much a
structured representation for which one can create static representations
of that lack any form of dynamic parsing. Indeed, many early ASN.1
implementations used exactly this - parsing the ASN.1 definition and
generating static parsers that were "bug free", in as long as the parser
generator was bug free. This is the same thing Tor is doing. There are a
number of deficiencies in doing so, and implementors moved away from it,
and as a result, many bugs when processing ASN.1 were introduced. However,
this is not an intrinsic property of ASN.1, but of how implementors have
chosen to implement.

Hopefully this will be the end of the discussion of this vein on the list.
I see Nikos has already explained why the Heartbeat construct was itself
exceptional and, ostenstibly, non-idiomatic and error prone. That does
not, however, apply to the entire protocol, and one can arguably write
non-idiomatic and error-prone structures in the majority of parsers out
there, but that doesn't mean we're all doomed to invent Yet Another Parser
Language.

If anything, your argument is best reduced to a "fixed width field"
argument, which has its merits, but also lacks any form of extensibility.
While some may see that as a Good Thing, I would suggest that the majority
do not view "lack of extensibility except via protocol update" to be an
inherently valuable trait.

Cheers,
Ryan