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

Martin Thomson <> Mon, 23 March 2015 14:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3B28F1A8AC9 for <>; Mon, 23 Mar 2015 07:06:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UO7QTYz7Am9N for <>; Mon, 23 Mar 2015 07:06:38 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5F4E41A8AAE for <>; Mon, 23 Mar 2015 07:06:38 -0700 (PDT)
Received: by obcxo2 with SMTP id xo2so123659346obc.0 for <>; Mon, 23 Mar 2015 07:06:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QJW9JQi3puyJLvWAodwNchx7V1jzQanz85hZPs+QE2U=; b=grJ5D4dAjzVHgF/e5DZQheXyltp/XWc3SKazdA1s0tNEi2ZiuIVrxQQ5XX5dzsr6y5 AHQ3C6R9SegUpDH9F094Ocfa3BqPQn1XUnBbT9EABOpDOD8nYhjpYYAlpuLpev4o3wtJ CCw9C3u78arLOg2Fj9zfepvWtXjLVXHZ3x5qk2L9CfXdax1UB+9T9EmwbM+UEg/KuZEF nHcjpb/aG0J56LKbdpX2XNzxx7iwahPHBZWfx2FLKxGzE9uFT9ZttUQz2pcb8edj4Oag 6aEr5c2jpGZIloBpdDLmTfSpaAC1vZ/SJMUqp5vr9HcUdUMavkgn8oCM53gz28vtm/bc xXdw==
MIME-Version: 1.0
X-Received: by with SMTP id n9mr70519555oia.20.1427119597949; Mon, 23 Mar 2015 07:06:37 -0700 (PDT)
Received: by with HTTP; Mon, 23 Mar 2015 07:06:37 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Mon, 23 Mar 2015 07:06:37 -0700
Message-ID: <>
From: Martin Thomson <>
To: Stefan Winter <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Cc: "" <>,
Subject: Re: [Gen-art] [radext] Gen-ART review of draft-ietf-radext-dynamic-discovery-13
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 23 Mar 2015 14:06:40 -0000

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 <> wrote:
> Diameter defines its own S-NAPTR tags in its own RFCs


>> 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. 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."


> (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)


>> 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.)