Re: [TLS] Flags Extension: why only for TLS 1.3?

[Filippo Valsorda]

2021-11-04 11:12 GMT-04:00 David Benjamin :
> Indeed it's *because* there is still an existing 1.2 deployment that we 
> should be judicious with backports. Today, nearly every TLS implementation 
> needs to implement both 1.2 and 1.3. The ClientHello is cross-version, so it 
> is not possible for a client to say "I implement xyz extension only at 1.3". 
> That means anyone implementing a backported extension *must* implement and 
> test it in 1.2, even though it'll be virtually unused. Existing 1.2 peers 
> don't implement it and new peers will use it at 1.3.

What David mentions here resonates and is worth underscoring. Specifying an 
extension for both TLS 1.2 and TLS 1.3 forces almost every stack to support it 
at both versions. We don't get to choose "no, we only implement new stuff in 
TLS 1.3", which as far as Go is concerned, is the policy we want.

I understand that IoT devices are not running dual stacks, but that's not the 
point. This is an ecosystem cost analysis. If the extension is defined at both 
TLS 1.2 and TLS 1.3, all dual stacks out there will need to support it at both 
versions.

I think the condition in the charter that Sean mentioned is good, and should be 
abided. If an extension is about TLS 1.2 compatibility or transition, or if 
it's important not to fracture the ecosystem, it might be worth backporting; if 
it's just convenient for stacks that have not updated yet, it should not.___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Flags Extension: why only for TLS 1.3?

[Eric Rescorla]

FWIW, while I don't think we should be doing much enhancement of (D)TLS
1.2, I also don't think it makes sense not to allow enhancements to 1.3 to
be used with 1.2 where that makes sense, as it seems to here.

-Ekr


On Thu, Nov 4, 2021 at 11:05 AM Achim Kraus  wrote:

> Hi Sean,
>
> I hope, the answer of Hannes counts as "significant justification".
>
> Most of the discussion and arguments are about TLS 1.2 and 1.3.
>
> Just to be clear:
> RRC will only apply to DTLS, 1.2 and 1.3. There is no usage for TLS.
> And for RRC, Hannes and Thomas wants to use the "Flags Extension".
>
> I'm not sure, how fast DTLS 1.2 deployments will be moved to DTLS 1.3.
> But I'm pretty sure, that DTLS 1.2 with Connection ID will make many
> NB-IoT solutions possible, and RRC will help to defend that against
> attacks.
>
> best regards
> Achim Kraus
> Eclipse/Californium
> (Currently DTLS 1.2 only ;-) )
>
> Am 04.11.21 um 14:27 schrieb Sean Turner:
> > Hannes,
> >
> > Sorry I forgot to answer this, but John pretty much answered it for me.
> The prevailing notion that the WG has been under is that extensions defined
> are for TLS 1.3. We put the following in the charter to make that clear:
> >
> > 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.
> >
> > So ... do you have a significant justification?
> >
> > Cheers,
> > spt
> >
> >> On Nov 4, 2021, at 09:11, John Mattsson  40ericsson@dmarc.ietf.org> wrote:
> >>
> >> TLS 1.2 has been obsolete for over three years. Oxford dictionary
> defines obsolete as "no longer produced or used; out of date." NIST
> requires support of TLS 1.3 everywhere no later than Jan 2024, which at
> least in theory means no negotiation of TLS 1.2.
> >>
> >> I think IETF, TLS WG, and TLS libraries should spend their time on TLS
> 1.3 rather than giving the false idea it is ok to stay on TLS 1.2.
> >>
> >> John
> >>
> >> From: TLS  on behalf of Hannes Tschofenig <
> hannes.tschofe...@arm.com>
> >> Date: Monday, 25 October 2021 at 19:12
> >> To: IETF TLS 
> >> Subject: [TLS] Flags Extension: why only for TLS 1.3?
> >>
> >> Hi all,
> >>
> >> why is the flags extension only defined for TLS 1.3?
> >>
> >> There is nothing in this extension that prevents us from using it also
> in TLS 1.2.
> >>
> >> Could we make it also available to TLS 1.2?
> >>
> >> Ciao
> >> Hannes
> >>
> >> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> >> ___
> >> 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
> >
>
> ___
> 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] Flags Extension: why only for TLS 1.3?

[Achim Kraus]

Hi Sean,

I hope, the answer of Hannes counts as "significant justification".

Most of the discussion and arguments are about TLS 1.2 and 1.3.

Just to be clear:
RRC will only apply to DTLS, 1.2 and 1.3. There is no usage for TLS.
And for RRC, Hannes and Thomas wants to use the "Flags Extension".

I'm not sure, how fast DTLS 1.2 deployments will be moved to DTLS 1.3.
But I'm pretty sure, that DTLS 1.2 with Connection ID will make many
NB-IoT solutions possible, and RRC will help to defend that against
attacks.

best regards
Achim Kraus
Eclipse/Californium
(Currently DTLS 1.2 only ;-) )

Am 04.11.21 um 14:27 schrieb Sean Turner:

Hannes,

Sorry I forgot to answer this, but John pretty much answered it for me. The 
prevailing notion that the WG has been under is that extensions defined are for 
TLS 1.3. We put the following in the charter to make that clear:

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.

So ... do you have a significant justification?

Cheers,
spt


On Nov 4, 2021, at 09:11, John Mattsson 
 wrote:

TLS 1.2 has been obsolete for over three years. Oxford dictionary defines obsolete as 
"no longer produced or used; out of date." NIST requires support of TLS 1.3 
everywhere no later than Jan 2024, which at least in theory means no negotiation of TLS 
1.2.

I think IETF, TLS WG, and TLS libraries should spend their time on TLS 1.3 
rather than giving the false idea it is ok to stay on TLS 1.2.

John

From: TLS  on behalf of Hannes Tschofenig 

Date: Monday, 25 October 2021 at 19:12
To: IETF TLS 
Subject: [TLS] Flags Extension: why only for TLS 1.3?

Hi all,

why is the flags extension only defined for TLS 1.3?

There is nothing in this extension that prevents us from using it also in TLS 
1.2.

Could we make it also available to TLS 1.2?

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
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



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

Re: [TLS] Flags Extension: why only for TLS 1.3?

[Hannes Tschofenig]

Hi David,





  *   While it's true there is still plenty of 1.2 in many environments, 
defining a new extension like flags or connection ID won't make it apply to 
those connections. Both sides need to deploy new code to implement that 
extension. That means we shouldn't be looking at the trailing end of each 
environment, but the state of new deployments and where those should go. In 
that light, I think it makes sense to focus new protocol development on 1.3. If 
you have to deploy new TLS software anyway, you should migrate to 1.3.

This is just my experience: our partners are interested in moving to TLS 1.3. 
That’s great. There is still a lot of deployment based on 1.2. This deployment 
needs to be maintained. Companies have deployed the CID extension already and 
will apply software updates. Updating the code to add a feature, a bugfix and 
alike is one thing. Switching out the security stack altogether is not a minor 
thing.


  *   Indeed it's because there is still an existing 1.2 deployment that we 
should be judicious with backports. Today, nearly every TLS implementation 
needs to implement both 1.2 and 1.3. The ClientHello is cross-version, so it is 
not possible for a client to say "I implement xyz extension only at 1.3". That 
means anyone implementing a backported extension must implement and test it in 
1.2, even though it'll be virtually unused. Existing 1.2 peers don't implement 
it and new peers will use it at 1.3.

In the IoT space, the device have constraints. They are not implementing a dual 
stack 1.2 / 1.3 version for Cortex M class devices (at least in almost all 
cases).

If I have to define an extension for use with the ClientHello in DTLS 1.2 and a 
different one (based on flags) in DTLS 1.3 then this would not make my life any 
easier.

Ciao
Hannes

On Thu, Nov 4, 2021 at 9:57 AM Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>> wrote:
The term “obsolete” appears to be used incorrectly when it comes to TLS/DTLS 
1.2 used in the IoT environment. It is widely used today and I expect it to be 
used for a while since (a) there are no security problems with it (when 
configured correctly), and (b) for many use cases it also offers suitable 
performance. There is a well-tested open source codebase available for TLS/DTLS 
1.2. While I am a big fan of TLS / DTLS 1.3, I would also like to acknowledge 
the speed at which the market operates.

From: John Mattsson 
mailto:john.matts...@ericsson.com>>
Sent: Thursday, November 4, 2021 2:11 PM
To: Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>>; IETF TLS 
mailto:tls@ietf.org>>
Subject: Re: Flags Extension: why only for TLS 1.3?

TLS 1.2 has been obsolete for over three years. Oxford dictionary defines 
obsolete as "no longer produced or used; out of date." NIST requires support of 
TLS 1.3 everywhere no later than Jan 2024, which at least in theory means no 
negotiation of TLS 1.2.

I think IETF, TLS WG, and TLS libraries should spend their time on TLS 1.3 
rather than giving the false idea it is ok to stay on TLS 1.2.

John

From: TLS mailto:tls-boun...@ietf.org>> on behalf of 
Hannes Tschofenig mailto:hannes.tschofe...@arm.com>>
Date: Monday, 25 October 2021 at 19:12
To: IETF TLS mailto:tls@ietf.org>>
Subject: [TLS] Flags Extension: why only for TLS 1.3?
Hi all,

why is the flags extension only defined for TLS 1.3?

There is nothing in this extension that prevents us from using it also in TLS 
1.2.

Could we make it also available to TLS 1.2?

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Flags Extension: why only for TLS 1.3?

[John Mattsson]

I think the term telecom is as obsolete as TLS 1.2 :) Mobile network are all 
IP, and voice communication is to a large degree provided by Internet 
companies. 3GPP operates in generations every 10 years (2G, 3G, 4G, 5G, 6G), 
half generations every 5 years (GPRS, HSPA, 4G LTE Advanced), as well as 
releases every 1-2 years. I think the cellular industry has been one of the 
quickest adopters of TLS 1.3:

- 3GPP Rel-15 (2018) mandated support of TLS 1.3 for all network nodes for all 
uses of TLS (3GPP standards and products have quite many uses of (D)TLS). 5G 
core networks rely on TLS 1.3 and HTTPS for the new SBA zero-trust architecture.
- 3GPP Rel-16 (2020) mandated support of TLS 1.3 for all UEs (mobile phones and 
IoT devices) as well as EAP-TLS 1.3 (if EAP-TLS is supported).
- 3GPP Rel-17 (2021) has an approved work item to mandate support of DTLS 1.3 
but due to it not being published as an RFC yet, that is likely to happen in 
Rel-18 (2023) instead.

In the dark ages of SSL 3.0, TLS 1.0, TLS 1.1, etc. it seems to have been 
considered acceptable to continue using obsolete versions of security protocols 
like TLS. I’m happy that NIST agrees that this is not acceptable anymore. 
Industries should have started with the TLS 1.3 transition many years ago, 
right now industries should start thinking about when support of TLS 1.2 can be 
turned off (which is likely not before 2030-ish).

Cheers,
John

From: Salz, Rich 
Date: Thursday, 4 November 2021 at 15:02
To: Hannes Tschofenig , John Mattsson 
, IETF TLS 
Subject: Re: [TLS] Flags Extension: why only for TLS 1.3?
I am amused to see a telecom person saying obsolete when it’s only 2-3 years 
old.  In my discussions I’ve found that they think in terms of at least 10 
years. ☺

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

Re: [TLS] Flags Extension: why only for TLS 1.3?

[David Benjamin]

While it's true there is still plenty of 1.2 in many environments, defining
a new extension like flags or connection ID won't make it apply to those
connections. Both sides need to deploy new code to implement that
extension. That means we shouldn't be looking at the trailing end of each
environment, but the state of new deployments and where those should go. In
that light, I think it makes sense to focus new protocol development on
1.3. If you have to deploy new TLS software anyway, you should migrate to
1.3.

Indeed it's *because* there is still an existing 1.2 deployment that we
should be judicious with backports. Today, nearly every TLS implementation
needs to implement both 1.2 and 1.3. The ClientHello is cross-version, so
it is not possible for a client to say "I implement xyz extension only at
1.3". That means anyone implementing a backported extension *must* implement
and test it in 1.2, even though it'll be virtually unused. Existing 1.2
peers don't implement it and new peers will use it at 1.3.

On Thu, Nov 4, 2021 at 9:57 AM Hannes Tschofenig 
wrote:

> The term “obsolete” appears to be used incorrectly when it comes to
> TLS/DTLS 1.2 used in the IoT environment. It is widely used today and I
> expect it to be used for a while since (a) there are no security problems
> with it (when configured correctly), and (b) for many use cases it also
> offers suitable performance. There is a well-tested open source codebase
> available for TLS/DTLS 1.2. While I am a big fan of TLS / DTLS 1.3, I would
> also like to acknowledge the speed at which the market operates.
>
>
>
> *From:* John Mattsson 
> *Sent:* Thursday, November 4, 2021 2:11 PM
> *To:* Hannes Tschofenig ; IETF TLS <
> tls@ietf.org>
> *Subject:* Re: Flags Extension: why only for TLS 1.3?
>
>
>
> TLS 1.2 has been obsolete for over three years. Oxford dictionary defines
> obsolete as "no longer produced or used; out of date." NIST requires
> support of TLS 1.3 everywhere no later than Jan 2024, which at least in
> theory means no negotiation of TLS 1.2.
>
>
>
> I think IETF, TLS WG, and TLS libraries should spend their time on TLS
> 1.3 rather than giving the false idea it is ok to stay on TLS 1.2.
>
>
>
> John
>
>
>
> *From: *TLS  on behalf of Hannes Tschofenig <
> hannes.tschofe...@arm.com>
> *Date: *Monday, 25 October 2021 at 19:12
> *To: *IETF TLS 
> *Subject: *[TLS] Flags Extension: why only for TLS 1.3?
>
> Hi all,
>
>
>
> why is the flags extension only defined for TLS 1.3?
>
>
>
> There is nothing in this extension that prevents us from using it also in
> TLS 1.2.
>
>
>
> Could we make it also available to TLS 1.2?
>
>
>
> Ciao
>
> Hannes
>
>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> ___
> 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] Flags Extension: why only for TLS 1.3?

[Salz, Rich]

I am amused to see a telecom person saying obsolete when it’s only 2-3 years 
old.  In my discussions I’ve found that they think in terms of at least 10 
years. ☺

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

Re: [TLS] Flags Extension: why only for TLS 1.3?

[Hannes Tschofenig]

The term "obsolete" appears to be used incorrectly when it comes to TLS/DTLS 
1.2 used in the IoT environment. It is widely used today and I expect it to be 
used for a while since (a) there are no security problems with it (when 
configured correctly), and (b) for many use cases it also offers suitable 
performance. There is a well-tested open source codebase available for TLS/DTLS 
1.2. While I am a big fan of TLS / DTLS 1.3, I would also like to acknowledge 
the speed at which the market operates.

From: John Mattsson 
Sent: Thursday, November 4, 2021 2:11 PM
To: Hannes Tschofenig ; IETF TLS 
Subject: Re: Flags Extension: why only for TLS 1.3?

TLS 1.2 has been obsolete for over three years. Oxford dictionary defines 
obsolete as "no longer produced or used; out of date." NIST requires support of 
TLS 1.3 everywhere no later than Jan 2024, which at least in theory means no 
negotiation of TLS 1.2.

I think IETF, TLS WG, and TLS libraries should spend their time on TLS 1.3 
rather than giving the false idea it is ok to stay on TLS 1.2.

John

From: TLS mailto:tls-boun...@ietf.org>> on behalf of 
Hannes Tschofenig mailto:hannes.tschofe...@arm.com>>
Date: Monday, 25 October 2021 at 19:12
To: IETF TLS mailto:tls@ietf.org>>
Subject: [TLS] Flags Extension: why only for TLS 1.3?
Hi all,

why is the flags extension only defined for TLS 1.3?

There is nothing in this extension that prevents us from using it also in TLS 
1.2.

Could we make it also available to TLS 1.2?

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Flags Extension: why only for TLS 1.3?

[Hannes Tschofenig]

The problem we ran into is the following: We are just publishing the RFCs for 
the connection IDs for DTLS 1.2 and for DTLS 1.3. For the RRC work we need to 
define an extension. Using the flags extension makes a lot of sense for TLS 1.3 
(to avoid wasting bytes sent over the wire). Should we do something entirely 
different for DTLS 1.2?

-Original Message-
From: Sean Turner 
Sent: Thursday, November 4, 2021 2:27 PM
To: Hannes Tschofenig 
Cc: TLS List 
Subject: Re: [TLS] Flags Extension: why only for TLS 1.3?

Hannes,

Sorry I forgot to answer this, but John pretty much answered it for me. The 
prevailing notion that the WG has been under is that extensions defined are for 
TLS 1.3. We put the following in the charter to make that clear:

   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.

So ... do you have a significant justification?

Cheers,
spt

> On Nov 4, 2021, at 09:11, John Mattsson 
>  wrote:
>
> TLS 1.2 has been obsolete for over three years. Oxford dictionary defines 
> obsolete as "no longer produced or used; out of date." NIST requires support 
> of TLS 1.3 everywhere no later than Jan 2024, which at least in theory means 
> no negotiation of TLS 1.2.
>
> I think IETF, TLS WG, and TLS libraries should spend their time on TLS 1.3 
> rather than giving the false idea it is ok to stay on TLS 1.2.
>
> John
>
> From: TLS  on behalf of Hannes Tschofenig 
> 
> Date: Monday, 25 October 2021 at 19:12
> To: IETF TLS 
> Subject: [TLS] Flags Extension: why only for TLS 1.3?
>
> Hi all,
>
> why is the flags extension only defined for TLS 1.3?
>
> There is nothing in this extension that prevents us from using it also in TLS 
> 1.2.
>
> Could we make it also available to TLS 1.2?
>
> Ciao
> Hannes
>
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you.
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

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

Re: [TLS] Flags Extension: why only for TLS 1.3?

[Sean Turner]

Hannes,

Sorry I forgot to answer this, but John pretty much answered it for me. The 
prevailing notion that the WG has been under is that extensions defined are for 
TLS 1.3. We put the following in the charter to make that clear:

   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.

So ... do you have a significant justification?

Cheers,
spt

> On Nov 4, 2021, at 09:11, John Mattsson 
>  wrote:
> 
> TLS 1.2 has been obsolete for over three years. Oxford dictionary defines 
> obsolete as "no longer produced or used; out of date." NIST requires support 
> of TLS 1.3 everywhere no later than Jan 2024, which at least in theory means 
> no negotiation of TLS 1.2.
>  
> I think IETF, TLS WG, and TLS libraries should spend their time on TLS 1.3 
> rather than giving the false idea it is ok to stay on TLS 1.2.
>  
> John
>  
> From: TLS  on behalf of Hannes Tschofenig 
> 
> Date: Monday, 25 October 2021 at 19:12
> To: IETF TLS 
> Subject: [TLS] Flags Extension: why only for TLS 1.3?
> 
> Hi all, 
>  
> why is the flags extension only defined for TLS 1.3?
>  
> There is nothing in this extension that prevents us from using it also in TLS 
> 1.2.
>  
> Could we make it also available to TLS 1.2?
>  
> Ciao
> Hannes
>  
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium. Thank you.
> ___
> 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] Last Call: (Guidance for External PSK Usage in TLS) to Informational RFC

[John Mattsson]

Hi,

I think this is a great document with a lot of good information.


I think some things that should be more positive:

-- For both PSK authentication and PSK key exchange without (EC)DHE the bad 
security properties such as lack of identity protection and lack of forward 
secrecy can be overcome by using one-time PSKs. External PSKs with short 
lifetimes are quite common in many real deployments. I think this should be 
mentioned.

-- I think quantum resistance should be mentioned earlier in the document. 
Quantum resistance is a security property, not use a use case.


Some things that should be more negative:

-- In the list in 4.1 you can add
  "4.  Any group member can blame any other group member."


Other comments:

-- "then PSK-only key establishment modes are secure against both active and 
passive attack."
  I think this you need to describe the exact attacks you have in mind rather 
than use the work "secure". My view would be that acceptable security in 2021 
includes both identity protection and forward secrecy. But more on a system 
level, then necessarily by TLS itself.


-- "DH"
  I think it would be good to change all “DH” to “DHE” and all “Diffie-Hellman” 
to “ephemeral Diffie-Hellman” to avoid confusion with the static DH cipher 
suites in obsolete versions of TLS.


-- "As discussed in Section 6, there are use cases where it is desirable
   for multiple clients or multiple servers to share a PSK."

  "However, as discussed in Section 6, there are application scenarios
   that may rely on sharing the same PSK among multiple nodes."

Unless you have any real deployments to share, I think this should be 
reformulated. These are Gedankenexperiments used to illustrate the attack, not 
real-world applications. I would reformulate and remove "desirable", group PSKs 
should be very much discouraged. Suggestion:

"As discussed in Section 6, to illustrate their attack, [Akhmetzyanova] 
describes scenarios where multiple clients or multiple servers share a PSK."

Cheers,
John

From: TLS  on behalf of The IESG 
Date: Friday, 29 October 2021 at 18:18
To: IETF-Announce 
Cc: tls@ietf.org , draft-ietf-tls-external-psk-guida...@ietf.org 
, ka...@mit.edu , 
tls-cha...@ietf.org 
Subject: [TLS] Last Call:  
(Guidance for External PSK Usage in TLS) to Informational RFC

The IESG has received a request from the Transport Layer Security WG (tls) to
consider the following document: - 'Guidance for External PSK Usage in TLS'
   as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-c...@ietf.org mailing lists by 2021-11-19. Exceptionally, comments may
be sent to i...@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


   This document provides usage guidance for external Pre-Shared Keys
   (PSKs) in Transport Layer Security (TLS) 1.3 as defined in RFC 8446.
   This document lists TLS security properties provided by PSKs under
   certain assumptions, and then demonstrates how violations of these
   assumptions lead to attacks.  This document discusses PSK use cases
   and provisioning processes.  This document provides advice for
   applications to help meet these assumptions.  This document also
   lists the privacy and security properties that are not provided by
   TLS 1.3 when external PSKs are used.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tls-external-psk-guidance/



No IPR declarations have been submitted directly on this I-D.





___
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] tls@ietf112

[Sean Turner]

Martin,

Paul Grubbs approached us about presenting some work he has done to show "how 
zero-knowledge proofs can be used to prove properties of TLS plaintexts, and 
describes how this can solve problems related to TLS ‘visibility' in a 
privacy-preserving way, with no changes needed to TLS.  His paper can be found 
here:
https://eprint.iacr.org/2021/1022

Because this is not an I-D, I confirmed with that there are no IPR issues.

Apologies about the agenda, I think Chris has updated it to refer to the paper.

Cheers,
spt

> On Nov 4, 2021, at 02:32, Martin Thomson  wrote:
> 
> Hey Sean, what is "Zero-Knowledge Proofs meet TLS"?  I can't find a draft and 
> the link in the agenda is busted.
> 
> On Wed, Oct 20, 2021, at 06:46, Sean Turner wrote:
>> Hi! We have a meeting time scheduled for Tuesday, 9 November 2021 from 
>> 1600-1800 (UTC). Please send in your agenda topics along with how much 
>> time you think you will need to tls-cha...@ietf.org by 26 October 2021 
>> (early is better).
>> 
>> Cheers
>> Chris, Joe, and Sean
>> ___
>> 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

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

Re: [TLS] Flags Extension: why only for TLS 1.3?

[John Mattsson]

TLS 1.2 has been obsolete for over three years. Oxford dictionary defines 
obsolete as "no longer produced or used; out of date." NIST requires support of 
TLS 1.3 everywhere no later than Jan 2024, which at least in theory means no 
negotiation of TLS 1.2.

I think IETF, TLS WG, and TLS libraries should spend their time on TLS 1.3 
rather than giving the false idea it is ok to stay on TLS 1.2.

John

From: TLS  on behalf of Hannes Tschofenig 

Date: Monday, 25 October 2021 at 19:12
To: IETF TLS 
Subject: [TLS] Flags Extension: why only for TLS 1.3?
Hi all,

why is the flags extension only defined for TLS 1.3?

There is nothing in this extension that prevents us from using it also in TLS 
1.2.

Could we make it also available to TLS 1.2?

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Late DLS 1.3 issue

[Christopher Wood]

As a quick update, we're still in the process of reviewing the proposed change. 
Time pending, we may throw it on the agenda for next week's meeting.

Best,
Chris

On Thu, Oct 14, 2021, at 3:53 PM, Christopher Wood wrote:
> The PR's been updated to correct the editorial bug and clarify that the 
> epoch is truncated. We could also go with Martin's suggestion to make 
> the epoch 48 bits, yielding a 96-bit per-record sequence number. Or 
> something else.
>
> Please have another look. 
>
> Thanks,
> Chris
>
> On Wed, Oct 6, 2021, at 4:30 PM, Christopher Wood wrote:
>> On Tue, Oct 5, 2021, at 8:36 PM, Martin Thomson wrote:
>>> On Wed, Oct 6, 2021, at 12:58, Eric Rescorla wrote:
 This isn't dispositive, but note that TLS 1.3 doesn't include the epoch 
 in its nonce at all. 
>>>
>>> That strengthens the gut instinct some, as does the fact that QUIC 
>>> doesn't either.  But neither of those protocols is exactly the same as 
>>> DTLS.  DTLS doesn't place a hard end on any given epoch.  TLS does.  
>>> QUIC's continuous packet number space creates a hard limit, even if 
>>> that limit isn't a single value.  That suggests that some analysis 
>>> would be helpful.
>>>
>>> I'm less concerned about analysis than I am about getting the 
>>> specification bit right.
>>
>> FWIW, the intent of the change was to indeed truncate the epoch, as 
>> this is the variant that seems safest. I think you caught a couple 
>> places where that wasn't captured quite right, which we can fix.
>>
>> Best,
>> Chris
>>
>> ___
>> 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

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

Re: [TLS] Artart last call review of draft-ietf-tls-external-psk-guidance-03

[Christopher Wood]

Thanks, Martin! I agree with your point about the external PSK. I filed this 
issue to track its resolution:

   https://github.com/tlswg/external-psk-design-team/issues/76

I'll discuss the larger redundancy concern with the authors and see if there 
are some quick fixes to be made.

Best,
Chris

On Wed, Nov 3, 2021, at 5:27 PM, Martin Thomson via Datatracker wrote:
> Reviewer: Martin Thomson
> Review result: Ready with Issues
>
> This document addresses some of the less obvious aspects of how pre-shared 
> keys
> can be used in TLS.  A lot of this advice isn't specific to TLS, but it is a
> helpful document.  For someone who might be deploying a protocol that relies 
> on
> TLS - or might rely on it - the document is a useful resource.
>
> My only concern overall, and it is a vague concern, so I don't think action is
> needed, is that the document could probably use a little trimming.  There are
> some parts of the document that are less useful than other parts.  For 
> example,
> the bit about who has the PSKs is great (one server, one client, don't swap
> roles); but it is repeated a little across multiple sections.  The same 
> applies
> to a few of the other points.  It is probably not worth trying to edit the
> document down so that each point is made just once, because it isn't that bad,
> but a shorter document would be more impactful.
>
> A specific concern is the somewhat offhand way that early data is treated.  
> The
> only mention is in a throwaway: "primarily for the purposes of supporting TLS
> connections with early data" buried in a bullet in Section 6.  This is a 
> pretty
> big topic and having absolutely no mention seems odd.  I do think that it 
> needs
> some treatment in the document.  When early data is used with an external PSK,
> the only additional source of entropy that provides key diversity is the
> client's random value, which puts a lot of weight on that value containing
> sufficient entropy.  In this case, even if the PSK is good enough, the entropy
> in the random is significant as it is what ensures traffic key diversity if 
> the
> PSK is reused.  Reusing a PSK for early data also likely leads to poor
> anti-replay performance if the random is not good enough.
>
> I have to apologize to the authors for missing this when it went through the
> working group.  Fresh eyes and all that.

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

Re: [TLS] Question regarding RFC 7366

[John Mattsson]

I think the best way to think about AEAD from a protocol standpoint is as an 
interface. This is especially true for TLS where there are algorithms like 
TLS_SHA256_SHA256 for the AEAD interface that do not do encryption. A TLS 
cipher suite either use the AEAD interface or it does not.

Cheers,
John

From: TLS  on behalf of Peter Gutmann 

Date: Thursday, 4 November 2021 at 07:37
To: alex.sch...@gmx.de , tls@ietf.org 
Subject: Re: [TLS] Question regarding RFC 7366
alex.sch...@gmx.de  writes:

>I would really appreciate a response to get some clarification on what the
>intended interpretation is, i.e., when the extension should be used.

There's not really any contradiction, encrypt-then-MAC has nothing to do with
AEAD which is an all-in-one mode, so it doesn't apply to any AEAD cipher.

Peter.

___
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] Question regarding RFC 7366

[Peter Gutmann]

alex.sch...@gmx.de  writes:

>I would really appreciate a response to get some clarification on what the
>intended interpretation is, i.e., when the extension should be used.

There's not really any contradiction, encrypt-then-MAC has nothing to do with
AEAD which is an all-in-one mode, so it doesn't apply to any AEAD cipher.

Peter.

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

Re: [TLS] tls@ietf112

[Martin Thomson]

Hey Sean, what is "Zero-Knowledge Proofs meet TLS"?  I can't find a draft and 
the link in the agenda is busted.

On Wed, Oct 20, 2021, at 06:46, Sean Turner wrote:
> Hi! We have a meeting time scheduled for Tuesday, 9 November 2021 from 
> 1600-1800 (UTC). Please send in your agenda topics along with how much 
> time you think you will need to tls-cha...@ietf.org by 26 October 2021 
> (early is better).
>
> Cheers
> Chris, Joe, and Sean
> ___
> 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