Hi Rob, I'm circling back to an earlier point in the thread to cover all
of the issues. (Thomas and I just discussed these topics, but Yaron was
not able to join our call because of illness.)
On 7/14/22 9:06 AM, Peter Saint-Andre wrote:
Hi Robert, thanks for the review. Comments inline.
On 7/14/22 3:37 AM, Robert Wilton via Datatracker wrote:
Robert Wilton has entered the following ballot position for
draft-ietf-uta-rfc7525bis-09: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-uta-rfc7525bis/
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
Hi,
Thanks for this document, I think that it is a helpful update.
Disclaimer, I'm
not a security expert, but I would like to discuss some of the RFC 2119
constraints that have been specified please:
(1)
I find some of the 2119 language to be somewhat contradictory:
* Implementations MUST NOT negotiate TLS version 1.1 [RFC4346].
* Implementations MUST support TLS 1.2 [RFC5246] and MUST prefer to
negotiate TLS version 1.2 over earlier versions of TLS.
The second sentence implies that a TLS 1.2 is allowed to negotiate
earlier
versions of TLS, but a previous statement indicates that this is not
allowed.
A similar contradiction appears for DTLS:
* Implementations MUST NOT negotiate DTLS version 1.0 [RFC4347].
* Implementations MUST support DTLS 1.2 [RFC6347] and MUST prefer to
negotiate DTLS version 1.2 over earlier versions of DTLS.
Based on other reviews, I think we already have a fix for this:
https://github.com/yaronf/I-D/pull/447/files
We've had further discussion about this and related topics, but my take
is that if, as discussed later in the thread, we carve out QUIC from the
general recommendations (because it is a special case) then the text in
that PR should be appropriate for its intended purpose (it does not
address the wider issue of changing TLS 1.3 to MUST and/or TLS 1.2 to
SHOULD).
See also (re QUIC):
https://github.com/yaronf/I-D/pull/460
(2)
* New protocol designs that embed TLS mechanisms SHOULD
use only TLS
1.3 and SHOULD NOT use TLS 1.2; for instance, QUIC
[RFC9001]) took
this approach. As a result, implementations of such
newly-
developed protocols SHOULD support TLS 1.3 only with no
negotiation of earlier versions.
Why is this only a SHOULD and not a MUST? If a new protocol (rather
than an
updated version of an existing protocol) was being designed why would
it be
reasonable to design it to support TLS 1.2? If you want to keep these as
SHOULD rather than MUSTs then please can the document specify under what
circumstances it would be reasonable for a new protocol design to use
TLS 1.2.
Although personally I'm open to MUST here, I'd like to discuss that with
my co-authors (one of whom is offline this week).
Unfortunately Yaron was not able to join our call, but Thomas and I
discussed it and we think there could be two different cases:
(a) new security-focused protocols such as QUIC
(b) new application protocols (say, for real-time collaboration)
For (a), it definitely makes sense to use TLS 1.3 only (as noted in the
current text, QUIC uses the TLS handshake protocol with a different
record layer).
For (b), we see reasons why it might make sense to build on top of both
TLS 1.2 and TLS 1.3 at the present time: for instance, implementations
might want to "cast a wide net" in terms of underlying library or
operating support and thus avoid the significant effort involved in
building a secure transport protocol such as QUIC. Naturally, this
advice will probably change in 7525ter a few years from now.
(3)
When TLS-only
communication is available for a certain protocol, it MUST be used
by implementations and MUST be configured by administrators. When
a protocol only supports dynamic upgrade, implementations MUST
provide a strict local policy (a policy that forbids use of
plaintext in the absence of a negotiated TLS channel) and
administrators MUST use this policy.
The MUSTs feel too strong here, since there are surely deployments and
streams
of data where encryption, whilst beneficial, isn't an absolute
requirement?
In addition "MUST be used by implementations and MUST be configured by
administrators" also seem to conflict, i.e., if the implementation
must use it
then why would an administrator have to enable it?
I believe this is a duplicate of an issue that other folks have already
raised:
https://github.com/yaronf/I-D/issues/437
At https://github.com/yaronf/I-D/pull/461 I'm proposing the following text:
###
When TLS-only communication is available for a certain protocol, it MUST
be supported by implementations and MUST be configured by administrators
in preference to a dynamic upgrade method. When a protocol only supports
dynamic upgrade, implementations MUST provide a way for administrators
to set a strict local policy that forbids use of plaintext in the
absence of a negotiated TLS channel, and administrators MUST use this
policy.
###
(4)
When using RSA, servers MUST 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 ([RFC9155], and see [CAB-Baseline] for more details).
So, for clarity, this would presumably mean that SHA-256 is also
preferred over
say SHA-512? Is that the intention? Or would it be better if the SHOULD
allowed stronger ciphers?
I think we should probably say "SHA-256 or stronger", but again I'd like
to see what my co-authors think.
See separate note by Thomas Fossati.
Peter
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
