[Trans] Summary of DISCUSS items for draft-ietf-trans-rfc6962-bis

[Roman Danyliw <[e-mail]>]

Hi!

I just balloted YES with a few comments on draft-ietf-trans-rfc6962-bis.  To follow-up on Paul's earlier summary [1], I saw that some discussion has occurred in response to the IESG ballot but wanted to check-in with the authors on the disposition of addressing the remaining DISCUSS items.

[1] https://mailarchive.ietf.org/arch/msg/trans/9zGMHr_Fu1EefWbvthvqSANl3nA/

==[ Ben Kaduk
From: https://mailarchive.ietf.org/arch/msg/trans/2Sc26GMFwQnTRl5DEEk_-51ABFU/

Item #1

Sections 4.11 and 4.12 have arrays of NodeHash to carry consistency and
inclusion proofs, respectively, with minimum array size of 1.  However,
Sections 2.1.4.1 and 2.1.3.1 (respectively) seem to admit the
possibility of zero-length proofs in degenerate cases, which the
aforementioned protocol description language forbids the conveyance of.
(Section 5.3 explicitly requires the use of an empty consistency proof.)
Do those minimum array sizes need to be (implicit) zero?
(If they do not, it seems that a minimum size of 32 would have the same
effect as that of one, since a NodeHash has minimum size 32.)

Item #2

In Section 6:

   o  An Online Certificate Status Protocol (OCSP) [RFC6960] response
      extension (see Section 7.1.1), where the OCSP response is provided
      in the "CertificateStatus" message, provided that the TLS client
      included the "status_request" extension in the (extended)
      "ClientHello" (Section 8 of [RFC6066]).  [...]

This is not quite a TLS 1.3-compliant formulation -- TLS 1.3 does not
use the "CertificateStatus message", but rather uses the encoding of
that structure in a status_request extension in the CertificateEntry.
draft-ietf-trans-rfc6962-bis
===
==[ Mirja Kühlewind
From: https://mailarchive.ietf.org/arch/msg/trans/0R9dKzZ4h2bLQX4pyHqwdA4uVdo/

There was a presentation at maprg IETF 103 about the question 
if CT helps attackers to find new domains. I think this risk should at 
least be mentioned in the security considerations section.

[Roman] Pending review by Mirja.  Section 11.6 was added.
===

==[ Alexey Melnikov
From: https://mailarchive.ietf.org/arch/msg/trans/qiURoDHiWrP1l7X3WY9RRvYrWFg/

5.  Log Client Messages

   type:  A URN reference identifying the problem.  To facilitate
      automated response to errors, this document defines a set of
      standard tokens for use in the "type" field, within the URN
      namespace of: "urn:ietf:params:trans:error:".

I think you need to register this in <https://www.iana.org/assignments/params/params.xhtml#params-1>
===

Regards,
Roman