Ketan Talaulikar has entered the following ballot position for
draft-ietf-uta-tls13-iot-profile-23: 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-tls13-iot-profile/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks to the authors and the WG for their work on this document.

<discuss-1> I would like to discuss about three documents that are categorized
as informative but perhaps should be normative. Note: I may be wrong here since
I am not a subject matter expert and would be happy to be corrected.

Section 12

502        The Application-Layer Protocol Negotiation (ALPN) extension [RFC7301]
503        is independent of the credential type used for TLS authentication.

505        Implementations conforming to this profile MUST support ALPN.

RFC 7301 is needed to implement the required ALPN support. Therefore, it is
a Normative References?

Section 3

263        This profile considers three authentication modes for IoT devices:
264        (1) certificate-based, (2) raw public key-based and (3) external PSK-
265        based.  TLS/DTLS 1.3 supports both PSK-only and PSK with (EC)DHE key

Since RFC 7250 defines the certificate types, should it not be a normative
reference? Or have I got it wrong?

Section 19

1174       installed.  In these cases, the peer MAY use the Trusted CA
1175       Indication extension [RFC6066] to help the sender select an
1176       appropriate certificate chain.  During trust-anchor updates,

1191       *  The client certificate URL mechanism defined in Section 5 of
1192          [RFC6066] can replace client certificates in the handshake with
1193          references to external certificate objects.  When applications

Even if it is optional, it seems like RFC 6066 is referenced normatively?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Please find below one non-blocking comment also related to references :-)

The draft reference draft-ietf-tls-dtls-rrc (version 20) is stale.
It was replaced by rfc9853

The draft reference draft-ietf-tls-8773bis (version 13) is stale.
It was replaced by rfc9973

RFC7452 is an unused reference



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

Reply via email to