Subject: [TLS] TLS Charter Revision

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 2 Dec 2013 19:23:50 +0000

Hi Folks,

Sean, Eric and I have been put together a revised TLS working group charter to cover the TLS 1.3 work.   Please review the following charter and send any comments to the TLS list by December 16, 2013.

Thanks,

Joe
[For the Chairs]

The TLS (Transport Layer Security) working group was
established in 1996 to standardize a 'transport layer'
security protocol.  The basis for the work was SSL
(Secure Socket Layer) v3.0.  The TLS working group has
completed a series of specifications that describe the
TLS protocol v1.0, v1.1, and v1.2 and DTLS
(Datagram TLS) v1.2 as well as extensions to the
protocols and ciphersuites.

The primary purpose of the working group is to develop
(D)TLS v1.3.  Some of the main design goals are as follows,
in no particular order:

o Develop a mode that encrypts as much of the handshake as
is possible to reduce the amount of observable data to
both passive and active attackers.

o Develop modes to reduce handshake latency, which primarily
support HTTP-based applications, aiming for one roundtrip
for a full handshake and one zero roundtrip for repeated
handshakes.

o Reevaluate record payload protection cryptographic
 mechanisms and algorithms to address known weaknesses
 in RC4 and the CBC block cipher modes.

o Reevaluate handshake contents, e.g.,: Is time needed in
client hello?  Should signature in server key exchange
cover entire handshake?  Are bigger randoms required?
Should there be distinct cipher list for each version?

A secondary purpose is to maintain previous version of
the (D)TLS protocols as well as to specifying the Use of
(D)TLS, recommendations for use of (D)TLS, extensions to
(D)TLS, and cipher suites.  However, changes or additions
to older versions of (D)TLS whether via extensions or
ciphersuites are discouraged and require significant
justification to be taken on as work items.

With these objectives in mind, the TLS WG will also place a priority
in minimizing gratuitous changes to TLS.

Milestone/Dates:

201311 - Out-of-Band Public Key Validation for TLS to IESG
201401 - Secure Password Ciphersuites for TLS to IESG
201404 - TLS ALPN (Application Layer Protocol Negotiation)
       Extension to IESG
201411 - (D)TLS 1.3 to IESG

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 02 Dec 2013 14:40:09 -0500

minor nit-picks:

> for a full handshake and one zero roundtrip for repeated

what does "one zero roundtrip" mean?  should "a full handshake" be "the
first handshake" and "repeated handshakes" be "subsequent handshakes" ?

> the (D)TLS protocols as well as to specifying the Use of

this should probably be either "as well as specifying" or "as well as to
specify", and "Use" shouldn't be capitalized.

	--dkg

---

From: Watson Ladd <[email-masked]>
Date: Mon, 2 Dec 2013 19:45:22 -0800

I strenuously object to the proposed rechartering as it now stands.
First, I do not have confidence in this WG and its chair to
deliver a secure protocol to the IESG. They did not the previous 3
times, and I do not want to give them a 4th shot without some
guarantee
of the quality. Secondly, the proposed recharting has made certain
technical decisions related to the protocol without due discussion, in
particular
the list of goals implies that we keep the stupidity of multiple
ciphersuites and extensions galore around. Thirdly, the experience of
TLS 1.2 teaches us that no matter how compatible a protocol upgrade
is, it will not happen, and so one need not keep compatibility.
Fourthly, item 3 is not strong enough: AtE needs to die a fiery death
and nothing short of killing RC4 will address its shortcomings.

I propose the following charter instead.
"To create a protocol establishing a secure encrypted and
authenticated channel in the standard model between parties A and B,
supporting the following authentication methods:
-One-way authentication with the PKI
-Two-way authentication with the PKI
-Two-way authentication with a shared low-entropy secret
-One side authenticated with the PKI, and the other with a shared
low-entropy secret.
Said protocol will function over UDP and TCP with a minimum of
handshakes, complexity, and options, and will have a formal security
proof."
Sincerely,
Watson Ladd

---

From: Marsh Ray <[email-masked]>
Date: Wed, 4 Dec 2013 03:13:57 +0000

From: TLS [mailto:[email-masked]] On Behalf Of Watson Ladd

> First, I do not have confidence in this WG and its chair to deliver a secure protocol to the
> IESG. They did not the previous 3 times, and I do not want to give them a 4th shot
> without some guarantee of the quality.

> Secondly, the proposed recharting has made certain technical decisions related to
> the protocol without due discussion, in particular the list of goals implies that we
> keep the stupidity of multiple ciphersuites and extensions galore around.

SSL/TLS has had some issues over the last 20 years, but I can't think of any serious ones *caused* by the multiplicity of ciphersuites and extensions. To the contrary, the version negotiation, cipher suite, and extension mechanisms have been invaluable in rapidly deploying fixes when cracks have appeared in the other parts.

> Thirdly, the experience of TLS 1.2 teaches us that no matter how compatible a
> protocol upgrade is, it will not happen, and so one need not keep compatibility.

That must be why SSLv2 has 99% server market share and TLS has only 20%. Oh wait, I got that backwards. https://www.trustworthyinternet.org/ssl-pulse/
So uhh..."baloney".

Looks like the latest version of Centos and its upstream "major North American Linux vendor"
Made this change "OpenSSL and NSS now support TLS 1.1 and 1.2."
http://wiki.centos.org/Manuals/ReleaseNotes/CentOS6.5

Microsoft clients and servers have supported it for years now but it has been off by default.

Oh looky... 83.9% of sites have even added support for the RFC 5746 Renegotiation Indication security patch in just the last 3-4 years, whereas only 74.3% of servers have disabled SSLv2. I dunno, could have something to do with the fact that the extension mechanism allows adoption without breaking existing clients and servers.

> Fourthly, item 3 is not strong enough: AtE needs to die a fiery death and nothing short of killing RC4 will address its shortcomings.

I agree that AtE was a mistake and needs to go, but what would killing RC4 do to "address its shortcomings"?

> "To create a protocol establishing a secure encrypted and authenticated channel in the
> standard model between parties A and B, supporting the following authentication methods:
> -Two-way authentication with a shared low-entropy secret -One side authenticated with the PKI, and the other with a shared low-entropy secret.
> Said protocol will function over UDP and TCP with a minimum of handshakes, complexity, and options, and will have a formal security proof."

Gee you make it sound so easy.

I think we should also consider forward secrecy to be a required and essential security property these days.

Also, how about some security for anonymous connections too? And resistance to traffic analysis and fingerprinting. And privacy of the endpoints' identities. And not becoming a browser evercookie. And not enabling any new forms of server DoS attacks. And so on.

- Marsh

---

From: Watson Ladd <[email-masked]>
Date: Tue, 3 Dec 2013 20:08:11 -0800

> SSL/TLS has had some issues over the last 20 years, but I can't think of any serious ones *caused* by the multiplicity of ciphersuites and extensions. To the contrary, the version negotiation, ciph…
Other than letting people shoot themselves in the foot by making
insecure choices and limiting the number of compatible
implementations, as well as confounding security analysis?
> That must be why SSLv2 has 99% server market share and TLS has only 20%. Oh wait, I got that backwards. https://www.trustworthyinternet.org/ssl-pulse/
Look at TLS 1.2 vs TLS 1.0. Active attacks exist that are only fixed
by TLS 1.2. That's also server side, not client side, so it's only
part of the full picture. And it's been 14 years since TLS 1.0 came
out. Major US financial institutions, responsible for trillions of
assets, deploy TLS in configurations that are insecure.
> Microsoft clients and servers have supported it for years now but it has been off by default.
A functioning upgrade path protects the upgraded. That it's been off
by default shows just how bad the upgrade picture is.
> Oh looky... 83.9% of sites have even added support for the RFC 5746 Renegotiation Indication security patch in just the last 3-4 years, whereas only 74.3% of servers have disabled SSLv2. I dunno, c…
If your browser is negotiating a broken protocol it is broken. Keeping
you using it is doing no one any favours.
> I agree that AtE was a mistake and needs to go, but what would killing RC4 do to "address its shortcomings"?
That "and" was not subordinating/the "its" goes with RC4 not AtE.
> Gee you make it sound so easy.
What part do you think is hard? We've known how to do all of this
since basically forever in cryptography terms, except the formal proof
part, but
that's automatic now. CurveCP has all of this working except the
shared low-entropy secret part.

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

---

From: Trevor Perrin <[email-masked]>
Date: Tue, 3 Dec 2013 21:56:27 -0800

On Tue, Dec 3, 2013 at 8:08 PM, Watson Ladd <[email-masked]> wrote:
> that's automatic now. CurveCP has all of this working

It doesn't, actually.  CurveCP has some security flaws [1], no formal
proof, no PKI support, and lacks the low-round-trip properties that
are TLS 1.3 goals.

Key agreement remains a complex topic even in academia.  Trying to
balance low round-trips, computational efficiency,
handshake-data-hiding, implementation complexity,
backwards-compatibility, extensibility, IPR, etc. involves difficult
tradeoffs.

Anyways, I prefer Joseph's charter, as it identifies specific focuses
for improvement (round-trips, handshake-data-hiding), whereas yours is
quite vague ("minimum of handshakes, complexity, and options").

Trevor

[1] http://codesinchaos.wordpress.com/2012/09/09/curvecp-1/

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 04 Dec 2013 10:14:09 +0100

> both passive and active attackers.

I'd phrase that differently. I believe what we want to achieve is to
protect the identity of the participants, as well as the purpose of
connection (service), from passive (and if possible) from active
attackers. That gives a purpose to the goal (encrypting stuff is good,
but doesn't explain why we need that).

>  in RC4 and the CBC block cipher modes.

I think this contains two completely different issues. I'd split it into
* Replace RC4 with a known to be secure stream cipher
* Fix the known weaknesses in the CBC block cipher mode.

(I'm not so strong about the splitting, but given the existing work on
the topic the word Re-evaluate seems to be suggesting a further delay.
There is nothing to evaluate in the RC4 issue - it is broken, and we
already have more than one suggested solutions for the CBC issue)

Moreover this goal is not reflected in the milestones. Given the work
that is already there I'd expect to have these two points completed not
later than the beginning of 2014.

Except with the two points above, I agree with the charter revision.

regards,
Nikos

---

From: Martin Thomson <[email-masked]>
Date: Wed, 4 Dec 2013 09:21:07 -0800

> Microsoft clients and servers have supported it for years now but it has been off by default.

I probably shouldn't be the one telling you this, but IE11 offers 1.2
now.  And I think that 1.2 has been accepted by IIS since Windows
Server 2008.  :)  Just more information in support of your thesis.
The MS HTTP folks did some testing and found that of the sites they
connected to (~1 million), around 16% accepted 1.2.

(Caveat: not my numbers, just my memory, you can ask Rob Trace for details.)

---

From: Mohamad Badra <[email-masked]>
Date: Thu, 5 Dec 2013 18:26:33 +0400

On Mon, Dec 2, 2013 at 11:23 PM, Joseph Salowey (jsalowey) <
[email-masked]> wrote:

> Hi Folks,
>
> Sean, Eric and I have been put together a revised TLS working group
> charter to cover the TLS 1.3 work.   Please review the following charter
> and send any comments to the TLS list by December 16, 2013.
>
> Thanks,
>
> Joe
> [For the Chairs]
>
>
​​

Actually, I am surprised that the co-chair Eric​ ​is​ ​really​ ​supporting
the above text!

1-  As ​you are fun of​ ​doing a DHE exchange before establishing an
ordinary handshake​ to avoid passive/active attacks, why aren't you
supporting its integration to TLS1.3? (I am repeating the same argument
​the WG co-chairs ​used against adopting
draft-hajjeh-tls-identity-protection as a WG item​).​ Do you really need
this major changes to the TLS state machine? ;)

​2- ​Will your statement [1] apply when encrypting the certificate during
the "initial" TLS1.3 handshake?

​Best regards,
Badra​
​[1] https://datatracker.ietf.org/ipr/1036/​

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 10 Dec 2013 06:38:57 +0000

Updated Charter text based on the discussion so far is below.  Changes: 

1. Fixed typos 
2. Third bullet to "Update record payload protection cryptographic
mechanisms and algorithms to address known weaknesses
in the CBC block cipher modes and to replace RC4."

Thanks,

Joe

o Develop modes to reduce handshake latency, which primarily
support HTTP-based applications, aiming for one roundtrip
for a full handshake and one or zero roundtrip for repeated
handshakes.

o Update record payload protection cryptographic
mechanisms and algorithms to address known weaknesses
in the CBC block cipher modes and to replace RC4.

the (D)TLS protocols as well as to specify the use of

Milestone/Dates:

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 10 Dec 2013 10:26:13 +0200

Hi Joe,

There is never-ending discussion on this list about servers that do not 
implement version negotiation correctly, and various solutions to 
prevent, secure, or provide policy for client-side version fallback. 
Shouldn't this be part of the group's charter?

Thanks,
	Yaron

On 12/10/2013 08:38 AM, Joseph Salowey (jsalowey) wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 10 Dec 2013 08:59:23 +0000

Hi Joe

Wouid it be reasonable to add a "better privacy" goal for the tls 1.3 work? 

Ta
S

---

From: Yoav Nir <[email-masked]>
Date: Tue, 10 Dec 2013 11:24:37 +0200

Hi Stephen

I suggest "better confidentiality". "Privacy" applies to humans, not 
machines. I don't think it's appropriate for a machine-2-machine 
protocol like TLS.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 10 Dec 2013 10:14:07 +0000

> machines. I don't think it's appropriate for a machine-2-machine 

A reasonable point. However by privacy I was also trying to
include any reasonable steps that can be taken e.g. to make
traffic analysis harder, without implying that that would
be higher priority than e.g. performance though. For example
Alfredo's ideas on padding (or similar) could be built in
to the TLS1.3 application data protection and that could
be well worth while.

There could also be aspects related to how identifying
different protocol elements might be, where different design
decisions (with about the same costs) could be made if the
WG does or doesn't consider privacy.

I'd have no objection if the charter didn't use the term
privacy but it seems like a useful shorthand to save having to
try break it out into the various reasonable bits that could
be done here.

But yeah maybe it'd be better qualified e.g. to something
like "The WG will consider the privacy implications of
TLS1.3 and where possible (balancing with other requirements)
will aim to make TLS1.3 more privacy-friendly, e.g. via more
consistent application traffic padding, more considered use
of long term identifying values, etc."

To be clear: I'm not asking that TLS1.3 become Tor:-)

S.

>> Ta S
>>> 1. Fixed typos 2. Third bullet to "Update record payload
>>> protection cryptographic mechanisms and algorithms to address
>>> known weaknesses in the CBC block cipher modes and to replace
>>> RC4."
>>> 
>>> Thanks,
>>> 
>>> Joe
>>> 
>>> The TLS (Transport Layer Security) working group was established
>>> in 1996 to standardize a 'transport layer' security protocol.
>>> The basis for the work was SSL (Secure Socket Layer) v3.0.  The
>>> TLS working group has completed a series of specifications that
>>> describe the TLS protocol v1.0, v1.1, and v1.2 and DTLS (Datagram
>>> TLS) v1.2 as well as extensions to the protocols and
>>> ciphersuites.
>>> 
>>> The primary purpose of the working group is to develop (D)TLS
>>> v1.3.  Some of the main design goals are as follows, in no
>>> particular order:
>>> 
>>> o Develop a mode that encrypts as much of the handshake as is
>>> possible to reduce the amount of observable data to both passive
>>> and active attackers.
>>> 
>>> support HTTP-based applications, aiming for one roundtrip for a
>>> full handshake and one or zero roundtrip for repeated 
>>> handshakes.
>>> 
>>> o Update record payload protection cryptographic mechanisms and
>>> algorithms to address known weaknesses in the CBC block cipher
>>> modes and to replace RC4.
>>> 
>>> o Reevaluate handshake contents, e.g.,: Is time needed in client
>>> hello?  Should signature in server key exchange cover entire
>>> handshake?  Are bigger randoms required? Should there be distinct
>>> cipher list for each version?
>>> 
>>> A secondary purpose is to maintain previous version of the (D)TLS
>>> protocols as well as to specify the use of (D)TLS,
>>> recommendations for use of (D)TLS, extensions to (D)TLS, and
>>> cipher suites.  However, changes or additions to older versions
>>> of (D)TLS whether via extensions or ciphersuites are discouraged
>>> and require significant justification to be taken on as work
>>> items.
>>> 
>>> With these objectives in mind, the TLS WG will also place a
>>> priority in minimizing gratuitous changes to TLS.
>>> 
>>> Milestone/Dates:
>>> 
>>> 201311 - Out-of-Band Public Key Validation for TLS to IESG 201401
>>> - Secure Password Ciphersuites for TLS to IESG 201404 - TLS ALPN
>>> (Application Layer Protocol Negotiation) Extension to IESG 201411
>>> - (D)TLS 1.3 to IESG 
>>> _______________________________________________ TLS mailing list 
>>> [email-masked] https://www.ietf.org/mailman/listinfo/tls
>> 
>> _______________________________________________ TLS mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/tls
> 
>

---

From: Hovav Shacham <[email-masked]>
Date: Tue, 10 Dec 2013 14:57:16 -0800

On Mon, Dec 9, 2013 at 10:38 PM, Joseph Salowey (jsalowey) <
[email-masked]> wrote:

> Updated Charter text based on the discussion so far is below.

I support this proposed charter, FWIW.

-hs.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 12 Dec 2013 10:22:30 -0500

I agree with Marsh that PFS should be included.

I am concerned about the 'political' emphasis on reducing round trips. One of the arguments heard I hear against 'https everywhere' is that the extra round-trips' cause too much latency and impact customer's web experience. If we can work to reduce RTT without sacrificing security, then that's great and I would like to see "while maintaining security features" or some such added.

I would like to add a bullet that says backward compatibility with previous  versions is not a requirement. Given all that downgrade fallback issues that continually arise here, we should strongly consider if the right thing to do is just break the chain.

	/r$

--  
Principal Security Engineer
Akamai Technology
Cambridge, MA

---

From: Michael Sweet <[email-masked]>
Date: Thu, 12 Dec 2013 10:33:10 -0500

FWIW, one of the big features of HTTP/2.0 is the ability to run multiple simultaneous requests over a single connection which mitigates most of the effects of extra RTT. What's left is the initial connection setup time - important for benchmarks, perhaps, but definitely down in the noise for most web pages...

> I would like to add a bullet that says backward compatibility with previous  versions is not a requirement. Given all that downgrade fallback issues that continually arise here, we should strongly…

_______________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Patrick McManus <[email-masked]>
Date: Thu, 12 Dec 2013 10:59:41 -0500

Time to first byte is extremely important to web content - so any kind of
latency-scaled overhead is viewed as a serious cost. TLS induced latency is
one factor that currently weighs against deploying content over https:// --
That is a dynamic most on this list would like to change I am sure.

Reducing setup overhead of all types is vitally important to that
constituency. That's not just assertion - we see that reflected (sometimes
indirectly) in ongoing efforts such as false start, snap start, stapling,
session tickets, iw 10, tcp fast open, http/2, tail loss probe, and quic.

A robust discussion can be had about cost-benefits of various approaches to
RTT elimination, but the demand side of the ledger should be clear.

On Thu, Dec 12, 2013 at 10:33 AM, Michael Sweet <[email-masked]> wrote:

> FWIW, one of the big features of HTTP/2.0 is the ability to run multiple
> simultaneous requests over a single connection which mitigates most of the
> effects of extra RTT. What's left is the initial connection setup time -
> important for benchmarks, perhaps, but definitely down in the noise for
> most web pages...
>
>
> > I am concerned about the 'political' emphasis on reducing round trips.
> One of the arguments heard I hear against 'https everywhere' is that the
> extra round-trips' cause too much latency and impact customer's web
> experience. If we can work to reduce RTT without sacrificing security, then
> that's great and I would like to see "while maintaining security features"
> or some such added.
> >
> > I would like to add a bullet that says backward compatibility with
> previous  versions is not a requirement. Given all that downgrade fallback
> issues that continually arise here, we should strongly consider if the
> right thing to do is just break the chain.
> >
> >       /r$
> >
> > --

---

From: Michael Sweet <[email-masked]>
Date: Thu, 12 Dec 2013 12:17:58 -0500

Patrick,

While I agree that minimizing RTT is a laudable goal, I don't think it is a necessary goal for TLS/1.3.

Witness that browsers/servers that support Google's TLS-encrypted SPDY have already seen significant performance improvement without needing a 0 RTT version of TLS.  And as HTTP/2.0 shares some of the same design elements, we can expect to see similar improvements over TLS-encrypted HTTP/1.1 as well.

Minimizing RTT helps with initial response latency only.  And I would argue the primary factor against using TLS for everything is performance and resource usage and NOT latency.  If you can, by using SPDY or HTTP/2.0, reduce the number of connections a web browser makes to your server(s) by an order of magnitude, that will be a far greater factor in the decision making process than shaving maybe 250ms from the initial connection latency of each connection.

On Dec 12, 2013, at 10:59 AM, Patrick McManus <[email-masked]> wrote:

> Time to first byte is extremely important to web content - so any kind of latency-scaled overhead is viewed as a serious cost. TLS induced latency is one factor that currently weighs against deploying content over https:// -- That is a dynamic most on this list would like to change I am sure.
> 
> Reducing setup overhead of all types is vitally important to that constituency. That's not just assertion - we see that reflected (sometimes indirectly) in ongoing efforts such as false start, snap start, stapling, session tickets, iw 10, tcp fast open, http/2, tail loss probe, and quic.
> 
> A robust discussion can be had about cost-benefits of various approaches to RTT elimination, but the demand side of the ledger should be clear.
> 
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 13 Dec 2013 09:23:49 +0800

> I agree with Marsh that PFS should be included.

Can you elaborate more on this? TLS already supports PFS, so are you
arguing we should maintain that support or that we should strip out
all non-PFS cipher suites (see the thread on static RSA...)

> I am concerned about the 'political' emphasis on reducing round trips. One of the arguments heard I hear against 'https everywhere' is that the extra round-trips' cause too much latency and impact…

I have no problem with that. I would have thought it went without saying
but I'm more than happy to have us say it.

> I would like to add a bullet that says backward compatibility with previous  versions is not a requirement. Given all that downgrade fallback issues that continually arise here, we should strongly…

I think this is actually backwards: it's precisely having some sort of secure
backward negotiation that allows for clean deployment. The problem is
that people have screwed up those mechanisms. If we just do a clean
break there is no chance that secure version detection will work.

-Ekr

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 12 Dec 2013 21:56:58 -0500

Ø  Time to first byte is extremely important to web content

Sure,  but it's not the only thing (and I know you're not saying it is). I'm all in favor of a robust discussion of the trade-offs. After all, we generally approve of having speed limits on our roads.
--
Principal Security Engineer
Akamai Technology
Cambridge, MA

---

From: Watson Ladd <[email-masked]>
Date: Thu, 12 Dec 2013 19:38:05 -0800

On Thu, Dec 12, 2013 at 6:56 PM, Salz, Rich <[email-masked]> wrote:
> Sure,  but it’s not the only thing (and I know you’re not saying it is). I’m
> all in favor of a robust discussion of the trade-offs. After all, we
> generally approve of having speed limits on our roads.
TLS could be one round trip if we were willing to eliminate a bunch of
options. I think we should have
a discussion aimed at seeing what we can chop out to reduce the need
for negotiation.

---

From: Brian Smith <[email-masked]>
Date: Thu, 12 Dec 2013 21:15:23 -0800

On Thu, Dec 12, 2013 at 7:22 AM, Salz, Rich <[email-masked]> wrote:

> I am concerned about the 'political' emphasis on reducing round trips. One
> of the arguments heard I hear against 'https everywhere' is that the extra
> round-trips' cause too much latency and impact customer's web experience.
> If we can work to reduce RTT without sacrificing security, then that's
> great and I would like to see "while maintaining security features" or some
> such added.
>

Rich,

I think you make a very good point. I'd like to clarify, though, that at
least the 1-RTT full handshake proposals are actually not just about
increasing performance, but also about increasing security. A 1-RTT full
handshake improves performance over the case where the client does not use
the TLS False Start mechanism. A new 1-RTT full handshake will improve
security over the case when a client *does* use False Start. (It turns out
that there are more practical security considerations with False Start than
seemed to be the case at first.) Also, a new 1-RTT handshake has the
potential to improve privacy/confidentiality of information in the
handshake. Finally, the 1-RTT handshake would make it esaier to deploy TLS
because it reduces the need for distributed session caches or distributed
session ticket keys--if you're happy to pay the CPU cost of full
handshakes, but not the latency cost of 2-RTTs, then per-host sessions may
work just fine for you.

Consequently, I see the 1-RTT handshake as improving security, privacy,
performance, and ease of deployment at the very small cost of some reduced
flexibility. (But, you get that flexibility back by falling back to the
2-RTT full handshake.)

The 0-RTT handshake ideas I've seen are a little different. There, we may
have to make a security/performance tradeoff, because there are more ways
where an operational failure can make things go bad. I suspect that server
admins will have to decide whether to make this tradeoff or not, after
we've done all we can do to minimize the associated security risks in the
protocol definition. In other words, I think that we should consider
features that have reasonable security tradeoffs, but we should make those
features optional.

> right thing to do is just break the chain.

If there is a way to avoid requiring backward compatibility, that doesn't
add latency when the server only speaks current versions of TLS, then it is
something to consider. But, at least browsers need to work with existing
SSL 3.0-TLS 1.2 servers, without performance regressions, for many years to
come. That leads me to think that the ClientHello message must be backward
compatible with older versions of TLS, at least.

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 13 Dec 2013 09:06:00 -0500

> Can you elaborate more on this? TLS already supports PFS, so are you arguing we should maintain that support or that we should strip out all non-PFS cipher suites (see the thread on static RSA...)

I think we should have an explicit discussion point if PFS is a MUST or a SHOULD.

> I think this is actually backwards: it's precisely having some sort of secure backward negotiation that allows for clean deployment. The problem is that people have screwed up those mechanisms. If we just do a clean break there is no chance that secure version detection will work.

So do we think the problem will be solved this time around?  I don't know, so I guess it goes into the discussion threads.

	/r$

---

From: Marsh Ray <[email-masked]>
Date: Tue, 17 Dec 2013 03:33:45 +0000

From: TLS On Behalf Of Watson Ladd
Sent: Thursday, December 12, 2013 7:38 PM
>
> TLS could be one round trip if we were willing to eliminate a bunch
> of options. I think we should have a discussion aimed at seeing what
> we can chop out to reduce the need for negotiation.

I think most of us would agree that the ability to use forward-secret
key exchange remains a requirement.

In these discussions I am often reminded of this earlier proposal
which attempted some of these design challenges:
http://tools.ietf.org/html/draft-agl-tls-snapstart-00#section-2

- Marsh