Subject: [dane] Fwd: [apps-discuss] DANE IETF LC state of play

From: Paul Hoffman <[email-masked]>
Date: Tue, 1 May 2012 12:03:31 -0700

Begin forwarded message:

> From: SM <[email-masked]>
> Subject: Re: [apps-discuss] [dane] DANE IETF LC state of play
> Date: May 1, 2012 11:23:04 AM PDT
> To: Paul Hoffman <[email-masked]>
> Cc: Apps Discuss <[email-masked]>
> 
> Hi Paul,
> At 10:27 01-05-2012, Paul Hoffman wrote:
>> Those interpretations were by people who didn't believe the text that MX and SRV were purposely not addressed.
> 
> Ok.
> 
>> I believe I did: I repeated the "we're not addressing this" text so it appears twice.
> 
> Sorry, I must have missed that.
> 
>> They are not addressed because they have nothing to do with the protocol in the document. Please let me know if you still disagree, and send proposed text to the DANE WG.
> 
> I'll post the text here as part of IETF Last Call comments if it is ok with you/the WG.  I am not including the arguments to avoid rehashing what was said before.  Please ask if the arguments are needed.
> 
> In section 1.3:
> 
> Proposed text:
> 
> "Note that this document does not cover how to associate certificates
>  with domain names for application protocols that depend on MX, SRV, NAPTR,
>  and similar DNS resource records; it is expected that later updates to
>  this document might cover methods for making those associations."
> 
> I suggest removing the following text in Section 3:
> 
>  'To request a TLSA resource record for an SMTP server running the
>   STARTTLS protocol on port 25 at "mail.example.com",
>   "_25._tcp.mail.example.com" is used.'
> 
> in Section 8:
> 
>   A DNS administrator who goes rogue and changes both the A, AAAA, CNAME
>   and/or TLSA records for a domain name can cause the user to go to an
>   unauthorized server that will appear authorized, unless the client
>   performs PKIX certification path validation and rejects the
>   certificate.
> 
>   If the authentication mechanism for adding or changing TLSA data in a
>   zone is weaker than the authentication mechanism for changing the A
>   AAAA, and/or CNAME records, a man-in-the-middle who can redirect traffic
>   to their site may be able to impersonate the attacked host in TLS if
>   they can use the weaker authentication mechanism.
> 
> Regards,
> -sm

---

From: "Marc Lampo" <[email-masked]>
Date: Wed, 9 May 2012 09:26:25 +0200 (CEST)

Hello,

(sorry for late jump in)

http://www.ietf.org/mail-archive/web/dane/current/msg04702.html

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

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