Changeset 2612


Ignore:
Timestamp:
01/02/14 10:28:17 (6 years ago)
Author:
fielding@…
Message:

(editorial) minor tweaks to new security sections (suggested by mnot); see #549

Location:
draft-ietf-httpbis/latest
Files:
2 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.html

    r2611 r2612  
    28732873            <p id="rfc.section.9.1.p.1">HTTP relies on the notion of an <dfn>authoritative response</dfn>: a response that has been determined by (or at the direction of) the authority identified within the target URI to be the
    28742874               most appropriate response for that request given the state of the target resource at the time of response message origination.
    2875                That is the essence of what a user is looking for when they make any HTTP request, especially when it is a request to an authority
    2876                trusted by that user to provide a specific service. Providing a response from a non-authoritative source, such as a shared
    2877                cache, is often useful to improve performance and availability, but only to the extent that the source can be trusted or that
    2878                a distrusted response can be safely used.
     2875               Providing a response from a non-authoritative source, such as a shared cache, is often useful to improve performance and availability,
     2876               but only to the extent that the source can be trusted or the distrusted response can be safely used.
    28792877            </p>
    28802878            <p id="rfc.section.9.1.p.2">Unfortunately, establishing authority can be difficult. For example, <dfn>phishing</dfn> is an attack on the user's perception of authority, where that perception can be misled by presenting similar branding in
     
    28882886               obtains resolution results, could impact the authenticity of address mappings; DNSSEC (<a href="#RFC4033" id="rfc.xref.RFC4033.1"><cite title="DNS Security Introduction and Requirements">[RFC4033]</cite></a>) is one way to improve authenticity.
    28892887            </p>
    2890             <p id="rfc.section.9.1.p.4">Furthermore, after an IP address is obtained, establishing authority is vulnerable to attacks on Internet Protocol routing.</p>
    2891             <p id="rfc.section.9.1.p.5">The "https" scheme (<a href="#https.uri" title="https URI scheme">Section&nbsp;2.7.2</a>) is intended to prevent (or at least reveal) many of these potential attacks on establishing authority, assuming the negotiated
    2892                TLS connection is secured in a way that verifies the communicating server's identity matches the target URI's authority component
    2893                (see <a href="#RFC2818" id="rfc.xref.RFC2818.3"><cite title="HTTP Over TLS">[RFC2818]</cite></a> and <a href="#Georgiev" id="rfc.xref.Georgiev.1"><cite title="The Most Dangerous Code in the World: Validating SSL Certificates in Non-browser Software">[Georgiev]</cite></a>).
     2888            <p id="rfc.section.9.1.p.4">Furthermore, after an IP address is obtained, establishing authority for an "http" URI is vulnerable to attacks on Internet
     2889               Protocol routing.
     2890            </p>
     2891            <p id="rfc.section.9.1.p.5">The "https" scheme (<a href="#https.uri" title="https URI scheme">Section&nbsp;2.7.2</a>) is intended to prevent (or at least reveal) many of these potential attacks on establishing authority, provided that the
     2892               negotiated TLS connection is secured and the client properly verifies that the communicating server's identity matches the
     2893               target URI's authority component (see <a href="#RFC2818" id="rfc.xref.RFC2818.3"><cite title="HTTP Over TLS">[RFC2818]</cite></a>). Correctly implementing such verification can be difficult (see <a href="#Georgiev" id="rfc.xref.Georgiev.1"><cite title="The Most Dangerous Code in the World: Validating SSL Certificates in Non-browser Software">[Georgiev]</cite></a>).
    28942894            </p>
    28952895         </div>
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r2611 r2612  
    39083908   identified within the target URI to be the most appropriate response for
    39093909   that request given the state of the target resource at the time of
    3910    response message origination. That is the essence of what a user is looking
    3911    for when they make any HTTP request, especially when it is a request to an
    3912    authority trusted by that user to provide a specific service. Providing a
    3913    response from a non-authoritative source, such as a shared cache, is often
    3914    useful to improve performance and availability, but only to the extent that
    3915    the source can be trusted or that a distrusted response can be safely used.
     3910   response message origination. Providing a response from a non-authoritative
     3911   source, such as a shared cache, is often useful to improve performance and
     3912   availability, but only to the extent that the source can be trusted or
     3913   the distrusted response can be safely used.
    39163914</t>
    39173915<t>
     
    39393937</t>
    39403938<t>
    3941    Furthermore, after an IP address is obtained, establishing authority is
    3942    vulnerable to attacks on Internet Protocol routing.
     3939   Furthermore, after an IP address is obtained, establishing authority for
     3940   an "http" URI is vulnerable to attacks on Internet Protocol routing.
    39433941</t>
    39443942<t>
    39453943   The "https" scheme (<xref target="https.uri"/>) is intended to prevent
    39463944   (or at least reveal) many of these potential attacks on establishing
    3947    authority, assuming the negotiated TLS connection is secured in a way that
    3948    verifies the communicating server's identity matches the target URI's
    3949    authority component (see <xref target="RFC2818"/> and
    3950    <xref target="Georgiev"/>).
     3945   authority, provided that the negotiated TLS connection is secured and
     3946   the client properly verifies that the communicating server's identity
     3947   matches the target URI's authority component
     3948   (see <xref target="RFC2818"/>). Correctly implementing such verification
     3949   can be difficult (see <xref target="Georgiev"/>).
    39513950</t>
    39523951</section>
Note: See TracChangeset for help on using the changeset viewer.