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
