Re: [TLS] I-D Action: draft-ietf-tls-oldversions-deprecate-01.txt

, 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

Re: [TLS] I-D Action: draft-ietf-tls-oldversions-deprecate-01.txt

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

Re: [TLS] I-D Action: draft-ietf-tls-oldversions-deprecate-01.txt

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

test 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

Re: [TLS] Confirming consensus: TLS1.3->TLS*

nd 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) ___

Re: [TLS] Terminology clarification around SSL & TLS

braries. 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 l

Re: [TLS] TLS 1.3 -> TLS 2.0?

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

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

perations 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 non datur argumentum. » ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

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 ma

[TLS] Compression along with TLS in NNTP

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

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:/

Re: [TLS] TLS 1.3 - Support for compression to be removed

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

Re: [TLS] TLS 1.3 - Support for compression to be removed

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

Re: [TLS] TLS 1.3 - Support for compression to be removed

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 respon

Re: [TLS] TLS 1.3 - Support for compression to be removed

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

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://ww

Re: [TLS] TLS 1.3 - Support for compression to be removed

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