sts-3.3: Add the preload key

[attilamolnar]

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]

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

[attilamolnar]

Added links to sections the text is talking about.

[attilamolnar]

Added links to sections the text is talking about.

[attilamolnar]

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]

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]

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

[attilamolnar]

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

[jwheare]

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.

[jwheare]

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.

[lol768]

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.

[lol768]

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.

[attilamolnar]

@jwheare which section do you suggest putting the explanation in?

[attilamolnar]

@jwheare which section do you suggest putting the explanation in?

[jwheare]

Just right after it's mentioned for now. We can move it around and finesse it if needed once the main gist is written down.

[jwheare]

Just right after it's mentioned for now. We can move it around and finesse it if needed once the main gist is written down.

[jwheare]

Thanks a lot, I'll take a closer look at this when I have a chance and suggest some improved wording.

[jwheare]

Thanks a lot, I'll take a closer look at this when I have a chance and suggest some improved wording.

[jwheare]

I split out the SNI recommendation to cover the whole policy, rather than be limited to preload.

[jwheare]

I split out the SNI recommendation to cover the whole policy, rather than be limited to preload.

[attilamolnar]

@jwheare Makes sense, LGTM

[attilamolnar]

@jwheare Makes sense, LGTM

[jwheare]

Thanks, any final comments from anyone else before this is merged?

[jwheare]

Thanks, any final comments from anyone else before this is merged?

[SISheogorath]

"MITM" is explained in this part, but not in line 236. Since 236 is earlier it would make sense to move the (man-in-the-middle) up there or remove it completely.

[jwheare]

Yeah this bothered me a tiny bit too, but well, this is the part that actually talks about it, line 236 is a reference to this part of the spec.

We could alternatively move this section further up, changing the order to:

• General Security considerations
• Client implementation considerations
• Server implementation considerations

[jwheare]

I'll punt that over to #301 though.

[lol768]

Nit: Most of the literature I've seen doesn't capitalise the minor words in the initialism, so I'd expect to see MitM(e.g. see http://ieeexplore.ieee.org/document/7546529/?reload=true)

[lol768]

LGTM, will be nice to see the preload stuff in the spec

[lol768]

LGTM, will be nice to see the preload stuff in the spec