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

[Stephen Farrell <[e-mail]>]

Hiya,

Yes, an addition such as you suggest below should be
good enough to sort the discuss.

Thanks,
S.

PS: You still didn't tell me if the WG plans to think
about origin auth and provenance or not. I guess that
means there are no such plans.

On 16/05/16 18:21, Asmus Freytag (c) wrote:
> 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.
>>
>