For one remaining clarification, inline w/ [DC] On Fri, Jul 4, 2025 at 6:06 AM Douglas Gash (dcmgash) <[email protected]> wrote:
> Hello Deb, > > > > Many thanks for taking the time and for the comments and insights. > > > > Please see inline: > > > > *From: *Deb Cooley via Datatracker <[email protected]> > *Date: *Tuesday, 24 June 2025 at 14:11 > *To: *The IESG <[email protected]> > *Cc: *[email protected] < > [email protected]>, [email protected] < > [email protected]>, [email protected] <[email protected]>, > [email protected] <[email protected]>, Joe Clarke > (jclarke) <[email protected]>, Joe Clarke (jclarke) <[email protected]> > *Subject: *Deb Cooley's No Objection on > draft-ietf-opsawg-tacacs-tls13-23: (with COMMENT) > > Deb Cooley has entered the following ballot position for > draft-ietf-opsawg-tacacs-tls13-23: No Objection > > 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-opsawg-tacacs-tls13/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > I support Ketan's discuss. This protocol is in wide use, it would be > useful to > have the whole protocol be PS. > > Thanks to Russ Housley for their secdir review. > > Section 3, last sentence: This draft is almost in the RFC Editor's > queue. It > would be better if it could be a normative reference, since it is exactly > what > you are trying to specify here. > > Section 3.4.1: Sometimes these (both cert path validation and revocation > checking) can be quite hard. Many implementations of TLS allow a bypass > in the > case of network latency issues. And while it pains me to say this as 'a > PKI > person', you may need to consider whether there needs to be an allowance > for a > bypass. What happens if there are network issues blocking chains or OCSP? > > Is there a reference for this abort? Would prefer not to define a TLS > abort behaviour inside this doc. > [DC] not an abort, per se. Just a softening of the rules in the case that either OCSP or CRLs are not available. As I recall, this is a hard MUST in your draft (it has been a minute), where in many situations, it is listed as 'best effort' or try to check CRLs or OCSP, but don't fail if the network isn't cooperating. Not a big deal either way. > > > Section 5.1.2: There is an 'early data extension' that the client could > include to enable the ability to send early data. Perhaps the statement > 'A TLS > client or server MUST NOT include the "early_data" extension. See Section > 2.3 > and 4.2.10 of [RFC8446] for security concerns.' or something similar could > be > added. > > Agreed, will add. > > > > Section 5.1.5: 'subject to eavesdropping' because SNI is sent in the > clear in > the Client Hello? Would it be more direct to say something like, 'the TLS > SNI > extension is part of the TLS client hello, which is sent in cleartext and > is, > therefore...' That might make for an awkward sentence, which could be > split > into two sentences. > > Agreed, clarified the cleartext nature of the client hello. > > > > Section 5.2: Nit: just be sure the (TBD) is properly flagged for IANA. > > Section 5.3: I'm not sure it is necessary to throw STARTTLS 'under the > bus' as > it were. The point can be made w/out it (especially since no reference to > STARTTLS is supplied). I'd be happy to help with the re-write. > [https://en.wikipedia.org/wiki/Throw_under_the_bus] > > Agreed, we’ve removed references to STARTTLS. >
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
