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

, 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

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

ion 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&#

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

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

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 usu

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

st 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

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

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

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

y the needs of security? We believe it would work better than complexifying the simple COMPRESS command, and that it no longer introduces potential security issues in the default configuration (whereas the previous version did). -- Julien ÉLIE « A man inserted an 'ad' in the class

Re: [TLS] [Uta] Compression along with TLS in NNTP

on, 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 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

ression dictionary after every response. -- Julien ÉLIE « Ta remise sur pied lui a fait perdre la tête ! » (Astérix) ___ 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) ___ T

[TLS] Compression along with TLS in NNTP

T 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

(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

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

mpatible 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

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

ticles requires more band-width. Not much for a text-only feed of course. As for a full binary feed, compression will be welcome (a news server may inject binaries and send them to dozens of peers at the same time, which consumes band-width). -- Julien ÉLIE « – Je ne peux que vous pr

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

? Thanks for that checkpoint in the discussion! I think the counter-arguments given so far all fall in that sentence. Maybe we could say "if TLS 1.2 has a flaw or if I want to benefit of the new facilities provided with TLS 1.3" to be more general. -- Julien ÉLIE « – Je ne pe

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 !

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

ompression, according to their needs. It is what happened with BEAST: Firefox and Chrome disabled TLS compression. -- Julien ÉLIE « Tant qu'il y a des marmites, il y a de l'espoir ! » (Astérix) ___ TLS mailing list TLS@ietf.org https://

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

egotiate 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 m

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

x27;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

lysis 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 reflecte

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

PASS badpassword 481 Authentication failed How compression would make NNTP weaker? (Brute-force attack is still necessary, even with compression enabled.) -- Julien ÉLIE « Etna : lave dévalante. » ___ TLS mailing list TLS@ietf.org https://www.ietf.org/ma

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

S 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 « E

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

nce Firefox, Apache...) Do we know how many protocols currently suffer from CRIME? Maybe a best practice could be suggested by UTA for the implementation of TLS in software, to disable compression if vulnerable. And for the others, to implement a way to enable/disable compression in case one da

Re: [TLS] RC4 cipher with NNTP (RFC 4642)

. Many thanks for your explanation. -- Julien ÉLIE « Quand on aime on ne compte pas… Ça tombe bien, je suis mauvaise en calcul ! » ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] RC4 cipher with NNTP (RFC 4642)

al! I will ask in the UTA list to have their opinion about what should be done. Have a nice week-end, -- Julien ÉLIE « Petite annonce : Sourd rencontrerait sourde pour terrain d'entente. » ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailma

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

is not always necessary), as RFC 4642 recalls: The STARTTLS command is usually used to initiate session security, although it can also be used for client and/or server certificate authentication and/or data compression. -- Julien ÉLIE « Petite annonce : Sourd rencontrerait sourde pour

Re: [TLS] RC4 cipher with NNTP (RFC 4642)

gain to all who answered, -- Julien ÉLIE « Audaces fortuna iuvat. » (inspiré de Virgile, pour les chauves) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] RC4 cipher with NNTP (RFC 4642)

rks well enough, and clients can if they desire more security restrict which CAs they are willing to accept as issuers of the fixed peer's certificate. Thanks again for having shared your thoughts. We'll take them into account (if of course we update RFC 4642). -- Julien ÉLIE « Audac

Re: [TLS] RC4 cipher with NNTP (RFC 4642)

cification, though. -- Julien ÉLIE « Vous savez, les idées, elles sont dans l'air. Il suffit que quelqu'un vous en parle de trop près, pour que vous les attrapiez ! » (Raymond Devos) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] RC4 cipher with NNTP (RFC 4642)

ervers. TLS is more wide-spread for the connection of a news client to a news server so as to read or post articles. -- Julien ÉLIE « Vous savez, les idées, elles sont dans l'air. Il suffit que quelqu'un vous en parle de trop près, pour que vous les att

[TLS] RC4 cipher with NNTP (RFC 4642)

phers still be explicitly mentioned, or the paragraph totally removed? (RFC 5246 that standardizes TLS 1.2 already has a Section 9 about the mandatory TLS_RSA_WITH_AES_128_CBC_SHA cipher suite.) Of course, if you see other things that should be amended in RFC 4242, do not hesitate to tell. Thanks be