Subject: [TLS] a proposal for TLS 1.3

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 12 Nov 2013 10:54:47 +0100

Hello,
 Having seen the current discussion for TLS 1.3, I have some proposal.
Since the changes requested are large, I'd suggest not to design TLS 1.3
in this working group. I'd suggest this working group to set the specs
for the next TLS version (and better name it 2.0), and then announce a
competition for the initial draft of the protocol. Then have the WG
review the submitted proposals in a year or two, accept a winner, and
the WG starts working on the winning draft.

I'm pretty sure there are many research groups that will be honoured
to join such a competition and their results may outperform the
results of the limited number of participants in the working group.

best regards,
Nikos

---

From: Yoav Nir <[email-masked]>
Date: Tue, 12 Nov 2013 10:05:27 +0000

Hi Nikos. This is pretty much what httpbis did for HTTP/2. Only it did not take a year or two - only two IETF cycles. 

So a competition could be announced now, with proposals presented in London, and a decision reached before Toronto.

While there are many research groups, they don't do protocol work so much. 

The real tricky thing here is not designing a "new TLS", but co-existence with SSLv3, TLS 1.0, 1.1, and 1.2 without resorting to the kind of fallback mechanism where you try with TLS 1.3 (or 2.0, or even better - 4.0) and if you get a reset, try again with TLS 1.2, and if that doesn't work, go straight to SSLv3.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Nikos Mavrogiannopoulos
Sent: Tuesday, November 12, 2013 11:55 AM
To: [email-masked]
Subject: [TLS] a proposal for TLS 1.3

Hello,
 Having seen the current discussion for TLS 1.3, I have some proposal.
Since the changes requested are large, I'd suggest not to design TLS 1.3 in this working group. I'd suggest this working group to set the specs for the next TLS version (and better name it 2.0), and then announce a competition for the initial draft of the protocol. Then have the WG review the submitted proposals in a year or two, accept a winner, and the WG starts working on the winning draft.

I'm pretty sure there are many research groups that will be honoured to join such a competition and their results may outperform the results of the limited number of participants in the working group.

best regards,
Nikos

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 12 Nov 2013 12:51:23 +0200

What Nikos proposes is reminiscent of what happened with IKEv2. I wasn't 
following closely at the time (more than 10 years ago), but:

- This did bring in people from the research community. See for example, 
http://tools.ietf.org/html/draft-ietf-ipsec-jfk-03.
- It took WAY longer than 2 IETF cycles.
- As far as I know there was never a problem statement document.

So it's not a glowing example, but it proves this can be done.

Thanks,
	Yaron

On 11/12/2013 12:05 PM, Yoav Nir wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Alex Elsayed <[email-masked]>
Date: Tue, 12 Nov 2013 03:31:37 -0800

I'd also suggest that the state of affairs is more optimistic than this 
would suggest simply due to the passage of time - look at the drastically 
increased participation between the AES competition and the SHA-3 
competition; cryptography research seems to only be getting better-
distributed.

Perhaps this could drive a boom in cryptographic protocol research the same 
way the AES and SHA-3 competitions seem to have done for their fields. 
There's certainly a better public awareness of the need for it.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 12 Nov 2013 12:37:41 +0100

The story in IKEv2 was different. There were a few guys (already active 
in the IETF for a long time) proposing designs and there wasn't really 
an outreach to the research  outside the IETF, as far as I recall.

There was some work on documenting the design decisions (which also 
explains the problem being solved and captures the requirements) but 
that did not go anywhere. Here is the document: 
http://tools.ietf.org/html/draft-ietf-ipsec-ikev2-tutorial-01

Of course it takes longer than 2 IETF when it comes to such a complex task.

Am 12.11.13 11:51, schrieb Yaron Sheffer:
>> Hi Nikos. This is pretty much what httpbis did for HTTP/2. Only it did
>> not take a year or two - only two IETF cycles.
>>
>> So a competition could be announced now, with proposals presented in
>> London, and a decision reached before Toronto.
>>
>> The real tricky thing here is not designing a "new TLS", but
>> co-existence with SSLv3, TLS 1.0, 1.1, and 1.2 without resorting to
>> the kind of fallback mechanism where you try with TLS 1.3 (or 2.0, or
>> even better - 4.0) and if you get a reset, try again with TLS 1.2, and
>> if that doesn't work, go straight to SSLv3.
>>
>> Since the changes requested are large, I'd suggest not to design TLS
>> 1.3 in this working group. I'd suggest this working group to set the
>> specs for the next TLS version (and better name it 2.0), and then
>> announce a competition for the initial draft of the protocol. Then
>> have the WG review the submitted proposals in a year or two, accept a
>> winner, and the WG starts working on the winning draft.
>>

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 12 Nov 2013 07:13:05 -0800

On Nov 12, 2013, at 3:37 AM, Hannes Tschofenig <[email-masked]> wrote:

> The story in IKEv2 was different. There were a few guys (already active in the IETF for a long time) proposing designs and there wasn't really an outreach to the research  outside the IETF, as far as I recall.

You recall incorrectly. There was definite outreach, and this caused some good review input but not different proposals. This WG could certainly use review from the crypto community.

> There was some work on documenting the design decisions (which also explains the problem being solved and captures the requirements) but that did not go anywhere. Here is the document: http://tools.ietf.org/html/draft-ietf-ipsec-ikev2-tutorial-01

Right, but for a different reason: the WG was never clear on the design decisions. Some people were insistent on "has to look like IKEv1" while others were insistent on "has to be simpler" and those two could not come to any consensus. It came down to the chairs making a decision.

> Of course it takes longer than 2 IETF when it comes to such a complex task.

IPsec is important to networks; TLS is important to applications. In the past decade, the latter has become more important in the public eye and therefore might attract a larger contingent of hopefully-useful input.

--Paul Hoffman

---

From: Watson Ladd <[email-masked]>
Date: Tue, 12 Nov 2013 08:05:10 -0800

> the WG starts working on the winning draft.
We need to begin by identifying the problems that require TLS 1.3 to be solved.
Most issues TLS 1.2 with extensions can fix AFAIK. (other than the
multiple round trips, but I'm sure
optimistic extensions can fix that one)
> results of the limited number of participants in the working group.
Actually, TLS is a very solved problem: creating a secured channel
between two participants,
one of whom has certificates to show the other. What about this isn't
solved in TLS 1.2?
We would get better bang for the buck kicking RC4 out and getting
people to upgrade to TLS 1.2
Sincerely,
Watson

-- 
"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, 12 Nov 2013 09:52:15 -0800

On Tue, Nov 12, 2013 at 1:54 AM, Nikos Mavrogiannopoulos
<[email-masked]> wrote:
> competition for the initial draft of the protocol.

Agree with Nikos.

There's a lot of interrelated technical issues, and some different
strategies that could be taken.

Having the WG make all these decisions seems likely to produce a
disjointed, frankenstein protocol.  It would be better to have a few
groups producing coherent proposals.

There are proposals already floating around (QUIC, MinimaLT, EKR's),
and we've seen increasing academic interest here (Kenny Paterson,
others), so it seems likely we could get some good designs and
comparative analysis.

Trevor