Opened 11 years ago

Closed 10 years ago

#11 closed defect (fixed)

failing insecure connections and user recourse

Reported by: jeff.hodges@… Owned by: draft-ietf-websec-strict-transport-sec@…
Priority: major Milestone:
Component: strict-transport-sec Version:
Severity: Active WG Document Keywords:
Cc:

Description

http://www.ietf.org/mail-archive/web/websec/current/msg00076.html

Subject: Re: [websec] failing insecure connections and user recourse (was:

Some questions about HSTS)

From: =JeffH <Jeff.Hodges@…>
Date: Tue, 23 Nov 2010 16:42:03 -0800
To: IETF WebSec? WG <websec@…>

[ I'm outta the office this week; expect longer than usual delays ]

Yoav Nir noted..

In sections 2.4.1.1, point #9 says: 9. UAs need to prevent users from
clicking-through security warnings. Halting connection attempts in the face

of secure transport exceptions is acceptable.

...

Point #9 seems to say contradictory things. On the one hand, it says that
"UAs need to prevent..." and I interpret "need" to mean "MUST", but on the
other hand, halting connections is just "acceptable". So is it MAY or MUST?

section 2.4.1.1, comprises core functional requirements for addressing the
threats noted in an earlier section of the Overview -- its non-normative
expository material.

The relevant normative language in the present spec
(draft-hodges-strict-transport-sec-02) is..

7.3. Errors in Secure Transport Establishment

When connecting to a Known HSTS Server, the UA MUST terminate the
connection with no user recourse if there are any errors (e.g.
certificate errors), whether "warning" or "fatal" or any other error
level, with the underlying secure transport.

Paul Hoffman notes..

...the IETF, generally does not make such decisions for users. We make
protocols and recommendations to developers. The text in this document
should be worded as such.

Agreed. I propose moving the "with no user recourse" phrase (no more, no less),
in the language quoted above, to section "10. UA Implementation Advice", and
appropriately elaborate on it there (and in security considerations).

Change History (1)

comment:1 Changed 10 years ago by jeff.hodges@…

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.