salvatoreloreto/ietfdrafts

IETF draft I am authoring or co-authoring

ietfdrafts's Issues

Typo section 1.1

Section: 1.1 Type: bug (typo)

Suggested change

An "Explicitly Authenticated",

to

An "Explicitly Authenticated Proxy",

What is the expected behaviour for non-TLS protected http URIs?

Type: question, enhancement

What is the EAP's expected behaviour for non-TLS protected http URIs? We should at least mention this, and consider the security implications carefully. For example (option 1):

Section 4.4 Explicitly Authenticated Proxy for non-secured http requests
In this case the Proxy will create a secure connection to the client, but will not negotiate > a secure connection to the origin server. plus diagram

But this behaviour may lead the user to believe that they are in fact securely connected to the origin server, for example if a padlock is shown based on the secure connection to the proxy.

So option 2:

Section 4.4 Explicitly Authenticated Proxy for non-secured http requests
Where the 'http' request is not secured by the origin server, the Proxy will drop the
secure connection to the client and revert to its regular behaviour for non-secured 'http' requests

But what would be the impact of the secure connection dropping?

Shorter abstract

Section: Abstract. Type: enhancement request

Reason:

I think most of this can be explained in the introduction, and that we simply define the scope here

Suggested change:

start
Abstract

This document specifies the behaviour of an Explicitly Authenticated proxy as an intermediary of TLS-protected 'http' traffic over HTTP/2.
end

Shorter Introduction

Section: Introduction (section 1). Type: enhancement request

Reason

This is all good text but often repeats what is being discussed in the three referenced RFCs, which are well summarised

Suggested change

Remove the three explanatory paragraphs above

'Several drafts analysing[...]'

New Introduction section

Section: 1, 1.1 Type: Enhancement

Reason

• The opening paragraphs often repeat what is being discussed in the three referenced RFCs, which are well summarised
• Duplication of definition of EAP between section 1.1. and the Terminology entry in section 2
• The note on expected HTTPS behaviour now points to a new section to describe that
• move the full definition of an EAP into the Terminology section (this is now #7 )
• removed the note on expected behaviour for https and replaced it with a pointer to section 4 (which describes that behaviour)
• made the references higher level (so just pointing to section 3 and section 4) rather than too many details in this section.
• added a pointer to section 5
• added a pointer to section 6
• added a pointer to section 7 (see #9) which deals with user consent

Suggested change

1. Introduction

Several drafts analysing the role and the requirements for proxies have
been submitted:

1. [I-D.nottingham-http-proxy-problem] discusses the use and
   configuration of proxies in HTTP, pointing out problems in the
   currently deployed Web infrastructure along the way
2. [I-D.vidya-httpbis-explicit-proxy-ps] describes the issues with
   HTTP proxies for TLS protected traffic and motivates the need for
   explicit proxying capability in HTTP. It also presents the goals
   that such a solution would need to satisfy and some example
   solution directions.
3. [I-D.rpeon-httpbis-exproxy] describes a method for connecting to
   a proxy via a secure channel, allowing, disallowing, and
   detecting any transforms that the proxy may perform, and allowing
   the proxy to connect via secure channel to another site on the
   user's behalf.

Use cases in form of stories for proxies are also listed in the wiki
Proxy-User-Stories [1] and analysed in a matrix form in Trusted Proxy
Use Case Analysis and Alternatives [2].

This draft explicitly narrows down the general discussion to the role
of an Explicitly Authenticated Proxy (link to definition in Terminology here)
as an intermediary of TLS-protected "http" scheme URIs of HTTP2 traffic.

This document describes a method for an user agent to automatically
discover and then for an user to accept or reject (i.e. to provide
consent for) an Explicitly Authenticated Proxy to be securely
involved when a request to an "http" URI resource is made.

Section 3 defines processes to signal that an "http" URI
is being requested over HTTP2.

Section 4 describes the role of the Explicitly Authenticated Proxy
when "http" URIs resources have been requested, and the expected
behaviour for "https" scheme URI requests.

Section 5 defines how an Explicitly Authenticated Proxy signals its
presence to an origin server

Section 6 deals with the security implications of introducing an
Explicitly Authenticated Proxy

Section 7 deals with how the user manages their consent for the
Explicitly Authenticated Proxy to operate.

Add a new section on goals and non-goals

Section: new section. Type: enhancement request

Reason:

Add new section on goals/non-goals. i.e. why we are doing this, and what we are not doing

Suggested text for new section:

start

Goals and non-goals

The primary goal is to define an intermediary to TLS-protected 'http' traffic, that operates with the knowledge
and explicit consent of the user

Non-goals are to define an intermediary for unprotected 'http' traffic over both HTTP/1.1 and HTTP/2, and for 'https' URIs. However the intermediary's expected behaviour for these cases is listed for completeness.

end

New section on consent

section: new section, '7 User Consent' Type: enhancement

Reason:

Consent is a hugely important aspect of the EAP, and should have its own section to cover how it can be done. This can also re-use the material from the existing section 3.3, 'opt out' (pasted below under 7.3)

Suggest change

1. Remove section 3.3. Its text will be reused in section 7
2. Suggested headings for section 7:

Section 7 User consent

7.1 Explaining the proxy functions to the user

7.2 Obtaining and storing user consent

7.3 Expected behaviour if the user opts out/revokes consent
If the user does not give consent, or decides to opt out from the
proxy for a specific connection, the user agent will negotiate HTTP2
connection using "h2" value in the ALPN extension field. The proxy
will then treat the connection as an "https" connection and will
forward the ClientHello message to the Server, establishing an end-
to-end TLS connection between the user agent and the destination
server.

Change the URI schemes to their IANA names

Section: all Type: enhancement

Reason

The IANA name for the URI schemes does not include '://'

Suggested Change:

All instances of 'http://' to 'http'
All instances of 'https://' to 'https'

Make scope explicit in Introduction

Section: Introduction (section 1) Type: enhancement

Reason

Best to make the scope of the EAP clear in the Introduction

Suggested change:

for the last line of this section, needs to be explicit that this is TLS-protected http URIs:

start

This draft explicitly narrows down the general discussion to the role of Proxy as an intermediary of TLS-protected 'http' URIs over HTTP/2

end

Change terminology entry for EAP

Section: 2 Type: Enhancement

Reason

As per issue 8 , the shorter introduction leaves the formal definition of the EAP to theTerminology section. The formal reference to 'proxies' should be used in the 'Explicit proxy' definition as that comes first

Suggested change

1. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].

This document defines the following terms:

Explicit proxy: an intercepting proxy (see section 2.3 [I-D.ietf-httpbis-p1-messaging]) that
communicates its presence to the user agent and destination server.

Explicitly Authenticated Proxy: an HTTP Proxy that is certificate authenticated, user acknowledged > and connected to over a TLS encrypted (and possibly integrity protected) connection. An Explicitly Authenticated Proxy is configured by the user agent to
exclusively receive "http" URI scheme requests and attempt to satisfy
those requests on behalf of the user agent. The presence of a configured Explicitly Authenticated Proxy MUST NOT change the user agent behaviour for the "https" URI scheme requests.