Message-ID: <4F16D95A.3000006@isode.com>
Date: Wed, 18 Jan 2012 14:38:18 +0000
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
To: Brian Trammell <trammell@tik.ee.ethz.ch>
References: <4F11E975.9070307@isode.com>
 <10722E0B-059E-4800-84C0-B330F397B63A@tik.ee.ethz.ch>
In-Reply-To: <10722E0B-059E-4800-84C0-B330F397B63A@tik.ee.ethz.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-transfer-encoding: quoted-printable
Cc: Kathleen Moriarty <kathleen.moriarty@emc.com>, gen-art@ietf.org,
 The IESG <iesg@ietf.org>
Subject: Re: [Gen-art] Gen-ART last call review of
 draft-ietf-mile-rfc6046-bis-05
Precedence: list

On 17/01/2012 10:16, Brian Trammell wrote:
> Hi, Alexey,
>
> Thanks for the review; questions and comments thereon inline...
>
> On Jan 14, 2012, at 9:45 PM, Alexey Melnikov wrote:
>
>> I am the assigned Gen-ART reviewer for this draft. For background on Gen-=
ART, please see the FAQ at<http://wiki.tools.ietf.org/area/gen/trac/wiki/Gen=
Artfaq>.
>>
>> Please resolve these comments along with any other Last Call comments you=
 may receive.
>>
>> Document: draft-ietf-mile-rfc6046-bis-05
>> Reviewer: Alexey Melnikov
>> Review Date: 2012=9601=9614
>> IETF LC End Date: 2012-01-17
>> IESG Telechat date: 2012-01-19
>>
>> Summary: This draft is almost ready for publication as a Proposed Standar=
d RFC.
>>
>>
>> Major issues:
>>
>> In Section 3:
>>
>>    The RID callback MUST contain a zero-length entity body
>>    and a 'RID-Callback-Token' entity header
>>
>> [Minor issue] "header" -->  "header field" (header is the collection of a=
ll header fields).
>>
>>    , itself containing a unique
>>    token generated by the receiving RID system.
>>
>> I am missing ABNF for the new header field.
> Seems a little superfluous... it's an opaque string, but I suppose we shou=
ld point out it doesn't contain \r or \n...
Saying it is an opaque string is Ok, but you don't even specify which=20
characters are allowed in it.
>   Will add.
Thanks.
>>    RID systems MUST use TLS version 1.1 [RFC4346] or higher with mutual
>>    authentication for transport confidentiality, identification, and
>>
>> Do you mean that a RID client must use X.509 certificates?
> Well, each RID system (HTTP client or server) is identified by an X.509 ce=
rtificate (hence "mutual"); how can I make this clearer?
>
>>    authentication, as in [RFC2818].
>>
>> I find the whole sentence to be confusing. Note that the rules of RFC 612=
5 for certificate verification are stricter than in RFC 2818 and this senten=
ce can be read as conflicting with the paragraph below which requires use of=
 RFC 6125. What are you trying to say here?
> The intention here is "Use current best practices as would be supported by=
 off-the-shelf HTTP/1.1 and TLS 1.1 implementations to provide mutual authen=
tication." "Current best practices", however, seems to be something of a mov=
ing target.
>
> I cite 2818 as it is the current binding between HTTP/1.1 and TLS. I cite =
6125 solely for certificate verification.
How about something like this:

OLD:
   RID systems MUST use TLS version 1.1 [RFC4346] or higher with mutual
   authentication for transport confidentiality, identification, and
   authentication, as in [RFC2818].

NEW:
   RID systems MUST use HTTP over TLS as specified in [RFC2818], with=20
the exception
   of server TLS identity verification which is detailed below.
   RID systems MUST use TLS version 1.1 [RFC4346] or higher with mutual
   X.509 authentication. TLS provides for transport confidentiality,
   identification, and authentication.
>>    RID systems MUST provide for the verification of the identity of a
>>    RID system peer presenting a valid and trusted certificate, by
>>    verifying the fully-qualified domain name and service name from the
>>    DNS SRV record, if available, against that stored in the certificate,
>>
>> I am confused: this is the first time DNS SRV records are mentioned
>> (BTW, they need a Normative Reference). Earlier text seem to suggest that=
 DNS SRV are not used to locate protocol endpoints. If RID is using DNS SRV,=
 then information about how it is used is missing from the document.
> It doesn't. Was trying to point out here that SRV must be matched if (for =
deployment-specific reasons) it was present. This is simply a poor attempt a=
t citing 6125.
SRV-ID are really only applicable to protocols which are using DNS SRV.=20
So I would have prohibited them... But if you want to keep using them,=20
you need to specify what is the service name you would expect in them.
>>    as in Section 6 of [RFC6125].
>>
>> RFC 6125 allows for various options and this paragraph doesn't seem to co=
ver all of them. I suggest you check Section 13.7.1.2.1 of RFC 6120 for an e=
xample of what should be specified (ignore XmppAddr identifier type, as it i=
s very XMPP specific). For X.509 SANs which are disallowed, you should say s=
o.
> Will do. (6125 is missing something here, a guide for using it in other sp=
ecs...)
>
> Best regards,
>
> Brian