Subject: [dane] DANE IETF LC state of play

From: Stephen Farrell <[email-masked]>
Date: Tue, 01 May 2012 10:12:43 +0100

Hi all,

Well that's been a busy IETF LC. I think that shows that this is an
important spec and the editors and chairs have done a great job
so far on handling IETF LC comments, but I think there is a bit more
work to do to be sure we're done and we may as well get that done
now before the IESG are let loose on it:-)

I went through the DANE WG archive of all the IETF LC comments and
found the following ones where its not crystal clear from the archive
that they're sorted.

Notes: a) they might be just fine, e.g. if just one person comments
and nobody else thought it important, then doing nothing is probably
right. these just weren't clear from the archive so I wanna check;
b) I only had time to scan the WG archive, if there are mails that
were only to [email-masked] or apps-discsuss that resolved these
then I missed them, so just tell me about that, so I'll forward
this to the other lists to check as well.

So here's the list:

1) Jeff Hodges
http://www.ietf.org/mail-archive/web/dane/current/msg04695.html
http://www.ietf.org/mail-archive/web/dane/current/msg04713.html

I mailed Jeff to see if -20 is ok. Silence can be taken to mean
yes I think but since he had a bunch of things its hard to be
sure.

2) PSA
http://www.ietf.org/mail-archive/web/dane/current/msg04702.html
http://www.ietf.org/mail-archive/web/dane/current/msg04790.html

There are a few more small things still open in the last mail
from earlier today.

3) Dave Cridland
http://www.ietf.org/mail-archive/web/dane/current/msg04624.html

I think there are still some occurrences of "certificate type"
in section 8, (e.g. 3rd para, p18) so those weren't all fixed.
I think that's the only remaining thing from Dave's review.

4) John Gilmore,
http://www.ietf.org/mail-archive/web/dane/current/msg04635.html

A.1 only has CA examples, what about non CA uses? I didn't see
any reaction to that and it seems like a fair comment.

5) John Gilmore
http://www.ietf.org/mail-archive/web/dane/current/msg04637.html

John thinks there's a bias in sections 8/8.1, but I didn't see
any reaction to that (other than mine, which just said "please
do the right thing, whatever that is")

6) Mark Andrews
http://www.ietf.org/mail-archive/web/dane/current/msg04657.html

Again, not sure if there was follow-up.

7) PHB
http://www.ietf.org/mail-archive/web/dane/current/msg04709.html

Don't mandate client security policy (hardfail). I didn't see
an obvious conclusion reached to make a change or not make a
change.

8) Various on SRV
http://www.ietf.org/mail-archive/web/dane/current/msg04793.html

I think this might need a tweak to the SRV language in 1.3 (and
just suggested one).

Cheers,
Stephen.

---

From: "Marc Lampo" <[email-masked]>
Date: Tue, 8 May 2012 15:52:36 +0200 (CEST)

Hello,

(sorry for late jump in)

There is a remark about section 8 and SSL proxies.

My feeling is the topic condition were SSL proxy is present
is not yet treated with sufficient depth.

1) I'd see the (conventional) proxy as a DANE-unaware client,
    in which case fall back scenario is described.

   Or proxy implementers may enhance the implementation by supporting
DANE.
    In which case some error messages may have to be defined
    reflecting abnormalities in the DANE protocol, experienced by the
proxy.

2) The proposed draft for DANE states, in that section 8, on SSL proxy.
    "In such environments, using TLSA records will prevent the SSL proxy
     from functioning as expected because the TLS client will get a
     certificate association from the DNS that will not match the
     certificate that the SSL proxy uses with the client."

   --> I think what is actually meant is the connection between
       TLS client on end-user equipment (browser) and the proxy.
       The "connection" could work fine between proxy and TLS service
        (either because TLSA is ignored - "unknown" -
	   or because DANE is supported)
!! --> the text assumes that the end-user equipment does indeed get
        the TLSA RR from the external service.
        In proxy setups, this might not be true !
	  Since internal clients don't need Internet resolving,
	   there access to public DNS might be limited for good reason !
         (think "internal root servers")

    Overall, my feeling is that end-user clients that access TLS
     services via a proxy, should make exceptions to how they handle DANE.
     (like : knowing how the proxy handles DANE)

Please don't mistake me :
 I generally like what DANE offers as extra !
 But my feeling is only that the case of SSL proxy needs more elaboration.

Kind regards,

Marc Lampo

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: 01 May 2012 11:13 AM
To: dane
Subject: [dane] DANE IETF LC state of play

Hi all,

Well that's been a busy IETF LC. I think that shows that this is an
important spec and the editors and chairs have done a great job so far on
handling IETF LC comments, but I think there is a bit more work to do to
be sure we're done and we may as well get that done now before the IESG
are let loose on it:-)

I went through the DANE WG archive of all the IETF LC comments and found
the following ones where its not crystal clear from the archive that
they're sorted.

Notes: a) they might be just fine, e.g. if just one person comments and
nobody else thought it important, then doing nothing is probably right.
these just weren't clear from the archive so I wanna check;
b) I only had time to scan the WG archive, if there are mails that were
only to [email-masked] or apps-discsuss that resolved these then I missed
them, so just tell me about that, so I'll forward this to the other lists
to check as well.

So here's the list:

1) Jeff Hodges

I mailed Jeff to see if -20 is ok. Silence can be taken to mean yes I
think but since he had a bunch of things its hard to be sure.

2) PSA

There are a few more small things still open in the last mail from earlier
today.

3) Dave Cridland

4) John Gilmore,

A.1 only has CA examples, what about non CA uses? I didn't see any
reaction to that and it seems like a fair comment.

5) John Gilmore

John thinks there's a bias in sections 8/8.1, but I didn't see any
reaction to that (other than mine, which just said "please do the right
thing, whatever that is")

6) Mark Andrews

7) PHB

Don't mandate client security policy (hardfail). I didn't see an obvious
conclusion reached to make a change or not make a change.

8) Various on SRV

I think this might need a tweak to the SRV language in 1.3 (and just
suggested one).

Cheers,
Stephen.

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 9 May 2012 13:35:28 +0200

> is not yet treated with sufficient depth.

The questions is whether it does have to be treated in depth?

>     certificate that the SSL proxy uses with the client."

Would it help to replace: "the TLS client" with "the DANE-aware TLS client"?

If not, could you please provide proposed text to fix that?  I am not feeling
that we have to cover all possible cases here, I think that we can safely assume
that the "client" here is compliant with the document protocol.

> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

--
 Ondřej Surý -- Chief Science Officer
 -------------------------------------------
 CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
 Americka 23, 120 00 Praha 2, Czech Republic
 mailto:[email-masked]    http://nic.cz/
 tel:+420.222745110       fax:+420.222745112
 -------------------------------------------

---

From: "Marc Lampo" <[email-masked]>
Date: Wed, 9 May 2012 14:58:45 +0200 (CEST)

Hello,

In my opinion the "client" side should not be ignored !

The present text implicitly assumes the browser
- has direct access to the server
- has unlimited access to public DNS data
    (obviously, since it must be able to query for IP address of the server)

Only in that section 8, the existence of "SSL Proxy" is mentioned.
And the phrasing is such that it mostly suggest : "DANE won't work".

Why not insert a section between present 6. and 7.
that addresses this "client" side ?

I see four cases :
X.1. Unlimited access to DANE service and to public DNS

Explain that this is the initial assumption.

X.2. Client accesses DANE service via explicit SSL proxy,
     and has unlimited access to public DNS.

In this condition the client is aware of the existence of that SSL proxy,
and it is aware of the service TLSA RR.

X.3. Client accesses DANE service via implicit SSL proxy,
     and has unlimited access to public DNS.

In this condition the client is not aware of the existence of that SSL 
proxy,
and it is aware of the service TLSA RR.

X.4. Client accesses DANE service via explicit SSL proxy,
     and does not have access to public DNS.

In this condition the client is aware of the existence of that SSL proxy,
and it is not aware of the service TLSA RR.

I think the document would benefit from explicit statements
about those conditions.

To benefit as much as possible from DANE,
I think the authors can propose how to cope with situation X.2
 - explicit proxy + full access to public DNS -,
in such a way that the end-user is not punished by the existence of
the SSL proxy --> allow for exceptions when not to insist on DANE 
validation.

As well as with situation X.4
 - explicit proxy + no access to public DNS - :
since the browser client sees no TSLA RR (even "worse" : NXDOMAIN)
this situation could be permitted (no DANE validation by browser).

Situation X.3
 - implicit proxy, with full access to public DNS -
is problematic (as far as I can see - yet another reason to avoid implicit 
proxy)

I do think it is out of scope of "this" document
to describe possible "extensions" that allow
full benefit of DANE to clients behind explicit proxies.
That would be some kind of "dialogue" between
the explicit, DANE aware, proxy and the browser.
(in a first impulse :
 like adding a TLSA record on the proxy's (internal) DNS data
 that
 - confirms this proxy is a client supporting DANE
 - acknowledges the certificate of this explicit proxy
    (like : certificate usage field value of value #4
            which is comparable to #3 - domain issued certificate -
            but that implies the certificate is of the proxy
            not the DANE service.)
 ((please don't shoot me for this suggestion,
   I am by no means a specialist in DANE))

Please forgive that I do not attempt to provide directly useable text;
I have by no means the in depth insight in DANE to do so.

Kind regards,

Marc Lampo

-----Original Message-----
From: Ondřej Surý [mailto:[email-masked]]
Sent: 09 May 2012 01:35 PM
To: Marc Lampo
Cc: 'Stephen Farrell'; 'dane'
Subject: Re: [dane] DANE IETF LC state of play

On 8. 5. 2012, at 15:52, Marc Lampo wrote:

> My feeling is the topic condition were SSL proxy is present is not yet
> treated with sufficient depth.

If not, could you please provide proposed text to fix that?  I am not 
feeling that we have to cover all possible cases here, I think that we can 
safely assume that the "client" here is compliant with the document 
protocol.

> important spec and the editors and chairs have done a great job so far
> on handling IETF LC comments, but I think there is a bit more work to
> do to be sure we're done and we may as well get that done now before
> the IESG are let loose on it:-)
>
> right.
> were only to [email-masked] or apps-discsuss that resolved these then I
> missed them, so just tell me about that, so I'll forward this to the
> other lists to check as well.
>
> So here's the list:
>
> 1) Jeff Hodges
> There are a few more small things still open in the last mail from
> earlier today.
>
> 3) Dave Cridland
> reaction to that (other than mine, which just said "please do the
> right thing, whatever that is")
>
> 6) Mark Andrews
> Don't mandate client security policy (hardfail). I didn't see an
> obvious conclusion reached to make a change or not make a change.
>
> 8) Various on SRV

---

From: Paul Wouters <[email-masked]>
Date: Wed, 9 May 2012 09:39:25 -0400 (EDT)

> The questions is whether it does have to be treated in depth?

We could do more then just state "you have a problem". How about:

    When a TLS client supporting TLSA records is configured to use an SSL
    proxy, it should have one or more of the following features:

    o Disable all DNS lookups when using an SSL proxy (eg SOCKS proxy)
    o Disable or allow to disable TLSA validation when using an SSL proxy
    o Treat the SSL certificate of the configured SSL proxy as a valid override
      for information obtained from TLSA records.
    o Prominently warn if the SSL proxy certificate does not validate to
      a configured PKIX trust anchor.

    TLS clients configured to use an SSL proxy should clearly display the
    certificate owner name of the SSL proxy at locations where normally the
    remote TLS certificate information is displayed to prevent the malicious
    configuration of an SSL proxy without the user's consent.

One thing I'm not sure about is what to do with TLSA-based SSL proxy
certificates. It might be nice to configure those for trust, but could
also lead to rogue configurations of SSL proxy that validate their
certificate to a random TLSA record on a remote malicious site.

Paul

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 9 May 2012 15:44:06 +0200

>   configuration of an SSL proxy without the user's consent.

This is a very bad idea to do in the "protocol" document.  We don't want
to have a kitchensink protocol document which includes all.

Personally I am just fine with 'you have a problem' statement and let the
people solve it elsewhere if they care.

O.

---

From: Warren Kumari <[email-masked]>
Date: Wed, 9 May 2012 13:15:21 -0400

> people solve it elsewhere if they care.

<aol>Me too!</aol>

<chair>Hmmm, this sounds like a really nice idea for a follow on document -- "How to do DANE like things in the presence of proxies" or something... Submissions considered...</chair>

W