Re: [TLS] Certificate keyUsage enforcement question (new in RFC8446 Appendix E.8)
Geoffrey Keating wrote: > Viktor Dukhovni writes: >> >> TL;DR: Should TLS client abort DHE-RSA handshakes with a peer >> certificate that *only* lists: >> >> X509v3 Key Usage: >> Key Encipherment, Data Encipherment > > Yes, because in DHE-RSA, the RSA key is used for signing, and this is > an encryption-only key. There is *ZERO* security problem associated with TLS client allowing a TLS server to do this, but it makes it harder to catch defective CA software and bogus CA issuing practices when clients do not complain here -- and the TLS specification says this KeyUsage DigitalSignature is a MUST for DHE/ECDHE key exchange: TLSv1.2: https://tools.ietf.org/html/rfc5246#page-49 DHE_RSARSA public key; the certificate MUST allow the ECDHE_RSA key to be used for signing (the digitalSignature bit MUST be set if the key usage extension is present) with the signature scheme and hash algorithm that will be employed in the server key exchange message. Note: ECDHE_RSA is defined in [TLSECC]. TLSv1.0: https://tools.ietf.org/html/rfc2246#page-38 CAs and CA software that issues certificates as TLS server certificates (i.e. with ExtKeyUsage id-kp-serverAuth, id-kp-clientAuth or both) and forgets to assert DigitalSignature, prove their own royal brokenness. Using an RSA key for PKCS#1 v1.5 signatures is *NO* security problem. Do not get confused by the FUD and snake-oil that resulted in the needless additional complexity of RSA-PSS in TLSv1.3, that adds ZERO security value. https://www.schneier.com/blog/archives/2018/09/evidence_for_th.html https://eprint.iacr.org/2018/855 There is some security risk with using an RSA signing-only key for PKCS#1 v1.5 encryption, i.e. the equivalent of using a keyUsage without keyEncipherment for static-RSA key exchange -Martin ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Certificate keyUsage enforcement [whose duty, client's or server's?]
On Wed, Nov 07, 2018 at 03:48:26PM +0100, Martin Rex wrote: > There is *ZERO* security problem associated with TLS client allowing > a TLS server to do this, but it makes it harder to catch defective > CA software and bogus CA issuing practices when clients do not complain > here The interoperability issues I'm seeing are with self-signed certificates used in opportunistic TLS and DANE in SMTP. The CA is some end-user, who "does not know any better", and the question is how pedantic should the client's TLS stack be in such a case. Perhaps the correct place to *enforce* any keyUsage requirement is in the TLS *server*, which should limit *itself* to the algorithms compatible with the certificate. That would be both more effective, and more interoperable. > -- and the TLS specification says this KeyUsage DigitalSignature > is a MUST for DHE/ECDHE key exchange: > > TLSv1.2: https://tools.ietf.org/html/rfc5246#page-49 > > DHE_RSARSA public key; the certificate MUST allow the > ECDHE_RSA key to be used for signing (the > digitalSignature bit MUST be set if the key > usage extension is present) with the signature > scheme and hash algorithm that will be employed > in the server key exchange message. > Note: ECDHE_RSA is defined in [TLSECC]. What the RFC does not say is whose duty it is (if anyone's) to *enforce* the restriction. Perhaps clients should not be the ones to do so? -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Certificate keyUsage enforcement question (new in RFC8446 Appendix E.8)
On Wed, Nov 7, 2018 at 1:12 AM Viktor Dukhovni wrote: > [ Quoted text slightly reordered to put the RSA issue first, as that's > the main thing I'm trying to get clarity on, and enabling keyUsage > enforcement is causing some interoperability issues now... ] > > > On Nov 5, 2018, at 11:11 PM, Geoffrey Keating wrote: > > > >> TL;DR: Should TLS client abort DHE-RSA handshakes with a peer > >> certificate that *only* lists: > >> > >>X509v3 Key Usage: > >>Key Encipherment, Data Encipherment > > > > Yes, because in DHE-RSA, the RSA key is used for signing, and this is > > an encryption-only key. > > > > > As far as I know there's no similar attack on RSA, but I think this is > > not a well-examined area. > > Since the vast majority of certificates in the wild are RSA, and > interoperability is a concern, I'd really like to better understand > what risk if any posed if one allows a an *RSA* key with a keyUsage > of "keyEncipherment" (seen on some live servers that then do DHE-RSA) > to be used for "DigitalSignature"? I am only aware of risks in the > converse direction. How unreasonable would it be to be more forgiving > and allow *RSA* "DigitalSignature" when the keyUsage indicates otherwise? > This seems flipped to me. Which attacks do you see enforcing keyEncipherment blocking? If you are concerned about Bleichenbacher-type private key oracles, it should be more important to enforce digitalSignature, and even that's not sufficient in itself (cf. DROWN affecting non-SSLv2 clients too). A private key oracle allows both ciphertext decryption *and* signature forgery, so we need clients to know which forged signatures to reject, and for an uncompromised path to be possible. Thus, if you believe the server's RSA key exchange implementation admits a private key oracle and that oracle is efficient enough for online attacks[*], I believe you need all of the following for the client to not care: 1. The server uses separate keys for RSA encryption and RSA signing. It will never use its RSA signing key for RSA encryption. 2. The server key separation is reflected in keyUsage bits, which is enforced by the client in (EC)DHE_RSA modes. 3. The client doesn't accept RSA key exchange at all. If all are true, the client will never accept the encryption key and the signing key is uncompromised, so we're fine. If any of the above are false, I don't think it works. If the server shares RSA and (EC)DHE_RSA keys (1), as everyone does, its one and only key is effectively compromised and there's not a whole lot one can do, short of fixing or disabling the RSA key exchange implementation on the server. If the client ignores keyUsage in (EC)DHE_RSA (2), as most do, the server's key separation is moot. The client doesn't know to reject a private-key-oracle-forged signature. If the client still supports RSA key exchange (3), as most do, none of this key separation matters, because the attacker can just negotiate RSA key exchange anyway. My experience is that typically none of (1), (2), or (3) happen, much less all, so this is all kind of moot. :-) Re (2), historically we'd seen issues with MITM proxies minting certs incorrectly, BoringSSL only enforces key usage for RSA starting TLS 1.3 (it was new, so get it right from the start) and ECDSA at all versions (only one value in practice, seems to have worked out). I started gathering more current metrics a while back but haven't had time to follow-up on this yet. But as most clients sadly still have to support RSA key exchange (3) and managing two certificates (1) is onerous for most server, I doubt any fixing that will help in practice for a while, if ever. It's more an ecosystem health thing. David [*] If you believe the oracle isn't efficient enough for online attacks, you probably can just lean on downgrade protection ratcheting you to (EC)DHE_RSA and call it a day? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Certificate keyUsage enforcement question (new in RFC8446 Appendix E.8)
Viktor Dukhovni writes: > [ Quoted text slightly reordered to put the RSA issue first, as that's > the main thing I'm trying to get clarity on, and enabling keyUsage > enforcement is causing some interoperability issues now... ] > > > On Nov 5, 2018, at 11:11 PM, Geoffrey Keating wrote: > > > >> TL;DR: Should TLS client abort DHE-RSA handshakes with a peer > >> certificate that *only* lists: > >> > >>X509v3 Key Usage: > >>Key Encipherment, Data Encipherment > > > > Yes, because in DHE-RSA, the RSA key is used for signing, and this is > > an encryption-only key. > > > > > As far as I know there's no similar attack on RSA, but I think this is > > not a well-examined area. > > Since the vast majority of certificates in the wild are RSA, and > interoperability is a concern, I'd really like to better understand > what risk if any posed if one allows a an *RSA* key with a keyUsage > of "keyEncipherment" (seen on some live servers that then do DHE-RSA) > to be used for "DigitalSignature"? I am only aware of risks in the > converse direction. How unreasonable would it be to be more forgiving > and allow *RSA* "DigitalSignature" when the keyUsage indicates otherwise? Maybe I should expand on my previous answer. There is, obviously, an attack with RSA under some circumstances. If you have an oracle where the attacker can see the results of any RSA decryption, then this leads directly to the ability to forge a signature. In more practical situations, the attacker doesn't get to see the results. Instead, for example in properly-implemented TLS, the attacker only learns whether the decryption was successful, relative to a key chosen by the attacker, and a 'successful' decryption includes a padding check of the output which is highly unlikely to succeed for a fixed input. So there doesn't seem to be a direct attack in this situation. However, how do you know this is the situation? There is the obvious question about improper implementations. How do you know that this key wasn't configured this way because there's a known security issue which might leak a key used for encryption, and the key is intended only to be presented to hosts which will not accept DHE? This is particularly relevant because we do know of some attacks on PKCS#1v1.5 encryption, which make the 'proper implementation' quite complicated, and you can see the result in RFC 3218. However these attacks were concerned primarily with recovering the symmetric key, and not forging a signature using the RSA key. I don't think anyone has deeply investigated the signature-forging issue in this context, since typically if you can recover the symmetric key, that's bad enough (you can just force the connection to use an encryption-based ciphersuite). In general, though, what you're asking is "The CA signing this key has instructed that I do not accept signatures made with it. Is it OK to accept signatures made with it?" It's really hard to see how the answer to that could generally be 'yes'. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WG adoption call: draft-wood-tls-ticketrequests
Adopt it. It's a small, useful feature. On Wed, Nov 7, 2018 at 2:48 PM Sean Turner wrote: > > At TLS@IETF103, there was consensus in the room to adopt > draft-wood-tls-ticketrequests. This message is to confirm that consensus. > If you do not support adoption of draft-wood-tls-ticketrequests as WG item > please say so by 2359UTC on 30 November 2018 (and say why). > > Thanks, > 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] WG adoption call: draft-wood-tls-ticketrequests
As a co-author, I do support adoption, as this will help optimize client connection racing. Tommy > On Nov 8, 2018, at 8:07 AM, Martin Thomson wrote: > > Adopt it. It's a small, useful feature. > On Wed, Nov 7, 2018 at 2:48 PM Sean Turner wrote: >> >> At TLS@IETF103, there was consensus in the room to adopt >> draft-wood-tls-ticketrequests. This message is to confirm that consensus. >> If you do not support adoption of draft-wood-tls-ticketrequests as WG item >> please say so by 2359UTC on 30 November 2018 (and say why). >> >> Thanks, >> 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] WG adoption call: draft-wood-tls-ticketrequests
I support adoption and I am sure OpenSSL will implement, or I will do it and make a PR. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Are we holding TLS wrong?
Hi everyone, Over in the Babel working group we have a draft about securing Babel with DTLS: https://tools.ietf.org/html/draft-ietf-babel-dtls-01 It's 5 pages long, could any TLS experts please give it a quick read and let us know if we're using DTLS correctly? Also, should the document contain guidance such as which DTLS version to use? Thanks, David ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Certificate keyUsage enforcement [whose duty, client's or server's?]
Viktor Dukhovni writes: >On Wed, Nov 07, 2018 at 03:48:26PM +0100, Martin Rex wrote: >> There is *ZERO* security problem associated with TLS client allowing >> a TLS server to do this, but it makes it harder to catch defective >> CA software and bogus CA issuing practices when clients do not complain >> here > >The interoperability issues I'm seeing are with self-signed certificates used >in opportunistic TLS and DANE in SMTP. The CA is some end-user, who "does not >know any better", and the question is how pedantic should the client's TLS >stack be in such a case. My code, by default, strictly enforces keyUsage [0], so I end up seeing all the broken certs out there, and it's complete chaos, (DH) keyAgreement set for RSA certs, every possible key usage (includings ones the algorithm isn't capable of) set, things like email encryption and SSL server set for CA certs (extKeyUsage), keyEncipherment for signing keys, digitalSignature for encryption keys, it's the Rule 34 of PKI (if you can think of it, someone's put it in an extension). This includes CA-issued certs, not self-signed ones. I think a significant chunk of TLS PKI only works because implementations don't strictly enforce keyUsage. Peter. [0] Which probably wasn't the best default setting. If you think the public web PKI has broken certs, you should see what turns up in the SCADA world... ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] WG adoption call: draft-wood-tls-ticketrequests
I support the adoption as well, we need it for lurk. Yours, Daniel On Wed, Nov 7, 2018 at 8:31 PM Salz, Rich wrote: > I support adoption and I am sure OpenSSL will implement, or I will do it > and make a PR. > > ___ > 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] Certificate keyUsage enforcement [whose duty, client's or server's?]
Peter, I think your code did exactly right. The standard requires honoring KeyUsage.. Maybe if more implementations were diligent with this, the cert zoo we're observing would've been less wild... Regards, Uri Sent from my iPhone > On Nov 7, 2018, at 21:21, Peter Gutmann wrote: > > Viktor Dukhovni writes: > >>> On Wed, Nov 07, 2018 at 03:48:26PM +0100, Martin Rex wrote: >>> There is *ZERO* security problem associated with TLS client allowing >>> a TLS server to do this, but it makes it harder to catch defective >>> CA software and bogus CA issuing practices when clients do not complain >>> here >> >> The interoperability issues I'm seeing are with self-signed certificates used >> in opportunistic TLS and DANE in SMTP. The CA is some end-user, who "does >> not >> know any better", and the question is how pedantic should the client's TLS >> stack be in such a case. > > My code, by default, strictly enforces keyUsage [0], so I end up seeing all > the broken certs out there, and it's complete chaos, (DH) keyAgreement set for > RSA certs, every possible key usage (includings ones the algorithm isn't > capable of) set, things like email encryption and SSL server set for CA certs > (extKeyUsage), keyEncipherment for signing keys, digitalSignature for > encryption keys, it's the Rule 34 of PKI (if you can think of it, someone's > put it in an extension). This includes CA-issued certs, not self-signed ones. > I think a significant chunk of TLS PKI only works because implementations > don't strictly enforce keyUsage. > > Peter. > > [0] Which probably wasn't the best default setting. If you think the public >web PKI has broken certs, you should see what turns up in the SCADA >world... > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls smime.p7s Description: S/MIME cryptographic signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Certificate keyUsage enforcement question (new in RFC8446 Appendix E.8)
> On Nov 7, 2018, at 6:07 PM, Geoffrey Keating wrote: > > n general, though, what you're asking is "The CA signing this key has > instructed that I do not accept signatures made with it. Is it OK to > accept signatures made with it?" It's really hard to see how the > answer to that could generally be 'yes'. Thanks for everyone's input, this has been very helpful. The approach I'm inclined to take is as follows: 1. Always enforce key usage for your own certificate, ensuring key separation as provisioned at the time of key/certificate creation. This also maximizes opportunities for problems to be detected early and fixed. 2. Always enforce peer certificate key usage (separation) for ECDSA. ECDSA keys are more brittle when misused. 3. Enforce RSA peer certificate key usage when RSA key transport is locally disabled, allowing only (EC)DHE-RSA. This is always the case with TLS 1.3, but for TLS <= 1.2 subject to the enabled ciphers. The rationale for 3 is as follows: * The primary responsibility for doing key separation right falls on the key holder (as in 1). If that's always done correctly, the peer has nothing to second-guess. * If the key holder has no key separation, and makes key recovery possible through some sort of side-channel, then the attacker who recovers the key can always misuse that key via whichever key exchange is allowed by the certificate, when all are accepted by the client. Therefore, if the client supports both RSA key exchange and (EC)DHE-RSA, the attacker wins regardless of any effort by the client to enforce key usages. Which leaves the case where the client only accepts (EC)DHE-RSA (as with TLS 1.3 or TLS 1.2 with the RSA key exchange features disabled). In that case, if the attacker is able to compromise a server key constrained to "keyEncipherment", but cannot obtain a fraudulent certificate, then he'd have a certificate for just "keyEncipherment" which the client will refuse to honour for "digitalSignature". And so the client actually gets some measure of protection by doing keyUsage enforcement. This approach also has the advantage that legacy cases continue to (mis)behave like they always did, but the strictness rises to match the client's protocol preferences wether through use of TLS 1.3 (fresh start, fresh constraints) or by restricting TLS 1.2 ciphers in a way that makes keyUsage enforcement a practical counter-measure to at least some potential attacks. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Are we holding TLS wrong?
Hi David, A few quick notes below. Cheers The 11/08/2018 09:14, David Schinazi wrote: > Hi everyone, > > Over in the Babel working group we have a draft about securing Babel with > DTLS: > https://tools.ietf.org/html/draft-ietf-babel-dtls-01 > > It's 5 pages long, could any TLS experts please give it a quick read and > let us know if we're using DTLS correctly? > > Also, should the document contain guidance such as which DTLS version to > use? > > Thanks, > David Premise: I don't know Babel -- apologies for any nonsense! One high level thing which I can't extrapolate from the draft (which is probably due to my ignorance with Babel) is whether you envisage that *every* node does DTLS on the unicast channel, IOW that non-DTLS nodes are excluded from the mesh? Or would it be acceptable to mesh HMAC and DTLS neighbours? What about clear-text speakers? (It'd seem unwise to let them in an otherwise secured enclave.) You should probably provide some guidance about the kind of credentials do you plan to use (certs, raw pkeys)? It seems to me that the P2P nature of the protocol requires mutual authentication, could you confirm it? This seems to be a critical thing to prevent a rogue node to spoof the lowest (highest, I have already forgot, sorry) L-L address in a clear-text multicast Hello and bypass authentication. - s2.1 "Nodes SHOULD ensure that new client DTLS connections use different ephemeral ports from recently used connections to allow servers to differentiate between the new and old DTLS connections." Maybe you could suggest using a sufficiently entropic connection id here as a more robust alternative. - s2.5 Not sure what the ceremonies around flushing a neighbor are, but I'd make explicit signalling EOD at least a SHOULD? It seems more polite :-) - s.3 Not sure which TLS stack Babel nodes will use (are you targeting extremely constrained devices with custom TLS implementations?), but all the stacks I know of let the application set the MTU and take care of splitting the messages in MTU sized chunks transparently. -- Thomas ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Are we holding TLS wrong?
I took a quick look at the document and I don't know Babel. I see that you have two different proposals for securing Babel messages, namely * DTLS, and * a custom format offering integrity protection only. You correctly note in the document that DTLS offers more features. It is an authentication and key exchange protocol. One option to explore is to use DTLS to perform authentication and key exchange then use your custom format for integrity protection of packets with the keys exported from DTLS. Design-wise this approach is similiar to what we have done with DTLS-SRTP. This would also allow you to cover the multicast security case. Ciao Hannes Gesendet: Donnerstag, 08. November 2018 um 11:30 Uhr Von: "Fossati, Thomas (Nokia - GB/Cambridge)" An: "David Schinazi" Cc: "draft-ietf-babel-d...@ietf.org" , "tls@ietf.org" Betreff: Re: [TLS] Are we holding TLS wrong? Hi David, A few quick notes below. Cheers The 11/08/2018 09:14, David Schinazi wrote: > Hi everyone, > > Over in the Babel working group we have a draft about securing Babel with > DTLS: > https://tools.ietf.org/html/draft-ietf-babel-dtls-01 > > It's 5 pages long, could any TLS experts please give it a quick read and > let us know if we're using DTLS correctly? > > Also, should the document contain guidance such as which DTLS version to > use? > > Thanks, > David Premise: I don't know Babel -- apologies for any nonsense! One high level thing which I can't extrapolate from the draft (which is probably due to my ignorance with Babel) is whether you envisage that *every* node does DTLS on the unicast channel, IOW that non-DTLS nodes are excluded from the mesh? Or would it be acceptable to mesh HMAC and DTLS neighbours? What about clear-text speakers? (It'd seem unwise to let them in an otherwise secured enclave.) You should probably provide some guidance about the kind of credentials do you plan to use (certs, raw pkeys)? It seems to me that the P2P nature of the protocol requires mutual authentication, could you confirm it? This seems to be a critical thing to prevent a rogue node to spoof the lowest (highest, I have already forgot, sorry) L-L address in a clear-text multicast Hello and bypass authentication. - s2.1 "Nodes SHOULD ensure that new client DTLS connections use different ephemeral ports from recently used connections to allow servers to differentiate between the new and old DTLS connections." Maybe you could suggest using a sufficiently entropic connection id here as a more robust alternative. - s2.5 Not sure what the ceremonies around flushing a neighbor are, but I'd make explicit signalling EOD at least a SHOULD? It seems more polite :-) - s.3 Not sure which TLS stack Babel nodes will use (are you targeting extremely constrained devices with custom TLS implementations?), but all the stacks I know of let the application set the MTU and take care of splitting the messages in MTU sized chunks transparently. -- Thomas ___ 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] WG adoption call: draft-wood-tls-ticketrequests
+1 to adoption. I found myself unsure of how many tickets to send in the new Go implementation, which is notoriously averse to configuration knobs, and would love to have the client pick. 2018-11-07 14:47 GMT+0700 Sean Turner : > At TLS@IETF103, there was consensus in the room to adopt draft-wood-tls- > ticketrequests. This message is to confirm that consensus. If you do > not support adoption of draft-wood-tls-ticketrequests as WG item please > say so by 2359UTC on 30 November 2018 (and say why). > > Thanks, > 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] WG adoption call: draft-wood-tls-ticketrequests
I support adoption, this seems straightforward and is a good solution to a real world problem I’ve got. Thanks, Eric > On Nov 8, 2018, at 9:44 AM, Daniel Migault > wrote: > > I support the adoption as well, we need it for lurk. > Yours, > Daniel > >> On Wed, Nov 7, 2018 at 8:31 PM Salz, Rich wrote: >> I support adoption and I am sure OpenSSL will implement, or I will do it and >> make a PR. >> >> ___ >> 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
[TLS] I-D Action: draft-ietf-tls-oldversions-deprecate-01.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : Deprecating TLSv1.0 and TLSv1.1 Authors : Kathleen Moriarty Stephen Farrell Filename: draft-ietf-tls-oldversions-deprecate-01.txt Pages : 21 Date: 2018-11-07 Abstract: This document, if approved, formally deprecates Transport Layer Security (TLS) versions 1.0 [RFC2246] and 1.1 [RFC4346] and moves these documents to the historic state. These versions lack support for current and recommended cipher suites, and various government and industry profiles of applications using TLS now mandate avoiding these old TLS versions. TLSv1.2 has been the recommended version for IETF protocols since 2008, providing sufficient time to transition away from older versions. Products having to support older versions increase the attack surface unnecessarily and increase opportunities for misconfigurations. Supporting these older versions also requires additional effort for library and product maintenance. This document updates many RFCs that normatively refer to TLS1.0 or TLS1.1 as described herein. This document also updates RFC 7525 and hence is part of BCP195. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-oldversions-deprecate-01 https://datatracker.ietf.org/doc/html/draft-ietf-tls-oldversions-deprecate-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-oldversions-deprecate-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D Action: draft-ietf-tls-oldversions-deprecate-01.txt
Hiya, This version attempts to make the few changes discussed at the meeting on Monday. I wrote a script that gave me a list of 76(!) RFCs this might need to update, and may of course have mucked that up, so if anyone has a chance to check if (some of) those make sense, that'd be great. Ta, S. On 08/11/2018 05:28, internet-dra...@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Transport Layer Security WG of the IETF. > > Title : Deprecating TLSv1.0 and TLSv1.1 > Authors : Kathleen Moriarty > Stephen Farrell > Filename: draft-ietf-tls-oldversions-deprecate-01.txt > Pages : 21 > Date: 2018-11-07 > > Abstract: >This document, if approved, formally deprecates Transport Layer >Security (TLS) versions 1.0 [RFC2246] and 1.1 [RFC4346] and moves >these documents to the historic state. These versions lack support >for current and recommended cipher suites, and various government and >industry profiles of applications using TLS now mandate avoiding >these old TLS versions. TLSv1.2 has been the recommended version for >IETF protocols since 2008, providing sufficient time to transition >away from older versions. Products having to support older versions >increase the attack surface unnecessarily and increase opportunities >for misconfigurations. Supporting these older versions also requires >additional effort for library and product maintenance. > >This document updates many RFCs that normatively refer to TLS1.0 or >TLS1.1 as described herein. This document also updates RFC 7525 and >hence is part of BCP195. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tls-oldversions-deprecate-01 > https://datatracker.ietf.org/doc/html/draft-ietf-tls-oldversions-deprecate-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-oldversions-deprecate-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
