sts-3.3: Add the preload key #295

Open
wants to merge 2 commits into
from

Projects

None yet

4 participants

@attilamolnar
Member

This is one way to check whether a server wishes to be included in preload lists. Another method, proposed by e on IRC is to request a signature from a valid certificate when submitting servers to a preload list.

@jwheare jwheare referenced this pull request Jan 5, 2017
Closed

Security tracker #269

0 of 5 tasks complete
@attilamolnar attilamolnar requested a review from jwheare Jan 6, 2017
@jwheare
jwheare approved these changes Jan 6, 2017 View changes

Looks good to me. No version bump required, the new key is backwards compatible.

@jwheare jwheare modified the milestone: Roadmap Jan 7, 2017
@attilamolnar
Member

Added links to sections the text is talking about.

@attilamolnar
Member
attilamolnar commented Jan 10, 2017 edited

Added paragraph telling clients to ignore the preload key unless they are looking to confirm that the server requests to be included in STS preload lists. We could also mention that this (ignoring) applies to the vast majority of clients.

@attilamolnar attilamolnar requested a review from DarthGandalf Jan 11, 2017
+Servers SHOULD verify whether the hostname provided to them via SNI is a
+hostname that is whitelisted for preloading by administrators to determine
+whether or not to advertise this key.
+If no hostname is available via SNI, this key SHOULD NOT be sent.
@DarthGandalf
DarthGandalf Jan 11, 2017 Member

How does HTTP do it?

@attilamolnar
attilamolnar Jan 11, 2017 Member

HTTP has the Host: header

@attilamolnar
Member

I'll merge this at the end of the week if there are no objections.

@jwheare
Member
jwheare commented Jan 15, 2017

Sorry for the late suggestion, but could you flesh out this part some more?

If no hostname is available via SNI, this key SHOULD NOT be sent

It should be explained to a reader why this recommendation is being made, I don't think it's completely obvious as written. An example of the risk to server operators of not checking the hostname would be good.

This was referenced Jan 16, 2017
@lol768
lol768 commented Feb 2, 2017 edited

An example of the risk to server operators of not checking the hostname would be good.

I guess the main risk here is that an IRC network has other A record entries (or indeed a wildcard entry that points all subdomains at a certain IP address) that they may not want an STS policy stored persistently for - blindly sending the preload key regardless of the hostname sent in the SNI extension would cause these to be stored, if the client was able to open a secure connection. They'd need to be using a wildcard (or multi-SAN cert) for this situation to be applicable, so it's something of an edge case - but probably worth outlining nonetheless.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment