Viktor Dukhovni writes:
>I am tacitly assuming that the implementation community might be somewhat
>more pragmatic than the WG, and be willing to improve the behaviour of the
>current extension, or perhaps the "silent majority" of the WG would in fact
>be willing be more pragmatic on resumption,
On Wed, Mar 08, 2023 at 05:11:27AM +, Peter Gutmann wrote:
> I think a safer option moving forward is "scrap it and order a new one", just
> do an RFC with a new, single extension with unambiguous semantics that
> reintroduces the TLS classic session resumption, but done with TLS 1.3
>
Viktor Dukhovni writes:
>The protocol specification needs to say something along the lines of:
I'm not sure if this will work though. The PSK stuff is already the second
biggest dog's breakfast in the spec (why are there two extensions used to
communicate PSK information, with complex
On Tue, Mar 7, 2023 at 6:51 PM Viktor Dukhovni
wrote:
> What specific changes would you recommend in say the OpenSSL
> implementation? Just not sending the useless tickets? Fine, we've
> saved a bit of bandwidth, but haven't really solved the problem.
>
I don't know the details of the OpenSSL
On Tue, Mar 07, 2023 at 03:49:13PM -0800, Nick Harper wrote:
> It is interoperable by default, if the implementations follow the spec. If
> implementations don't follow the spec, no amount of spec language will fix
> their behavior.
What specific changes would you recommend in say the OpenSSL
On Tue, Mar 7, 2023 at 6:50 AM Viktor Dukhovni
wrote:
> On Mon, Mar 06, 2023 at 11:18:50PM -0800, Nick Harper wrote:
>
> > > Basically, one way or another, PSK key exchange mode negotiation needs
> > > to be interoperable by default.
> >
> > Based on your first message, it sounds like you have
On Mon, Mar 06, 2023 at 11:18:50PM -0800, Nick Harper wrote:
> > Basically, one way or another, PSK key exchange mode negotiation needs
> > to be interoperable by default.
>
> Based on your first message, it sounds like you have identified an
> implementation where it is not interoperable. All
On Mon, Mar 6, 2023 at 9:30 PM Viktor Dukhovni
wrote:
> On 6 Mar 2023, at 8:13 pm, Peter Gutmann
> wrote:
>
> > Not really sure how to fix this, although at the moment "stay with TLS
> > classic" seems to be the preferred option.
>
> There are three stages of fixes:
>
> 1. Update the protocol
On 6 Mar 2023, at 8:13 pm, Peter Gutmann wrote:
> Not really sure how to fix this, although at the moment "stay with TLS
> classic" seems to be the preferred option.
There are three stages of fixes:
1. Update the protocol specification.
2. Fix the implementations.
3. Keep using TLS 1.2 until
Viktor Dukhovni writes:
>I took a look at whether it is practically possible for a client to "opt-in"
>to (ostensibly cheaper) non-DHE TLS 1.3 resumption by sending a
>"psk_key_exchange_modes" extension consisting of just "psk_ke".
>
>Turns out that at least when the server is OpenSSL, the
I took a look at whether it is practically possible for a client to
"opt-in" to (ostensibly cheaper) non-DHE TLS 1.3 resumption by sending a
"psk_key_exchange_modes" extension consisting of just "psk_ke".
Turns out that at least when the server is OpenSSL, the client is likely
to be sad.
Details
11 matches
Mail list logo
