Subject: [TLS] Fwd: New Version Notification for draft-wood-tls-ticketrequests-01.txt

From: Christopher Wood <[email-masked]>
Date: Mon, 29 Oct 2018 21:29:02 -0700

This updated version of the ticket requests draft incorporates feedback we received in Montreal. Specifically, it removes the post-handshake request and response messages in favor of a simpler mechanism by which clients indicate their desired ticket count in a CH extension. Time permitting, we’d like a few minutes to discuss the latest changes and gauge WG interest in the draft.

Thanks,
Chris (chair hat off)

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-wood-tls-ticketrequests-01.txt
> Date: October 13, 2018 at 6:05:44 PM PDT
> To: Christopher Wood <[email-masked]>, David Schinazi <[email-masked]>, Tommy Pauly <[email-masked]>, "Christopher A. Wood" <[email-masked]>
> 
> 
> A new version of I-D, draft-wood-tls-ticketrequests-01.txt
> has been successfully submitted by Christopher A. Wood and posted to the
> IETF repository.
> 
> Name:		draft-wood-tls-ticketrequests
> Revision:	01
> Title:		TLS Ticket Requests
> Document date:	2018-10-13
> Group:		Individual Submission
> Pages:		6
> URL:            https://www.ietf.org/internet-drafts/draft-wood-tls-ticketrequests-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-wood-tls-ticketrequests/
> Htmlized:       https://tools.ietf.org/html/draft-wood-tls-ticketrequests-01
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-wood-tls-ticketrequests
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-wood-tls-ticketrequests-01
> 
> Abstract:
>   TLS session tickets enable stateless connection resumption for
>   clients without server-side per-client state.  Servers vend session
>   tickets to clients, at their discretion, upon connection
>   establishment.  Clients store and use tickets when resuming future
>   connections.  Moreover, clients should use tickets at most once for
>   session resumption, especially if such keying material protects early
>   application data.  Single-use tickets bound the number of parallel
>   connections a client may initiate by the number of tickets received
>   from a given server.  To address this limitation, this document
>   describes a mechanism by which clients may specify the desired number
>   of tickets needed for future connections.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 30 Oct 2018 15:49:54 +1100

There is an ongoing discussion on the QUIC issue tracker that might
benefit from some attention here.

https://github.com/quicwg/base-drafts/issues/1834

Of most interest here is that there is no mechanism by which a TLS
endpoint can limit the size of handshake messages.  This wasn't a
problem prior to TLS 1.3, renegotiation notwithstanding, but if an
endpoint needs to buffer a 16Mb message it will probably be unhappy.
And many TLS implementations buffer.  Knowing where short of 16Mb is
safe to send is tricky.  Right now, all we do is rely on the natural
pressure to keep tickets small and the fact that tickets are pure
overhead to keep things under control, but it's a hole that is a
little irritating to leave unpatched.

Of secondary concern for QUIC and DTLS, but not TLS, is the total
amount of data that can be sent in handshake messages.  If that data
arrives out of order, it would be nice to bound the amount of memory
that is apportioned for receiving and reassembling handshake messages.
I mention this only because the same solution might be used to fix
both problems.

(I was motivated to post this after reading the ticket requests draft
from Chris, which we should publish.  That draft doesn't run really
cause this problem, but it made me think that 255 tickets might make a
bit of a mess if sent all at once.)

---

From: John Mattsson <[email-masked]>
Date: Tue, 30 Oct 2018 11:37:32 +0000

>Of secondary concern for QUIC and DTLS, but not TLS, is the total amount of data that can be sent in handshake messages.  

The total amount of data sent in the TLS handshake is quite a big concern when TLS is used in EAP-TLS. Many authenticator (access point) implementations will drop the EAP session if it hasn't finished after 40 - 50 packets or approximately 60 kB. 255 tickets would make many EAP-TLS session to fail, but the suggested mechanism where the client indicates the desired number of tickets seems good.

Cheers,
John

-----Original Message-----
From: TLS <[email-masked]> on behalf of Martin Thomson <[email-masked]>
Date: Tuesday, 30 October 2018 at 05:50
To: "[email-masked]" <[email-masked]>
Subject: [TLS] TLS message limits

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

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 31 Oct 2018 04:52:49 +0000

John Mattsson <[email-masked]> writes:

>The total amount of data sent in the TLS handshake is quite a big concern
>when TLS is used in EAP-TLS. Many authenticator (access point)
>implementations will drop the EAP session if it hasn't finished after 40 - 50
>packets or approximately 60 kB. 

It's even worse with the common EAP-over-RADIUS, where you're limited to 4kB
total size, with even that needing to be broken down into 253-byte sub-
packets.

Peter.