Re: [TLS] TurboTLS: handshaking over UDP to remove 1 round trip

[Bas Westerbaan]

I would like to see examples of these use cases where using QUIC is
impossible, but using TurboTLS is.

Best,

 Bas

On Wed, Nov 15, 2023 at 6:37 PM David Joseph  wrote:

> Hi everyone,
>
> We wanted to speak about this draft on *TurboTLS* at 118 but didn't
> manage to squeeze into the packed session.
>
> Forwarding a new draft here that describes an idea for UDP handshaking in
> parallel to setting up the TCP stream, then switching back to TLS-over-TCP
> for the session portion. This enables *removing one round trip from all
> TLS versions* in the best case, and in the worst case scenario, falling
> back to TLS-over-TCP with an extremely small latency boost.
>
> TurboTLS doesn't change the contents of any TLS messages, only how some
> handshake messages are delivered over UDP instead of TCP. This technique
> supports *transparent proxying*, whereby standard TLS requests can be
> intercepted and turbo charged, by sitting one proxy in front of both client
> and server. First client requests are intercepted, translated to UDP,
> received by the server proxy, translated back to TCP, and sent back without
> client nor server being aware that their exchange has been turbo charged.
>
> Proxying enables legacy systems using all versions of TLS to obtain faster
> connection establishment without touching their network stack. TurboTLS has
> most potential *where migration to QUIC is not possible *in the near
> term due to legacy servers, or due to firewall visibility/deep packet
> inspection concerns, yet for systems which handle many short-lived TLS
> connections per second with non-trivial network latency.
>
> We managed to speak with a few of you privately about your thoughts on the
> benefits and drawbacks of this technique, and would like you to share any
> more opinions with us below so that we can understand whether it is worth
> developing this draft further.
>
> If this sounds like it might be useful to you/your use case, please get in
> touch!
>
> Kind regards,
> David
>
> -- Forwarded message -
> From: 
> Date: Sun, Nov 5, 2023 at 12:43 AM
> Subject: New Version Notification for draft-joseph-tls-turbotls-00.txt
> To: Carlos Aguilar-Melchor , David Joseph <
> d...@sandboxaq.com>, Douglas Stebila , Jason
> Goertzen 
>
>
> A new version of Internet-Draft draft-joseph-tls-turbotls-00.txt has been
> successfully submitted by Deirdre Connolly and posted to the
> IETF repository.
>
> Name: draft-joseph-tls-turbotls
> Revision: 00
> Title:TurboTLS for faster connection establishment
> Date: 2023-11-05
> Group:Individual Submission
> Pages:16
> URL:  https://www.ietf.org/archive/id/draft-joseph-tls-turbotls-00.txt
> Status:   https://datatracker.ietf.org/doc/draft-joseph-tls-turbotls/
> HTML:
> https://www.ietf.org/archive/id/draft-joseph-tls-turbotls-00.html
> HTMLized: https://datatracker.ietf.org/doc/html/draft-joseph-tls-turbotls
>
>
> Abstract:
>
>This document provides a high level protocol description for
>handshaking over UDP in the Transport Layer Security (TLS) protocol
>(version independent).  In parallel, a TCP session is established,
>and once this is done, the TLS session reverts to TCP.  In the event
>that the UDP handshaking portion fails, TurboTLS falls back to TLS-
>over-TCP as is usually done, resulting in negligible latency cost in
>the case of failure.
>
>Discussion of this work is encouraged to happen on the TLS IETF
>mailing list tls@ietf.org or on the GitHub repository which contains
>the draft: https://github.com/PhDJsandboxaq/draft-ietf-turbotls-design
>
>
>
> The IETF Secretariat
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TurboTLS: handshaking over UDP to remove 1 round trip

[John Mattsson]

>I would like to see examples of these use cases where using QUIC is 
>impossible, but using >TurboTLS is.

+1

QUIC is the obvious future replacement for TCP, (D)TLS, SCTP, and RTP. I think 
IETF should focus on QUIC. I think people staying on TLS/TCP need to live with 
an extra roundtrip. Visibility is likely not a very convincing argument for the 
TLS WG. Visibility needs to be solved in the endpoints. The sooner people 
understand this the better. TurboTLS would just delay this transition.

Cheers,
John

From: TLS  on behalf of Bas Westerbaan 

Date: Monday, 27 November 2023 at 11:40
To: David Joseph 
Cc: tls@ietf.org 
Subject: Re: [TLS] TurboTLS: handshaking over UDP to remove 1 round trip
I would like to see examples of these use cases where using QUIC is impossible, 
but using TurboTLS is.

Best,

 Bas

On Wed, Nov 15, 2023 at 6:37 PM David Joseph 
mailto:d...@sandboxaq.com>> wrote:
Hi everyone,

We wanted to speak about this draft on TurboTLS at 118 but didn't manage to 
squeeze into the packed session.

Forwarding a new draft here that describes an idea for UDP handshaking in 
parallel to setting up the TCP stream, then switching back to TLS-over-TCP for 
the session portion. This enables removing one round trip from all TLS versions 
in the best case, and in the worst case scenario, falling back to TLS-over-TCP 
with an extremely small latency boost.

TurboTLS doesn't change the contents of any TLS messages, only how some 
handshake messages are delivered over UDP instead of TCP. This technique 
supports transparent proxying, whereby standard TLS requests can be intercepted 
and turbo charged, by sitting one proxy in front of both client and server. 
First client requests are intercepted, translated to UDP, received by the 
server proxy, translated back to TCP, and sent back without client nor server 
being aware that their exchange has been turbo charged.

Proxying enables legacy systems using all versions of TLS to obtain faster 
connection establishment without touching their network stack. TurboTLS has 
most potential where migration to QUIC is not possible in the near term due to 
legacy servers, or due to firewall visibility/deep packet inspection concerns, 
yet for systems which handle many short-lived TLS connections per second with 
non-trivial network latency.

We managed to speak with a few of you privately about your thoughts on the 
benefits and drawbacks of this technique, and would like you to share any more 
opinions with us below so that we can understand whether it is worth developing 
this draft further.

If this sounds like it might be useful to you/your use case, please get in 
touch!

Kind regards,
David

-- Forwarded message -
From: mailto:internet-dra...@ietf.org>>
Date: Sun, Nov 5, 2023 at 12:43 AM
Subject: New Version Notification for draft-joseph-tls-turbotls-00.txt
To: Carlos Aguilar-Melchor 
mailto:carlos.agui...@sandboxaq.com>>, David 
Joseph mailto:d...@sandboxaq.com>>, Douglas Stebila 
mailto:dsteb...@uwaterloo.ca>>, Jason Goertzen 
mailto:jason.goert...@sandboxquantum.com>>


A new version of Internet-Draft draft-joseph-tls-turbotls-00.txt has been
successfully submitted by Deirdre Connolly and posted to the
IETF repository.

Name: draft-joseph-tls-turbotls
Revision: 00
Title:TurboTLS for faster connection establishment
Date: 2023-11-05
Group:Individual Submission
Pages:16
URL:  https://www.ietf.org/archive/id/draft-joseph-tls-turbotls-00.txt
Status:   https://datatracker.ietf.org/doc/draft-joseph-tls-turbotls/
HTML: https://www.ietf.org/archive/id/draft-joseph-tls-turbotls-00.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-joseph-tls-turbotls


Abstract:

   This document provides a high level protocol description for
   handshaking over UDP in the Transport Layer Security (TLS) protocol
   (version independent).  In parallel, a TCP session is established,
   and once this is done, the TLS session reverts to TCP.  In the event
   that the UDP handshaking portion fails, TurboTLS falls back to TLS-
   over-TCP as is usually done, resulting in negligible latency cost in
   the case of failure.

   Discussion of this work is encouraged to happen on the TLS IETF
   mailing list tls@ietf.org or on the GitHub repository 
which contains
   the draft: 
https://github.com/PhDJsandboxaq/draft-ietf-turbotls-design



The IETF Secretariat

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ECH: Changes to IANA consideration section

[Sean Turner]

Bumping this up in case anybody missed it.

spt

> On Nov 21, 2023, at 21:03, Sean Turner  wrote:
> 
> Hi! I sent over the early allocation request and the IANA folks rightly 
> pointed out two things that need to be added. This email is to make sure we 
> have agreement on the two changes to the registrations in s11.1. If you don’t 
> agree with the values proposed below please let the list know by 1 December 
> 2023.
> 
> 1. The encrypted_client_hello and ech_outer_extensions registrations need to 
> indicate the value for the "DTLS-Only” column. Unless I am mistaken, “N” is 
> the obvious value for both. See 
> https://github.com/tlswg/draft-ietf-tls-esni/pull/584
> 
> 2. The "TLS 1.3” column for ech_outer_extensions registration needs to 
> indicate a value; remember, this column indicates the messages in which the 
> extension may appear.  Currently, it’s “”. “N/A" has been suggested, which 
> makes sense to me considering this extension never directly appears in CH, 
> SH, EE, CT, CR, NST, or HRR extensions field. We can’t use “-“ because that 
> means not used in TLS 1.3. “” is used elsewhere in the registry by only for 
> unassigned and reserved values.  The following PR change “” to “N/A”: 
> https://github.com/tlswg/draft-ietf-tls-esni/pull/59
> 
> Cheers,
> spt

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] I-D Action: draft-ietf-tls-rfc8447bis-06.txt

[internet-drafts]

Internet-Draft draft-ietf-tls-rfc8447bis-06.txt is now available. It is a work
item of the Transport Layer Security (TLS) WG of the IETF.

   Title:   IANA Registry Updates for TLS and DTLS
   Authors: Joe Salowey
Sean Turner
   Name:draft-ietf-tls-rfc8447bis-06.txt
   Pages:   18
   Dates:   2023-11-27

Abstract:

   This document updates the changes to TLS and DTLS IANA registries
   made in RFC 8447.  It adds a new value "D" for discouraged to the
   recommended column of the selected TLS registries.

   This document updates the following RFCs: 3749, 5077, 4680, 5246,
   5705, 5878, 6520, 7301, and 8447.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tls-rfc8447bis-06.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-rfc8447bis-06

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] I-D Action: draft-ietf-tls-rfc8447bis-07.txt

[internet-drafts]

Internet-Draft draft-ietf-tls-rfc8447bis-07.txt is now available. It is a work
item of the Transport Layer Security (TLS) WG of the IETF.

   Title:   IANA Registry Updates for TLS and DTLS
   Authors: Joe Salowey
Sean Turner
   Name:draft-ietf-tls-rfc8447bis-07.txt
   Pages:   18
   Dates:   2023-11-27

Abstract:

   This document updates the changes to TLS and DTLS IANA registries
   made in RFC 8447.  It adds a new value "D" for discouraged to the
   recommended column of the selected TLS registries.

   This document updates the following RFCs: 3749, 5077, 4680, 5246,
   5705, 5878, 6520, 7301, and 8447.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tls-rfc8447bis-07.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-rfc8447bis-07

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-07.txt

[Sean Turner]

Hi! -06 and -07 incorporate the “Comment” column that we discussed at IETF 118. 
 Joe and I are planning to ask for WGLC on this version.

spt

> On Nov 27, 2023, at 10:11, internet-dra...@ietf.org wrote:
> 
> Internet-Draft draft-ietf-tls-rfc8447bis-07.txt is now available. It is a work
> item of the Transport Layer Security (TLS) WG of the IETF.
> 
>   Title:   IANA Registry Updates for TLS and DTLS
>   Authors: Joe Salowey
>Sean Turner
>   Name:draft-ietf-tls-rfc8447bis-07.txt
>   Pages:   18
>   Dates:   2023-11-27
> 
> Abstract:
> 
>   This document updates the changes to TLS and DTLS IANA registries
>   made in RFC 8447.  It adds a new value "D" for discouraged to the
>   recommended column of the selected TLS registries.
> 
>   This document updates the following RFCs: 3749, 5077, 4680, 5246,
>   5705, 5878, 6520, 7301, and 8447.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-tls-rfc8447bis-07.html
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-rfc8447bis-07
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ECH: Changes to IANA consideration section

[Sean Turner]

> On Nov 21, 2023, at 21:03, Sean Turner  wrote:
> 
> Hi! I sent over the early allocation request and the IANA folks rightly 
> pointed out two things that need to be added. This email is to make sure we 
> have agreement on the two changes to the registrations in s11.1. If you don’t 
> agree with the values proposed below please let the list know by 1 December 
> 2023.
> 
> 1. The encrypted_client_hello and ech_outer_extensions registrations need to 
> indicate the value for the "DTLS-Only” column. Unless I am mistaken, “N” is 
> the obvious value for both. See 
> https://github.com/tlswg/draft-ietf-tls-esni/pull/584
> 
> 2. The "TLS 1.3” column for ech_outer_extensions registration needs to 
> indicate a value; remember, this column indicates the messages in which the 
> extension may appear.  Currently, it’s “”. “N/A" has been suggested, which 
> makes sense to me considering this extension never directly appears in CH, 
> SH, EE, CT, CR, NST, or HRR extensions field. We can’t use “-“ because that 
> means not used in TLS 1.3. “” is used elsewhere in the registry by only for 
> unassigned and reserved values.  The following PR change “” to “N/A”: 
> https://github.com/tlswg/draft-ietf-tls-esni/pull/59

Whoops it is PR #597 not #59:
https://github.com/tlswg/draft-ietf-tls-esni/pull/597

> Cheers,
> spt

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ECH: Changes to IANA consideration section

[Watson Ladd]

On Tue, Nov 21, 2023 at 9:03 PM Sean Turner  wrote:
>
> Hi! I sent over the early allocation request and the IANA folks rightly 
> pointed out two things that need to be added. This email is to make sure we 
> have agreement on the two changes to the registrations in s11.1. If you don’t 
> agree with the values proposed below please let the list know by 1 December 
> 2023.
>
> 1. The encrypted_client_hello and ech_outer_extensions registrations need to 
> indicate the value for the "DTLS-Only” column. Unless I am mistaken, “N” is 
> the obvious value for both. See 
> https://github.com/tlswg/draft-ietf-tls-esni/pull/584
>
> 2. The "TLS 1.3” column for ech_outer_extensions registration needs to 
> indicate a value; remember, this column indicates the messages in which the 
> extension may appear.  Currently, it’s “”. “N/A" has been suggested, which 
> makes sense to me considering this extension never directly appears in CH, 
> SH, EE, CT, CR, NST, or HRR extensions field. We can’t use “-“ because that 
> means not used in TLS 1.3. “” is used elsewhere in the registry by only for 
> unassigned and reserved values.  The following PR change “” to “N/A”: 
> https://github.com/tlswg/draft-ietf-tls-esni/pull/59

The only alternative I can think of is to introduce CHI, standing for
client hello inner, as a possible value for that field. Then we need
to update all the other values in the registry as well. I understand
why we got to N/A, but the subtlety of N/A vs - vs the empty string
irks me a bit, especially as this is used in TLS 1.3, hence the list
is applicable, it's just empty!

Sincerely,
Watson

>
> Cheers,
> spt
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



-- 
Astra mortemque praestare gradatim

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-07.txt

[Salz, Rich]

> Hi! -06 and -07 incorporate the “Comment” column that we discussed at IETF 
> 118. Joe and I are planning to ask for WGLC on this version.


Looks good to me, thanks!

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-07.txt

[Watson Ladd]

On Mon, Nov 27, 2023 at 10:14 AM Sean Turner  wrote:
>
> Hi! -06 and -07 incorporate the “Comment” column that we discussed at IETF 
> 118.  Joe and I are planning to ask for WGLC on this version.

Minor quibble with the IANA instructions for instruction type. It
reads " Setting a value to "Y" or "D" in the "Recommended" column
requires IETF Standards Action [RFC8126].  Any state transition to or
from a "Y" or "D" value requires IESG Approval."  To me this is a bit
unclear: standards action is required to move a value to Y or D, but
then does IESG Approval kick in as well? Conversely is IESG approval
the only way to make something N? I think the answer to this as
written is yes, while the first one is genuinely unclear.

Sincerely,
Watson Ladd

-- 
Astra mortemque praestare gradatim

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ECH: Changes to IANA consideration section

[Martin Thomson]

On Tue, Nov 28, 2023, at 05:03, Watson Ladd wrote:
>> 2. The "TLS 1.3” column for ech_outer_extensions registration needs to 
>> indicate a value; remember, this column indicates the messages in which the 
>> extension may appear.  Currently, it’s “”. “N/A" has been suggested, which 
>> makes sense to me considering this extension never directly appears in CH, 
>> SH, EE, CT, CR, NST, or HRR extensions field. We can’t use “-“ because that 
>> means not used in TLS 1.3. “” is used elsewhere in the registry by only for 
>> unassigned and reserved values.  The following PR change “” to “N/A”: 
>> https://github.com/tlswg/draft-ietf-tls-esni/pull/59
>
> The only alternative I can think of is to introduce CHI, standing for
> client hello inner, as a possible value for that field. Then we need
> to update all the other values in the registry as well. I understand
> why we got to N/A, but the subtlety of N/A vs - vs the empty string
> irks me a bit, especially as this is used in TLS 1.3, hence the list
> is applicable, it's just empty!

"CH" seems fine to me.

That it can only appear in the inner CH is a very important detail, but one 
that is addressed in the specification.  Many other extensions have conditions 
on when they can be included in a message.  This might be a new level of 
conditionality, but it seems like implementing the specification will clear up 
any confusion.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls