Re: [TLS] TLS1.3 + PSK with multiple identities

2016-10-03 Thread Olivier Levillain
Hi list, I have been working in the labs at ANSSI (the French Network and Information System Agency) for several years and I just defended my PhD thesis on the TLS ecosystem (documents are available at http://paperstreet.picty.org/~yeye/2016/phdthesis-Levillain16/). >> On Mon, 2016-09-19 at

Re: [TLS] Draft 18 review : Hello Retry Request and supported groups cache

2016-11-23 Thread Olivier Levillain
Hi, >> Being able to send supported_groups does allow a server to choose to make >> a tradeoff between an extra round trip on the current connection and its >> own group preferences. One example where a server might want to do this is >> where it believes that X25519 is likely a more future-proof

Re: [TLS] Draft 18 review: Downgrade protection

2016-11-23 Thread Olivier Levillain
Hi, > Thanks for your comments. I do want this section to be clear. > > It would be very helpful if you formatted this as a PR. That would make it > easier to understand the changes in this text. The text has been proposed as PR 775 (https://github.com/tlswg/tls13-spec/pull/775). olivier

Re: [TLS] Draft 18 review : Message splitting and interleaving

2016-11-23 Thread Olivier Levillain
Le 23/11/2016 00:24, Eric Rescorla a écrit : > On Tue, Nov 22, 2016 at 2:18 PM, David Benjamin <david...@chromium.org> > wrote: > >> On Tue, Nov 22, 2016 at 2:05 PM Olivier Levillain < >> olivier.levill...@ssi.gouv.fr> wrote: >> >>> Hi list, >&g

Re: [TLS] Draft 18 review : Extensions and message reuse

2016-11-23 Thread Olivier Levillain
Le 22/11/2016 22:19, Eric Rescorla a écrit : > On Tue, Nov 22, 2016 at 11:02 AM, Olivier Levillain < > olivier.levill...@ssi.gouv.fr> wrote: >> The first example of such a problem is the signature_scheme and >> signature_algorithms enums. In practice, the signature_a

Re: [TLS] Draft 18 review : 0-RTT

2016-11-23 Thread Olivier Levillain
Le 23/11/2016 01:28, Martin Thomson a écrit : > On 23 November 2016 at 06:07, Olivier Levillain > <olivier.levill...@ssi.gouv.fr> wrote: >> In 4.2.8 (P.47), the server receiving early_data "can behave in one of >> two ways"... followed by three cases. Beside

Re: [TLS] Draft 18 review : Hello Retry Request and supported groups cache

2016-11-23 Thread Olivier Levillain
>> There were actually two points in my message: >> - I was not convinced by this way of signalling a preference without >> enforcing it, but I understand that, if we keep supported_groups, it >> does not cost much and the client can safely ignore the server sent >> extension; >> - however, I

Re: [TLS] Draft 18 review : Message order

2016-11-23 Thread Olivier Levillain
Hi, > On Tue, Nov 22, 2016 at 11:08 AM, Olivier Levillain < > olivier.levill...@ssi.gouv.fr> wrote: > >> = Message order = >> >> I believe the message P.27 section 4 is important, but not >> sufficient. As already expressed on the list, a formal auto

[TLS] Draft 18 review: Downgrade protection

2016-11-22 Thread Olivier Levillain
over both random values, it is not possible for an active attacker to modify the randoms without detection as long as ephemeral ciphers are used. It does not provide downgrade protection when static RSA is used. I can propose a PR if this makes sense to the WG. Olivier

[TLS] Draft 18 review : Extensions and message reuse

2016-11-22 Thread Olivier Levillain
not need to have broader context (the message where the extension is included). In other words, we would like select syntax in structs to only use local information. I can try and propose a PR for each extension if there is an interest in the WG. Olivier Levillain

[TLS] Draft 18 review : PSK and PSK Binder

2016-11-22 Thread Olivier Levillain
the binder. Olivier Levillain ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

[TLS] Draft 18 review : 0-RTT

2016-11-22 Thread Olivier Levillain
erverHello. This indicates that the server has ignored any early data and an ordinary 1-RTT handshake is required. Olivier Levillain ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

[TLS] Draft 18 review : Message splitting and interleaving

2016-11-22 Thread Olivier Levillain
. I might volunteer some text if there is an interest of the WG. Olivier Levillain ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

[TLS] Draft 18 review : Message order

2016-11-22 Thread Olivier Levillain
. = Message order = I believe the message P.27 section 4 is important, but not sufficient. As already expressed on the list, a formal automaton should be provided in the spec. I think Ekr said there was some work in progress in this area. Is this a goal for the final specification? Olivier

[TLS] Draft 18 review : Minor remarks and typos

2016-11-22 Thread Olivier Levillain
g references concerning the analysis of the TLS record layer = Typos = - P.28 (section 4.1.1): a quote is missing after '"psk_key_exchange_modes' - P.46 (4.2.7): "A clients MUST provide" => "client" - P.54 (4.4.1): "If an extension applies the the entire chain" => "to the" - P.58 (4.4.2): "A single 0 byte which servers as the separator" => "serves" - P.63 (4.5.3): "If the request_udate" => request_update - P.86 (8.2): "and the TLS SignatureAlgorithm Registry to list values 4-233 as "Reserved"" => It should be 223 (as 224-255 are reserved for private use) Olivier Levillain ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

[TLS] Draft 18 review : Signature in certificates

2016-11-22 Thread Olivier Levillain
rom an out-of-band mechanism in this case) - when the only available chains use signature scheme are not known to be supported by the client - the case of SHA-1 is special The same confusion can be found in 4.4.2 P.59 ("If sent by a server...")

Re: [TLS] Deprecating alert levels

2016-10-26 Thread Olivier Levillain
Hi list, I recently saw a related CVE regarding OpenSSL on oss-security mailing list: CVE-2016-8610. The original mail is http://seclists.org/oss-sec/2016/q4/224. As I understand it, the idea is to send a continuous flow of unauthenticated, warning-level alerts in the middle of the initial

Re: [TLS] WGLC: draft-ietf-tls-tls13-19

2017-03-27 Thread Olivier Levillain
. Best regards, Olivier Levillain * One of these issues is that requiring Client Authentication upon an applicative request may lead a client to have to write records on a SSL_read call : 1) client and server complete the handshake 2) client sends a request (SSL_write) 3) server reads the request

Re: [TLS] WGLC: draft-ietf-tls-tls13-19

2017-03-31 Thread Olivier Levillain
simple extension in the ClientHello : https://github.com/tlswg/tls13-spec/pull/921/ I believe this proposal is a good trade-off allowing simpler implementation designs when late client authentication is not needed. Best regards, Olivier Levillain ___

Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-02.txt

2018-02-14 Thread Olivier Levillain
ady know that. Since the whole goal of this draft is to reduce the size of the message, I would strongly suggest this field be removed. It is too much a temptation to be considered as a reliable information for shaky implementations. Best regards, Olivier Levillain _