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 non-v
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 verifi
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/
___
T
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 "
Hi,
On 2020-05-06 08:00 +0200, Hanno Becker wrote:
>> The latter, to me, suggests that authenticating the pseudo-header alone
>> may not be sufficient. It would at least allow on-path modifications to
>> the on-the-wire header, which I don't expect is intended.
>
> Can we go a bit into this? As
Hi,
On 2020-05-17 07:35 +0200, Hanno Becker wrote:
> So, we're here at the moment:
> (1) Only the CID issue really _needs_ fixing somehow.
> (2) Other header fields are currently authenticated through a mixture of
> AAD, nonce, and implicit properties of the AEAD,
> and proof complexity doesn't s
