> On Jan 21, 2021, at 16:50, Daniel Migault <mglt.ietf@xxxxxxxxx> wrote:
>
> Hi,
>
> First I deeply apologize for taking so long to respond, I just realized now these responses.
No worries it does happen that I miss email from time to time too ;)
> I do not believe a review of IoT protocol is needed, I am more thinking that TLS document should serve as a base guidance for TLS. Specific needs for IoT are addressed based on the generic guidances. In some cases specific extensions, cipher suites - not referenced by IANA as recommended - will be needed to address specific corner cases.
I agree with you since the TLS RFC provides the general use case. Other RFCs can specify other use cases. The way we handled this for CCM_8 suites was to include the following note:
Note
CCM_8 cipher suites are not marked as "Recommended". These
cipher suites have a significantly truncated authentication tag
that represents a security trade-off that may not be appropriate
for general environments.
spt
> Yours,
> Daniel
>
> On Tue, Oct 27, 2020 at 11:32 PM Sean Turner <sean@xxxxxxxxx> wrote:
>
>
> > On Oct 27, 2020, at 10:32, Daniel Migault <mglt.ietf@xxxxxxxxx> wrote:
> >
> > To address the comment below, keeping weak security is likely to weaken current and future IoT communications, so I do not think there is room for compromise with performance. Of course this is in a context of TLS. I expect protocol to leverage from TLS security, so the impact should be rather negligible.
> >
> > """
> > As those hash algorithms were 'cheap' for TLS 1.2, I would appreciate a review of impacted IoT protocols if those algorithms are deprecated.
> > """
>
> In terms of process, are you suggesting "a review of impacted IoT protocols if those algorithms are deprecated” MUST be completed prior to advancing this document to the IESG?
>
> spt
>
> > Yours,
> > Daniel
> >
> >
> > On Tue, Oct 27, 2020 at 10:21 AM Daniel Migault via Datatracker <noreply@xxxxxxxx> wrote:
> > Reviewer: Daniel Migault
> > Review result: Ready with Nits
> >
> > Hi,
> >
> >
> > I reviewed this document as part of the IoT Directorate's ongoing effort to
> > review all IETF documents being processed by the IESG. These comments were
> > written primarily for the benefit of the Security Area Directors. Document
> > authors, document editors, and WG chairs should treat these comments just like
> > any other IETF Last Call comments.
> >
> > Review Results: Ready with Nits
> >
> > Please find my comments below.
> >
> > Yours,
> > Daniel
> >
> >
> > Deprecating MD5 and SHA-1 signature hashes in TLS 1.2
> > draft-ietf-tls-md5-sha1-deprecate-04
> > [...]
> >
> > 1. Introduction
> >
> > The usage of MD5 and SHA-1 for signature hashing in TLS 1.2 is
> > specified in [RFC5246]. MD5 and SHA-1 have been proven to be
> > insecure, subject to collision attacks [Wang]. In 2011, [RFC6151]
> > detailed the security considerations, including collision attacks for
> > MD5. NIST formally deprecated use of SHA-1 in 2011
> > [NISTSP800-131A-R2] and disallowed its use for digital signatures at
> > the end of 2013, based on both the Wang, et. al, attack and the
> > potential for brute-force attack. In 2016, researchers from INRIA
> > identified a new class of transcript collision attacks on TLS (and
> > other protocols) that rely on efficient collision-finding algorithms
> > on the underlying hash constructions [Transcript-Collision].
> > Further, in 2017, researchers from Google and CWI Amsterdam
> > [SHA-1-Collision] proved SHA-1 collision attacks were practical.
> > This document updates [RFC5246] and [RFC7525] in such a way that MD5
> > and SHA-1 MUST NOT be used for digital signatures. However, this
> > document does not deprecate SHA-1 in HMAC for record protection.
> >
> > <mglt>
> > RFC6194 may be mentioned as a reference for
> > not deprecating HMAC-SHA-1 as well as an
> > additional reference to [NISTSP800-131A-R2].
> >
> > Reading the text the situation of HMAC with
> > MD5 is unclear. Since we specify that SHA-1
> > is not deprecated for HMAC we may specify
> > the status for HMAC with MD5. Given RFC6151 I
> > hope the reason is that MD5 and HMAC-MD5 has
> > already been deprecated but I have not found
> > this. Maybe that would worth mentioning it
> > is deprecated already.
> >
> > </mglt>
> >
> > [...]
> >
> > 2. Signature Algorithms
> >
> > Clients MUST NOT include MD5 and SHA-1 in the signature_algorithms
> > extension. If a client does not send a signature_algorithms
> > extension, then the server MUST abort the handshake and send a
> > handshake_failure alert, except when digital signatures are not used
> > (for example, when using PSK ciphers).
> >
> > <mglt>
> > It seems to me that the server behavior might
> > be defined as well. In our case this could be
> > something around the lines the server MUST
> > ignore MD5 and SHA1 values in the signature
> > algorithm extension.
> >
> > </mglt>
> >
> > 3. Certificate Request
> >
> > Servers SHOULD NOT include MD5 and SHA-1 in CertificateRequest
> > messages.
> >
> > <mglt>
> > It seems to me that the same level of
> > authentication should be provided for both
> > peers and that server MUST NOT include MD5
> > or SHA-1.
> >
> > A SHOULD NOT status might be welcome for a
> > smooth transition. At that time, collision
> > for MD5 and SHA1 are known for years. It is likely
> > that software that still need MD5 or SHA1 are
> > likely to never upgrade, so I doubt a smooth
> > path worth being taken.
> > </mglt>
> >
> > 4. Server Key Exchange
> >
> > Servers MUST NOT include MD5 and SHA-1 in ServerKeyExchange messages.
> > If a client receives a MD5 or SHA-1 signature in a ServerKeyExchange
> > message it MUST abort the connection with the illegal_parameter
> > alert.
> >
> > <mglt>
> > As per section 2, the client has clearly
> > indicated it does not support signature with
> > MD5/SHA1, so Server Key Exchange should not
> > end up with signature with SHA1/MD5.
> >
> > """
> > If the client has offered the "signature_algorithms" extension, the
> > signature algorithm and hash algorithm MUST be a pair listed in that
> > extension.
> > """
> >
> > It also seems to me that the constraint of
> > including a MD5 and SHA-1 signature is
> > related to the Certificate. I suspect that
> > some clarification are needed here.
> >
> > Since the case where the extension becomes
> > mandatory, the quoted text above of RFC 5246
> > might be updated as well, though this does
> > not appear that necessary.
> >
> > </mglt>
> >
> > 5. Certificate Verify
> >
> > Clients MUST NOT include MD5 and SHA-1 in CertificateVerify messages.
> > If a server receives a CertificateVerify message with MD5 or SHA-1 it
> > MUST abort the connection with handshake_failure or
> > insufficient_security alert.
> >
> >
> > <mglt>
> >
> > 6. Certificate
> >
> > Unless I am missing something, it seems to me
> > that signature may also be found in the
> > Certificate messages for the chain as well in
> > the restriction of the signature algorithm.
> > The end certificate is associated to the peer
> > while other certificate are related to a CA.
> >
> > It seems that client and server behavior may
> > be specified. The quoted text below may be
> > helpful to clarify.
> >
> > """
> > 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.
> > """
> >
> > </mglt>
> >
> > 6. Updates to RFC5246
> >
> > [RFC5246], The Transport Layer Security (TLS) Protocol Version 1.2,
> > suggests that implementations can assume support for MD5 and SHA-1 by
> > their peer. This update changes the suggestion to assume support for
> > SHA-256 instead, due to MD5 and SHA-1 being deprecated.
> >
> > In Section 7.4.1.4.1: the text should be revised from:
> >
> > OLD:
> >
> > "Note: this is a change from TLS 1.1 where there are no explicit
> > rules, but as a practical matter one can assume that the peer
> > supports MD5 and SHA- 1."
> >
> > NEW:
> >
> > "Note: This is a change from TLS 1.1 where there are no explicit
> > rules, but as a practical matter one can assume that the peer
> > supports SHA-256."
> >
> >
> > <mglt>
> > I am reading the Note as an explanation on
> > why sha was taken as the default hash
> > function with the following rules.
> >
> > """
> > If the client does not send the signature_algorithms extension, the
> > server MUST do the following:
> >
> > - If the negotiated key exchange algorithm is one of (RSA, DHE_RSA,
> > DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had
> > sent the value {sha1,rsa}.
> >
> > - If the negotiated key exchange algorithm is one of (DHE_DSS,
> > DH_DSS), behave as if the client had sent the value {sha1,dsa}.
> >
> > - If the negotiated key exchange algorithm is one of (ECDH_ECDSA,
> > ECDHE_ECDSA), behave as if the client had sent value {sha1,ecdsa}.
> > """
> >
> > The current document does not update the
> > default hash function from sha to sha256 to
> > avoid interoperability issue where one peer
> > takes sha while the other one takes sha-256.
> > As a results, these rules and the "Note" may
> > eventually all together be replaced by your
> > text of section 2.
> >
> > The following text may also be removed:
> >
> > """
> > If the client supports only the default hash and signature algorithms
> > (listed in this section), it MAY omit the signature_algorithms
> > extension.
> > """
> >
> > Regarding the Note, it seems to be that the
> > removal of support for MD5/SHA1 will result
> > in interoperability issues. At this point,
> > the issue is due to the obsolescence of the
> > implementation as deprecation of SHA1/Md5 has
> > started a long time ago.
> >
> > It is unclear to me how normative is
> > interpreted "can assume". Was the support of
> > MD5/SHA1 a SHOULD or a MUST? In both case, if
> > we were willing to maintain interoperability
> > between software that only implemented
> > MD5/SHA1, we should take a slower path and
> > introducing SHA-256 and having were MD5/SHA1
> > kept for interoperability purpose before
> > being deprecated. I do not think we should
> > take that path as implementations that
> > currently do not support SHA-256 are unlikely
> > to be updated and that deprecation of
> > SHA1/MD5 has started a long time ago.
> >
> > I would however mention the issue of
> > interoperability in the section but not in
> > the text to update. In the text to update I
> > would maybe suggest that the support of
> > SHA-256 comes with a normative MUST
> > statement.
> >
> >
> > </mglt>
> >
> > Velvindron, et al. Expires April 12, 2021 [Page 3]
> >
> > Internet-Draft draft-ietf-tls-md5-sha1-deprecate October 2020
> >
> >
> > 7. Updates to RFC7525
> >
> > [RFC7525], Recommendations for Secure Use of Transport Layer Security
> > (TLS) and Datagram Transport Layer Security (DTLS) recommends use of
> > SHA-256 as a minimum requirement. This update moves the minimum
> > recommendation to use stronger language deprecating use of both SHA-1
> > and MD5. The prior text did not explicitly include MD5 or SHA-1; and
> > this text adds guidance to ensure that these algorithms have been
> > deprecated..
> >
> > Section 4.3:
> >
> > OLD:
> >
> > When using RSA, servers SHOULD authenticate using certificates with
> > at least a 2048-bit modulus for the public key. In addition, the use
> > of the SHA-256 hash algorithm is RECOMMENDED (see [CAB-Baseline] for
> > more details). Clients SHOULD indicate to servers that they request
> > SHA-256, by using the "Signature Algorithms" extension defined in TLS
> > 1.2.
> >
> > NEW:
> >
> > Servers SHOULD authenticate using certificates with at least a
> > 2048-bit modulus for the public key.
> >
> > In addition, the use of the SHA-256 hash algorithm is RECOMMENDED;
> > and SHA-1 or MD5 MUST NOT be used (see [CAB-Baseline] for more
> > details). Clients MUST indicate to servers that they request SHA-
> > 256, by using the "Signature Algorithms" extension defined in TLS
> > 1.2.
> >
> > <mglt>
> > I understand the reason we do specify that
> > hash algorithms that MUST NOT been used. This
> > is fine in the context of this document, but
> > it seems to me that if we were writing the
> > updated specification we may have rather
> > mentioned a minimum level of security hash
> > function needs to be met - in our case
> > SHA-256. I leave the co-authors make the
> > appropriated choice.
> >
> > </mglt>
> >
> >
> > 8. IANA Considerations
> >
> > The document updates the "TLS SignatureScheme" registry to change the
> > recommended status of SHA-1 based signature schemes to N (not
> > recommended) as defined by [RFC8447]. The following entries are to
> > be updated:
> >
> > +--------+----------------+-------------+-------------------+
> > | Value | Description | Recommended | Reference |
> > +--------+----------------+-------------+-------------------+
> > | 0x0201 | rsa_pkcs1_sha1 | N | [RFC8446][RFCTBD] |
> > | 0x0203 | ecdsa_sha1 | N | [RFC8446][RFCTBD] |
> > +--------+----------------+-------------+-------------------+
> >
> > Other entries of the resgistry remain the same.
> >
> >
> > <mglt>
> > It seems to me that TLS 1.2 is using the TLS
> > hash and TLS signature registry TLS signature
> > registry and TLS 1.3 is using Signature
> > Scheme.
> >
> > I suspect that TLS hash values for sha1 and
> > md5 should be deprecated. And RFCTBD should
> > be added for sha1 and md5. Note that the
> > SHOULD NOT status for CertificateRequest
> > may have prevented such deprecation.
> >
> > A side effect is these code points for
> > signature scheme that were assigned for
> > compatibility with legacy (TLS 1.2)
> > signatures must not be used anymore - if
> > there are no more valid with TLS 1.2.
> > </mglt>
> >
> >
> >
> >
> > _______________________________________________
> > TLS mailing list
> > TLS@xxxxxxxx
> > https://www.ietf.org/mailman/listinfo/tls
> >
> >
> > --
> > Daniel Migault
> > Ericsson
>
>
>
> --
> Daniel Migault
> Ericsson
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
