sts-3.3: Add the preload key #295

attilamolnar · 2017-01-05T21:24:08Z

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 · 2017-01-10T12:46:09Z

Added links to sections the text is talking about.

attilamolnar · 2017-01-10T13:04:14Z

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.

DarthGandalf · 2017-01-11T12:37:40Z

core/sts-3.3.md

+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.


How does HTTP do it?

HTTP has the Host: header

attilamolnar · 2017-01-11T12:55:43Z

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

jwheare · 2017-01-15T22:45:50Z

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 · 2017-02-02T10:51:46Z

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 · 2017-03-06T21:43:42Z

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

jwheare · 2017-03-06T22:02:02Z

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.

…he hostname in SNI

jwheare · 2017-03-09T17:38:59Z

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

…TS policy as a whole, rather than be limited to the preload key

jwheare · 2017-07-07T10:44:48Z

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

attilamolnar · 2017-07-11T14:41:17Z

@jwheare Makes sense, LGTM

jwheare · 2017-07-11T14:52:04Z

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

progval · 2017-07-11T16:27:51Z

core/sts-3.3.md

@@ -205,7 +241,8 @@ discussed in General security considerations.
 As further protection against bootstrap MITM vulnerabilities, clients may choose to
 include a pre-loaded list of known hosts with STS policies. Such lists should be
 compiled on an opt-in basis, by request of IRC network administrators. Hosts should be
-verified to be correctly advertising an STS policy before inclusion.
+verified to be correctly advertising an STS policy, as well as a 
+[preload policy](#the-preload-key) before inclusion.


Could you make it explicit that preload implies “by request of IRC network administrators”?

How should this be worded to make it more clear to you?

“by request of IRC network administrators via the preload key”

How's this? 4730fb6

SISheogorath · 2017-07-12T21:03:13Z

core/sts-3.3.md

@@ -274,7 +311,7 @@ server may be offered at a different domain name, for example a subdomain.

 It's possible for an attacker to strip the STS `port` value from an initial connection
 established via an insecure connection, before the policy has been cached by the client.
-This represents a Bootstrap MITM (man-in-the-middle) vulnerability.
+This represents a bootstrap MITM (man-in-the-middle) vulnerability.


"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.

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

I'll punt that over to #301 though.

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 · 2017-07-13T12:40:34Z

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

jwheare mentioned this pull request Jan 5, 2017

Security tracker #269

Closed

5 tasks

attilamolnar requested a review from jwheare January 6, 2017 11:45

jwheare approved these changes Jan 6, 2017

View changes

jwheare added sts security labels Jan 7, 2017

jwheare modified the milestone: Roadmap Jan 7, 2017

attilamolnar force-pushed the sts-preload branch from 0014a43 to 543ddaa Compare January 10, 2017 12:45

sts-3.3: Add the preload key

cbcdc87

attilamolnar force-pushed the sts-preload branch from 543ddaa to cbcdc87 Compare January 10, 2017 12:58

MUST ignore preload key on non-secure conns

c3cca5e

attilamolnar requested a review from DarthGandalf January 11, 2017 10:05

DarthGandalf approved these changes Jan 11, 2017

View changes

attilamolnar added the Last call label Jan 11, 2017

This was referenced Jan 16, 2017

STS edits #301

Closed

Ratify STS #296

Closed

attilamolnar force-pushed the sts-preload branch from ce3c3a3 to 52c25c6 Compare March 6, 2017 22:57

Explain why servers shouldn't send the preload key without checking t…

992ef08

…he hostname in SNI

attilamolnar force-pushed the sts-preload branch from 52c25c6 to 992ef08 Compare March 6, 2017 23:18

[sts] Style edits, and split out SNI recommendation to apply to the S…

82f1f27

…TS policy as a whole, rather than be limited to the preload key

jwheare removed the Last call label Jul 7, 2017

progval reviewed Jul 11, 2017

View changes

[sts] Clarify preload list opt-in

4730fb6

SISheogorath reviewed Jul 12, 2017

View changes

jwheare merged commit 96f5ef8 into ircv3:master Jul 17, 2017

jwheare added a commit to jwheare/ircv3-specifications that referenced this pull request Jul 17, 2017

Merge in changes from ircv3#295

754bf3d

sts-3.3: Add the preload key #295

sts-3.3: Add the preload key #295

attilamolnar commented Jan 5, 2017

jwheare left a comment

attilamolnar commented Jan 10, 2017

attilamolnar commented Jan 10, 2017 •

edited

DarthGandalf Jan 11, 2017

attilamolnar Jan 11, 2017

attilamolnar commented Jan 11, 2017

jwheare commented Jan 15, 2017

lol768 commented Feb 2, 2017 •

edited

attilamolnar commented Mar 6, 2017

jwheare commented Mar 6, 2017

jwheare commented Mar 9, 2017

jwheare commented Jul 7, 2017

attilamolnar commented Jul 11, 2017

jwheare commented Jul 11, 2017

progval Jul 11, 2017

jwheare Jul 11, 2017

progval Jul 11, 2017 •

edited

jwheare Jul 12, 2017

progval Jul 12, 2017

SISheogorath Jul 12, 2017

jwheare Jul 12, 2017

jwheare Jul 12, 2017

lol768 Jul 13, 2017

lol768 commented Jul 13, 2017

sts-3.3: Add the preload key #295

sts-3.3: Add the preload key #295

Conversation

attilamolnar commented Jan 5, 2017

jwheare left a comment

Choose a reason for hiding this comment

attilamolnar commented Jan 10, 2017

attilamolnar commented Jan 10, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

attilamolnar commented Jan 11, 2017

jwheare commented Jan 15, 2017

lol768 commented Feb 2, 2017 • edited

attilamolnar commented Mar 6, 2017

jwheare commented Mar 6, 2017

jwheare commented Mar 9, 2017

jwheare commented Jul 7, 2017

attilamolnar commented Jul 11, 2017

jwheare commented Jul 11, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

progval Jul 11, 2017 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lol768 commented Jul 13, 2017

attilamolnar commented Jan 10, 2017 •

edited

lol768 commented Feb 2, 2017 •

edited

progval Jul 11, 2017 •

edited