Re: [TLS] I-D Action: draft-ietf-tls-oldversions-deprecate-01.txt
Hi Stephen, And RFC 7525 (belonging to BCP 195) states in Section 3.1.1: o Implementations SHOULD NOT negotiate TLS version 1.1 [...] o Implementations MUST support TLS 1.2 [RFC5246] and MUST prefer to negotiate TLS version 1.2 over earlier versions of TLS. That's why I thought RFC 8143 was already requiring not to use TLS 1.1. SHOULD NOT != MUST NOT though:-) And in any case, an additional unnecessary update would be no harm in this case, so I figure it's best to leave it as-is. Sure. (Unless I'm missing some reason why that UPDATE would do damage, in which case, we should chat more.) No damage at all. You can leave it as-is. So, yes, I've added 7525 to the list of UPDATEd stuff in my copy and made a change of intended status to BCP. (I bet a beer we'll change that again >1 time:-) :) -- Julien ÉLIE « Si l'art n'a pas de patrie, les artistes en ont une. » (Camille Saint-Saëns) ___ 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
Hi Stephen, That's why I suggest draft-ietf-tls-oldversions-deprecate does not update RFC 4642. It is no longer useful. Are you OK with this analysis? Sorta:-) I think these are overlapping but not quite identical updates. E.g. IIUC 8143 doesn't say to not use TLSv1.1. I added the sentence below to the editor's copy [1], but happy to do something else if I'm wrong, which is entirely possible;-) RFC 8143 (updating RFC 4642) states in Section 3: The best current practices documented in [BCP195] apply here. Therefore, NNTP implementations and deployments compliant with this document are REQUIRED to comply with [BCP195] as well. And RFC 7525 (belonging to BCP 195) states in Section 3.1.1: o Implementations SHOULD NOT negotiate TLS version 1.1 [...] o Implementations MUST support TLS 1.2 [RFC5246] and MUST prefer to negotiate TLS version 1.2 over earlier versions of TLS. That's why I thought RFC 8143 was already requiring not to use TLS 1.1. Incidentally, in the Abstract of draft-ietf-tls-oldversions-deprecate, it is said that this document updates RFC 7525, but RFC 7525 does not appear in the Updates list. Shouldn't it be added? -- Julien ÉLIE « Le rire est une chose sérieuse avec laquelle il ne faut pas plaisanter. » (Raymond Devos) ___ 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
Hi Stephen, 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. I believe updating RFC 4642 (TLS with NNTP) is useless because this RFC has already been updated by RFC 8143. In RFC 8143: A.6. Related to Other Obsolete Wording The first two sentences of the seventh paragraph in Section 2.2.2 of [RFC4642] are removed. There is no special requirement for NNTP with regard to TLS Client Hello messages. Section 7.4.1.2 and Appendix E of [RFC5246] apply. That is to say, the following sentences in RFC 4642 are no longer relevant: Servers MUST be able to understand backwards-compatible TLS Client Hello messages (provided that client_version is TLS 1.0 or later), and clients MAY use backwards-compatible Client Hello messages. Neither clients nor servers are required to actually support Client Hello messages for anything other than TLS 1.0. That's why I suggest draft-ietf-tls-oldversions-deprecate does not update RFC 4642. It is no longer useful. Are you OK with this analysis? -- Julien ÉLIE « Le rire est une chose sérieuse avec laquelle il ne faut pas plaisanter. » (Raymond Devos) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Obsolete TLS wording in EAP-TLS specification
Hi all, The EAP-TLS authentication protocol specification (RFC 5216) mentions in Section 2.4 that: - "EAP-TLS implementations MUST support TLS v1.0" - "SHOULD support TLS_RSA_WITH_RC4_128_SHA and TLS_RSA_WITH_RC4_128_MD5" And Sections 5.2, 5.3 and 5.4 do not give latest recommendations for certificate validation. Yet, EAP-TLS is wide-spread, and notably used with WPA and WPA2. Shouldn't it be updated in favour of following RFC 7525 (BCP for TLS) and RFC 6125 (guideline for certificate validation)? -- Julien ÉLIE « The following two statements are usually both true: There's not enough documentation. There's too much documentation. » (Larry Wall) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Confirming consensus: TLS1.3->TLS*
Hi all, The consensus in the room was to leave it as is, i.e., TLS1.3, and tonot rebrand it to TLS 2.0, TLS 2, or TLS 4. We need to confirm this decision on the list so please let the list know your top choice between: - Leave it TLS 1.3 - Rebrand TLS 2.0 - Rebrand TLS 2 - Rebrand TLS 4 Is there a reason why TLS 4.0 was not proposed? I would indeed vote for TLS 4.0 (I believe minor versions are useful to keep; bumping the major version should occur only when there are disruptive changes). TLS 4.0 gives people a stronger signal that it is a "must-have" (compared to 1.3), and prevent people from being confused by SSL 2 and 3. P.-S.: I would also suggest to use the TLS 1.3 name for "TLS 1.2 LTS". -- Julien ÉLIE « Ce que j'aime chez vous, c'est que vous savez jusqu'où on va trop loin. » (Cocteau) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Terminology clarification around SSL & TLS
Hi, The technology is SSL, and is sometimes also refered to as SSL/TLS. please no. the technology is TLS. + i would like to continue to be able to say unambiguously that all known versions of SSL are badly broken and should be avoided. Let's not muddy those waters further. + Let's not use a proprietary protocol name for a standard protocol. Conveniently, all SSL is broken now, long live TLS! There's still something I find confusing: on the one hand, SSL is badly broken and "diediedied", it is a proprietary protocol name, and the consensus in the TLS WG seems to be "long live TLS" but on the other hand major SSL/TLS implementations keep the SSL name living. When people look for TLS implementations, they will find OpenSSL, BoringSSL, LibreSSL, MatrixSSL, wolfSSL, etc. Besides, a developer will often use "-lssl" to link against TLS libraries. So, if the consensus is to prevent people who speak about or work on TLS from constantly viewing the SSL name, will forthcoming software releases change their name? Otherwise, confusion keeps being sustained... -- Julien ÉLIE « En voyant le lit vide, il le devint. » (Ponson du Terrail) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 -> TLS 2.0?
Hi all, I think it's time we just renamed TLS 1.3 to TLS 2.0. There are major changes, so labeling it a major version seems more appropriate. +1 to all of this. As people on the list know, I've been calling it "TLS 2.0-called-1.3" for a long time now. It really is a new protocol rather than something in the 1.x family, and it's quite misleading calling it 1.3. I am also in favour of a TLS 1.3 -> TLS 2.0 renaming. Considering that possible change, wouldn't it be useful to go on working on draft-gutmann-tls-lts-05, and consider TLS-LTS not as a TLS extension but as a real 1.3 version of the 1.x series? -- Julien ÉLIE ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Terminology clarification around SSL & TLS
Hi all, Following a recent discussion about how to name the successor of TLS 1.2, I wish to share an idea about a possible terminology clarification. I believe it could help to conciliate people understanding of SSL & TLS. We would have 3 notions: 1/ the technology, 2/ the protocols, 3/ the protocol versions. The technology is SSL, and is sometimes also refered to as SSL/TLS. (Note that bare TLS is not a technology.) The protocols are: - deprecated eponym SSL, - TLS, - DTLS. The protocol versions are: - 1.0, 2.0 and 3.0 for SSL, - 1.0, 1.1, 1.2 and 2.0 for TLS, - 1.0, 1.2 and 2.0 for DTLS. Any comments about that proposal? -- Julien ÉLIE ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Uta] Compression along with TLS in NNTP
Hi Jeffrey, Here is an extract of the paragraphs dealing with TLS in the draft, so that you can easily see what to comment (wording improvement, missing stuff...). The point of COMPRESS as an NNTP extension is to behave as a transport layer, similar to STARTTLS [RFC4642]. Compression can therefore benefit to all NNTP commands sent or received after the use of COMPRESS. It kind of sounds doomed under threat models with active attackers. The active attacker can swallow the STARTTLS message and no one would be the wiser. How does the protocol thwart downgrades under active attackers? First of all, one should note that STARTTLS is not widely used in practice for NNTP. Implicit TLS on a dedicated port (TCP 563) is the common way for NNTP clients to negotiate a TLS layer. To answer your question, the Security Considerations Section of RFC 4642 (Using TLS with NNTP) mentions: Before the TLS handshake has begun, any protocol interactions are performed in the clear and may be modified by an active attacker. For this reason, clients and servers MUST discard any sensitive knowledge obtained prior to the start of the TLS handshake upon the establishment of a security layer. Furthermore, the CAPABILITIES command SHOULD be re-issued upon the establishment of a security layer, and other protocol state SHOULD be re-negotiated as well. [...] During the TLS negotiation, the client MUST check its understanding of the server hostname against the server's identity as presented in the server Certificate message, in order to prevent man-in-the-middle attacks. Matching is performed according to these rules: - The client MUST use the server hostname it used to open the connection (or the hostname specified in TLS "server_name" extension [TLS-EXT]) as the value to compare against the server name as expressed in the server certificate. The client MUST NOT use any form of the server hostname derived from an insecure remote source (e.g., insecure DNS lookup). CNAME canonicalization is not done. - If a subjectAltName extension of type dNSName is present in the certificate, it SHOULD be used as the source of the server's identity. - Matching is case-insensitive. - A "*" wildcard character MAY be used as the left-most name component in the certificate. For example, *.example.com would match a.example.com, foo.example.com, etc., but would not match example.com. - If the certificate contains multiple names (e.g., more than one dNSName field), then a match with any one of the fields is considered acceptable. If the match fails, the client SHOULD either ask for explicit user confirmation or terminate the connection with a QUIT command and indicate the server's identity is suspect. Additionally, clients MUST verify the binding between the identity of the servers to which they connect and the public keys presented by those servers. Clients SHOULD implement the algorithm in Section 6 of [PKI-CERT] for general certificate validation, but MAY supplement that algorithm with other validation methods that achieve equivalent levels of verification (such as comparing the server certificate against a local store of already-verified certificates and identity bindings). A man-in-the-middle attack can be launched by deleting the STARTTLS capability label in the CAPABILITIES response from the server. This would cause the client not to try to start a TLS session. Another man-in-the-middle attack would allow the server to announce its STARTTLS capability, but alter the client's request to start TLS and the server's response. An NNTP client can partially protect against these attacks by recording the fact that a particular NNTP server offers TLS during one session and generating an alarm if it does not appear in the CAPABILITIES response for a later session. (Of course, the STARTTLS capability would not be listed after a security layer is in place.) If the client receives a 483 or 580 response, the client has to decide what to do next. The client has to choose among three main options: to go ahead with the rest of the NNTP session, to (re)try TLS later in the session, or to give up and postpone newsreading/transport activity. If an error occurs, the client can assume that the server may be able to negotiate TLS in the future and should try to negotiate TLS in a later session. However, if the client and server were only using TLS for authentication and no previous 480 response was received, the client may want to proceed with the NNTP session, in case some of the operations the client wanted to perform are accepted by the server even if the client is unauthenticated. Does it answer your question? -- Julien ÉLIE « Contra factum
Re: [TLS] [Uta] Compression along with TLS in NNTP
Last year, in September 2015, we spoke about the removal of TLS-level compression in TLS 1.2. Of course one should read "TLS 1.3". -- Julien ÉLIE « I don't worry about terrorism. I was married for two years. » (Sam Kinison) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Compression along with TLS in NNTP
, a server SHOULD NOT allow compression, and a client SHOULD NOT attempt to activate compression, for the same reasons as mentioned above in this Section. Implementations MUST support a configuration where compression can be easily disabled. Future extensions to NNTP that define commands conveying confidential data SHOULD ensure to state that they SHOULD NOT be used along with compression. Thanks again for your useful comments! -- Julien ÉLIE « Pourvu que ça dure ! » (Letizia Bonaparte) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - Support for compression to be removed
Hi all, > If compression is so important to NNTP, they should add first-class support. Period. They should not be relying on a poorly conceived feature which has been repeatedly demonstrated to introduce vulnerabilities in what is supposed to be a *security protocol* just because they don't want to implement compression themselves. An unsafe feature shouldn't be kept in TLS just because some protocols want to do unsafe things and are too lazy to implement their own compression. [Stephen] Compression does have issues clearly, but it's not correct to describe people wanting TLS to compress as lazy. They're rather looking for the same features that TLS has offered for a couple of decades. The good news is that the "first-class" NNTP compression support will soon be a reality. We've updated the draft of the COMPRESS command, and we hope to publish it as an RFC: https://tools.ietf.org/html/draft-murchison-nntp-compress-02 Interoperability is proven: both a news client (flnews) and a news server (INN) have implemented it. As far as security is concerned, authentication MUST be done *before* activating the compression layer (in other words, AUTHINFO is no longer valid after a successful use of COMPRESS). Thanks again guys for having put us to work on that NNTP extension! -- Julien ÉLIE « Aequum est ut cuius participauit lucrum, participet et damnun. » ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - Support for compression to be removed
Hi Bill, Well, it depends. How much security do people need. In the NNTP case, I can't see a strong argument for confidentiality. There may be a need for compression, which is why I suggested a "TLC" (Transport Level Compression) facility, which is, to the extent possible, API compatible with a TLS library. [...] What we need for NNTP is a build without security, but with compression option. And it is probably the case for protocols other than NNTP. The current discussion focuses on NNTP but I bet the same question can arise from other protocols. -- Julien ÉLIE « On a toujours tort d'essayer d'avoir raison devant des gens qui ont toutes les bonnes raisons de croire qu'ils n'ont pas tort. » (Raymond Devos) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - Support for compression to be removed
Hi Dave, No sane security protocol should allow any mode which is known to be insecure under its common use-case. Then the default in TLS 1.3 could be to not activate compression. TLS 1.2 is technically configurable in a secure manner, but hardly anyone does so correctly. With TLS 1.3, we need to get rid of all of the insecure modes so all configurations are secure (at least to start). This is compatible with keeping compression as a mode that can be explicitly activated. -- Julien ÉLIE « Tant qu'il y a des marmites, il y a de l'espoir ! » (Astérix) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - Support for compression to be removed
Hi Watson, Though I've read a few pages explaining how CRIME and BEAST attacks work, I still do not see well how TLS-level compression would make NNTP vulnerable. Same thing for POP or IMAP I believe. The news server does not leak information. The responses are just OK or KO. This analysis would predict that HTTP isn't vulnerable. I don't understand that point for AUTHINFO. NNTP only answers "281 Authentication succeeded" or "481 Authentication failed" here, whereas HTTP response bodies are far more complex and part of the request may be reflected in the response. -- Julien ÉLIE « Etna : lave dévalante. » ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - Support for compression to be removed
Hi Karthik, It may well be true that some (typically unauthenticated) application protocols on top of TLS can survive TLS compression, but it is unlikely. [...] HTTP is a particularly bad case because the attacker can potentially inject arbitrary data before (and after) the secret. With NNTP you may escape the worst of this adversary, but you probably won’t find any TLS expert willing to say that compressing the password is ok. OK, many thanks for the illustration! So in fact, to be safer, authentication commands should either be sent uncompressed or be more complex than they currently are (for instance with the insertion of random data with random length along with the authentication command). If TLS 1.3 is used, so without compression facility, adding a new COMPRESS command to NNTP will not help if how authentication is done is not strenghtened at the same time, won't it? Or AUTHINFO is not a valid command after the use of COMPRESS. -- Julien ÉLIE « Etna : lave dévalante. » ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - Support for compression to be removed
Hi Geoffrey, I bet other protocols would also need similar new specifications to explain how compression can be enabled. I think that's the idea. TLS compression only works for NNTP because no confidentiality is required. In other protocols, there's at least something (if not everything) where confidentality is desirable and so compression needs to be specified very carefully if at all. OK, understood. Even in NNTP, you don't want compression if you're using AUTHINFO---and how do you know AUTHINFO will or won't be used at the time of STARTTLS? Note that AUTHINFO can also use any available SASL mechanisms instead of sending plain user/pass. (Depending on the SASL mechanism, a security layer can be negotiated during the SASL exchange.) Unfortunately, that facility is not wide-spread in news clients and servers. To respond to your question, STARTTLS is not available after a successful authentication. Therefore, it cannot be used after STARTTLS. RFC 4642 states: A server supporting the STARTTLS command as defined in this document will advertise the "STARTTLS" capability label in response to the CAPABILITIES command ([NNTP] Section 5.2). However, this capability MUST NOT be advertised once a TLS layer is active (see Section 2.2.2) or after successful authentication [NNTP-AUTH]. However, though that practice is discouraged, most of news clients still connect to port 563 (dedicated to NNTPS) and negotiate a TLS security layer upon connection. They do not use STARTTLS in that case; and clients can authenticate with AUTHINFO, with an active TLS layer. -- Julien ÉLIE « Tant qu'il y a des marmites, il y a de l'espoir ! » (Astérix) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS 1.3 - Support for compression to be removed
Hi Loganaden, If compression is dropped at the TLS layer, you can still do it at the layer above it. Indeed. And, it's probably a better idea to do it in the layer above. Then how will the news server know that the client is compressing data after the use of STARTTLS where a security layer without compression has been negotiated? It cannot guess it; and it won't try all uncompression methods to see which one has been used. Unless you are speaking of an update of the NNTP protocol to add a new compression capability (for instance with the use of a new COMPRESS command with possible arguments), that could be used by clients? Well, it will require some work to specify it. Not to speak of its implementation afterwards. I bet other protocols would also need similar new specifications to explain how compression can be enabled. -- Julien ÉLIE « Etna : lave dévalante. » ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
