On Fri, May 15, 2020, at 20:29, Thomas Fossati wrote:
> While the specific behaviours might more or less differ, the same
> considerations apply to 1.2. How do we make sure that the message
> doesn't get ignored? Would it be worth drafting this separately to
> cover both versions (+ an explicit
Joseph Salowey has requested publication of
draft-ietf-tls-md5-sha1-deprecate-03 as Proposed Standard on behalf of the TLS
working group.
Please verify the document's state at
https://datatracker.ietf.org/doc/draft-ietf-tls-md5-sha1-deprecate/
___
RFC 5246 sec 7.4.4 states that "non-anonymous" servers can request a
client certificate, and otherwise attempting to request a certificate
should result in a fatal alert.
I would generally think of a handshake using PSK or SRP to not be
anonymous but rather the peer identity is implicitly
Issues
--
* tlswg/draft-ietf-tls-esni (+1/-0/0)
1 issues created:
- Trial decryption after HelloRetryRequest (by ocheron)
https://github.com/tlswg/draft-ietf-tls-esni/issues/233
* tlswg/dtls-conn-id (+1/-0/4)
1 issues created:
- Disallow sending MAC failure fatal alerts to
