Re: [TLS] Proposed Errata for rfc5246

The intent is that the server pick the most preferred signature algorithm that is supported and meets local policy. Given the local policy aspect of the server's choice, it can be any one offered by the client. The client should not offer any that are not acceptable according o their local

[TLS] Proposed Errata for rfc5246

Hi folks, Bob Beck of OpenBSD/LibreSSL reported this issue with an implementation: " Fun fact: The TLS 1.2 signature algorithms extension is sent in client preference order. http://outlook.office365.com then chooses the least preferred. every time. Additional fun fact:

Re: [TLS] Are we holding TLS wrong?

> - s2.5 Not sure what the ceremonies around flushing a neighbor are, > but I'd make explicit signalling EOD at least a SHOULD? It seems more > polite :-) > I agree, I upgraded politeness to a SHOULD. Note however that a neighbour is usually discarded when we loose too many Hellos

Re: [TLS] Are we holding TLS wrong?

> Yep, all of which speaks to some serious shortcomings of the > HMAC-based protocol. The scope of Babel-HMAC is deliberately limited. Babel-HMAC aims to implement the strict minimum of features that make it useful. Any deployment that needs features beyond what Babel-HMAC provides should use

Re: [TLS] Certificate keyUsage enforcement question (new in RFC8446 Appendix E.8)

> Nor have I, and I rather think that introducing fixed-(EC)DH ciphers into TLS > was a mistake, and glad to see them gone in TLS 1.3. I agree with the sentiment, but there is a concerted effort to bring fixed (EC)DH to TLS 1.3: