On 7/12/22 2:57 PM, Roman Danyliw via Datatracker wrote:
Roman Danyliw has entered the following ballot position for
draft-ietf-uta-rfc7525bis-09: Yes
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/
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
Thank you to Ben Kaduk for the SECDIR review.
** Section 3.2
When TLS-only
communication is available for a certain protocol, it MUST be used
by implementations and MUST be configured by administrators.
This guidance seems a little vague but prescriptive. Is the guidance that if
there is a TLS-version or TLS support for a given protocol, that
implementations of that protocol “MUST” support it? My confusion is around the
wording that “it must be used by implementations.”
The idea is that if the protocol has a way to ensure that TLS is used
(e.g., port 443 in HTTP), then it is safer to use that method than to
perform dynamic upgrade. This isn't about using TLS or not using TLS,
but about which method is used (if a protocol supports a TLS-only
mode/port and a dynamic upgrade mode/port). We thought this would have
been clear from the context of the paragraph.
Perhaps this would be clearer?
OLD
When TLS-only
communication is available for a certain protocol, it MUST be used
by implementations and MUST be configured by administrators.
NEW
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.
** Section 3.2
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.
Aren’t site administrators responsible for setting and enforcing local policy?
Why would the software vendor (implementations) be provided the policy?
Perhaps it would be clearer to say that implementations must provide the
ability for administrators to set a strict local policy?
** Section 3.3.1
-- Given that the recommendations of this section include things beyond
certificate compression, is the title of “Certificate Compression” appropriate?
The recommendations in this section are limited to certificate
compression, so I think the section title is fine.
-- Would there be any additional techniques to list per Section 4 of RFC9191?
Thanks for the pointer; I had not been aware of RFC 9191. Are those
methods limited to EAP? An informational reference to that RFC might be
appropriate.
** Section 4.4
When a sender is approaching CL, the implementation SHOULD initiate a
new handshake (or in TLS 1.3, a Key Update) to rotate the session
key.
When a receiver has reached IL, the implementation SHOULD close the
connection.
Should these normative SHOULDs be MUSTs? What is the circumstance where it
would be prudent or necessary sender to use the existing key material after the
CL has been exceeded? Same issue on the IL limit.
We (the co-authors) will discuss this topic and reply again.
Peter
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
