On 7/15/22 3:25 AM, Rob Wilton (rwilton) wrote:
Hi Peter,
-----Original Message-----
From: Peter Saint-Andre <stpe...@stpeter.im>
Sent: 14 July 2022 16:07
To: Rob Wilton (rwilton) <rwil...@cisco.com>; The IESG <i...@ietf.org>
Cc: draft-ietf-uta-rfc7525...@ietf.org; uta-cha...@ietf.org; uta@ietf.org;
le...@sunet.se
Subject: Re: Robert Wilton's Discuss on draft-ietf-uta-rfc7525bis-09: (with
DISCUSS and COMMENT)
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
But is "Implementations MUST support TLS 1.2 {{!RFC5246}}." really right?
Shouldn’t this be "Implementations MUST support TLS 1.2 {{!RFC5246}} or a later version"?
Otherwise, protocols like QUIC would presumably not be compliant with this BCP if they only
support TLS 1.3? Or alternatively, this could probably be stated as "Implementations MAY
support TLS 1.2 {{!RFC5246}}".
The implementations we've always had in mind for this document are
TLS/DTLS implementations, not implementations of protocols that re-use
TLS/DTLS in whole or in part (e.g. QUIC re-uses the handshake protocol
but not the record layer). However, that's not crystal clear in the
document because we only recently started mentioning QUIC. I'll talk
with my co-authors about this when we next have a chance to meet
regarding all the recent feedback.
<snip/>
(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
Okay, I still think that the proposed text isn't quite right - why would an
administrator need to configure it, if it used by the implementation?:
Hmm, I think "MUST be used by implementations" is not quite right - I
would prefer "MUST be supported by implementations" - but I'd like to
discuss this with my co-authors.
This topic of TLS-only vs. dynamic upgrade is a bit of a sore point for
me, because on the way to publishing RFC 3920 the IESG at the time
insisted that we remove the TLS-only ports for XMPP and instead mandate
the use of STARTTLS (because ports are precious and dynamic upgrade must
be just as good as TLS-only, right?). Fast forward 18 years and people
think differently, some folks in the XMPP community likely still use the
"forbidden" TLS-only ports (in violation of the IESG's edict from 2004),
etc. Do we implictly condone use of the forbidden ports by saying that
implementations MUST use TLS-only methods? Do we need to go back and
retrofit all the protocols that were told to use STARTTLS or other
dynamic upgrade methods? Do we need to request assignment of those
forbidden ports? What happens if the relevant folks still don't want to
assign those ports? And so on.
Current:
When a TLS-only
communication method is available for a certain protocol, it MUST
be used by implementations and MUST be configured by
administrators, in preference to a dynamic upgrade method.
Perhaps something like the following might be better:
When available, implementations MUST default to using a TLS-only
communication method in preference to any dynamic upgrade method. For legacy
implementations defaulting to a dynamic upgrade method, then administrators
SHOULD(*) configure the protocols to only use the TLS-only communication method
over any dynamic upgrade method and MUST advise service users to directly use
the TLS-only communication methods (e.g., for IMAP mail server settings).
(*) Perhaps this could be a MUST, but that would seem likely to be hard to
follow if that would break lots of customers ...
Yeah, this is getting complicated. Let me discuss with my co-authors (I
hope that happens next week) and we'll reply again.
Peter
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
