Subject: Re: [keyassure] draft-ietf-dane-protocol-02 posted - RR name

From: Yaron Sheffer <[email-masked]>
Date: Sun, 16 Jan 2011 12:51:22 +0200

Hi Paul,

No, I am not taking any sides regarding support for protocols that are 
not mentioned in the charter (which is Issue #5). Note that IPsec itself 
is, in fact, already in the charter.

Neither am I proposing to expand the scope of the current document 
(which is Issue #17). I actually prefer the current focus.

I am just proposing the make the record's *name* protocol-agnostic, so 
it can be reused in the future without excuses.

Thanks,
	Yaron

> Date: Sat, 15 Jan 2011 17:00:44 -0800
> From: Paul Hoffman<[email-masked]>
> Subject: Re: [keyassure] draft-ietf-dane-protocol-02 posted
> To: [email-masked]
> Message-ID:<[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 1/15/11 1:00 PM, Yaron Sheffer wrote:
>
>> I have an issue with the name of the DNS record type. "TLSA" implies one
>> specific protocol. The working group's scope includes additional ones,
>> and those and possibly others will want to use the same record type,
>> hopefully.
>
> This would be issue #5 on our open issues list (reminder:
> <http://trac.tools.ietf.org/wg/dane/trac/report/1>). Are you trying to
> get the chairs to start this discussion sooner than the others they
> might want? :-) [1]
>
> --Paul Hoffman
>
> [1] The smiley there is because Yaron is co-chair of the IPsecME WG with
> me and we tend to run our group off the issue tracker.
>
>
> ------------------------------
>

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 16 Jan 2011 08:00:20 -0800

> it can be reused in the future without excuses.

Ah, I didn't realize this was a bikeshed discussion. :-) I would prefer 
to keep the name as tied to what we know it will be used for and let 
other people do deltas if they want.

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 16 Jan 2011 21:42:49 +0200

Hi Paul,

For the first sentence of 3.1.2, I don't care if it's SHOULD or MUST. 
But it's got to be normative.

Having reread 3.1.3, I am literally shocked by the way we propose to 
deal with certs that (1) validate OK with respect to DNSSEC but (2) do 
not chain up to a known trust anchor. We propose to leave the decision 
to the user, just like the bad old days of PKI!

Instead, I suggest to replace *both* 3.1.3 and 3.1.4 by the following text:

3.1.3 Non-Validated Certificates

Certificates that are correctly associated with a domain name, but which 
do not chain into a locally stored trust anchor, are no different from 
self-signed certificates. Therefore, only their public key can be used 
in conjunction with the associated domain name. Other pertinent data in 
the certificate, such as the Subject, Issuer and Subject Alternative 
Name fields, as well as EV indications, MUST be ignored. In particular, 
TLS clients MUST NOT present such data to the user.

[Alternatively, if we suggest to give Type 3/4 associations the full CA 
treatment, where the complete cert chain becomes trusted, this may also 
be fine. But we should not leave this decision to the end user!]

Thanks,
	Yaron

> Date: Sat, 15 Jan 2011 17:08:11 -0800
> Subject: Re: [keyassure] draft-ietf-dane-protocol-02 posted - cert
> 	validation
> To: [email-masked]
> Message-ID:<[email-masked]>
> On 1/15/11 1:15 PM, Yaron Sheffer wrote:
>> Sec. 3.1.2 of the draft singles out self-signed certs, where "host
>> names" (in the section title) or "all data other than the key" (first
>> paragraph) is ignored.
>>
>> I have two issues here:
>>
>> - The first paragraph should have a normative SHOULD, instead of "can".
>> The data is indeed untrustworthy and clients SHOULD ignore it unless
>> validated otherwise.
>
> This was argued about previously, I think. This should be a new open
> issue because it deals with adding a 2119-level restriction. Also, why
> "SHOULD" and not "MUST"? When is is OK to not ignore the data? (FWIW, I
> don't have strong feelings either way on any of this).
>
>> - The exact same considerations apply to non-self signed certs. I don't
>> see a reason to talk specifically about self-signed certs.
>
> We disagree here. The Issuer field in a CA certificate cannot be ignored
> when doing PKIX chaining.
>
>> Just because
>> someone presents a cert that has, say, Verisign as the Issuer, doesn't
>> mean it is a valid Verisign certificate unless validated in the
>> traditional manner.
>
> Um, exactly. But self-signed certs are not "validated in the traditional
> manner", which is why this section exists.
>
>> So none of the certificate data can be trusted,
>> including the important Subject and SubjectAltName fields. Sec. 3.1.4
>> kind of implies this fact, but the incorrect differentiation between
>> regular and self-signed certs remains.
>
> I believe there is a strong differentiation between "was validated" and
> "wasn't validated". If you and I are saying the same thing, I would love
> to see text to clarify what we have written.
>
> --Paul Hoffman
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 16 Jan 2011 16:23:54 -0500

Mostly agree

But restrictions on the validity and/or use of the certificate MUST still be
observed.

i.e. if a self-signed certificate says that the subject is Bank of Ethel
then that is a positive statement and MUST be ignored.

But if the certificate says 'not valid after X' or 'only for protocol Y' or
has an unknown critical extension then it MUST be rejected.

On Sun, Jan 16, 2011 at 2:42 PM, Yaron Sheffer <[email-masked]>wrote:

> Hi Paul,
>
> For the first sentence of 3.1.2, I don't care if it's SHOULD or MUST. But
> it's got to be normative.
>
> Having reread 3.1.3, I am literally shocked by the way we propose to deal
> with certs that (1) validate OK with respect to DNSSEC but (2) do not chain
> up to a known trust anchor. We propose to leave the decision to the user,
> just like the bad old days of PKI!
>
> Certificates that are correctly associated with a domain name, but which do
> not chain into a locally stored trust anchor, are no different from
> self-signed certificates. Therefore, only their public key can be used in
> conjunction with the associated domain name. Other pertinent data in the
> certificate, such as the Subject, Issuer and Subject Alternative Name
> fields, as well as EV indications, MUST be ignored. In particular, TLS
> clients MUST NOT present such data to the user.
>
> treatment, where the complete cert chain becomes trusted, this may also be
> fine. But we should not leave this decision to the end user!]
>
> Thanks,
>        Yaron
>
>>  _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

-- 
Website: http://hallambaker.com/

---

From: Paul Wouters <[email-masked]>
Date: Sun, 16 Jan 2011 21:08:29 -0500 (EST)

On Sun, 16 Jan 2011, Phillip Hallam-Baker wrote:

> Mostly agree
> But restrictions on the validity and/or use of the certificate MUST still be observed.
> 
> i.e. if a self-signed certificate says that the subject is Bank of Ethel then that is a positive statement and
> MUST be ignored.
> 
> But if the certificate says 'not valid after X' or 'only for protocol Y' or has an unknown critical extension
> then it MUST be rejected.

I am not sure if I agree (or disagree)

If the pubkey is DNSSEC validated, shouldn't it be treated as valid? especially in the
absence of a validation by a CA (eg a self signed cert)

I forsee people adding existing non-CA, self signed certs in DNS and forgetting their
validity period. And in some sense whether or not the validated pubkey is in DNSSEC,
is the claim of validity.

However I also expect browsers not to take these certificates too different from their
existing policies with respect to displaying non-validated certificate properties. So
this issue is somewhat moot, the admin should generate a proper certificate and hopefully
later can use a bare public key TLS variant to avoid all of this.

I guess I could live with either, which means its probably a local user/vendor policy
decision? eg I could see a browser popup for this.

The one thing I am feeling more strongly about, is the ignoring of the CN= in self signed
certs and taking the DNS location of the TLSA record as the authority for the certificate
being valid, even if the CN= does not match. Specifically because it eases larger scale
ssl deployment, which I think is one of the goals of this draft.

Paul

> On Sun, Jan 16, 2011 at 2:42 PM, Yaron Sheffer <[email-masked]> wrote:
>       Hi Paul,
>
>       For the first sentence of 3.1.2, I don't care if it's SHOULD or MUST. But it's got to be
>       normative.
>
>       Having reread 3.1.3, I am literally shocked by the way we propose to deal with certs that (1)
>       validate OK with respect to DNSSEC but (2) do not chain up to a known trust anchor. We propose to
>       leave the decision to the user, just like the bad old days of PKI!
>
>       Certificates that are correctly associated with a domain name, but which do not chain into a
>       locally stored trust anchor, are no different from self-signed certificates. Therefore, only their
>       public key can be used in conjunction with the associated domain name. Other pertinent data in the
>       certificate, such as the Subject, Issuer and Subject Alternative Name fields, as well as EV
>       indications, MUST be ignored. In particular, TLS clients MUST NOT present such data to the user.
>
>       [Alternatively, if we suggest to give Type 3/4 associations the full CA treatment, where the
>       complete cert chain becomes trusted, this may also be fine. But we should not leave this decision
>       to the end user!]
>
>       Thanks,
>              Yaron
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 16 Jan 2011 21:32:38 -0500

If the creator of a self signed certificate chose to put restrictions on its
use then those should be respected.

I would like it to be possible for services like SMTP to establish TLS keys
with minimal infrastructure. That can't happen if there is a risk that the
low assurance SMTP key will compromise the high assurance Web Server.

On Sun, Jan 16, 2011 at 9:08 PM, Paul Wouters <[email-masked]> wrote:

>> deal with certs that (1)
>> fields, as well as EV

---

From: Paul Wouters <[email-masked]>
Date: Sun, 16 Jan 2011 21:54:17 -0500 (EST)

On Sun, 16 Jan 2011, Phillip Hallam-Baker wrote:

> If the creator of a self signed certificate chose to put restrictions on its use then those should be
> respected.

You are probably right - especially if the creator has a future choice of bare public key TLS.

> I would like it to be possible for services like SMTP to establish TLS keys with minimal infrastructure. That
> can't happen if there is a risk that the low assurance SMTP key will compromise the high assurance Web Server.

I'm not sure how this problem would work. Can you explain it in a little more detail?

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 17 Jan 2011 07:52:22 -0500

On Sun, Jan 16, 2011 at 9:54 PM, Paul Wouters <[email-masked]> wrote:

>> can't happen if there is a risk that the low assurance SMTP key will
>> compromise the high assurance Web Server.
>>
>

Let us say that the authors of Sendmail decide that they want to make it
easy to turn on STARTTLS.

So when the server is configured it looks to see if there is DNSSEC on the
domain associated with its host name. If so it generates a public key pair,
rolls itself a certificate and either tells the admin the DNS RR to insert
in the zone or uses a TSIG type mechanism to register the key itself.

For this to be acceptable two conditions need to be met:

1) The security must be adequate for the SMTP service

2) The mechanism must not reduce the security of any other service at the
domain

Since SMTP is generally engaged without cryptographic security, any
improvement is better than none and the first condition is a really low bar.

But the second can be very complex. Particularly since the authors of the
mail server don't want to have any idea what the rest of the infrastructure
might be at a site.

The safest way to make this work automatically is to make it possible for
the mail service to mark its keys for SMTP use only.

---

From: Ondřej Surý <[email-masked]>
Date: Mon, 17 Jan 2011 14:48:54 +0100

On 17.1.2011 13:52, Phillip Hallam-Baker wrote:
>
>
> On Sun, Jan 16, 2011 at 9:54 PM, Paul Wouters <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>         I would like it to be possible for services like SMTP to
>         establish TLS keys with minimal infrastructure. That
>         can't happen if there is a risk that the low assurance SMTP key
>         will compromise the high assurance Web Server.
>
>
> So when the server is configured it looks to see if there is DNSSEC on
> the domain associated with its host name. If so it generates a public
> key pair, rolls itself a certificate and either tells the admin the DNS
> RR to insert in the zone or uses a TSIG type mechanism to register the
> key itself.
>
>
> 2) The mechanism must not reduce the security of any other service at
> the domain
>
>
> But the second can be very complex. Particularly since the authors of
> the mail server don't want to have any idea what the rest of the
> infrastructure might be at a site.
>
> The safest way to make this work automatically is to make it possible
> for the mail service to mark its keys for SMTP use only.

I don't think we need to solve 2) from this babysitting perspective.

What you are talking about is about having different certs for different 
services and we are back at issue #1 in the tracker.

If I take your example then most common case is that SMTP server is 
named mail.<something>, f.e. mail.example.net.  And I guess in most 
cases it will not clash with another services under this name.  And it 
should be handled by the admins in the few corner cases where the name 
of the mail server is same as name of some other important service.

Ondrej
-- 
  Ondřej Surý
  vedoucí výzkumu/Head of R&D department
  -------------------------------------------
  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: Paul Wouters <[email-masked]>
Date: Mon, 17 Jan 2011 09:17:37 -0500 (EST)

On Mon, 17 Jan 2011, Phillip Hallam-Baker wrote:

> Let us say that the authors of Sendmail decide that they want to make it easy to turn on STARTTLS.
> So when the server is configured it looks to see if there is DNSSEC on the domain associated with its host name. If so it generates a public
> key pair, rolls itself a certificate and either tells the admin the DNS RR to insert in the zone or uses a TSIG type mechanism to register the
> key itself.
> 
> 2) The mechanism must not reduce the security of any other service at the domain

It also assumes a "higher secure level" is available for the other (say www) service, which
already has a cert - issued by the sysadmin and/or signed by a CA -thus using PKIX.

> Since SMTP is generally engaged without cryptographic security, any improvement is better than none and the first condition is a really low
> bar.

Sure.

> But the second can be very complex. Particularly since the authors of the mail server don't want to have any idea what the rest of the
> The safest way to make this work automatically is to make it possible for the mail service to mark its keys for SMTP use only. 

I'm still unsure how this affects the cert on the web port? If we have
multiple TLSA certs in DNS under the same name, and one appears on the
mail server and one on the http server, how did the security of the http
server get reduced by sendmail adding its cert to its config and DNS?

At most, I can think of some compromise/mistake where the mail cert would
get used on the httpd server. Eg a hacker compromises the webserver, the
webserver cert is stored on disk (not in hardware) and password protected
(which AFAIK is quite rare on web servers these days) and will now use
the mail server cert on the web server to do evil. All of which I think
could be done without restarting the webserver and thus losing the web
server certificate.

Any sufficiently important web server cert will be in stored in hardware
and will be run on a dedicated server that is not also running mail.

So I find it hard to see a real life use case where abusing the multiple
TLSA certificates would provide a real life issue.

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 17 Jan 2011 09:20:27 -0500

Rule number one is do no harm.

If this group proposes a spec that damages the security of other
infrastructure it is going to be resisted.

DNS name allocation has always been left to site policy. The target of an MX
record is required to be a canonical name. Thus it should be the unique name
of the host.

If you want to propose unnecessary changes to DNS operations to make your
specification proposal work then you are going to find getting IETF
consensus very difficult.

On Mon, Jan 17, 2011 at 8:48 AM, Ondřej Surý <[email-masked]> wrote:

> If I take your example then most common case is that SMTP server is named
> mail.<something>, f.e. mail.example.net.  And I guess in most cases it
> will not clash with another services under this name.  And it should be
> handled by the admins in the few corner cases where the name of the mail
> server is same as name of some other important service.
>
> Ondrej
> --
>  Ondřej Surý

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 17 Jan 2011 09:30:04 -0500

The specific concern would be that someone could make use of the lightweight
SMTP cert issue process to acquire a certificate for another service.

Another concern would be that in a heavily outsourced deployment, I may
trust a company to run my inbound mail server but not want them to have the
ability to advertise other services (like accepting payments).

The simplest, most direct way to enforce this type of restriction is to put
a note in the certificate governing acceptable use.

On Mon, Jan 17, 2011 at 9:17 AM, Paul Wouters <[email-masked]> wrote:

>> domain associated with its host name. If so it generates a public
>> key pair, rolls itself a certificate and either tells the admin the DNS RR
>> to insert in the zone or uses a TSIG type mechanism to register the
>> key itself.
>>
>> mail server don't want to have any idea what the rest of the

---

From: Paul Wouters <[email-masked]>
Date: Mon, 17 Jan 2011 09:32:48 -0500 (EST)

On Mon, 17 Jan 2011, Phillip Hallam-Baker wrote:

> If this group proposes a spec that damages the security of other infrastructure it is going to be resisted.

Though written as a definite statement, I don't think there is agreement that DANE in its current
form would "damage" existing infrastructure. This seems self-evident as anyone can decide as a
site policy not to deploy DANE and use any existing security infrastructure (such as trusted CAs)

> DNS name allocation has always been left to site policy.

DANE would not change that.

> The target of an MX record is required to be a canonical name. Thus it should be the
> unique name of the host.

I know many mail servers that listen to mail.exmaple.com though it is not their unique
name, especially when running mail for more then one domain. In fact, the hostname of the
machine is pretty irrelevant to its name in DNS.

> If you want to propose unnecessary changes to DNS operations to make your specification proposal work then you are going to find getting IETF

I find these general top quoted statements without any context quite frustrating to process.

Paul

> What you are talking about is about having different certs for different services and we are back at issue #1 in the tracker.
> 
> If I take your example then most common case is that SMTP server is named mail.<something>, f.e. mail.example.net.  And I guess in most
> cases it will not clash with another services under this name.  And it should be handled by the admins in the few corner cases where the
> name of the mail server is same as name of some other important service.
> 
> Ondrej
> --
>  Ondřej Surý

---

From: Paul Wouters <[email-masked]>
Date: Mon, 17 Jan 2011 09:34:55 -0500 (EST)

On Mon, 17 Jan 2011, Phillip Hallam-Baker wrote:

> The specific concern would be that someone could make use of the lightweight SMTP cert issue process to acquire a certificate for another
> service.
> 
> Another concern would be that in a heavily outsourced deployment, I may trust a company to run my inbound mail server but not want them to have
> the ability to advertise other services (like accepting payments).
> 
> The simplest, most direct way to enforce this type of restriction is to put a note in the certificate governing acceptable use.

So issue such a certificate, and use PCIX and trusted CA's like the currently deployed
sites do? Don't use DANE. What would DANE buy you in this case?

Paul

---

From: Ondřej Surý <[email-masked]>
Date: Mon, 17 Jan 2011 15:34:55 +0100

> infrastructure it is going to be resisted.

You have created the hypothetical scenario in which the harm is created. 
  I find such scenario unlikely for security wise administrators (the 
admin blindly pasting output of some random sendmail script into the DNS).

> DNS name allocation has always been left to site policy. The target of
> an MX record is required to be a canonical name. Thus it should be the
> unique name of the host.

And the usage of the (one or more different) certificates was also a 
site policy, yet you are proposing that we should include it now into 
the protocol.

> If you want to propose unnecessary changes to DNS operations to make
> your specification proposal work then you are going to find getting IETF

I am proposing no such thing.  I am proposing we should leave the 
decisions up to the site admins, who knows the best how to deal with 
certificates, host names etc. according to their local (site) policy.

If we want to be extra sure that we document security properly we could 
create a BCP (or series of BCP) document(s) on how to handle specific 
protocols.  Right now I see no real need to include usage specifier into 
DANE protocol.  That might change on the basis of issue #1 result, but 
right now I doubt it.

Ondrej

> On Mon, Jan 17, 2011 at 8:48 AM, Ondřej Surý <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>         On Sun, Jan 16, 2011 at 9:54 PM, Paul Wouters
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>             I'm not sure how this problem would work. Can you explain it
>         in a
>             little more detail?
>
>             Paul
>
>
>     What you are talking about is about having different certs for
>     different services and we are back at issue #1 in the tracker.
>
>     named mail.<something>, f.e. mail.example.net
>     <http://mail.example.net>.  And I guess in most cases it will not
>     clash with another services under this name.  And it should be
>     handled by the admins in the few corner cases where the name of the
>     mail server is same as name of some other important service.
>
>     Ondrej
>     --
>       Ondřej Surý
>       mailto:[email-masked] <mailto:[email-masked]> http://nic.cz/
>     [email-masked] <mailto:[email-masked]>

---

From: Ondřej Surý <[email-masked]>
Date: Mon, 17 Jan 2011 15:50:34 +0100

On 17.1.2011 15:30, Phillip Hallam-Baker wrote:
> The specific concern would be that someone could make use of the
> lightweight SMTP cert issue process to acquire a certificate for another
> service.
 >
> trust a company to run my inbound mail server but not want them to have
> The simplest, most direct way to enforce this type of restriction is to
> put a note in the certificate governing acceptable use.

No, the simplest, most direct way (apart from not using DANE at all) is 
to have different host names for inbound mail server and other services.

You have painted the very rare scenario in which the canonical name (ie. 
the target of MX record) is same as some other service, and you document 
the degradation of security on such unlikely scenario.

<chair hat>
I propose that either you present an evidence that it will have any real 
impact or we just drop this issue since it's impact is negligible. 
Thank you.
</chair hat>

BTW: I just hand checked top20 domain names from alexa list and all of 
them has something like [.*][mx|mail|smtp].<domainname1> for 
<domainname2> where usually domainname1 = domainname2.

O.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 17 Jan 2011 09:51:50 -0500

2011/1/17 Ondřej Surý <[email-masked]>

> You have created the hypothetical scenario in which the harm is created.  I
> find such scenario unlikely for security wise administrators (the admin
> blindly pasting output of some random sendmail script into the DNS).

Relying on the competence of administrators to fix protocol security
shortcomings is not acceptable.

All I am arguing for here is that this group does not presume to turn off
security controls that already exist in PKIX because it does not understand
what they are for.

Postulating a competent administrator is another way of saying 'lets rely on
magic here'.

Anyone can design a system that is secure when someone who is competent (and
honest) uses it. But in the real world only some people are competent some
of the time.

Deployment of DNSSEC is already going to be a bear of a job. And you are
arguing that its ok to turn off controls to make it harder.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 17 Jan 2011 09:55:25 -0500

OK, we will return to this in last call then

And in IETF last call

And when the PKIX people object to your whole spec on the grounds that you
are changing theirs we can start DANE from scratch

Blocking discussion of critical security issues in the WG is not going to
get you to RFC any faster.

You cannot claim to have a WG consensus if your response to every issue you
don't like is to put your chair hart on and attempt to block discussion.

On Mon, Jan 17, 2011 at 9:50 AM, Ondřej Surý <[email-masked]> wrote:

> No, the simplest, most direct way (apart from not using DANE at all) is to
> have different host names for inbound mail server and other services.
>
> the target of MX record) is same as some other service, and you document the
> degradation of security on such unlikely scenario.
>
> <chair hat>
> impact or we just drop this issue since it's impact is negligible. Thank
> you.
> </chair hat>
>
> BTW: I just hand checked top20 domain names from alexa list and all of them
> has something like [.*][mx|mail|smtp].<domainname1> for <domainname2> where
> usually domainname1 = domainname2.
>
> O.
>
> --
>  Ondřej Surý

---

From: Ondřej Surý <[email-masked]>
Date: Mon, 17 Jan 2011 16:09:23 +0100

I have politely asked you to provide evidence that it's going to be 
issue, so we can continue the discussion.  Yet you came back with 
threats about WGLC and IETFLC and a straw man argument that I block the 
discussion.

Hence I believe no further discussion is possible.  If you have 
arguments which I have asked for then I would be more than happy to 
continue this discussion in productive and constructive manner.

Ondrej

On 17.1.2011 15:55, Phillip Hallam-Baker wrote:
> And when the PKIX people object to your whole spec on the grounds that
> you are changing theirs we can start DANE from scratch
>
>
> Blocking discussion of critical security issues in the WG is not going
> to get you to RFC any faster.
>
> You cannot claim to have a WG consensus if your response to every issue
> you don't like is to put your chair hart on and attempt to block discussion.
>
>
> On Mon, Jan 17, 2011 at 9:50 AM, Ondřej Surý <[email-masked]
>     No, the simplest, most direct way (apart from not using DANE at all)
>     is to have different host names for inbound mail server and other
>     services.
>
>     You have painted the very rare scenario in which the canonical name
>     (ie. the target of MX record) is same as some other service, and you
>     document the degradation of security on such unlikely scenario.
>
>     <chair hat>
>     I propose that either you present an evidence that it will have any
>     real impact or we just drop this issue since it's impact is
>     negligible. Thank you.
>     </chair hat>
>
>     BTW: I just hand checked top20 domain names from alexa list and all
>     of them has something like [.*][mx|mail|smtp].<domainname1> for

---

From: Paul Wouters <[email-masked]>
Date: Mon, 17 Jan 2011 10:11:35 -0500 (EST)

DANE is an alternative for PKIX.

The important issue here is can someone use both or not, and can someone
migrate from one to the other. DANE should not be limited by PKIX, just
like PKIX should not be limited by DANE. But we have had this discussion
a few times already.

My concern is for example with the regularly seen expired certificates. I
forsee people, especially those using self signed certificates, to
generate TLSA records and forget about their certificate's expiry date.

I think there is real value in ignoring all certificate properties. But we
could decide on making such a TLSA record have its own "certificate type".

eg, we could add type 5/6 to section 2 of the DANE draft:

 	5 Hash of a public key taken from an end-entity certificate. All PKIX
 	  elements are specifically ignored.

 	6 Full public key taken from an end-entity certificate. All PKIX
 	  elements are specifically ignored.

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 17 Jan 2011 11:18:57 -0500

This is an existing security control established in PKIX

I believe the burden of proof is on those proposing to make a change that
they are not going to cause damage.

Now if you look at this thread, I have given numerous use cases that
demonstrate a need for what I am arguing for. I have not seen any use case
given in favor of ignoring the information.

I have provided evidence, it is your side that has refused. I don't think I
have seen a single use case from you ever.

> I have politely asked you to provide evidence that it's going to be issue,
> so we can continue the discussion.  Yet you came back with threats about
> WGLC and IETFLC and a straw man argument that I block the discussion.
>
> Hence I believe no further discussion is possible.  If you have arguments
> which I have asked for then I would be more than happy to continue this
> discussion in productive and constructive manner.
>
> Ondrej
>
>

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 17 Jan 2011 08:10:18 -0800

> elements are specifically ignored.

I agree that we should nail down in the spec whether PKIX information 
other than the key itself should be paid attention to in end-entity 
certificates gotten through TLSA. I disagree that we want to have two 
semantics based on different values in the TLSA record. Doing so says 
that the server gets to tell the client what security policy the client 
should use.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Mon, 17 Jan 2011 11:33:32 -0500 (EST)

On Mon, 17 Jan 2011, Paul Hoffman wrote:

> I agree that we should nail down in the spec whether PKIX information other 
> than the key itself should be paid attention to in end-entity certificates 
> gotten through TLSA. I disagree that we want to have two semantics based on 
> different values in the TLSA record. Doing so says that the server gets to 
> tell the client what security policy the client should use.

So change it from "ignored" to "MAY ignore" ?

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 17 Jan 2011 09:11:28 -0800

> This is an existing security control established in PKIX

Correct. And we are discussing expressly ignoring it when used in 
end-entity certificates when used for associating a key with a domain name.

> I believe the burden of proof is on those proposing to make a change
> that they are not going to cause damage.

You are saying we have to prove something unprovable? That seems like a 
mighty high bar, one that doesn't apply to any other work in the IETF.

> demonstrate a need for what I am arguing for. I have not seen any use
> case given in favor of ignoring the information.

I have reviewed your messages on this (poorly-named) thread, and I do 
not see a use case that demonstrates a need. I assume that means I am 
not understanding you. Can you copy one from earlier in this thread 
here? (FWIW, I see statements that do not relate to end-entity 
certificates, but those are not what we are discussing here.)

> I have provided evidence, it is your side that has refused.

Please ratchet down the invective. There are no "sides" here. Further, 
some of us who disagree with you so far were waiting for you to be 
clearer: that is quite different that "refusing".

> I don't
> think I have seen a single use case from you ever.

The use cases for TLSA are listed in the draft.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 17 Jan 2011 09:13:27 -0800

On 1/17/11 8:33 AM, Paul Wouters wrote:
>> that the server gets to tell the client what security policy the
>> client should use.
>

Clients "MAY ignore" anything already. It sounds like you are trying to 
add bits that say "and I want you to enforce this even though I have no 
idea what your local policy is". That doesn't sound like it adds much 
value to me.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 17 Jan 2011 13:34:44 -0500 (EST)

On Mon, 17 Jan 2011, Paul Hoffman wrote:

> Clients "MAY ignore" anything already. It sounds like you are trying to add 
> bits that say "and I want you to enforce this even though I have no idea what 
> your local policy is". That doesn't sound like it adds much value to me.

I'm trying to addres Phillip's concern about implicitely changing PKIX validation
by making it more explicit, and giving the administrator the local policy choice
to put down a preference of either DANE or PKIX as their trust anchor.

While most believe the existence of DANE itself signifies the preference, Phillip
does not agree. A specific sub-type in section 2 for TLSA would address this.

PKIX is all about the server teling the client policy, even if the precise policy
bits are contained in a PKIX certificate and not in an RRTYPE. I don't see why
DANE could not do the same (as long as the protocol allows specifying both policies)

In the current spec, there is the contradiction of "expired cert" vs "valid RRSIG".
It would be nice if a preference could be specified and that this use case would
not end up being varying per implementation. (even though I think that implementations
should ignore everything but the public key from a cert when using DANE)

Paul

---

From: Matt McCutchen <[email-masked]>
Date: Mon, 17 Jan 2011 13:51:59 -0500

> impact or we just drop this issue since it's impact is negligible. 

Here's an example: my university's student mail system provides POP3S,
IMAPS, SMTP with STARTTLS for message submission, and a HTTPS webmail
interface all on the same server name (mail.umd.edu).

This kind of configuration is convenient for users: they only have to
remember the one host name, not the prefixes used for the different
services (which are not standardized anywhere and will be different for
different service providers).  PKIX supports it via SRVNames (RFC 4985).
DANE should support it too.

-- 
Matt

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 17 Jan 2011 14:04:18 -0500

On Mon, Jan 17, 2011 at 12:13 PM, Paul Hoffman <[email-masked]>wrote:

> bits that say "and I want you to enforce this even though I have no idea
> what your local policy is". That doesn't sound like it adds much value to
> me.

No, you are quite incorrect.

Clients 'may' do anything they like.

But that does not mean that they 'MAY' do anything in the sense of normative
compliance. In the case of X.509 and PKIX there are very specific MUST
requirements that have to be observed for interoperability.

One of them is that RPs MUST NOT accept a certificate with a critical
extension that they do not understand. that is an interoperability criteria.

In practice it is a restriction that would take a great deal of effort to
avoid enforcing since existing code has those restrictions built in at a
very low level.

If we were to attempt to adopt the approach suggested and simply ignore
critical extensions and expiry dates, the likely outcome is going to be that
some people are going to code to the DANE spec and others are going to code
to the PKIX spec. And as a PKIX person I am not going to tell the person who
is reading that document that they are wrong to ignore the DANE
requirements.

So to accept the proposal to ignore critical extensions, revocation, expiry
is to create a huge amount of scope for interoperability failures.

If people don't want critical extensions then they shouldn't put them in
their self-signed certs. The only way that a critical extension is going to
get in a cert is if someone decides to put it there.

If people don't want to worry about expiry dates then set them to the issue
date plus 100 years.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 17 Jan 2011 11:04:57 -0800

On 1/17/11 10:34 AM, Paul Wouters wrote:
>> Clients "MAY ignore" anything already. It sounds like you are trying
>> to add bits that say "and I want you to enforce this even though I
>> have no idea what your local policy is". That doesn't sound like it
>> adds much value to me.
>

In this discussion, people (not just Phill) have brought out many 
different parts of a PKIX cert that might or might not be taken into 
account by the TLS client receiving the cert through TLSA. I don't think 
there is much agreement yet on which parts are important, and thus 
should be an open issue for us to deal with so we can see where 
consensus lies.

---

From: Martin Rex <[email-masked]>
Date: Mon, 17 Jan 2011 20:08:28 +0100 (MET)

> are changing theirs we can start DANE from scratch

I'm not sure I fully understand what you're talking about, but I believe
it is a non-issue.

The existing TLS X.509 PKI has a huge gaping security problem, and
DANE is supposed to provide a band-aid for this.

But why should DANE be _limited_ to mitigating serious PKIX problems?

Does PKIX have a monopoly of foobaring the worlds security needs?
I also don't see any requirements in and around TLS that it ought to
be limited to (vanilla) PKIX.  There may be a strong economic interest
from commercial CAs and parties of the CA/Browser forum that no
alternatives to commercial CAs become commonly used with HTTPS,
but that is definitely not a resonable engineering decision for
the IETF to prevent this from happening.

The issue seems to be much less about processing X.509 certs and
attributes, rather than deciding when to consider which specific
certs or keys as trusted.

So far, they solution to bootstrapping trust in PKIX is also
primarily done as "deus ex machina" (aka leap-of-faith).
like an initial install of http://www.mozilla.com/en-US/firefox/

Last time I checked, DANE builds on DNSSEC, and DNSSEC itself
is also not wedlocked to PKIX.

-Martin

---

From: Ondřej Surý <[email-masked]>
Date: Mon, 17 Jan 2011 20:16:42 +0100

> interface all on the same server name (mail.umd.edu).

Thank you for the real world example.

> different service providers).

BTW do you realize that all the services you have named use the same 
certificate?  So the level of trust is probably same for all those services.

> PKIX supports it via SRVNames (RFC 4985). DANE should support it too.

I don't see a problem here for non-self-signed certs (3.1.4 says that 
additional certificate data should be processed as normal).

The only issue is with self-signed certs type 1/2 (type 3/4 is CA 
self-signed cert).  So basically you are saying (if I may generalize) 
that we should not ignore certificate data in self-signed certs and thus 
support SRVNames in self-signed certs.

Correct?

O.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 17 Jan 2011 14:33:20 -0500 (EST)

On Mon, 17 Jan 2011, Phillip Hallam-Baker wrote:

> So to accept the proposal to ignore critical extensions, revocation, expiry is to create a huge amount of scope for interoperability failures.

I am okay with leaving that for a new sub type for bare public key TLS.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Mon, 17 Jan 2011 14:37:13 -0500 (EST)

On Mon, 17 Jan 2011, Ondřej Surý wrote:

> The only issue is with self-signed certs type 1/2 (type 3/4 is CA self-signed 
> cert).  So basically you are saying (if I may generalize) that we should not 
> ignore certificate data in self-signed certs and thus support SRVNames in 
> self-signed certs.

Note that we should support a dual migration, where someone will move from PKIX
to DANE, but also has to deal with users going from software that does not support
DANE to software that supports DANE. This will be the main reason why "DANE certs"
are seeing X.509 extended properties to begin with.

Paul

---

From: Ondřej Surý <[email-masked]>
Date: Mon, 17 Jan 2011 20:40:40 +0100

> certificate? So the level of trust is probably same for all those services.

Just to make sure...  I was not arguing here with you, just pointing out 
that it's quite different to have all "mail" services under one name 
(and probably same policy) and to have "low-level" SMTP cert and some 
other high security protocol at other name (like running incoming SMTP 
server under www.paypal.com name)

> support SRVNames in self-signed certs.

Further thinking about this.  It seems to me that we have two issues here:

Issue#1 - Multiple services at one name

Issue#tbd - Ignoring (or not) certificate data in self-signed certs

The solution for Issue#1 might be usage of SRVNames.

The solution to Issue#tbd might be in tool which would easily generate 
different self-signed certs from one private key (or ability to do that 
on-fly), hence defeating the need to ignore cert properties.

O.

---

From: Matt McCutchen <[email-masked]>
Date: Mon, 17 Jan 2011 15:10:21 -0500

> server under www.paypal.com name)

Understood.  I don't have an example of the latter.  However, even when
the services are at the same trust level, diversion of a connection
bound for one service to another legitimate service is something that
TLS can, and IMHO should, prevent.  Using different certificates bound
to the individual services is one way to do this.  (The other would be
to put a SRVName in the server_name extension and have the server check
it.)

> Issue#tbd - Ignoring (or not) certificate data in self-signed certs

Right.

> The solution for Issue#1 might be usage of SRVNames.

That is one possible solution.  I prefer the solutions listed in the
ticket (https://trac.tools.ietf.org/wg/dane/trac/ticket/1), which will
also work with bare public keys.

> on-fly), hence defeating the need to ignore cert properties.

Sure.  Generating a cert with appropriate property values
(subjectAltName, validity period, ...) is doable.  The question is
whether the practical value of honoring a particular PKIX property
(either because it is a useful security measure or to meet admin
expectations) justifies the admin effort to set it properly.  I don't
think this case has been made convincingly one way or the other.

-- 
Matt

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 17 Jan 2011 15:23:19 -0500

> Issue#tbd - Ignoring (or not) certificate data in self-signed certs

Agreed

> The solution for Issue#1 might be usage of SRVNames.

I think so. SRV Names are the DNS way to address protocols, they are a very
powerful and useful tool.

They also allow us to focus on a much narrower set of concerns at a given
instance. If we are talking about a record with an _https._tcp prefix then I
am very happy to only be talking about TLS and only talking about HTTP.

> on-fly), hence defeating the need to ignore cert properties.

Someone suggested being able to (optionally) put a critical extension in the
cert with an SRV property.

I rather like that proposal as it really ties everything very neatly to the
DNS set of identifiers and a DNS way of looking at the world.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 17 Jan 2011 18:03:28 -0500

>...

Your statement that "PKIX is all about the server teling the client 
policy ..." is not really true.

X.509 and PKIX standards assume that each client (relying party) 
locally selects the set of trust anchors that it employs. Thus a 
server, when it supplies an EE cert in a TLS exchange, is offering a 
cert for validation by the client, under the policies adopted by that 
client (e.g., as reflected in the trust anchors configured in that 
client). The server may have some policy inputs to the PKIX 
validation  process, based on the value of certain extensions in its 
cert, but those extension values have to be approved by the CA that 
issued the server's EE cert. Thus the server may not have had free 
rein re those extension values.

Steve

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 18 Jan 2011 08:46:48 +0100

On 17.1.2011 21:23, Phillip Hallam-Baker wrote:
>
>
> On Mon, Jan 17, 2011 at 2:40 PM, Ondřej Surý <[email-masked]
> I think so. SRV Names are the DNS way to address protocols, they are a
> very powerful and useful tool.
>
> They also allow us to focus on a much narrower set of concerns at a
> given instance. If we are talking about a record with an _https._tcp
> prefix then I am very happy to only be talking about TLS and only
> talking about HTTP.

Since you have stripped rest of the mail it's unclear now.  I was 
talking about SRVNames in the Certificate as specified in RFC 4985 and 
pointed out by Matt McCutchen (thanks Matt), and not about SRV DNS RRs. 
  While we may use SRV RR types as well to solve Issue#1, I wasn't 
talking about them.  I feel it's important to make that distinction, so 
we talk about the same thing.

Ondrej

---

From: Jakob Schlyter <[email-masked]>
Date: Tue, 18 Jan 2011 10:42:29 +0100

On 18 jan 2011, at 08.46, Ondřej Surý wrote:

> Since you have stripped rest of the mail it's unclear now.  I was talking about SRVNames in the Certificate as specified in RFC 4985 and pointed out by Matt McCutchen (thanks Matt), and not about SRV DNS RRs.  While we may use SRV RR types as well to solve Issue#1, I wasn't talking about them.  I feel it's important to make that distinction, so we talk about the same thing.

Correct, we have two different mechanisms:

- indicating service in the certificate itself (using SRVNames)
- indicating service using the DNS hostname, e.g. _http._tcp.example.com. IN TLSA ...

It would be possible to use them separately or together. If I have a web server and a mail server - with different certificates - at the host mail.example.com, I could

a) publish two TLSA RR at mail.example.com, each cert using SRVNames to specify what service is used with what certificate
b) publish one TLSA RR at _smtp._tcp.example.com and one at _http._tcp.example.com.
c) both (a) and (b)

Phil; does this separation make sense?

	jakob

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Tue, 18 Jan 2011 11:45:52 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Paul Wouters
 
> While most believe the existence of DANE itself signifies the preference,
> Phillip does not agree. A specific sub-type in section 2 for TLSA would address
> this.

Not sure where to add this point but I also believe this should not be an all/nothing choice.  I expect we would not deploy in isolation, completely ditch our existing EV support, etc.  I intend to use something like DANE to get exclusivity, not (initially?) separation from the existing CA world.

- Andy

---

From: Steve Schultze <[email-masked]>
Date: Tue, 18 Jan 2011 20:01:17 -0500

On Jan 16, 2011, at 11:00 AM, Paul Hoffman wrote:
> Ah, I didn't realize this was a bikeshed discussion. :-) I would prefer to keep the name as tied to what we know it will be used for and let other people do deltas if they want.

Er, the name can be "tied to what we know it will be used for" and still be general enough that if other uses come along our work can be reused.  If we are too specific, any subsequent use for something outside of TLS would require creating a new RRTYPE and getting that deployed.  I don't see any reason why we'd want to make that necessary.  I'm with Yaron.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 18 Jan 2011 21:16:39 -0500

On Sun, Jan 16, 2011 at 11:00 AM, Paul Hoffman <[email-masked]>wrote:

> Ah, I didn't realize this was a bikeshed discussion. :-) I would prefer to
> keep the name as tied to what we know it will be used for and let other
> people do deltas if they want.

Not a bikeshed discussion at all.

How strong is this 'preference' of yours. Do you think it is worth actually
arguing over or do you just think that you should have your way because you
don't think it important even though others do?