[Dance] WGLC path forward draft-ietf-dance-client-auth and draft-ietf-dance-tls-clientid

[Joey Salazar <[e-mail]>]

Hello DANCE,

DANCE met at IETF-118 and discussed the remaining last call issues
with respect to the draft-ietf-dance-client-auth and
draft-ietf-dance-tls-clientid documents.  Below is a summary of the
issues, and the path forward as agreed to during the WG meeting.  The
DANCE chairs would like the WG participants to please review the
conclusions reached and to speak up if there are any participants that
disagree with the proposed paths forward for the issues.

Please submit your thoughts and/or contributions by *EOB December 21st*.
Issues left unaddressed by that time will be discarded.

The youtube video of the session can be found here for those that wish
to watch it: https://www.youtube.com/watch?v=HDKFZAkOyW4

Last call comment discussion: draft-ietf-dance-client-auth
============================================================

Issue: Examples needed
~~~~~~~~~~~~~~~~~~~

  Comment from: Rick van Rein

  - could use examples for:
    - domain names
    - wildcards and DANE-TA

  Potential: Volunteer needed to add an easy example
  Potential: /or/ point to architecture document?
  Potential: /or/ point to use-cases document?

  Conclusion at IETF-118: ask for text volunteers or drop if no volunteers


Issue: Encoding the transport label
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  Comment from: Michael Richardson

  LC comment notes:
  - The transport label encoding may not be needed,
  - both TLS and DTLS are functionally dual-usable already
  - the current draft already says the transport label is not needed

  Potential: leave as is

  Conclusion at IETF-118: leave as is the general document should not
  be that prescriptive


Issue: clarity on the security considerations
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  Comment from: Robert Moskowitz

  LC comment notes:
  - Are there privacy concerns because of client identity harvesting in
    DANCE?
  - do we need a better security consideration section description?

  Potential: Mention this consideration in the security consideration

  Conclusion at IETF-118: Bob to offer suggestive texts


Issue: X.509 certificates should be a MUST
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  Comment from: Michael Richardson

  LC comment notes:
  - Why is there an exception that allows for SHOULD when using X.509
    certificate

  Potential: Change it to MUST

  Conclusion at IETF-118: different modes in client authentication,
  but you don't have to.  You can also use raw public key.

  result: leave as is with extra text explaining why

  Shumon to see if further elaboration would be helpful/necessary


Issue: Nits
~~~~~~~~

  Comment from: Michael Richardson

  LC comment notes:
  - Smaller wording suggestions and nits IRT DNSSEC validation,
    distinction between TLS and DTLS, [_service] and device notation,
    references for both RFCs and inactive drafts
  - Message-ID: 763667.1668330590@dyas

  Potential: Accept and act on the nits

  Conclusion at IETF-118: accept suggested text from Michael


Last call comments about draft-ietf-dance-tls-clientid
============================================================

Issue: Needs a check regarding the supported TLS version
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  Comment from: Michael Richardson


  LC comment notes:
  - We have a reference to TLS 1.2 and 1.3 and DTLS 1.3
  - We have a reference to RFC8446 (framing extension)

  Potential: This extension supports both TLS 1.2 [RFC5246] and TLS 1.3
  [RFC8446], and future TLS versions.  DTLS [RFC6347] is also
  supported. The term TLS in this document is used generically to
  describe all protocols.

  Potential: A reference to RFC6066 is not needed (TLS extensions)

  Conclusion at IETF-118: accept this suggested text from the chairs
  above, add additional fuzzy text mentioning that future versions of
  the TLS protocol may require extensions be put in other places
  within TLS initialization messages.

  Conclusion: reference is not needed


Issue: Request for clarity on the ClientName limit definition
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  Comment from: Rick van Rein and Michael Richardson

  LC comment notes:
  - dane_clientid extensions defined as <1..255>
  - TLS encodes names as ascii
  - DNS encodes them as 255 character limit names
    - (with a trailing dot/null indicating the root zone)

  The decode_error alert and a closedown of the connection when using
  empty dane_clientid extensions defined as <1..255>

  - We require ClientName to be non-empty
  - Do we ever need to require an extension with a zero-length
    ClientName?

  Potential: ensure the text properly shows the difference between the
  TLS length required vs the DANE request length required.

  Conclusion at IETF-118: Mark and Shumon will work on the right end
  length for 255 issue, likely extending the potential length to 1024.

  Also: Shumon needs to talk with EKR or someone about a better way to
  write an empty presentation syntax for TLS extensions.


Issue: Use stiffer requirements
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  Comment from: Rick van Rein and Michael Richardson

  LC comment notes:
  - More stiff requirements suggested in order to improve
    interoperability and reduce code complexity
  - "When using X.509 certificate authentication, it SHOULD send this
    extension."

  Potential: SHOULD -> MUST

  Conclusion at IETF-118: it's a SHOULD because of mixed-mode cases or
  where it may not be wise to deploy it operationally

  Also: Add a sentence explaining why it's a SHOULD


Issue: The draft SHOULD say what RR content it expects
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  Comment from: Robert Moskowitz

  LC comment notes:
  + Interpretation: DANE has multiple usage/etc models now, should we
    specify which are usable in this context?

  Potential: drop this suggestion as it adds more strictness than is
  necessary.  Disagreement about whether or not this should go into this
  document vs a more specific one if needed.

  Conclusion at IETF-118: leave as is -- future application specific
  profiles might make it more strict, but the strictness is not needed
  in the base document.


Issue: Use case for mixed environments in terms of certificate_authorities
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  Comment from: Rick van Rein?

  LC comment notes:
  - Use case for mixed environments in terms of certificate_authorities
  - likely in the context of an ownership change

  Potential: ???

  Conclusion at IETF-118: need more information about mixed
  environments before a concrete suggestion could be made.

Your chairs,
Wes and Joey