Re: [Lager] Stephen Farrell's Discuss on draft-ietf-lager-specification-11: (with DISCUSS and COMMENT)

["Asmus Freytag (c)" <[e-mail]>]

On 5/16/2016 5:48 AM, Stephen Farrell wrote:
> Hiya,
>
> This is the promised (and delayed, sorry;-) follow up...
>
> On 28/04/16 20:58, Asmus Freytag (c) wrote:
>>> (4) section 12: I don't think this is at all sufficient.
>>> Missing aspects include: Imprecise LGRs could result in
>>> registration of identifiers that are unexpected in many other
>>> protocols, leading to new vulnerabilities; LGRs could be
>>> deliberately manipulated so as to create such imprecision, and
>>> if I could feed one such to a registry (e.g. via some nice
>>> friendly looking git repo) then I could exploit the vuln later
>>> for fun and profit - that seems to call for some
>>> interoperable form of data integrity and origin
>>> authentication (is the lager WG doing that?) and lastly (for
>>> now), the XML language defined here is very flexible as noted
>>> earlier - I would expect there to be many implementation bugs
>>> in new code that attempts to parse this language. So I think
>>> the security considerations needs to be re-done really.
>> My reading of this comment is that it presupposes a particular use-case.
> Isn't that use-case the reason why this language was developed?
> The charter says it is "primarily to support" that anyway, so
> I don't accept that this is just one amongst many use cases,
> if that's what you mean, but do correct me if I'm getting what
> you meant wrong.

The use case I was referring to is your scenario of registries 
"grabbing" random LGR definitions from open source repositories and 
making them policy without substantial review.

I think the more fundamental issue to cover is that the use of the LGR 
format - by itself - offers no guarantee of suitability of the LGR 
content (more on that below). That is a fair point. The security issues 
ultimately stem from the use of unsuitable policies, not from how they 
are expressed.
>
>> The use case we've identified so far is that these will substitute for
>> IDN tables.
>>
>> IDN tables are controlled by registries and define registry policy. As
>> such it would be up to the registry to have a policy that is well-defined,
>> and the registries would be in charge of developing or adopting an LGR
>> that matches their policies.
>>
>> The LGR data format (and that's what it is) doesn't change anything in who
>> can set and enforce registry policy.
> Correct. But doesn't this change who is likely to develop the
> (fragments of) documents that describe those policies and
> in doing so it could (IMO fairly easily) create unexpected
> side effects for other protocols.
>
>> I also do not understand what an "imprecise" LGR would be. In contrast
>> to what they replace (IDN tables), LGRs are way more definite.
> By "imprecise" I meant an LGR that allows some identifiers
> to end up in protocols where those identifiers cause problems.

Thanks for the clarification. That puts a different spin on things. An 
"imprecise" statement of label generation rules usually means you can't 
tell reliably which labels are being generated. However, let's take your 
definition of "doesn't automatically prevent unsuitable labels".

I fully agree. Nothing in the LGR format prevents unsuitable labels. 
It's just a format. Deciding what labels are suitable or not is the role 
of the LGR content. The draft makes limited, if any, recommendations for 
the contents of label generation rules.

> If there's a good argument that that can never happen then
> that'd be a fine counter-argument, but ISTM that the LGR
> language would allow that. Yes, a registry who did that could
> be called out for it, but fixing such things afterwards can
> be hard and some of the subtleties might take a while to get
> noticed.

Perhaps it would be useful to spell out that the draft (by specifying a 
format) does not by itself change what labels are generated.

It enables a number of techniques that might increase security: the 
format guarantees that each label will be definitely associated with a 
disposition, and many properties of a set of label generation rules can 
be mechanically verified.

In the root zone LGR process we found that having a consistent and 
unambiguous format greatly helps in understanding and reviewing LGR 
proposals, arguably a security benefit.
>> Issues of deployment of LGRs in IDN registration seem out of scope for
>> this document.
> I agree the specifics of any given LGR or registry policy
> aren't in scope but the fact that an "imprecise" (in the sense
> above) LGR could cause wider trouble in perhaps unexpected ways,
> is definitely worth noting here I think, unless that's just
> not really possible. (See above.)
>
> As a near-aside, you didn't tell me if the WG are considering
> issues such as origin authentication or provenance of LGR
> fragments in some other document. I'm not asking that this
> one be held up pending development of that, but I'd be
> interested in knowing. And if the WG aren't ever going to do
> that, which may be reasonable if nobody would deploy it,
> then that also argues for recognising the potential threats
> here. (E.g. that taking a snippet of an LGR from stackexchange
> might be problematic.)

I think it's fair to note that the use of the format places very little 
constraints on what can be expressed as LGR - and, in particular, that 
the use of the format in and of itself does not guarantee that the 
results are suitable.

However, I would argue that this is not the place to discuss all the 
unsuitable ways labels can be defined - because there are other, 
existing formats for label generation rules (aka IDN tables) which also 
allow the definition of policies that range from good to bad.
>
> Lastly, I'm sure you're correct that LGRs are probably more
> likely to be precise, compared to previous technologies such
> as IDN tables, but that does not mean that there's no need to
> recognise potential threats arising from LGRs even if those
> threats existed and were more likely to occur with tables.

For comparison, here is the language used in RFC 3743 (which defines one 
of the IDN table formats with which this draft is compatible):

    As discussed in the Introduction, substantially-unrestricted use of
    international (non-ASCII) characters in domain name labels may cause
    user confusion and invite various types of attacks.  In particular,
    in the case of CJK languages, an attacker has an opportunity to
    divert or confuse users as a result of different characters (or, more
    specifically, assigned code points) with identical or similar
    semantics.  These Guidelines provide a partial remedy for those risks
    by supplying a framework for prohibiting inappropriate characters
    from being registered at all and for permitting "variant" characters
    to be grouped together and reserved, so that they can only be
    registered in the DNS by the same owner.  However, the system it
    suggests is no better or worse than the per-zone and per-language
    tables whose format and use this document specifies.  Specific
    tables, and any additional local processing, will reflect per-zone
    decisions about the balance between risk and flexibility of
    registrations.   And, of course, errors in construction of those
    tables may significantly reduce the quality of protection provided.

We could certainly write equivalent language - but note, that language 
also does not go into details on what kind of bad tables one can write, 
only that it is possible. (And unlike RFC 3743 the draft does not 
contain "guidelines").

Will post suggested language when we have it,

A./
>
> Cheers,
> S.
>