Stephen Farrell <[email protected]> wrote:
> 3) Wrt Brian's point about DHE 1024, I think that was already discussed
> on the list earlier and while the mozilla figures are interesting they
> don't change my mind - I think the benefit of PFS and the fact that
> s/w updates can fix this silently after one has configured the DHE
> cipherstuite and that the draft already says you should use 2048 all
> add to to where the draft is ok as-is.
Firstly, I am also a very big advocate for PFS. More than arguing
against the DHE variants of the cipher suites, I'm arguing for the
ECDHE variants.
I understand that this document is near the end of the road and that
changes should be minimized if possible. Also, re-reading the draft, I
think most of my concern is already addressed well enough in section
4.4. I'd like to propose one small additional bullet point to the list
of bullets in section 4.4:
+ o Many server choose DH parameters of 1024 bits or fewer.
+
o There are widely deployed client implementations that reject
received DH parameters if they are longer than 1024 bits.
CURRENT TEXT: "With regard to PKIX certificates, servers SHOULD
support OCSP and OCSP stapling, including the OCSP stapling extension
defined in [RFC6961], as a best practice given the current state of
the art and as a foundation for a possible future solution."
SUGGESTED NEW TEXT: "With regard to PKIX certificates, servers SHOULD
support OCSP and OCSP stapling, including both the status_request_v2
extension defined in [RFC6961] and the status_request extension
defined in Section 8 of [RFC6066], as a best practice given the
current state of the art and as a foundation for a possible future
solution."
In particular, I believe that the current text is intending to mean
the same thing as the suggested new text, but it is easy to
misunderstand it to be recommending only the status_request_v2
extension, and not also recommending the status_request extension.
(Indeed, this is how I read it last night, which is why I expressed
concern about it.)
What do you think?
I am content with all my other feedback being ignored, as it is less important.
Cheers,
Brian
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
