Re: [TLS] TLS 1.3, Raw Public Keys, and Misbinding Attacks

in the certificate is actually used for anything. Ciao Hannes From: TLS On Behalf Of John Mattsson Sent: Thursday, March 28, 2024 4:22 PM To: TLS@ietf.org Subject: [TLS] TLS 1.3, Raw Public Keys, and Misbinding Attacks Hi, I looked into what RFC 8446(bis) says about Raw Public Keys. As correctly

Re: [TLS] TLS 1.3, Raw Public Keys, and Misbinding Attacks

Dennis beat me to making the key point about identity :) There are cases where identity misbinding is possible in similar systems. RFC 8844 describes one such case. However, this is not an inherent failing in TLS, but in the usage context. That weakness was not the result of using raw public

Re: [TLS] TLS 1.3, Raw Public Keys, and Misbinding Attacks

Hi John, It depends what you mean by an identity. TLS1.3 ensures the peers agree on the used RPKs and it doesn't rely on any external proof of possession to achieve that property. How the peers come to trust the RPKs or their corresponding identity is of necessity left to the application -

Re: [TLS] TLS 1.3, Raw Public Keys, and Misbinding Attacks

On Thu, Mar 28, 2024 at 03:22:05PM +, John Mattsson wrote: > I looked into what RFC 8446(bis) says about Raw Public Keys. As > correctly stated in RFC 8446, TLS 1.3 with signatures and certificates > is an implementation of SIGMA-I: Assuming certificates are issued with strong assurance,

Re: [TLS] TLS 1.3, Raw Public Keys, and Misbinding Attacks

On Thu, Mar 28, 2024 at 4:22 PM John Mattsson wrote: > Hi, > > > > I looked into what RFC 8446(bis) says about Raw Public Keys. As correctly > stated in RFC 8446, TLS 1.3 with signatures and certificates is an > implementation of SIGMA-I: > > > > SIGMA does however require that the identities of

[TLS] TLS 1.3, Raw Public Keys, and Misbinding Attacks

Hi, I looked into what RFC 8446(bis) says about Raw Public Keys. As correctly stated in RFC 8446, TLS 1.3 with signatures and certificates is an implementation of SIGMA-I: SIGMA does however require that the identities of the endpoints (called A and B in [SIGMA]) are included in the messages.

Re: [TLS] TLS 1.3 servers and psk_key_exchange_modes == [psk_ke]?

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,

Re: [TLS] TLS 1.3 servers and psk_key_exchange_modes == [psk_ke]?

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 >

Re: [TLS] TLS 1.3 servers and psk_key_exchange_modes == [psk_ke]?

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

Re: [TLS] TLS 1.3 servers and psk_key_exchange_modes == [psk_ke]?

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

Re: [TLS] TLS 1.3 servers and psk_key_exchange_modes == [psk_ke]?

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

Re: [TLS] TLS 1.3 servers and psk_key_exchange_modes == [psk_ke]?

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

Re: [TLS] TLS 1.3 servers and psk_key_exchange_modes == [psk_ke]?

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

Re: [TLS] TLS 1.3 servers and psk_key_exchange_modes == [psk_ke]?

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

Re: [TLS] TLS 1.3 servers and psk_key_exchange_modes == [psk_ke]?

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

Re: [TLS] TLS 1.3 servers and psk_key_exchange_modes == [psk_ke]?

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

[TLS] TLS 1.3 servers and psk_key_exchange_modes == [psk_ke]?

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

Re: [TLS] TLS 1.3 and certificate based authentication

TLS 1.3 supports certificate-based client auth in the primary handshake. -Ekr On Fri, Jan 14, 2022 at 8:19 AM Urmas Vanem wrote: > Hello! > > > > TLS 1.3 introduces post-handshake authentication. It relies on > client/browser, client/browser must send post_handshake_auth extension to > server

[TLS] TLS 1.3 and certificate based authentication

Hello! TLS 1.3 introduces post-handshake authentication. It relies on client/browser, client/browser must send post_handshake_auth extension to server before it can work. I hope I understood it correctly. But today we know only Firefox from popular browsers support this extension (and not by

[TLS] TLS 1.3 Authentication and Integrity only Cipher Suites

Internet-Draft "TLS 1.3 Authentication and Integrity only Cipher Suites" ( https://tools.ietf.org/html/draft-camwinget-tls-ts13-macciphersuites-08) highlights TLS use cases with authentication and integrity needs, without any need for confidentiality. The draft promotes mutual authentication, but

Re: [TLS] TLS 1.3 ECC Private Key Compromise? (was Re: Un-deprecating everything TLS 1.2)

On 10/6/20 19:11, Nick Harper wrote: I conclude that if this leads to some vulnerability, this implies the ECDHE algorithm (or its implementation), not the TLS handshake, is flawed. Thank you for the analysis! Mike ___ TLS mailing list TLS@ietf.org

Re: [TLS] TLS 1.3 ECC Private Key Compromise? (was Re: Un-deprecating everything TLS 1.2)

> > Please just tell me why I'm wrong and I'll feel > > better since we won't have to malign another cute > > furry animal. > I've told you already why I believe you're wrong here. At this point, it won't do much good to continue posting about this list on the list. My suggestion to you is to

[TLS] TLS 1.3 ECC Private Key Compromise? (was Re: Un-deprecating everything TLS 1.2)

[Resending this with a better Subject line. --Mike] On 10/6/20 16:11, I wrote: On 10/5/20 22:00, Christopher Patton wrote: I agree that the HRR code path is hard to reason about, but I don't really see an attack here. Is it your contention that the HRR code path leads to an attack not

Re: [TLS] TLS 1.3 Problem?

On 9/29/20 19:51, Martin Thomson wrote: It's symmetric crypto[1]. Hardly worth noting. [1] Mostly. NSS wraps the symmetric key with an asymmetric key so that server clusters can share session ticket encryption keys without needing interconnects. But encryption or decryption only happens once

Re: [TLS] TLS 1.3 Problem?

On Wed, Sep 30, 2020, at 01:14, Michael D'Errico wrote: > Also, are you sure you want to do this?  The design of > TLS 1.3 was supposed to make it fast, but creating a > pseudo session ticket for every connection requiring a > HRR and then validating and decoding it is going to be > really slow. 

Re: [TLS] TLS 1.3 Problem?

Michael D'Errico wrote: > > Since RFC 8446 obsoletes RFC 5246, this is a serious problem. > > How is this supposed to work?   Sorry but I did not follow the > development of TLS 1.3.  I felt that I was unwelcome in this > group by some of the "angry cryptographers" as I call them. The

Re: [TLS] TLS 1.3 Problem?

Dear Michael, On Tue, 29 Sep 2020 at 17:14, Michael D'Errico wrote: > OK, so it sounds like you put something similar to a > NewSessionTicket (TLS 1.2) in the cookie with enough > information to recreate the server state. Whilst getting to grips with TLS 1.3, I wrote a tutorial

Re: [TLS] TLS 1.3 Problem?

Is stateless HelloRetryRequest even being used? If so, how? NSS implements HRR this way always. We pack the necessary state for the connection to continue into the cookie (which is protected with an AEAD). We can also retain server state, in which case the retained state is compared

Re: [TLS] TLS 1.3 Problem?

On Tue, Sep 29, 2020, at 10:38, Watson Ladd wrote: > > Is stateless HelloRetryRequest even being used? If so, how? NSS implements HRR this way always. We pack the necessary state for the connection to continue into the cookie (which is protected with an AEAD). We can also retain server

Re: [TLS] TLS 1.3 Problem?

On Mon, Sep 28, 2020 at 3:33 PM Michael D'Errico wrote: > On Mon, Sep 28, 2020, at 11:07, Hannes Tschofenig wrote: > > > > Luckily, we don't have any angry cryptographers in this group. > > Were they all pushed away too? > I don't think this is very likely. The TLS list can get a bit

Re: [TLS] TLS 1.3 Problem?

On Mon, Sep 28, 2020 at 6:33 PM Michael D'Errico wrote: > > On Mon, Sep 28, 2020, at 11:07, Hannes Tschofenig wrote: > > > > Luckily, we don't have any angry cryptographers in this group. > > Were they all pushed away too? > > Anyway, back on the topic of stateless HelloRetryRequest, I > don't

Re: [TLS] TLS 1.3 Problem?

On Mon, Sep 28, 2020, at 11:07, Hannes Tschofenig wrote: > > Luckily, we don't have any angry cryptographers in this group. Were they all pushed away too? Anyway, back on the topic of stateless HelloRetryRequest, I don't see how this can work given that the client can make several modifications

Re: [TLS] TLS 1.3 Problem?

spec, see https://tools.ietf.org/html/rfc8446#appendix-D. Ciao Hannes -Original Message- From: TLS On Behalf Of Michael D'Errico Sent: Sunday, September 27, 2020 9:52 PM To: tls@ietf.org Subject: [TLS] TLS 1.3 Problem? Hi, Took a quick look at RFC 8446 and noticed that there

Re: [TLS] TLS 1.3 Problem?

On Sun, Sep 27, 2020, at 22:28, Michael D'Errico wrote: > > I'm afraid to keep reading In section 4, HandshakeType and Handshake are missing the value for the HelloRetryRequest message. Oh wait, never mind, it's the same value as ServerHello (?). Everything appears to be a hack within a

Re: [TLS] TLS 1.3 Problem?

The client is expected to adapt its behavior based on the negotiated version indicated in the ServerHello. If the server selects TLS 1.2, for example, then the client behaves as specified in RFC 5246. This is no different from previous version of TLS. --Richard On Sun, Sep 27, 2020 at 10:29 PM

Re: [TLS] TLS 1.3 Problem?

On Sun, Sep 27, 2020, at 16:53, Ben Smyth wrote: > The client will reject the server's ServerHello in your example. OK, so all eggs in one basket? I'm afraid to keep reading Mike ___ TLS mailing list TLS@ietf.org

Re: [TLS] TLS 1.3 Problem?

The client will reject the server's ServerHello in your example. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

[TLS] TLS 1.3 Problem?

Hi, Took a quick look at RFC 8446 and noticed that there is no definition of ServerKeyExchange or ServerHelloDone which are part of TLS 1.2 and prior.  A 1.3 client talking to a 1.2 or earlier server is likely going to receive both of these messages: RFC 5246  TLS

Re: [TLS] TLS 1.3 Document Update

If we wanted to go further, defining a new flag that says ‘use “main” as the prefix’ in the ClientHello? I agree that text indicating the interop requrements of master is useful. And then don’t obscure it. ___ TLS mailing list TLS@ietf.org

Re: [TLS] TLS 1.3 Document Update

Hi Ekr, this is great! I just wanted to suggest that, instead of obscuring the word "master", we add a (foot)note to the text explaining its persistence in the spec and give some historical context. Best, Chris P. On Tue, Aug 11, 2020 at 9:11 AM Eric Rescorla wrote: > Hi folks, > > I've just

Re: [TLS] TLS 1.3 and TCP interactions

I wonder if an extension could be used to signal the client's and server's ability to handle unexpected alerts. So, for example, if a client TLS implementation and the application using it can't handle new tickets, then don't send them. Of course, implementors should get advice about these

Re: [TLS] TLS 1.3 and TCP interactions

On Fri, May 29, 2020 at 7:28 PM Nico Williams wrote: > On Fri, May 29, 2020 at 06:35:58PM -0400, Watson Ladd wrote: > > In my experience the issues are thorniest when dealing with blocking > > sockets. Libraries using nonblocking sockets have to signal to the > > application that they want IO to

Re: [TLS] TLS 1.3 and TCP interactions

On Fri, May 29, 2020 at 8:06 PM Jeremy Harris wrote: > On 29/05/2020 22:52, David Benjamin wrote: > > On Fri, May 29, 2020 at 5:36 PM Jeremy Harris wrote: > > > >> On 29/05/2020 21:59, David Benjamin wrote: > >>> Moreover, in a client-speaks-first protocol, the error now comes after > >> the >

Re: [TLS] TLS 1.3 and TCP interactions

On Fri, May 29, 2020 at 04:59:57PM -0400, David Benjamin wrote: > > Half-RTT data > > We haven’t done much with half-RTT data outside of 0-RTT connections, but > half-RTT may risk similar issues. Half-RTT data in a client certificate > connection is sent before the server learns the client

Re: [TLS] TLS 1.3 and TCP interactions

On Fri, May 29, 2020 at 10:36:42PM +0100, Jeremy Harris wrote: > > Note (4) and (5) happen in parallel. Ideally ??? would be a bad_certificate > > alert, but it is sometimes a TCP reset. I’m not a TCP expert, but I believe > > this is because the client writes data (“GET / ...”) the server never

Re: [TLS] TLS 1.3 and TCP interactions

On 29/05/2020 22:52, David Benjamin wrote: > On Fri, May 29, 2020 at 5:36 PM Jeremy Harris wrote: > >> On 29/05/2020 21:59, David Benjamin wrote: >>> Moreover, in a client-speaks-first protocol, the error now comes after >> the >>> client has already sent its request. This is not only a behavior

Re: [TLS] TLS 1.3 and TCP interactions

On Fri, May 29, 2020 at 06:35:58PM -0400, Watson Ladd wrote: > In my experience the issues are thorniest when dealing with blocking > sockets. Libraries using nonblocking sockets have to signal to the > application that they want IO to happen during the handshake, and can > use that same mechanism

Re: [TLS] TLS 1.3 and TCP interactions

On Fri, May 29, 2020 at 5:01 PM David Benjamin wrote: > > Hi all, > > > As we’ve been using TLS 1.3 in more scenarios, we’ve encountered some > interesting interactions with TCP. We thought we’d document these and send a > note here. In general, we've found that TLS implementations need to be

Re: [TLS] TLS 1.3 and TCP interactions

On Fri, May 29, 2020 at 5:36 PM Jeremy Harris wrote: > On 29/05/2020 21:59, David Benjamin wrote: > > Moreover, in a client-speaks-first protocol, the error now comes after > the > > client has already sent its request. This is not only a behavior change > but > > makes it unreliable over TCP.

Re: [TLS] TLS 1.3 and TCP interactions

On 29/05/2020 21:59, David Benjamin wrote: > Moreover, in a client-speaks-first protocol, the error now comes after the > client has already sent its request. This is not only a behavior change but > makes it unreliable over TCP. TCP sees: > > >1. > >Client: write(ClientHello); >2.

[TLS] TLS 1.3 and TCP interactions

Hi all, As we’ve been using TLS 1.3 in more scenarios, we’ve encountered some interesting interactions with TCP. We thought we’d document these and send a note here. In general, we've found that TLS implementations need to be wary of post-handshake messages and “unexpected” transport writes. This

[TLS] TLS 1.3 PQ Cert Performance Study

Hi all, As the topic of PQ certs in TLS has been discussed in this forum a number of times, I wanted to bring up our paper (https://eprint.iacr.org/2020/071 ) that just appeared in NDSS 2020 for awareness. It evaluates the NIST PQ Signature candidates used in X.509 certificates for TLS 1.3

Re: [TLS] TLS 1.3 unsupported_extension vs illegal_parameter clarification

On Wednesday, 12 February 2020 19:46:01 CET, Daniel Van Geest wrote: Hi, I’m looking for some clarification on unsupported_extension vs illegal_parameter alerts in TLS 1.3. RFC 8446 says: If an implementation receives an extension which it recognizes and which is not specified for the

Re: [TLS] TLS 1.3 supported versions and downgrade protection

On Thu, Dec 5, 2019 at 12:36 PM Benjamin Kaduk wrote: > On Thu, Dec 05, 2019 at 05:30:10PM +, Daniel Van Geest wrote: > > Hi all, > > > > I think there might be ambiguity or an interoperability issue with the > TLS 1.3 ServerHello Random value downgrade protection and some (possibly?) >

Re: [TLS] TLS 1.3 supported versions and downgrade protection

On Thu, Dec 05, 2019 at 05:30:10PM +, Daniel Van Geest wrote: > Hi all, > > I think there might be ambiguity or an interoperability issue with the TLS > 1.3 ServerHello Random value downgrade protection and some (possibly?) > legitimate negotiation of TLS 1.2 using the supported_versions

[TLS] TLS 1.3 supported versions and downgrade protection

Hi all, I think there might be ambiguity or an interoperability issue with the TLS 1.3 ServerHello Random value downgrade protection and some (possibly?) legitimate negotiation of TLS 1.2 using the supported_versions extension. Looking through RFC 8446 and the mail archives I don’t see

[TLS] TLS 1.3 Extended Key Schedule

Hi TLSWG, Chris and I have put together a draft for adding extra key material into the TLS 1.3 handshake. There are various drafts that want to inject extra information into the key schedule, so it would be great if we could manage to do this in a generic way. You can have a look here

[TLS] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates

Hi, Please find attached a new version of the draft "TLS Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates". In the new version, we consider 1609.2 cert signing applicable for TLS 1.3 see section "5. Certificate Verification". In accordance with instructions from the

[TLS] TLS 1.3 in iOS

Hi all, Last week, we shipped the first developer seed of iOS 12.2. Among other features, TLS 1.3 is now enabled by default for the entire system. All users of Network.framework and NSURLSession APIs will now negotiate TLS 1.3. The number of TLS 1.3 capable clients on the Internet should take

Re: [TLS] TLS 1.3 updates from Chrome

Hi, Thanks for that interesting explanation. I just learned about another TLS 1.3 "intolerance" issue that people deploying it should be aware of: It seems some servers don't consider TLS 1.3 cipher suites as "safe" for HTTP/2 and this breaks connections:

[TLS] TLS 1.3 updates from Chrome

Dear all, The upcoming release of Google Chrome 70 is expected to enable the final version of TLS 1.3. As the release has progressed through our early release channels, we have learned about some deployment issues we would like to share with the community. First, we are aware of some intolerance

Re: [TLS] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates

Thank you Rus, I will correct it. Mounira - Mail original - De: "housley" À: "Mounira Msahli" Cc: "tls" Envoyé: Mardi 2 Octobre 2018 11:23:07 Objet: Re: [TLS] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates The docum

Re: [TLS] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates

Hi Ilari, >> - The construction looks like it mixes different kinds of structures: 1609.2 Data of type signed versus TLS 1.3 signature. I do not think this is cryptographically kosher. In fact, I think the call for "extreme care" for certain kinds of modifications from TLS 1.3

Re: [TLS] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates

The document says: /* Managed by IANA */ enum { X509(0), RawPublicKey(2), 1609Dot2(?), /* Number 3 will be requested for 1609.2 */ (255) 103097(?), /* Number 4 will be requested for 103097 */ (255) } CertificateType;

Re: [TLS] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates

On Wed, Sep 26, 2018 at 05:57:28PM +0200, Mounira Msahli wrote: > Hi all, > > Please find attached a new version of the draft. We took account of > pevious TLS group comments. William, editor of 1609.2, proposes to > add the section certificate verify (section 4.3 in the draft). > It concerns

Re: [TLS] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates

. We are soliciting your feedbacks. Regards Mounira - Mail original - De: "Hubert Kario" À: "tls" Cc: "Mounira Msahli" , "Ilari Liusvaara" Envoyé: Lundi 27 Août 2018 19:39:12 Objet: Re: [TLS] TLS 1.3 Authentication using ETSI TS 103 097 and I

Re: [TLS] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates

RFC 7250 >>> For the extension, TLS Client and Server Handshake Behavior shall be >>> specified for two TLS versions. Kind Regards Mounira - Mail original - De: "Hubert Kario" redhat.com> À: "tls" Cc: "Mounira Msahli" , "Ilari Liusvaara&q

Re: [TLS] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates

On Monday, 27 August 2018 19:24:34 CEST Mounira Msahli wrote: > One could abbrevate the handshake traces to just show the relevant > parts (which could also cut some clutter)? I think the relevant > messages always occur in the same order (clienthello, serverhello/ > encryptedextensions,

Re: [TLS] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates

" Envoyé: Lundi 27 Août 2018 18:37:50 Objet: Re: [TLS] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates On Mon, Aug 27, 2018, 8:21 AM Mounira Msahli < [ mailto:mounira.msa...@telecom-paristech.fr | mounira.msa...@telecom-paristech.fr ] > wrote: Hi

Re: [TLS] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates

agree with you about the rest of comments. Cheers Mounira - Mail original - De: "Ilari Liusvaara" À: "Mounira Msahli" Cc: "tls" Envoyé: Lundi 27 Août 2018 18:34:05 Objet: Re: [TLS] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2 cert

Re: [TLS] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates

ards > Mounira > > > > - Mail original - > De: "Hubert Kario" > À: "tls" > Cc: "Mounira Msahli" , "Ilari > Liusvaara" > Envoyé: Lundi 27 Août 2018 16:39:56 > Objet: Re: [TLS] TLS 1.3 Authentication using ETSI TS 103 097 and

Re: [TLS] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates

On Mon, Aug 27, 2018 at 06:21:15PM +0200, Mounira Msahli wrote: > Hi Hubert, > > I can do the exercise but the result will be two sections totally > decorrelated: one for TLS 1.3 and one for TLS 1.2. Two drafts in > one document. The certificate message might be bit annoying as it has different

Re: [TLS] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates

uses extension defined in [RFC7250]. Kind Regards Mounira - Mail original - De: "Hubert Kario" À: "tls" Cc: "Mounira Msahli" , "Ilari Liusvaara" Envoyé: Lundi 27 Août 2018 16:39:56 Objet: Re: [TLS] TLS 1.3 Authentication using ETSI

Re: [TLS] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates

On Friday, 24 August 2018 19:44:36 CEST Mounira Msahli wrote: > - You should also specify use in TLS 1.2 in the same draft (or say that > is prohibited). This is so one only needs one reference for the > codepoint allocation. > > >>> It is not prohibited, for TLS 1.2 the extension is already

Re: [TLS] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates

ificate, the other is the implicit > certificate. > > So for you draft submitted, you plan support both types of certificates or > just one of them, i.e. the X.509 certificate. > > Best regards. > > Haiguang > > -Original Message- > From: TLS [mailto:tls-boun...@ie

Re: [TLS] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates

Behalf Of Mounira Msahli Sent: Saturday, August 25, 2018 1:45 AM To: Ilari Liusvaara Cc: tls Subject: Re: [TLS] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates Thank you Ilari, In response to your comments below: - I did not see requirements where to place the e

Re: [TLS] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates

.509 certificate. Best regards. Haiguang -Original Message- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Mounira Msahli Sent: Saturday, August 25, 2018 1:45 AM To: Ilari Liusvaara Cc: tls Subject: Re: [TLS] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2

Re: [TLS] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates

t quite hard to read due to various editorial issues. >> We will update the draft Kind Regards Mounira - Mail original - De: "Ilari Liusvaara" À: "Mounira Msahli" Cc: "tls" Envoyé: Vendredi 24 Août 2018 17:50:38 Objet: Re: [TLS] TLS 1.3 Authent

Re: [TLS] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates

Hi William, Thank you for these details. And we welcome your comments . Cheers Mounira - Mail original - De: "William Whyte" À: "Mounira Msahli" Cc: "tls" Envoyé: Vendredi 24 Août 2018 17:16:00 Objet: Re: [TLS] TLS 1.3 Authentication using E

Re: [TLS] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates

On Fri, Aug 24, 2018 at 04:09:43PM +0200, Mounira Msahli wrote: > Hi all, > > > The draft: TLS 1.3 Authentication using IEEE 1609.2/ETSI TS 103097 > certificates is updated in accordance with TLS 1.3: > https://tools.ietf.org/html/draft-tls-certieee1609-01 > > This document describes the use

Re: [TLS] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates

Hi all -- as editor of 1609.2 (and a contributor to 103 097) I'd like to recommend that the WG moves forward with consideration of this draft. There are a number of initiatives in the connected vehicle space that need TLS with 1609.2 certificates, and in particular ISO 21177, which is currently in

[TLS] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates

Hi all, The draft: TLS 1.3 Authentication using IEEE 1609.2/ETSI TS 103097 certificates is updated in accordance with TLS 1.3: https://tools.ietf.org/html/draft-tls-certieee1609-01 This document describes the use of certificates specified by the Institute of Electrical and Electronics

[TLS] TLS 1.3 Stickers

To all of the contributors to the TLS 1.3 process, many thanks! We are big believers and feel really good about the state of the protocol. A lot of our consumers are excited to start using it. We’ve taken the TLS 1.3 logo and made a batch of stickers, and want to share them. If you are

[TLS] TLS 1.3 mandatory to support in 3GPP 5G

I am happy to announce that TLS 1.3 is already mandatory to support for all uses of TLS in 3GPP 5G (and also LTE, 3G systems that are updated to the latest release). Release 15 makes TLS 1.3 mandatory for networks and Release 16 makes TLS 1.3 mandatory also for MEs (i.e. mobile phones) while

Re: [TLS] TLS 1.3 multiple session tickets from the client?

On Wed, 2018-05-16 at 11:30 +0200, Ander Juaristi wrote: > El 2018-05-11 09:05, Nikos Mavrogiannopoulos escribió: > > On Thu, 2018-05-10 at 11:46 -0400, Viktor Dukhovni wrote: > > > > > > Good to know. Does any implementation other than OpenSSL support > > > external PSKs? How do you

Re: [TLS] TLS 1.3 multiple session tickets from the client?

El 2018-05-11 09:05, Nikos Mavrogiannopoulos escribió: On Thu, 2018-05-10 at 11:46 -0400, Viktor Dukhovni wrote: Good to know. Does any implementation other than OpenSSL support external PSKs? How do you distinguish between external PSKs and resumption PSKs? gnutls does. For external PSKs

Re: [TLS] TLS 1.3 multiple PSKs (was session tickets) from the client?

On Thursday, 10 May 2018 19:28:45 CEST Viktor Dukhovni wrote: > > On May 10, 2018, at 11:46 AM, Viktor Dukhovni wrote: > >> I would imagine, but NSS, at least, doesn't support external PSKs. > > > > Good to know. Does any implementation other than OpenSSL support > >

Re: [TLS] TLS 1.3 multiple session tickets from the client?

On Thursday, 10 May 2018 17:46:40 CEST Viktor Dukhovni wrote: > > On May 10, 2018, at 10:17 AM, Eric Rescorla wrote: > >> Do you prepend some new "magic" to the (RFC5077 or similar) session > >> tickets? Or just look for a matching STEK key name and let that be > >> the "magic"? >

Re: [TLS] TLS 1.3 multiple session tickets from the client?

On Thu, 2018-05-10 at 11:46 -0400, Viktor Dukhovni wrote: > > On May 10, 2018, at 10:17 AM, Eric Rescorla wrote: > > > > > Do you prepend some new "magic" to the (RFC5077 or similar) > > > session > > > tickets? Or just look for a matching STEK key name and let that > > > be > >

Re: [TLS] TLS 1.3 multiple PSKs (was session tickets) from the client?

> -Original Message- > From: TLS <tls-boun...@ietf.org> On Behalf Of Martin Thomson > Sent: Thursday, May 10, 2018 5:31 PM > To: <tls@ietf.org> <tls@ietf.org> > Subject: Re: [TLS] TLS 1.3 multiple PSKs (was session tickets) from the client? > > On Fri,

Re: [TLS] TLS 1.3 multiple PSKs (was session tickets) from the client?

On Fri, May 11, 2018 at 9:08 AM Viktor Dukhovni wrote: > Should servers issue resumption tickets after an initial PSK handshake? > And if so, should resumption be preferred for any reason when the client > sends both a resumption ticket and the external PSK? I don't

Re: [TLS] TLS 1.3 multiple PSKs (was session tickets) from the client?

> On May 10, 2018, at 1:28 PM, Viktor Dukhovni wrote: > > On a related note, should a client sending both a resumption and > an external PSK place the resumption PSK first in the list of > PSK identities? My concern is that server implementations might > otherwise

Re: [TLS] TLS 1.3 multiple session tickets from the client?

> -Original Message- > From: TLS <tls-boun...@ietf.org> On Behalf Of Viktor Dukhovni > Sent: Thursday, May 10, 2018 8:47 AM > To: TLS WG <tls@ietf.org> > Subject: Re: [TLS] TLS 1.3 multiple session tickets from the client? > > > > > On M

Re: [TLS] TLS 1.3 multiple PSKs (was session tickets) from the client?

> On May 10, 2018, at 11:46 AM, Viktor Dukhovni wrote: > >> I would imagine, but NSS, at least, doesn't support external PSKs. > > Good to know. Does any implementation other than OpenSSL support > external PSKs? How do you distinguish between external PSKs and >

Re: [TLS] TLS 1.3 multiple session tickets from the client?

On Thu, May 10, 2018 at 8:46 AM, Viktor Dukhovni wrote: > > > > On May 10, 2018, at 10:17 AM, Eric Rescorla wrote: > > > >> Do you prepend some new "magic" to the (RFC5077 or similar) session > >> tickets? Or just look for a matching STEK key name and let

Re: [TLS] TLS 1.3 multiple session tickets from the client?

> On May 10, 2018, at 10:17 AM, Eric Rescorla wrote: > >> Do you prepend some new "magic" to the (RFC5077 or similar) session >> tickets? Or just look for a matching STEK key name and let that be >> the "magic"? > > I would imagine, but NSS, at least, doesn't support external

Re: [TLS] TLS 1.3 multiple session tickets from the client?

On Thu, May 10, 2018 at 6:46 AM, Viktor Dukhovni wrote: > > > > On May 10, 2018, at 7:48 AM, Eric Rescorla wrote: > > > > The option for multiple PSKs is something that is used in pure PSK modes, > > but I confess to not fully understanding the reasons you

Re: [TLS] TLS 1.3 multiple session tickets from the client?

> On May 10, 2018, at 7:48 AM, Eric Rescorla wrote: > > The option for multiple PSKs is something that is used in pure PSK modes, > but I confess to not fully understanding the reasons you might use multiple > PSKs. I suspect that they are most useful during a key rollover. >

Re: [TLS] TLS 1.3 multiple session tickets from the client?

On Thu, May 10, 2018 at 2:23 AM, Martin Thomson wrote: > On Thu, May 10, 2018 at 2:11 PM Viktor Dukhovni > wrote: > > TLS 1.3 allows clients to send multiple PSK identities, with the server > > choosing one. When, if every, might it make sense

Re: [TLS] TLS 1.3 multiple session tickets from the client?

On Thu, May 10, 2018 at 2:11 PM Viktor Dukhovni wrote: > TLS 1.3 allows clients to send multiple PSK identities, with the server > choosing one. When, if every, might it make sense for the client to > send multiple session tickets to the server? If this is not expected,

  1   2   3   >