Is this an attempt to replace the CA system?

No. S-links are intended to make the web more secure within the current CA system. They would also remain useful (likely requiring support for new directives) even if CAs were eventually phased out in favor of some alternative system.

How will introducers know what to include in s-links?
This is up to introducers and not a part of the s-link specification, but introducers can learn pins through explicit signals like HPKP or TACK headers, DANE records, CT logs, or other public commitments. Introducers may also infer pins inductively by observing what web servers are using, similar to Convergence notaries, if they so desire.

What if sites serve invalid s-links? Won't this lead to lots of broken links?
These will appear to be broken links to end users. Sites can serve broken links today, although doing so reduces the trust that users have in them. Broken links are already a fact of life on the web. Well-maintained websites already scan for broken links and this is straightforward to adapt to s-links.

User experience

Aren't hyperlinks broken because users can't tell where a link points to?
S-links are intentionally designed not to change the UI around hyperlinks, despite these flaws. Users today must trust the linking site to have chosen a link appropriately. S-links don't attempt to solve this UI shortcoming.

Will this generate lots of new certificate warnings and (further) desensitize users to them? 
The current proposal calls for an error which closely mimics a traditional HTTP 404 (not found) error, with suitable diagnostic info. A broken s-link is not necessarily a problem with the destination site, so this UI makes it clear to users that the introducer site has made a mistake.

Can users get around a broken s-link by copying the URL out of the a element directly?
Clever users will be able to do this, but they are also able to evade and/or disable certificate warnings. Designing the right amount of work for users to override s-links policy is an open question.

S-links look hard to type. Can they be used to transmit security information for sites out-of-band?
S-links aren't designed to solve the problem of binding server keys to short strings that users can type, remember, or check against a known value. S-links are designed for the web and can express policies which are too complex to represent in a human-manageable form.


Why are s-links specified using HTML, rather than in URLs themselves? 
Practically, there isn't a backwards-compatible way to add information to URLs that will not cause errors in legacy clients. More broadly, s-links are about specifying security information according to the linking web site, so the trust model is less clear outside of an HTML document. S-links aren't intended to persistently name online resources.

What about AJAX, WebSockets, and other JavaScript functions which load remote resources?
S-link strings can be used for these purposes as well if these specifications are updated to take an optional link-security parameter.

What about redirects?
This is an open issue; there are many ways to do a redirect and it will take changes in many places to support all of them. Like with JavaScript functions above, it's a matter of picking a standard place to put link security policies. 


Can a malicious or compromised website use s-links in a bad way?

S-links are designed to give no new abilities to malicious websites. Because they can only express a stricter security security policy for verifying sites than the default, malicious web sites can only use s-links to serve broken links. They can do this today.

Can the link-security attribute be set or modified via JavaScript?
Given the above limit that s-links can only make security policy stricter, there is no security risk in allowing them to be modified via JavaScript.

Can I use s-links to use self-signed certificates without warnings? 
No, because of the above requirement that s-links only allow expressing a stricter security policy to prevent new avenues for abuse. Allowing s-links to override normal checks and accept self-signed certificates would be a major new avenue for attack. A hacker who can compromise DNS and get users to click on an s-link could then impersonate any target site.

How is revocation handled?
S-links can't be revoked once served, although they expire.  Assuming s-links are based on key commitments like HPKP, user agents will break for revoked keys already. S-links are easier to revoke than client pin stores, since clients can re-load a web page and get an updated s-link. To guard against the risk of lost keys in s-links, multiple possible keys can be specified (like with HPKP).

Relation to other proposals

How is this different from YURLsDNSCurve URLs, Tor .onion addresses, or other proposals to put public keys in URLs?
These proposals all modify URLs and are essentially about long-lasting secure names. S-links are a much more lightweight approach designed for specifying short-term security information on a dynamic basis.

Why not have a directive requiring the loaded content to have a specific hash?
This has been proposed elsewhere (dating back quite a ways) to solve a different problem of using untrusted mirror sites to host known content. S-links are about securing access to sites with changing content but consistent security parameters. While it would be possible to add a fixed content hash as a s-link security directive, this is a fundamentally different problem.

How do s-links interact with other proposals to increase web security? 
There are many proposals to increase the security of SSL on the web. S-links can support all of them:
  • HPKP: Observing HPKP headers is a useful way to infer pins to include in s-links. S-link syntax closely mirrors HPKP to make this easy. One major difference is using an absolute expiry time instead of a relative max-age, because web pages are more likely to be cached with no date than headers.
  • Pre-loaded key pins: Chrome already pre-loads pins for several domains and Mozilla plans to follow suit. This won't scale forever, but is a great way to ensure secure connections to larger sites which can act as introducers. S-links can extend this strong level of trust to the rest of the web through secure introduction.
  • Content Security Policy (CSP): CSP has some similar goals to using s-links to protect the loading of page resources. Sites can use CSP to declare that resources are only loaded over HTTPS or from the same origin as the main page. S-links allow loading resources from external origins with a stricter TLS policy.
  • Certicate Transparency (CT): Certificate Transparency is a proposal for all CA-signed certificates to be recorded in a publicly verifiable append-only log. The log can issue signed proof that a certificate has been logged, preventing malicious certificates from being used in secret. Until CT is universally deployed, user agents can't require CT log proofs during signature verification. S-links can specify that a CT log proof is mandatory, preventing middleperson attacks at sites participating in CT.
  • DNSSECDNSSEC allows DNS records to be signed, preventing DNS poisoning as a means to carry out a middleperson attack. DNSSEC can still leave users vulnerable to an attacker with IP-level network control. S-links might be used to force DNSSEC-secured IP resolution for a given URL while DNSSEC is being rolled out.
  • DANE: DANE (DNS-based Authentication of Named Entities) is a proposal for including certificates in DNS records. This allows sites to use DNSSEC to verify their public key. S-links can require DANE verification of a site's public key.
  • TACKTACK enables sites to use a meta-public key (called a TACK-signing key) to cross-sign any certificate chains they might use. TACK-signing keys are established through continuity, similar to HPKP. Like with HPKP pins, s-links can solve the initial trust gap for TACK by requiring a specific TACK-signing key is in use when users navigate to a new site after secure introduction.
  • Sovereign KeysSovereign Keys is a proposal for sites to record a meta-public key (called a Sovereign Key) in a publicly verifiable append-only log. This key must be used to sign any certificate chains for the corresponding domain. Clients discover Sovereign Keys by querying mirrors of the public log. S-links can provide an alternative method to discover new Sovereign Keys during secure introduction, negating the need for queries to mirrors before each connection.
  • Convergence: Convergence uses network notaries to observe certificates in use around the web and verify that clients are seeing the same certificates as notaries are. It is currently deployed as a browser extension which requires contacting notaries on every connection to a new site. S-links would enable an implementation of Convergence online, where users browse to any new site through the website of a notary. The notary would serve s-links containing the notary's value of a destination site's certificate, preventing the requirement to install a Convergence extension.