Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication
draft-ietf-netconf-rfc5539bis-10

-- Section 5 --

   presented X.509 certificate may also be considered valid if it
   matches a locally configured certificate fingerprint.  If X.509
   certificate path validation fails and the presented X.509 certificate
   does not match a locally configured certificate fingerprint,

It's probably worth it here to allow for things such as DANE, by slightly changing the wording.  what do you think of this, perhaps?:

NEW
   presented X.509 certificate may also be considered valid if it
   matches one obtained by another trusted mechanism, such as
   using a locally configured certificate fingerprint.  If X.509
   certificate path validation fails and the presented X.509 certificate
   does not match a certificate obtained by a trusted mechanism,
END

Does something like that make sense?  Or is it better to limit it to preconfigured certs?

-- Section 7 --

        Similarily, if the
        username does not comply to the NETCONF requirements on
        usernames [RFC6241] (i.e., the username is not representable in
        XML)

Checking: Is "not representable in XML" really the only way the username would not comply?  That is, is "i.e." correct here, or do you mean "e.g."?

-- Section 9 --

   If third-
   party authentication is needed, the SSH transport can be used.

Very small point: you have four citations to 6242 in two paragraphs in Section 3, but none here.  This would probably be a good place to stick another citation.

I found the discussion on the SecDir review interesting, so thanks for the more detailed explanations.  I do agree that the draft already does state that this is a certificate fingerprint, but don't see (maybe point me to where it is if I missed it), that this is all local, per:
https://www.ietf.org/mail-archive/web/secdir/current/msg05526.html

I'm wondering why the yang model that was spilt out into another draft isn't referenced as that would be helpful as well (last 2 paragraphs of Tom's response):
https://www.ietf.org/mail-archive/web/secdir/current/msg05524.html

This is non blocking as I'd like to figure out if it's helpful to avoid questions and link drafts where appropriate (unless I missed something).

Thanks,
Kathleen

- section 2: be no harm to say the server has to send a
CertificateRequest as part of the handshake and/or to say (or
point to) how e.g. to configure that in apache or similar.
(Not normatively, but as an illustration to save folks time
when they go to do it.)

- section 7, if we get the ID via step (b) option 2 and step
(c) option A then anyone certified below that CA gets to use
that identity. I'd say that's a sufficiently bad plan in
almost all cases to be worth noting as a security
consideration.  (Sorry for not spotting that in RFC7407 but I
think the alg there is harder to see in the yang module(s) so
I guess I missed it;-)

- I agree with Sam's second comment in the secdir review [1]
that specifying how to fingerprint is a good idea, even if
it's non-normative. I think in this case you may need to
fingerprint the full certificate and not the public key, as
the latter could allow attacks - but someone would need to
spend more time that I have today to figure out if there are
any interesting attacks. (Did the WG think those issues
through?)

   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05522.html