Re: [TLS] Proposed Errata for rfc5246

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 <housley@vigilsec.com> 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 <loganaden@gmail.com> 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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls