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
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
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
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
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
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
>> 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
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
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
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
the binder.
Olivier Levillain
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
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
.
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
.
= 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
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
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...")
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
.
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
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
___
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
_
20 matches
Mail list logo