RFC Errata System | 18 Aug 16:34 2015

[Editorial Errata Reported] RFC6797 (4449)

The following errata report has been submitted for RFC6797,
"HTTP Strict Transport Security (HSTS)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6797&eid=4449

--------------------------------------
Type: Editorial
Reported by: deo luyimbaazi <luyimbaazi28 <at> gmail.com>

Section: facebook

Original Text
-------------
i cant access Facebook wall through Mozilla Firefox, thank

Corrected Text
--------------
i cant access Facebook wall through Mozilla Firefox, thank

Notes
-----

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 
(Continue reading)

Tobias Gondrom | 13 Jun 15:40 2015

FYI: Wikimedia Foundation Turns On HTTPS and HSTS, Including Wikipedia

Hi all,

I thought this might be nice to read for some of us:
Good news, Wikipedia is turning on HSTS. :-)

http://techcrunch.com/2015/06/12/the-wikimedia-foundation-turns-on-https-by-default-across-all-sites-including-wikipedia/

Have a nice weekend, Tobias

Brad Hill | 6 May 18:43 2015

Call for review: Subresource Integrity

WebSec members and interested parties,

The WebAppSec WG at the W3C plans to advance Subresource Integrity to Candidate Recommendation soon and is
asking for wide review of the specification.

This specification defines a mechanism by which user agents may verify that a fetched resource has been
delivered without unexpected manipulation.

http://w3c.github.io/webappsec/specs/subresourceintegrity/

If you wish to make comments regarding this document, please send them to public-webappsec <at> w3.org with
[SRI] at the start of your email's subject. All comments are welcome.

Further sharing of this call for wide review among other interested communities is encouraged.

Thank you,

Brad Hill

RFC Errata System | 5 May 13:28 2015

[Errata Verified] RFC7469 (4354)

The following errata report has been verified for RFC7469,
"Public Key Pinning Extension for HTTP". 

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=7469&eid=4354

--------------------------------------
Status: Verified
Type: Technical

Reported by: Kirit Saelensminde <kirit <at> felspar.com>
Date Reported: 2015-05-04
Verified by: Barry Leiba (IESG)

Section: 3

Original Text
-------------
   As in Section 2.4, the token refers to the algorithm name, and the
   quoted-string refers to the base64 encoding of the SPKI Fingerprint.
   When formulating the JSON POST body, the UA MUST either use single-
   quoted JSON strings or use double-quoted JSON strings and backslash-
   escape the embedded double quotes in the quoted-string part of the
   known-pin.

....

      'pin-sha256="d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM="',

(Continue reading)

RFC Errata System | 5 May 08:01 2015

[Technical Errata Reported] RFC7469 (4354)

The following errata report has been submitted for RFC7469,
"Public Key Pinning Extension for HTTP".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=7469&eid=4354

--------------------------------------
Type: Technical
Reported by: Kirit Saelensminde <kirit <at> felspar.com>

Section: 3

Original Text
-------------
   As in Section 2.4, the token refers to the algorithm name, and the
   quoted-string refers to the base64 encoding of the SPKI Fingerprint.
   When formulating the JSON POST body, the UA MUST either use single-
   quoted JSON strings or use double-quoted JSON strings and backslash-
   escape the embedded double quotes in the quoted-string part of the
   known-pin.

....

      'pin-sha256="d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM="',

Corrected Text
--------------
   As in Section 2.4, the token refers to the algorithm name, and the
   quoted-string refers to the base64 encoding of the SPKI Fingerprint.
(Continue reading)

Alice Wonder | 20 Apr 19:02 2015
Picon

Suggestions for Fixing PKI

Dear List,

This is just for thought, I have neither the resources nor energy to 
push it through.

I would use the existing DNS system to do the equivalent of OCSP stapling.

ICANN creates a new TLD, we can call it pki.

Only certificate authorities can register names in pki.

The registry `Example Certificates, LTD.' would register example.pki

Even though the system uses the DNS system, only a limited subset of RR 
types would be allowed in the pki. TLD.

For example, MX and A and AAAA records etc. should not be allowed, it is 
a utility TLD intended to serve as infrastructure.

For the serial number in the SOA record, seconds since UNIX epoch would 
be what I would suggest. As serial is 32-bit that will eventually wrap 
but DNS allows for serial to wrap. Whether it is seconds since UNIX 
epoch or something else doesn't matter but I do suggest the serial be 
standardized, and YYYYMMDDnn does not allow enough updates in a 24 hour 
period.

BIND etc. probably shouldn't be used for the master, the master should 
probably be a custom server that talks to the CA's database and probably 
shouldn't have a public facing IP address, but bind / NSD / whatever 
could serve as slaves, there is no need for non-standard RR types to be 
(Continue reading)

Tobias Gondrom | 15 Apr 17:22 2015

FYI: presentation about HSTS and key pinning adoption at last IETF 92 SAAG meeting

Hi guys,

just fyi: there was 2 weeks ago an interesting presentation at the IETF 
92 SAAG about HSTS and key pinning adoption. If you are interested you 
can watch it here:

http://recordings.conf.meetecho.com/Playout/watch.jsp?recording=IETF92_SAAG&chapter=chapter_0 
(you can jump to minute 24 and play).

Best regards, Tobias

Phillip Hallam-Baker | 9 Apr 00:00 2015

DNS publication of HSTS and PKP header data using CAA

http://tools.ietf.org/html/draft-hallambaker-webseccaa-00

It is a pretty straightforward proposal:

* Use the CAA record with either the hsts or hpkp tag
* Put the same text you would have put into the CAA record value field

There are a few differences in interpretation. All we are trying to do
here is to help people to close the 'secure after first use' hole, not
replace.

Given that we have quite a bit of use of HSTS headers, providing a
mechanism for publishing this in the DNS looks like being the obvious
approach.

Tom Ritter | 19 Jan 18:55 2015

Requiring OCSP Stapling as a directive in HSTS

Hi all.  I'd like to propose an idea: add an optional directive to the
HSTS header that, when included, mandates any certificate received for
a domain require OCSP Stapling. It would respect includeSubdomains and
max-age.

The threat model I'm trying to address is an attacker who can get a
valid certificate misissued for a domain.  Because of the revocation
situation, the attacker can then MITM users with impunity, blocking
revocation lookups if they occur.  While UAs would receive a crlset or
other push of revoked certificates, I believe that the UA will still
work if that connection is blocked, and it's not clear how long that
connection must be blocked before the UA stops working entirely.  (If
that happens at all.)

Counting from the detection of the attack (which efforts like CT and
Pinning help detect), requiring OCSP stapling changes the window of
attack from {forever?, 30 days?, an unknown value?} to the OCSP
staple's lifetime.  (Assuming the attacker gets a OCSP signature right
before revocation.)

Why OCSP stapling and not require the UA to instead use 'hard-fail'
revocation checking?  Well, CRLs have all sorts of drawbacks: longer
expiry times, large sizes, and they're pretty much being phased out
everywhere.  (I know about Delta-CRLs - developing a specification for
them, implementing, and deploying them will take years, if ever, due
to IPR stuff. This does not.)   What about requiring OCSP querying?
Browsers don't much care for that - it's slow, can timeout for
non-security reasons, it's out of the control of the web site owner.
That leaves us with OCSP Stapling - it's fast, implemented, deployed.

(Continue reading)

=JeffH | 13 Jan 19:36 2015

test pls ignore

test

Chris Hartmann | 12 Jan 20:18 2015
Picon

Authentic inter-domain relationships. Is this a security problem? Appropriate for websec?

1) Bob trusts and does personal business with a.com.

2) a.com forms a business relationship with b.com to perform a
business function on its behalf (payment processor, blog, whatever).
The landing page is b.com/a

3) Bob visits b.com/a and notices that the page claims to be
affiliated and owned by a.com

4) How can Bob, in absolute terms, trust that b.com/a is affiliated
and a delegated service by a.com? (say, prior to submitting sensitive
information)

Is this a security problem? I think so.

We’ve all had to make this decision one time or another on weak
inferences and correlations. I’d imagine Phishers don’t mind at all
that there is an inability for the common internet user (looking at
you grandma) to make the judgement call on web service affiliations.
They’ve been conditioned with the best practice of looking at the
address bar (and perhaps the DNS namespace) along with the lock icon
to indicate trustworthiness, which may actually help the attacker in
their act of misdirection. Inter-domain relationships model business
relationships and trust. If web users could be armed with a new
“sense” which proves these legitimate relationships (say
cryptographically) then perhaps they would have more reason to be
skeptical of those who cannot prove their affiliation. I’m not saying
we can take human judgement completely out of the equation, but why
not have a tool to help anchor this commonly needed and risky
correlation.
(Continue reading)


Gmane