Subject: Re: [TLS] TLS 1.3 Wish List Suggestions

From: Sajeev S <[email-masked]>
Date: Wed, 12 Mar 2014 21:51:37 +0530

Hi Eric,

Just a thought----------for this section
https://tools.ietf.org/html/draft-rescorla-tls13-new-flows-00

5.4 <https://tools.ietf.org/html/draft-rescorla-tls13-new-flows-00#section-5.4>.
 Some other questions to think about

   [TODO]

   o  Should we get rid of resumption?

Can we have the port no which can be used for Resumption in the initial
Handshake flow.

This data(port no) can be a encrypted message.

Regards,
Sajeev

On Sat, Nov 23, 2013 at 10:58 PM, Sajeev S <[email-masked]> wrote:

> Hi Eric,
>
> My self Sajeev, I have  over 7+ years of expertise in Testing SSL/TLS
> protocol and PKI.
>
> I read through the "
> https://www.ietf.org/proceedings/87/slides/slides-87-tls-5.pdf"
>
> I have one suggestion for this "TLS 1.3 Wish List"
>
> Can we add an TLS Extension field when we use TLS 1.3 as protocol version,
> which will inform the Certificate key size bits to be used in the SSL/TLS
> transaction.
>
> As we move forward in the SSL/TLS security,the certificate key size bits
> will play an important role.
>
> Proposal----------->
> 1. Client hello will have extension saying that we will use 1024/2048/4096
> public key bit size certificates
> 2. Server hello will send an extension which will decide which key size to
> be used.
>
> The above key size bit extension can be used for deciding both Server
> certificates and client certificates.
>
>  It is just an idea........need to analyse more because not only RSA/DSA
> certificates will be used.
> It also depends on which ciphersuite gets select..........if it is ECC
> based or DH based.
>
> we can also have the size for DH key.
>
> For EC based we already have curve and point extensions.
>
> Please let me know if it is feasible to add this functionality?
>
> Regards,
> Sajeev
>
>
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 12 Mar 2014 09:26:01 -0700

Sajeev,

Can you expand on this topic a bit? Are you talking about the
UDP/TCP port #? Something else?

-Ekr

On Wed, Mar 12, 2014 at 9:21 AM, Sajeev S <[email-masked]> wrote:

> 5.4 <https://tools.ietf.org/html/draft-rescorla-tls13-new-flows-00#section-5.4>.  Some other questions to think about
>
>    [TODO]
>
>> Can we add an TLS Extension field when we use TLS 1.3 as protocol
>> version, which will inform the Certificate key size bits to be used in the
>> SSL/TLS transaction.
>>
>> 1. Client hello will have extension saying that we will use
>> 1024/2048/4096 public key bit size certificates
>> 2. Server hello will send an extension which will decide which key size
>> to be used.
>>

---

From: Sajeev S <[email-masked]>
Date: Wed, 12 Mar 2014 23:04:08 +0530

The port TCP(TLS) / UDP(DTLS) for which the server listens for Resumption.

This will make the client to send the Reuse request for this particular
server on this pre-negotiated port(to be included in the initial Handshake
flow)

This will also make Reuse request binded with initial Handshake.

The port number to be used can be a new encrypted handshake message sent
after
Finished Handshake message
or
During application data transfer
and
Before sending close notify message

Server should listen on the same tcp/udp port to do a reuse request.

Just a thought...................

Regards,
Sajeev

---

From: Quynh Dang <[email-masked]>
Date: Wed, 12 Mar 2014 14:19:06 -0400

Dear all, I urged for these two features before. I think they would be good
for security reason. Regards, Quynh.
On Nov 23, 2013 3:16 PM, "Sajeev S" <[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: Nico Williams <[email-masked]>
Date: Wed, 12 Mar 2014 14:09:09 -0500

On Wed, Mar 12, 2014 at 11:21 AM, Sajeev S <[email-masked]> wrote:
> 5.4.  Some other questions to think about
>
>    [TODO]
>

Why?  But we should get rid of resumption without resumption tickets.
Resumption session caches on the server side are very hard to get
right.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 12 Mar 2014 14:22:52 -0500

> The port TCP(TLS) / UDP(DTLS) for which the server listens for Resumption.

There's no such thing as a "TLS port", therefore there can't really be
such a thing as a "port for TLS resumption".  And it'd be a terrible
idea to say that TLS resumption for {HTTP, IMAP, SMTP, SUBMIT, LDAP,
...} must happen on a different port.

Nico
--

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 12 Mar 2014 13:25:38 -0600

> Why?  But we should get rid of resumption without resumption tickets.

For all TLS-using application protocols, or mainly for HTTP?

> Resumption session caches on the server side are very hard to get

All of this is hard to get right. :-)

Peter

---

From: Nico Williams <[email-masked]>
Date: Wed, 12 Mar 2014 14:35:55 -0500

> For all TLS-using application protocols, or mainly for HTTP?

For TLS.  We're talking about TLS 1.3...

> All of this is hard to get right. :-)

Yes :(  Some things add unnecessary complexity.  And session
resumption tickets are actually a major simplification, therefore we
should jettison the old more complex variant.

Nico
--

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 12 Mar 2014 14:29:01 -0600

> should jettison the old more complex variant.

I ask because HTTP is a so-called stateless protocol, whereas in the 
XMPP world it's natural for the server to hold a lot of state about the 
client connection. Where I come from, it feels weird for the server to 
send a bunch of state down the client only to have the client present it 
again on session resumption.

Peter

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 12 Mar 2014 16:39:49 -0400

> I ask because HTTP is a so-called stateless protocol, whereas in the XMPP world it's natural for the server to hold a lot of state about the client connection. Where I come from, it feels weird for the server to send a bunch of state down the client only to have the client present it again on session resumption.

Would it feel less weird if you think of it as a distributed cluster of servers?

	/r$

--  
Principal Security Engineer
Akamai Technology
Cambridge, MA

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 12 Mar 2014 14:49:41 -0600

> Would it feel less weird if you think of it as a distributed cluster of servers?

You mean the client is one node in a server cluster? That sounds even 
weirder. :-)

Peter

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 12 Mar 2014 16:51:52 -0400

> You mean the client is one node in a server cluster? That sounds even weirder. :-)

No, the server is a pool and next time you connect you'll perhaps get a different one.

This seems to be how twitter works, for example: https://blog.twitter.com/2013/forward-secrecy-at-twitter

	/r$

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 12 Mar 2014 15:01:34 -0600

> No, the server is a pool and next time you connect you'll perhaps get a different one.

Oh yes, many XMPP server implementations are deployed that way at high 
scale.

Peter

---

From: Nico Williams <[email-masked]>
Date: Wed, 12 Mar 2014 16:42:15 -0500

On Wed, Mar 12, 2014 at 3:29 PM, Peter Saint-Andre <[email-masked]> wrote:
> I ask because HTTP is a so-called stateless protocol, whereas in the XMPP

HTTP is stateless, but apps that use HTTP don't have to be (cookies!),
and TLS doesn't have to be (sessions! connections!).

In any case, if statelessness is what you're after, then TLS session
resumption tickets is what you want, and deprecating the old form of
session resumption should be something you should really want.

To be fair clients don't have to be willing to resume sessions, and
servers don't have to offer resumption.  Of either type.  So it's
already possible for clients and servers to only implement session
resumption tickets, or not at all.  But session resumption with
session resumption tickets is a *good* thing, a great optimization
(supposing that its use is not itself revealing of important
information to passive attackers).

> world it's natural for the server to hold a lot of state about the client
> connection. Where I come from, it feels weird for the server to send a bunch
> of state down the client only to have the client present it again on session
> resumption.

I don't see anything weird about that.

Nico
--