People who are interested in this issue may be interested in the following requirements doc that I generated as input to the DANE WG but is also relevant here:
http://www.ietf.org/id/draft-hallambaker-dane-requirements-00.txt (There will be a -01 to change the copyright to allow mods and fix some definitions later today when my RAID has rebuilt) TLS security policy actually has at least three requirements: R1) Opportunistic TLS - tell a client that TLS is always available and can be used as an alternative to plaintext. R2) Strict TLS - tell a client that TLS must be used for the whole transaction including for content incorporated by linking. R3) Trust root / end entity cert restrictions. The certificate is passed to the client in the TLS handshake. Thus what people take as a 'requirement to put keys in the DNS' is actually the same as a requirement to use a restricted set of keys. These requirements actually serve two very distinct use cases: U1) Better than nothing, opportunistic TLS. The content was going to be sent in plaintext but we are going to upgrade on the fly to use TLS. (R1) U2) The highest possible level of security is required. The Web site and all linked content must be secured with TLS. (R2+R3) Addressing (R2) is very hard because it forces us to look at the internals of HTTP and TLS and Javascript and other piles of yuk. Defining a header or a DNS record to say 'use strict security' is easy. But defining what strict security is in a way that people can deploy is actually very hard. So in practice R2 is going to end up having to address a whole bunch of constraints that will probably end up with a set of additional requirements so that a site like Paypal can say things like 'paypal.com has a cert from vendor X, linked sites must have EV certs'. And there will need to be quite a lot of detail there. Ideally I think we might well want to see a mechanism where we go into a default deny mode so that a site declares a strict security policy and then grants exceptions for off site linking and the like. -- Website: http://hallambaker.com/
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
