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

Hi!

I'm checking in again. Inline ...

> -----Original Message-----
> From: Trans <trans-bounces@ietf.org> On Behalf Of Roman Danyliw
> Sent: Monday, February 24, 2020 3:45 PM
> To: trans@ietf.org
> Subject: [Trans] Summary of DISCUSS items for draft-ietf-trans-rfc6962-bis
> 
> 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

I haven't seen discussion of Ben's DISCUSS feedback

> ===
> ==[ 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.

Issue closed.  Mirja cleared her DISCUSS ballot.  Thanks for those updates in -33/-34.

> ===
> 
> ==[ 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>
> ===

Murray has picked up this DISCUSS position from Alexey:
https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/ballot/#murray-kucherawy

Regards,
Roman

> Regards,
> Roman
> 
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans