Re: [mile] FW: IDN issue

[<[e-mail]>]

I agree with David and will just add a couple of notes for clarification.

If this helps to solve the issues, I'll update the draft accordingly.

Thank you,
Kathleen

-----Original Message-----
From: Black, David
Sent: Thursday, January 26, 2012 5:30 PM
To: Peter Saint-Andre; Moriarty, Kathleen
Cc: [e-mail]; [e-mail]
Subject: RE: [mile] FW: IDN issue

Hi Peter,

> >>> In short, there be dragons.
> >>
> >> Indeed (as I'm entirely too well-aware of from the précis WG), however, the goal
> >> here is to find a suitable cave in which to confine the dragons :-).
> >
> > Nice way to put it. And yes, the PRECIS WG is a fun place to hang out.
> > Speaking of which, how's that iSCSI profile of the precis framework
> > coming along? ;-)

I'm working on getting a set of four iSCSI-related drafts out of the storm WG first.
So far, it's three down, one to go, see http://datatracker.ietf.org/wg/storm/ .  Be
careful what you wish for as an AD :-).

> >> (1) RIDPolicy class, MsgDestination=RIDSystem.

Section 11 text:

> >    The Node class identifies a host or network device.  This document
> >    re-uses the definition of Node from the IODEF specification
> >    [RFC5070], Section 3.16.  However, that document did not clearly
> >    specify whether a NodeName could be an Internationalized Domain Name
> >    (IDN).  RID systems MUST treat the NodeName class as a domain name
> >    slot [RFC5890].  RID systems SHOULD support IDNs in the NodeName
> >    class; if they do so, the UTF-8 representation of the domain name
> >    MUST be used, i.e., all of the domain name's labels MUST be U-labels
> >    expressed in UTF-8 or NR-LDH labels [RFC5890]; A-labels MUST NOT be
> >    used.  A RID system can convert between A-labels and U-labels by
> >    using the Punycode encoding [RFC3492] for A-labels as described in
> >    the protocol specification for Internationalized Domain Names in
> >    Applications [RFC5891].
> >
> > If the application is not checking this, how will it know whether any
> > A-labels have snuck in? Will it depend on its DNS resolver to return the
> > IDN in the appropriate format? The foregoing text implies that the RID
> > system will do the conversion, so it's not clear to me where the
> > responsibility lies (and if it's not clear to me, it might be clear to
> > an implementer).

At the end of the day the better answer (IMHO) is "depend on its DNS resolver".
If we can expect the DNS resolver to handle converting A-labels to U-labels in
an IDN and returning the result, the last sentence in Section 11 of the draft
can be replaced by:

        RID systems are expected to obtain an IDN meeting these requirements
        by asking a DNS resolver to return an IDN that does not contain
        A-labels (even if the input IDN contains A-labels).

** Will that work?

> > What we care about is consistent transport so that applications can
> > share data.  As long as the data received is the same for every
> > implementation, we shouldn't care how they use the domain names in
> > their application, right?
>
> Unless they are making access decisions (authentication, authorization,
> etc.) based on those domain names, because then they need to be compared
> correctly. But if RID systems are making those decisions based on IP
> address anyway, then I'm much less concerned -- perhaps even not
> concerned at all.

The NodeName in 6045-bis is not used for access decisions.  Access decisions
are specified in 6046-bis - see the other thread discussing certificates,
DNS-IDs and reference identifiers.

KMM: This is true, we use digital signatures within RID for any identification of the sender.  This is tied to profile information about the other entities in the exchange.

> > KMM: I see your point here.  How about the following text to make it clear
> > that the IP address is required and the DNS name is derived from the IP address:

[... text modification snipped ...]

> Sure, that's fine. Then my question becomes: how exactly is the NodeName
> actually used in RID systems? It's the use that drives the
> internationalization considerations. If the NodeName is merely
> epiphenomenal and it's the IP address that we use to get things done,
> then we don't particularly care about the NodeName.

I'll have to leave that one to Kathleen (draft author); this concern also applies
to IncidentSource (below).

KMM: The use cases that seem to be the concern are actually more applicable to the IODEF document.  The RID message could use IP addresses for any real checking needed.  Having the DNS is a nice thing, so we can rely on IP and have the DNS included for users to view.   This could be derived from the DNS as is currently suggested, put in the Node element for the RID message and stored locally (maybe validated on a periodic basis).  The DNS names will come more in handy with the Node instances within the IODEF document, where you will track the history of an incident and systems involved in the investigation or the incident (both are maintained in the IODEF document so it stays with the incident during the investigation as opposed to the messaging).  As Brian pointed out, we will need to deal with that as well at some point after we finish this up.

> >> (2) RIDPolicy class, MsgDestination=SourceOfIncident, and also the IncidentSource
> >> class.

> > I think it's fine to use IP address here.

That's good.

> > NOTE: you said that IncidentSource needs additional text to state that
> > the IP address required, but I do not see that here:

That text was added, but the diff doesn’t show enough context to indicate that the
text is in IncidentSource.  In any case, Kathleen's suggested addition of text to
say that the IP address is REQUIRED in all of the cases should make this crystal clear.

KMM: Great, that sounds like an agreement :-)

The Node in IncidentSource may contain both a domain name and an IP address.

> >> (3) RIDPolicy class, MsgDestination=ext-value.  This is an escape that allows
> >> extensions to MsgDestination.  The description of this should include a "there
> >> be dragons" warning about IDNs in NodeName.
> >
> > In -09 that is:
> >
> >          3.  ext-value.  An escape value used to extend this attribute.
> >              All extensions shall specify the contents and meaning of
> >              the Node element of RIDPolicy.  If the NodeName element of
> >              Node is used by an extension, NodeName may contain an
> >              Internationalized Domain Name (IDN) and that IDN is
> >              required to satisfy the requirements in [RFC5890].  It is
> >              strongly recommended that RID Systems satisfy those IDN
> >              requirements via appropriate use of the DNS as opposed to
> >              implementing their own checks for these requirements.  For
> >              example, an extension could use both a NodeName and an IP
> >              address to which the NodeName resolves.  See IODEF
> >              [RFC5070], Section 5.1 on extensibility.
> >
> > That seems slightly underspecified: what is meant by "to satisfy the
> > requirements in [RFC5890]" and "appropriate use of the DNS"? Does that
> > mean "ensuring that the IDN retrieved from the DNS consists only of
> > U-labels and NR-LDH labels"? If so, is that done by asking the DNS
> > resolver for U-labels, or is it done by actively performing a check in
> > the RID system itself (see above about "MUST NOT be A-labels")?
> >
> > Is this something that is left for each extension to define? If so, we
> > should come out and say precisely that.
> > _______
> > KMM: The important part for RID is that we communicate and exchange messages in a way that everyone
> can accept and process.  Application handling for this translation, whether it be by DNS or some other
> mechanism, really shouldn't matter.  As long as the internationalization is handled in a way that lets
> us consistently exchange information, I think the real issues are solved, no?
> > If I add "See Section 11 of this document for
> >       Internationalization considerations."  Does that resolve the issue since it provides
> consistent guidance that enables the exchange of information?
> > _______
>
> Yes, we want to make sure that applications handle these matters
> consistently. Pointing to Section 11 would solve that issue, as long as
> we can agree on what goes in Section 11. :)

Assuming that the new DNS resolver text for section 11 is ok, here's a suggested
(shorter) rewrite:

          3.  ext-value.  An escape value used to extend this attribute.
              All extensions shall specify the contents and meaning of
              the Node element of RIDPolicy.  See IODEF [RFC5070],
              Section 5.1 on extensibility. If the NodeName element of
              Node is used by an extension, NodeName may contain an
              Internationalized Domain Name (IDN); see Section 11 for
              applicable requirements. All extensions SHOULD use an IP Address
              in the Address element of the Node class as the primary means
              of Node identification.

** Does that look ok?

KMM: I think so, Peter?

Thanks,
--David

> -----Original Message-----
> From: Peter Saint-Andre [mailto:[e-mail]]
> Sent: Thursday, January 26, 2012 4:24 PM
> To: Moriarty, Kathleen
> Cc: Black, David; [e-mail]; [e-mail]
> Subject: Re: [mile] FW: IDN issue
>
> On 1/26/12 1:42 PM, [e-mail] wrote:
> > Hi Peter,
> >
> > I'll try to respond in line below and let David fill in any gaps.
> >
> > Thanks,
> > Kathleen
> >
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf Of Peter Saint-Andre
> > Sent: Thursday, January 26, 2012 3:05 PM
> > To: Black, David
> > Cc: [e-mail]; [e-mail]
> > Subject: Re: [mile] FW: IDN issue
> >
> > Hi David,
> >
> > On 1/25/12 5:06 PM, [e-mail] wrote:
> >> Hello Peter,
> >>
> >>> In short, there be dragons.
> >>
> >> Indeed (as I'm entirely too well-aware of from the précis WG), however, the goal
> >> here is to find a suitable cave in which to confine the dragons :-).
> >
> > Nice way to put it. And yes, the PRECIS WG is a fun place to hang out.
> > Speaking of which, how's that iSCSI profile of the precis framework
> > coming along? ;-)
> >
> >> The place to start looking for that cave is an understanding of how NodeName is
> >> used. The quick summary is that there are three cases:
> >>
> >> (1) RIDPolicy class, MsgDestination=RIDSystem.
> >>
> >> The NodeName is the destination of the RID message, so it can be required to work
> >> in the DNS, which already has to deal with figuring out whether a U-Label is valid.
> >> Text could be added to require that the NodeName either be used to send the RID
> >> message via DNS lookup or that it has been looked up at some point in the past and
> >> resolves to the IP address to which the RID message is sent.  Both of these
> >> approaches rely on the DNS implementation to validate the U-label.
> >
> > I think that might be fine. I see that version -09 says:
> >
> >          1.  RIDSystem.  The address listed in the Node element of the
> >              RIDPolicy class is the next upstream RID system that will
> >              receive the RID message.  If NodeName element of the Node
> >              class is used, it contains a DNS domain name.  The
> >              originating RID system is required to check that this
> >              domain name resolves to the IP address to which the RID
> >              message is sent.  This check may be performed in advance of
> >              sending the message and the result saved for future use
> >              with additional RID messages.
> >
> > However, the spec right now says that the domain name MUST NOT contain
> > A-labels:
> >
> >    The Node class identifies a host or network device.  This document
> >    re-uses the definition of Node from the IODEF specification
> >    [RFC5070], Section 3.16.  However, that document did not clearly
> >    specify whether a NodeName could be an Internationalized Domain Name
> >    (IDN).  RID systems MUST treat the NodeName class as a domain name
> >    slot [RFC5890].  RID systems SHOULD support IDNs in the NodeName
> >    class; if they do so, the UTF-8 representation of the domain name
> >    MUST be used, i.e., all of the domain name's labels MUST be U-labels
> >    expressed in UTF-8 or NR-LDH labels [RFC5890]; A-labels MUST NOT be
> >    used.  A RID system can convert between A-labels and U-labels by
> >    using the Punycode encoding [RFC3492] for A-labels as described in
> >    the protocol specification for Internationalized Domain Names in
> >    Applications [RFC5891].
> >
> > If the application is not checking this, how will it know whether any
> > A-labels have snuck in? Will it depend on its DNS resolver to return the
> > IDN in the appropriate format? The foregoing text implies that the RID
> > system will do the conversion, so it's not clear to me where the
> > responsibility lies (and if it's not clear to me, it might be clear to
> > an implementer).
> > _________
> > KMM: We state that the document must be UTF-8 compliant("The use of UTF-8 is REQUIRED").  Does that
> cover the checking since A-labels are not UTF-8 formatted?
>
> Not exactly. As I mentioned previously, the character encoding of the
> RID document (e.g., as UTF-8) is distinct from the character repertoire
> of information that goes in the domain name slot (here, the NodeName). A
> document that has an encoding of UTF-8 can include all sorts of data
> elements whose character repertoire is limited to the US-ASCII range
> (e.g., this is true of IP addresses). The relevant distinction between
> A-labels and U-labels is not the encoding of the RID document in which
> they are included (Network Virtual Terminal [RFC5198] vs. UTF-8) but the
> character repertoire (only characters in the US-ASCII range for A-labels
> because of the special features of Punycode vs. any Unicode letter,
> digit, or hyphen for U-labels). Naturally, in order to include a U-label
> directly in a document or protocol it will need to use an encoding that
> allows Unicode characters (such as UTF-8), but an A-label can be
> included in a UTF-8 document just fine -- the decisions are separate.
>
> > Would the question be resolved by changing:
> > " A RID system can convert between A-labels and U-labels by "
> > TO: " A an application communicating via RID can convert between A-labels and U-labels by "
>
> I think that might be a distinction without a difference.
>
> > This would put the burden within a application associated with the API that is IODEF/RID/RID
> Transport.
>
> I see that as an integral part of the RID system, but perhaps I'm
> missing something.
>
> > What we care about is consistent transport so that applications can share data.  As long as the data
> received is the same for every implementation, we shouldn't care how they use the domain names in
> their application, right?
>
> Unless they are making access decisions (authentication, authorization,
> etc.) based on those domain names, because then they need to be compared
> correctly. But if RID systems are making those decisions based on IP
> address anyway, then I'm much less concerned -- perhaps even not
> concerned at all.
>
> > __________
> > And if only U-labels are permitted, then comparison proceeds using the
> > U-labels as input. However, if so we might need to specify mappings of
> > the kind discussed in RFC 5895 (e.g., mapping uppercase and titlecase to
> > lowercase so that PRÉCIS.example.com is treated "the same" as
> > précis.example.com).
> >
> > BUT...
> >
> > Will RID systems in fact be doing such comparisons? The text from the
> > first paragraph quoted above indicates that RID systems will be checking
> > the association between a DNS domain name and an IP address, not
> > directly comparing DNS domain names (including IDNs). If that is true,
> > then we probably *don't* need to care much about comparison and any talk
> > of mappings is moot. Can you please verify that RID systems will be
> > checking the association with the IP address, rather than directly
> > comparing DNS domain names?
> > _______
> > KMM: I see your point here.  How about the following text to make it clear that the IP address is
> required and the DNS name is derived from the IP address:
> >
> >          1.  RIDSystem.  The IP address of the next upstream system accepting RID communications is
> REQUIRED and is listed in the Node element of the
> >              RIDPolicy class.  If NodeName element of the Node
> >              class is used, it contains a DNS domain name.  The
> >              originating RID system is required to check that this
> >              domain name resolves to the IP address to which the RID
> >              message is sent.  This check may be performed in advance of
> >              sending the message and the result saved for future use
> >              with additional RID messages.
> > ______
>
> Sure, that's fine. Then my question becomes: how exactly is the NodeName
> actually used in RID systems? It's the use that drives the
> internationalization considerations. If the NodeName is merely
> epiphenomenal and it's the IP address that we use to get things done,
> then we don't particularly care about the NodeName.
>
> >> (2) RIDPolicy class, MsgDestination=SourceOfIncident, and also the IncidentSource
> >> class.
> >>
> >> In both of these cases the IP address is the primary identifier (IncidentSource
> >> needs additional text to state that the IP address is required - that appears to
> >> have been overlooked).  There are a couple of options here:
> >>
> >> a) The simplest is to prohibit NodeName usage.
> >> b) NodeName could be required to correspond to the IP address via DNS lookup.
> >
> > In -09 that is:
> >
> >          2.  SourceOfIncident.  The Address element of the Node element
> >              contains the IP address of the incident source, and the
> >              NodeName element of the Node class is not used.  The IP
> >              address is used to determine the path of systems accepting
> >              RID communications that will be used to find the closest
> >              RID system to the source of an attack in which the IP
> >              address used by the source is believed to be valid and a
> >              Request message with MsgDst set to InvestigationRequest is
> >              used.  This is not to be confused with the IncidentSource
> >              class, as the defined value here is from an initial trace
> >              or investigation Request, not the source used in a Result
> >              message.
> >
> > I think it's fine to use IP address here.
> >
> > NOTE: you said that IncidentSource needs additional text to state that
> > the IP address required, but I do not see that here:
> > _____
> > KMM: Thanks, if we are fixing text, let's just add that now.  This one should be easy.
> >
> > Proposed:
> >          2.  SourceOfIncident.  The Address element of the Node element
> >              contains the IP address of the incident source, and the
> >              NodeName element of the Node class is not used.  The IP
> >              address is REQUIRED when this option is selected.  The IP address is used to determine
> the path of systems accepting
> >              RID communications that will be used to find the closest
> >              RID system to the source of an attack in which the IP
> >              address used by the source is believed to be valid and a
> >              Request message with MsgDst set to InvestigationRequest is
> >              used.  This is not to be confused with the IncidentSource
> >              class, as the defined value here is from an initial trace
> >              or investigation Request, not the source used in a Result
> >              message.
> > _____
>
> Looks good.
>
> > http://tools.ietf.org/rfcdiff?url1=draft-ietf-mile-rfc6045-bis-08&difftype=--
> html&submit=Go!&url2=draft-ietf-mile-rfc6045-bis-09
> >
> > However, I think that can be added before sending this document to the
> > RFC Editor, or during AUTH48.
> >
> >> (3) RIDPolicy class, MsgDestination=ext-value.  This is an escape that allows
> >> extensions to MsgDestination.  The description of this should include a "there
> >> be dragons" warning about IDNs in NodeName.
> >
> > In -09 that is:
> >
> >          3.  ext-value.  An escape value used to extend this attribute.
> >              All extensions shall specify the contents and meaning of
> >              the Node element of RIDPolicy.  If the NodeName element of
> >              Node is used by an extension, NodeName may contain an
> >              Internationalized Domain Name (IDN) and that IDN is
> >              required to satisfy the requirements in [RFC5890].  It is
> >              strongly recommended that RID Systems satisfy those IDN
> >              requirements via appropriate use of the DNS as opposed to
> >              implementing their own checks for these requirements.  For
> >              example, an extension could use both a NodeName and an IP
> >              address to which the NodeName resolves.  See IODEF
> >              [RFC5070], Section 5.1 on extensibility.
> >
> > That seems slightly underspecified: what is meant by "to satisfy the
> > requirements in [RFC5890]" and "appropriate use of the DNS"? Does that
> > mean "ensuring that the IDN retrieved from the DNS consists only of
> > U-labels and NR-LDH labels"? If so, is that done by asking the DNS
> > resolver for U-labels, or is it done by actively performing a check in
> > the RID system itself (see above about "MUST NOT be A-labels")?
> >
> > Is this something that is left for each extension to define? If so, we
> > should come out and say precisely that.
> > _______
> > KMM: The important part for RID is that we communicate and exchange messages in a way that everyone
> can accept and process.  Application handling for this translation, whether it be by DNS or some other
> mechanism, really shouldn't matter.  As long as the internationalization is handled in a way that lets
> us consistently exchange information, I think the real issues are solved, no?
> > If I add "See Section 11 of this document for
> >       Internationalization considerations."  Does that resolve the issue since it provides
> consistent guidance that enables the exchange of information?
> > _______
>
> Yes, we want to make sure that appliations handle these matters
> consistently. Pointing to Section 11 would solve that issue, as long as
> we can agree on what goes in Section 11. :)
>
> >> So, the answer to the somewhat rhetorical question:
> >>
> >>> Do IODEF/RID implementations want to sign up for all that?
> >>
> >> Is approximately "Yes, by relying on the DNS implementation," with the addition
> >> of a "there be dragons" warning to the MsgDestination ext-value extension text
> >> to communicate that to designers of extensions, and a possible prohibition of
> >> use of NodeName when the IP address is the primary identifier.
> >
> > I think we're getting close to reflecting that in text, but a few
> > clarifications would help, as would validation from the WG that this
> > direction is agreeable.
> >
> > I realize that these are thorny issues and that folks probably just want
> > someone to come from on high and say "yea verily, here is the one true
> > path to internationalization nirvana". Unfortunately, there is no such
> > path, so the WG needs to weigh the costs and benefits, clearly
> > understand what it's doing, and then make a decision one way or the
> > other. We've had too many WGs (some of which I've been involved with)
> > just take some i18n advice without knowledge, and the results have been
> > less then positive.
> >
> > Thanks for your patience!
> >
> > Peter
> > _________
> > Thank you for your detailed reviews!
>
> I'm here for you! ;-)
>
> Peter
>
> --
> Peter Saint-Andre
> https://stpeter.im/
>
>