Subject: Re: [apps-discuss] AppsDir review of draft-ietf-pkix-est-07

From: Tobias Gondrom <[email-masked]>
Date: Thu, 11 Jul 2013 15:44:18 +0700

Fine with nearly every answer.
One comment inline.
Best regards, Tobias

On 11/07/13 06:31, Max Pritikin (pritikin) wrote:
> This series of emails details the EST updates to est-07 in response to
> the comments below,
>  
> On Jun 25, 2013, at 2:28 AM, Tobias Gondrom
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>> 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/ApplicationsAreaDirectorate
>> ).
>>
>> 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-est-07
>> Title: Enrollment over Secure Transport
>> Reviewer: Tobias Gondrom
>> Review Date: 25.6.2013
>>
>> Summary: The draft looks fine.
>> It is heading for STD track and mostly describes Simple PKI over TLS
>> (and using the protected channel mechanisms for mutual authentication
>> as well (beyond simple confidentiality)).
>>
>> comments:
>>
>>
>> 1. section 2.2.2 and 2.2.3
>> ( client verification.)
>> (Certificate-less TLS (e.g., with a shared credential distributed
>> out-of-band);
>> and HTTP-based with a username/password distributed out-of-band.)
>>
>> make sure to avoid information leakage. E.g. in case of
>> certificate-less TLS, if cookies are used, make sure that are not
>> transmitted over the normal unprotected HTTP band.
>> (section 3.2.3 already specifies that "HTTP Basic and Digest
>> authentication MUST only be performed over TLS 1.1 [RFC4346] or later
>> versions." which is good.)
>
> This statement in 3.2.3 re-enforces the statement in Section 3.3 that
> "HTTPS MUST be used.  TLS 1.1 [RFC4346] (or a later version) MUST
> be used."
> Arguably these statements could be condensed into 2119 assertion
> (although we have not done this). 
>
>> 2. section 3.2.4:
>> when registering  "application/csrattrs" with IANA in section 6
>> I see you have no Magic number or file extension.
>> Is there a chance that this request might at some point be made
>> without direct HTTP and might want some of the two?
>
> A file extension (".csrattrs") has been added. 
>
>> 3. section 3.2.2:
>> as you want to offer to use HTTP POST and GET.
>> I am not so happy about the HTTP GET parts. How do you consider the
>> risk of information leakage with HTTP GET when you have e.g. labels?
>> e.g. in case of    "2. 
>> https://www.example.com/.well-known/est/arbitraryLabel1/cacerts"
>
> Infrastructures that wish to keep their public certificate
> infrastructure details private can enforce client authentication
> during GET operations as specified in s4.1.2 ("EST server SHOULD NOT
> require client authentication").

Hm. Not sure. This does potentially not fulfill all security needs:
because even if you use authentication, you will still leak the
information in the GET URL to everyone in your HTTP/TCP path. Is this a
problem?

>
>> Second you may consider to note URI length limitations in GET requests. 
>
> Reject: There is plenty about URI/HTTP/etc that we are not noting
>
>> nits:
>> page 32
>> s/to use the the secp384r1 elliptic curve/to use the secp384r1
>> elliptic curve
>
> fixed.
>
>>
>>
>> Oh and you should clean up idnits:
>>  ** Downref: Normative reference to an Informational RFC: RFC 2986
>>   ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246)
>
> As previously noted on thread these are acceptable.
>
> - max
>
>>
>>
>> Best regards, Tobias
>>
>>
>

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Wed, 10 Jul 2013 23:31:51 +0000

This series of emails details the EST updates to est-07 in response to the comments below,

On Jun 25, 2013, at 2:28 AM, Tobias Gondrom <[email-masked]<mailto:[email-masked]>> wrote:

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/ApplicationsAreaDirectorate ).

Summary: The draft looks fine.
It is heading for STD track and mostly describes Simple PKI over TLS (and using the protected channel mechanisms for mutual authentication as well (beyond simple confidentiality)).

comments:

1. section 2.2.2 and 2.2.3
( client verification.)
(Certificate-less TLS (e.g., with a shared credential distributed out-of-band);
and HTTP-based with a username/password distributed out-of-band.)

make sure to avoid information leakage. E.g. in case of certificate-less TLS, if cookies are used, make sure that are not transmitted over the normal unprotected HTTP band.
(section 3.2.3 already specifies that "HTTP Basic and Digest authentication MUST only be performed over TLS 1.1 [RFC4346] or later versions." which is good.)

This statement in 3.2.3 re-enforces the statement in Section 3.3 that "HTTPS MUST be used.  TLS 1.1 [RFC4346] (or a later version) MUST be used."
Arguably these statements could be condensed into 2119 assertion (although we have not done this).

2. section 3.2.4:
when registering  "application/csrattrs" with IANA in section 6
I see you have no Magic number or file extension.
Is there a chance that this request might at some point be made without direct HTTP and might want some of the two?

3. section 3.2.2:
as you want to offer to use HTTP POST and GET.
I am not so happy about the HTTP GET parts. How do you consider the risk of information leakage with HTTP GET when you have e.g. labels?
e.g. in case of    "2.  https://www.example.com/.well-known/est/arbitraryLabel1/cacerts"

Infrastructures that wish to keep their public certificate infrastructure details private can enforce client authentication during GET operations as specified in s4.1.2 ("EST server SHOULD NOT require client authentication").

nits:
page 32
s/to use the the secp384r1 elliptic curve/to use the secp384r1 elliptic curve

fixed.

- max

Best regards, Tobias

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Mon, 15 Jul 2013 17:35:05 +0000

Response inline,

On Jul 11, 2013, at 2:44 AM, Tobias Gondrom <[email-masked]<mailto:[email-masked]>> wrote:

comments:

2. section 3.2.4:

3. section 3.2.2:

Hm. Not sure. This does potentially not fulfill all security needs: because even if you use authentication, you will still leak the information in the GET URL to everyone in your HTTP/TCP path. Is this a problem?

Because TLS is mandated any attacker on path will only have access to the encrypted data.

- max

nits:
page 32

fixed.

- max

Best regards, Tobias