Re: [TLS] potential attack on TLS cert compression

2018-03-22 Thread Thomas Pornin
poor compression ratios. A 32 kB window is a lot for the kind of architecture that BearSSL targets. --Thomas Pornin ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] draft-thomson-tls-record-limit-00

2017-03-28 Thread Thomas Pornin
_parameter" alert. The "max_fragment_length" extension is completely client-driven: it is used only on the client's initiative, and uses the client's length. The server's only choice is to accept the will of the client, or reject the connection. Thus, it hand

Re: [TLS] RFC 6066 - Max fragment length negotiation

2017-03-21 Thread Thomas Pornin
dpoint requires small records, then it cannot really talk with peers that don't support the proposed maximum_record_size extension, so it needs recent implementations that _should_ already implement at least TLS 1.2 and some AEAD cipher suites.) --Thomas Pornin

Re: [TLS] RFC 6066 - Max fragment length negotiation

2017-03-17 Thread Thomas Pornin
On Fri, Mar 17, 2017 at 04:44:48PM +0200, Ilari Liusvaara wrote: > The mere thought of someone implementing streaming processing in > C scares me. I think BearSSL autogenerates that code. Yes, actual code is in a custom Forth dialect, which is compiled to token-threaded code executed by a C

Re: [TLS] RFC 6066 - Max fragment length negotiation

2017-03-17 Thread Thomas Pornin
in TLS 1.3 that supporting the extension is mandatory. Otherwise, chances are that Web browsers won't implement it anyway. I can prototype things in BearSSL (both client and server). --Thomas Pornin ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead

2017-03-01 Thread Thomas Pornin
a stronger legacy foothold.) --Thomas Pornin ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

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

2016-12-02 Thread Thomas Pornin
on and with a trend toward simplification: the _operational_ notion is to lump versions into two groups, the ones that must be used and the ones that must not be used. There is about nothing IETF can do about it (though a really poorly chosen name might increase confusion even further).

Re: [TLS] Maximum Fragment Length negotiation

2016-11-29 Thread Thomas Pornin
nclusion in the TLS 1.3 draft. What is the process for submitting such text? --Thomas Pornin ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Certificate compression (a la QUIC) for TLS 1.3

2016-11-29 Thread Thomas Pornin
happy. --Thomas Pornin ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

[TLS] Maximum Fragment Length negotiation

2016-11-24 Thread Thomas Pornin
ght direction. Any comments / suggestions ? Thanks, --Thomas Pornin ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls