For the record, NSS servers always pick their choices first, except for key shares in TLS 1.3 where P-256 and X25519 are considered equal and the one with a share wins. Some servers do similar things for ChaCha20Poly1305 vs. AES-128-GCM, where maybe client ordering indicates a preference where the server doesn't care. For instance, the client might not have AES-NI or equivalent and so prefer not to use AES. We never got around to implementing that one, but its the other case I'm aware of. Otherwise, servers can and do pick what they like, which is usually the right way around in my opinion. On Wed, Nov 14, 2018 at 6:12 PM Russ Housley <[email protected]> wrote: > > 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 policy. > > Russ > > > On Nov 14, 2018, at 2:07 AM, Loganaden Velvindron <[email protected]> wrote: > > 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: I believe it is still standards compliant. RFC5246 says > only that it must be sent by the client in preference order. It does not say > the server must respect the order. > " > My suggestion would be something like: > Section 7.4.1.4.1. current text: > > Servers MUST NOT send this extension. TLS servers MUST support receiving this > extension. > Suggestion: > Servers MUST NOT send this extension. TLS servers MUST support receiving this > extension. TLS servers MUST respect the order in which the signature > algorithms are sent by the client. > > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
