Re: [Gen-art] [radext] Gen-ART review of draft-ietf-radext-dynamic-discovery-13

[Martin Thomson <[e-mail]>]

Thanks.  I think that you have everything in hand.  I'm happy with the
promised changes.

On 23 March 2015 at 01:16, Stefan Winter <[e-mail]> wrote:
> Diameter defines its own S-NAPTR tags in its own RFCs

Ack.

>> S2.1.1.2 uses SHOULD to recommend that clients retry with their other
>> certificates.  I'd recommend use of MAY here, unless you would like to
>> expand on why this a SHOULD is valuable.
>
> Well... realm discovery is triggered typically by an end user trying to
> authenticate. If a client has a certificate but doesn't want to show it,
> this becomes an avoidable DoS for the user. Also, if the client doesn't
> always try the certificates in the same order, the connection setup also
> becomes indeterministic - sometimes it works, sometimes not.
>
> The clause makes a case for "don't give up prematurely" and makes the
> behaviour deterministic.
>
> So, I believe a SHOULD is the right thing to ask for here - would you
> prefer an updated draft with this reasoning included, or are the
> explanations in this mail sufficient?

I think that mentioning the consequences would be wise.  The
incentives are certainly properly aligned.  (I do worry about the
inordinate number of protocol steps this is going to introduce, but I
guess that is the point of the experiment.)

>> S2.1.1.3.3. I know that this is experimental and all, but this seems a
>> little too hand-wavy even for that.  I think that this is the right
>> design, but the section could be a little more confident (and precise)
>> in the description of how this works.  It took me a couple of goes to
>> understand how this was intended to work.  One important realization
>> was that a common root for the realm needs to be configured.  I'd like
>> to see this section expanded slightly (my initial inclination would
>> have been toward removal, but the content is in line with the
>> experiment, so it's probably valuable).
>
> Oh, it's totally handwavy, agreed :-) The mechanism described here is
> not implemented anywhere, and DANE in general only deals with the
> server-side auth, leaving a gaping hole on the question how to validate
> client certs. So, it really is just a sketch - that's why I used that
> word in the text.
>
> Actually I find that approach rather elegant, but it would take people
> with a lot of energy to pick it up, complete the DANE specs for
> client-side auth, implement TLS libraries that can do this, and to
> actually deploy it.
>
> I'm not sure I know how to handle your comment text-wise... when it
> comes to the need of a common root, I would have hoped that there is
> already text making it clear, i.e.:
>
> "if
>    DANE/TLSA records of all authorized servers are put into a DNSSEC
>    zone with a common, consortium-specific branch of the DNS tree, then
>    the entity executing the algorithm can retrieve TLSA Resource Records
>    (TLSA RR) for the label "realm.commonroot" [...]"
>
> If you can suggest specific text that helps readers understand this
> easier, I'm all ears...

Much of the rest of the document is more precise about the steps
involved.  I got the sense that the DANE text was rushed or cursory.
I'd rather see a more precise description of the steps that a client
would use; or the text could be removed; or the text could be reduced
to something even more vague ("You could use TLSA records for this.")

> Actually, even if DNS is trustworthy, the authorisation needs to be
> checked. It's more like:
>
> (new)
> "Regardless whether the results from DNS discovery are trustworthy or
> not (e.g. DNSSEC in use), it is always important to verify that the
> server which was contacted is authorized to service requests for the
> user which triggered the discovery process."

WFM

> (What I planned to say there was that if DNS without SEC is used, not
> only the authorisation is in question and needs to be checked, but also
> the discovered IP/port; but that's not totally important in itself
> because the authorisation check comes unconditionally and covers both
> anyway)

Right.

>> S 3.4.3 doesn't cover how to handle NAPTR records with flags set to
>> "a", though other parts of the document describe that.  I think there
>> is some refactoring of the dependency on the S-NAPTR algorithm, and an
>> allowance for a default port.
>
> That's already done in step 9, which basically hands off further
> resolution to S-NAPTR by stating: "For the extracted NAPTRs, perform
> successive resolution as defined in [RFC3958], section 2.2."
>
> If anything, poiting to section 2.2 is maybe too specific, because many
> parts of RFC3958 are about "s" and "a" NAPTR entries; do you think it
> makes the document more readable if I remove the "section 2.2" ?

No, that's fine.  I was just concerned about the port part; I see that
it is there, but it's fairly obtuse.  (My reaction is partly in error:
I was relying on my memory of 3958 a little too much.)

[...]