Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

On Thu, Mar 23, 2017 at 10:11 AM, Andrei Popov <Andrei.Popov@microsoft.com>
wrote:

> Ø  Note that any client which in fact supports
>
> Ø  SHA-256 with TLS 1.2 but doesn't send signature_algorithms containing
> it,
>
> Ø  is noncomformant. It's not clear to me how many such clients in fact
> exist.
>
>
>
> We saw enough TLS 1.2 clients that are non-compliant in this way that I
> made the server-side change to accommodate them.
>
> Obviously, Martin Rex’s code is one example.
>

Thanks. That's interesting to know.

-Ekr

> I’ve also seen a number of embedded/IoT-oriented TLS stacks that had this
> defect initially, when they first implemented TLS 1.2, although they were
> quick to fix.
>
> Some of our customers in East Asia reported that the TLS stacks they used
> had this defect; when pointed at the RFC, they took the issue to the
> corresponding SW vendor(s).
>
> Overall, a small percentage, but it generated enough support calls that
> the server change was worthwhile.
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* TLS [mailto:tls-bounces@ietf.org] *On Behalf Of *Eric Rescorla
> *Sent:* Thursday, March 23, 2017 9:58 AM
> *To:* Fries, Steffen <steffen.fries@siemens.com>
> *Cc:* TLS WG <tls@ietf.org>
> *Subject:* Re: [TLS] Enforcing stronger server side signature/hash
> combinations in TLS 1.2
>
>
>
>
>
>
>
> On Thu, Mar 23, 2017 at 8:37 AM, Fries, Steffen <steffen.fries@siemens.com>
> wrote:
>
> Hi Erik,
>
>
>
> based on your reply my conclusion is that
>
> -          there is no (standard compliant) way for a server to use a
> SHA256 based certificate for server side authentication in cases where the
> client does not provide the signature_algorithm extension
>
> Not quite. If the client offers TLS 1.1 or below, then you simply don't
> know if it
>
> will accept SHA-256 and you should send whatever you have. If the client
> offers
>
> TLS 1.2 and no signature_algorithm extension, then you technically are
> forbidden
>
> from sending it a SHA-256 certificate. Note that any client which in fact
> supports
>
> SHA-256 with TLS 1.2 but doesn't send signature_algorithms containing it,
>
> is noncomformant. It's not clear to me how many such clients in fact exist.
>
>
>
> -          clients should always use the signature algorithm extension to
> ensure the server can apply a certificate with the appropriate crypt
> algorithms
>
> Yes.
>
>
>
> -Ekr
>
>
>
>
>
> Best regards
>
> Steffen
>
>
>
> On Thu, Mar 23, 2017 at 7:39 AM, Viktor Dukhovni <ietf-dane@dukhovni.org>
> wrote:
>
>
> > On Mar 23, 2017, at 10:31 AM, Fries, Steffen <steffen.fries@siemens.com>
> wrote:
> >
> > According to  TLS 1.2 section 7.4.1.4.1. a client may use the
> > signature_algorithm extension to signal any combinations the
> > client supports, listed in the order of preferences.
>
> The signature algorithm is primarily about signatures made as part
> of the TLS handshake, and not so much signatures in certificates.
>
>
>
> This does not seem consistent with https://tools.ietf.org/
> rfcmarkup?doc=5246#section-7.4.2
>
>
>
> "If the client provided a "signature_algorithms" extension, then all
> certificates provided by
>
> the server MUST be signed by a hash/signature algorithm pair that appears
> in that extension."
>
>
>
> I appreciate that there are people who feel that this rule is bad, and
>
> to some extent it has been relaxed in 1.3, but I think the text is
>
> pretty clear here.
>
>
>
>
>
> > If the client does not use this extension, the server must use the
> > signature algorithm in combination with SHA1.
>
> For signing the TLS key exchange, however, it should still present
> whatever certificate chain it has, even if that chain employs SHA256.
> It is exceedingly unlikely these days that a client will not support
> SHA256 signatures in the certificate chain.
>
>
>
> Yes, that's generally true. Though a TLS 1.2 client which does not offer
> SHA-256
>
> in its ClientHello but accepts SHA-256 is broken. So, this should generally
>
> only happen with TLS 1.1 and below.
>
>
>
>
>
>
>
> > Unfortunately the server is not allowed to use this extension, otherwise
> > he could tell the client his preferences according to his security
> policy.
>
> The protocol (as it should) lacks the additional round-trips necessary for
> the server to initiate signature algorithm negotiation.
>
>
>
> I'm not sure quite what the OP Is trying to achieve here. For certificates
> offered
>
> by the server, the client just tells you what algorithms it will accept
> for no negotiation
>
> is needed. For certificates offered by the client, the server tells the
> client
>
> what algorithms it will accept in the CertificateRequest.
>
> https://tools.ietf.org/rfcmarkup?doc=5246#section-7.4.4
>
>
>
> -Ekr
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
>