Re: [TLS] Mail regarding draft-ietf-tls-tls13
> On Jun 18, 2018, at 3:12 PM, Ben Personick wrote: > > So essentially TLS 1.3 drops support for DH/DHE ciphers on RSA keys, but > willl otherwise work as expected? No, it drops support for *non* (EC)DHE RSA ciphers, keeping *only* the (EC)DHE RSA ciphers, for specific FFDHE groups (as before) specific ECDHE curves. Note that (IIRC) the TLS 1.3 implementation in OpenSSL 1.1.1 will not include support the TLS 1.3 finite-field DHE groups, and so TLS 1.3 interoperability with OpenSSL *requires* ECDHE support. If your implementation offers TLS 1.3, but offers no ECDHE signature algorithms, the handshake will (IIRC) likely fail. So what's becoming effectively mandatory with TLS 1.3 is ECDHE key agreement, not ECDSA certificates, though TLS 1.3 clients really should also support connections to servers that have ECDSA P-256, P-384, P-521, Ed25519 and Ed448 certificates. But servers can stick with RSA certificates so long as they are willing to do ECDHE key agreement. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Mail regarding draft-ietf-tls-tls13
Hello Tony, So essentially TLS 1.3 drops support for DH/DHE ciphers on RSA keys, but willl otherwise work as expected? Ben From: Tony Arcieri Sent: Monday, June 18, 2018 11:36 To: Ben Personick Cc: Subject: Re: [TLS] Mail regarding draft-ietf-tls-tls13 On Mon, Jun 18, 2018 at 6:30 AM Ben Personick mailto:ben.person...@iongroup.com>> wrote: There is a common thread circulating, that all support for RSA Certificates/Ciphers are dropped in TLS 1.3. RSA certificates will continue to work in TLS 1.3+. What will not be supported in TLS 1.3+ is RSA key transport / key encipherment (which lacks forward secrecy, among other problems). However, this is a property of how the protocol does key exchange / key agreement and has nothing to do with certificates. -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Mail regarding draft-ietf-tls-tls13
Hello Viktor, I am only concerned with offereing newer , faster, and more secure cipher suites on our web application, so that as clients have the ability to use them they can begin to do so. Our LB offers a method to present baoth an RSA and ECC cert at thw aame time, at the cost of buying both each year. I can only support ecdsa_rsa unless I have an ECC certificate to support ecsda_ecsde ciphers. Since TLS 1.3 will continue to allow ecdsa_rsa ciphers, there will be no push to move towards offering them, because of various 'reasons'. Ben From: Viktor Dukhovni Sent: Monday, June 18, 2018 12:32 To: Ben Personick Cc: TLS WG Subject: Re: [TLS] Mail regarding draft-ietf-tls-tls13 > On Jun 18, 2018, at 9:10 AM, Ben Personick wrote: > > There is a common thread circulating, that all support for RSA > Certificates/Ciphers are dropped in TLS 1.3. This is not the case. > As I wrote in the last email, I am aware we can implemenet ECC certs and > ciphers in TLS 1.2, along side RSA certs/ciphers, however there is a > consistent fear of breaking what already works by moving onto offering both > an ECC and RSA certificate and corrosponding ciphers. You should at least support verifying ECDSA certificates on the client side, some servers your client software might connect to may have only ECDSA certificates. On the server side you can continue to use RSA certificates if you wish. While ECDSA is faster on the server, there are still some clients (perhaps yours among them) that only support RSA, and so you'd need to have both RSA and ECDSA certificates, which is operationally a bit more challenging. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Mail regarding draft-ietf-tls-tls13
On Mon, Jun 18, 2018 at 12:12 PM Ben Personick wrote: > So essentially TLS 1.3 drops support for DH/DHE ciphers on RSA keys, but > willl otherwise work as expected? > DH/DHE ciphers are orthogonal to RSA key transport/encipherment. The latter uses the RSA algorithm for encryption, without any DH(E) algorithm whatsoever, and that is what is no longer supported in TLS 1.3. -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Mail regarding draft-ietf-tls-tls13
> On Jun 18, 2018, at 9:10 AM, Ben Personick wrote: > > There is a common thread circulating, that all support for RSA > Certificates/Ciphers are dropped in TLS 1.3. This is not the case. > As I wrote in the last email, I am aware we can implemenet ECC certs and > ciphers in TLS 1.2, along side RSA certs/ciphers, however there is a > consistent fear of breaking what already works by moving onto offering both > an ECC and RSA certificate and corrosponding ciphers. You should at least support verifying ECDSA certificates on the client side, some servers your client software might connect to may have only ECDSA certificates. On the server side you can continue to use RSA certificates if you wish. While ECDSA is faster on the server, there are still some clients (perhaps yours among them) that only support RSA, and so you'd need to have both RSA and ECDSA certificates, which is operationally a bit more challenging. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Mail regarding draft-ietf-tls-tls13
On Mon, Jun 18, 2018 at 6:30 AM Ben Personick wrote: > There is a common thread circulating, that all support for RSA > Certificates/Ciphers are dropped in TLS 1.3. > RSA certificates will continue to work in TLS 1.3+. What will not be supported in TLS 1.3+ is RSA key transport / key encipherment (which lacks forward secrecy, among other problems). However, this is a property of how the protocol does key exchange / key agreement and has nothing to do with certificates. -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Mail regarding draft-ietf-tls-tls13
Hello Sean Thanks for the explination. :) Ben From: Sean Turner Sent: Saturday, June 16, 2018 11:04 PM To: Ben Personick Cc: tls@ietf.org Subject: Re: [TLS] Mail regarding draft-ietf-tls-tls13 > On Jun 12, 2018, at 16:15, Ben Personick wrote: > > I have read some articles saying the draft is approved, but on looking it > seems not to be, I am a little unsure why the draft has been stuck in this > seemingly nearly finished but not quite ready state for 3 months. The draft has been approved by the IESG. Once a draft is approved it moves over to the RFC editor (and there’s some IANA review too); here’s a link to the RFC editorial process [0]; here’s a link to their publication queue [1]. 3 months is about what I expected in terms of wait post approval.. We’re nearly there. spt [0] https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fpubprocess%2F=02%7C01%7Cben.personick%40iongroup.com%7Ca655a0eeead9423fbd0408d5d3ff13d0%7C768fe7d4ebee41a79851d5825ecdd396%7C0%7C1%7C636648014877571083=P7w%2BqRt4H8tqJaRkG%2FoQJg8%2FJMDABTe6BAcgx33JWEU%3D=0 [1] https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fcurrent_queue.php=02%7C01%7Cben.personick%40iongroup.com%7Ca655a0eeead9423fbd0408d5d3ff13d0%7C768fe7d4ebee41a79851d5825ecdd396%7C0%7C1%7C636648014877571083=IxdHA4%2FTBCy%2BugEOcO37Rx4nDiRXOCSIAQOLlXtVSmQ%3D=0 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Mail regarding draft-ietf-tls-tls13
Hello Viktor, Thanks for your thoughtful reply. I haven't read the draft itself, only the articals which point to it. There is a common thread circulating, that all support for RSA Certificates/Ciphers are dropped in TLS 1.3. As I wrote in the last email, I am aware we can implemenet ECC certs and ciphers in TLS 1.2, along side RSA certs/ciphers, however there is a consistent fear of breaking what already works by moving onto offering both an ECC and RSA certificate and corrosponding ciphers. If TLS 1.3 does support RSA certs, that removes the drive to begin offering ecdhe_ecdsa alongside ecdhe_rsa, which essentially moves it back to the "Do not need to implement pile", which will not tick forward into the "must implement" pile until it is absolutely required. I was sincerely hoping to be able to use the expected "end of ths RSA Cert" to move us there in preparation of supporting TLS 1.3 and for once be ahead of the curve instead of implemementing what seems to be superiod encryption methods much later. Ben From: Viktor Dukhovni Sent: Saturday, June 16, 2018 11:31 PM To: Ben Personick Cc: tls@ietf.org Subject: Re: [TLS] Mail regarding draft-ietf-tls-tls13 > On Jun 12, 2018, at 4:15 PM, Ben Personick wrote: > > We are currently evaluating when to begin offering ECC Certificates based > cypto on our websites. > > Despite the advantages to doing this in TLS 1..2, there is a lot of push-back > to wait until we “have to support it” once the TLS 1.3 draft is published, > and the option to use it becomes available. I am puzzled why you feel you have to support ECC certificates with TLS 1.3, and yet not for TLS 1.2? RSA certificates continue to be supported in TLS 1.3, and ECDSA certificates are well supported in TLS 1.2. Are you referring to deploying ECC certificates in your server software, or interoperating with ECC servers in your client software? If the latter, then indeed you should start to support servers that can only present ECDSA, rather than RSA, certificates. And do so with both TLS 1.2 and TLS 1.3, it is not clear why you'd wait for TLS 1.3 to be published. (We can party when it comes out, but that should not IMHO hold up implementations of ECDSA support). -- -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Universal PSKs
On Mon, 2018-06-18 at 13:56 +0200, Jonathan Hoyland wrote: > The issue with the current draft is that it leaves a single PSK with > two potential interpretations. > If the draft also changed the PSK identity value then each PSK would > have a single interpretation. > If the draft changes the identity then it can also change the PSK key > without having to change the manner in which the binder is computed. > In that case universal PSKs and regular PSKs do not need to be > distinguished, because they are both validated in the same way. > > A server unaware of universal PSKs would simply see an unrecognised > PSK identity. > If both the unmodified and the modified PSKs are sent, then it can > simply select the unmodified version, ignoring the other. > A server that recognises both values can choose which to use. > > If the modified PSK identity was a channel binding, then the modified > version would have stronger security properties, and thus presumably > would be preferable. > In this case the hash function used for the binder remains > selectable. > > Would that resolve your issue? That may not be sufficient. A server which sees an unrecognized PSK may chose to pretend it recognized it to avoid user enumeration attacks similarly to TLS1.2 (optional) behavior. Hence a modified username would cause negotiation failure with such a server. A new extension seems to be necessary to eliminate any interoperability issues with servers that will not follow the universal psk draft. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Universal PSKs
The issue with the current draft is that it leaves a single PSK with two potential interpretations. If the draft also changed the PSK identity value then each PSK would have a single interpretation. If the draft changes the identity then it can also change the PSK key without having to change the manner in which the binder is computed. In that case universal PSKs and regular PSKs do not need to be distinguished, because they are both validated in the same way. A server unaware of universal PSKs would simply see an unrecognised PSK identity. If both the unmodified and the modified PSKs are sent, then it can simply select the unmodified version, ignoring the other. A server that recognises both values can choose which to use. If the modified PSK identity was a channel binding, then the modified version would have stronger security properties, and thus presumably would be preferable. In this case the hash function used for the binder remains selectable. Would that resolve your issue? Regards, Jonathan Hoyland On Mon, 18 Jun 2018 at 12:22 Hubert Kario wrote: > On Friday, 15 June 2018 16:24:58 CEST Salz, Rich wrote: > > >that's not workable. > > > > > > It's not great, however > > > > > > >the reason why implementations chose to use old API to provision TLS > > >1.3 PSKs > > >was to make the upgrade process as smooth as possible, disabling TLS > > >1.3 is quite antithetical to that > > > > Disabling TLS 1.3 for those using 1.2 PSK's is unlikely to affect most > uses, > > and seems the only way forward. > > > Do you have an alternative solution? > > I don't see a reason to fragment the TLS 1.3 landscape "5 minutes" after > the > release TLS 1.3, even if you consider it small fragmentation. > > Correct solution was to include it in the TLS 1.3 proper. > > Now we have a TLS 1.3 draft which says: > >Prior to accepting PSK key establishment, the server MUST validate >the corresponding binder value (see Section 4.2.11.2 below). If this >value is not present or does not validate, the server MUST abort the >handshake. > > and a proposed change to it that doesn't say anything about > differentiating > between universal binders and regular binders. And forces those new > binders to > SHA-256 where previously it was selectable. > > So, either it is a severe issue and we should rework TLS 1.3 draft, or > this > draft needs to be significantly reworked before it will not cause huge > interoperability headaches – signalling extension is the bare minimum, > most > likely a new PSK extension is necessary. > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech > Republic___ > 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] Universal PSKs
On Friday, 15 June 2018 16:24:58 CEST Salz, Rich wrote: > >that's not workable. > > > It's not great, however > > > >the reason why implementations chose to use old API to provision TLS > >1.3 PSKs > >was to make the upgrade process as smooth as possible, disabling TLS > >1.3 is quite antithetical to that > > Disabling TLS 1.3 for those using 1.2 PSK's is unlikely to affect most uses, > and seems the only way forward. > Do you have an alternative solution? I don't see a reason to fragment the TLS 1.3 landscape "5 minutes" after the release TLS 1.3, even if you consider it small fragmentation. Correct solution was to include it in the TLS 1.3 proper. Now we have a TLS 1.3 draft which says: Prior to accepting PSK key establishment, the server MUST validate the corresponding binder value (see Section 4.2.11.2 below). If this value is not present or does not validate, the server MUST abort the handshake. and a proposed change to it that doesn't say anything about differentiating between universal binders and regular binders. And forces those new binders to SHA-256 where previously it was selectable. So, either it is a severe issue and we should rework TLS 1.3 draft, or this draft needs to be significantly reworked before it will not cause huge interoperability headaches – signalling extension is the bare minimum, most likely a new PSK extension is necessary. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Universal PSKs
On Fri, 2018-06-15 at 13:00 +0100, Matt Caswell wrote: > > On 15/06/18 12:37, Nikos Mavrogiannopoulos wrote: > > It feels that's this is too little too late. Implementations which > > support PSKs will switch to TLS1.3 irrespective of this proposal. > > If > > this proposal takes on, we will have some implementations which > > support > > universal PSKs and others which don't leading to interoperability > > problems which we wouldn't have otherwise. > > I'm not sure how many TLS1.3 implementations there are out there that > also have TLS1.2 PSK support. OpenSSL is one of them. We have APIs > for TLS1.2 PSKs and different APIs for TLS1.3 PSKs. Currently > applications > using the old APIs can still expect those PSKs to work in TLS1.3. In > light of this proposal we are considering removing our TLS1.2 -> > TLS1.3 > PSK code and instead restricting applications using TLS1.2 PSK APIs > to > only TLS1.2 until this is resolved (although unfortunately that would > mean removing it from our upcoming LTS release). In gnutls [0] we have the same APIs for PSK under TLS1.2 and TLS1.3 and the transition is quite smooth, but in contrast to David's algorithm, we select a PSK before selecting the ciphersuite in order to make that work. The problem I see is that PSKs are restricted to SHA256 KDF and thus AES128 which is somewhat ugly but we can live with it until we provide a better way to mark a specific PRF in our key files. regards, Nikos [0]. https://nikmav.blogspot.com/2018/05/gnutls-and-tls-13.html (PSK key exchange) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Universal PSKs
On Fri, 2018-06-15 at 09:11 -0400, David Benjamin wrote: > On Fri, Jun 15, 2018 at 7:14 AM Hubert Kario > wrote: > > On Thursday, 14 June 2018 21:46:27 CEST David Benjamin wrote: > > > Thoughts? If the WG likes this design, I would suggest: > > > > > > - Most folks who want to use TLS 1.3 with external PSKs should > > probably > > > design their protocols to provision universal PSKs instead, after > > it > > > stabilizes. > > > > > > - Folks who want to use TLS 1.3 with existing TLS 1.2 PSKs should > > use the > > > compatibility derivation in this draft, after it stabilizes. > > > > > > - Folks who want to ship TLS 1.3 before then and have a TLS 1.2 > > PSK API > > > should not use the 1.2 PSK as a 1.3 PSK. For now, just turn TLS > > 1.3 off by > > > default if that API is used and, in a future release, use the > > compatibility > > > derivation after it stabilizes. > > > > that's not workable. > > > > the reason why implementations chose to use old API to provision > > TLS 1.3 PSKs > > was to make the upgrade process as smooth as possible, disabling > > TLS 1.3 is > > quite antithetical to that > > Indeed. That is why the TLS 1.2 compatibility section exists. :-) So > that implementations in that position can reuse TLS 1.2 PSK APIs in > TLS 1.3 while honoring the security proof. > > But, unfortunately, there's a slight timing issue. There's no way > some random draft published yesterday will be finalized before TLS > 1.3. So implementations with TLS 1.2 PSK APIs would need to either > violate the TLS 1.3 security proof or not ship TLS 1.3 until this > draft finalizes. Is key separation between TLS1.3 and TLS1.2 something that TLS1.3 provides or intended to provide? As I mentioned in my reply TLS1.3 design goals were very apparent that keys will be re-used from TLS1.2, and this is what is happening today for any kind of keys from RSA to PSKs. I'm not sure I see a new cross-protocol violation here that was not discussed during the TLS1.3 process. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Universal PSKs
On Fri, 2018-06-15 at 14:24 +, Salz, Rich wrote: > >that's not workable. > > > It's not great, however > > >the reason why implementations chose to use old API to provision > > TLS 1.3 PSKs > > was to make the upgrade process as smooth as possible, disabling > TLS 1.3 is > quite antithetical to that > > Disabling TLS 1.3 for those using 1.2 PSK's is unlikely to affect > most uses, and seems the only way forward. > > Do you have an alternative solution? TLS 1.3 provides a solution. These secrets under TLS1.3 are restricted to using the SHA256 PRF. That's how we have implemented it in gnutls. regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] cost of padding removal in TLS1.3 [was: Possible timing attack on TLS 1.3 padding mechanism]
On Thu, 2018-03-01 at 21:52 +, Paterson, Kenny wrote: > Hi, > > I've been analysing the record protocol spec for TLS 1.3 a bit, > specifically the new padding mechanism. I think there's a possible > timing attack on a naïve implementation of de-padding. Maybe this is > already known to people who've been paying more attention than me! > > Recall that the padding mechanism permits an arbitrary number of 00 > bytes to be added after the plaintext and content type byte, up to > the max record size. This data is then encrypted using whichever AEAD > scheme is specified in the cipher suite. This padding scheme is quite > important for TLS 1.3 because the current AEAD schemes do leak the > length of record plaintexts. There should be no padding oracle style > attack possible because of the integrity guarantees of the AEAD > schemes in use. > > The idea for the timing attack is as follows. > > The natural way to depad (after AEAD decryption) is to remove the 00 > bytes at the end of the plaintext structure one by one, until a non- > 00 byte is encountered. This is then the content type byte. Notice > that the amount of time needed to execute this depadding routine > would be proportional to the number of padding bytes. If there's some > kind of response record for this record, then measuring the time > taken from reception of the target record to the appearance of the > response record can be used to infer information about the amount of > padding, and thereby, the true length of the plaintext (since the > length of the padded plaintext is known from the ciphertext length). Hi, I'd like to get back into that old thread because we've figured out that making the padding removal not depending on the data is quite costly for aes-gcm on a modern processor. Roughly, the record processing time drops by half for large packets comparing to TLS1.2, in effect pushing implementors to make the default padding removal time- variable. Has this performance drop been observed by others? regards, Nikos ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
