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]> 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]>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] >> https://www.ietf.org/mailman/listinfo/uta >> > >
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
