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]
https://www.ietf.org/mailman/listinfo/uta
