Hi! I'm checking in again. Inline ...
> -----Original Message----- > From: Trans <[email protected]> On Behalf Of Roman Danyliw > Sent: Monday, February 24, 2020 3:45 PM > To: [email protected] > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/trans _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
