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?

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.

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.

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]



_______________________________________________
OPSAWG mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to