In case helpful to a broader community supporting operations, I had posted this blog to a few places to encourage transition planning. It’s written at a higher level than discussions here with the intent of having the information accessible to a broader audience with other areas of expertise. It may have raised awareness of the need to transition to get quantum cryptography support. 

RSA:




APNIC:

Last week, the US put out an executive order with a transition date requirement of 2030 for TLSv1.3.

Best regards,
Kathleen 

Sent from my mobile device

On Jun 7, 2025, at 12:47 PM, Eric Rescorla <[email protected]> wrote:





On Sat, Jun 7, 2025 at 4:40 AM Peter Gutmann <[email protected]> wrote:
Eric Rescorla <[email protected]> writes:

>Under the assumption you mean "our customers", then those people are probably
>coming in via a Web browser. All modern Web browsers support TLS 1.3. If
>someone is coming in via a browser which doesn't support TLS 1.3, then it's
>because that browser isn't being updated, which means that it wouldn't get
>some hypothetical TLS 1.2 PQC update even if one existed.

And here again we have the standard TLS WG position that nothing exists
outside the web. Perhaps the group should be renamed to "TLS for the Web"
just to make it clear that that's the only thing that gets any consideration
here - there's not even any acknowledgement in the above that anything outside
the web exists.

Peter,

I don't think this is really a good faith reading of my message.

For those following along at home, here's the entire context, with
Edward's message and my response.


> > Here is the problem > say all our external endpoints are
> > communicating via TLS 1.3 ;our clients (which most of the times we
> > will not have control over) will need TLS 1.3 > if the client
> > doesn’t have tls 1.3 our communication will need to negotiate
> > /communicate with a lower protocol 1.2 perhaps?  If TLS 1.2 received
> > the new PQC algorithms then it will create less havoc on many
> > organizations just trying to communicate securely
>
> I'm not quite sure what you mean by "our clients" here. Are you talking
> about people or software? Under the assumption you mean "our customers",
> then those people are probably coming in via a Web browser. All modern
> Web browsers support TLS 1.3. If someone is coming in via a browser which
> doesn't support TLS 1.3, then it's because that browser isn't being updated,
> which means that it wouldn't get some hypothetical TLS 1.2 PQC update
> even if one existed.

So the context for my message is the following category of
endpoints:

    our clients (which most of the times we will not have control over)

This is a somewhat clearly unspecified set, and in the first sentence
(which you trimmed for some reason), I explicitly express some concern
about this ambiguity.. As is clear from this sentence and the
nextsentence where I say "Under the assumption", I'm trying to give it
a clear meaning, in this case that he means the customers. A bank's
retail customers typically talk to a bank via one of two mechanisms:

- The bank's app (which the bank *does* control, and so won't have
  the issue raised here)
- The Web

Commercial customers may well come in through some other kind of
client, though I imagine they also use the Web a lot, hence
*probably*.  I don't think any of this reveals some kind of attitude
that the Web is the only thing that matters, merely a recognition
that in *this* scenario it's in fact the main modality. Looking
backwards, it would have been good to more explicitly acknowledge
the app case, but of course from a technical perspective, those
are probably just Web APIs.

I'm of course aware that banks have partners they communicate with
and various kinds of partners via all sorts of non-Web mechanisms,
but, as above, the scope of this discussion is "clients".


> not even any acknowledgement in the above that anything outside
> the web exists.

And of course this is just false, as the word "probably" explicitly
acknowledges that there might be some other mechanism.

-Ekr





 
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to