Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Loganaden Velvindron]

Peter,

I'm curious. Are those embedded devices or IoT type of appliances
where the firmware has a TLS
library that will never be updated ?


On Tue, 12 Dec 2023 at 05:30, Peter Gutmann  wrote:
>
> Rob Sayre  writes:
>
> >>Given that TLS 1.2 will be around for quite some time
> >Not clear.
>
> Absolutely clear.  I work with stuff with 20-30 year deployment and life
> cycles.  I'm fairly certain TLS 1.2 will still be around when the WebTLS world
> is debating the merits of TLS 1.64 vs. TLS 1.65.
>
> (This is also why the TLS-LTS draft was created, BTW).
>
> 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] Adoption call for 'TLS 1.2 Feature Freeze'

[Viktor Dukhovni]

On Mon, Dec 11, 2023 at 07:51:13PM -0800, Rob Sayre wrote:

> > Absolutely clear.  I work with stuff with 20-30 year deployment and
> > life cycles.  I'm fairly certain TLS 1.2 will still be around when
> > the WebTLS world is debating the merits of TLS 1.64 vs. TLS 1.65.
> 
> I have to say, I am skeptical of this claim. The reason being that you
> don't really want 20 year old computers connected directly to local
> ethernet without a bridge.

Did Peter say anything about (general purpose) computers or connections
to the "local ethernet" (or Internet)?  Suppose you have a control
system for a ship, an factory floor, or a nuclear power plant.

How often would one want to perform major software updates that
substantially change aspects of the system design?  What is the expected
lifetime of such systems?

Since Peter has been addressing market needs in that space for some
decades, I'd be inclined to take him at his word...

Again, it may well be that he does not have a compelling case for
ongoing TLS working-group processes to enhance TLS 1.2, or he may yet.

Peter, is there anything beyond TLS-TLS that you're looking to see work
on?  Is the issue foreclosing on opportunities to do anticipated
necessary work, or is it mostly that the statement that the work can't
happen causing disruption with audits and other bureaucratic issues?

-- 
Viktor.

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

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

[Sean Turner]

I am going to go ahead and forward this. Note that since the “Comments” column 
isn’t a thing until we get 8447bis through the door the note will follow.

spt

> On Dec 6, 2023, at 14:46, Sean Turner  wrote:
> 
> Okay a new proposal the ech_outer_extensions registration:
> - Set "TLS 1.3" column to “CH”
> - Include the following note in our new “Comments” column [0]: "Only appears 
> in inner CH."
> 
> spt
> 
> [0] PRs:
> https://github.com/tlswg/rfc8447bis/pull/48
> https://github.com/tlswg/rfc8447bis/pull/49
> 
>> On Nov 29, 2023, at 16:09, Stephen Farrell  wrote:
>> 
>> 
>> Hiya,
>> 
>> On 27/11/2023 14:35, Sean Turner wrote:
>>> Bumping this up in case anybody missed it.
>> 
>> 'case it helps, I'm fine with the original mail you sent and any of
>> "n/a" or "CH" being used rather than "-". If it helps, I've a very
>> minuscule hint of a preference for "CH" so you can count me as agreeing
>> with MT.
>> 
>> But I won't object to any other thing, 'cause I don't think there's a
>> perfect answer, and it matters very little, and defining a new thing
>> like "CHI" just for this seems OTT, but meh, I could even live with
>> that too.
>> 
>> I'd also be fine with this just left to chair/editor discretion FWIW.
>> While it's good to bring things like that to the list, I don't
>> think you need to delay based on a small-ish set of responses.
>> 
>> Cheers,
>> S.
>> 
>> 
>> 
>>> 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 mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Peter Gutmann]

Rob Sayre  writes:

>>Given that TLS 1.2 will be around for quite some time
>Not clear.

Absolutely clear.  I work with stuff with 20-30 year deployment and life
cycles.  I'm fairly certain TLS 1.2 will still be around when the WebTLS world
is debating the merits of TLS 1.64 vs. TLS 1.65.

(This is also why the TLS-LTS draft was created, BTW).

Peter.


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

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Peter Gutmann]

Watson Ladd  writes:

>How does a feature freeze make it impossible to keep supporting TLS 1.2 as
>is?

Because if there's some tweak required for some reason (I don't know what that
could be since I can't predict the future) the draft seems to prohibit it.

Peter.

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

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Watson Ladd]

On Mon, Dec 11, 2023 at 5:15 PM Peter Gutmann  wrote:
>
> In all the rush to jump on the bandwagon, no-one has yet answered the question
> I posed earlier: For anyone who's already moved to TLS 1.3 the draft is
> irrelevant, and for people who have to keep supporting TLS 1.2 gear more or
> less indefinitely it makes their job hard if not impossible.

How does a feature freeze make it impossible to keep supporting TLS 1.2 as is?

> So what's the
> point of this draft?  For TLS 1.3 it's just workgroup posturing which I don't
> have a problem with (I was on the PKIX WG for years, that was practically in
> their charter), but for ongoing TLS 1.2 use it's going to pointlessly make
> life difficult for anyone working in that area.
>
> Why is this draft even a thing?
>
> Peter.
>
> ___
> 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] Adoption call for 'TLS 1.2 Feature Freeze'

[Peter Gutmann]

In all the rush to jump on the bandwagon, no-one has yet answered the question
I posed earlier: For anyone who's already moved to TLS 1.3 the draft is
irrelevant, and for people who have to keep supporting TLS 1.2 gear more or
less indefinitely it makes their job hard if not impossible.  So what's the
point of this draft?  For TLS 1.3 it's just workgroup posturing which I don't
have a problem with (I was on the PKIX WG for years, that was practically in
their charter), but for ongoing TLS 1.2 use it's going to pointlessly make
life difficult for anyone working in that area.

Why is this draft even a thing?

Peter.

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

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Viktor Dukhovni]

On Mon, Dec 11, 2023 at 06:38:05PM -0500, David Benjamin wrote:

> Protocol changes generally require both client and server changes to take
> effect. Pre-existing deployments, by simply pre-existing, will not have
> those changes. If we add, say, post-quantum options for TLS 1.2, it will
> benefit zero existing TLS 1.2 deployments. If we add post-quantum options
> for TLS 1.3, it will benefit zero existing TLS 1.3 deployments. That's not
> why we make these changes. We make them to benefit *future* TLS
> deployments, e.g. when server operators update their software. Although it
> can be a slow progress, pre-existing deployments gradually cycle into
> updated deployments.

FWIW, I had already considered this, and in fact essentially agree with
this take on the tradeoffs.  My point is mainly that there is legitimate
room for some diversity of opinion.

As you noted in your response, the PKCS1 barrier to TLS 1.3 adoption
that might be holding back some operators will be addressed.  Another,
that likely won't is that negotiation of "psk_ke" is particularly
brittle in TLS 1.3, and in constrained environments DH on every
resumption could be problematic.

My personal list of pain points is short, others can probably think of a
few more.  I actually don't object to the draft.  Rather, perhaps
"over", reacting to Rob's apparent negative reaction to posing the
question of whether the draft was *necessary*.

-- 
Viktor.

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

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[David Benjamin]

I don't think that quite captures the tradeoffs. Sure, TLS 1.2 will be
around for quite some time, but that *does not mean it is worth adding new
features to TLS 1.2*. Those two statements are not directly related.

Protocol changes generally require both client and server changes to take
effect. Pre-existing deployments, by simply pre-existing, will not have
those changes. If we add, say, post-quantum options for TLS 1.2, it will
benefit zero existing TLS 1.2 deployments. If we add post-quantum options
for TLS 1.3, it will benefit zero existing TLS 1.3 deployments. That's not
why we make these changes. We make them to benefit *future* TLS
deployments, e.g. when server operators update their software. Although it
can be a slow progress, pre-existing deployments gradually cycle into
updated deployments.

So when we decide whether to make a change to TLS 1.2 or TLS 1.3, the
pre-existing deployments of both protocols are irrelevant. What matters is
what will be used in new TLS software. At this point, now that TLS 1.3 is
well-established, we should broadly expect new TLS software to be
TLS-1.3-capable. Thus is it not worth our time to backport such changes to
TLS 1.2. When I say "our", I don't mean just this working group, but also
TLS implementers, application software that configures TLS implementations,
and server operators who must somehow navigate the sea of options that
comes from everyone else's indecision. Together, those costs are
significant.

More than that, we (the WG) should communicate this expectation. We did it
once by publishing RFC 8446 and obsoleting RFC 5246. hence this document.
But communication is hard, and now that the expectation is stronger, we
should repeat it more strongly. There will always be stragglers and
misunderstandings. Perhaps some more obscure TLS implementation has yet to
implement TLS 1.3. (Or DTLS 1.3.) Perhaps some application has a hardcoded
TLS 1.2 setting that needs to be updated. Perhaps some config files are
stale.

Publishing this document helps clear up what was already the WG's
expectation. If it reminds a chunk of those folks to move to TLS 1.3, it
will have been worthwhile. That is also why mentioning PQC is valuable, as
it is the extension that is most likely to be on server operators' minds.

Finally, communicating this is useful to us. Perhaps some new deployments
are TLS 1.2 not out of inertia, but because something in TLS 1.3
inadvertently made migration difficult for those folks. In that case, us
publishing this document helps invite such feedback. For example,
draft-ietf-tls-tls13-pkcs1 addresses a migration challenge. (That specific
example long predates this and, judging by the list discussion in 2019, it
was perhaps a little ahead of its time, but we all got there eventually.
:-D)

This has nothing to do with raising the floor. This is about not bothering
to start a new, shorter tower on the side while we raise the main ceiling.

On Mon, Dec 11, 2023, 16:58 Viktor Dukhovni  wrote:

> On Mon, Dec 11, 2023 at 12:32:36PM -0800, Rob Sayre wrote:
>
> > PS - I have to say, not in this message, but sometimes it seems like the
> > goal of TLS 1.2 advocates is weaker encryption. So, for them, the flaws
> in
> > TLS 1.2 that the draft describes are desirable. If that's the case,
> > participants are not working toward the same goal. Writing down the
> > consensus seems worth it.
>
> For what it is worth, my agenda/perspective has never been to weaken
> encryption.  Rather, it has always been about making usable encryption
> ubiquitous.  While we continue work on raising the ceiling, one can be
> legitimately weary of raising the floor so high that encryption is
> unusable, and communication happens in the clear instead.
>
> Given that TLS 1.2 will be around for quite some time, it is not obvious
> that a feature freeze will in practice improve security.  It is good
> that there's ongoing effort to make TLS 1.3 better, and I accept that it
> may well not be possible to deliver on required TLS 1.3 work and to also
> make some occasional modest improvements to TLS 1.2, but if the goal is
> to deliver secure products to users, a realist might accept that TLS 1.2
> is likely to continue to be used for some time, and that those users
> could be better served if some improvements continued to take place.
>
> The contrarian possition of course assumes that such improvements
> wouldn't be a significant drain on scarce resources.  That assumption is
> a matter for debate, and the "right" trade-offs are not completely
> obvious.  Some difference of perspectives can be expected.
>
> Whatever else we do, we should not default to questioning the motives of
> others who would make somewhat different tradeoffs.  Worry more when
> everyone is in violent agreement, perhaps something is then being
> missed.
>
> --
> Viktor.
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Viktor Dukhovni]

On Mon, Dec 11, 2023 at 02:40:41PM -0800, Rob Sayre wrote:

> > Given that TLS 1.2 will be around for quite some time
> 
> Not clear.

As a data point, I've had no luck so far with encouraging the email
operators of domain-registry.bg to upgrade their primary MX from TLS 1.0
to at least TLS 1.2. :-(

> I don't think anyone did that (including me). The question is whether the
> IETF should state that continuing work on TLS 1.2 is not worth doing.

Indeed that's the question, but there's a spectrum of choices.  One
choice is to preclude such work now.  Another is to swiftly decline
non-compelling proposals as they come up.

If there is indeed a sufficient stream of new distracting proposed TLS
1.2 tweaks then perhaps closing the gate is well motivated.  If the
volume of proposals is sufficiently low, there's no need to solve
non-problems.  Somewhere in between it can be difficult to know which is
the right choice, but we can but do our best.

-- 
Viktor.

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

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Rob Sayre]

Viktor Dukhovni  wrote:
> For what it is worth, my agenda/perspective has never been to weaken
encryption.

Right, I wrote that your message was not something that advocated weakened
encryption.

> Given that TLS 1.2 will be around for quite some time

Not clear.

> Whatever else we do, we should not default to questioning the motives of
others

I don't think anyone did that (including me). The question is whether the
IETF should state that continuing work on TLS 1.2 is not worth doing.

There are drafts that champion TLS 1.2 flaws in the name of
"observability". So, it's easy to understand that not everyone agrees here.
That's why I think it's best to document the IETF consensus.

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

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Viktor Dukhovni]

On Mon, Dec 11, 2023 at 12:32:36PM -0800, Rob Sayre wrote:

> PS - I have to say, not in this message, but sometimes it seems like the
> goal of TLS 1.2 advocates is weaker encryption. So, for them, the flaws in
> TLS 1.2 that the draft describes are desirable. If that's the case,
> participants are not working toward the same goal. Writing down the
> consensus seems worth it.

For what it is worth, my agenda/perspective has never been to weaken
encryption.  Rather, it has always been about making usable encryption
ubiquitous.  While we continue work on raising the ceiling, one can be
legitimately weary of raising the floor so high that encryption is
unusable, and communication happens in the clear instead.

Given that TLS 1.2 will be around for quite some time, it is not obvious
that a feature freeze will in practice improve security.  It is good
that there's ongoing effort to make TLS 1.3 better, and I accept that it
may well not be possible to deliver on required TLS 1.3 work and to also
make some occasional modest improvements to TLS 1.2, but if the goal is
to deliver secure products to users, a realist might accept that TLS 1.2
is likely to continue to be used for some time, and that those users
could be better served if some improvements continued to take place.

The contrarian possition of course assumes that such improvements
wouldn't be a significant drain on scarce resources.  That assumption is
a matter for debate, and the "right" trade-offs are not completely
obvious.  Some difference of perspectives can be expected.

Whatever else we do, we should not default to questioning the motives of
others who would make somewhat different tradeoffs.  Worry more when
everyone is in violent agreement, perhaps something is then being
missed.

-- 
Viktor.

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

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Rob Sayre]

Viktor Dukhovni  wrote:
> I do however wonder why this requires a draft formalising the stance?
> [...]
> Is the draft actually necessary?

It is a good way to avoid continually discussing the matter. So, yes, it
will save time: by documenting IETF consensus.

thanks,
Rob

PS - I have to say, not in this message, but sometimes it seems like the
goal of TLS 1.2 advocates is weaker encryption. So, for them, the flaws in
TLS 1.2 that the draft describes are desirable. If that's the case,
participants are not working toward the same goal. Writing down the
consensus seems worth it.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Viktor Dukhovni]

On Wed, Dec 06, 2023 at 12:33:52AM -0500, Deirdre Connolly wrote:

> At the TLS meeting at IETF 118 there was significant support for the draft
> 'TLS 1.2 is in Feature Freeze' (
> https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/)  This call
> is to confirm this on the list.  Please indicate if you support the
> adoption of this draft and are willing to review and contribute text. If
> you do not support adoption of this draft please indicate why.  This call
> will close on December 20, 2023.

I take no issue with the WG declining to do further non-emergency work
on TLS 1.2, if that promotes best use of scarce WG cycles.

I do however wonder why this requires a draft formalising the stance?
The simplest way to not do non-emergency work on TLS 1.2 seems to me to
not do non-emergency work on TLS 1.2.  Is the draft actually necessary?

Would not working on the draft save even more cycles?

-- 
Viktor.

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

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Russ Housley]

John:
> 
> But now when I look at TS 33.222 personally, I see that Section 5.3 actually 
> uses HTTP Digest for the Shared key-based client authentication, not TLS PSK 
> authentication.

Thanks for getting back to me on this.

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

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Arnaud Taddei]

Ditto +1 to Rich

From: TLS  on behalf of Bas Westerbaan 

Date: Monday, 11 December 2023 at 18:21
To: Salz, Rich 
Cc: Hannes Tschofenig , 
TLS@ietf.org 
Subject: Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'
The draft itself is an exercise in clear communication, and mentioning PQC 
explicitly fits with that.  Thus I agree with Rich to keep it.

Best,

 Bas

On Mon, Dec 11, 2023 at 6:18 PM Salz, Rich 
mailto:rs...@akamai.com>> wrote:
· that is implied by a "feature freeze". No reason to highlight PQC 
(even though it is a hype topic right now).

Yes, to both of these.  But I still think it should be explicitly called out.  
If the WG thinks otherwise, then fine, the document is that much shorter :)

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.


smime.p7s
Description: S/MIME Cryptographic Signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Bas Westerbaan]

The draft itself is an exercise in clear communication, and mentioning PQC
explicitly fits with that.  Thus I agree with Rich to keep it.

Best,

 Bas

On Mon, Dec 11, 2023 at 6:18 PM Salz, Rich  wrote:

>
>- that is implied by a "feature freeze". No reason to highlight PQC
>(even though it is a hype topic right now).
>
> Yes, to both of these.  But I still think it should be explicitly called
> out.  If the WG thinks otherwise, then fine, the document is that much
> shorter :)
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Salz, Rich]

  *   that is implied by a "feature freeze". No reason to highlight PQC (even 
though it is a hype topic right now).

Yes, to both of these.  But I still think it should be explicitly called out.  
If the WG thinks otherwise, then fine, the document is that much shorter :)
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Watson Ladd]

On Tue, Dec 5, 2023, 9:34 PM Deirdre Connolly 
wrote:

> At the TLS meeting at IETF 118 there was significant support for the draft
> 'TLS 1.2 is in Feature Freeze' (
> https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/)  This
> call is to confirm this on the list.  Please indicate if you support the
> adoption of this draft and are willing to review and contribute text. If
> you do not support adoption of this draft please indicate why.  This call
> will close on December 20, 2023.
>

I support adoption and can review.

>
> Thanks,
> Deirdre, 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

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Hannes Tschofenig]

Hi Rich,


that is implied by a "feature freeze". No reason to highlight PQC (even
though it is a hype topic right now).


Ciao

Hannes


Am 11.12.2023 um 17:18 schrieb Salz, Rich:


  * I consider Section 3 "Implications for post-quantum cryptography"
misplaced. I suggest to delete the section
  * The motivation for the draft is unrelated to developments with PQC.

The point is to explain to people that we are going to need PQ crypto,
and it **will not be a 1.2 enhancement**


___
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] Adoption call for 'TLS 1.2 Feature Freeze'

[Salz, Rich]

  *   I consider Section 3 "Implications for post-quantum cryptography" 
misplaced. I suggest to delete the section
  *   The motivation for the draft is unrelated to developments with PQC.

The point is to explain to people that we are going to need PQ crypto, and it 
*will not be a 1.2 enhancement*


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

Re: [TLS] Privacy and PSK identifiers (was Re: Call to Move RFC 8773 from Experimental to Standards Track)

[John Mattsson]

Thanks Christian,

I think all of the suggested solutions are viable with different tradeoffs. 
Actually, I think it is hard to find special cases where none of the solutions 
work.

>One approach is to encrypt the PSK identifier using the public key of
>the destination. That works nicely if we suppose that the clients have
>somehow acquired that public key, maybe using a setup similar to ECH.
>But it supposes that the encrypted result is reasonably short so it can
>fit in the Client Hello without blowing its size. I am concerned that
>this will not work well using post quantum public keys.

If you distribute the external PSK, I think you can distribute a public key as 
well. If the external PSK is derived that is trickier as the client has to 
fetch it from e.g., DNS. The size of ECIES is 32 bytes for the public key + 
overhead for the tag and a few bytes for any encoding overhead. I don't think 
quantum-resistance should be a excuse to not do anything. Using ECIES is much 
much better than sending the psk identifier in cleartext.

>Another approach would be to use symmetric key cryptography. Of course,
>we cannot really assume that random clients will have access to the
>encryption key chosen by the server. But we could have a system in which
>clients are provisioned with a set of equivalent encrypted identifiers.
>That approach works for Session Resumption Tickets. They are provisioned
>by the server, and the best practice is for client to use them only
>once. The downside is that this encryption typically uses Session Ticket
>Encryption Keys that are short lived and frequently rotated. That's a
>good fit for session resumption, but not so much for long term PSK.

In many systems you can replace the external PSK quite often. In 3GPP the 
external PSK used in TLS are refreshed every week.

>If neither STEK nor public keys are adequate, we could use trial
>encryption. Encrypt the PSK-ID using the PSK, and let the server do
>trial decryption by going through the list of provisioned PSK. Your
>guess as to whether this is acceptable is as good as mine.

You can trial decrypt (symmetic crypto) quite many PSK-ID using the same number 
of cycles as an asymmetric signature. But if the server needs to fetch the PSKs 
from a database it might be problematic.

I think mentioning that you can encrypt the PSK identifier and that the server 
can do trial decryption would be very good additions to Section C.4 of 
RFC8446bis that discusses tracking.

Cheers,
John Preuß Mattsson

From: TLS  on behalf of Christian Huitema 

Date: Friday, 8 December 2023 at 21:25
To: John Mattsson , Russ Housley 

Cc: IETF TLS 
Subject: [TLS] Privacy and PSK identifiers (was Re: Call to Move RFC 8773 from 
Experimental to Standards Track)
On 12/8/2023 6:57 AM, John Mattsson wrote:
> That seems like a good start. I think it would be good the TLS WG came
> up with additional guidelines/mechanisms/requirements for doing External
>   PSK in a secure way that does not enable tracking. Using the same
> External PSK identifier for a long time should be discouraged. Maybe ECH
>   is the solution. That would however be outside the scope of RFC 8773.

I spent a lot of time studying a related problem with DNSSD. It is very
hard, and we could only find partial solutions.

One approach is to encrypt the PSK identifier using the public key of
the destination. That works nicely if we suppose that the clients have
somehow acquired that public key, maybe using a setup similar to ECH.
But it supposes that the encrypted result is reasonably short so it can
fit in the Client Hello without blowing its size. I am concerned that
this will not work well using post quantum public keys.

Another approach would be to use symmetric key cryptography. Of course,
we cannot really assume that random clients will have access to the
encryption key chosen by the server. But we could have a system in which
clients are provisioned with a set of equivalent encrypted identifiers.
That approach works for Session Resumption Tickets. They are provisioned
by the server, and the best practice is for client to use them only
once. The downside is that this encryption typically uses Session Ticket
Encryption Keys that are short lived and frequently rotated. That's a
good fit for session resumption, but not so much for long term PSK.

If neither STEK nor public keys are adequate, we could use trial
encryption. Encrypt the PSK-ID using the PSK, and let the server do
trial decryption by going through the list of provisioned PSK. Your
guess as to whether this is acceptable is as good as mine.

-- Christian Huitema

___
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] Call to Move RFC 8773 from Experimental to Standards Track

[John Mattsson]

Hi Russ,

Seem like good suggested updates.

Russ Housley wrote:
>Can you point me to the 3GPP document that makes use of RFC 8773?  It should 
>probably be referenced in Section 3.1 >as another example along with 
>[I-D.ietf-emu-bootstrapped-tls].

Hi, Section 5.3 of TS 33.222 specifies "Shared key-based UE authentication with 
certificate-based NAF authentication". Other sections specified “Shared 
key-based mutual authentication” and “Certificate based mutual”. It was 
recently discussed in 3GPP if 5.3 should be updated to refer to RFC 8773.

But now when I look at TS 33.222 personally, I see that Section 5.3 actually 
uses HTTP Digest for the Shared key-based client authentication, not TLS PSK 
authentication. Must have been some misunderstanding. 3GPP does not use RFC 
8773.

Cheers,
John Preuß Mattsson

From: Russ Housley 
Date: Friday, 8 December 2023 at 20:08
To: John Mattsson 
Cc: IETF TLS 
Subject: Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track
John:

Thanks for you thoughtful review.

Russ Housley wrote:
>   Appendix E.6 of [RFC8446] discusses identity-exposure attacks on
>   PSKs.  Also, Appendix C.4 of [I-D.ietf-tls-rfc8446bis] discusses
>   tracking prevention.  The guidance in these sections remain relevant.
>
>   If an external PSK identity is used for multiple connections, then an
>   observer will generally be able track clients and/or servers across
>   connections.  The rotation of the external PSK identity or the use of
>   the Encrypted Client Hello extension [I-D.ietf-tls-esni] can mitigate
>   this risk.

That seems like a good start. I think it would be good the TLS WG came up with 
additional guidelines/mechanisms/requirements for doing External PSK in a 
secure way that does not enable tracking. Using the same External PSK 
identifier for a long time should be discouraged. Maybe ECH is the solution. 
That would however be outside the scope of RFC 8773.

Some additional comments on RFC8773(bis):

- I think the abstact and introduction should talk about client authentication 
as well. Right now it only talks about server authentication. The external PSK 
provides both client and server authentication. The 3GPP use case for RFC 8773 
is to use certificates for the server authentication and PSK for the client 
authentication.

Can you point me to the 3GPP document that makes use of RFC 8773?  It should 
probably be referenced in Section 3.1 as another example along with 
[I-D.ietf-emu-bootstrapped-tls].

Suggested Abstract update:

   This document specifies a TLS 1.3 extension that allows TLS clients
   and servers to authenticate with a combination of a certificate and
   an external pre-shared key (PSK).

Suggested Introduction update:

   The TLS 1.3 [RFC8446] handshake protocol provides two mutually
   exclusive forms of server authentication.  First, the server can be
   authenticated by providing a signature certificate and creating a
   valid digital signature to demonstrate that it possesses the
   corresponding private key.  Second, the server can be authenticated
   by demonstrating that it possesses a pre-shared key (PSK) that was
   established by a previous handshake.  A PSK that is established in
   this fashion is called a resumption PSK.  A PSK that is established
   by any other means is called an external PSK.

   A TLS 1.3 server that is authenticating with a certificate may
   optionally request a certificate from the TLS 1.3 client for
   authentication as described in Section 4.3.2 of [RFC8446].

   This document specifies a TLS 1.3 extension permitting certificate-
   based authentication to be combined with an external PSK as an input
   to the TLS 1.3 key schedule.


- When RFC 8773 was published, we did not have ML-KEM and ML-DSA, now we do. I 
think RFC8773bis should explain how and why the solution with External PSK is 
needed now that we have ML-KEM and ML-DSA. Is it needed when we get standard 
track ML-KEM and ML-DSA? CNSA 2.0 seems to indicate that ML-KEM and ML-DSA is 
enough for TOP SECRET, but I know that some european governments like to always 
combine External PSK with asymmetric crypto just to be on the safe side and to 
always get PFS.

I suggest an additional paragraph in Section 3.1:

   Quantum-resistant public-key cryptographic algorithms are becoming
   standards, but it will take many years for TLS 1.3 ciphersuites that
   use these algorithms to be developed and deployed.  In some
   environments, deployment of a strong external PSK provides protection
   until these quantum-resistant algorithms are deployed.

Russ



Cheers,
John Preuß Mattsson

From: Russ Housley mailto:hous...@vigilsec.com>>
Date: Wednesday, 6 December 2023 at 21:51
To: John Mattsson 
mailto:john.matts...@ericsson.com>>
Cc: IETF TLS mailto:tls@ietf.org>>
Subject: Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track
John:

I respond to your three suggested changes below:

(1) How about a title of "TLS 1.3 Extension for Using Certi

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Dennis Jackson]

RFC 8773 S3:

> In the near term, this document describes a TLS 1.3 extension to 
protect today's communications from the future invention of a 
large-scale quantum computer by providing a strong external PSK as an 
input to the TLS 1.3 key schedule while preserving the authentication 
provided by the existing certificate and digital signature mechanisms.


I don't see anything specifically alarming about the design, but I'm 
very uncomfortable about any standards-track document making a strong 
security claim like this  if its not backed by some kind of formal 
analysis.


The document could also be a bit more explicit on the security 
properties it achieves and when e.g. that it breaks down once a 
large-scale QC is actually available, that clients & servers need to 
reject connections which do not negotiate the extension to actually 
benefit from its protection.


On the issue of tracking via external PSKs - it's easy to imagine a 
scheme where client and server divide time into epochs and derive 
per-epoch keys to prevent tracking between epochs. I'm sure there must 
be some prior art that could be referenced as a recommendation?


Best,
Dennis

On 29/11/2023 15:51, Joseph Salowey wrote:
RFC 8773 (TLS 1.3 Extension for Certificate-Based Authentication with 
an External Pre-Shared Key) was originally published as experimental 
due to lack of implementations. As part of implementation work for the 
EMU workitem draft-ietf-emu-bootstrapped-tls which uses RFC 8773 there 
is ongoing implementation work. Since the implementation status of RFC 
8773 is changing, this is a consensus call to move RFC 8773 to 
standards track as reflected in 
[RFC8773bis](https://datatracker.ietf.org/doc/draft-ietf-tls-8773bis). 
This will also help avoid downref for the EMU draft.  Please indicate 
if you approve of or object to this transition to standards track 
status by December 15, 2023.


Thanks,

Joe, Sean, and Deirdre

___
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] Adoption call for 'TLS 1.2 Feature Freeze'

[Dennis Jackson]

I support adoption, and am happy to review.

Best,
Dennis

On 06/12/2023 12:50, Salz, Rich wrote:


At the TLS meeting at IETF 118 there was significant support for the 
draft 'TLS 1.2 is in Feature Freeze' 
(https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/ 
) 
 This call is to confirm this on the list.  Please indicate if you 
support the adoption of this draft and are willing to review and 
contribute text. If you do not support adoption of this draft please 
indicate why.  This call will close on December 20, 2023.


As the co-author, I support this and am willing to continue working on 
it as needed.



___
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] Adoption call for 'TLS 1.2 Feature Freeze'

[Hannes Tschofenig]

I consider Section 3 "Implications for post-quantum cryptography"
misplaced. I suggest to delete the section


The motivation for the draft is unrelated to developments with PQC.


Ciao

Hannes



Am 11.12.2023 um 11:59 schrieb Bas Westerbaan:

I support adoption, and am happy to review.

Best,

 Bas

On Wed, Dec 6, 2023 at 6:34 AM Deirdre Connolly
 wrote:

At the TLS meeting at IETF 118 there was significant support for
the draft 'TLS 1.2 is in Feature Freeze'
(https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/)
 This call is to confirm this on the list.  Please indicate if you
support the adoption of this draft and are willing to review and
contribute text. If you do not support adoption of this draft
please indicate why.  This call will close on December 20, 2023.

Thanks,
Deirdre, 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] Adoption call for 'TLS 1.2 Feature Freeze'

[Bas Westerbaan]

I support adoption, and am happy to review.

Best,

 Bas

On Wed, Dec 6, 2023 at 6:34 AM Deirdre Connolly 
wrote:

> At the TLS meeting at IETF 118 there was significant support for the draft
> 'TLS 1.2 is in Feature Freeze' (
> https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/)  This
> call is to confirm this on the list.  Please indicate if you support the
> adoption of this draft and are willing to review and contribute text. If
> you do not support adoption of this draft please indicate why.  This call
> will close on December 20, 2023.
>
> Thanks,
> Deirdre, 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