In fact it's the other way around. See Sec. 4 of the BCP draft, in
particular
http://tools.ietf.org/html/draft-ietf-uta-tls-bcp-00#section-4.2. It's
not a clear-cut decision though.
Thanks,
Yaron
On 05/28/2014 12:31 AM, Benjamin Black wrote:
Given the significant performance difference between ECDHE and DHE, what
is the rationale for recommending DHE? Is DHE being recommended to deal
with older servers that don't support ECDHE?
On Tue, May 27, 2014 at 1:43 PM, Benjamin Black <[email protected]
<mailto:[email protected]>> wrote:
Even if OCSP endpoints are prevalent, do many browsers check and is
that even the right model? Thoughtful practitioners suggest not:
https://www.imperialviolet.org/2014/04/19/revchecking.html
And another +1 for HSTS.
b
On Tue, May 27, 2014 at 12:36 PM, Yaron Sheffer
<[email protected] <mailto:[email protected]>> wrote:
I agree with most of Tom's comments.
HSTS needs to be added for sure.
I will need an explanation on why Lucky13 is "an implementation
error". Looks like a protocol error to me.
Re: upcoming technologies (TACK, CT), I suggest to not even
mention them in this document. It is not a survey of TLS
technologies but a guide for the perplexed deployer (and
possibly their vendor). When these things become "current"
practices, we will need to republish.
OCSP (stapling or otherwise) assumes widespread deployment of
OCSP servers. Is that the situation today? To put it into
concrete terms, are more than 25% of currently issued
certificates provided with a working OCSP endpoint?
Thanks,
Yaron
On 05/27/2014 09:01 AM, Ralph Holz wrote:
Hi,
1) "will very likely obsolete the current document"
Suggest it be
"will very likely obsolete this document"
2) There are a few attacks on TLS that are omitted. In
particular,
I would have expected information on securing deploying a
configuration that also avoids: - The ECC algorithm
confusion
attack[1] - Triple Handshake - TLS stripping (And using
HSTS to
prevent)
I agree that all three should be included.
HSTS should go into the companion document.
3) I think it is worth mentioning that TLS Servers have
an asymetric
workload with the client, and thus can be subject to
computational
DoS attacks.
That is true, but I am wondering how much it helps if we
mention it - it
is so generic that the only real help would be to avoid TLS,
which is
probably not what we want.
4) I would like to say something about using PKP to mitigate
certificate forgeries, but that'll have to be in an
update when PKP
gets standardized.
Agreed on both points (although I'd add that systems like
TACK may be
preferable). Maybe we should have an outlook section that
mentions
upcoming technologies like CT, HPKP etc.?
5) I would love to say something about section 3.2 and using
(if/when it becomes available) the SCSV, but I suppose
that doesn't
actually help anyone because it's not available now either.
Later revision of the document?
8) My opinion is that OCSP information, stapled in the
response, is
a 'Best Current Practice' for TLS.
Totally agree. Although we'd need to mention then that the
even better
way would be to include the stapled responses for the
intermediate
certs, too (normal stapling doesn't do that).
To sum up, I think I can write something up regarding HSTS
and OCSP
stapling, and maybe a little bit about the "outlook section".
Yaron, what's your take?
Ralph
_________________________________________________
Uta mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/__listinfo/uta
<https://www.ietf.org/mailman/listinfo/uta>
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
