Skip to main content

Telechat Review of draft-ietf-uta-rfc7525bis-09
review-ietf-uta-rfc7525bis-09-secdir-telechat-kaduk-2022-07-12-00

Request Review of draft-ietf-uta-rfc7525bis
Requested revision No specific revision (document currently at 11)
Type Telechat Review
Team Security Area Directorate (secdir)
Deadline 2022-07-12
Requested 2022-06-29
Authors Yaron Sheffer , Peter Saint-Andre , Thomas Fossati
I-D last updated 2022-07-12
Completed reviews Secdir Last Call review of -07 by Benjamin Kaduk (diff)
Artart Last Call review of -09 by Cullen Fluffy Jennings (diff)
Genart Last Call review of -07 by Tim Evens (diff)
Secdir Telechat review of -09 by Benjamin Kaduk (diff)
Tsvart Telechat review of -09 by Magnus Westerlund (diff)
Assignment Reviewer Benjamin Kaduk
State Completed
Request Telechat review on draft-ietf-uta-rfc7525bis by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/rHQnO7m9cVqwyOTk5QLVB1SU8WA
Reviewed revision 09 (document currently at 11)
Result Ready
Completed 2022-07-12
review-ietf-uta-rfc7525bis-09-secdir-telechat-kaduk-2022-07-12-00
I looked over the updates from -07 to -09, and they all look good.
I recognize that not all of my previous comments resulted in any text
changes, and appreciate that they were given consideration and the
conscious choice made to not act.  I'd also like to thank the editors
for their efforts to proactively tag me in the github discussion that my
earlier review triggered, and I apologize for not keeping up with that
traffic as it came in.

I do have one comment on the new text:

Section 3.9

Thanks for adding the section on mulit-server deployment, that's a great
addition!  In the (first) "multiple services" case, we might also want
to mention that the protection of credentials (certificate private keys)
is a shared attack surface across services, so when we say "provide
equivalent levels of security" we might clarify that we consider both
the TLS configuration and the protections against server compromise as
being relevant.  (Even if the two services do not share
credentials/keys, which would itself be best practice, since they are on
the same domain name the credentials for one are likely to be usable for
impersonating the other.  Only if technologies like X.509 EKUs and/or
certificate extensions are used to restrict both certificates'
applicability does this risk disappear, and I'm reluctant to propose
adding extensive discussion of these topics to the draft at this stage
in the process.)


I'll also repeat one comment from my earlier review to make it more visible
to the ADs.  I acknowledge that the authors already responded to it and
that the same reply continues to apply; I do not expect that repeating my
statement will be any more convincing than it was the first time.

Section 3.1.1

   *  Implementations MUST support TLS 1.2 [RFC5246] and MUST prefer to
      negotiate TLS version 1.2 over earlier versions of TLS.
      [...]
   *  Implementations SHOULD support TLS 1.3 [RFC8446] and, if
      implemented, MUST prefer to negotiate TLS 1.3 over earlier
      versions of TLS.

It's very disappointing to me to see that we label a TLS 1.3-only
implementation as non-compliant with the BCP for TLS usage; such an
implementation is more secure than a joint 1.2+1.3 implementation.
That said, I assume that the WG discussed this topic extensively and
it seems somewhat unlikely that I have any new contributions to that
discussion.