Hi Brian,
On 18/01/2012 16:16, Brian Trammell wrote:
On Jan 18, 2012, at 3:38 PM, Alexey Melnikov wrote:
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/GenArtfaq>.
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–01–14
IETF LC End Date: 2012-01-17
IESG Telechat date: 2012-01-19
Summary: This draft is almost ready for publication as a Proposed Standard 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 all
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 should
point out it doesn't contain \r or \n...
Saying it is an opaque string is Ok, but you don't even specify which
characters are allowed in it.
Will add.
Thanks.
Hm. Good point; also didn't mention a maximum length. Fixed in -07, defined as
1*255(VCHAR).
I think this issue is resolved.
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 certificate
(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 6125 for
certificate verification are stricter than in RFC 2818 and this sentence 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 authentication." "Current best
practices", however, seems to be something of a moving 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 the
exception
of server TLS identity verification which is detailed below.
Ah. Okay, now I understand the issue...
This is only one of them...
RID systems MUST use TLS version 1.1 [RFC4346] or higher with mutual
X.509 authentication. TLS provides for transport confidentiality,
identification, and authentication.
The language has changed in -07 to the following; would this be acceptable?
RID systems MUST use TLS version 1.1 [RFC4346] or higher with mutual
authentication for confidentiality, identification, and
authentication, as in [RFC2818],
Part of the issue with this text is that reads as if "mutual
authentication" results in "confidentiality, identification and
authentication". TLS does, that is why I split the sentence into
multiple. Also RFC 2818 is a wrong reference because it doesn't even
mention confidentiality.
I am hoping this is not nitpicking, but I think using simpler sentences
clearer.
when transporting RID messages over
HTTPS.
The rest looks good to me:
RID systems MUST use mutual authentication; that is, both RID
systems acting as HTTPS clients and RID systems acting as HTTPS
servers MUST be identified by an X.509 certificate [RFC5280]. Mutual
authentication requires full path validation on each certificate, as
defined in [RFC5280].
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 at
citing 6125.
SRV-ID are really only applicable to protocols which are using DNS SRV. So I
would have prohibited them... But if you want to keep using them, you need to
specify what is the service name you would expect in them.
Indeed. We don't, so, removed. Thanks for the clarification.
Actually, since the binding between RID and a PKI is better defined in
rfc6045-bis, 6046-bis now refers to it, as follows:
Each RID system SHOULD authenticate its peers via a PKI as detailed
in Section 9.3 of [I-D.ietf-mile-rfc6045-bis].
Would this address the concern?
Let me check.
Many thanks, best regards,
Brian
as in Section 6 of [RFC6125].
RFC 6125 allows for various options and this paragraph doesn't seem to cover
all of them. I suggest you check Section 13.7.1.2.1 of RFC 6120 for an example
of what should be specified (ignore XmppAddr identifier type, as it is very
XMPP specific). For X.509 SANs which are disallowed, you should say so.
Will do. (6125 is missing something here, a guide for using it in other
specs...)
Best regards,
Brian
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
