Re: [saag] Comment added to draft-gutmann-scep history

Alexey Melnikov <alexey.melnikov@isode.com> Mon, 30 July 2018 09:55 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D31EF130FF6; Mon, 30 Jul 2018 02:55:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQG4clah6nk8; Mon, 30 Jul 2018 02:55:03 -0700 (PDT)
Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 0B479130FEE; Mon, 30 Jul 2018 02:55:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1532944502; d=isode.com; s=june2016; i=@isode.com; bh=SyKQudwV9rSkAA+HWLkPoQPxQq+4zt2EWO1zXsiW7bE=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=r+x2+ZoKgad2bBNq1/lz/f991bRJqcVM7tLZMwszi1arYttiBkkjsiqbjwKaSVG5K+pNLb xB7RacVjvggUKig0OWabLbVUpyaWjn45WnHivPPvG5wRa98oThpD9aazOVUlfuhIO2UVnZ z7jqmTZ4TxcJaWVS871FkaEYXvCrRpM=;
Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id <W17gdQBzxGri@statler.isode.com>; Mon, 30 Jul 2018 10:55:02 +0100
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>, "draft-gutmann-scep@ietf.org" <draft-gutmann-scep@ietf.org>, "carl@redhoundsoftware.com" <carl@redhoundsoftware.com>
Cc: "saag@ietf.org" <saag@ietf.org>
References: <152231658869.24008.11321959845877039592.idtracker@ietfa.amsl.com> <1522887334433.4490@cs.auckland.ac.nz> <1525092187804.38190@cs.auckland.ac.nz> <bcb96609-a4fd-faf6-cf07-12b9f1fe7df0@isode.com> <1531471734017.88813@cs.auckland.ac.nz> <1531537625942.57273@cs.auckland.ac.nz>
From: Alexey Melnikov <alexey.melnikov@isode.com>
Message-ID: <bcd1496d-08c8-6e4e-8aec-30e2647c63ad@isode.com>
Date: Mon, 30 Jul 2018 10:55:00 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
In-Reply-To: <1531537625942.57273@cs.auckland.ac.nz>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/2bMmZ1m3ULNET8USWTjjHijLjM8>
Subject: Re: [saag] Comment added to draft-gutmann-scep history
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Jul 2018 09:55:05 -0000

Hi Peter,

I will respond to your long email next week when I have a chance to 
catch up with my documents, in the meantime, a quick response to this email:


On 14/07/2018 04:07, Peter Gutmann wrote:
> I wrote:
>
>> I could perhaps add a note somewhere at the start saying that SCEP, like any
>> number of other PKI protocols, uses HTTP as a universal substrate, and that
>> you shouldn't expect that doing something HTTP-ish like setting a Content-
>> type will actually have any effect?  A reference to RFC 3205/BCP 56 should
>> probably accompany that.
> How about this:
>
> -- Snip --
>
> Like many other Internet protocols, SCEP uses HTTP as a universal substrate,
> for more on the implications of this see <xref target="BCP56">BCP 56</xref>.
Referencing existing version of BCP 56 doesn't sound great, considering 
that it is being revised by the HTTPBIS WG.

Also, can you please add some text that SCEP deviates from best current 
practices, like correct use of MIME types and non use of harcoded paths.
> While SCEP messages are carried over HTTP transport, neither the client nor
> the server is likely to be a conventional HTTP-speaking web server or client,
> providing only the minimum functionality required for HTTP transport, see the
> "HTTP Considerations" section of <xref target="RFC6712">RFC 6712</xref> for
> more on this.  Implementations SHOULD NOT use complex HTTP mechanisms such as
> chunked encoding, Expect/Continue, HTTP redirects, and similar facilities.
>
> To guard against establishing an erroneous connection to any of the myriad
> other devices and services that speak HTTP, SCEP servers MAY choose to respond
> to non-SCEP requests, for example a GET from a web browser,
I understand where you are going with this, but the above is non 
implementable. What is "non-SCEP request" and how a SCEP server can 
determine that the client is a browser? I think the above text can be 
made tighter.
>   with an HTML
> diagnostic message notifying the client that they're talking to the wrong
> server or service.  Similarly, clients MAY check for an HTML response from the
> server and report a configuration error, for example that the client is
> connecting to the wrong server or port on a server.
If you change "HTML response" to "text/html", the above is agreable.

Best Regards,
Alexey
> -- Snip --
>
> The latter is particularly useful, my code has been doing that for quite some
> time to deal with "the client/server is broken, it's not getting
> certificates".  The problem invariably is that they've specified the wrong
> server name/IP address, or forgotten to specify a port so the default 80 is
> used, or there's a proxy in the way that redirects the connection to a web
> server on 80 rather than a SCEP server on 80, or something similar.
>
> Maybe we need an updated BCP 56 that provides info on the general use of HTTP
> as a substrate and how to deal with it that every other HTTP-as-substrate-
> using RFC can refer to (no, I'm not volunteering to write it :-).
>
> Peter.