Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-pkix-cmp-transport-protocols

From: Mark Nottingham <[email-masked]>
Date: Mon, 7 May 2012 09:47:49 +1000

Hi Martin,

Responses below.

On 07/05/2012, at 3:59 AM, Peylo, Martin (NSN - FI/Espoo) wrote:
[…]
> I added the following to the introduction: 
> 
>  The usage of HTTP for transporting CMP messages exclusively uses POST
> method
>  for requests, effectively tunneling CMP over HTTP.  While this is
> generally
>  considered as bad practice and should not be emulated, there are good
> reasons to
>  do so for transporting CMP.  HTTP is used as it is generally easy to
> implement,
>  traverses network borders utilizing ubiquitous proxies and is already
> commonly
>  found in existing CMP implementations.  Other request methods such as
> GET are 
>  not used as all PKI management operations are triggered using the
> CMP's PKI 
>  messages which need to be transported within a POST request.

Looks good, thanks.

>> * Section 3.2 "Persistent Connections" effectively re-specifies part
> of
>> HTTP; this section should be removed.
> 
> I couldn't find HTTP explicitly forbidding (or permitting) to use the
> information 
> if sequential requests came over the same connection or not on the
> higher layer 
> - but of course I might have missed that somewhere.  As I personally
> already have 
> experienced this as a fatal source of incompatibility between CMP client
> and server 
> implementations I would like to keep this paragraph.  Trying to avoid
> sounding like
> re-specifying parts of HTTP I changed this section to the following:
> 
>  HTTP permits to reuse a connection for subsequent requests.
> Implementations
>  may use this functionality but MUST NOT rely on this for messages
> within the
>  same CMP transaction as e.g. intermediate HTTP proxies might terminate
> the
>  connection after each request/response pair.
> 
> Do you think it would be OK to keep it like this?

We're clarifying this in HTTPbis, but of course that doesn't help you *right* now.

I'd change to something like:

HTTP persistent connections [ref to 2616] allow multiple interactions to take place on the same HTTP connection. However, neither HTTP nor this protocol are designed to correlate messages on the same connection in any meaningful way; persistent connections are only a performance optimisation. In particular, intermediaries can do things like mix connections from different clients into one "upstream" connections, terminate persistent connections and forward requests as non-persistent requests, etc. As such, implementations MUST NOT infer that requests on the same connection come from the same client (e.g., for purposes of authentication); every message is to be evaluated in isolation. 

>> * Section 9 "Security Considerations" #2 -- "There is no security at
> the
>> HTTP protocol level" is a gross misstatement.
> 
> Changed to:
> 
>   2.  Without being encapsulated in effective security protocols such
> as
>       TLS [RFC5246] there is no integrity protection at the HTTP
>       protocol level.  Therefore information from the HTTP protocol
>       should not be used to change state of the transaction.

Works for me.

>> * Section 9 "Security Considerations" #2 -- "The client SHOULD NOT
>> support the "301 Moved Permanently status code" is ambiguous. Do you
>> mean that it should never be followed, or that it should not be stored
>> as a permanent redirect? A statement merely warning of the effects of
> a
>> MITM would be more useful here.
> 
> Changed to:
> 
>   3.  Client users should be aware that storing the target location of
>       a HTTP response with the "301 Moved Permanently" status code
>       could be exploited by a man-in-the-middle attacker to block them
>       permanently from contacting the correct server.

OK.

Thanks,

--
Mark Nottingham
http://www.mnot.net/

---

From: "Peylo, Martin (NSN - FI/Espoo)" <[email-masked]>
Date: Sun, 6 May 2012 20:59:58 +0300

Hi Mark,
 
please excuse the long delay and thank you very much for your helpful
review comments.

Inline below are explanations/notes about the changes which will appear
in 
draft-ietf-pkix-cmp-transport-protocols-17 which should become available

here soon:

http://tools.ietf.org/html/draft-ietf-pkix-cmp-transport-protocols-17

I hope all your very valid concerns were appropriately addressed!

Kind regards,
Martin

> -----Original Message-----
> From: ext Mark Nottingham [mailto:[email-masked]]
> Sent: Monday, March 05, 2012 5:26 AM
> To: [email-masked] Discuss; draft-ietf-pkix-cmp-transport-
> [email-masked]
> Cc: [email-masked] IESG
> Subject: APPSDIR review of draft-ietf-pkix-cmp-transport-protocols
> 
> I have been selected as the Applications Area Directorate reviewer for
> this draft (for background on appsdir, please see
>
<http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectora
> te>).
> 
> Please resolve these comments along with any other Last Call comments
> you may receive. Please wait for direction from your document shepherd
> or AD before posting a new version of the draft.
> 
> Document: draft-ietf-pkix-cmp-transport-protocols-16
> Title: Internet X.509 Public Key Infrastructure -- HTTP Transport for
> CMP
> Reviewer: Mark Nottingham
> Review Date: March 4, 2012
> 
> Summary: This draft is not ready for publication as a Proposed
Standard
> and should be revised before publication.
> 
> 
> Major Issues:
> 
> * This draft describes a HTTP-based protocol that exclusively uses
POST;
> i.e., it effectively tunnels.
> 
> This is widely recognised as bad practice, and should be avoided where
> possible. A good use of HTTP is one that defines resources with
> particular behaviours, formats with associated semantics, and then
uses
> links to navigate / manipulate the state of the application. GET
should
> be used for retrieval (it's not even clear if it's allowed / used in
> this draft).
> 
> Preferably, the draft should be re-worked to use HTTP well, rather
than
> tunnelling.
> 
> Alternatively, there should be a notice inserted that explains this
> draft is tunnelling over HTTP, and this practice should not be
emulated.

> Minor Issues:
> 
> * Section 3.1 "HTTP Versions" - the wording here doesn't reflect how
> HTTP versioning works; see RFC2145. Suggest: "Clients MUST support
> HTTP/1.0 [RFC1945], and SHOULD support HTTP/1.1 [RFC2616]."

Suggestion used (but changed "Clients" to "Implementations").

of

> * Section 3.6 "HTTP Request-URI" -- What does "depicting a directly"
> mean? HTTP and URIs say nothing about directories.

Very valid point, I changed section 3.6 to the following changing 
"directory" to "path" and removing what I found to be redundant as
already specified:

3.6.  HTTP Request-URI

   The Request-URI is formed as specified in [RFC3986].

   A server implementation MUST handle Request-URI paths with or without
   a trailing slash as identical.

   An example of a Request-Line and a Host header field in an HTTP/1.1
   header, sending a CMP request to a server, located in the "/cmp" path
   of the host "example.com", would be

      POST /cmp HTTP/1.1
      Host: example.com

   or in the absoluteURI form

      POST http://example.com/cmp/ HTTP/1.1
      Host: example.com

> * Section 3.8 "HTTP Considerations" -- Pragma: no-cache is not
> meaningful in responses, and shouldn't be limited to just HTTP/1.0, as
> versioning is hop-by-hop, not end-to-end. In any case, this paragraph
> can be dropped, because POST isn't cacheable by default, and is never
> cached in practice.

Paragraph dropped.

> * Section 3.8 "HTTP Considerations" -- The paragraphs on connection
> management and content-codings are re-specifying HTTP, and should be
> removed.

Paragraphs removed.

the

Changed to:

a

Changed to:

> --
> Mark Nottingham   http://www.mnot.net/
> 
>

---

From: "Peylo, Martin (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 7 May 2012 12:58:49 +0300

Hi Mark,

thank you for that!

[...]
> HTTP persistent connections [ref to 2616] allow multiple interactions
to
> take place on the same HTTP connection. However, neither HTTP nor this
> protocol are designed to correlate messages on the same connection in
> any meaningful way; persistent connections are only a performance
> optimisation. In particular, intermediaries can do things like mix
> connections from different clients into one "upstream" connections,
> terminate persistent connections and forward requests as
non-persistent
> requests, etc. As such, implementations MUST NOT infer that requests
on
> the same connection come from the same client (e.g., for purposes of
> authentication); every message is to be evaluated in isolation.

Excellent paragraph - it will certainly stand out in terms of technical
and linguistic quality!  I will take that 1:1 but would like to change
the "(e.g., for purposes of authentication)" to "(e.g., for correlating
PKI messages with ongoing transactions)" as this better describes the
most probable use case CMP implementers could be tempted to use this
for.

When that is OK for you I'll insert that and upload the draft for which
Sean then can issue the LC (provided everything is OK for him).

Kind regards,
Martin

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 7 May 2012 20:08:06 +1000

Works for me.

Cheers,

---

From: Sean Turner <[email-masked]>
Date: Mon, 07 May 2012 06:13:39 -0400

Great post a new version and I'll get the IETF LC started.

spt