Re: fyi: Strict Transport Security (STS) specification

Just to fill in a bit amongst Adam's coverage of Aryeh's good questions..

Adam replied:
 > Aryeh asked:
 >> "Underlying secure transport error" could use definition -- I'd
 >> imagine it would include, among other things, an unrecognized root
 >> certificate, an expired or revoked certificate, etc., but perhaps it
 >> could be made clearer.  Or do other relevant specs already define this
 >> term?
 >
 > You're correct about the meaning of the term.  Clarifying what we mean
 > is probably a good idea.

Agreed.

 > There's a question of how specifically we want to tie this to TLS.

Well, one way to address it is to have normative subsections for specific 
underlying secure transports, e.g. TLS and SSH3 (at least) that specifically 
identify the (class of) errors that the sec transport layer can relay "up the 
stack" as warnings (and that aren't out-of-hand fatal for the transport (many 
are)), and note that they are to be treated as fatal by the HTTP layer.

For TLS, see RFC4346 top of pg 31 -- errors not noted as fatal on prior pages 
are possibly warnings at the discretion of clients or servers, and we want to 
that (me thinks) and say "if you get any such warnings from the TLS impl, treat 
them as fatal and follow TLS procedures to shut down the TLS connection".

Would that be specific enough?


Adam replied:
 > Aryeh asked:
 >> Regarding the Issue in section 10: it seems to me that the long-term
 >> solution to this would be something like DNSSEC, right?
 >
 > I agree that once DNSSEC is the deployed, it will be a good way to
 > deliver an STS policy.  There's actually a proposal floating around to
 > do exactly that, but I can't put my fingers on it at the moment.

shucks, I'd intended to stick DNSSEC into that Issue box along with the other 
stuff in there. Good catch.

Yes, STS policy /could/ be delivered in other fashions, some form of DNS-based 
metadata coupled with DNSSEC is one. DNSSEC coupled with other (emergent) 
metadata (mentioned in that issue) approaches are others.


 > Aryeh asked:
 >> Regarding "STS could be used to mount certain forms of DoS attacks,
 >> where attackers set fake STS headers on legitimate sites available
 >> only insecurely (e.g. social network service sites, wikis, etc.)": how

Well, the other thing that's meant there too, and which isn't really, is that 
an admin of hosting.example.com could malevolently/inadvertently DoS 
{sites}.hosting.example.com given the manner this is presently designed.

But, we feel that given that a superdomain admin currently can do all sorts of 
nasty things to a subdomain either malevolently/inadvertently (e.g. take 'em 
out of the zone file) that this really doesn't alter the status quo.

Thanks for your feedback.

HTH,

=JeffH
PayPal InfoSec Team

Received on Monday, 21 September 2009 23:01:01 UTC