Subject: Re: [keyassure] The draft and subj alt names
From: =JeffH <[email-masked]>
To: IETF DANE WG list <[email-masked]>
Date: Mon, 04 Apr 2011 07:50:59 -0700
List-Id: Key Assurance With DNSSEC <keyassure.ietf.org>

On Mar 31, 2011, at 12:05 PM, Olle E. Johansson wrote:

 > I have read the draft and reacted to one thing. Sorry if this already have 
been discussed on the list.
 >
 > The draft -06 says
 > "The end entity certificate from TLS, regardless of whether it was
 >   matched with a TLSA type 1 certificate or chained to a TLSA type 2 CA
 >   certificate, must have at least one identifier in the subject or
 >   subjectAltName field of the matched certificates matches the expected
 >   identifier for the TLS server. "
 >
 > The new RFC 6125 tells us that we should:
 > "Move toward including and checking even more specific
 >      subjectAlternativeName extensions where appropriate for using the
 >      protocol (e.g., uniformResourceIdentifier and the otherName form
 >      SRVName)."
 >

"Richard L. Barnes" <[email-masked]> replied on Thu, 31 Mar 2011 13:12:32 +0200..
 >
 > As I've said in other threads, this WG should be silent on requirements for
 > certificate names, since different applications use TLS certificate names in
 > different ways.

+1 to what Richard says.

The RFC6125 (aka "TLS Server Identity Check") text quoted by Olle is a 
suggestion to _applications_ to move away from CN-ID and towards leveraging 
SubjectAlternativeName (SAN) name types in terms of the identifiers embedded in 
certs and checked against _at the app layer_ during TLS connection establishment.

I think that Richard is correct that what the DANE WG is designing lies "below" 
the applications, and it is still their job to ascertain whether the name(s) 
embedded in the cert used to secure the connection meaningfully match the 
intended server. Please see sections 1 and 2 of RFC6125 for an in-depth 
discussion of the nuances.

HTH,

=JeffH

From: Jeff Schmidt <[email-masked]>
To: Paul Wouters <[email-masked]>, Jay Daley <[email-masked]>
Date: Fri, 1 Apr 2011 21:35:46 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] The draft and subj alt names

On 4/1/11 2:22 AM, "Paul Wouters" <[email-masked]> wrote:
>The cert is just a legacy container for the public key. We should not be
>adding policy
>in DANE that entangles DANE with PKIX (or any other trust scheme)

+1.  Or have an easy way to unwind any such entanglements (i.e. make them
optional).

Jeff

Date: Fri, 01 Apr 2011 16:38:27 +0200
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] The draft and subj alt names

On 1.4.2011 15:56, Martin Rex wrote:
> Jay Daley wrote:
>>
>> 6.  Add a flag into TLSA that specifies
>>      whether name matching is to be done or not
>
> I think that (6.) would be the most sensible solution.

This starts to look like overengineering.  Let's not put too many 
ingreedients into one pot please.

> Especially for self-signed X.509 certificates, it doesn't make sense
> to look at name attributes of the certificate at all, because these
> are all self-asserted attributes, not certified attributes.  The
> only thing that really matters is the public key.

On the other hand it's not that hard to issue a self-signed CA issued 
cert which matches the domain name, isn't it?

The other option would be use the bare keys (see Paul W. proposal in TLS 
WG).  E.g. if you use X.509 do match, if you use bare key, don't match.

> TLSv1.2  1. Introduction, last sentence
>
>    http://tools.ietf.org/html/rfc5246#page-5
>
>                                    the decisions on how to initiate TLS
>     handshaking and how to interpret the authentication certificates
>     exchanged are left to the judgment of the designers and implementors
>     of protocols that run on top of TLS.
>
> HTTP over TLS, 3.1 Server Endpoint Indentification, 2nd paragraph
>
>    http://tools.ietf.org/html/rfc2818#section-3.1
>
>     If the client has external information as to the expected identity of
>     the server, the hostname check MAY be omitted. (For instance, a
>     client may be connecting to a machine whose address and hostname are
>     dynamic but the client knows the certificate that the server will
>     present.)
>
>
> or the new RFC-6125
>
>    http://tools.ietf.org/html/rfc6125#page-8
>
>     o  Keys or certificates employed outside the context of PKIX-based
>        systems.
>
>        Some deployed application technologies use a web of trust model
>        based on or similar to OpenPGP [OPENPGP], or use self-signed
>        certificates, or are deployed on networks that are not directly
>        connected to the public Internet and therefore cannot depend on
>        Certificate Revocation Lists (CRLs) or the Online Certificate
>        Status Protocol [OCSP] to check CA-issued certificates.  However,
>        the method for binding a public key to an identifier in OpenPGP
>        differs essentially from the method in X.509, the data in self-
>        signed certificates has not been certified by a third party in any
>        way, [...]

I think that those paragraphs are exactly the reason why the option 
"Leave it alone - it's up to the application" is most appropriate for 
the DANE WG.  And there will be interest I think that it could be solved 
elsewhere or here as BCP RFC.

O.
-- 
  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: Martin Rex <[email-masked]>
To: [email-masked] (Jay Daley)
Date: Fri, 1 Apr 2011 15:56:27 +0200 (MEST)
Cc: [email-masked]
Subject: Re: [keyassure] The draft and subj alt names
Reply-To: [email-masked]

Jay Daley wrote:
> 
> 6.  Add a flag into TLSA that specifies
>     whether name matching is to be done or not

I think that (6.) would be the most sensible solution.

Especially for self-signed X.509 certificates, it doesn't make sense
to look at name attributes of the certificate at all, because these
are all self-asserted attributes, not certified attributes.  The
only thing that really matters is the public key.

Today's browsers show a very intimidating warning page when they
receive a server cert that doesn't match their expectations.
But once you have convinced your browser that you want to connect,
and to make this decision persistent (cert pinning), then there
are no more warnings on further connects about mismatches on
name attributes of the certificate.

TLSv1.2  1. Introduction, last sentence

  http://tools.ietf.org/html/rfc5246#page-5

                                  the decisions on how to initiate TLS
   handshaking and how to interpret the authentication certificates
   exchanged are left to the judgment of the designers and implementors
   of protocols that run on top of TLS.

HTTP over TLS, 3.1 Server Endpoint Indentification, 2nd paragraph

  http://tools.ietf.org/html/rfc2818#section-3.1

   If the client has external information as to the expected identity of
   the server, the hostname check MAY be omitted. (For instance, a
   client may be connecting to a machine whose address and hostname are
   dynamic but the client knows the certificate that the server will
   present.)

or the new RFC-6125

  http://tools.ietf.org/html/rfc6125#page-8

   o  Keys or certificates employed outside the context of PKIX-based
      systems.

      Some deployed application technologies use a web of trust model
      based on or similar to OpenPGP [OPENPGP], or use self-signed
      certificates, or are deployed on networks that are not directly
      connected to the public Internet and therefore cannot depend on
      Certificate Revocation Lists (CRLs) or the Online Certificate
      Status Protocol [OCSP] to check CA-issued certificates.  However,
      the method for binding a public key to an identifier in OpenPGP
      differs essentially from the method in X.509, the data in self-
      signed certificates has not been certified by a third party in any
      way, [...]

-Martin

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 1 Apr 2011 15:10:56 +0200
To: Jay Daley <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] The draft and subj alt names

Let me phrase it differently.  If you give DANE specific name matching =
requirements, then you not only have to update the appropriate =
application RFCs, you have to change all the corresponding code.  If you =
look at HTTPS libraries, for example:=20
-- Most of them will only check the cert against the domain name in the =
HTTPS URI (with no user-configurability)
-- Some can be configured to accept a list of names
-- None that I'm aware of have a "don't check the name" option. =20
(Some of them don't ever check names, but they're non-compliant anyway.)

This is not to mention that if you put a cert with the wrong domain name =
in TLS, you're going to break non-DANE clients. =20

I don't think that all this trouble is worth the small optimization, and =
(not to be a process weenie) I don't think that working at the =
application layer is within the scope of this working group.

--Richard

On Apr 1, 2011, at 5:15 AM, Jay Daley wrote:

> On 1/04/2011, at 3:06 PM, Richard L. Barnes wrote:
>=20
>> The only choice that avoids updating several RFCs is 5.
>=20
> Is that your only reason for not wanting to tackle this?  Do you have =
any view on the nature of trust that DNSSEC provides to applications or =
not?
>=20
>> Just leave it alone!
>=20
> No.
>=20
> warmest regards
> Jay
>=20
>> --Richard
>>=20
>>=20
>> On Mar 31, 2011, at 10:41 PM, Jay Daley wrote:
>>=20
>>> On 1/04/2011, at 12:12 AM, Richard L. Barnes wrote:
>>>=20
>>>> As I've said in other threads, this WG should be silent on =
requirements for certificate names, since different applications use TLS =
certificate names in different ways.  See for example the difference =
between RFC 2818 and RFC 6125.  The text you reference in the draft is =
technically harmless ("must" not "MUST"), but should probably be deleted =
anyway.
>>>=20
>>> There are two separate issues here:
>>> a) whether we think name matching is still needed with DANE
>>> b) what the draft should say about that
>>>=20
>>> On a) I would make the case that name matching is should not be done =
because
>>> - DNSSEC provides sufficient trust
>>> - name matching forces certain operational decisions onto end user =
(e.g. multiple certs, cert reuse) that are unreasonable
>>>=20
>>> On b) There are six options for the draft:
>>>=20
>>> 1.  State that name matching must be done
>>> 2.  State that name matching must not be done
>>> 3.  Leave it to applications with a recommendation to match
>>> 4.  Leave it to applications with a recommendation not to match
>>> 5.  Leave it to applications with no recommendation
>>> 6.  Add a flag into TLSA that specifies whether name matching is to =
be done or not
>>>=20
>>> My choice, in order of preference would be 2, 6, 4. =20
>>>=20
>>> Jay
>>>=20
>>>>=20
>>>> --Richard
>>>>=20
>>>>=20
>>>>=20
>>>> On Mar 31, 2011, at 12:05 PM, Olle E. Johansson wrote:
>>>>=20
>>>>> I have read the draft and reacted to one thing. Sorry if this =
already have been discussed on the list.
>>>>>=20
>>>>> The draft -06 says
>>>>> "The end entity certificate from TLS, regardless of whether it was
>>>>> matched with a TLSA type 1 certificate or chained to a TLSA type 2 =
CA
>>>>> certificate, must have at least one identifier in the subject or
>>>>> subjectAltName field of the matched certificates matches the =
expected
>>>>> identifier for the TLS server. "
>>>>>=20
>>>>> The new RFC 6125 tells us that we should:
>>>>> "Move toward including and checking even more specific
>>>>>  subjectAlternativeName extensions where appropriate for using the
>>>>>  protocol (e.g., uniformResourceIdentifier and the otherName form
>>>>>  SRVName)."
>>>>>=20
>>>>> I feel we need to be more specific in the draft.  What type of =
subjectAltName should we match with?
>>>>> dnsName?
>>>>>=20
>>>>> And if we're using SIP, and have URI's in the certificate - should =
that be part of this draft
>>>>> or should we open for protocol-specific specifications for other =
types of subject Alt Names?
>>>>>=20
>>>>> /O
>>>>> _______________________________________________
>>>>> keyassure mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/keyassure
>>>>=20
>>>> _______________________________________________
>>>> keyassure mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/keyassure
>>>=20
>>>=20
>>> --=20
>>> Jay Daley
>>> Chief Executive
>>> .nz Registry Services (New Zealand Domain Name Registry Limited)
>>> desk: +64 4 931 6977
>>> mobile: +64 21 678840
>>>=20
>>=20
>=20
>=20
> --=20
> Jay Daley
> Chief Executive
> .nz Registry Services (New Zealand Domain Name Registry Limited)
> desk: +64 4 931 6977
> mobile: +64 21 678840
>=20

From: "Jim Schaad" <[email-masked]>
To: "'Eric Rescorla'" <[email-masked]>, "'Richard L. Barnes'" <[email-masked]>
Date: Fri, 1 Apr 2011 10:15:51 +0200
Cc: [email-masked]
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] =
On
> Behalf Of Eric Rescorla
> Sent: Wednesday, March 30, 2011 2:28 PM
> To: Richard L. Barnes
> Cc: [email-masked]
> Subject: Re: [keyassure] Objective: Restrictive versus Supplementary
Models
>=20
> On Wed, Mar 30, 2011 at 2:18 PM, Richard L. Barnes <[email-masked]>
> wrote:
> > I agree with Ekr and Steve that these are the right goals. =A0I =
don't have
any
> further goals to add. =A0Just trying to re-state in bullet-point form:
> >
> > 1. Cert-lock / CA-lock
> > 1.1. Use case:
> > 1.1.1. Client initiates TLS connection and gets server cert chain
> > 1.1.2. Client performs normal TLS/PKIX validation on cert chain =
1.1.3.
> > Client retrieves DANE records from DNS 1.1.4. DANE records specify =
EE
> > or CA certs that MUST be present in cert chain 1.1.5. Client =
verifies
> > that TLS cert chain meets DANE constraints 1.2. Security goal: =
Defend
> > against issuance of other certs for this domain 1.3. DNSSEC
> > RECOMMENDED, not REQUIRED; attacker can only cause connection =
failure
> >
> > 2. Domain-managed authentication
> > 2.1. Use case:
> > 2.1.1. Client retrieves DANE records from DNS 2.1.2. DANE records
> > specify Trust Anchors for PKIX certificate validation 2.1.3. Client
> > adds DANE CA certs to TA store (optionally, drops all others) 2.1.3.
> > Client initiates TLS connection and gets server cert chain 2.1.4.
> > Client performs normal TLS/PKIX validation on cert chain

I have some concerns about making these a TA in all cases.  Specifically =
if
this is an intermediate CA in a chain that goes to a TA that I have
configured in my system.  Turning this CA into a TA means that any
configuration information that I have on my TA plus any extensions that =
are
in CA certificates between the TA and CA in the DANE statement are all
suddenly ignored.  I think this is bad behavior.

Jim

>=20
> I don't think this last point has consensus. Certainly, in the case =
where
the
> certificate in question is the terminal certificate, I think at least =
some
people
> don't care if it's invalid from a PKIX perspective.
>=20
> -Ekr
>=20
> > 2.2. Security goal: Allow TLS to work without pre-configured TAs =
2.3.
> > DNSSEC REQUIRED; attacker can insert bogus TAs
> >
> >
> >
> >
> >
> > On Mar 30, 2011, at 10:48 AM, Eric Rescorla wrote:
> >
> >> To follow up on my comments at the microphone, there are two
> >> potential objectives for technology of this type:
> >>
> >> 1. Protecting against CA mis-issue (as in CA/cert lock).
> >> 2. Allowing TLS to work without getting a certificate from one of =
the
> >> established trust anchors.
> >>
> >> In the first case, the idea would be that the relying party would =
go
> >> through its ordinary validation logic and if that failed, would
> >> reject the certificate. However, if the validation succeeded, it
> >> would check DNS and if that check failed, would then reject the
> >> certificate. Only if both checks succeeded would the certificate be
> >> accepted. [0] The objective of this type of mechanism would be =
simply
> >> to defend against unauthorized certificate issuance.
> >> Note that in this case, the DANE data need not be DNSSEC secured,
> >> because an attacker who tampers with it will solely be able to =
cause
> >> a connection failure, and in many cases (TLS, SSH, etc.) an =
attacker
> >> with those capabilities can tamper with the A record and block the
> >> connection that way.
> >>
> >> In the second case, the intention is to allow clients to =
effectively
> >> bypass the existing trust hierarchy by injecting a new trust point
> >> via the DNS. Thus, either the certificate validation simply will =
not
> >> be used at all (in the case where a terminal certificate is =
provided)
> >> or will be used up to a newly inserted trust anchor. In either =
case,
> >> the presumptive rationale here is that it's too inconvenient to =
deal
> >> with the existing CAs and that DANE will be easier.
> >> This version of DANE *does* need to be protected via DNSSEC because
> >> tampering with these records allows the attacker to impersonate the
> >> authenticating party to the relying party.
> >>
> >>
> >> The draft to some extent conflates these two objectives, since it
> >> *both* injects a new trust
> >> anchor and restricts the list of potential certificates. It does =
not
> >> allow you to simply restrict the list of CAs/certificates without
> >> also injecting a new trust point.
> >>
> >>
> >> Opinion follows:
> >> For my money the most important driving use case for this work is =
the
> >> first case, for two reasons. First, it's the more pressing problem
> >> since it's not really
> >> *that* hard to get a
> >> certificate from one of the existing CAs, but this also means that =
we
> >> have to worry about mis-issue by misbehaving CAs, as we have =
recently
> >> seen. Second, the incremental deployment story is much easier, =
since
> >> clients which don't speak DANE will just not be protected against
> >> attack, whereas in the second case clients which don't speak DANE
> >> will experience certificate errors when connecting to a DANE-only
> >> site.
> >>
> >> -Ekr
> >>
> >>
> >> [0] The checks can be done in either order. This is only for =
clarity.
> >> _______________________________________________
> >> keyassure mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/keyassure
> >
> >
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Date: Fri, 1 Apr 2011 03:29:10 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Yoav Nir <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models

On Fri, 1 Apr 2011, Yoav Nir wrote:

>>> So I think the requirements document should describe EKR's use cases, and require that the TLSA record be able to differentiate between records that are appropriate for the two use cases.
>>
>> Are you really suggesting some kind of indicator that says "you can ignore the cruft from the cert that is bogus
>> that I vouched for via the RRSIG"?
>
> Stated like this, it conveys policy. I just want it to say that this is the cert I'm going to use, and I can't vouch for anything there besides the public key.

The obvious answer here is to make it explicit that you are only vouching for the public key... by only putting
the public key in the DANE record to sign.

1) You're not signing items you want the client to ignore
2) You're not signing for information that contradicts itself (RRSIG/TTL vs Expiry or RRlabel vs Subject*)

Paul

From: Yoav Nir <[email-masked]>
To: Paul Wouters <[email-masked]>
Date: Fri, 1 Apr 2011 10:22:40 +0300
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models

On Apr 1, 2011, at 10:13 AM, Paul Wouters wrote:

> On Thu, 31 Mar 2011, Yoav Nir wrote:
>=20
>> Cert-lock (and CA-lock) are what EKR calls supplementary, while the othe=
rs are the restrictive. While the sever (and domain owner) can't dictate cl=
ient policy, they should be able to indicate whether the Certificate (TA or=
 EE) that's in the TLSA record is supposed to be validatable or not. The cl=
ient (relying party) may have a policy to ignore records that push a non-va=
lid certificate, but if you're going to publish a record with a certificate=
 that you have just issued using openssl on your laptop and expires in 1975=
, the TLSA record had better reflect that this certificate is just a contai=
ner for a public key, not something you can chain and validate.
>>=20
>> So I think the requirements document should describe EKR's use cases, an=
d require that the TLSA record be able to differentiate between records tha=
t are appropriate for the two use cases.
>=20
> Are you really suggesting some kind of indicator that says "you can ignor=
e the cruft from the cert that is bogus
> that I vouched for via the RRSIG"?

Stated like this, it conveys policy. I just want it to say that this is the=
 cert I'm going to use, and I can't vouch for anything there besides the pu=
blic key.=

Date: Fri, 1 Apr 2011 03:22:39 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Jay Daley <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] The draft and subj alt names

On Fri, 1 Apr 2011, Jay Daley wrote:

>> As I've said in other threads, this WG should be silent on requirements for certificate names, since different applications use TLS certificate names in different ways.  See for example the difference between RFC 2818 and RFC 6125.  The text you reference in the draft is technically harmless ("must" not "MUST"), but should probably be deleted anyway.
>
> There are two separate issues here:
> a) whether we think name matching is still needed with DANE
> b) what the draft should say about that
>
> On a) I would make the case that name matching is should not be done because
> - DNSSEC provides sufficient trust
> - name matching forces certain operational decisions onto end user (e.g. multiple certs, cert reuse) that are unreasonable

Also, image you have to keep updating your cert in DANE every time you add/remove a
vhost and you have to update the subjectAltname. One of the advantages of putting it
in DNS is that you know the name of the entity without having to look inside the cert.

The cert is just a legacy container for the public key. We should not be adding policy
in DANE that entangles DANE with PKIX (or any other trust scheme)

Paul

From: Yoav Nir <[email-masked]>
To: Paul Wouters <[email-masked]>
Date: Fri, 1 Apr 2011 10:20:17 +0300
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models

On Apr 1, 2011, at 10:18 AM, Paul Wouters wrote:

> On Thu, 31 Mar 2011, Martin Rex wrote:
>=20
>> To me, processing unsigned TLSA records is similar to
>> processing unsigned OCSP responses or unsigned CRLs.
>> I would not do the latter, and I'm in doubt that the former
>> is a good idea.
>=20
> Agreed.
>=20
> Paul

+1  (and it's also like an unsigned cert)

Date: Fri, 1 Apr 2011 03:18:07 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Martin Rex <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models

On Thu, 31 Mar 2011, Martin Rex wrote:

> To me, processing unsigned TLSA records is similar to
> processing unsigned OCSP responses or unsigned CRLs.
> I would not do the latter, and I'm in doubt that the former
> is a good idea.

Agreed.

Paul

Date: Fri, 1 Apr 2011 03:13:55 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Yoav Nir <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models

On Thu, 31 Mar 2011, Yoav Nir wrote:

> Cert-lock (and CA-lock) are what EKR calls supplementary, while the others are the restrictive. While the sever (and domain owner) can't dictate client policy, they should be able to indicate whether the Certificate (TA or EE) that's in the TLSA record is supposed to be validatable or not. The client (relying party) may have a policy to ignore records that push a non-valid certificate, but if you're going to publish a record with a certificate that you have just issued using openssl on your laptop and expires in 1975, the TLSA record had better reflect that this certificate is just a container for a public key, not something you can chain and validate.
>
> So I think the requirements document should describe EKR's use cases, and require that the TLSA record be able to differentiate between records that are appropriate for the two use cases.

Are you really suggesting some kind of indicator that says "you can ignore the cruft from the cert that is bogus
that I vouched for via the RRSIG"?

Paul

From [email-masked]  Mon Apr  4 12:04:42 2011
From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= <[email-masked]>
Date: Mon, 4 Apr 2011 21:06:02 +0200
To: "[email-masked]" <[email-masked]>
Subject: [dane] The dane list was created

Hi,

the new list was created and all settings have been created. Please start us=
ing the new name.

Thank you,
Ond=C5=99ej Sur=C3=BD=

From [email-masked]  Mon Apr  4 16:38:37 2011
Date: Tue, 5 Apr 2011 01:40:17 +0200
From: Phillip Hallam-Baker <[email-masked]>
To: Warren Kumari <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

--20cf307d040831a18704a02048da
Content-Type: text/plain; charset=ISO-8859-1

I have rather a lot of use cases and I really think people would prefer that
I edit and cull mine first. Or at minimum get them into some sort of
structured representation.

Getting them all done by Thursday is going to be rather optimistic.

On Thu, Mar 31, 2011 at 12:03 AM, Warren Kumari <[email-masked]> wrote:

> Hi there all,
>
> So it became (blindingly) clear during the meeting today that we need a
> use-cases type document to clearly explain what we believe the actual use
> cases are, what we think we can do, etc.
>
> This discussion has already progressed nicely on-list ("Objective:
> Restrictive versus Supplementary Models"), but we would like to keep the
> momentum going, strike while the iron is hot and various similar idioms, so:
>
> 1: We are asking folk to please send any additional use cases to the list
> by Thursday April 7th.
>
> 2: We are starting a consensus call to add a milestone for the use-case
> document.
> From the meeting it seems that there is likely to be strong consensus for
> creating this, but please provide input on list....
>
> I would like to apologize for not realizing earlier that the group wanted
> this document -- it is very easy to get swept up in the "Let's fix this
> thing" and assuming that everyone has the same idea of what the "thing"
> actually is.... I thought that we had figured this out on-list right back at
> the beginning of time, but a: not as clearly as I thought and b: we didn't
> clearly capture this....
>
> W
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

--20cf307d040831a18704a02048da
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<meta charset=3D"utf-8"><span class=3D"Apple-style-span" style=3D"border-co=
llapse: collapse; color: rgb(51, 51, 51); font-family: arial, sans-serif; f=
ont-size: 13px; ">I have rather a lot of use cases and I really think peopl=
e would prefer that I edit and cull mine first. Or at minimum get them into=
 some sort of structured representation.<br>
<br><div>Getting them all done by Thursday is going to be rather optimistic=
.</div></span><br><div class=3D"gmail_quote">On Thu, Mar 31, 2011 at 12:03 =
AM, Warren Kumari <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]=
">[email-masked]</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;">Hi there all,<br>
<br>
So it became (blindingly) clear during the meeting today that we need a use=
-cases type document to clearly explain what we believe the actual use case=
s are, what we think we can do, etc.<br>
<br>
This discussion has already progressed nicely on-list (&quot;Objective: Res=
trictive versus Supplementary Models&quot;), but we would like to keep the =
momentum going, strike while the iron is hot and various similar idioms, so=
:<br>

<br>
1: We are asking folk to please send any additional use cases to the list b=
y Thursday April 7th.<br>
<br>
2: We are starting a consensus call to add a milestone for the use-case doc=
ument.<br>
>From the meeting it seems that there is likely to be strong consensus for c=
reating this, but please provide input on list....<br>
<br>
I would like to apologize for not realizing earlier that the group wanted t=
his document -- it is very easy to get swept up in the &quot;Let&#39;s fix =
this thing&quot; and assuming that everyone has the same idea of what the &=
quot;thing&quot; actually is.... I thought that we had figured this out on-=
list right back at the beginning of time, but a: not as clearly as I though=
t and b: we didn&#39;t clearly capture this....<br>

<br>
W<br>
_______________________________________________<br>
keyassure mailing list<br>
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/keyassure" target=3D"_blan=
k">https://www.ietf.org/mailman/listinfo/keyassure</a><br>
</blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a href=3D"htt=
p://hallambaker.com/">http://hallambaker.com/</a><br><br>

--20cf307d040831a18704a02048da--

From [email-masked]  Mon Apr  4 18:26:46 2011
From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 4 Apr 2011 21:28:20 -0400
To: Warren Kumari <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

I kind of agree with Phillip on the deadline.  I would propose pushing =
it back to the 14th.  My responses:

1. It occurs to me that all of the technologies we're talking about =
entail a domain owner putting something in the DNS to assert something =
about their domain, which implies some expectation about how the client =
should process TLS certs.  So it might be useful to phrase use cases in =
terms of what the domain owner is asserting.  Re-stating Ekr's use cases =
in this format:

Use Case 1 "CA Lock":=20
-- The certificate my server presents in TLS will be chain to this CA. =20=

-- Clients should accept a TLS server certificate only if it chains to =
this CA, but may also require that it chain to an existing trust anchor. =
=20

Use Case 2 "Cert Lock":=20
-- The certificate my server presents in TLS will be this specific =
certificate. =20
-- Clients should accept a TLS certificate only if it matches this =
certificate, but may also require that it chain to an existing trust =
anchor.

Use Case 3 "New TA":=20
-- The certificate my server presents in TLS will chain to this CA, =
which should be treated as a TA. =20
-- Clients should accept a TLS server certificate if and only if it =
chains to this CA.

Use Case 4 "Certificate as Bare Key":=20
-- The certificate my server presents in TLS will be this specific =
certificate. =20
-- Clients should accept a TLS certificate if and only if it matches =
this certificate.

Others should feel free to use this structure for any further use cases. =
=20

2. I support the addition of the milestone.

On Mar 30, 2011, at 6:03 PM, Warren Kumari wrote:

> Hi there all,
>=20
> So it became (blindingly) clear during the meeting today that we need =
a use-cases type document to clearly explain what we believe the actual =
use cases are, what we think we can do, etc.
>=20
> This discussion has already progressed nicely on-list ("Objective: =
Restrictive versus Supplementary Models"), but we would like to keep the =
momentum going, strike while the iron is hot and various similar idioms, =
so:
>=20
> 1: We are asking folk to please send any additional use cases to the =
list by Thursday April 7th.
>=20
> 2: We are starting a consensus call to add a milestone for the =
use-case document.
> =46rom the meeting it seems that there is likely to be strong =
consensus for creating this, but please provide input on list....
>=20
> I would like to apologize for not realizing earlier that the group =
wanted this document -- it is very easy to get swept up in the "Let's =
fix this thing" and assuming that everyone has the same idea of what the =
"thing" actually is.... I thought that we had figured this out on-list =
right back at the beginning of time, but a: not as clearly as I thought =
and b: we didn't clearly capture this....
>=20
> W
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

From [email-masked]  Mon Apr  4 18:34:57 2011
From: Paul Hoffman <[email-masked]>
Date: Mon, 4 Apr 2011 18:36:37 -0700
To: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

On Apr 4, 2011, at 6:28 PM, Richard L. Barnes wrote:

> I kind of agree with Phillip on the deadline.  I would propose pushing =
it back to the 14th.  My responses:
>=20
> 1. It occurs to me that all of the technologies we're talking about =
entail a domain owner putting something in the DNS to assert something =
about their domain, which implies some expectation about how the client =
should process TLS certs.  So it might be useful to phrase use cases in =
terms of what the domain owner is asserting.  Re-stating Ekr's use cases =
in this format:
>=20
> Use Case 1 "CA Lock":=20
> -- The certificate my server presents in TLS will be chain to this CA. =
=20
> -- Clients should accept a TLS server certificate only if it chains to =
this CA, but may also require that it chain to an existing trust anchor. =
=20
>=20
> Use Case 2 "Cert Lock":=20
> -- The certificate my server presents in TLS will be this specific =
certificate. =20
> -- Clients should accept a TLS certificate only if it matches this =
certificate, but may also require that it chain to an existing trust =
anchor.
>=20
> Use Case 3 "New TA":=20
> -- The certificate my server presents in TLS will chain to this CA, =
which should be treated as a TA. =20
> -- Clients should accept a TLS server certificate if and only if it =
chains to this CA.
>=20
> Use Case 4 "Certificate as Bare Key":=20
> -- The certificate my server presents in TLS will be this specific =
certificate. =20
> -- Clients should accept a TLS certificate if and only if it matches =
this certificate.

I like the wording in this taxonomy.

I consider 3 and 2 to be requirements, 1 to be useful, and 4 to be =
mostly uninteresting if if 3 and/or 2 are implemented.

--Paul Hoffman

From [email-masked]  Tue Apr  5 03:20:36 2011
Date: Tue, 5 Apr 2011 11:22:09 +0100
From: Ben Laurie <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

On 5 April 2011 02:36, Paul Hoffman <[email-masked]> wrote:
>
> On Apr 4, 2011, at 6:28 PM, Richard L. Barnes wrote:
>
>> I kind of agree with Phillip on the deadline. =A0I would propose pushing=
 it back to the 14th. =A0My responses:
>>
>> 1. It occurs to me that all of the technologies we're talking about enta=
il a domain owner putting something in the DNS to assert something about th=
eir domain, which implies some expectation about how the client should proc=
ess TLS certs. =A0So it might be useful to phrase use cases in terms of wha=
t the domain owner is asserting. =A0Re-stating Ekr's use cases in this form=
at:
>>
>> Use Case 1 "CA Lock":
>> -- The certificate my server presents in TLS will be chain to this CA.
>> -- Clients should accept a TLS server certificate only if it chains to t=
his CA, but may also require that it chain to an existing trust anchor.
>>
>> Use Case 2 "Cert Lock":
>> -- The certificate my server presents in TLS will be this specific certi=
ficate.
>> -- Clients should accept a TLS certificate only if it matches this certi=
ficate, but may also require that it chain to an existing trust anchor.
>>
>> Use Case 3 "New TA":
>> -- The certificate my server presents in TLS will chain to this CA, whic=
h should be treated as a TA.
>> -- Clients should accept a TLS server certificate if and only if it chai=
ns to this CA.
>>
>> Use Case 4 "Certificate as Bare Key":
>> -- The certificate my server presents in TLS will be this specific certi=
ficate.
>> -- Clients should accept a TLS certificate if and only if it matches thi=
s certificate.
>
> I like the wording in this taxonomy.
>
> I consider 3 and 2 to be requirements, 1 to be useful, and 4 to be mostly=
 uninteresting if if 3 and/or 2 are implemented.

OTOH, I think 4 is vital - otherwise self-signed certs cannot be first
class citizens.

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

From [email-masked]  Tue Apr  5 03:41:42 2011
From: Henry Story <[email-masked]>
Date: Tue, 5 Apr 2011 12:43:14 +0200
To: Ben Laurie <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

On 5 Apr 2011, at 12:22, Ben Laurie wrote:

> On 5 April 2011 02:36, Paul Hoffman <[email-masked]> wrote:
>>=20
>> On Apr 4, 2011, at 6:28 PM, Richard L. Barnes wrote:
>>=20
>>> I kind of agree with Phillip on the deadline.  I would propose =
pushing it back to the 14th.  My responses:
>>>=20
>>> 1. It occurs to me that all of the technologies we're talking about =
entail a domain owner putting something in the DNS to assert something =
about their domain, which implies some expectation about how the client =
should process TLS certs.  So it might be useful to phrase use cases in =
terms of what the domain owner is asserting.  Re-stating Ekr's use cases =
in this format:
>>>=20
>>> Use Case 1 "CA Lock":
>>> -- The certificate my server presents in TLS will be chain to this =
CA.
>>> -- Clients should accept a TLS server certificate only if it chains =
to this CA, but may also require that it chain to an existing trust =
anchor.
>>>=20
>>> Use Case 2 "Cert Lock":
>>> -- The certificate my server presents in TLS will be this specific =
certificate.
>>> -- Clients should accept a TLS certificate only if it matches this =
certificate, but may also require that it chain to an existing trust =
anchor.
>>>=20
>>> Use Case 3 "New TA":
>>> -- The certificate my server presents in TLS will chain to this CA, =
which should be treated as a TA.
>>> -- Clients should accept a TLS server certificate if and only if it =
chains to this CA.
>>>=20
>>> Use Case 4 "Certificate as Bare Key":
>>> -- The certificate my server presents in TLS will be this specific =
certificate.
>>> -- Clients should accept a TLS certificate if and only if it matches =
this certificate.
>>=20
>> I like the wording in this taxonomy.
>>=20
>> I consider 3 and 2 to be requirements, 1 to be useful, and 4 to be =
mostly uninteresting if if 3 and/or 2 are implemented.
>=20
> OTOH, I think 4 is vital - otherwise self-signed certs cannot be first
> class citizens.

Indeed 4 is vital. It is what can create the biggest boost for SSL =
deployment ever. As mentioned a month or so ago on this list, MOST TLS =
endpoints deployed by far are running self signed certificates according =
to the http://www.eff.org/observatory (3 times more that working TLS =
deployments). By making it easy for those to be integrated properly, =
browsers can show TLS error messages for real cases of fraudulent sites, =
thereby increasing security dramatically on the web.

Henry

>=20
>>=20
>> --Paul Hoffman

Social Web Architect
http://bblfish.net/

From [email-masked]  Tue Apr  5 04:31:26 2011
Date: Tue, 5 Apr 2011 13:32:59 +0200
From: Phillip Hallam-Baker <[email-masked]>
To: Henry Story <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

--20cf3071c9d00a65df04a02a3d2f
Content-Type: text/plain; charset=ISO-8859-1

This is not a use case approach.

What we have is simply a statement of requirements which does not have any
justification in supporting use cases.

What was asked for were use cases:

[U-WS-OPP] Alice finds Sally's server through a search engine. Alice prefers
to protect her communications with cryptography if this is supported by the
sever but will communicate in plaintext otherwise.

etc. etc.

On Tue, Apr 5, 2011 at 12:43 PM, Henry Story <[email-masked]>wrote:

>
> On 5 Apr 2011, at 12:22, Ben Laurie wrote:
>
> > On 5 April 2011 02:36, Paul Hoffman <[email-masked]> wrote:
> >>
> >> On Apr 4, 2011, at 6:28 PM, Richard L. Barnes wrote:
> >>
> >>> I kind of agree with Phillip on the deadline.  I would propose pushing
> it back to the 14th.  My responses:
> >>>
> >>> 1. It occurs to me that all of the technologies we're talking about
> entail a domain owner putting something in the DNS to assert something about
> their domain, which implies some expectation about how the client should
> process TLS certs.  So it might be useful to phrase use cases in terms of
> what the domain owner is asserting.  Re-stating Ekr's use cases in this
> format:
> >>>
> >>> Use Case 1 "CA Lock":
> >>> -- The certificate my server presents in TLS will be chain to this CA.
> >>> -- Clients should accept a TLS server certificate only if it chains to
> this CA, but may also require that it chain to an existing trust anchor.
> >>>
> >>> Use Case 2 "Cert Lock":
> >>> -- The certificate my server presents in TLS will be this specific
> certificate.
> >>> -- Clients should accept a TLS certificate only if it matches this
> certificate, but may also require that it chain to an existing trust anchor.
> >>>
> >>> Use Case 3 "New TA":
> >>> -- The certificate my server presents in TLS will chain to this CA,
> which should be treated as a TA.
> >>> -- Clients should accept a TLS server certificate if and only if it
> chains to this CA.
> >>>
> >>> Use Case 4 "Certificate as Bare Key":
> >>> -- The certificate my server presents in TLS will be this specific
> certificate.
> >>> -- Clients should accept a TLS certificate if and only if it matches
> this certificate.
> >>
> >> I like the wording in this taxonomy.
> >>
> >> I consider 3 and 2 to be requirements, 1 to be useful, and 4 to be
> mostly uninteresting if if 3 and/or 2 are implemented.
> >
> > OTOH, I think 4 is vital - otherwise self-signed certs cannot be first
> > class citizens.
>
> Indeed 4 is vital. It is what can create the biggest boost for SSL
> deployment ever. As mentioned a month or so ago on this list, MOST TLS
> endpoints deployed by far are running self signed certificates according to
> the http://www.eff.org/observatory (3 times more that working TLS
> deployments). By making it easy for those to be integrated properly,
> browsers can show TLS error messages for real cases of fraudulent sites,
> thereby increasing security dramatically on the web.
>
> Henry
>
>
> >
> >>
> >> --Paul Hoffman
>
> Social Web Architect
> http://bblfish.net/
>
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

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

--20cf3071c9d00a65df04a02a3d2f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

This is not a use case approach.<div><br></div><div>What we have is simply =
a statement of requirements which does not have any justification in suppor=
ting use cases.</div><div><br></div><div><br></div><div>What was asked for =
were use cases:</div>
<div><br></div><div>[U-WS-OPP] Alice finds Sally&#39;s server through a sea=
rch engine. Alice prefers to protect her communications with cryptography i=
f this is supported by the sever but will communicate in plaintext otherwis=
e. =A0</div>
<div><br></div><div>etc. etc.</div><div><br></div><div><br></div><div><br><=
div class=3D"gmail_quote">On Tue, Apr 5, 2011 at 12:43 PM, Henry Story <spa=
n dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">henry.story@bb=
lfish.net</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;"><div class=3D"im"><br>
On 5 Apr 2011, at 12:22, Ben Laurie wrote:<br>
<br>
&gt; On 5 April 2011 02:36, Paul Hoffman &lt;<a href=3D"mailto:paul.hoffman=
@vpnc.org">[email-masked]</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; On Apr 4, 2011, at 6:28 PM, Richard L. Barnes wrote:<br>
&gt;&gt;<br>
&gt;&gt;&gt; I kind of agree with Phillip on the deadline. =A0I would propo=
se pushing it back to the 14th. =A0My responses:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; 1. It occurs to me that all of the technologies we&#39;re talk=
ing about entail a domain owner putting something in the DNS to assert some=
thing about their domain, which implies some expectation about how the clie=
nt should process TLS certs. =A0So it might be useful to phrase use cases i=
n terms of what the domain owner is asserting. =A0Re-stating Ekr&#39;s use =
cases in this format:<br>

&gt;&gt;&gt;<br>
&gt;&gt;&gt; Use Case 1 &quot;CA Lock&quot;:<br>
&gt;&gt;&gt; -- The certificate my server presents in TLS will be chain to =
this CA.<br>
&gt;&gt;&gt; -- Clients should accept a TLS server certificate only if it c=
hains to this CA, but may also require that it chain to an existing trust a=
nchor.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Use Case 2 &quot;Cert Lock&quot;:<br>
&gt;&gt;&gt; -- The certificate my server presents in TLS will be this spec=
ific certificate.<br>
&gt;&gt;&gt; -- Clients should accept a TLS certificate only if it matches =
this certificate, but may also require that it chain to an existing trust a=
nchor.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Use Case 3 &quot;New TA&quot;:<br>
&gt;&gt;&gt; -- The certificate my server presents in TLS will chain to thi=
s CA, which should be treated as a TA.<br>
&gt;&gt;&gt; -- Clients should accept a TLS server certificate if and only =
if it chains to this CA.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Use Case 4 &quot;Certificate as Bare Key&quot;:<br>
&gt;&gt;&gt; -- The certificate my server presents in TLS will be this spec=
ific certificate.<br>
&gt;&gt;&gt; -- Clients should accept a TLS certificate if and only if it m=
atches this certificate.<br>
&gt;&gt;<br>
&gt;&gt; I like the wording in this taxonomy.<br>
&gt;&gt;<br>
&gt;&gt; I consider 3 and 2 to be requirements, 1 to be useful, and 4 to be=
 mostly uninteresting if if 3 and/or 2 are implemented.<br>
&gt;<br>
&gt; OTOH, I think 4 is vital - otherwise self-signed certs cannot be first=
<br>
&gt; class citizens.<br>
<br>
</div>Indeed 4 is vital. It is what can create the biggest boost for SSL de=
ployment ever. As mentioned a month or so ago on this list, MOST TLS endpoi=
nts deployed by far are running self signed certificates according to the <=
a href=3D"http://www.eff.org/observatory" target=3D"_blank">http://www.eff.=
org/observatory</a> (3 times more that working TLS deployments). By making =
it easy for those to be integrated properly, browsers can show TLS error me=
ssages for real cases of fraudulent sites, thereby increasing security dram=
atically on the web.<br>

<br>
Henry<br>
<br>
<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; --Paul Hoffman<br>
<br>
Social Web Architect<br>
<a href=3D"http://bblfish.net/" target=3D"_blank">http://bblfish.net/</a><b=
r>
<div><div></div><div class=3D"h5"><br>
_______________________________________________<br>
dane mailing list<br>
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/dane</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--20cf3071c9d00a65df04a02a3d2f--

From [email-masked]  Tue Apr  5 04:32:30 2011
Date: Tue, 5 Apr 2011 12:34:03 +0100
From: Ben Laurie <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

On 5 April 2011 12:32, Phillip Hallam-Baker <[email-masked]> wrote:
> This is not a use case approach.
> What we have is simply a statement of requirements which does not have an=
y
> justification in supporting use cases.

This does not alter the fact that 4 is vital :-)

>
> What was asked for were use cases:
> [U-WS-OPP] Alice finds Sally's server through a search engine. Alice pref=
ers
> to protect her communications with cryptography if this is supported by t=
he
> sever but will communicate in plaintext otherwise.
> etc. etc.
>
>
> On Tue, Apr 5, 2011 at 12:43 PM, Henry Story <[email-masked]>
> wrote:
>>
>> On 5 Apr 2011, at 12:22, Ben Laurie wrote:
>>
>> > On 5 April 2011 02:36, Paul Hoffman <[email-masked]> wrote:
>> >>
>> >> On Apr 4, 2011, at 6:28 PM, Richard L. Barnes wrote:
>> >>
>> >>> I kind of agree with Phillip on the deadline. =A0I would propose pus=
hing
>> >>> it back to the 14th. =A0My responses:
>> >>>
>> >>> 1. It occurs to me that all of the technologies we're talking about
>> >>> entail a domain owner putting something in the DNS to assert somethi=
ng about
>> >>> their domain, which implies some expectation about how the client sh=
ould
>> >>> process TLS certs. =A0So it might be useful to phrase use cases in t=
erms of
>> >>> what the domain owner is asserting. =A0Re-stating Ekr's use cases in=
 this
>> >>> format:
>> >>>
>> >>> Use Case 1 "CA Lock":
>> >>> -- The certificate my server presents in TLS will be chain to this C=
A.
>> >>> -- Clients should accept a TLS server certificate only if it chains =
to
>> >>> this CA, but may also require that it chain to an existing trust anc=
hor.
>> >>>
>> >>> Use Case 2 "Cert Lock":
>> >>> -- The certificate my server presents in TLS will be this specific
>> >>> certificate.
>> >>> -- Clients should accept a TLS certificate only if it matches this
>> >>> certificate, but may also require that it chain to an existing trust=
 anchor.
>> >>>
>> >>> Use Case 3 "New TA":
>> >>> -- The certificate my server presents in TLS will chain to this CA,
>> >>> which should be treated as a TA.
>> >>> -- Clients should accept a TLS server certificate if and only if it
>> >>> chains to this CA.
>> >>>
>> >>> Use Case 4 "Certificate as Bare Key":
>> >>> -- The certificate my server presents in TLS will be this specific
>> >>> certificate.
>> >>> -- Clients should accept a TLS certificate if and only if it matches
>> >>> this certificate.
>> >>
>> >> I like the wording in this taxonomy.
>> >>
>> >> I consider 3 and 2 to be requirements, 1 to be useful, and 4 to be
>> >> mostly uninteresting if if 3 and/or 2 are implemented.
>> >
>> > OTOH, I think 4 is vital - otherwise self-signed certs cannot be first
>> > class citizens.
>>
>> Indeed 4 is vital. It is what can create the biggest boost for SSL
>> deployment ever. As mentioned a month or so ago on this list, MOST TLS
>> endpoints deployed by far are running self signed certificates according=
 to
>> the http://www.eff.org/observatory (3 times more that working TLS
>> deployments). By making it easy for those to be integrated properly,
>> browsers can show TLS error messages for real cases of fraudulent sites,
>> thereby increasing security dramatically on the web.
>>
>> Henry
>>
>>
>> >
>> >>
>> >> --Paul Hoffman
>>
>> Social Web Architect
>> http://bblfish.net/
>>
>> _______________________________________________
>> dane mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dane
>
>
>
> --
> Website: http://hallambaker.com/
>
>

From [email-masked]  Tue Apr  5 04:46:49 2011
Resent-To: [email-masked]
Resent-From: Florian Weimer <[email-masked]>
Resent-Date: Tue, 05 Apr 2011 11:48:23 +0000
Resent-Message-ID: <[email-masked]>
To: Eric Rescorla <[email-masked]>
From: Florian Weimer <[email-masked]>
Date: Tue, 05 Apr 2011 11:13:12 +0000
Lines: 26
Resent-Date: Tue, 05 Apr 2011 11:48:23 +0000
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Objective: Restrictive versus Supplementary Models

* Eric Rescorla:

> In the second case, the intention is to allow clients to effectively
> bypass the existing trust hierarchy by injecting a new trust point
> via the DNS. Thus, either the certificate validation simply will not
> be used at all (in the case where a terminal certificate is
> provided) or will be used up to a newly inserted trust anchor. In
> either case, the presumptive rationale here is that it's too
> inconvenient to deal with the existing CAs and that DANE will be
> easier.  This version of DANE *does* need to be protected via DNSSEC
> because tampering with these records allows the attacker to
> impersonate the authenticating party to the relying party.

If you switch HTTPS transparently (meaning: no UI indicators, secure
cookies are not sent, SOP checks run against :80 instead of :443),
then you don't need DNSSEC.

I'm pretty sure it's politically and technically infeasible to
introduce DNSSEC-driven UI changes on a larger scale, so I doubt that
any non-transparent approach will fly.

--=20
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstra=DFe 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

From [email-masked]  Tue Apr  5 05:00:34 2011
From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 5 Apr 2011 08:02:05 -0400
To: Ben Laurie <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

>>> I kind of agree with Phillip on the deadline.  I would propose =
pushing it back to the 14th.  My responses:
>>>=20
>>> 1. It occurs to me that all of the technologies we're talking about =
entail a domain owner putting something in the DNS to assert something =
about their domain, which implies some expectation about how the client =
should process TLS certs.  So it might be useful to phrase use cases in =
terms of what the domain owner is asserting.  Re-stating Ekr's use cases =
in this format:
>>>=20
>>> Use Case 1 "CA Lock":
>>> -- The certificate my server presents in TLS will be chain to this =
CA.
>>> -- Clients should accept a TLS server certificate only if it chains =
to this CA, but may also require that it chain to an existing trust =
anchor.
>>>=20
>>> Use Case 2 "Cert Lock":
>>> -- The certificate my server presents in TLS will be this specific =
certificate.
>>> -- Clients should accept a TLS certificate only if it matches this =
certificate, but may also require that it chain to an existing trust =
anchor.
>>>=20
>>> Use Case 3 "New TA":
>>> -- The certificate my server presents in TLS will chain to this CA, =
which should be treated as a TA.
>>> -- Clients should accept a TLS server certificate if and only if it =
chains to this CA.
>>>=20
>>> Use Case 4 "Certificate as Bare Key":
>>> -- The certificate my server presents in TLS will be this specific =
certificate.
>>> -- Clients should accept a TLS certificate if and only if it matches =
this certificate.
>>=20
>> I like the wording in this taxonomy.
>>=20
>> I consider 3 and 2 to be requirements, 1 to be useful, and 4 to be =
mostly uninteresting if if 3 and/or 2 are implemented.
>=20
> OTOH, I think 4 is vital - otherwise self-signed certs cannot be first
> class citizens.

Just one technical point: You can arguably do self-signed certs with 3, =
either because self-signed certs chain to themselves, or because you can =
issue a second cert under a self-signed TA you put in DANE.  Pretty =
picture on slide 8 of this:
<http://tools.ietf.org/agenda/80/slides/dane-2.pdf>

--Richard=

From [email-masked]  Tue Apr  5 05:01:04 2011
From: Yoav Nir <[email-masked]>
To: Henry Story <[email-masked]>
Date: Tue, 5 Apr 2011 14:02:35 +0200
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dane] [keyassure] Use cases document.

On Apr 5, 2011, at 1:43 PM, Henry Story wrote:

>=20
> On 5 Apr 2011, at 12:22, Ben Laurie wrote:
>=20
>>>>=20
>>>> Use Case 1 "CA Lock":
>>>> -- The certificate my server presents in TLS will be chain to this CA.
>>>> -- Clients should accept a TLS server certificate only if it chains to=
 this CA, but may also require that it chain to an existing trust anchor.
>>>>=20
>>>> Use Case 2 "Cert Lock":
>>>> -- The certificate my server presents in TLS will be this specific cer=
tificate.
>>>> -- Clients should accept a TLS certificate only if it matches this cer=
tificate, but may also require that it chain to an existing trust anchor.
>>>>=20
>>>> Use Case 3 "New TA":
>>>> -- The certificate my server presents in TLS will chain to this CA, wh=
ich should be treated as a TA.
>>>> -- Clients should accept a TLS server certificate if and only if it ch=
ains to this CA.
>>>>=20
>>>> Use Case 4 "Certificate as Bare Key":
>>>> -- The certificate my server presents in TLS will be this specific cer=
tificate.
>>>> -- Clients should accept a TLS certificate if and only if it matches t=
his certificate.
>>>=20
>>> I like the wording in this taxonomy.
>>>=20
>>> I consider 3 and 2 to be requirements, 1 to be useful, and 4 to be most=
ly uninteresting if if 3 and/or 2 are implemented.
>>=20
>> OTOH, I think 4 is vital - otherwise self-signed certs cannot be first
>> class citizens.
>=20
> Indeed 4 is vital. It is what can create the biggest boost for SSL deploy=
ment ever. As mentioned a month or so ago on this list, MOST TLS endpoints =
deployed by far are running self signed certificates according to the http:=
//www.eff.org/observatory (3 times more that working TLS deployments). By m=
aking it easy for those to be integrated properly, browsers can show TLS er=
ror messages for real cases of fraudulent sites, thereby increasing securit=
y dramatically on the web.

+1=

From [email-masked]  Tue Apr  5 05:12:36 2011
Date: Tue, 5 Apr 2011 14:14:10 +0200
From: Phillip Hallam-Baker <[email-masked]>
To: Ben Laurie <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

--20cf3071c9d052ccc604a02ad0d5
Content-Type: text/plain; charset=ISO-8859-1

But what are the circumstances in which it is to be used?

Does Alice have a preference for confidentiality or is this essential? Does
Alice need to be able to verify that encryption is in use? Does Alice need
to know anything about the accountability, reputation or otherwise of the
subject?

There is a very low end security approach where all we want to do is to turn
on encryption if possible and connect with plaintext otherwise. Alice is
willing to accept the possibility of a man in the middle approach and is not
going to verify the status of the connection.

There is also a very high end security approach where we wish to ensure
strict security on first and every contact and ensure that compatible trust
anchors are employed.

And there are shades in between.

The first case can be addressed without DNSSEC: Just use encryption and
don't provide any security signal (e.g. padlock) in primary chrome.

The second case needs DNSSEC and more to add trust in.

While the precise definition of what 'strict security' turns out to be is
something we can leave to =Jeff and co in WebSec. I think we need to have a
story for how we could present the 'strict' indicator through the DNS along
with the trust anchor/key restrictions.

We may not want to add such capability to the standard immediately, but we
can have extensibility without impact on what people assert are the 'core'
use cases. I don't see why we have to accept the idea that because some
people are only interested in X we should deliberately design the spec so
that it is only capable of doing X and can never, ever be extended to do
anything else whatsoever.

The consensus at the Prague meeting was very clearly that DANE needs to go
back and do use cases and requirements.

In my view that means that the room rejected the idea of simply writing a
set of requirements that precisely describe the capabilities of the only
proposal that has been allowed to be considered.

There was a very strong view in the room that DANE has tried to move too
fast to propose a solution. Now that may in part be my fault, I have been
thinking about this particular problem for many years. But I think that
there was also a feeling that the WG had defined the problem it was trying
to solve to be the need to use the exact technology being proposed rather
than look at what a potential adopter of the scheme might be looking for.

I agree that your requirement is essential. But I disagree with the idea
that we should therefore design a spec that stovepipes that single
requirement.

On Tue, Apr 5, 2011 at 1:34 PM, Ben Laurie <[email-masked]> wrote:

> On 5 April 2011 12:32, Phillip Hallam-Baker <[email-masked]> wrote:
> > This is not a use case approach.
> > What we have is simply a statement of requirements which does not have
> any
> > justification in supporting use cases.
>
> This does not alter the fact that 4 is vital :-)
>
> >
> > What was asked for were use cases:
> > [U-WS-OPP] Alice finds Sally's server through a search engine. Alice
> prefers
> > to protect her communications with cryptography if this is supported by
> the
> > sever but will communicate in plaintext otherwise.
> > etc. etc.
> >
> >
> > On Tue, Apr 5, 2011 at 12:43 PM, Henry Story <[email-masked]>
> > wrote:
> >>
> >> On 5 Apr 2011, at 12:22, Ben Laurie wrote:
> >>
> >> > On 5 April 2011 02:36, Paul Hoffman <[email-masked]> wrote:
> >> >>
> >> >> On Apr 4, 2011, at 6:28 PM, Richard L. Barnes wrote:
> >> >>
> >> >>> I kind of agree with Phillip on the deadline.  I would propose
> pushing
> >> >>> it back to the 14th.  My responses:
> >> >>>
> >> >>> 1. It occurs to me that all of the technologies we're talking about
> >> >>> entail a domain owner putting something in the DNS to assert
> something about
> >> >>> their domain, which implies some expectation about how the client
> should
> >> >>> process TLS certs.  So it might be useful to phrase use cases in
> terms of
> >> >>> what the domain owner is asserting.  Re-stating Ekr's use cases in
> this
> >> >>> format:
> >> >>>
> >> >>> Use Case 1 "CA Lock":
> >> >>> -- The certificate my server presents in TLS will be chain to this
> CA.
> >> >>> -- Clients should accept a TLS server certificate only if it chains
> to
> >> >>> this CA, but may also require that it chain to an existing trust
> anchor.
> >> >>>
> >> >>> Use Case 2 "Cert Lock":
> >> >>> -- The certificate my server presents in TLS will be this specific
> >> >>> certificate.
> >> >>> -- Clients should accept a TLS certificate only if it matches this
> >> >>> certificate, but may also require that it chain to an existing trust
> anchor.
> >> >>>
> >> >>> Use Case 3 "New TA":
> >> >>> -- The certificate my server presents in TLS will chain to this CA,
> >> >>> which should be treated as a TA.
> >> >>> -- Clients should accept a TLS server certificate if and only if it
> >> >>> chains to this CA.
> >> >>>
> >> >>> Use Case 4 "Certificate as Bare Key":
> >> >>> -- The certificate my server presents in TLS will be this specific
> >> >>> certificate.
> >> >>> -- Clients should accept a TLS certificate if and only if it matches
> >> >>> this certificate.
> >> >>
> >> >> I like the wording in this taxonomy.
> >> >>
> >> >> I consider 3 and 2 to be requirements, 1 to be useful, and 4 to be
> >> >> mostly uninteresting if if 3 and/or 2 are implemented.
> >> >
> >> > OTOH, I think 4 is vital - otherwise self-signed certs cannot be first
> >> > class citizens.
> >>
> >> Indeed 4 is vital. It is what can create the biggest boost for SSL
> >> deployment ever. As mentioned a month or so ago on this list, MOST TLS
> >> endpoints deployed by far are running self signed certificates according
> to
> >> the http://www.eff.org/observatory (3 times more that working TLS
> >> deployments). By making it easy for those to be integrated properly,
> >> browsers can show TLS error messages for real cases of fraudulent sites,
> >> thereby increasing security dramatically on the web.
> >>
> >> Henry
> >>
> >>
> >> >
> >> >>
> >> >> --Paul Hoffman
> >>
> >> Social Web Architect
> >> http://bblfish.net/
> >>
> >> _______________________________________________
> >> dane mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/dane
> >
> >
> >
> > --
> > Website: http://hallambaker.com/
> >
> >
>

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

--20cf3071c9d052ccc604a02ad0d5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

But what are the circumstances in which it is to be used?<div><br></div><di=
v>Does Alice have a preference for confidentiality or is this essential? Do=
es Alice need to be able to verify that encryption is in use? Does Alice ne=
ed to know anything about the accountability, reputation or otherwise of th=
e subject?</div>
<div><br></div><div><br></div><div>There is a very low end security approac=
h where all we want to do is to turn on encryption if possible and connect =
with plaintext otherwise. Alice is willing to accept the possibility of a m=
an in the middle approach and is not going to verify the status of the conn=
ection.</div>
<div><br></div><div>There is also a very high end security approach where w=
e wish to ensure strict security on first and every contact and ensure that=
 compatible trust anchors are employed.</div><div><br></div><div>And there =
are shades in between.</div>
<div><br></div><div><br></div><div>The first case can be addressed without =
DNSSEC: Just use encryption and don&#39;t provide any security signal (e.g.=
 padlock) in primary chrome.</div><div><br></div><div>The second case needs=
 DNSSEC and more to add trust in.</div>
<div><br></div><div><br></div><div>While the precise definition of what &#3=
9;strict security&#39; turns out to be is something we can leave to =3DJeff=
 and co in WebSec. I think we need to have a story for how we could present=
 the &#39;strict&#39; indicator through the DNS along with the trust anchor=
/key restrictions.</div>
<div><br></div><div>We may not want to add such capability to the standard =
immediately, but we can have extensibility without impact on what people as=
sert are the &#39;core&#39; use cases. I don&#39;t see why we have to accep=
t the idea that because some people are only interested in X we should deli=
berately design the spec so that it is only capable of doing X and can neve=
r, ever be extended to do anything else whatsoever.</div>
<div><br></div><div><br></div><div>The consensus at the Prague meeting was =
very clearly that DANE needs to go back and do use cases and requirements.<=
/div><div><br></div><div>In my view that means that the room rejected the i=
dea of simply writing a set of requirements that precisely describe the cap=
abilities of the only proposal that has been allowed to be considered.</div=
>
<div><br></div><div>There was a very strong view in the room that DANE has =
tried to move too fast to propose a solution. Now that may in part be my fa=
ult, I have been thinking about this particular problem for many years. But=
 I think that there was also a feeling that the WG had defined the problem =
it was trying to solve to be the need to use the exact technology being pro=
posed rather than look at what a potential adopter of the scheme might be l=
ooking for.</div>
<div><br></div><div><br></div><div>I agree that your requirement is essenti=
al. But I disagree with the idea that we should therefore design a spec tha=
t stovepipes that single requirement.</div><div><br></div><div><br></div>
<div><div class=3D"gmail_quote">On Tue, Apr 5, 2011 at 1:34 PM, Ben Laurie =
<span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">[email-masked]</a=
>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">On 5 April 2011 12:32, Phillip Hallam-Baker &lt;<a href=
=3D"mailto:[email-masked]">[email-masked]</a>&gt; wrote:<br>
&gt; This is not a use case approach.<br>
&gt; What we have is simply a statement of requirements which does not have=
 any<br>
&gt; justification in supporting use cases.<br>
<br>
</div>This does not alter the fact that 4 is vital :-)<br>
<div><div></div><div class=3D"h5"><br>
&gt;<br>
&gt; What was asked for were use cases:<br>
&gt; [U-WS-OPP] Alice finds Sally&#39;s server through a search engine. Ali=
ce prefers<br>
&gt; to protect her communications with cryptography if this is supported b=
y the<br>
&gt; sever but will communicate in plaintext otherwise.<br>
&gt; etc. etc.<br>
&gt;<br>
&gt;<br>
&gt; On Tue, Apr 5, 2011 at 12:43 PM, Henry Story &lt;<a href=3D"mailto:hen=
[email-masked]">[email-masked]</a>&gt;<br>
&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; On 5 Apr 2011, at 12:22, Ben Laurie wrote:<br>
&gt;&gt;<br>
&gt;&gt; &gt; On 5 April 2011 02:36, Paul Hoffman &lt;<a href=3D"mailto:pau=
[email-masked]">[email-masked]</a>&gt; wrote:<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; On Apr 4, 2011, at 6:28 PM, Richard L. Barnes wrote:<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; I kind of agree with Phillip on the deadline. =A0I wo=
uld propose pushing<br>
&gt;&gt; &gt;&gt;&gt; it back to the 14th. =A0My responses:<br>
&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; 1. It occurs to me that all of the technologies we&#3=
9;re talking about<br>
&gt;&gt; &gt;&gt;&gt; entail a domain owner putting something in the DNS to=
 assert something about<br>
&gt;&gt; &gt;&gt;&gt; their domain, which implies some expectation about ho=
w the client should<br>
&gt;&gt; &gt;&gt;&gt; process TLS certs. =A0So it might be useful to phrase=
 use cases in terms of<br>
&gt;&gt; &gt;&gt;&gt; what the domain owner is asserting. =A0Re-stating Ekr=
&#39;s use cases in this<br>
&gt;&gt; &gt;&gt;&gt; format:<br>
&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; Use Case 1 &quot;CA Lock&quot;:<br>
&gt;&gt; &gt;&gt;&gt; -- The certificate my server presents in TLS will be =
chain to this CA.<br>
&gt;&gt; &gt;&gt;&gt; -- Clients should accept a TLS server certificate onl=
y if it chains to<br>
&gt;&gt; &gt;&gt;&gt; this CA, but may also require that it chain to an exi=
sting trust anchor.<br>
&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; Use Case 2 &quot;Cert Lock&quot;:<br>
&gt;&gt; &gt;&gt;&gt; -- The certificate my server presents in TLS will be =
this specific<br>
&gt;&gt; &gt;&gt;&gt; certificate.<br>
&gt;&gt; &gt;&gt;&gt; -- Clients should accept a TLS certificate only if it=
 matches this<br>
&gt;&gt; &gt;&gt;&gt; certificate, but may also require that it chain to an=
 existing trust anchor.<br>
&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; Use Case 3 &quot;New TA&quot;:<br>
&gt;&gt; &gt;&gt;&gt; -- The certificate my server presents in TLS will cha=
in to this CA,<br>
&gt;&gt; &gt;&gt;&gt; which should be treated as a TA.<br>
&gt;&gt; &gt;&gt;&gt; -- Clients should accept a TLS server certificate if =
and only if it<br>
&gt;&gt; &gt;&gt;&gt; chains to this CA.<br>
&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; Use Case 4 &quot;Certificate as Bare Key&quot;:<br>
&gt;&gt; &gt;&gt;&gt; -- The certificate my server presents in TLS will be =
this specific<br>
&gt;&gt; &gt;&gt;&gt; certificate.<br>
&gt;&gt; &gt;&gt;&gt; -- Clients should accept a TLS certificate if and onl=
y if it matches<br>
&gt;&gt; &gt;&gt;&gt; this certificate.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; I like the wording in this taxonomy.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; I consider 3 and 2 to be requirements, 1 to be useful, an=
d 4 to be<br>
&gt;&gt; &gt;&gt; mostly uninteresting if if 3 and/or 2 are implemented.<br=
>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; OTOH, I think 4 is vital - otherwise self-signed certs cannot=
 be first<br>
&gt;&gt; &gt; class citizens.<br>
&gt;&gt;<br>
&gt;&gt; Indeed 4 is vital. It is what can create the biggest boost for SSL=
<br>
&gt;&gt; deployment ever. As mentioned a month or so ago on this list, MOST=
 TLS<br>
&gt;&gt; endpoints deployed by far are running self signed certificates acc=
ording to<br>
&gt;&gt; the <a href=3D"http://www.eff.org/observatory" target=3D"_blank">h=
ttp://www.eff.org/observatory</a> (3 times more that working TLS<br>
&gt;&gt; deployments). By making it easy for those to be integrated properl=
y,<br>
&gt;&gt; browsers can show TLS error messages for real cases of fraudulent =
sites,<br>
&gt;&gt; thereby increasing security dramatically on the web.<br>
&gt;&gt;<br>
&gt;&gt; Henry<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; --Paul Hoffman<br>
&gt;&gt;<br>
&gt;&gt; Social Web Architect<br>
&gt;&gt; <a href=3D"http://bblfish.net/" target=3D"_blank">http://bblfish.n=
et/</a><br>
&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; dane mailing list<br>
&gt;&gt; <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
&gt;&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_=
blank">https://www.ietf.org/mailman/listinfo/dane</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; Website: <a href=3D"http://hallambaker.com/" target=3D"_blank">http://=
hallambaker.com/</a><br>
&gt;<br>
&gt;<br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--20cf3071c9d052ccc604a02ad0d5--

From [email-masked]  Tue Apr  5 05:18:10 2011
From: Paul Hoffman <[email-masked]>
Date: Tue, 5 Apr 2011 05:19:33 -0700
To: "Richard L. Barnes" <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

On Apr 5, 2011, at 5:02 AM, Richard L. Barnes wrote:

>>>> I kind of agree with Phillip on the deadline.  I would propose =
pushing it back to the 14th.  My responses:
>>>>=20
>>>> 1. It occurs to me that all of the technologies we're talking about =
entail a domain owner putting something in the DNS to assert something =
about their domain, which implies some expectation about how the client =
should process TLS certs.  So it might be useful to phrase use cases in =
terms of what the domain owner is asserting.  Re-stating Ekr's use cases =
in this format:
>>>>=20
>>>> Use Case 1 "CA Lock":
>>>> -- The certificate my server presents in TLS will be chain to this =
CA.
>>>> -- Clients should accept a TLS server certificate only if it chains =
to this CA, but may also require that it chain to an existing trust =
anchor.
>>>>=20
>>>> Use Case 2 "Cert Lock":
>>>> -- The certificate my server presents in TLS will be this specific =
certificate.
>>>> -- Clients should accept a TLS certificate only if it matches this =
certificate, but may also require that it chain to an existing trust =
anchor.
>>>>=20
>>>> Use Case 3 "New TA":
>>>> -- The certificate my server presents in TLS will chain to this CA, =
which should be treated as a TA.
>>>> -- Clients should accept a TLS server certificate if and only if it =
chains to this CA.
>>>>=20
>>>> Use Case 4 "Certificate as Bare Key":
>>>> -- The certificate my server presents in TLS will be this specific =
certificate.
>>>> -- Clients should accept a TLS certificate if and only if it =
matches this certificate.
>>>=20
>>> I like the wording in this taxonomy.
>>>=20
>>> I consider 3 and 2 to be requirements, 1 to be useful, and 4 to be =
mostly uninteresting if if 3 and/or 2 are implemented.
>>=20
>> OTOH, I think 4 is vital - otherwise self-signed certs cannot be =
first
>> class citizens.
>=20
> Just one technical point: You can arguably do self-signed certs with =
3, either because self-signed certs chain to themselves, or because you =
can issue a second cert under a self-signed TA you put in DANE.  Pretty =
picture on slide 8 of this:
> <http://tools.ietf.org/agenda/80/slides/dane-2.pdf>

That's not a "technical point", it is a fundamental feature. With #3, #4 =
becomes pretty irrelevant and implementers have fewer different =
semantics to deal with.

--Paul Hoffman

From [email-masked]  Tue Apr  5 05:19:27 2011
Date: Tue, 5 Apr 2011 13:20:58 +0100
From: Ben Laurie <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

On 5 April 2011 13:14, Phillip Hallam-Baker <[email-masked]> wrote:
> But what are the circumstances in which it is to be used?
> Does Alice have a preference for confidentiality or is this essential? Do=
es
> Alice need to be able to verify that encryption is in use? Does Alice nee=
d
> to know anything about the accountability, reputation or otherwise of the
> subject?
>
> There is a very low end security approach where all we want to do is to t=
urn
> on encryption if possible and connect with plaintext otherwise. Alice is
> willing to accept the possibility of a man in the middle approach and is =
not
> going to verify the status of the connection.
> There is also a very high end security approach where we wish to ensure
> strict security on first and every contact and ensure that compatible tru=
st
> anchors are employed.
> And there are shades in between.
>
> The first case can be addressed without DNSSEC: Just use encryption and
> don't provide any security signal (e.g. padlock) in primary chrome.
> The second case needs DNSSEC and more to add trust in.
>
> While the precise definition of what 'strict security' turns out to be is
> something we can leave to =3DJeff and co in WebSec. I think we need to ha=
ve a
> story for how we could present the 'strict' indicator through the DNS alo=
ng
> with the trust anchor/key restrictions.
> We may not want to add such capability to the standard immediately, but w=
e
> can have extensibility without impact on what people assert are the 'core=
'
> use cases. I don't see why we have to accept the idea that because some
> people are only interested in X we should deliberately design the spec so
> that it is only capable of doing X and can never, ever be extended to do
> anything else whatsoever.
>
> The consensus at the Prague meeting was very clearly that DANE needs to g=
o
> back and do use cases and requirements.
> In my view that means that the room rejected the idea of simply writing a
> set of requirements that precisely describe the capabilities of the only
> proposal that has been allowed to be considered.
> There was a very strong view in the room that DANE has tried to move too
> fast to propose a solution. Now that may in part be my fault, I have been
> thinking about this particular problem for many years. But I think that
> there was also a feeling that the WG had defined the problem it was tryin=
g
> to solve to be the need to use the exact technology being proposed rather
> than look at what a potential adopter of the scheme might be looking for.
>
> I agree that your requirement is essential. But I disagree with the idea
> that we should therefore design a spec that stovepipes that single
> requirement.

All I was doing was disagreeing with Paul, not attempting to define
the sole agenda of the WG.

>
> On Tue, Apr 5, 2011 at 1:34 PM, Ben Laurie <[email-masked]> wrote:
>>
>> On 5 April 2011 12:32, Phillip Hallam-Baker <[email-masked]> wrote:
>> > This is not a use case approach.
>> > What we have is simply a statement of requirements which does not have
>> > any
>> > justification in supporting use cases.
>>
>> This does not alter the fact that 4 is vital :-)
>>
>> >
>> > What was asked for were use cases:
>> > [U-WS-OPP] Alice finds Sally's server through a search engine. Alice
>> > prefers
>> > to protect her communications with cryptography if this is supported b=
y
>> > the
>> > sever but will communicate in plaintext otherwise.
>> > etc. etc.
>> >
>> >
>> > On Tue, Apr 5, 2011 at 12:43 PM, Henry Story <[email-masked]>
>> > wrote:
>> >>
>> >> On 5 Apr 2011, at 12:22, Ben Laurie wrote:
>> >>
>> >> > On 5 April 2011 02:36, Paul Hoffman <[email-masked]> wrote:
>> >> >>
>> >> >> On Apr 4, 2011, at 6:28 PM, Richard L. Barnes wrote:
>> >> >>
>> >> >>> I kind of agree with Phillip on the deadline. =A0I would propose
>> >> >>> pushing
>> >> >>> it back to the 14th. =A0My responses:
>> >> >>>
>> >> >>> 1. It occurs to me that all of the technologies we're talking abo=
ut
>> >> >>> entail a domain owner putting something in the DNS to assert
>> >> >>> something about
>> >> >>> their domain, which implies some expectation about how the client
>> >> >>> should
>> >> >>> process TLS certs. =A0So it might be useful to phrase use cases i=
n
>> >> >>> terms of
>> >> >>> what the domain owner is asserting. =A0Re-stating Ekr's use cases=
 in
>> >> >>> this
>> >> >>> format:
>> >> >>>
>> >> >>> Use Case 1 "CA Lock":
>> >> >>> -- The certificate my server presents in TLS will be chain to thi=
s
>> >> >>> CA.
>> >> >>> -- Clients should accept a TLS server certificate only if it chai=
ns
>> >> >>> to
>> >> >>> this CA, but may also require that it chain to an existing trust
>> >> >>> anchor.
>> >> >>>
>> >> >>> Use Case 2 "Cert Lock":
>> >> >>> -- The certificate my server presents in TLS will be this specifi=
c
>> >> >>> certificate.
>> >> >>> -- Clients should accept a TLS certificate only if it matches thi=
s
>> >> >>> certificate, but may also require that it chain to an existing
>> >> >>> trust anchor.
>> >> >>>
>> >> >>> Use Case 3 "New TA":
>> >> >>> -- The certificate my server presents in TLS will chain to this C=
A,
>> >> >>> which should be treated as a TA.
>> >> >>> -- Clients should accept a TLS server certificate if and only if =
it
>> >> >>> chains to this CA.
>> >> >>>
>> >> >>> Use Case 4 "Certificate as Bare Key":
>> >> >>> -- The certificate my server presents in TLS will be this specifi=
c
>> >> >>> certificate.
>> >> >>> -- Clients should accept a TLS certificate if and only if it
>> >> >>> matches
>> >> >>> this certificate.
>> >> >>
>> >> >> I like the wording in this taxonomy.
>> >> >>
>> >> >> I consider 3 and 2 to be requirements, 1 to be useful, and 4 to be
>> >> >> mostly uninteresting if if 3 and/or 2 are implemented.
>> >> >
>> >> > OTOH, I think 4 is vital - otherwise self-signed certs cannot be
>> >> > first
>> >> > class citizens.
>> >>
>> >> Indeed 4 is vital. It is what can create the biggest boost for SSL
>> >> deployment ever. As mentioned a month or so ago on this list, MOST TL=
S
>> >> endpoints deployed by far are running self signed certificates
>> >> according to
>> >> the http://www.eff.org/observatory (3 times more that working TLS
>> >> deployments). By making it easy for those to be integrated properly,
>> >> browsers can show TLS error messages for real cases of fraudulent
>> >> sites,
>> >> thereby increasing security dramatically on the web.
>> >>
>> >> Henry
>> >>
>> >>
>> >> >
>> >> >>
>> >> >> --Paul Hoffman
>> >>
>> >> Social Web Architect
>> >> http://bblfish.net/
>> >>
>> >> _______________________________________________
>> >> dane mailing list
>> >> [email-masked]
>> >> https://www.ietf.org/mailman/listinfo/dane
>> >
>> >
>> >
>> > --
>> > Website: http://hallambaker.com/
>> >
>> >
>
>
>
> --
> Website: http://hallambaker.com/
>
>

From [email-masked]  Tue Apr  5 05:21:38 2011
From: Paul Hoffman <[email-masked]>
Date: Tue, 5 Apr 2011 05:23:18 -0700
To: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

On Apr 5, 2011, at 4:32 AM, Phillip Hallam-Baker wrote:

> This is not a use case approach.

Correct: it is a requirements approach. As we have seen in the =
discussion thread so far, use cases often are tinged with what the =
proposed technical solution should be. This is not to say that use cases =
are bad; in fact, they would be a helpful addition to this discussion.

> What we have is simply a statement of requirements which does not have =
any justification in supporting use cases.

We disagree: the requirements listed by various people so far can be =
mapped to some use cases.

> What was asked for were use cases:

Were we in the same meeting? What was asked for was requirements and use =
cases.

> [U-WS-OPP] Alice finds Sally's server through a search engine. Alice =
prefers to protect her communications with cryptography if this is =
supported by the sever but will communicate in plaintext otherwise. =20
>=20
> etc. etc.

This highlights what will be interesting in the use case scenario: will =
the use cases be driven by the TLS client users or TLS server users?

--Paul Hoffman

From [email-masked]  Tue Apr  5 05:35:11 2011
From: Henry Story <[email-masked]>
Date: Tue, 5 Apr 2011 14:36:38 +0200
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

--Apple-Mail-59--570232588
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On 5 Apr 2011, at 14:14, Phillip Hallam-Baker wrote:

> But what are the circumstances in which it is to be used?
>=20
> Does Alice have a preference for confidentiality or is this essential? =
Does Alice need to be able to verify that encryption is in use? Does =
Alice need to know anything about the accountability, reputation or =
otherwise of the subject?

The only thing that would be guaranteed to clients connecting to servers =
presenting self signed certificates matching the cert (or its bare key) =
in the DNSsec  is connection to the computer named in the DNS. That is a =
huge improvement for all the servers presenting self signed =
certificates.

The way I see Dane is that it increases trust at every level. It is =
quite easy to understand why: there is now an additional way to confirm =
information:

 - so self signed certs, move from just being useful for guaranteeing =
communication to also guaranteeing identity (they move from no padlock =
to padlock)
 - CA signed certs move away from  the growing danger of irrelevance - =
since they can be undermined by corrupt CAs, aka the weakest link =
problem - to being verified and supported by the DNS

>=20
> There is a very low end security approach where all we want to do is =
to turn on encryption if possible and connect with plaintext otherwise. =
Alice is willing to accept the possibility of a man in the middle =
approach and is not going to verify the status of the connection.

that is self signed certs now, running 3 times as many TLS end points as =
CA signed tls endpoints.

>=20
> There is also a very high end security approach where we wish to =
ensure strict security on first and every contact and ensure that =
compatible trust anchors are employed.

Those are CAs, but they are not very high end because they are being =
undermined by bad or just unlucky CAs.

>=20
> And there are shades in between.
>=20
>=20
> The first case can be addressed without DNSSEC: Just use encryption =
and don't provide any security signal (e.g. padlock) in primary chrome.
>=20
> The second case needs DNSSEC and more to add trust in.

No, both those cases are improved by DANE and DNSsec.

>=20
> While the precise definition of what 'strict security' turns out to be =
is something we can leave to =3DJeff and co in WebSec. I think we need =
to have a story for how we could present the 'strict' indicator through =
the DNS along with the trust anchor/key restrictions.
>=20
> We may not want to add such capability to the standard immediately, =
but we can have extensibility without impact on what people assert are =
the 'core' use cases. I don't see why we have to accept the idea that =
because some people are only interested in X we should deliberately =
design the spec so that it is only capable of doing X and can never, =
ever be extended to do anything else whatsoever.

I don't think I ever claimed that supporting self signed certs should be =
the *only* requirement . Just that it is a very important use case.  =
Dane is Win/Win for all.

>=20
> The consensus at the Prague meeting was very clearly that DANE needs =
to go back and do use cases and requirements.
>=20
> In my view that means that the room rejected the idea of simply =
writing a set of requirements that precisely describe the capabilities =
of the only proposal that has been allowed to be considered.
>=20
> There was a very strong view in the room that DANE has tried to move =
too fast to propose a solution. Now that may in part be my fault, I have =
been thinking about this particular problem for many years. But I think =
that there was also a feeling that the WG had defined the problem it was =
trying to solve to be the need to use the exact technology being =
proposed rather than look at what a potential adopter of the scheme =
might be looking for.
>=20
>=20
> I agree that your requirement is essential. But I disagree with the =
idea that we should therefore design a spec that stovepipes that single =
requirement.

I think it follows naturally. No stovepiping needed. But that's =
something one can discuss later. The requirement is pretty appealing.

Henry

>=20
>=20
> On Tue, Apr 5, 2011 at 1:34 PM, Ben Laurie <[email-masked]> wrote:
> On 5 April 2011 12:32, Phillip Hallam-Baker <[email-masked]> wrote:
> > This is not a use case approach.
> > What we have is simply a statement of requirements which does not =
have any
> > justification in supporting use cases.
>=20
> This does not alter the fact that 4 is vital :-)
>=20
> >
> > What was asked for were use cases:
> > [U-WS-OPP] Alice finds Sally's server through a search engine. Alice =
prefers
> > to protect her communications with cryptography if this is supported =
by the
> > sever but will communicate in plaintext otherwise.
> > etc. etc.
> >
> >
> > On Tue, Apr 5, 2011 at 12:43 PM, Henry Story =
<[email-masked]>
> > wrote:
> >>
> >> On 5 Apr 2011, at 12:22, Ben Laurie wrote:
> >>
> >> > On 5 April 2011 02:36, Paul Hoffman <[email-masked]> =
wrote:
> >> >>
> >> >> On Apr 4, 2011, at 6:28 PM, Richard L. Barnes wrote:
> >> >>
> >> >>> I kind of agree with Phillip on the deadline.  I would propose =
pushing
> >> >>> it back to the 14th.  My responses:
> >> >>>
> >> >>> 1. It occurs to me that all of the technologies we're talking =
about
> >> >>> entail a domain owner putting something in the DNS to assert =
something about
> >> >>> their domain, which implies some expectation about how the =
client should
> >> >>> process TLS certs.  So it might be useful to phrase use cases =
in terms of
> >> >>> what the domain owner is asserting.  Re-stating Ekr's use cases =
in this
> >> >>> format:
> >> >>>
> >> >>> Use Case 1 "CA Lock":
> >> >>> -- The certificate my server presents in TLS will be chain to =
this CA.
> >> >>> -- Clients should accept a TLS server certificate only if it =
chains to
> >> >>> this CA, but may also require that it chain to an existing =
trust anchor.
> >> >>>
> >> >>> Use Case 2 "Cert Lock":
> >> >>> -- The certificate my server presents in TLS will be this =
specific
> >> >>> certificate.
> >> >>> -- Clients should accept a TLS certificate only if it matches =
this
> >> >>> certificate, but may also require that it chain to an existing =
trust anchor.
> >> >>>
> >> >>> Use Case 3 "New TA":
> >> >>> -- The certificate my server presents in TLS will chain to this =
CA,
> >> >>> which should be treated as a TA.
> >> >>> -- Clients should accept a TLS server certificate if and only =
if it
> >> >>> chains to this CA.
> >> >>>
> >> >>> Use Case 4 "Certificate as Bare Key":
> >> >>> -- The certificate my server presents in TLS will be this =
specific
> >> >>> certificate.
> >> >>> -- Clients should accept a TLS certificate if and only if it =
matches
> >> >>> this certificate.
> >> >>
> >> >> I like the wording in this taxonomy.
> >> >>
> >> >> I consider 3 and 2 to be requirements, 1 to be useful, and 4 to =
be
> >> >> mostly uninteresting if if 3 and/or 2 are implemented.
> >> >
> >> > OTOH, I think 4 is vital - otherwise self-signed certs cannot be =
first
> >> > class citizens.
> >>
> >> Indeed 4 is vital. It is what can create the biggest boost for SSL
> >> deployment ever. As mentioned a month or so ago on this list, MOST =
TLS
> >> endpoints deployed by far are running self signed certificates =
according to
> >> the http://www.eff.org/observatory (3 times more that working TLS
> >> deployments). By making it easy for those to be integrated =
properly,
> >> browsers can show TLS error messages for real cases of fraudulent =
sites,
> >> thereby increasing security dramatically on the web.
> >>
> >> Henry
> >>
> >>
> >> >
> >> >>
> >> >> --Paul Hoffman
> >>
> >> Social Web Architect
> >> http://bblfish.net/
> >>
> >> _______________________________________________
> >> dane mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/dane
> >
> >
> >
> > --
> > Website: http://hallambaker.com/
> >
> >
>=20
>=20
>=20
> --=20
> Website: http://hallambaker.com/
>=20

Social Web Architect
http://bblfish.net/

--Apple-Mail-59--570232588
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><br><div><div>On 5 Apr 2011, at 14:14, Phillip Hallam-Baker =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite">But what are the circumstances in which it is to be =
used?<div><br></div><div>Does Alice have a preference for =
confidentiality or is this essential? Does Alice need to be able to =
verify that encryption is in use? Does Alice need to know anything about =
the accountability, reputation or otherwise of the =
subject?</div></blockquote><div><br></div><div>The only thing that would =
be guaranteed to clients connecting to servers presenting self signed =
certificates matching the cert (or its bare key) in the DNSsec &nbsp;is =
connection to the computer named in the DNS. That is a huge improvement =
for all the servers presenting self signed =
certificates.</div><div><br></div><div>The way I see Dane is that it =
increases trust at every level. It is quite easy to understand why: =
there is now an additional way to confirm =
information:</div><div><br></div><div>&nbsp;- so self signed certs, move =
from just being useful for guaranteeing communication to also =
guaranteeing identity (they move from no padlock to =
padlock)</div><div>&nbsp;- CA signed certs move away from &nbsp;the =
growing danger of irrelevance - since they can be undermined by corrupt =
CAs, aka the weakest link problem - to being verified and supported by =
the DNS</div><div><br></div><div><br></div><br><blockquote =
type=3D"cite"><div><br></div><div>There is a very low end security =
approach where all we want to do is to turn on encryption if possible =
and connect with plaintext otherwise. Alice is willing to accept the =
possibility of a man in the middle approach and is not going to verify =
the status of the connection.</div></blockquote><div><br></div><div>that =
is self signed certs now, running 3 times as many TLS end points as CA =
signed tls endpoints.</div><br><blockquote type=3D"cite">
<div><br></div><div>There is also a very high end security approach =
where we wish to ensure strict security on first and every contact and =
ensure that compatible trust anchors are =
employed.</div></blockquote><div><br></div><div>Those are CAs, but they =
are not very high end because they are being undermined by bad or just =
unlucky CAs.</div><br><blockquote type=3D"cite"><div><br></div><div>And =
there are shades in between.</div>
<div><br></div><div><br></div><div>The first case can be addressed =
without DNSSEC: Just use encryption and don't provide any security =
signal (e.g. padlock) in primary chrome.</div><div><br></div><div>The =
second case needs DNSSEC and more to add trust =
in.</div></blockquote><div><br></div>No, both those cases are improved =
by DANE and DNSsec.<br><br><blockquote =
type=3D"cite"><div><br></div><div>While the precise definition of what =
'strict security' turns out to be is something we can leave to =3DJeff =
and co in WebSec. I think we need to have a story for how we could =
present the 'strict' indicator through the DNS along with the trust =
anchor/key restrictions.</div>
<div><br></div><div>We may not want to add such capability to the =
standard immediately, but we can have extensibility without impact on =
what people assert are the 'core' use cases. I don't see why we have to =
accept the idea that because some people are only interested in X we =
should deliberately design the spec so that it is only capable of doing =
X and can never, ever be extended to do anything else =
whatsoever.</div></blockquote><div><br></div><div>I don't think I ever =
claimed that supporting self signed certs should be the *only* =
requirement . Just that it is a very important use case. &nbsp;Dane is =
Win/Win for all.</div><div><br></div><br><blockquote =
type=3D"cite"><div><font class=3D"Apple-style-span" =
color=3D"#000000"><br></font></div><div>The consensus at the Prague =
meeting was very clearly that DANE needs to go back and do use cases and =
requirements.</div><div><br></div><div>In my view that means that the =
room rejected the idea of simply writing a set of requirements that =
precisely describe the capabilities of the only proposal that has been =
allowed to be considered.</div>
<div><br></div><div>There was a very strong view in the room that DANE =
has tried to move too fast to propose a solution. Now that may in part =
be my fault, I have been thinking about this particular problem for many =
years. But I think that there was also a feeling that the WG had defined =
the problem it was trying to solve to be the need to use the exact =
technology being proposed rather than look at what a potential adopter =
of the scheme might be looking for.</div>
<div><br></div><div><br></div><div>I agree that your requirement is =
essential. But I disagree with the idea that we should therefore design =
a spec that stovepipes that single =
requirement.</div></blockquote><div><br></div><div>I think it follows =
naturally. No stovepiping needed. But that's something one can discuss =
later. The requirement is pretty =
appealing.</div><div><br></div><div><br></div><div>Henry</div><br><blockqu=
ote type=3D"cite"><div><br></div><div><br></div>
<div><div class=3D"gmail_quote">On Tue, Apr 5, 2011 at 1:34 PM, Ben =
Laurie <span dir=3D"ltr">&lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>&gt;</span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">On 5 April 2011 12:32, Phillip Hallam-Baker &lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>&gt; wrote:<br>
&gt; This is not a use case approach.<br>
&gt; What we have is simply a statement of requirements which does not =
have any<br>
&gt; justification in supporting use cases.<br>
<br>
</div>This does not alter the fact that 4 is vital :-)<br>
<div><div></div><div class=3D"h5"><br>
&gt;<br>
&gt; What was asked for were use cases:<br>
&gt; [U-WS-OPP] Alice finds Sally's server through a search engine. =
Alice prefers<br>
&gt; to protect her communications with cryptography if this is =
supported by the<br>
&gt; sever but will communicate in plaintext otherwise.<br>
&gt; etc. etc.<br>
&gt;<br>
&gt;<br>
&gt; On Tue, Apr 5, 2011 at 12:43 PM, Henry Story &lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>&gt;<br=
>
&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; On 5 Apr 2011, at 12:22, Ben Laurie wrote:<br>
&gt;&gt;<br>
&gt;&gt; &gt; On 5 April 2011 02:36, Paul Hoffman &lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>&gt; =
wrote:<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; On Apr 4, 2011, at 6:28 PM, Richard L. Barnes =
wrote:<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; I kind of agree with Phillip on the deadline. =
&nbsp;I would propose pushing<br>
&gt;&gt; &gt;&gt;&gt; it back to the 14th. &nbsp;My responses:<br>
&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; 1. It occurs to me that all of the technologies =
we're talking about<br>
&gt;&gt; &gt;&gt;&gt; entail a domain owner putting something in the DNS =
to assert something about<br>
&gt;&gt; &gt;&gt;&gt; their domain, which implies some expectation about =
how the client should<br>
&gt;&gt; &gt;&gt;&gt; process TLS certs. &nbsp;So it might be useful to =
phrase use cases in terms of<br>
&gt;&gt; &gt;&gt;&gt; what the domain owner is asserting. =
&nbsp;Re-stating Ekr's use cases in this<br>
&gt;&gt; &gt;&gt;&gt; format:<br>
&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; Use Case 1 "CA Lock":<br>
&gt;&gt; &gt;&gt;&gt; -- The certificate my server presents in TLS will =
be chain to this CA.<br>
&gt;&gt; &gt;&gt;&gt; -- Clients should accept a TLS server certificate =
only if it chains to<br>
&gt;&gt; &gt;&gt;&gt; this CA, but may also require that it chain to an =
existing trust anchor.<br>
&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; Use Case 2 "Cert Lock":<br>
&gt;&gt; &gt;&gt;&gt; -- The certificate my server presents in TLS will =
be this specific<br>
&gt;&gt; &gt;&gt;&gt; certificate.<br>
&gt;&gt; &gt;&gt;&gt; -- Clients should accept a TLS certificate only if =
it matches this<br>
&gt;&gt; &gt;&gt;&gt; certificate, but may also require that it chain to =
an existing trust anchor.<br>
&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; Use Case 3 "New TA":<br>
&gt;&gt; &gt;&gt;&gt; -- The certificate my server presents in TLS will =
chain to this CA,<br>
&gt;&gt; &gt;&gt;&gt; which should be treated as a TA.<br>
&gt;&gt; &gt;&gt;&gt; -- Clients should accept a TLS server certificate =
if and only if it<br>
&gt;&gt; &gt;&gt;&gt; chains to this CA.<br>
&gt;&gt; &gt;&gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; Use Case 4 "Certificate as Bare Key":<br>
&gt;&gt; &gt;&gt;&gt; -- The certificate my server presents in TLS will =
be this specific<br>
&gt;&gt; &gt;&gt;&gt; certificate.<br>
&gt;&gt; &gt;&gt;&gt; -- Clients should accept a TLS certificate if and =
only if it matches<br>
&gt;&gt; &gt;&gt;&gt; this certificate.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; I like the wording in this taxonomy.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; I consider 3 and 2 to be requirements, 1 to be useful, =
and 4 to be<br>
&gt;&gt; &gt;&gt; mostly uninteresting if if 3 and/or 2 are =
implemented.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; OTOH, I think 4 is vital - otherwise self-signed certs =
cannot be first<br>
&gt;&gt; &gt; class citizens.<br>
&gt;&gt;<br>
&gt;&gt; Indeed 4 is vital. It is what can create the biggest boost for =
SSL<br>
&gt;&gt; deployment ever. As mentioned a month or so ago on this list, =
MOST TLS<br>
&gt;&gt; endpoints deployed by far are running self signed certificates =
according to<br>
&gt;&gt; the <a href=3D"http://www.eff.org/observatory" =
target=3D"_blank">http://www.eff.org/observatory</a> (3 times more that =
working TLS<br>
&gt;&gt; deployments). By making it easy for those to be integrated =
properly,<br>
&gt;&gt; browsers can show TLS error messages for real cases of =
fraudulent sites,<br>
&gt;&gt; thereby increasing security dramatically on the web.<br>
&gt;&gt;<br>
&gt;&gt; Henry<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; --Paul Hoffman<br>
&gt;&gt;<br>
&gt;&gt; Social Web Architect<br>
&gt;&gt; <a href=3D"http://bblfish.net/" =
target=3D"_blank">http://bblfish.net/</a><br>
&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; dane mailing list<br>
&gt;&gt; <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
&gt;&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/dane" =
target=3D"_blank">https://www.ietf.org/mailman/listinfo/dane</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; Website: <a href=3D"http://hallambaker.com/" =
target=3D"_blank">http://hallambaker.com/</a><br>
&gt;<br>
&gt;<br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: =
<a href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>
</blockquote></div><br><div>
<span class=3D"Apple-style-span" style=3D"border-collapse: separate; =
color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; =
font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; orphans: 2; text-align: =
auto; text-indent: 0px; text-transform: none; white-space: normal; =
widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; "><span class=3D"Apple-style-span" =
style=3D"border-collapse: separate; color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; =
widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; "><div style=3D"word-wrap: =
break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space; "><span class=3D"Apple-style-span" =
style=3D"border-collapse: separate; color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; =
widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; "><div style=3D"word-wrap: =
break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space; "><span class=3D"Apple-style-span" =
style=3D"border-collapse: separate; color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; =
widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; "><div style=3D"word-wrap: =
break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space; "><span class=3D"Apple-style-span" =
style=3D"border-collapse: separate; -webkit-border-horizontal-spacing: =
0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; -webkit-text-decorations-in-effect: none; =
text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; =
orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div =
style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><span class=3D"Apple-style-span" =
style=3D"border-collapse: separate; -webkit-border-horizontal-spacing: =
0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; -webkit-text-decorations-in-effect: none; =
text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; =
orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; =
-webkit-text-decorations-in-effect: none; text-indent: 0px; =
-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; "><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; =
-webkit-text-decorations-in-effect: none; text-indent: 0px; =
-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; "><span><div>Social =
Web Architect<br><a =
href=3D"http://bblfish.net/">http://bblfish.net/</a></div></span></span></=
span></span></div></span></div></span></div></span></div></span></span>
</div>
<br></body></html>=

--Apple-Mail-59--570232588--

From [email-masked]  Tue Apr  5 05:47:50 2011
Date: Tue, 5 Apr 2011 14:49:25 +0200
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

--bcaec50163b95fa32304a02b4e6a
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Apr 5, 2011 at 2:23 PM, Paul Hoffman <[email-masked]> wrote:

>
> On Apr 5, 2011, at 4:32 AM, Phillip Hallam-Baker wrote:
>
> > What we have is simply a statement of requirements which does not have
> any justification in supporting use cases.
>
> We disagree: the requirements listed by various people so far can be mapped
> to some use cases.

And we can derive the requirements from the technical proposal.

The point of use cases is that they are a tool for ensuring that the
proposal does at least bear some resemblance to actual user needs. That
point is lost if the use cases are an output of the process and not an
input.

In practice the approach is almost always bi-directional. I usually find I
am working with a client to determine their use cases by reverse engineering
their technical proposals. But the idea is that you should also work the
other way and look to see what OTHER requirements are driven by those use
cases and need to be met.

> What was asked for were use cases:
>
> Were we in the same meeting? What was asked for was requirements and use
> cases.

See the start of this thread. The WG chairs asked for Use Cases.

"1: We are asking folk to please send any additional use cases to the list
by Thursday April 7th."

> [U-WS-OPP] Alice finds Sally's server through a search engine. Alice
> prefers to protect her communications with cryptography if this is supported
> by the sever but will communicate in plaintext otherwise.
> >
> > etc. etc.
>
> This highlights what will be interesting in the use case scenario: will the
> use cases be driven by the TLS client users or TLS server users?

 Hopefully both.

But there is another complication, use case engineering is not really
designed for use in security applications. So we also need and
Assets-Risks-Threat analysis.

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

--bcaec50163b95fa32304a02b4e6a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Tue, Apr 5, 2011 at 2:23 PM, Paul Hof=
fman <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">paul.ho=
[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im"><br>
On Apr 5, 2011, at 4:32 AM, Phillip Hallam-Baker wrote:<br><br></div><div c=
lass=3D"im">
&gt; What we have is simply a statement of requirements which does not have=
 any justification in supporting use cases.<br>
<br>
</div>We disagree: the requirements listed by various people so far can be =
mapped to some use cases.</blockquote><div><br></div><div>And we can derive=
 the requirements from the technical proposal.</div><div><br></div><div>
The point of use cases is that they are a tool for ensuring that the propos=
al does at least bear some resemblance to actual user needs. That point is =
lost if the use cases are an output of the process and not an input.</div>
<div><br></div><div>In practice the approach is almost always bi-directiona=
l. I usually find I am working with a client to determine their use cases b=
y reverse engineering their technical proposals. But the idea is that you s=
hould also work the other way and look to see what OTHER requirements are d=
riven by those use cases and need to be met.</div>
<div>=A0</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class=3D"=
im">
&gt; What was asked for were use cases:<br>
<br>
</div>Were we in the same meeting? What was asked for was requirements and =
use cases.</blockquote><div><br></div><div>See the start of this thread. Th=
e WG chairs asked for Use Cases.</div><div><br></div><div>&quot;<span class=
=3D"Apple-style-span" style=3D"border-collapse: collapse; color: rgb(51, 51=
, 51); font-family: arial, sans-serif; font-size: 13px; ">1: We are asking =
folk to please send any additional use cases to the list by Thursday April =
7th.&quot;</span>=A0</div>
<meta charset=3D"utf-8"><div><br></div><div><br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex;"><div class=3D"im">
&gt; [U-WS-OPP] Alice finds Sally&#39;s server through a search engine. Ali=
ce prefers to protect her communications with cryptography if this is suppo=
rted by the sever but will communicate in plaintext otherwise.<br>
&gt;<br>
&gt; etc. etc.<br>
<br>
</div>This highlights what will be interesting in the use case scenario: wi=
ll the use cases be driven by the TLS client users or TLS server users?</bl=
ockquote><div><br></div><div>=A0Hopefully both.=A0</div><div><br></div><div=
>
But there is another complication, use case engineering is not really desig=
ned for use in security applications. So we also need and Assets-Risks-Thre=
at analysis.</div></div><br>-- <br>Website: <a href=3D"http://hallambaker.c=
om/">http://hallambaker.com/</a><br>
<br>

--bcaec50163b95fa32304a02b4e6a--

From [email-masked]  Tue Apr  5 06:02:25 2011
From: Paul Hoffman <[email-masked]>
Date: Tue, 5 Apr 2011 06:04:03 -0700
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

On Apr 5, 2011, at 5:49 AM, Phillip Hallam-Baker wrote:

> The point of use cases is that they are a tool for ensuring that the =
proposal does at least bear some resemblance to actual user needs. That =
point is lost if the use cases are an output of the process and not an =
input.

Fully agree.

> In practice the approach is almost always bi-directional. I usually =
find I am working with a client to determine their use cases by reverse =
engineering their technical proposals. But the idea is that you should =
also work the other way and look to see what OTHER requirements are =
driven by those use cases and need to be met.

Yep. We don't do this so well in the IETF, and it would be nice if we =
could do better here.

> > What was asked for were use cases:
>=20
> Were we in the same meeting? What was asked for was requirements and =
use cases.
>=20
> See the start of this thread. The WG chairs asked for Use Cases.
>=20
> "1: We are asking folk to please send any additional use cases to the =
list by Thursday April 7th."=20

Good catch. I was thinking of the discussion in Prague that spurred this =
thread, not the thread itself. Some people kept vehemently saying =
"requirements", and some also said "use cases".

> > [U-WS-OPP] Alice finds Sally's server through a search engine. Alice =
prefers to protect her communications with cryptography if this is =
supported by the sever but will communicate in plaintext otherwise.
> >
> > etc. etc.
>=20
> This highlights what will be interesting in the use case scenario: =
will the use cases be driven by the TLS client users or TLS server =
users?
>=20
>  Hopefully both.=20

I'm not sure of that, but that's because the use cases I'm thinking of =
are all for the TLS server admins. It would be good to see both so we =
can judge.

--Paul Hoffman

From [email-masked]  Tue Apr  5 06:13:57 2011
From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 5 Apr 2011 15:15:37 +0200
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

5 apr 2011 kl. 15.04 skrev Paul Hoffman:

> On Apr 5, 2011, at 5:49 AM, Phillip Hallam-Baker wrote:
>=20
>> The point of use cases is that they are a tool for ensuring that the =
proposal does at least bear some resemblance to actual user needs. That =
point is lost if the use cases are an output of the process and not an =
input.
>=20
> Fully agree.
>=20
>> In practice the approach is almost always bi-directional. I usually =
find I am working with a client to determine their use cases by reverse =
engineering their technical proposals. But the idea is that you should =
also work the other way and look to see what OTHER requirements are =
driven by those use cases and need to be met.
>=20
> Yep. We don't do this so well in the IETF, and it would be nice if we =
could do better here.
>=20
>>> What was asked for were use cases:
>>=20
>> Were we in the same meeting? What was asked for was requirements and =
use cases.
>>=20
>> See the start of this thread. The WG chairs asked for Use Cases.
>>=20
>> "1: We are asking folk to please send any additional use cases to the =
list by Thursday April 7th."=20
>=20
> Good catch. I was thinking of the discussion in Prague that spurred =
this thread, not the thread itself. Some people kept vehemently saying =
"requirements", and some also said "use cases".
>=20
>>> [U-WS-OPP] Alice finds Sally's server through a search engine. Alice =
prefers to protect her communications with cryptography if this is =
supported by the sever but will communicate in plaintext otherwise.
>>>=20
>>> etc. etc.
>>=20
>> This highlights what will be interesting in the use case scenario: =
will the use cases be driven by the TLS client users or TLS server =
users?
>>=20
>> Hopefully both.=20
>=20
> I'm not sure of that, but that's because the use cases I'm thinking of =
are all for the TLS server admins. It would be good to see both so we =
can judge.
>=20
In the SIP world, it's actually both.

Paul's phone client wants to place a secure call to Philip. Philips' =
proxy is the first server, Philip's phone is the next one, contacted by =
the proxy. After initial rendez-vous using the SIP proxy the SIP phones =
may connect p2p, where Philip's phone connect to Paul's phone, whose =
phone is now a server.

I can't get my head around where DANE comes into the picture after step =
one - where Paul use Philip's SIP uri domain to get the cacert for that =
domain or the actual cert for that server (or fingerprints). If DANE has =
a use case in step two - where the proxy contacts a phone or step three, =
where Philips phone contacts Pauls phone directly. If step three is =
using a domain contact URI, DANE has a role. In SIP lingo, that would be =
a gruu.

Just to get a use case which is not clearly client-server following the =
HTTP model.

/O=

From [email-masked]  Tue Apr  5 06:15:28 2011
Date: Tue, 5 Apr 2011 15:17:03 +0200
From: Phillip Hallam-Baker <[email-masked]>
To: Henry Story <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

--20cf304346e42d729404a02bb19f
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Apr 5, 2011 at 2:36 PM, Henry Story <[email-masked]> wrote:

>
> On 5 Apr 2011, at 14:14, Phillip Hallam-Baker wrote:
>
> But what are the circumstances in which it is to be used?
>
> Does Alice have a preference for confidentiality or is this essential? Does
> Alice need to be able to verify that encryption is in use? Does Alice need
> to know anything about the accountability, reputation or otherwise of the
> subject?
>
>
> The only thing that would be guaranteed to clients connecting to servers
> presenting self signed certificates matching the cert (or its bare key) in
> the DNSsec  is connection to the computer named in the DNS. That is a huge
> improvement for all the servers presenting self signed certificates.
>
> The way I see Dane is that it increases trust at every level. It is quite
> easy to understand why: there is now an additional way to confirm
> information:
>
>  - so self signed certs, move from just being useful for guaranteeing
> communication to also guaranteeing identity (they move from no padlock to
> padlock)
>

I don't think that is justified. We should eliminate the padlock entirely
for all classes of certificate.

The user interprets the padlock icon as proof that they are safe, that the
party they are dealing with is trustworthy.

Owning a DNS name does not make you a good person. So I can't see a
justification for showing the padlock for any Domain Validated certificate.

The user is not going to check the status of the connection in any case, so
why provide information that is only going to confuse the user and be
misinterpreted?

There is a very low end security approach where all we want to do is to turn
> on encryption if possible and connect with plaintext otherwise. Alice is
> willing to accept the possibility of a man in the middle approach and is not
> going to verify the status of the connection.
>
>
> that is self signed certs now, running 3 times as many TLS end points as CA
> signed tls endpoints.
>

How many of those are mail servers?

What is the desired fallback strategy?

Let us say that Alice's mail server is connecting to Bob's mail server to
deliver mail and that Mallet is posing as a man in the middle and presents a
non compliant cert. Note that neither user is present during the exchange
and so we can't fallback to asking the user what to do. What is your
preferred outcome:

1) Alice's mail server refuses to deliver mail to Bob's mail server?

2) Alice's mail server uses the bogus certificate and delivers the mail
anyway?

3) Alice's mail server delivers the mail en-clair?

Now I would guess that the preferred outcome is (1) but none of the outcomes
are exactly good and the outcome that the programmers are likely to code is
probably (3) which is the worst of the lot.

Under the existing DANE draft, Mallet can force outcome #3 by simply
stripping out the STARTTLS request which is (inevitably) sent before we have
authentication.

There are in fact two downgrade attacks possible here:

1) Force the user to accept a bogus certificate

2) Force the user to accept the communication en-clair.

Attack #2 dominates attack #1.

I agree that we should address #1. But we achieve no security benefit unless
we also address #2.

The first case can be addressed without DNSSEC: Just use encryption and
> don't provide any security signal (e.g. padlock) in primary chrome.
>
> The second case needs DNSSEC and more to add trust in.
>
>
> No, both those cases are improved by DANE and DNSsec.
>

Not unless you also address the protocol downgrade attack.

If you allow the SSL stripping downgrade attack, preventing the use of a
bogus cert is irrelevant for Internet services and of marginal utility for
Web browsing transactions.

The user is going to ignore the padlock and click through any warning
screen.

The only case where I can see a value to using DNSSEC here is if we start by
telling the client that TLS is always available at the genuine service.

If there is a mechanism that allows the client to verify the use of TLS
without user involvement, the padlock icon becomes unnecessary.

While the precise definition of what 'strict security' turns out to be is
> something we can leave to =Jeff and co in WebSec. I think we need to have a
> story for how we could present the 'strict' indicator through the DNS along
> with the trust anchor/key restrictions.
>
> We may not want to add such capability to the standard immediately, but we
> can have extensibility without impact on what people assert are the 'core'
> use cases. I don't see why we have to accept the idea that because some
> people are only interested in X we should deliberately design the spec so
> that it is only capable of doing X and can never, ever be extended to do
> anything else whatsoever.
>
>
> I don't think I ever claimed that supporting self signed certs should be
> the *only* requirement . Just that it is a very important use case.
>

I don't think it is useful to get back into an argument of who said what or
argued what.

>  Dane is Win/Win for all.
>

Hopefully not. I would hope that a security protocol is a lose for Mallet.

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

--20cf304346e42d729404a02bb19f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Tue, Apr 5, 2011 at 2:36 PM, Henry St=
ory <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">henry.=
[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style=3D"word-wrap:break-word"><br><div><div class=3D"im"><div>On 5 Ap=
r 2011, at 14:14, Phillip Hallam-Baker wrote:</div><br><blockquote type=3D"=
cite">But what are the circumstances in which it is to be used?<div><br></d=
iv>
<div>Does Alice have a preference for confidentiality or is this essential?=
 Does Alice need to be able to verify that encryption is in use? Does Alice=
 need to know anything about the accountability, reputation or otherwise of=
 the subject?</div>
</blockquote><div><br></div></div><div>The only thing that would be guarant=
eed to clients connecting to servers presenting self signed certificates ma=
tching the cert (or its bare key) in the DNSsec =A0is connection to the com=
puter named in the DNS. That is a huge improvement for all the servers pres=
enting self signed certificates.</div>
<div><br></div><div>The way I see Dane is that it increases trust at every =
level. It is quite easy to understand why: there is now an additional way t=
o confirm information:</div><div><br></div><div>=A0- so self signed certs, =
move from just being useful for guaranteeing communication to also guarante=
eing identity (they move from no padlock to padlock)</div>
</div></div></blockquote><div><br></div><div>I don&#39;t think that is just=
ified. We should eliminate the padlock entirely for all classes of certific=
ate.=A0</div><div><br></div><div>The user interprets the padlock icon as pr=
oof that they are safe, that the party they are dealing with is trustworthy=
.</div>
<div><br></div><div>Owning a DNS name does not make you a good person. So I=
 can&#39;t see a justification for showing the padlock for any Domain Valid=
ated certificate.</div><div><br></div><div>The user is not going to check t=
he status of the connection in any case, so why provide information that is=
 only going to confuse the user and be misinterpreted?</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex;"><div style=3D"word-wrap:brea=
k-word"><div><div class=3D"im"><blockquote type=3D"cite"><div>There is a ve=
ry low end security approach where all we want to do is to turn on encrypti=
on if possible and connect with plaintext otherwise. Alice is willing to ac=
cept the possibility of a man in the middle approach and is not going to ve=
rify the status of the connection.</div>
</blockquote><div><br></div></div><div>that is self signed certs now, runni=
ng 3 times as many TLS end points as CA signed tls endpoints.</div></div></=
div></blockquote><div><br></div><div>How many of those are mail servers?=A0=
</div>
<div><br></div><div>What is the desired fallback strategy?</div><div><br></=
div><div><br></div><div>Let us say that Alice&#39;s mail server is connecti=
ng to Bob&#39;s mail server to deliver mail and that Mallet is posing as a =
man in the middle and presents a non compliant cert. Note that neither user=
 is present during the exchange and so we can&#39;t fallback to asking the =
user what to do. What is your preferred outcome:</div>
<div><br></div><div>1) Alice&#39;s mail server refuses to deliver mail to B=
ob&#39;s mail server?</div><div><br></div><div>2) Alice&#39;s mail server u=
ses the bogus certificate and delivers the mail anyway?</div><div><br></div=
>
<div>3) Alice&#39;s mail server delivers the mail en-clair?</div><div><br><=
/div><div><br></div><div>Now I would guess that the preferred outcome is (1=
) but none of the outcomes are exactly good and the outcome that the progra=
mmers are likely to code is probably (3) which is the worst of the lot.</di=
v>
<div><br></div><div>Under the existing DANE draft, Mallet can force outcome=
 #3 by simply stripping out the STARTTLS request which is (inevitably) sent=
 before we have authentication.</div><div><br></div><div><br></div><div>
There are in fact two downgrade attacks possible here:</div><div><br></div>=
<div>1) Force the user to accept a bogus certificate</div><div><br></div><d=
iv>2) Force the user to accept the communication en-clair.</div><div><br>
</div><div>Attack #2 dominates attack #1.=A0</div><div><br></div><div>I agr=
ee that we should address #1. But we achieve no security benefit unless we =
also address #2.=A0</div><div><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style=3D"word-wrap:break-word"><div><div class=3D"im"><blockquote type=
=3D"cite"><div>The first case can be addressed without DNSSEC: Just use enc=
ryption and don&#39;t provide any security signal (e.g. padlock) in primary=
 chrome.</div>
<div><br></div><div>The second case needs DNSSEC and more to add trust in.<=
/div></blockquote><div><br></div></div>No, both those cases are improved by=
 DANE and DNSsec.</div></div></blockquote><div><br></div><div>Not unless yo=
u also address the protocol downgrade attack.</div>
<div><br></div><div>If you allow the SSL stripping downgrade attack, preven=
ting the use of a bogus cert is irrelevant for Internet services and of mar=
ginal utility for Web browsing transactions.</div><div><br></div><div>The u=
ser is going to ignore the padlock and click through any warning screen.</d=
iv>
<div><br></div><div><br></div><div>The only case where I can see a value to=
 using DNSSEC here is if we start by telling the client that TLS is always =
available at the genuine service.=A0</div><div><br></div><div>If there is a=
 mechanism that allows the client to verify the use of TLS without user inv=
olvement, the padlock icon becomes unnecessary.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex;"><div style=3D"word-wrap:brea=
k-word"><div><div class=3D"im"><blockquote type=3D"cite"><div>While the pre=
cise definition of what &#39;strict security&#39; turns out to be is someth=
ing we can leave to =3DJeff and co in WebSec. I think we need to have a sto=
ry for how we could present the &#39;strict&#39; indicator through the DNS =
along with the trust anchor/key restrictions.</div>

<div><br></div><div>We may not want to add such capability to the standard =
immediately, but we can have extensibility without impact on what people as=
sert are the &#39;core&#39; use cases. I don&#39;t see why we have to accep=
t the idea that because some people are only interested in X we should deli=
berately design the spec so that it is only capable of doing X and can neve=
r, ever be extended to do anything else whatsoever.</div>
</blockquote><div><br></div></div><div>I don&#39;t think I ever claimed tha=
t supporting self signed certs should be the *only* requirement . Just that=
 it is a very important use case.</div></div></div></blockquote><div><br>
</div><div>I don&#39;t think it is useful to get back into an argument of w=
ho said what or argued what.</div><div><br></div><div>=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex;">
<div style=3D"word-wrap:break-word"><div><div> =A0Dane is Win/Win for all.<=
/div></div></div></blockquote><div><br></div><div>Hopefully not. I would ho=
pe that a security protocol is a lose for Mallet.</div><div><br></div><div>
<br></div></div>-- <br>Website: <a href=3D"http://hallambaker.com/">http://=
hallambaker.com/</a><br><br>

--20cf304346e42d729404a02bb19f--

From [email-masked]  Tue Apr  5 06:24:56 2011
From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 5 Apr 2011 09:26:34 -0400
To: "Olle E. Johansson" <[email-masked]>
Cc: Paul Hoffman <[email-masked]>, [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

>>>> [U-WS-OPP] Alice finds Sally's server through a search engine. =
Alice prefers to protect her communications with cryptography if this is =
supported by the sever but will communicate in plaintext otherwise.
>>>>=20
>>>> etc. etc.
>>>=20
>>> This highlights what will be interesting in the use case scenario: =
will the use cases be driven by the TLS client users or TLS server =
users?
>>>=20
>>> Hopefully both.=20
>>=20
>> I'm not sure of that, but that's because the use cases I'm thinking =
of are all for the TLS server admins. It would be good to see both so we =
can judge.
>>=20
> In the SIP world, it's actually both.
>=20
> Paul's phone client wants to place a secure call to Philip. Philips' =
proxy is the first server, Philip's phone is the next one, contacted by =
the proxy. After initial rendez-vous using the SIP proxy the SIP phones =
may connect p2p, where Philip's phone connect to Paul's phone, whose =
phone is now a server.
>=20
> I can't get my head around where DANE comes into the picture after =
step one - where Paul use Philip's SIP uri domain to get the cacert for =
that domain or the actual cert for that server (or fingerprints). If =
DANE has a use case in step two - where the proxy contacts a phone or =
step three, where Philips phone contacts Pauls phone directly. If step =
three is using a domain contact URI, DANE has a role. In SIP lingo, that =
would be a gruu.
>=20
> Just to get a use case which is not clearly client-server following =
the HTTP model.
>=20
> /O

On the one hand, I think this case is pretty clearly out of the initial =
scope of the working group, which is focused on single TLS connections.  =
On the other hand, it might be addressed at least in part by Paul's =
S/MIME draft, since SIP identifiers and email identifiers have basically =
the same form.

--Richard

From [email-masked]  Tue Apr  5 06:30:56 2011
Date: Tue, 5 Apr 2011 15:32:32 +0200
From: Phillip Hallam-Baker <[email-masked]>
To: Florian Weimer <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Objective: Restrictive versus Supplementary Models

--20cf304346e489986c04a02be875
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Apr 5, 2011 at 1:13 PM, Florian Weimer <[email-masked]> wrote:

> * Eric Rescorla:
>
> > In the second case, the intention is to allow clients to effectively
> > bypass the existing trust hierarchy by injecting a new trust point
> > via the DNS. Thus, either the certificate validation simply will not
> > be used at all (in the case where a terminal certificate is
> > provided) or will be used up to a newly inserted trust anchor. In
> > either case, the presumptive rationale here is that it's too
> > inconvenient to deal with the existing CAs and that DANE will be
> > easier.  This version of DANE *does* need to be protected via DNSSEC
> > because tampering with these records allows the attacker to
> > impersonate the authenticating party to the relying party.
>
> If you switch HTTPS transparently (meaning: no UI indicators, secure
> cookies are not sent, SOP checks run against :80 instead of :443),
> then you don't need DNSSEC.
>
> I'm pretty sure it's politically and technically infeasible to
> introduce DNSSEC-driven UI changes on a larger scale, so I doubt that
> any non-transparent approach will fly.
>

The trend is certainly to deprecate providing a security signal to indicate
use of DV certs. The only reason it is done today is that this is the legacy
approach and the current protocols require the user to check that TLS is in
use.

So I really can't see how an argument of the form 'DNSSEC validation is just
as good as DV, therefore it should get a padlock icon' is going to get
traction with the browser providers.

The question they are going to ask is 'what level of security notification
is justified and/or necessary'.

Anyone care to argue that mere possession of a DNS domain makes you
trustworthy?

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

--20cf304346e489986c04a02be875
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Tue, Apr 5, 2011 at 1:13 PM, Florian =
Weimer <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">fweimer@bfk.=
de</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
* Eric Rescorla:<br>
<div class=3D"im"><br>
&gt; In the second case, the intention is to allow clients to effectively<b=
r>
&gt; bypass the existing trust hierarchy by injecting a new trust point<br>
&gt; via the DNS. Thus, either the certificate validation simply will not<b=
r>
&gt; be used at all (in the case where a terminal certificate is<br>
&gt; provided) or will be used up to a newly inserted trust anchor. In<br>
&gt; either case, the presumptive rationale here is that it&#39;s too<br>
&gt; inconvenient to deal with the existing CAs and that DANE will be<br>
&gt; easier. =A0This version of DANE *does* need to be protected via DNSSEC=
<br>
&gt; because tampering with these records allows the attacker to<br>
&gt; impersonate the authenticating party to the relying party.<br>
<br>
</div>If you switch HTTPS transparently (meaning: no UI indicators, secure<=
br>
cookies are not sent, SOP checks run against :80 instead of :443),<br>
then you don&#39;t need DNSSEC.<br>
<br>
I&#39;m pretty sure it&#39;s politically and technically infeasible to<br>
introduce DNSSEC-driven UI changes on a larger scale, so I doubt that<br>
any non-transparent approach will fly.<br></blockquote><div><br></div><div>=
The trend is certainly to deprecate providing a security signal to indicate=
 use of DV certs. The only reason it is done today is that this is the lega=
cy approach and the current protocols require the user to check that TLS is=
 in use.</div>
<div><br></div><div>So I really can&#39;t see how an argument of the form &=
#39;DNSSEC validation is just as good as DV, therefore it should get a padl=
ock icon&#39; is going to get traction with the browser providers.</div>
<div><br></div><div>The question they are going to ask is &#39;what level o=
f security notification is justified and/or necessary&#39;.=A0</div><div><b=
r></div><div><br></div><div>Anyone care to argue that mere possession of a =
DNS domain makes you trustworthy?</div>
</div><div><br></div><div><br></div>-- <br>Website: <a href=3D"http://halla=
mbaker.com/">http://hallambaker.com/</a><br><br>

--20cf304346e489986c04a02be875--

From [email-masked]  Tue Apr  5 07:06:02 2011
From: Matt McCutchen <[email-masked]>
To: Florian Weimer <[email-masked]>
Date: Tue, 05 Apr 2011 10:07:35 -0400
Cc: [email-masked]
Subject: Re: [dane] Objective: Restrictive versus Supplementary Models

On Tue, 2011-04-05 at 11:13 +0000, Florian Weimer wrote:
> If you switch HTTPS transparently (meaning: no UI indicators, secure
> cookies are not sent, SOP checks run against :80 instead of :443),
> then you don't need DNSSEC.

Indeed, this could be done, but I want server-authenticated connections.

> I'm pretty sure it's politically and technically infeasible to
> introduce DNSSEC-driven UI changes on a larger scale, so I doubt that
> any non-transparent approach will fly.

Technically, the existing Firefox blue badge works with my modified NSS
(https://mattmccutchen.net/cryptid/#nss-dane) if you ignore the
unvalidated certificate details.  Politically, I don't know, but I would
use such a browser.

-- 
Matt

From [email-masked]  Tue Apr  5 07:08:53 2011
From: Henry Story <[email-masked]>
Date: Tue, 5 Apr 2011 16:10:21 +0200
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

--Apple-Mail-60--564608836
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On 5 Apr 2011, at 15:17, Phillip Hallam-Baker wrote:
> On Tue, Apr 5, 2011 at 2:36 PM, Henry Story <[email-masked]> =
wrote:
>=20
> On 5 Apr 2011, at 14:14, Phillip Hallam-Baker wrote:
>=20
>> But what are the circumstances in which it is to be used?
>>=20
>> Does Alice have a preference for confidentiality or is this =
essential? Does Alice need to be able to verify that encryption is in =
use? Does Alice need to know anything about the accountability, =
reputation or otherwise of the subject?
>=20
> The only thing that would be guaranteed to clients connecting to =
servers presenting self signed certificates matching the cert (or its =
bare key) in the DNSsec  is connection to the computer named in the DNS. =
That is a huge improvement for all the servers presenting self signed =
certificates.
>=20
> The way I see Dane is that it increases trust at every level. It is =
quite easy to understand why: there is now an additional way to confirm =
information:
>=20
>  - so self signed certs, move from just being useful for guaranteeing =
communication to also guaranteeing identity (they move from no padlock =
to padlock)
>=20
> I don't think that is justified. We should eliminate the padlock =
entirely for all classes of certificate.=20
>=20
> The user interprets the padlock icon as proof that they are safe, that =
the party they are dealing with is trustworthy.

I don't think it is up to this group to work on the semantics of the =
padlock frankly. Those are UI issues to be discussed by another group, =
browser vendors in particular.=20

> Owning a DNS name does not make you a good person.

Owning a multi billion dollar company that can afford a EV cert does not =
do that either. I think we have seen plenty of examples of that =
recently. Certification does not guarantee moral behavior, just =
identity. With DNS & Dane it is domain-name identity. CA's can then add =
extra information and certify additional properties.

> So I can't see a justification for showing the padlock for any Domain =
Validated certificate.
>=20
> The user is not going to check the status of the connection in any =
case, so why provide information that is only going to confuse the user =
and be misinterpreted?

Again we should not discuss UI elements here, unless we want to get =
completely sidetracked.

You may not see the value of knowing you reached the site you clicked =
on, but I and many people do.
I would love to know when I reach those 10s of millions of sites that =
had self signed certs that they are the sites that I was intending to =
connect to. I would love to know that I reached the web page that the =
site I was on had linked to. I would put a padlock there, you may not. =
But the use case is there and it is the obvious thing one can use Dane =
for.

>=20
>> There is a very low end security approach where all we want to do is =
to turn on encryption if possible and connect with plaintext otherwise. =
Alice is willing to accept the possibility of a man in the middle =
approach and is not going to verify the status of the connection.
>=20
> that is self signed certs now, running 3 times as many TLS end points =
as CA signed tls endpoints.
>=20
> How many of those are mail servers?=20

You can go to the EFF observatory page, download the database of the =
observatory and answer all those
questions yourself. They explain how to do this here:

  http://www.youtube.com/watch?v=3DVUKCDm04AqI

>=20
> What is the desired fallback strategy?
>=20
>=20
> Let us say that Alice's mail server is connecting to Bob's mail server =
to deliver mail and that Mallet is posing as a man in the middle and =
presents a non compliant cert. Note that neither user is present during =
the exchange and so we can't fallback to asking the user what to do. =
What is your preferred outcome:
>=20
> 1) Alice's mail server refuses to deliver mail to Bob's mail server?
>=20
> 2) Alice's mail server uses the bogus certificate and delivers the =
mail anyway?
>=20
> 3) Alice's mail server delivers the mail en-clair?

My question is: how is it done now?  In what percentage of case do =
people choose which option? Then you will find that in a very large =
percentage of cases security is not added at all because the simple =
solution of self signed certs is not available. Make that possible and =
easy and you increase the space in which secure behavior is possible.

With Dane you just increase the security of those servers that wish to =
be secure. You increase the scope of secure behavior. You make secure =
behavior cheaper, and so more widely used, which creates network =
effects.

>  would guess that the preferred outcome is (1) but none of the =
outcomes are exactly good and the outcome that the programmers are =
likely to code is probably (3) which is the worst of the lot.
>=20
> Under the existing DANE draft, Mallet can force outcome #3 by simply =
stripping out the STARTTLS request which is (inevitably) sent before we =
have authentication.
>=20
> There are in fact two downgrade attacks possible here:
>=20
> 1) Force the user to accept a bogus certificate
>=20
> 2) Force the user to accept the communication en-clair.
>=20
> Attack #2 dominates attack #1.=20
>=20
> I agree that we should address #1. But we achieve no security benefit =
unless we also address #2.=20

Ok, I don't see why allowing Dane to publish self signed certs affects =
this at all? Does it not make things easier? In the HTTPS case it =
clearly does.

>=20
>> The first case can be addressed without DNSSEC: Just use encryption =
and don't provide any security signal (e.g. padlock) in primary chrome.
>>=20
>> The second case needs DNSSEC and more to add trust in.
>=20
> No, both those cases are improved by DANE and DNSsec.
>=20
> Not unless you also address the protocol downgrade attack.
>=20
> If you allow the SSL stripping downgrade attack, preventing the use of =
a bogus cert is irrelevant for Internet services and of marginal utility =
for Web browsing transactions.
>=20
> The user is going to ignore the padlock and click through any warning =
screen.

There will be a lot less warning screens in his day to day experience, =
and so it will be possible to teach the user to take  failures more =
seriously. Currently there are many cases where users are taught to =
click through the warning screen, by knowledgeable people. This can =
become a habit. Allowing self signed certs to be published in Dane will =
make it easy to tell people: why don't you just publish your self signed =
cert in DNS? If you can't even bother to do that, then why should I take =
your site/service seriously.

>=20
> The only case where I can see a value to using DNSSEC here is if we =
start by telling the client that TLS is always available at the genuine =
service.

That is indeed the idea: make a web that is very much more widely TLS =
based. Increase the usage of TLS 100 fold or more. Make it the default. =
Why not? Google are doing it now, Facebook is. Soon everyone will. After =
all any web page with links to other sites that is not protected is a =
danger, because it could be man in the middled to rewrite URLs and point =
people to the wrong site.

>  If there is a mechanism that allows the client to verify the use of =
TLS without user involvement, the padlock icon becomes unnecessary.

Again that is a UI issue, which is exceedingly important, but not one we =
should concern ourselves here. Assume UI specialists, graphics artists, =
and people with a humanities background will do their job.

>=20
>> While the precise definition of what 'strict security' turns out to =
be is something we can leave to =3DJeff and co in WebSec. I think we =
need to have a story for how we could present the 'strict' indicator =
through the DNS along with the trust anchor/key restrictions.
>>=20
>> We may not want to add such capability to the standard immediately, =
but we can have extensibility without impact on what people assert are =
the 'core' use cases. I don't see why we have to accept the idea that =
because some people are only interested in X we should deliberately =
design the spec so that it is only capable of doing X and can never, =
ever be extended to do anything else whatsoever.
>=20
> I don't think I ever claimed that supporting self signed certs should =
be the *only* requirement . Just that it is a very important use case.
>=20
> I don't think it is useful to get back into an argument of who said =
what or argued what.
>=20
> =20
>  Dane is Win/Win for all.
>=20
> Hopefully not. I would hope that a security protocol is a lose for =
Mallet.

I seem to have hit a nerve.

Henry

>=20
>=20
> --=20
> Website: http://hallambaker.com/
>=20

Social Web Architect
http://bblfish.net/

--Apple-Mail-60--564608836
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><br><div><div>On 5 Apr 2011, at 15:17, Phillip Hallam-Baker =
wrote:</div><blockquote type=3D"cite"><div class=3D"gmail_quote">On Tue, =
Apr 5, 2011 at 2:36 PM, Henry Story <span dir=3D"ltr">&lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>&gt;</s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style=3D"word-wrap:break-word"><br><div><div class=3D"im"><div>On 5 =
Apr 2011, at 14:14, Phillip Hallam-Baker wrote:</div><br><blockquote =
type=3D"cite">But what are the circumstances in which it is to be =
used?<div><br></div>
<div>Does Alice have a preference for confidentiality or is this =
essential? Does Alice need to be able to verify that encryption is in =
use? Does Alice need to know anything about the accountability, =
reputation or otherwise of the subject?</div>
</blockquote><div><br></div></div><div>The only thing that would be =
guaranteed to clients connecting to servers presenting self signed =
certificates matching the cert (or its bare key) in the DNSsec &nbsp;is =
connection to the computer named in the DNS. That is a huge improvement =
for all the servers presenting self signed certificates.</div>
<div><br></div><div>The way I see Dane is that it increases trust at =
every level. It is quite easy to understand why: there is now an =
additional way to confirm information:</div><div><br></div><div>&nbsp;- =
so self signed certs, move from just being useful for guaranteeing =
communication to also guaranteeing identity (they move from no padlock =
to padlock)</div>
</div></div></blockquote><div><br></div><div>I don't think that is =
justified. We should eliminate the padlock entirely for all classes of =
certificate.&nbsp;</div><div><br></div><div>The user interprets the =
padlock icon as proof that they are safe, that the party they are =
dealing with is trustworthy.</div></div></blockquote><div><br></div>I =
don't think it is up to this group to work on the semantics of the =
padlock frankly. Those are UI issues to be discussed by another group, =
browser vendors in particular.&nbsp;<br><br><blockquote type=3D"cite"><div=
 class=3D"gmail_quote"><div>Owning a DNS name does not make you a good =
person. </div></div></blockquote><div><br></div><div>Owning a multi =
billion dollar company that can afford a EV cert does not do that =
either. I think we have seen plenty of examples of that recently. =
Certification does not guarantee moral behavior, just identity. With DNS =
&amp; Dane it is domain-name identity. CA's can then add extra =
information and certify additional properties.</div><br><blockquote =
type=3D"cite"><div class=3D"gmail_quote"><div>So I can't see a =
justification for showing the padlock for any Domain Validated =
certificate.</div><div><br></div><div>The user is not going to check the =
status of the connection in any case, so why provide information that is =
only going to confuse the user and be =
misinterpreted?</div></div></blockquote><div><br></div><div>Again we =
should not discuss UI elements here, unless we want to get completely =
sidetracked.</div><div><br></div><div>You may not see the value of =
knowing you reached the site you clicked on, but I and many people =
do.</div><div>I would love to know when I reach those 10s of millions of =
sites that had self signed certs that they are the sites that I was =
intending to connect to. I would love to know that I reached the web =
page that the site I was on had linked to. I would put a padlock there, =
you may not. But the use case is there and it is the obvious thing one =
can use Dane for.</div><div><br></div><br><blockquote type=3D"cite"><div =
class=3D"gmail_quote">
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex;"><div =
style=3D"word-wrap:break-word"><div><div class=3D"im"><blockquote =
type=3D"cite"><div>There is a very low end security approach where all =
we want to do is to turn on encryption if possible and connect with =
plaintext otherwise. Alice is willing to accept the possibility of a man =
in the middle approach and is not going to verify the status of the =
connection.</div>
</blockquote><div><br></div></div><div>that is self signed certs now, =
running 3 times as many TLS end points as CA signed tls =
endpoints.</div></div></div></blockquote><div><br></div><div>How many of =
those are mail =
servers?&nbsp;</div></div></blockquote><div><br></div><div>You can go to =
the EFF observatory page, download the database of the observatory and =
answer all those</div><div>questions yourself. They explain how to do =
this here:</div><div><br></div><div>&nbsp;&nbsp;<a =
href=3D"http://www.youtube.com/watch?v=3DVUKCDm04AqI">http://www.youtube.c=
om/watch?v=3DVUKCDm04AqI</a></div><div><br></div><blockquote =
type=3D"cite"><div class=3D"gmail_quote">
<div><br></div><div>What is the desired fallback =
strategy?</div><div><br></div><div><br></div><div>Let us say that =
Alice's mail server is connecting to Bob's mail server to deliver mail =
and that Mallet is posing as a man in the middle and presents a non =
compliant cert. Note that neither user is present during the exchange =
and so we can't fallback to asking the user what to do. What is your =
preferred outcome:</div>
<div><br></div><div>1) Alice's mail server refuses to deliver mail to =
Bob's mail server?</div><div><br></div><div>2) Alice's mail server uses =
the bogus certificate and delivers the mail anyway?</div><div><br></div>
<div>3) Alice's mail server delivers the mail =
en-clair?</div></div></blockquote><div><br></div><div>My question is: =
how is it done now? &nbsp;In what percentage of case do people choose =
which option? Then you will find that in a very large percentage of =
cases security is not added at all because the simple solution of self =
signed certs is not available. Make that possible and easy and you =
increase the space in which secure behavior is =
possible.</div><div><br></div><div>With Dane you just increase the =
security of those servers that wish to be secure. You increase the scope =
of secure behavior. You make secure behavior cheaper, and so more widely =
used, which creates network effects.</div><br><blockquote =
type=3D"cite"><div class=3D"gmail_quote"><div>&nbsp;would guess that the =
preferred outcome is (1) but none of the outcomes are exactly good and =
the outcome that the programmers are likely to code is probably (3) =
which is the worst of the lot.</div>
<div><br></div><div>Under the existing DANE draft, Mallet can force =
outcome #3 by simply stripping out the STARTTLS request which is =
(inevitably) sent before we have =
authentication.</div><div><br></div><div>
There are in fact two downgrade attacks possible =
here:</div><div><br></div><div>1) Force the user to accept a bogus =
certificate</div><div><br></div><div>2) Force the user to accept the =
communication en-clair.</div><div><br>
</div><div>Attack #2 dominates attack =
#1.&nbsp;</div><div><br></div><div>I agree that we should address #1. =
But we achieve no security benefit unless we also address =
#2.&nbsp;</div></div></blockquote><div><br></div><div>Ok, I don't see =
why allowing Dane to publish self signed certs affects this at all? Does =
it not make things easier? In the HTTPS case it clearly =
does.</div><div><br></div><blockquote type=3D"cite"><div =
class=3D"gmail_quote"><div><br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex;">
<div style=3D"word-wrap:break-word"><div><div class=3D"im"><blockquote =
type=3D"cite"><div>The first case can be addressed without DNSSEC: Just =
use encryption and don't provide any security signal (e.g. padlock) in =
primary chrome.</div>
<div><br></div><div>The second case needs DNSSEC and more to add trust =
in.</div></blockquote><div><br></div></div>No, both those cases are =
improved by DANE and =
DNSsec.</div></div></blockquote><div><br></div><div>Not unless you also =
address the protocol downgrade attack.</div>
<div><br></div><div>If you allow the SSL stripping downgrade attack, =
preventing the use of a bogus cert is irrelevant for Internet services =
and of marginal utility for Web browsing =
transactions.</div><div><br></div><div>The user is going to ignore the =
padlock and click through any warning =
screen.</div></div></blockquote><div><br></div><div>There will be a lot =
less warning screens in his day to day experience, and so it will be =
possible to teach the user to take &nbsp;failures more seriously. =
Currently there are many cases where users are taught to click through =
the warning screen, by knowledgeable people. This can become a habit. =
Allowing self signed certs to be published in Dane will make it easy to =
tell people: why don't you just publish your self signed cert in DNS? If =
you can't even bother to do that, then why should I take your =
site/service seriously.</div><br><blockquote type=3D"cite"><div =
class=3D"gmail_quote"><div><font class=3D"Apple-style-span" =
color=3D"#000000"><br></font></div><div>The only case where I can see a =
value to using DNSSEC here is if we start by telling the client that TLS =
is always available at the genuine =
service.</div></div></blockquote><div><br></div><div>That is indeed the =
idea: make a web that is very much more widely TLS based. Increase the =
usage of TLS 100 fold or more. Make it the default. Why not? Google are =
doing it now, Facebook is. Soon everyone will. After all any web page =
with links to other sites that is not protected is a danger, because it =
could be man in the middled to rewrite URLs and point people to the =
wrong site.</div><br><blockquote type=3D"cite"><div =
class=3D"gmail_quote"><div>&nbsp;If there is a mechanism that allows the =
client to verify the use of TLS without user involvement, the padlock =
icon becomes =
unnecessary.</div></div></blockquote><div><br></div><div>Again that is a =
UI issue, which is exceedingly important, but not one we should concern =
ourselves here. Assume UI specialists, graphics artists, and people with =
a humanities background will do their job.</div><br><blockquote =
type=3D"cite"><div class=3D"gmail_quote">
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex;"><div =
style=3D"word-wrap:break-word"><div><div class=3D"im"><blockquote =
type=3D"cite"><div>While the precise definition of what 'strict =
security' turns out to be is something we can leave to =3DJeff and co in =
WebSec. I think we need to have a story for how we could present the =
'strict' indicator through the DNS along with the trust anchor/key =
restrictions.</div>

<div><br></div><div>We may not want to add such capability to the =
standard immediately, but we can have extensibility without impact on =
what people assert are the 'core' use cases. I don't see why we have to =
accept the idea that because some people are only interested in X we =
should deliberately design the spec so that it is only capable of doing =
X and can never, ever be extended to do anything else whatsoever.</div>
</blockquote><div><br></div></div><div>I don't think I ever claimed that =
supporting self signed certs should be the *only* requirement . Just =
that it is a very important use =
case.</div></div></div></blockquote><div><br>
</div><div>I don't think it is useful to get back into an argument of =
who said what or argued =
what.</div><div><br></div><div>&nbsp;</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex;">
<div style=3D"word-wrap:break-word"><div><div> &nbsp;Dane is Win/Win for =
all.</div></div></div></blockquote><div><br></div><div>Hopefully not. I =
would hope that a security protocol is a lose for =
Mallet.</div></div></blockquote><div><br></div><div>I seem to have hit a =
nerve.</div><div><br></div><div>Henry</div><br><blockquote =
type=3D"cite"><div class=3D"gmail_quote"><div><br></div><div>
<br></div></div>-- <br>Website: <a =
href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</blockquote></div><br><div>
<span class=3D"Apple-style-span" style=3D"font-size: 12px; "><div =
style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><span class=3D"Apple-style-span" =
style=3D"border-collapse: separate; color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; =
widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; "><div style=3D"word-wrap: =
break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space; "><span class=3D"Apple-style-span" =
style=3D"border-collapse: separate; color: rgb(0, 0, 0); font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; =
widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; =
-webkit-border-vertical-spacing: 0px; =
-webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; "><div style=3D"word-wrap: =
break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space; "><span class=3D"Apple-style-span" =
style=3D"border-collapse: separate; -webkit-border-horizontal-spacing: =
0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; -webkit-text-decorations-in-effect: none; =
text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; =
orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div =
style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><span class=3D"Apple-style-span" =
style=3D"border-collapse: separate; -webkit-border-horizontal-spacing: =
0px; -webkit-border-vertical-spacing: 0px; color: rgb(0, 0, 0); =
font-family: Helvetica; font-size: 12px; font-style: normal; =
font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; -webkit-text-decorations-in-effect: none; =
text-indent: 0px; -webkit-text-size-adjust: auto; text-transform: none; =
orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; =
-webkit-text-decorations-in-effect: none; text-indent: 0px; =
-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; "><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant: normal; font-weight: normal; =
letter-spacing: normal; line-height: normal; =
-webkit-text-decorations-in-effect: none; text-indent: 0px; =
-webkit-text-size-adjust: auto; text-transform: none; orphans: 2; =
white-space: normal; widows: 2; word-spacing: 0px; "><span><div>Social =
Web Architect<br><a =
href=3D"http://bblfish.net/">http://bblfish.net/</a></div></span></span></=
span></span></div></span></div></span></div></span></div></span>
</div>
<br></body></html>=

--Apple-Mail-60--564608836--

From [email-masked]  Tue Apr  5 07:19:24 2011
From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 5 Apr 2011 16:21:03 +0200
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document. - padlock

5 apr 2011 kl. 15.17 skrev Phillip Hallam-Baker:

>=20
>  - so self signed certs, move from just being useful for guaranteeing =
communication to also guaranteeing identity (they move from no padlock =
to padlock)
>=20
> I don't think that is justified. We should eliminate the padlock =
entirely for all classes of certificate.=20
>=20
> The user interprets the padlock icon as proof that they are safe, that =
the party they are dealing with is trustworthy.
>=20

The padlock symbol may be out of scope for Dane. It may work for HTTP, =
but not for SIP. The TLS part is only one small part of the concept of a =
"secure call". The SIP group need to standardize the meaning of padlock =
for VoIP and IM - does it mean both secure media, identity and =
signalling or is encrypted signalling enough?

/O=

From [email-masked]  Tue Apr  5 07:20:40 2011
To: Matt McCutchen <[email-masked]>
From: Florian Weimer <[email-masked]>
Date: Tue, 05 Apr 2011 14:22:11 +0000
Cc: [email-masked]
Subject: Re: [dane] Objective: Restrictive versus Supplementary Models

* Matt McCutchen:

> On Tue, 2011-04-05 at 11:13 +0000, Florian Weimer wrote:
>> If you switch HTTPS transparently (meaning: no UI indicators, secure
>> cookies are not sent, SOP checks run against :80 instead of :443),
>> then you don't need DNSSEC.
>
> Indeed, this could be done, but I want server-authenticated connections.

Then you'll need DNSSEC.  But even without successful DNSSEC
validation, you would get an encrypted connection which is only
vulnerable to active attacks, at modest cost (no UI definition hassle,
no CAs to deal with).  With DNSSEC, it would be very much like HTTPS
today in terms of security properties, except that there is no
perceptible security indicator.  You'd still need to get a certificate
from a browser-approved CA before clients will see the padlock.

--=20
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstra=DFe 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

From [email-masked]  Tue Apr  5 07:23:07 2011
From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 5 Apr 2011 10:24:44 -0400
To: "Olle E. Johansson" <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document. - padlock

The padlock symbol is out of scope for the IETF in general.  It's a UI =
issue.  Let's move on, please.
--Richard

On Apr 5, 2011, at 10:21 AM, Olle E. Johansson wrote:

>=20
> 5 apr 2011 kl. 15.17 skrev Phillip Hallam-Baker:
>=20
>>=20
>> - so self signed certs, move from just being useful for guaranteeing =
communication to also guaranteeing identity (they move from no padlock =
to padlock)
>>=20
>> I don't think that is justified. We should eliminate the padlock =
entirely for all classes of certificate.=20
>>=20
>> The user interprets the padlock icon as proof that they are safe, =
that the party they are dealing with is trustworthy.
>>=20
>=20
> The padlock symbol may be out of scope for Dane. It may work for HTTP, =
but not for SIP. The TLS part is only one small part of the concept of a =
"secure call". The SIP group need to standardize the meaning of padlock =
for VoIP and IM - does it mean both secure media, identity and =
signalling or is encrypted signalling enough?
>=20
> /O
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

From [email-masked]  Tue Apr  5 07:25:27 2011
From: Martin Rex <[email-masked]>
To: [email-masked] (Phillip Hallam-Baker)
Date: Tue, 5 Apr 2011 16:27:06 +0200 (MEST)
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.
Reply-To: [email-masked]

Phillip Hallam-Baker wrote:
> 
> What was asked for were use cases:
> 
> [U-WS-OPP] Alice finds Sally's server through a search engine. Alice prefers
> to protect her communications with cryptography if this is supported by the
> sever but will communicate in plaintext otherwise.

But this particular scenario is a completely lost cause anyway.

You do not need the TLS X.509 PKI in Browsers and neither DANE
to obtain an encrypted channel--and identification of the server
endpoint address is impossible, because you do not have a trusted
source for the reference identifier to start with.

This is a classical "good faith" use case, and a "leap-of-faith" on
initial encounter would be perfectly sufficient (if the browsers
had not been turned into commercial CA nagware).

-Martin

From [email-masked]  Tue Apr  5 07:40:44 2011
Date: Tue, 5 Apr 2011 10:42:19 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Henry Story <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

--20cf307abea71a23d004a02ce208
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Apr 5, 2011 at 10:10 AM, Henry Story <[email-masked]>wrote:

>
> On 5 Apr 2011, at 15:17, Phillip Hallam-Baker wrote:
>
>
>>  - so self signed certs, move from just being useful for guaranteeing
>> communication to also guaranteeing identity (they move from no padlock to
>> padlock)
>>
>
> I don't think that is justified. We should eliminate the padlock entirely
> for all classes of certificate.
>
> The user interprets the padlock icon as proof that they are safe, that the
> party they are dealing with is trustworthy.
>
>
> I don't think it is up to this group to work on the semantics of the
> padlock frankly. Those are UI issues to be discussed by another group,
> browser vendors in particular.
>

You just suggested that DNSSEC validation alone should be a qualification
for display of the padlock icon.

Owning a DNS name does not make you a good person.
>
>
> Owning a multi billion dollar company that can afford a EV cert does not do
> that either. I think we have seen plenty of examples of that recently.
> Certification does not guarantee moral behavior, just identity. With DNS &
> Dane it is domain-name identity. CA's can then add extra information and
> certify additional properties.
>

But having been vetted through EV does at least establish a reasonable
probability that they are accountable in law and it is rather likely that
the user already has an idea of the extent to which that is useful.

If someone has an EV cert telling me that they are incorporated in Lagos,
Nigeria that extent may not be very high. If the company is incorporated in
Germany or the UK I have rather more confidence.

> So I can't see a justification for showing the padlock for any Domain
> Validated certificate.
>
> The user is not going to check the status of the connection in any case, so
> why provide information that is only going to confuse the user and be
> misinterpreted?
>
>
> Again we should not discuss UI elements here, unless we want to get
> completely sidetracked.
>

No, if people want to propose a scheme that is predicated on the display of
a padlock icon, then the intended semantics of the padlock icon have to be
up for discussion.

There is actually a pretty clear W3C document on the topic after all.

> You may not see the value of knowing you reached the site you clicked on,
> but I and many people do.
> I would love to know when I reach those 10s of millions of sites that had
> self signed certs that they are the sites that I was intending to connect
> to. I would love to know that I reached the web page that the site I was on
> had linked to. I would put a padlock there, you may not. But the use case is
> there and it is the obvious thing one can use Dane for.
>

And again you come back to proposing to display the padlock one paragraph
after claiming that it is out of scope.

If you want DANE information to be capable of leading to a padlock display
then you are going to have to agree to discuss the semantics of the padlock
and argue that DANE information is sufficient to meet the requirements for
display of the padlock.

I don't need to argue the precise semantics of the padlock because I want to
provide a mechanism that allows it to be eliminated completely.
 Let us say that Alice's mail server is connecting to Bob's mail server to
deliver mail and that Mallet is posing as a man in the middle and presents a
non compliant cert. Note that neither user is present during the exchange
and so we can't fallback to asking the user what to do. What is your
preferred outcome:

>
> 1) Alice's mail server refuses to deliver mail to Bob's mail server?
>
> 2) Alice's mail server uses the bogus certificate and delivers the mail
> anyway?
>
> 3) Alice's mail server delivers the mail en-clair?
>
>
> My question is: how is it done now?  In what percentage of case do people
> choose which option?
>

0%

The option is chosen by the machines, not by the user. That is the point I
am trying to get to here. The padlock icon is only used in a minority of TLS
transactions and it is not very useful even in that case.

> With Dane you just increase the security of those servers that wish to be
> secure. You increase the scope of secure behavior. You make secure behavior
> cheaper, and so more widely used, which creates network effects.
>

Not necessarily.

People are only going to change their behavior if the value proposition for
change crosses some threshold value. Addressing only one attack (downgrade
attack on the certificate) without addressing an attack that dominates it
(downgrade attack on the use of channel security) does not cross that
threshold in my view.

I agree that we should address #1. But we achieve no security benefit unless
> we also address #2.
>
>
> Ok, I don't see why allowing Dane to publish self signed certs affects this
> at all? Does it not make things easier? In the HTTPS case it clearly does.
>

Nobody is arguing against publishing self-signed certs.

I am arguing that
1) We should allow publication of self signed certs to improve security.
2) Security is only in fact improved if it is known that TLS is offered.
3) It is necessary to support both in order to address the use case.

People are using self-signed certs for SMTP with STARTTLS perfectly well
today. What means of attack does DANE provide a control for? Is there any
attacker that is going to be thwarted?

> There will be a lot less warning screens in his day to day experience, and
> so it will be possible to teach the user to take  failures more seriously.
> Currently there are many cases where users are taught to click through the
> warning screen, by knowledgeable people. This can become a habit. Allowing
> self signed certs to be published in Dane will make it easy to tell people:
> why don't you just publish your self signed cert in DNS? If you can't even
> bother to do that, then why should I take your site/service seriously.
>

Again you step into UI while claiming it is out of scope. The UI
implications have to be in scope or the process is nonsense.

Your use case can be handled equally well by simply not showing the padlock
icon for self-signed certs and not raising any UI errors.

>
> The only case where I can see a value to using DNSSEC here is if we start
> by telling the client that TLS is always available at the genuine service.
>
>
> That is indeed the idea: make a web that is very much more widely TLS
> based. Increase the usage of TLS 100 fold or more. Make it the default. Why
> not? Google are doing it now, Facebook is. Soon everyone will. After all any
> web page with links to other sites that is not protected is a danger,
> because it could be man in the middled to rewrite URLs and point people to
> the wrong site.
>

Google can decide that they will always offer SSL. But if I enter
www.google.com into Google's own Chrome browser it will default to http
without TLS.

I agree with the use case you present here. But that use case leads to a
requirement for notifying the client that TLS is always offered so that it
can effect the upgrade.

>  If there is a mechanism that allows the client to verify the use of TLS
> without user involvement, the padlock icon becomes unnecessary.
>
> Again that is a UI issue, which is exceedingly important, but not one we
> should concern ourselves here. Assume UI specialists, graphics artists, and
> people with a humanities background will do their job.
>

I was part of the W3C working group that did just that.

You are the person who is proposing a protocol that depends on the effective
display of a security signal. So you are the person who bears the burden of
seeking out those experts and soliciting their opinions.

You cannot assume that the usability people will do their job because they
are not SECURITY usability people and their interest is to make the
application appear to be simple.

>   Dane is Win/Win for all.
>>
>
> Hopefully not. I would hope that a security protocol is a lose for Mallet.
>
>
> I seem to have hit a nerve.
>

No, and the idea that you have is your fundamental problem here. My
objective here is to make DANE into a protocol that is actually useful in
practice by providing an effective control against real world attacks
without relying on user interface signals that I know are not going to be
prominent enough to have utility.

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

--20cf307abea71a23d004a02ce208
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Tue, Apr 5, 2011 at 10:10 AM, Henry S=
tory <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">henry=
[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"=
>
<div style=3D"word-wrap:break-word"><br><div><div class=3D"im"><div>On 5 Ap=
r 2011, at 15:17, Phillip Hallam-Baker wrote:</div><blockquote type=3D"cite=
"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style=3D"word-wrap:break-word"><div><div><br></div><div>=A0- so self s=
igned certs, move from just being useful for guaranteeing communication to =
also guaranteeing identity (they move from no padlock to padlock)</div>
</div></div></blockquote><div><br></div><div>I don&#39;t think that is just=
ified. We should eliminate the padlock entirely for all classes of certific=
ate.=A0</div><div><br></div><div>The user interprets the padlock icon as pr=
oof that they are safe, that the party they are dealing with is trustworthy=
.</div>
</div></blockquote><div><br></div></div>I don&#39;t think it is up to this =
group to work on the semantics of the padlock frankly. Those are UI issues =
to be discussed by another group, browser vendors in particular.=A0</div>
</div></blockquote><div><br></div><div>You just suggested that DNSSEC valid=
ation alone should be a qualification for display of the padlock icon.</div=
><div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style=3D"word-wrap:break-word"><div><div class=3D"im"><blockquote type=
=3D"cite"><div class=3D"gmail_quote"><div>Owning a DNS name does not make y=
ou a good person. </div></div></blockquote><div><br></div></div><div>Owning=
 a multi billion dollar company that can afford a EV cert does not do that =
either. I think we have seen plenty of examples of that recently. Certifica=
tion does not guarantee moral behavior, just identity. With DNS &amp; Dane =
it is domain-name identity. CA&#39;s can then add extra information and cer=
tify additional properties.</div>
</div></div></blockquote><div><br></div><div>But having been vetted through=
 EV does at least establish a reasonable probability that they are accounta=
ble in law and it is rather likely that the user already has an idea of the=
 extent to which that is useful.</div>
<div><br></div><div>If someone has an EV cert telling me that they are inco=
rporated in Lagos, Nigeria that extent may not be very high. If the company=
 is incorporated in Germany or the UK I have rather more confidence.</div>
<div><br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style=3D"=
word-wrap:break-word"><div><div class=3D"im"><blockquote type=3D"cite"><div=
 class=3D"gmail_quote">
<div>So I can&#39;t see a justification for showing the padlock for any Dom=
ain Validated certificate.</div><div><br></div><div>The user is not going t=
o check the status of the connection in any case, so why provide informatio=
n that is only going to confuse the user and be misinterpreted?</div>
</div></blockquote><div><br></div></div><div>Again we should not discuss UI=
 elements here, unless we want to get completely sidetracked.</div></div></=
div></blockquote><div><br></div><div>No, if people want to propose a scheme=
 that is predicated on the display of a padlock icon, then the intended sem=
antics of the padlock icon have to be up for discussion.</div>
<div><br></div><div>There is actually a pretty clear W3C document on the to=
pic after all.</div><div><br></div><div>=A0</div><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex;">
<div style=3D"word-wrap:break-word"><div><div>You may not see the value of =
knowing you reached the site you clicked on, but I and many people do.</div=
><div>I would love to know when I reach those 10s of millions of sites that=
 had self signed certs that they are the sites that I was intending to conn=
ect to. I would love to know that I reached the web page that the site I wa=
s on had linked to. I would put a padlock there, you may not. But the use c=
ase is there and it is the obvious thing one can use Dane for.</div>
</div></div></blockquote><div><br></div><div>And again you come back to pro=
posing to display the padlock one paragraph after claiming that it is out o=
f scope.</div><div><br></div><div>If you want DANE information to be capabl=
e of leading to a padlock display then you are going to have to agree to di=
scuss the semantics of the padlock and argue that DANE information is suffi=
cient to meet the requirements for display of the padlock.</div>
<div><br></div><div>I don&#39;t need to argue the precise semantics of the =
padlock because I want to provide a mechanism that allows it to be eliminat=
ed completely.</div><div>=A0Let us say that Alice&#39;s mail server is conn=
ecting to Bob&#39;s mail server to deliver mail and that Mallet is posing a=
s a man in the middle and presents a non compliant cert. Note that neither =
user is present during the exchange and so we can&#39;t fallback to asking =
the user what to do. What is your preferred outcome:</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;"><div style=3D"word-wrap:break-word"><div><d=
iv class=3D"im"><blockquote type=3D"cite"><div class=3D"gmail_quote">
<div><br></div><div>1) Alice&#39;s mail server refuses to deliver mail to B=
ob&#39;s mail server?</div><div><br></div><div>2) Alice&#39;s mail server u=
ses the bogus certificate and delivers the mail anyway?</div><div><br>
</div>
<div>3) Alice&#39;s mail server delivers the mail en-clair?</div></div></bl=
ockquote><div><br></div></div><div>My question is: how is it done now? =A0I=
n what percentage of case do people choose which option? </div></div></div>
</blockquote><div><br></div><div>0%</div><div><br></div><div>The option is =
chosen by the machines, not by the user. That is the point I am trying to g=
et to here. The padlock icon is only used in a minority of TLS transactions=
 and it is not very useful even in that case.</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex;"><div style=3D"word-wrap:break=
-word"><div><div>With Dane you just increase the security of those servers =
that wish to be secure. You increase the scope of secure behavior. You make=
 secure behavior cheaper, and so more widely used, which creates network ef=
fects.</div>
</div></div></blockquote><div><br></div><div>Not necessarily.=A0</div><div>=
<br></div><div>People are only going to change their behavior if the value =
proposition for change crosses some threshold value. Addressing only one at=
tack (downgrade attack on the certificate) without addressing an attack tha=
t dominates it (downgrade attack on the use of channel security) does not c=
ross that threshold in my view.</div>
<div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style=3D=
"word-wrap:break-word"><div><div class=3D"im"><blockquote type=3D"cite"><di=
v class=3D"gmail_quote">
<div>I agree that we should address #1. But we achieve no security benefit =
unless we also address #2.=A0</div></div></blockquote><div><br></div></div>=
<div>Ok, I don&#39;t see why allowing Dane to publish self signed certs aff=
ects this at all? Does it not make things easier? In the HTTPS case it clea=
rly does.</div>
</div></div></blockquote><div><br></div><div>Nobody is arguing against publ=
ishing self-signed certs.</div><div><br></div><div>I am arguing that=A0</di=
v><div>1) We should allow publication of self signed certs to improve secur=
ity.</div>
<div>2) Security is only in fact improved if it is known that TLS is offere=
d.=A0</div><div>3) It is necessary to support both in order to address the =
use case.</div><div><br></div><div>People are using self-signed certs for S=
MTP with STARTTLS perfectly well today. What means of attack does DANE prov=
ide a control for? Is there any attacker that is going to be thwarted?</div=
>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex;"><div style=3D"word-wrap:break=
-word"><div><div>There will be a lot less warning screens in his day to day=
 experience, and so it will be possible to teach the user to take =A0failur=
es more seriously. Currently there are many cases where users are taught to=
 click through the warning screen, by knowledgeable people. This can become=
 a habit. Allowing self signed certs to be published in Dane will make it e=
asy to tell people: why don&#39;t you just publish your self signed cert in=
 DNS? If you can&#39;t even bother to do that, then why should I take your =
site/service seriously.</div>
</div></div></blockquote><div><br></div><div>Again you step into UI while c=
laiming it is out of scope. The UI implications have to be in scope or the =
process is nonsense.</div><div><br></div><div>Your use case can be handled =
equally well by simply not showing the padlock icon for self-signed certs a=
nd not raising any UI errors.=A0</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;"><div style=3D"word-wrap:break-word"><div><d=
iv class=3D"im"><blockquote type=3D"cite"><div class=3D"gmail_quote"><div><=
font color=3D"#000000"><br>
</font></div><div>The only case where I can see a value to using DNSSEC her=
e is if we start by telling the client that TLS is always available at the =
genuine service.</div></div></blockquote><div><br></div></div><div>That is =
indeed the idea: make a web that is very much more widely TLS based. Increa=
se the usage of TLS 100 fold or more. Make it the default. Why not? Google =
are doing it now, Facebook is. Soon everyone will. After all any web page w=
ith links to other sites that is not protected is a danger, because it coul=
d be man in the middled to rewrite URLs and point people to the wrong site.=
</div>
</div></div></blockquote><div><br></div><div>Google can decide that they wi=
ll always offer SSL. But if I enter <a href=3D"http://www.google.com">www.g=
oogle.com</a> into Google&#39;s own Chrome browser it will default to http =
without TLS.</div>
<div><br></div><div>I agree with the use case you present here. But that us=
e case leads to a requirement for notifying the client that TLS is always o=
ffered so that it can effect the upgrade.</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x;">
<div style=3D"word-wrap:break-word"><div><div class=3D"im"><blockquote type=
=3D"cite"><div class=3D"gmail_quote"><div>=A0If there is a mechanism that a=
llows the client to verify the use of TLS without user involvement, the pad=
lock icon becomes unnecessary.</div>
</div></blockquote></div><div>Again that is a UI issue, which is exceedingl=
y important, but not one we should concern ourselves here. Assume UI specia=
lists, graphics artists, and people with a humanities background will do th=
eir job.</div>
</div></div></blockquote><div><br></div><div>I was part of the W3C working =
group that did just that.</div><div><br></div><div>You are the person who i=
s proposing a protocol that depends on the effective display of a security =
signal. So you are the person who bears the burden of seeking out those exp=
erts and soliciting their opinions.</div>
<div><br></div><div>You cannot assume that the usability people will do the=
ir job because they are not SECURITY usability people and their interest is=
 to make the application appear to be simple.</div><div>=A0=A0</div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex;">
<div style=3D"word-wrap:break-word"><div><div class=3D"im"><blockquote type=
=3D"cite"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style=3D"word-wrap:break-word"><div><div> =A0Dane is Win/Win for all.<=
/div></div></div></blockquote><div><br></div><div>Hopefully not. I would ho=
pe that a security protocol is a lose for Mallet.</div></div></blockquote>
<div><br></div></div><div>I seem to have hit a nerve.</div></div></div></bl=
ockquote><div><br></div><div>No, and the idea that you have is your fundame=
ntal problem here. My objective here is to make DANE into a protocol that i=
s actually useful in practice by providing an effective control against rea=
l world attacks without relying on user interface signals that I know are n=
ot going to be prominent enough to have utility.</div>
<div><br></div><div>=A0</div></div>-- <br>Website: <a href=3D"http://hallam=
baker.com/">http://hallambaker.com/</a><br><br>

--20cf307abea71a23d004a02ce208--

From [email-masked]  Tue Apr  5 08:09:21 2011
From: Martin Rex <[email-masked]>
To: [email-masked] (Phillip Hallam-Baker)
Date: Tue, 5 Apr 2011 17:10:59 +0200 (MEST)
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Objective: Restrictive versus Supplementary
Reply-To: [email-masked]

Phillip Hallam-Baker wrote:
> 
> The trend is certainly to deprecate providing a security signal to indicate
> use of DV certs. The only reason it is done today is that this is the legacy
> approach and the current protocols require the user to check that TLS is in
> use.
> 
> So I really can't see how an argument of the form 'DNSSEC validation is just
> as good as DV, therefore it should get a padlock icon' is going to get
> traction with the browser providers.

It depends on whether the Browser vendors&developers see their products as
simple nagware to promote TLS server certificates from commercial CAs,
or as applications to address the needs of their customers/users.

> 
> The question they are going to ask is 'what level of security notification
> is justified and/or necessary'.
> 
> Anyone care to argue that mere possession of a DNS domain makes you
> trustworthy?

That is the implied premise of doing server endpoint identification
based on DNS hostnames (rfc2818, rfc6125) and as it is implemented
and has been used in web browsers and other TLS clients since the
invention of SSL.   It's nowhere close to a real authentication based
on reference identifiers that are actually aligned with human intent,
or a secure re-authentication on successive encounters.

It appears that the majority of folks everywhere (not just in the IETF)
deems this to be "good enough".  But then, there is this huge SSLiverse
of 600+ omnipotent CAs and an unknown number of RAs, and a breach of
any single one of them can be used to subvert the TLS protection for
millions of users worldwide.  So in a way, doing server endpoint
identification based on DNS hostnames and using the TLS X.509 PKI
appears to be equivalent-strength (lack of) security, i.e. well balanced.

-Martin

From [email-masked]  Tue Apr  5 08:10:36 2011
Date: Tue, 5 Apr 2011 11:12:12 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document. - padlock

--bcaec50163b9fe1e4c04a02d4c03
Content-Type: text/plain; charset=ISO-8859-1

The manner in which the padlock icon is displayed is out of scope.

But declaring an issue out of scope does not mean that it can then be used
as pixie dust.

I am calling out the padlock icon proposal from Henry and others as it is
relying on pixie dust that (1) they admit they do not understand and (2) is
only available in a special case and (3) probably not then.

There is no padlock icon in SIP, SMTP, Web Services or any other Internet
Service that does not have a primary user interface. If we are going to
propose a useful protocol it cannot rely on pixie dust.

On Tue, Apr 5, 2011 at 10:24 AM, Richard L. Barnes <[email-masked]> wrote:

> The padlock symbol is out of scope for the IETF in general.  It's a UI
> issue.  Let's move on, please.
> --Richard
>
> On Apr 5, 2011, at 10:21 AM, Olle E. Johansson wrote:
>
> >
> > 5 apr 2011 kl. 15.17 skrev Phillip Hallam-Baker:
> >
> >>
> >> - so self signed certs, move from just being useful for guaranteeing
> communication to also guaranteeing identity (they move from no padlock to
> padlock)
> >>
> >> I don't think that is justified. We should eliminate the padlock
> entirely for all classes of certificate.
> >>
> >> The user interprets the padlock icon as proof that they are safe, that
> the party they are dealing with is trustworthy.
> >>
> >
> > The padlock symbol may be out of scope for Dane. It may work for HTTP,
> but not for SIP. The TLS part is only one small part of the concept of a
> "secure call". The SIP group need to standardize the meaning of padlock for
> VoIP and IM - does it mean both secure media, identity and signalling or is
> encrypted signalling enough?
> >
> > /O
> > _______________________________________________
> > dane mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/dane
>
>

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

--bcaec50163b9fe1e4c04a02d4c03
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

The manner in which the padlock icon is displayed is out of scope.<div><br>=
</div><div>But declaring an issue out of scope does not mean that it can th=
en be used as pixie dust.</div><div><br></div><div>I am calling out the pad=
lock icon proposal from Henry and others as it is relying on pixie dust tha=
t (1) they admit they do not understand and (2) is only available in a spec=
ial case and (3) probably not then.</div>
<div><br></div><div><br></div><div>There is no padlock icon in SIP, SMTP, W=
eb Services or any other Internet Service that does not have a primary user=
 interface. If we are going to propose a useful protocol it cannot rely on =
pixie dust.</div>
<div><br></div><div><br></div><div><br><div class=3D"gmail_quote">On Tue, A=
pr 5, 2011 at 10:24 AM, Richard L. Barnes <span dir=3D"ltr">&lt;<a href=3D"=
mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex;">
The padlock symbol is out of scope for the IETF in general. =A0It&#39;s a U=
I issue. =A0Let&#39;s move on, please.<br>
--Richard<br>
<div><div></div><div class=3D"h5"><br>
On Apr 5, 2011, at 10:21 AM, Olle E. Johansson wrote:<br>
<br>
&gt;<br>
&gt; 5 apr 2011 kl. 15.17 skrev Phillip Hallam-Baker:<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; - so self signed certs, move from just being useful for guaranteei=
ng communication to also guaranteeing identity (they move from no padlock t=
o padlock)<br>
&gt;&gt;<br>
&gt;&gt; I don&#39;t think that is justified. We should eliminate the padlo=
ck entirely for all classes of certificate.<br>
&gt;&gt;<br>
&gt;&gt; The user interprets the padlock icon as proof that they are safe, =
that the party they are dealing with is trustworthy.<br>
&gt;&gt;<br>
&gt;<br>
&gt; The padlock symbol may be out of scope for Dane. It may work for HTTP,=
 but not for SIP. The TLS part is only one small part of the concept of a &=
quot;secure call&quot;. The SIP group need to standardize the meaning of pa=
dlock for VoIP and IM - does it mean both secure media, identity and signal=
ling or is encrypted signalling enough?<br>

&gt;<br>
&gt; /O<br>
</div></div>&gt; _______________________________________________<br>
&gt; dane mailing list<br>
&gt; <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blan=
k">https://www.ietf.org/mailman/listinfo/dane</a><br>
<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a href=3D"htt=
p://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--bcaec50163b9fe1e4c04a02d4c03--

From [email-masked]  Tue Apr  5 08:20:07 2011
From: Henry Story <[email-masked]>
Date: Tue, 5 Apr 2011 17:21:45 +0200
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

--Apple-Mail-61--560325366
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On 5 Apr 2011, at 16:42, Phillip Hallam-Baker wrote:

> I don't think it is useful to get back into an argument of who said =
what or argued what.

You then go into arguments claiming I was talking of something first and =
using it as part of an argument, and so on, when it was just meant to be =
illustrative. Anyway, since everyone on this lists agrees that UI design =
is out of scope I'll skip the discussion that evolves around who said =
what first.

> On Tue, Apr 5, 2011 at 10:10 AM, Henry Story <[email-masked]> =
wrote:
>=20
> On 5 Apr 2011, at 15:17, Phillip Hallam-Baker wrote:
> [snip]
>> Owning a DNS name does not make you a good person.
>=20
> Owning a multi billion dollar company that can afford a EV cert does =
not do that either. I think we have seen plenty of examples of that =
recently. Certification does not guarantee moral behavior, just =
identity. With DNS & Dane it is domain-name identity. CA's can then add =
extra information and certify additional properties.
>=20
> But having been vetted through EV does at least establish a reasonable =
probability that they are accountable in law and it is rather likely =
that the user already has an idea of the extent to which that is useful.
>=20
> If someone has an EV cert telling me that they are incorporated in =
Lagos, Nigeria that extent may not be very high. If the company is =
incorporated in Germany or the UK I have rather more confidence.

If I click from a page that I trust and I trust I arrived on the page it =
linked to then I don't care where the people live: Nigeria, Lagos or =
Germany.  The web functions with so little security because the network =
effect is so powerful. Increasing the lowest common denominator security =
will benefit from the network effect and create a huge increase in =
security.

> [snip]
> Ok, I don't see why allowing Dane to publish self signed certs affects =
this at all? Does it not make things easier? In the HTTPS case it =
clearly does.
>=20
> Nobody is arguing against publishing self-signed certs.

Ok. That's all I really care about. I want self signed certs support in =
Dane.

>=20
> I am arguing that=20
> 1) We should allow publication of self signed certs to improve =
security.
> 2) Security is only in fact improved if it is known that TLS is =
offered.=20
> 3) It is necessary to support both in order to address the use case.

We mostly agree here.

I would put (2) differently. If most pages linking to other page were =
behind TLS (even if unencrypted) and so if those would link to other =
page behind tls (even if unencrypted) then the web would be a much much =
more secure place. Because we could use the web of linked pages much =
more strongly to determine trust.=20

>=20
> People are using self-signed certs for SMTP with STARTTLS perfectly =
well today.

Perfectly?

> What means of attack does DANE provide a control for? Is there any =
attacker that is going to be thwarted?

With Dane more pages on the web will be able to point to resources with =
https URIs. As people click from one resource to another, they will at =
least be able to have a warning if a man in the middle attack is taking =
place. How that warning is presented to the user is a UI issue - and I =
am sure a lot of work can still be done in that space.

> =20
> There will be a lot less warning screens in his day to day experience, =
and so it will be possible to teach the user to take  failures more =
seriously. Currently there are many cases where users are taught to =
click through the warning screen, by knowledgeable people. This can =
become a habit. Allowing self signed certs to be published in Dane will =
make it easy to tell people: why don't you just publish your self signed =
cert in DNS? If you can't even bother to do that, then why should I take =
your site/service seriously.
>=20
> Again you step into UI while claiming it is out of scope. The UI =
implications have to be in scope or the process is nonsense.

I said UI is VERY important. I just don't want to get into a debate on =
what UI elements are the best here and what the semantics of each =
element are!

Ok. I'll stop here. The point of this thread is not to work through one =
issue but to get use cases together. Perhaps that is what we are doing, =
but if feels a bit more like an argument.

Henry

> [snip]=20

--Apple-Mail-61--560325366
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><br><div><div>On 5 Apr 2011, at 16:42, Phillip Hallam-Baker =
wrote:</div><div><br></div><blockquote type=3D"cite">I don't think it is =
useful to get back into an argument of who said what or argued =
what.</blockquote><div><br></div><div>You then go into arguments =
claiming I was talking of something first and using it as part of an =
argument, and&nbsp;so on, when it was just meant to be illustrative. =
Anyway, since everyone on this lists agrees that UI design is out of =
scope I'll skip the discussion that evolves around who said what =
first.</div><div><br></div><br><blockquote type=3D"cite">On Tue, Apr 5, =
2011 at 10:10 AM, Henry Story <span dir=3D"ltr">&lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>&gt;</s=
pan> wrote:<br><div class=3D"gmail_quote"><blockquote =
class=3D"gmail_quote" style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; =
border-left-color: rgb(204, 204, 204); border-left-style: solid; =
padding-left: 1ex; position: static; z-index: auto; ">
<div style=3D"word-wrap:break-word"><br><div><div class=3D"im"><div>On 5 =
Apr 2011, at 15:17, Phillip Hallam-Baker =
wrote:</div></div></div></div></blockquote><div>[snip]</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex;">
<div style=3D"word-wrap:break-word"><div><div class=3D"im"><blockquote =
type=3D"cite"><div class=3D"gmail_quote"><div>Owning a DNS name does not =
make you a good person. =
</div></div></blockquote><div><br></div></div><div>Owning a multi =
billion dollar company that can afford a EV cert does not do that =
either. I think we have seen plenty of examples of that recently. =
Certification does not guarantee moral behavior, just identity. With DNS =
&amp; Dane it is domain-name identity. CA's can then add extra =
information and certify additional properties.</div>
</div></div></blockquote><div><br></div><div>But having been vetted =
through EV does at least establish a reasonable probability that they =
are accountable in law and it is rather likely that the user already has =
an idea of the extent to which that is useful.</div>
<div><br></div><div>If someone has an EV cert telling me that they are =
incorporated in Lagos, Nigeria that extent may not be very high. If the =
company is incorporated in Germany or the UK I have rather more =
confidence.</div></div></blockquote><div><br></div><div>If I click from =
a page that I trust and I trust I arrived on the page it linked to then =
I don't care where the people live: Nigeria, Lagos or Germany. &nbsp;The =
web functions with so little security because the network effect is so =
powerful. Increasing the lowest common denominator security will benefit =
from the network effect and create a huge increase in =
security.</div><div><br></div><blockquote type=3D"cite"><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, =
204, 204); border-left-style: solid; padding-left: 1ex; position: =
static; z-index: auto; "><div style=3D"word-wrap:break-word"><div><div =
class=3D"im"><div><font class=3D"Apple-style-span" =
color=3D"#000000">[snip]</font></div></div><div>Ok, I don't see why =
allowing Dane to publish self signed certs affects this at all? Does it =
not make things easier? In the HTTPS case it clearly does.</div>
</div></div></blockquote><div><br></div><div>Nobody is arguing against =
publishing self-signed =
certs.</div></div></blockquote><div><br></div><div>Ok. That's all I =
really care about. I want self signed certs support in =
Dane.</div><br><blockquote type=3D"cite"><div =
class=3D"gmail_quote"><div><br></div><div>I am arguing =
that&nbsp;</div><div>1) We should allow publication of self signed certs =
to improve security.</div>
<div>2) Security is only in fact improved if it is known that TLS is =
offered.&nbsp;</div><div>3) It is necessary to support both in order to =
address the use case.</div></div></blockquote><div><br></div>We mostly =
agree here.<br><div><br></div><div>I would put (2) differently. If most =
pages linking to other page were behind TLS (even if unencrypted) and so =
if those would link to other page behind tls (even if unencrypted) then =
the web would be a much much more secure place. Because we could use the =
web of linked pages much more strongly to determine =
trust.&nbsp;</div><br><blockquote type=3D"cite"><div =
class=3D"gmail_quote"><div><br></div><div>People are using self-signed =
certs for SMTP with STARTTLS perfectly well =
today.</div></div></blockquote><div><br></div>Perfectly?<br><div><br></div=
><blockquote type=3D"cite"><div class=3D"gmail_quote"><div> What means =
of attack does DANE provide a control for? Is there any attacker that is =
going to be thwarted?</div></div></blockquote><div><br></div><div>With =
Dane more pages on the web will be able to point to resources with https =
URIs. As people click from one resource to another, they will at least =
be able to have a warning if a man in the middle attack is taking place. =
How that warning is presented to the user is a UI issue - and I am sure =
a lot of work can still be done in that =
space.</div><div><br></div><div><br></div><blockquote type=3D"cite"><div =
class=3D"gmail_quote">
<div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; =
border-left-width: 1px; border-left-color: rgb(204, 204, 204); =
border-left-style: solid; padding-left: 1ex; position: static; z-index: =
auto; "><div style=3D"word-wrap:break-word"><div><div>There will be a =
lot less warning screens in his day to day experience, and so it will be =
possible to teach the user to take &nbsp;failures more seriously. =
Currently there are many cases where users are taught to click through =
the warning screen, by knowledgeable people. This can become a habit. =
Allowing self signed certs to be published in Dane will make it easy to =
tell people: why don't you just publish your self signed cert in DNS? If =
you can't even bother to do that, then why should I take your =
site/service seriously.</div>
</div></div></blockquote><div><br></div><div>Again you step into UI =
while claiming it is out of scope. The UI implications have to be in =
scope or the process is =
nonsense.</div></div></blockquote><div><br></div><div>I said UI is VERY =
important. I just don't want to get into a debate on what UI elements =
are the best here and what the semantics of each element =
are!</div><div><br></div><div>Ok. I'll stop here. The point of this =
thread is not to work through one issue but to get use cases together. =
Perhaps that is what we are doing, but if feels a bit more like an =
argument.</div><div><br></div><div><br></div><div>Henry</div><div><br></di=
v></div><blockquote type=3D"cite"><div =
class=3D"gmail_quote"><div>[snip]&nbsp;</div><blockquote =
class=3D"gmail_quote" style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; =
border-left-color: rgb(204, 204, 204); border-left-style: solid; =
padding-left: 1ex; "><div style=3D"word-wrap: break-word; =
"><div></div></div></blockquote></div></blockquote><div><div =
class=3D"gmail_quote"><div><br></div></div></div></body></html>=

--Apple-Mail-61--560325366--

From [email-masked]  Tue Apr  5 08:24:17 2011
Date: Tue, 5 Apr 2011 11:17:54 -0400
To: Paul Hoffman <[email-masked]>
From: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

Paul,

I have to agree with one aspects of what PHB has suggested, i.e., 
that we need more than statements of requirements. We need one 
(preferably more) motivations for each requirement, to justify why it 
is a requirement.

Steve

From [email-masked]  Tue Apr  5 08:24:17 2011
Date: Tue, 5 Apr 2011 11:13:13 -0400
To: Ben Laurie <[email-masked]>
From: Stephen Kent <[email-masked]>
Cc: Paul Hoffman <[email-masked]>, [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

At 11:22 AM +0100 4/5/11, Ben Laurie wrote:
>...
>
>OTOH, I think 4 is vital - otherwise self-signed certs cannot be first
>class citizens.

A self-signed cert can be used as a TA, and is covered under #3.

Steve

From [email-masked]  Tue Apr  5 08:35:12 2011
From: Henry Story <[email-masked]>
Date: Tue, 5 Apr 2011 17:36:49 +0200
To: Stephen Kent <[email-masked]>
Cc: Paul Hoffman <[email-masked]>, [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

On 5 Apr 2011, at 17:13, Stephen Kent wrote:

> At 11:22 AM +0100 4/5/11, Ben Laurie wrote:
>> ...
>>=20
>> OTOH, I think 4 is vital - otherwise self-signed certs cannot be =
first
>> class citizens.
>=20
> A self-signed cert can be used as a TA, and is covered under #3.

It may be technically covered under #3 but the point was to create use =
cases and requirements.
#3 does not make the importance of self signed certs clear.

Henry

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

Social Web Architect
http://bblfish.net/

From [email-masked]  Tue Apr  5 08:44:57 2011
Date: Tue, 05 Apr 2011 11:46:31 -0400
From: Carl Wallace <[email-masked]>
To: Henry Story <[email-masked]>, Stephen Kent <[email-masked]>
Cc: Paul Hoffman <[email-masked]>, [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

On 4/5/11 11:36 AM, "Henry Story" <[email-masked]> wrote:

>
>On 5 Apr 2011, at 17:13, Stephen Kent wrote:
>
>> At 11:22 AM +0100 4/5/11, Ben Laurie wrote:
>>> ...
>>> 
>>> OTOH, I think 4 is vital - otherwise self-signed certs cannot be first
>>> class citizens.
>> 
>> A self-signed cert can be used as a TA, and is covered under #3.
>
>It may be technically covered under #3 but the point was to create use
>cases and requirements.
>#3 does not make the importance of self signed certs clear.
>
>Henry

It could be technically covered under any of these options, of which there
are really only two: cert lock and CA lock.  The other two options are
just instances of the first two where the client elected not to perform
further processing.  If the intent is to allow the server operator to
preclude further client action that should be stated in the use case, but
it does not seem necessary.  

From [email-masked]  Tue Apr  5 08:46:36 2011
Date: Tue, 5 Apr 2011 11:48:12 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Stephen Kent <[email-masked]>
Cc: Paul Hoffman <[email-masked]>, [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

--bcaec50163b9c0077404a02dcd15
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Apr 5, 2011 at 11:13 AM, Stephen Kent <[email-masked]> wrote:

> At 11:22 AM +0100 4/5/11, Ben Laurie wrote:
>
>> ...
>>
>>
>> OTOH, I think 4 is vital - otherwise self-signed certs cannot be first
>> class citizens.
>>
>
> A self-signed cert can be used as a TA, and is covered under #3.
>

I see this particular issue, whether a cert is encoded directly or the user
is required to insert a trust anchor to be a matter of implementation detail
and not a requirements question at all.

Amongst the requirements I have text for are:

[R-C-KEYPUB] Allow relying party to access the value of the key
material which may or may not be valid for the domain for which it
is published.

[R-C-DV] Assert that a key is valid for use with a specific domain

[R-P-LOCAL] Support deployment by local network administration without
reference to any other party.

[R-P-LOCALD] Support deployment by local network administration without
reference to any other party except for enrollment of DNSSEC KSK.

Note that it is quite likely going to be the case that it is not possible to
meet every requirement simultaneously. So attempting to usefully protect
against Mallet (who can perform a man in the middle attack) without DNSSEC
does not look possible to me, but protecting against EVE who can only
evesdrop (but cannot perform an integrity attack) may well be feasible.

And so I expect that at the end we are going to have proposals that state

'Use of DNSSEC is optional, thus [R-P-LOCAL] is satisfied. However in the
case DNSSEC is not used, the connection is vulnerable to an attack by
[A-SPOOF] or [A-MALLET], protection is only provided against [A-EVE]'

With DNSSEC deployment, protection is given against [A-SPOOF] and [A-MALLET]

With DNSSEC deployment and use of a third party issued certificate...

And so on.

There are going to be options and they are going to mean that there is a
tradeoff between security and convenience. That is OK, if there was no
tradeoff there would be no point in offering an option.

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

--bcaec50163b9c0077404a02dcd15
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Tue, Apr 5, 2011 at 11:13 AM, Stephen=
 Kent <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">[email-masked]</a=
>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
At 11:22 AM +0100 4/5/11, Ben Laurie wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
...<div class=3D"im"><br>
<br>
OTOH, I think 4 is vital - otherwise self-signed certs cannot be first<br>
class citizens.<br>
</div></blockquote>
<br>
A self-signed cert can be used as a TA, and is covered under #3.<br></block=
quote><div><br></div><div>I see this particular issue, whether a cert is en=
coded directly or the user is required to insert a trust anchor to be a mat=
ter of implementation detail and not a requirements question at all.</div>
<div><br></div><div>Amongst the requirements I have text for are:</div><div=
><br></div><div><div>[R-C-KEYPUB] Allow relying party to access the value o=
f the key material=A0which may or may not be valid for the domain for which=
 it is=A0published.</div>
</div></div><br clear=3D"all"><div>[R-C-DV] Assert that a key is valid for =
use with a specific=A0domain</div><div><br></div><div>[R-P-LOCAL] Support d=
eployment by local network administration without reference to any other pa=
rty.</div>
<div><br></div><div>[R-P-LOCALD] Support deployment by local network admini=
stration without reference to any other party except for enrollment of DNSS=
EC KSK.</div><div><br></div><div><br></div><div>Note that it is quite likel=
y going to be the case that it is not possible to meet every requirement si=
multaneously. So attempting to usefully protect against Mallet (who can per=
form a man in the middle attack) without DNSSEC does not look possible to m=
e, but protecting against EVE who can only evesdrop (but cannot perform an =
integrity attack) may well be feasible.</div>
<div><br></div><div>And so I expect that at the end we are going to have pr=
oposals that state</div><div><br></div><div>&#39;Use of DNSSEC is optional,=
 thus [R-P-LOCAL] is satisfied. However in the case DNSSEC is not used, the=
 connection is vulnerable to an attack by [A-SPOOF] or [A-MALLET], protecti=
on is only provided against [A-EVE]&#39;</div>
<div><br></div><div>With DNSSEC deployment, protection is given against [A-=
SPOOF] and [A-MALLET]</div><div><br></div><div>With DNSSEC deployment and u=
se of a third party issued certificate...</div><div><br></div><div>And so o=
n.</div>
<div><br></div><div><br></div><div>There are going to be options and they a=
re going to mean that there is a tradeoff between security and convenience.=
 That is OK, if there was no tradeoff there would be no point in offering a=
n option.</div>
<div><br></div><div>-- <br>Website: <a href=3D"http://hallambaker.com/">htt=
p://hallambaker.com/</a><br><br>
</div>

--bcaec50163b9c0077404a02dcd15--

From [email-masked]  Tue Apr  5 09:08:58 2011
Date: Tue, 5 Apr 2011 12:03:15 -0400
To: Henry Story <[email-masked]>
From: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

At 5:36 PM +0200 4/5/11, Henry Story wrote:
>On 5 Apr 2011, at 17:13, Stephen Kent wrote:
>
>>  At 11:22 AM +0100 4/5/11, Ben Laurie wrote:
>>>  ...
>>>
>>>  OTOH, I think 4 is vital - otherwise self-signed certs cannot be first
>>>  class citizens.
>>
>>  A self-signed cert can be used as a TA, and is covered under #3.
>
>It may be technically covered under #3 but the point was to create 
>use cases and requirements.
>#3 does not make the importance of self signed certs clear.
>
>Henry

I agree that self-signed certs are an important way for web sites to
become 1st class citizens w/o paying a TTP CA.  But, #4 is not a
requirement relative to that goal; it is just one way to achieve that
goal, and it is redundant relative to #3. Since having fewer ways to
accomplish a set of goals is generally viewed as desirable ...

Steve

From [email-masked]  Tue Apr  5 09:40:41 2011
Date: Tue, 5 Apr 2011 12:42:20 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: [email-masked]
Subject: [dane] browser UI out of scope, was Re:  Objective: Restrictive versus Supplementary Models

On Tue, 5 Apr 2011, Matt McCutchen wrote:

> On Tue, 2011-04-05 at 11:13 +0000, Florian Weimer wrote:
> > If you switch HTTPS transparently (meaning: no UI indicators, secure
> > cookies are not sent, SOP checks run against :80 instead of :443),
> > then you don't need DNSSEC.
> 
> Indeed, this could be done, but I want server-authenticated connections.
> 
> > I'm pretty sure it's politically and technically infeasible to
> > introduce DNSSEC-driven UI changes on a larger scale, so I doubt that
> > any non-transparent approach will fly.
> 
> Technically, the existing Firefox blue badge works with my modified NSS
> (https://mattmccutchen.net/cryptid/#nss-dane) if you ignore the
> unvalidated certificate details.  Politically, I don't know, but I would
> use such a browser.

This working group is designing a protocol, not a web browser UI. I suggest we focus on
the protocol design, and not get lost in padlocks, green bars, blue badges or what not.

Similarly, our use cases or requirements are not "create some art in the browser window"

I'm sure the browser people can deal with their gui representation in the new world of
TLS information that came from non-PKIX sources, DANE or otherwise.

Paul

From [email-masked]  Tue Apr  5 10:09:30 2011
Date: Tue, 5 Apr 2011 13:11:11 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Wouters <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] browser UI out of scope, was Re: Objective: Restrictive versus Supplementary Models

--20cf3054a133851c8604a02ef697
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Apr 5, 2011 at 12:42 PM, Paul Wouters <[email-masked]> wrote:

>
> This working group is designing a protocol, not a web browser UI. I suggest
> we focus on
> the protocol design, and not get lost in padlocks, green bars, blue badges
> or what not.
>
> Similarly, our use cases or requirements are not "create some art in the
> browser window"
>

Agree

> I'm sure the browser people can deal with their gui representation in the
> new world of
> TLS information that came from non-PKIX sources, DANE or otherwise.

Strongly disagree.

All the evidence from the usability 'experts' tells us that users (1) do not
notice the existence or otherwise of the low assurance security signal and
(2) do not understand what it means.

If people want to propose relying on a feature then they have to provide
evidence that it works. There is quite a lot of evidence to show that the EV
high assurance security signal is effective (shopping cart completion
rates).

I don't accept the argument that we can rely on a mechanism that we know to
be broken by ruling it out of scope. Better not to rely on that mechanism at
all.

We have the opportunity here to propose a scheme that does not require any
UI presentation that is no more complex to implement and has identical
performance characteristics to one that does.

All we need to do here is to design the mechanism in such a way that when a
DNS domain advertises a key/cert for protocol foo, that the relying party is
required to infer that this means that the genuine service will always offer
the corresponding security enhancement for protocol foo.

It does not mean having to make the protocol any more complex.

It does however require that we be very clear about our requirements and
what the precise semantics of the records are.

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

--20cf3054a133851c8604a02ef697
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Tue, Apr 5, 2011 at 12:42 PM, Paul Wo=
uters <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">paul@xele=
rance.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
This working group is designing a protocol, not a web browser UI. I suggest=
 we focus on<br>
the protocol design, and not get lost in padlocks, green bars, blue badges =
or what not.<br>
<br>
Similarly, our use cases or requirements are not &quot;create some art in t=
he browser window&quot;<br></blockquote><div><br></div><div>Agree</div><div=
><br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

I&#39;m sure the browser people can deal with their gui representation in t=
he new world of<br>
TLS information that came from non-PKIX sources, DANE or otherwise.</blockq=
uote><div><br></div><div>Strongly disagree.</div><div><br></div><div>All th=
e evidence from the usability &#39;experts&#39; tells us that users (1) do =
not notice the existence or otherwise of the low assurance security signal =
and (2) do not understand what it means.</div>
<div><br></div><div>If people want to propose relying on a feature then the=
y have to provide evidence that it works. There is quite a lot of evidence =
to show that the EV high assurance security signal is effective (shopping c=
art completion rates).</div>
<div><br></div><div><br></div><div>I don&#39;t accept the argument that we =
can rely on a mechanism that we know to be broken by ruling it out of scope=
. Better not to rely on that mechanism at all.</div><div><br></div><div>
We have the opportunity here to propose a scheme that does not require any =
UI presentation that is no more complex to implement and has identical perf=
ormance characteristics to one that does.=A0</div><div><br></div><div><br>
</div><div>All we need to do here is to design the mechanism in such a way =
that when a DNS domain advertises a key/cert for protocol foo, that the rel=
ying party is required to infer that this means that the genuine service wi=
ll always offer the corresponding security enhancement for protocol foo.</d=
iv>
<div><br></div><div>It does not mean having to make the protocol any more c=
omplex.=A0</div><div><br></div><div>It does however require that we be very=
 clear about our requirements and what the precise semantics of the records=
 are.</div>
<div><br></div></div>-- <br>Website: <a href=3D"http://hallambaker.com/">ht=
tp://hallambaker.com/</a><br><br>

--20cf3054a133851c8604a02ef697--

From [email-masked]  Tue Apr  5 10:15:51 2011
Date: Tue, 5 Apr 2011 13:17:31 -0400
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [dane] browser UI out of scope, was Re: Objective: Restrictive versus Supplementary Models

On Tue, Apr 05, 2011 at 01:11:11PM -0400, Phillip Hallam-Baker wrote:

> All we need to do here is to design the mechanism in such a way that when a
> DNS domain advertises a key/cert for protocol foo, that the relying party is
> required to infer that this means that the genuine service will always offer
> the corresponding security enhancement for protocol foo.

I thought the important thing to remember on the Internet was that you
are so not in charge, for every value of "you".  If that's right, then
I fail completely to understand how a level as low as the DNS is going
to "require" any inference on the part of the application layer.  This
entire thread seems to me to be a massive distraction.  Clients can do
what they want with information published in the DNS, and we're not
going to be the boss of them no matter how much we'd like to be.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

From [email-masked]  Tue Apr  5 10:30:35 2011
Date: Tue, 5 Apr 2011 19:32:16 +0200
From: Phillip Hallam-Baker <[email-masked]>
To: Andrew Sullivan <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] browser UI out of scope, was Re: Objective: Restrictive versus Supplementary Models

--20cf3071c9d0ebb30b04a02f4140
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Apr 5, 2011 at 7:17 PM, Andrew Sullivan <[email-masked]> wrote:

> On Tue, Apr 05, 2011 at 01:11:11PM -0400, Phillip Hallam-Baker wrote:
>
> > All we need to do here is to design the mechanism in such a way that when
> a
> > DNS domain advertises a key/cert for protocol foo, that the relying party
> is
> > required to infer that this means that the genuine service will always
> offer
> > the corresponding security enhancement for protocol foo.
>
> I thought the important thing to remember on the Internet was that you
> are so not in charge, for every value of "you".  If that's right, then
> I fail completely to understand how a level as low as the DNS is going
> to "require" any inference on the part of the application layer.  This
> entire thread seems to me to be a massive distraction.  Clients can do
> what they want with information published in the DNS, and we're not
> going to be the boss of them no matter how much we'd like to be.
>

There is a big difference between

1) Trust me when F(x) = True
2) Do not trust me when F(x) = False

The DNS would have to be very different for it to be used for case (1). It
is borderline sufficient for case (2) without DNSSEC and quite satisfactory
as one factor for case (2) with DNSSEC.

DANE is not about telling people which certificates or keys to trust, it is
all about what certificates, keys, security properties clients should NOT
trust.

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

--20cf3071c9d0ebb30b04a02f4140
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Tue, Apr 5, 2011 at 7:17 PM, Andrew S=
ullivan <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">ajs@shink=
uro.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">On Tue, Apr 05, 2011 at 01:11:11PM -0400, Phillip Hallam-=
Baker wrote:<br>
<br>
&gt; All we need to do here is to design the mechanism in such a way that w=
hen a<br>
&gt; DNS domain advertises a key/cert for protocol foo, that the relying pa=
rty is<br>
&gt; required to infer that this means that the genuine service will always=
 offer<br>
&gt; the corresponding security enhancement for protocol foo.<br>
<br>
</div>I thought the important thing to remember on the Internet was that yo=
u<br>
are so not in charge, for every value of &quot;you&quot;. =A0If that&#39;s =
right, then<br>
I fail completely to understand how a level as low as the DNS is going<br>
to &quot;require&quot; any inference on the part of the application layer. =
=A0This<br>
entire thread seems to me to be a massive distraction. =A0Clients can do<br=
>
what they want with information published in the DNS, and we&#39;re not<br>
going to be the boss of them no matter how much we&#39;d like to be.<br></b=
lockquote><div><br></div><div>There is a big difference between</div><div><=
br></div><div>1) Trust me when F(x) =3D True</div><div>2) Do not trust me w=
hen F(x) =3D False</div>
<div><br></div><div>The DNS would have to be very different for it to be us=
ed for case (1). It is borderline sufficient for case (2) without DNSSEC an=
d quite satisfactory as one factor for case (2) with DNSSEC.</div><div>
<br></div><div><br></div><div>DANE is not about telling people which certif=
icates or keys to trust, it is all about what certificates, keys, security =
properties clients should NOT trust.</div><div><br></div><div>=A0</div></di=
v>
-- <br>Website: <a href=3D"http://hallambaker.com/">http://hallambaker.com/=
</a><br><br>

--20cf3071c9d0ebb30b04a02f4140--

From [email-masked]  Tue Apr  5 10:45:56 2011
From: Paul Hoffman <[email-masked]>
Date: Tue, 5 Apr 2011 10:47:35 -0700
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] browser UI out of scope, was Re: Objective: Restrictive versus Supplementary Models

On Apr 5, 2011, at 10:32 AM, Phillip Hallam-Baker wrote:

> DANE is not about telling people which certificates or keys to trust, =
it is all about what certificates, keys, security properties clients =
should NOT trust.

That sounds like a requirement (not a use case) on which there has not =
been agreement here before. If the use cases you will be sending are not =
all predicated on that statement, when you send them, definitely please =
label which you think are and are not.

--Paul Hoffman

From [email-masked]  Tue Apr  5 10:46:41 2011
From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 5 Apr 2011 13:48:21 -0400
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] browser UI out of scope, was Re: Objective: Restrictive versus Supplementary Models

> DANE is not about telling people which certificates or keys to trust, =
it is all about what certificates, keys, security properties clients =
should NOT trust.

That seems directly contrary to all the people who expressed interest in =
Use Cases 3 and 4 in my taxonomy, both of which specify certificates =
that clients SHOULD trust.

--Richard=

From [email-masked]  Tue Apr  5 10:54:26 2011
Date: Tue, 5 Apr 2011 19:56:03 +0200
From: Phillip Hallam-Baker <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] browser UI out of scope, was Re: Objective: Restrictive versus Supplementary Models

--20cf307abea7fb633304a02f96a7
Content-Type: text/plain; charset=ISO-8859-1

The TLS protocol already allows the server to say to the client 'here is my
certificate, trust it'.

What DANE adds is the ability to say 'don't trust a certificate unless it
meets criteria X'

Which is how I read your two use cases.

OK, so maybe the statement is a little on the categorical side. But my point
is that we do not need to worry about the limitations of the DNS or DNSSEC
to do something that is useful.

On Tue, Apr 5, 2011 at 7:48 PM, Richard L. Barnes <[email-masked]> wrote:

> > DANE is not about telling people which certificates or keys to trust, it
> is all about what certificates, keys, security properties clients should NOT
> trust.
>
> That seems directly contrary to all the people who expressed interest in
> Use Cases 3 and 4 in my taxonomy, both of which specify certificates that
> clients SHOULD trust.
>
> --Richard

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

--20cf307abea7fb633304a02f96a7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

The TLS protocol already allows the server to say to the client &#39;here i=
s my certificate, trust it&#39;.<div><br></div><div>What DANE adds is the a=
bility to say &#39;don&#39;t trust a certificate unless it meets criteria X=
&#39;</div>
<div><br></div><div><br></div><div>Which is how I read your two use cases.=
=A0</div><div><br></div><div>OK, so maybe the statement is a little on the =
categorical side. But my point is that we do not need to worry about the li=
mitations of the DNS or DNSSEC to do something that is useful.=A0</div>
<div><br><br><div class=3D"gmail_quote">On Tue, Apr 5, 2011 at 7:48 PM, Ric=
hard L. Barnes <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">rba=
[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">&gt; DANE is not about telling people which certificates =
or keys to trust, it is all about what certificates, keys, security propert=
ies clients should NOT trust.<br>
<br>
</div>That seems directly contrary to all the people who expressed interest=
 in Use Cases 3 and 4 in my taxonomy, both of which specify certificates th=
at clients SHOULD trust.<br>
<font color=3D"#888888"><br>
--Richard</font></blockquote></div><br><br clear=3D"all"><br>-- <br>Website=
: <a href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--20cf307abea7fb633304a02f96a7--

From [email-masked]  Tue Apr  5 11:31:49 2011
To: Phillip Hallam-Baker <[email-masked]>
Comments: In-reply-to Phillip Hallam-Baker <[email-masked]> message dated "Tue, 05 Apr 2011 15:32:32 +0200."
Date: Tue, 05 Apr 2011 11:33:22 -0700
From: John Gilmore <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Objective: Restrictive versus Supplementary Models

Phillip Hallam-Baker asked:
> Anyone care to argue that mere possession of a DNS domain makes you
> trustworthy?

Anyone care to argue that mere possession of an EV certifying
authority trust anchor's private key makes you trustworthy?

Cryptography cannot enforce trustworthiness.  It can only, at best,
automate the validation of it.  DNSSEC and DANE will not guarantee
that the party you're communicating with won't screw you.  What it
will, in theory, guarantee is that your TCP connection hasn't been
tampered with and that you are actually connecting privately to the
party who registered the domain name you used.  Or to a henchman of
the corrupted domain registar or registry that that name was
registered in.

	John

From [email-masked]  Tue Apr  5 12:08:05 2011
Date: Tue, 5 Apr 2011 15:09:46 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: John Gilmore <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Objective: Restrictive versus Supplementary Models

--bcaec501641396cc5304a0309e59
Content-Type: text/plain; charset=ISO-8859-1

I think you are mistaken here, it depends on what your definition of
'trustworthy' is going to be. These are the definitions I use

Risk = The potential for harm

We quantify Risk through the equation Risk = cost-of-harm *
probability-of-harm
Ideally this should be performed as a summation across all the separate
types of risk or treat cost and probability as continuous variables.

Trust = confidence that risk has been adequately mitigated.

Since our possible actions are often limited, we typically end up treating
trust as a binary quantity, we either trust or do not. But in the general
case there may be degrees of trust.

I put my money in the bank because I see the FDIC sticker and conclude that
the risk of loss through bankruptcy is quite low.

Trusted = Something that is relied on

Trusted computing misses the point because almost all computers are trusted
to a far greater degree than they deserve.

Trustworthy = Something that is relied on because it meets the relying
party's criteria for trust.

Thus if I know that the DNS name of my bank is anybank.com, a DNS only
assurance may be sufficient to consider it trustworthy. Verifying my bank is
quite easy, verifying a random bank that I do not have a prior relationship
with is rather harder for me. So I want them to do rather more to prove that
they are trustworthy.

On Tue, Apr 5, 2011 at 2:33 PM, John Gilmore <[email-masked]> wrote:

> Phillip Hallam-Baker asked:
> > Anyone care to argue that mere possession of a DNS domain makes you
> > trustworthy?
>
> Anyone care to argue that mere possession of an EV certifying
> authority trust anchor's private key makes you trustworthy?
>
> Cryptography cannot enforce trustworthiness.  It can only, at best,
> automate the validation of it.  DNSSEC and DANE will not guarantee
> that the party you're communicating with won't screw you.  What it
> will, in theory, guarantee is that your TCP connection hasn't been
> tampered with and that you are actually connecting privately to the
> party who registered the domain name you used.  Or to a henchman of
> the corrupted domain registar or registry that that name was
> registered in.
>
>        John
>

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

--bcaec501641396cc5304a0309e59
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I think you are mistaken here, it depends on what your definition of &#39;t=
rustworthy&#39; is going to be. These are the definitions I use<div><br></d=
iv><div>Risk =3D The potential for harm</div><div><br></div><div>We quantif=
y Risk through the equation Risk =3D cost-of-harm * probability-of-harm</di=
v>
<div>Ideally this should be performed as a summation across all the separat=
e types of risk or treat cost and probability as continuous variables.</div=
><div><br></div><div><br></div><div>Trust =3D confidence that risk has been=
 adequately mitigated.</div>
<div><br></div><div>Since our possible actions are often limited, we typica=
lly end up treating trust as a binary quantity, we either trust or do not. =
But in the general case there may be degrees of trust.=A0</div><div><br></d=
iv>
<div>I put my money in the bank because I see the FDIC sticker and conclude=
 that the risk of loss through bankruptcy is quite low.</div><div><br></div=
><div><br></div><div>Trusted =3D Something that is relied on</div><div><br>
</div><div>Trusted computing misses the point because almost all computers =
are trusted to a far greater degree than they deserve.</div><div><br></div>=
<div><br></div><div>Trustworthy =3D Something that is relied on because it =
meets the relying party&#39;s criteria for trust.</div>
<div><br></div><div><br></div><div>Thus if I know that the DNS name of my b=
ank is <a href=3D"http://anybank.com">anybank.com</a>, a DNS only assurance=
 may be sufficient to consider it trustworthy. Verifying my bank is quite e=
asy, verifying a random bank that I do not have a prior relationship with i=
s rather harder for me. So I want them to do rather more to prove that they=
 are trustworthy.</div>
<div><br><div><br><div class=3D"gmail_quote">On Tue, Apr 5, 2011 at 2:33 PM=
, John Gilmore <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">gnu@to=
ad.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Phillip Hallam-Baker asked:<br>
<div class=3D"im">&gt; Anyone care to argue that mere possession of a DNS d=
omain makes you<br>
&gt; trustworthy?<br>
<br>
</div>Anyone care to argue that mere possession of an EV certifying<br>
authority trust anchor&#39;s private key makes you trustworthy?<br>
<br>
Cryptography cannot enforce trustworthiness. =A0It can only, at best,<br>
automate the validation of it. =A0DNSSEC and DANE will not guarantee<br>
that the party you&#39;re communicating with won&#39;t screw you. =A0What i=
t<br>
will, in theory, guarantee is that your TCP connection hasn&#39;t been<br>
tampered with and that you are actually connecting privately to the<br>
party who registered the domain name you used. =A0Or to a henchman of<br>
the corrupted domain registar or registry that that name was<br>
registered in.<br>
<font color=3D"#888888"><br>
 =A0 =A0 =A0 =A0John<br>
</font></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a href=
=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div></div>

--bcaec501641396cc5304a0309e59--

From [email-masked]  Tue Apr  5 15:26:03 2011
From: James Cloos <[email-masked]>
To: [email-masked]
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC
Copyright: Copyright 2011 James Cloos
OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
Date: Tue, 05 Apr 2011 18:22:18 -0400
Lines: 21
Cc: Paul Hoffman <[email-masked]>
Subject: Re: [dane] [keyassure] Use cases document.

>>>>> "PH" == Paul Hoffman <[email-masked]> writes:

PH> That's not a "technical point", it is a fundamental feature. With #3,
PH> #4 becomes pretty irrelevant and implementers have fewer different
PH> semantics to deal with.

Case 4 still has the advantages that it is easier, has fewer nodes in the
graph and therefore fewer place to fail, etc.

It is simply more likely that end users will grok it and, therefore, use it.

Correctly, even.

For those of us who understand how it works and for those who employ
someone who understands how it works, case 3 has some benefits.

But more most people case 4 is better.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

From [email-masked]  Tue Apr  5 16:13:31 2011
From: Paul Hoffman <[email-masked]>
Date: Tue, 5 Apr 2011 16:14:47 -0700
To: James Cloos <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

On Apr 5, 2011, at 3:22 PM, James Cloos wrote:

>>>>>> "PH" =3D=3D Paul Hoffman <[email-masked]> writes:
>=20
> PH> That's not a "technical point", it is a fundamental feature. With =
#3,
> PH> #4 becomes pretty irrelevant and implementers have fewer different
> PH> semantics to deal with.
>=20
> Case 4 still has the advantages that it is easier, has fewer nodes in =
the
> graph and therefore fewer place to fail, etc.
>=20
> It is simply more likely that end users will grok it and, therefore, =
use it.
>=20
> Correctly, even.
>=20
> For those of us who understand how it works and for those who employ
> someone who understands how it works, case 3 has some benefits.
>=20
> But more most people case 4 is better.

Given that we are trying to capture use cases and requirements, can you =
cast your message as one or both of those?

--Paul Hoffman

From [email-masked]  Tue Apr  5 16:32:02 2011
Date: Tue, 5 Apr 2011 23:33:44 +0000
From: Phillip Hallam-Baker <[email-masked]>
To: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

--bcaec50166a5a32f1a04a0344e7c
Content-Type: text/plain; charset=ISO-8859-1

OK, as promised at the WG meeting, here is a first cut at a requirements
document based on the use cases and requirements analysis that I have done
to support my earlier proposals in this area.

I have cut down the original documents to make this more manageable. What I
have not done (yet) is to draw up the correspondance matrices that link the
use cases to the requirements and so on. Nor have I got the links in
hypertext form.

The idea is that each use case should list the requirements it motivates and
vice versa. Every requirement should be driven by at least one use case.

What I have not quite worked out at this point is how to make use of the
attacker model to derive requirements from the use cases. Part of the point
of specifying the attacker profiles is that a proposal should not get credit
for blocking an attack A1 that allows attacker X to have effect Y if the
same attacker can realize Y through attack A2 that is also in their
capabilities.

http://www.ietf.org/id/draft-hallambaker-dane-requirements-00.txt

I have put this in as a personal submission so as not to pre-empt the WG
decision. But am quite happy if the WG wants to adopt it.

Its also missing an acknowledgements section, many of these use cases were
captured during our earlier arguments on the list.

Phill

--bcaec50166a5a32f1a04a0344e7c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>OK, as promised at the WG meeting, here is a first cut at a requiremen=
ts document based on the use cases and requirements analysis that I have do=
ne to support my earlier proposals in this area.</div><div><br></div><div>
I have cut down the original documents to make this more manageable. What I=
 have not done (yet) is to draw up the correspondance matrices that link th=
e use cases to the requirements and so on. Nor have I got the links in hype=
rtext form.</div>
<div><br></div><div>The idea is that each use case should list the requirem=
ents it motivates and vice versa. Every requirement should be driven by at =
least one use case.</div><div><br></div><div>What I have not quite worked o=
ut at this point is how to make use of the attacker model to derive require=
ments from the use cases. Part of the point of specifying the attacker prof=
iles is that a proposal should not get credit for blocking an attack A1 tha=
t allows attacker X to have effect Y if the same attacker can realize Y thr=
ough attack A2 that is also in their capabilities.=A0</div>
<div><br></div><a href=3D"http://www.ietf.org/id/draft-hallambaker-dane-req=
uirements-00.txt">http://www.ietf.org/id/draft-hallambaker-dane-requirement=
s-00.txt</a>
<div><br></div><div><br></div><div>I have put this in as a personal submiss=
ion so as not to pre-empt the WG decision. But am quite happy if the WG wan=
ts to adopt it.<br><br></div><div>Its also missing an acknowledgements sect=
ion, many of these use cases were captured during our earlier arguments on =
the list.</div>
<div><br></div><div>Phill</div>

--bcaec50166a5a32f1a04a0344e7c--

From [email-masked]  Wed Apr  6 04:54:53 2011
To: Paul Wouters <[email-masked]>
From: Florian Weimer <[email-masked]>
Date: Wed, 06 Apr 2011 11:56:32 +0000
Cc: [email-masked]
Subject: Re: [dane] browser UI out of scope

* Paul Wouters:

> This working group is designing a protocol, not a web browser UI. I
> suggest we focus on the protocol design, and not get lost in
> padlocks, green bars, blue badges or what not.

Oh, could you please clarify what you mean by this: Do you want to
design a protocol, without consideration for the UI side?  Or do you
want to design a protocol which does not require UI changes?  Or
something else entirely?

--=20
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstra=DFe 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

From [email-masked]  Wed Apr  6 05:03:34 2011
Date: Wed, 6 Apr 2011 08:05:15 -0400
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [dane] browser UI out of scope

On Wed, Apr 06, 2011 at 11:56:32AM +0000, Florian Weimer wrote:
> Oh, could you please clarify what you mean by this: Do you want to
> design a protocol, without consideration for the UI side?  Or do you
> want to design a protocol which does not require UI changes?  Or
> something else entirely?

What UI side?

I agree, wholeheartedly, that there is a UI problem here, that it
needs attention, and that just about anything would be better than the
miserable UIs that marked most of the history of SSL/TLS.  I don't
believe anyone is contesting that.

But the problem we are engaged in solving is how to communicate the
availability of certain facilities (and maybe the preferability of
thos facilities) via the DNS.  If the same communication came by
carrier pigeon, smoke signal, telegraph, or slips of paper handed
around by neighbours, there would be a UI problem.  That UI problem is
entirely separable from the problem of the underlying messages.

So, I say that those who think there is a special UI problem that
needs to be solved here, and by this group of people (a group not, as
nearly as I can tell, instantiating a great load of special UI
expertise), need to present an argument about what is special for the
UI in this case and what particular details need to be available from
the underlying layer.  Otherwise, I claim the talk of UI issues is
just hand waving, and I ask the chairs to declare it out of scope.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

From [email-masked]  Wed Apr  6 05:24:26 2011
From: Paul Hoffman <[email-masked]>
Date: Wed, 6 Apr 2011 05:26:02 -0700
To: Florian Weimer <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] browser UI out of scope

On Apr 6, 2011, at 4:56 AM, Florian Weimer wrote:

> * Paul Wouters:
>=20
>> This working group is designing a protocol, not a web browser UI. I
>> suggest we focus on the protocol design, and not get lost in
>> padlocks, green bars, blue badges or what not.
>=20
> Oh, could you please clarify what you mean by this: Do you want to
> design a protocol, without consideration for the UI side?  Or do you
> want to design a protocol which does not require UI changes?  Or
> something else entirely?

Speaking for myself: the first. TLSA applies to TLS, not "TLS but only =
in a web browser". This is completely clear in the document. There is no =
equivalent of a "lock icon" when a mail program downloads mail using =
IMAP or POP using TLS, and this is the wrong place to say that there =
should be (more than a decade later...). Similarly, many TLS-using =
scenarios involve clients and servers with no humans watching.

--Paul Hoffman

From [email-masked]  Wed Apr  6 05:57:15 2011
Date: Wed, 6 Apr 2011 12:58:55 +0000
From: Phillip Hallam-Baker <[email-masked]>
To: Andrew Sullivan <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] browser UI out of scope

--20cf307cfc682eb2a004a03f8e53
Content-Type: text/plain; charset=ISO-8859-1

I am quite happy to rule UI issues out of scope, PROVIDED that we also ban
any proposal that depends on UI.

If people are going to propose schemes that depend on UI, then they have to
demonstrate that they understand the UI issues involved. Ruling an issue
area out of scope does not mean that it can be regarded as magic pixie dust.

Not understanding an issue is not a reason to rule it out of scope. the
people who want to design protocols that depend on what they admit do not
understand are what we should rule out of scope.

There is indeed quite a bit of literature on the topic. In my view this
means that people who want to design security protocols must read it. At a
minimum people who want to design protocols with UI implications need to
talk to the people involved.

For years security people complained that nobody bothered to consider their
issues, security was an optional extra that was thrown in at the end of the
design process. Now we have security people arguing for the same approach to
UI.

In fact security UI design turns out to be really easy. The user is not
going to respond to UI cues unless (1) they are really intrusive, (2) they
are protecting an asset that the user considers important and (3) are
comprehensible to the user.

The green bar works because those criteria are met. The padlock icon does
not.

The other aspect of security usability is that the people who are
responsible for browser security have very little leverage when it comes to
UI issues. The priority in browser UI design has always been ease of use. If
people want to find out about these issues it is quite easy, they just need
to talk to the people involved.

The padlock icon only exists in current generation browsers because it is
grandfathered. Domain Validated keys should be ubiquitous and should
therefore require no security signal.

It is quite easy to design a DANE scheme that does not depend on the padlock
icon. Just design the protocol so that a client can determine that TLS is
offered. This allows the client to take over the job of checking for channel
security from the user. The user is only involved then when there is a
requirement to verify accountability.

On Wed, Apr 6, 2011 at 12:05 PM, Andrew Sullivan <[email-masked]> wrote:

> On Wed, Apr 06, 2011 at 11:56:32AM +0000, Florian Weimer wrote:
> > Oh, could you please clarify what you mean by this: Do you want to
> > design a protocol, without consideration for the UI side?  Or do you
> > want to design a protocol which does not require UI changes?  Or
> > something else entirely?
>
> What UI side?
>
> I agree, wholeheartedly, that there is a UI problem here, that it
> needs attention, and that just about anything would be better than the
> miserable UIs that marked most of the history of SSL/TLS.  I don't
> believe anyone is contesting that.
>
> But the problem we are engaged in solving is how to communicate the
> availability of certain facilities (and maybe the preferability of
> thos facilities) via the DNS.  If the same communication came by
> carrier pigeon, smoke signal, telegraph, or slips of paper handed
> around by neighbours, there would be a UI problem.  That UI problem is
> entirely separable from the problem of the underlying messages.
>
> So, I say that those who think there is a special UI problem that
> needs to be solved here, and by this group of people (a group not, as
> nearly as I can tell, instantiating a great load of special UI
> expertise), need to present an argument about what is special for the
> UI in this case and what particular details need to be available from
> the underlying layer.  Otherwise, I claim the talk of UI issues is
> just hand waving, and I ask the chairs to declare it out of scope.
>
> A
>
> --
> Andrew Sullivan
> [email-masked]
> Shinkuro, Inc.
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

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

--20cf307cfc682eb2a004a03f8e53
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I am quite happy to rule UI issues out of scope, PROVIDED that we also ban =
any proposal that depends on UI.<div><br></div><div>If people are going to =
propose schemes that depend on UI, then they have to demonstrate that they =
understand the UI issues involved. Ruling an issue area out of scope does n=
ot mean that it can be regarded as magic pixie dust.</div>
<div><br></div><div>Not understanding an issue is not a reason to rule it o=
ut of scope. the people who want to design protocols that depend on what th=
ey admit do not understand are what we should rule out of scope.</div><div>
<br></div><div><br></div><div>There is indeed quite a bit of literature on =
the topic. In my view this means that people who want to design security pr=
otocols must read it. At a minimum people who want to design protocols with=
 UI implications need to talk to the people involved.</div>
<div><br></div><div>For years security people complained that nobody bother=
ed to consider their issues, security was an optional extra that was thrown=
 in at the end of the design process. Now we have security people arguing f=
or the same approach to UI.=A0</div>
<div><br></div><div>In fact security UI design turns out to be really easy.=
 The user is not going to respond to UI cues unless (1) they are really int=
rusive, (2) they are protecting an asset that the user considers important =
and (3) are comprehensible to the user.</div>
<div><br></div><div>The green bar works because those criteria are met. The=
 padlock icon does not.</div><div><br></div><div>The other aspect of securi=
ty usability is that the people who are responsible for browser security ha=
ve very little leverage when it comes to UI issues. The priority in browser=
 UI design has always been ease of use. If people want to find out about th=
ese issues it is quite easy, they just need to talk to the people involved.=
</div>
<div><br></div><div><div><br></div><div>The padlock icon only exists in cur=
rent generation browsers because it is grandfathered. Domain Validated keys=
 should be ubiquitous and should therefore require no security signal.</div=
>
<div><br></div><div>It is quite easy to design a DANE scheme that does not =
depend on the padlock icon. Just design the protocol so that a client can d=
etermine that TLS is offered. This allows the client to take over the job o=
f checking for channel security from the user. The user is only involved th=
en when there is a requirement to verify accountability.</div>
<div><br></div><div><br><div class=3D"gmail_quote">On Wed, Apr 6, 2011 at 1=
2:05 PM, Andrew Sullivan <span dir=3D"ltr">&lt;<a href=3D"mailto:ajs@shinku=
ro.com">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex;">
<div class=3D"im">On Wed, Apr 06, 2011 at 11:56:32AM +0000, Florian Weimer =
wrote:<br>
&gt; Oh, could you please clarify what you mean by this: Do you want to<br>
&gt; design a protocol, without consideration for the UI side? =A0Or do you=
<br>
&gt; want to design a protocol which does not require UI changes? =A0Or<br>
&gt; something else entirely?<br>
<br>
</div>What UI side?<br>
<br>
I agree, wholeheartedly, that there is a UI problem here, that it<br>
needs attention, and that just about anything would be better than the<br>
miserable UIs that marked most of the history of SSL/TLS. =A0I don&#39;t<br=
>
believe anyone is contesting that.<br>
<br>
But the problem we are engaged in solving is how to communicate the<br>
availability of certain facilities (and maybe the preferability of<br>
thos facilities) via the DNS. =A0If the same communication came by<br>
carrier pigeon, smoke signal, telegraph, or slips of paper handed<br>
around by neighbours, there would be a UI problem. =A0That UI problem is<br=
>
entirely separable from the problem of the underlying messages.<br>
<br>
So, I say that those who think there is a special UI problem that<br>
needs to be solved here, and by this group of people (a group not, as<br>
nearly as I can tell, instantiating a great load of special UI<br>
expertise), need to present an argument about what is special for the<br>
UI in this case and what particular details need to be available from<br>
the underlying layer. =A0Otherwise, I claim the talk of UI issues is<br>
just hand waving, and I ask the chairs to declare it out of scope.<br>
<br>
A<br>
<font color=3D"#888888"><br>
--<br>
Andrew Sullivan<br>
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
Shinkuro, Inc.<br>
</font><div><div></div><div class=3D"h5">__________________________________=
_____________<br>
dane mailing list<br>
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/dane</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div></div>

--20cf307cfc682eb2a004a03f8e53--

From [email-masked]  Wed Apr  6 06:06:24 2011
Date: Wed, 6 Apr 2011 13:08:06 +0000
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] browser UI out of scope

--20cf3054a1130165ba04a03faf61
Content-Type: text/plain; charset=ISO-8859-1

Paul is exactly right here.

We have to cover cases where there is no UI at all. Including cases where
there is no Human Interaction (HI) because there is no human in the loop.

STARTTLS is a very good example. The mailing list software that supports
this list has to work without any human intervention whatsoever. No human,
no human interaction.

We can approach the problem in stages. For example, we could decide to
design a RR that is extensible so that we can first address the requirement
for Domain Validated keys and after that is done address the requirement for
verifying that TLS is used to secure the connection.

On Wed, Apr 6, 2011 at 12:26 PM, Paul Hoffman <[email-masked]> wrote:

> On Apr 6, 2011, at 4:56 AM, Florian Weimer wrote:
>
> > * Paul Wouters:
> >
> >> This working group is designing a protocol, not a web browser UI. I
> >> suggest we focus on the protocol design, and not get lost in
> >> padlocks, green bars, blue badges or what not.
> >
> > Oh, could you please clarify what you mean by this: Do you want to
> > design a protocol, without consideration for the UI side?  Or do you
> > want to design a protocol which does not require UI changes?  Or
> > something else entirely?
>
> Speaking for myself: the first. TLSA applies to TLS, not "TLS but only in a
> web browser". This is completely clear in the document. There is no
> equivalent of a "lock icon" when a mail program downloads mail using IMAP or
> POP using TLS, and this is the wrong place to say that there should be (more
> than a decade later...). Similarly, many TLS-using scenarios involve clients
> and servers with no humans watching.
>
> --Paul Hoffman
>
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

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

--20cf3054a1130165ba04a03faf61
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Paul is exactly right here.<div><br></div><div>We have to cover cases where=
 there is no UI at all. Including cases where there is no Human Interaction=
 (HI) because there is no human in the loop.</div><div><br></div><div>START=
TLS is a very good example. The mailing list software that supports this li=
st has to work without any human intervention whatsoever. No human, no huma=
n interaction.</div>
<div><br></div><div><br></div><div>We can approach the problem in stages. F=
or example, we could decide to design a RR that is extensible so that we ca=
n first address the requirement for Domain Validated keys and after that is=
 done address the requirement for verifying that TLS is used to secure the =
connection.</div>
<div><br></div><div><br><div class=3D"gmail_quote">On Wed, Apr 6, 2011 at 1=
2:26 PM, Paul Hoffman <span dir=3D"ltr">&lt;<a href=3D"mailto:paul.hoffman@=
vpnc.org">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex;">
<div class=3D"im">On Apr 6, 2011, at 4:56 AM, Florian Weimer wrote:<br>
<br>
&gt; * Paul Wouters:<br>
&gt;<br>
&gt;&gt; This working group is designing a protocol, not a web browser UI. =
I<br>
&gt;&gt; suggest we focus on the protocol design, and not get lost in<br>
&gt;&gt; padlocks, green bars, blue badges or what not.<br>
&gt;<br>
&gt; Oh, could you please clarify what you mean by this: Do you want to<br>
&gt; design a protocol, without consideration for the UI side? =A0Or do you=
<br>
&gt; want to design a protocol which does not require UI changes? =A0Or<br>
&gt; something else entirely?<br>
<br>
</div>Speaking for myself: the first. TLSA applies to TLS, not &quot;TLS bu=
t only in a web browser&quot;. This is completely clear in the document. Th=
ere is no equivalent of a &quot;lock icon&quot; when a mail program downloa=
ds mail using IMAP or POP using TLS, and this is the wrong place to say tha=
t there should be (more than a decade later...). Similarly, many TLS-using =
scenarios involve clients and servers with no humans watching.<br>

<font color=3D"#888888"><br>
--Paul Hoffman<br>
</font><div><div></div><div class=3D"h5"><br>
_______________________________________________<br>
dane mailing list<br>
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/dane</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--20cf3054a1130165ba04a03faf61--

From [email-masked]  Wed Apr  6 06:42:57 2011
From: Matt McCutchen <[email-masked]>
To: [email-masked]
Date: Wed, 06 Apr 2011 09:44:38 -0400
Subject: [dane] Of interest: Mozilla server authentication meeting today, 16-18 UTC

FYI: Mozilla is having a public meeting 16:00-18:00 UTC today to discuss
the future of server authentication for its products:

https://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/de464e2c6157f896/4a47f72729953dad#4a47f72729953dad

As you are probably aware, the open-source world tends to follow
Mozilla's lead.  So this could be a huge opportunity to promote better
schemes.  I will most likely join for the second hour.

-- 
Matt

From [email-masked]  Wed Apr  6 07:51:55 2011
From: James Cloos <[email-masked]>
To: Paul Hoffman <[email-masked]>
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC
Copyright: Copyright 2011 James Cloos
OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
Date: Wed, 06 Apr 2011 10:38:05 -0400
Lines: 37
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

>>>>> "PH" == Paul Hoffman <[email-masked]> writes:

PH> Given that we are trying to capture use cases and requirements,
PH> can you cast your message as one or both of those?

What exactly do you want?

The point is that, even though specifying a CA cert in the RR /can/
cover the fourth case, the fact that doing so requires that the users:

create a ca
create a private key for each server
create a csr for each server
sign each csr with their ca
append the ca cert to the resulting signed cert
provide the above to said server(s)
specify the ca cert in each dtls rr

rather than the simpler:

create a private key for each server
create a self-signed cert for each server
provide the above to said server(s)
specify said cert in each dtls rr

means that those who don't really understand it all likely will be
put off by the complexity.  And will therefor avoid it.

The simpler version is not only easier, but can be automated
server-by-server (ie, at package install time), doesn't require
securely saving as much state (ie the ca).  Et cetera.

The simpler version is just more likely to happen.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

From [email-masked]  Wed Apr  6 08:16:39 2011
From: Paul Hoffman <[email-masked]>
Date: Wed, 6 Apr 2011 08:18:20 -0700
To: James Cloos <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

On Apr 6, 2011, at 7:38 AM, James Cloos wrote:

>>>>>> "PH" =3D=3D Paul Hoffman <[email-masked]> writes:
>=20
> PH> Given that we are trying to capture use cases and requirements,
> PH> can you cast your message as one or both of those?
>=20
> What exactly do you want?

A list of requirements or use cases that are relevant to you. That's the =
purpose of this thread.

> The point is that, even though specifying a CA cert in the RR /can/
> cover the fourth case, the fact that doing so requires that the users:
>=20
> create a ca
> create a private key for each server
> create a csr for each server
> sign each csr with their ca
> append the ca cert to the resulting signed cert
> provide the above to said server(s)
> specify the ca cert in each dtls rr
>=20
> rather than the simpler:
>=20
> create a private key for each server
> create a self-signed cert for each server
> provide the above to said server(s)
> specify said cert in each dtls rr
>=20
> means that those who don't really understand it all likely will be
> put off by the complexity.  And will therefor avoid it.

That's certainly possible, but given how easy it would be for someone to =
write a very short script that generates both that says at the end =
"here's the text to paste into your BIND file and here's the cert to be =
pointed to in TLS", it is likely that some "who don't really understand =
it all" will still use DANE.=20

> The simpler version is not only easier, but can be automated
> server-by-server (ie, at package install time), doesn't require
> securely saving as much state (ie the ca).  Et cetera.

The CA does not need to be saved securely. In fact, you can delete the =
private key after issuing the end-entity key.

> The simpler version is just more likely to happen.

Not unless someone writes up use cases and/or requirements for it...

--Paul Hoffman

From [email-masked]  Wed Apr  6 08:29:37 2011
Date: Wed, 6 Apr 2011 11:13:37 -0400
To: Paul Hoffman <[email-masked]>
From: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] browser UI out of scope

At 5:26 AM -0700 4/6/11, Paul Hoffman wrote:
>On Apr 6, 2011, at 4:56 AM, Florian Weimer wrote:
>
>>  * Paul Wouters:
>>
>>>  This working group is designing a protocol, not a web browser UI. I
>>>  suggest we focus on the protocol design, and not get lost in
>>>  padlocks, green bars, blue badges or what not.
>>
>>  Oh, could you please clarify what you mean by this: Do you want to
>>  design a protocol, without consideration for the UI side?  Or do you
>>  want to design a protocol which does not require UI changes?  Or
>>  something else entirely?
>
>Speaking for myself: the first. TLSA applies to TLS, not "TLS but 
>only in a web browser". This is completely clear in the document. 
>There is no equivalent of a "lock icon" when a mail program 
>downloads mail using IMAP or POP using TLS, and this is the wrong 
>place to say that there should be (more than a decade later...). 
>Similarly, many TLS-using scenarios involve clients and servers with 
>no humans watching.
>
>--Paul Hoffman

+1

Steve

From [email-masked]  Wed Apr  6 09:49:13 2011
To: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 06 Apr 2011 09:48:12 -0700
From: Mike Helm <[email-masked]>
Cc: Paul Hoffman <[email-masked]>, [email-masked]
Subject: Re: [dane] browser UI out of scope
Reply-To: [email-masked]

Phillip Hallam-Baker writes:
> We have to cover cases where there is no UI at all. Including cases where
> there is no Human Interaction (HI) because there is no human in the loop.

> We can approach the problem in stages. For example, we could decide to
> design a RR that is extensible so that we can first address the requirement
> for Domain Validated keys and after that is done address the requirement for
> verifying that TLS is used to secure the connection.

> On Wed, Apr 6, 2011 at 12:26 PM, Paul Hoffman <[email-masked]> wrote:
> > Speaking for myself: the first. TLSA applies to TLS, not "TLS but only in a
> > web browser". This is completely clear in the document. There is no

There are many usage scenarios that could benefit from broader non-web browser
support and the staged approach sounds like a good direction.  Newer
identity services like SAML-based infrastructure or newer openid and oauth
are highly leveraged on tls and digital signature for security and some
of that traffic is outside browsers.  Grid computing is highly dependent
on messages secured by a tls-like protocol between servers.  Authentication
to wireless providers especially when done over WAN (like Eduroam) is
dependent on TLS and sometimes on specialized credential issuers that
need DANE for other reasons.

Thanks, ==mwh
Michael Helm
ESnet/LBNL

From [email-masked]  Wed Apr  6 11:23:41 2011
Date: Wed, 6 Apr 2011 14:24:49 -0400
To: James Cloos <[email-masked]>
From: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

Jim,

I think the steps you cite, while mostly accurate, are not a good
basis of comparison.  let me explain.

When one issues a cert one needs to provide the public key
and the other parameters that go into the cert, and one specifies
a private key that is used to sign the cert. If one uses crypto
primitives (vs. a CA implementation), this procedure should be
the same whether the cert is self-signed or not. The only differences
are the private key used, and some of the bits in the cert contents.

 From that perspective, what one does for a CA-based scenario is:

A. generate a key pair
B. issue a CA cert with the public key from that pair,
	signed by the private key from that pair
C. generate a key pair
D. issue an EE cert for the server using the public key from
	that key pair, signed under the CA's private key
E. put the CA cert in the RR
F. transport the EE cert in the TLS server hello message

For a self-signed cert used as an EE cert (contrary to 5280 specs)
steps C-F are the same. Only steps A+B are additional for the CA
model, and they are the same as steps C+D, modulo the cert contents
and the private key used.

If one has multiple servers, steps A+B are executed just once, so
the CA cert generation overhead is amortized over repetition of steps C+D.

Steve

P.S. I didn't understand your step "append the ca cert to the 
resulting signed cert"

From [email-masked]  Thu Apr  7 01:12:55 2011
To: [email-masked]
Comments: In-reply-to Phillip Hallam-Baker <[email-masked]> message dated "Tue, 05 Apr 2011 23:33:44 -0000."
Date: Thu, 07 Apr 2011 01:14:35 -0700
From: John Gilmore <[email-masked]>
Subject: Re: [dane] Use cases document.

Thank you, Phillip, for making a first cut at a use-case draft.  However...

One part I don't understand is that this draft comes with a copyright
notice in the very first paragraph, stating that neither modifications
nor derived works may be created.  I.e. nobody can edit this draft
except Phillip.  That appears to mean, according to BCP 78 and the
IETF Trust License Policy (TLP), that we have to start over from
scratch if he declines to "let us" revise it in ways that the
committee chooses.

Given his stance, I recommend that the working group ignore his text
and start over immediately with text written by someone else, rather
than wasting time discussing a useless draft (and perhaps
unconsciously absorbing copyrighted material that, if it appeared in a
later Working Group draft, would give Phillip a copyright claim
against the IETF).  The TLP v4 section 6c (from whence he drew his "no
modifications" text) makes it clear that "an IETF contribution with
such a notice cannot become a Standards Track document or, in most
cases, a working group document."

He said:
> I have put this in as a personal submission so as not to pre-empt the WG
> decision. But am quite happy if the WG wants to adopt it.

The WG *cannot* adopt it - and should not, for reasons beyond the copyright.

One thing I noticed before delving into the copyright and then
abandoning the document is that Phillip wouldn't be very predictable
if he hadn't jiggered the draft so that it's all about the
Certificates.  X.509 certificates.  It's buried right into the
definitions in pages 3 and 4; a "Relying Application" or "Relying
Party" isn't relying on public-key crypto; no, they're relying on a
"Certificate", which is defined as "An X.509 Certificate".

It's all a bit too transparent.

	John

From [email-masked]  Thu Apr  7 01:21:12 2011
To: Paul Hoffman <[email-masked]>
From: Florian Weimer <[email-masked]>
Date: Thu, 07 Apr 2011 08:22:51 +0000
Cc: [email-masked]
Subject: Re: [dane] browser UI out of scope

* Paul Hoffman:

>> Oh, could you please clarify what you mean by this: Do you want to
>> design a protocol, without consideration for the UI side?  Or do you
>> want to design a protocol which does not require UI changes?  Or
>> something else entirely?
>
> Speaking for myself: the first. TLSA applies to TLS, not "TLS but
> only in a web browser". This is completely clear in the
> document. There is no equivalent of a "lock icon" when a mail
> program downloads mail using IMAP or POP using TLS,

But mail clients usually have an option "require secure connection".
At some point, someone has to decide whether TLSA provides a secure
connection in the sense of the option.

In a similar fashion, someone needs to determine how TLSA and RFC 2109
interact.  At least this is entirely a protocol question, so you can't
escape it by saying that you don't do UI.  But the answer to this
question indirectly determines the UI aspect, too.

--=20
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstra=DFe 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

From [email-masked]  Thu Apr  7 02:00:40 2011
From: Henry Story <[email-masked]>
Date: Thu, 7 Apr 2011 11:02:16 +0200
To: Florian Weimer <[email-masked]>
Cc: Paul Hoffman <[email-masked]>, [email-masked]
Subject: Re: [dane] browser UI out of scope

On 7 Apr 2011, at 10:22, Florian Weimer wrote:

> * Paul Hoffman:
>=20
>>> Oh, could you please clarify what you mean by this: Do you want to
>>> design a protocol, without consideration for the UI side?  Or do you
>>> want to design a protocol which does not require UI changes?  Or
>>> something else entirely?
>>=20
>> Speaking for myself: the first. TLSA applies to TLS, not "TLS but
>> only in a web browser". This is completely clear in the
>> document. There is no equivalent of a "lock icon" when a mail
>> program downloads mail using IMAP or POP using TLS,
>=20
> But mail clients usually have an option "require secure connection".
> At some point, someone has to decide whether TLSA provides a secure
> connection in the sense of the option.
>=20
> In a similar fashion, someone needs to determine how TLSA and RFC 2109
> interact.  At least this is entirely a protocol question, so you can't
> escape it by saying that you don't do UI.  But the answer to this
> question indirectly determines the UI aspect, too.

Sending a message is a UI element - a machine readable UI element if you =
want. Those can then be translate into a number of other formats, or =
languages, such as visual ones with browsers, sound for telephones,... =
The information in the end goes into a database be it a wetware one like =
a brain, or software based one. In any case the hope is that it then =
affects subsequent behavior, though how it will do so will depend on =
policies set.

The bahavior can be completely situation specific. This is what =
behaviorists discovered when they tried  unsuccessfully to reduce mental =
processes to behavior in the middle part of the 20th century. A "warning =
fire" will tell most people to get out of the way, except of course for =
the fireman who will rush in that direction. A "warning lower security" =
will get most people to abort what they are doing, but others will just =
provide false information - a tactic I imagine must have been very =
prevalent in the Soviet Union.

So there is a message, or a number of security messages that can be =
sent, and it is up to apps to later make use of that. How they make use =
of it, is as pointed out above impossible to define in advance without =
taking the precise situation into account.=20

What Dane can provide is a new security message, that is simple to =
implement, that can be widely deployed and that can do a lot to improve =
the previous message.

Henry

>=20
> --=20
> Florian Weimer                <[email-masked]>
> BFK edv-consulting GmbH       http://www.bfk.de/
> Kriegsstra=DFe 100              tel: +49-721-96201-1
> D-76133 Karlsruhe             fax: +49-721-96201-99
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

Social Web Architect
http://bblfish.net/

From [email-masked]  Thu Apr  7 05:04:26 2011
Date: Thu, 7 Apr 2011 12:06:08 +0000
From: Phillip Hallam-Baker <[email-masked]>
To: John Gilmore <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] Use cases document.

--bcaec5171ea73c638a04a052ef7a
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Apr 7, 2011 at 8:14 AM, John Gilmore <[email-masked]> wrote:

> Thank you, Phillip, for making a first cut at a use-case draft.  However...
>
> One part I don't understand is that this draft comes with a copyright
> notice in the very first paragraph, stating that neither modifications
> nor derived works may be created.  I.e. nobody can edit this draft
> except Phillip.  That appears to mean, according to BCP 78 and the
> IETF Trust License Policy (TLP), that we have to start over from
> scratch if he declines to "let us" revise it in ways that the
> committee chooses.
>

Nah, that is just an oversight.

The reason that I use it on individual submissions is that once in the past
we did the same with the code and specifications for HTTP and HTML. NCSA
then released a new browser where 70% of the code came from CERN but did not
mention CERN, the use of the code or the 'World Wide Web' in any way
whatsoever. As a direct result, CERN management stopped supporting the Web
and I had to move to MIT.

I also had the same thing happen to me on the OCSP draft.

So my default is to use the XML for the non-modifiable license. I can change
that if folk actually care. To be honest, I don't actually read the
boilerplate.

The WG *cannot* adopt it - and should not, for reasons beyond the copyright.
>
> One thing I noticed before delving into the copyright and then
> abandoning the document is that Phillip wouldn't be very predictable
> if he hadn't jiggered the draft so that it's all about the
> Certificates.  X.509 certificates.  It's buried right into the
> definitions in pages 3 and 4; a "Relying Application" or "Relying
> Party" isn't relying on public-key crypto; no, they're relying on a
> "Certificate", which is defined as "An X.509 Certificate".
>

That is because the text for the definitions was copied over from the CAA
draft which is intentionally limited to X.509 because we don't want CAA
properties intended to restrict issue of certs from public CAs to muck up
SAML and/or PGP without actually thinking about it. That does not really
apply here.

I will fix these later on today.

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

--bcaec5171ea73c638a04a052ef7a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Thu, Apr 7, 2011 at 8:14 AM, John Gil=
more <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>=
&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Thank you, Phillip, for making a first cut at a use-case draft. =A0However.=
..<br>
<br>
One part I don&#39;t understand is that this draft comes with a copyright<b=
r>
notice in the very first paragraph, stating that neither modifications<br>
nor derived works may be created. =A0I.e. nobody can edit this draft<br>
except Phillip. =A0That appears to mean, according to BCP 78 and the<br>
IETF Trust License Policy (TLP), that we have to start over from<br>
scratch if he declines to &quot;let us&quot; revise it in ways that the<br>
committee chooses.<br></blockquote><div><br></div><div>Nah, that is just an=
 oversight.</div><div><br></div><div>The reason that I use it on individual=
 submissions is that once in the past we did the same with the code and spe=
cifications for HTTP and HTML. NCSA then released a new browser where 70% o=
f the code came from CERN but did not mention CERN, the use of the code or =
the &#39;World Wide Web&#39; in any way whatsoever.=A0As a direct result, C=
ERN management stopped supporting the Web and I had to move to MIT.</div>
<div><br></div><div>I also had the same thing happen to me on the OCSP draf=
t.=A0</div><div><br></div><div><br></div><div>So my default is to use the X=
ML for the non-modifiable license. I can change that if folk actually care.=
 To be honest, I don&#39;t actually read the boilerplate.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex;"><div class=3D"im">The WG *ca=
nnot* adopt it - and should not, for reasons beyond the copyright.</div>
<br>
One thing I noticed before delving into the copyright and then<br>
abandoning the document is that Phillip wouldn&#39;t be very predictable<br=
>
if he hadn&#39;t jiggered the draft so that it&#39;s all about the<br>
Certificates. =A0X.509 certificates. =A0It&#39;s buried right into the<br>
definitions in pages 3 and 4; a &quot;Relying Application&quot; or &quot;Re=
lying<br>
Party&quot; isn&#39;t relying on public-key crypto; no, they&#39;re relying=
 on a<br>
&quot;Certificate&quot;, which is defined as &quot;An X.509 Certificate&quo=
t;.<br></blockquote></div><br clear=3D"all">That is because the text for th=
e definitions was copied over from the CAA draft which is intentionally lim=
ited to X.509 because we don&#39;t want CAA properties intended to restrict=
 issue of certs from public CAs to muck up SAML and/or PGP without actually=
 thinking about it. That does not really apply here.<div>
<br></div><div>I will fix these later on today.<br><div><br>-- <br>Website:=
 <a href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div></div>

--bcaec5171ea73c638a04a052ef7a--

From [email-masked]  Thu Apr  7 09:19:08 2011
From: James Cloos <[email-masked]>
To: Stephen Kent <[email-masked]>
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC
Copyright: Copyright 2011 James Cloos
OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
Date: Thu, 07 Apr 2011 12:19:16 -0400
Lines: 27
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

>>>>> "SK" == Stephen Kent <[email-masked]> writes:

SK> I think the steps you cite, while mostly accurate, are not a good
SK> basis of comparison.  let me explain.

I presume that everyone here has done the csr dance enough that a
summary was enough...

SK> P.S. I didn't understand your step "append the ca cert to the
SK> resulting signed cert"

Since the ca cert is only trusted by way of the rr, the server will need
to send the full chain on each new connection.  So the users have to
remember the append the certs together whereever the server expects to
find its cert.

Failure to append was the most common error I encountered with chained certs.

EE certs in the rr is in all of the drafts, was the original target, is
easy to understand and explain, and I've read more consensus for than
against on the list.

Why the sudden backlash against?

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

From [email-masked]  Thu Apr  7 09:49:08 2011
Date: Thu, 7 Apr 2011 12:50:50 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: John Gilmore <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] Use cases document.

--bcaec5171ea7716adc04a056e92d
Content-Type: text/plain; charset=ISO-8859-1

The IPR has been changed to trust200902 and the definition of relying party
expanded to include any person relying on a cryptographic key. This is still
not quite correct since nobody should ever rely on a key itself, they are
always relying on on a key binding, but this will require more wordsmithing.

http://www.ietf.org/id/draft-hallambaker-dane-requirements-01.txt
<http://www.ietf.org/id/draft-hallambaker-dane-requirements-01.txt>

On Thu, Apr 7, 2011 at 8:06 AM, Phillip Hallam-Baker <[email-masked]>wrote:

>
>
> On Thu, Apr 7, 2011 at 8:14 AM, John Gilmore <[email-masked]> wrote:
>
>> Thank you, Phillip, for making a first cut at a use-case draft.
>>  However...
>>
>> One part I don't understand is that this draft comes with a copyright
>> notice in the very first paragraph, stating that neither modifications
>> nor derived works may be created.  I.e. nobody can edit this draft
>> except Phillip.  That appears to mean, according to BCP 78 and the
>> IETF Trust License Policy (TLP), that we have to start over from
>> scratch if he declines to "let us" revise it in ways that the
>> committee chooses.
>>
>
> Nah, that is just an oversight.
>
> The reason that I use it on individual submissions is that once in the past
> we did the same with the code and specifications for HTTP and HTML. NCSA
> then released a new browser where 70% of the code came from CERN but did not
> mention CERN, the use of the code or the 'World Wide Web' in any way
> whatsoever. As a direct result, CERN management stopped supporting the Web
> and I had to move to MIT.
>
> I also had the same thing happen to me on the OCSP draft.
>
>
> So my default is to use the XML for the non-modifiable license. I can
> change that if folk actually care. To be honest, I don't actually read the
> boilerplate.
>
> The WG *cannot* adopt it - and should not, for reasons beyond the
>> copyright.
>>
>> One thing I noticed before delving into the copyright and then
>> abandoning the document is that Phillip wouldn't be very predictable
>> if he hadn't jiggered the draft so that it's all about the
>> Certificates.  X.509 certificates.  It's buried right into the
>> definitions in pages 3 and 4; a "Relying Application" or "Relying
>> Party" isn't relying on public-key crypto; no, they're relying on a
>> "Certificate", which is defined as "An X.509 Certificate".
>>
>
> That is because the text for the definitions was copied over from the CAA
> draft which is intentionally limited to X.509 because we don't want CAA
> properties intended to restrict issue of certs from public CAs to muck up
> SAML and/or PGP without actually thinking about it. That does not really
> apply here.
>
> I will fix these later on today.
>
> --
> Website: http://hallambaker.com/
>
>

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

--bcaec5171ea7716adc04a056e92d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>The IPR has been changed to=A0trust200902 and the definition of relyin=
g party expanded to include any person relying on a cryptographic key. This=
 is still not quite correct since nobody should ever rely on a key itself, =
they are always relying on on a key binding, but this will require more wor=
dsmithing.</div>
<div><br></div><a href=3D"http://www.ietf.org/id/draft-hallambaker-dane-req=
uirements-01.txt">http://www.ietf.org/id/draft-hallambaker-dane-requirement=
s-01.txt</a><div><a href=3D"http://www.ietf.org/id/draft-hallambaker-dane-r=
equirements-01.txt"></a><br>
<br><div class=3D"gmail_quote">On Thu, Apr 7, 2011 at 8:06 AM, Phillip Hall=
am-Baker <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">hallam@g=
mail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br><br><div class=3D"gmail_quote"><div class=3D"im">On Thu, Apr 7, 2011 at=
 8:14 AM, John Gilmore <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]=
" target=3D"_blank">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">

Thank you, Phillip, for making a first cut at a use-case draft. =A0However.=
..<br>
<br>
One part I don&#39;t understand is that this draft comes with a copyright<b=
r>
notice in the very first paragraph, stating that neither modifications<br>
nor derived works may be created. =A0I.e. nobody can edit this draft<br>
except Phillip. =A0That appears to mean, according to BCP 78 and the<br>
IETF Trust License Policy (TLP), that we have to start over from<br>
scratch if he declines to &quot;let us&quot; revise it in ways that the<br>
committee chooses.<br></blockquote><div><br></div></div><div>Nah, that is j=
ust an oversight.</div><div><br></div><div>The reason that I use it on indi=
vidual submissions is that once in the past we did the same with the code a=
nd specifications for HTTP and HTML. NCSA then released a new browser where=
 70% of the code came from CERN but did not mention CERN, the use of the co=
de or the &#39;World Wide Web&#39; in any way whatsoever.=A0As a direct res=
ult, CERN management stopped supporting the Web and I had to move to MIT.</=
div>

<div><br></div><div>I also had the same thing happen to me on the OCSP draf=
t.=A0</div><div><br></div><div><br></div><div>So my default is to use the X=
ML for the non-modifiable license. I can change that if folk actually care.=
 To be honest, I don&#39;t actually read the boilerplate.</div>
<div class=3D"im">
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div>The WG *cannot* adopt it=
 - and should not, for reasons beyond the copyright.</div>
<br>
One thing I noticed before delving into the copyright and then<br>
abandoning the document is that Phillip wouldn&#39;t be very predictable<br=
>
if he hadn&#39;t jiggered the draft so that it&#39;s all about the<br>
Certificates. =A0X.509 certificates. =A0It&#39;s buried right into the<br>
definitions in pages 3 and 4; a &quot;Relying Application&quot; or &quot;Re=
lying<br>
Party&quot; isn&#39;t relying on public-key crypto; no, they&#39;re relying=
 on a<br>
&quot;Certificate&quot;, which is defined as &quot;An X.509 Certificate&quo=
t;.<br></blockquote></div></div><br clear=3D"all">That is because the text =
for the definitions was copied over from the CAA draft which is intentional=
ly limited to X.509 because we don&#39;t want CAA properties intended to re=
strict issue of certs from public CAs to muck up SAML and/or PGP without ac=
tually thinking about it. That does not really apply here.<div>

<br></div><div>I will fix these later on today.<br><div><br>-- <br>Website:=
 <a href=3D"http://hallambaker.com/" target=3D"_blank">http://hallambaker.c=
om/</a><br><br>
</div></div>
</blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a href=3D"htt=
p://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--bcaec5171ea7716adc04a056e92d--

From [email-masked]  Thu Apr  7 10:07:51 2011
From: Paul Hoffman <[email-masked]>
Date: Thu, 7 Apr 2011 10:08:26 -0700
To: James Cloos <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

On Apr 7, 2011, at 9:19 AM, James Cloos wrote:

>>>>>> "SK" =3D=3D Stephen Kent <[email-masked]> writes:
>=20
> SK> I think the steps you cite, while mostly accurate, are not a good
> SK> basis of comparison.  let me explain.
>=20
> I presume that everyone here has done the csr dance enough that a
> summary was enough...

Are you saying that there a use case where CSRs are impossible? Or a =
requirement that CSRs must not be generated for some reason?

You still have not stated what you want in terms of a use case and/or =
requirement.

> SK> P.S. I didn't understand your step "append the ca cert to the
> SK> resulting signed cert"
>=20
> Since the ca cert is only trusted by way of the rr, the server will =
need
> to send the full chain on each new connection. =20

The "full chain" is just the new CA cert.

> So the users have to
> remember the append the certs together whereever the server expects to
> find its cert.

But there is just one cert to append.

> Failure to append was the most common error I encountered with chained =
certs.

That may be true, but is irrelevant to what Steve said.

> EE certs in the rr is in all of the drafts, was the original target, =
is
> easy to understand and explain, and I've read more consensus for than
> against on the list.
>=20
> Why the sudden backlash against?

It is not "backlash": it is a discussion of what is really needed, and =
an engineering discussion of how to deliver what is needed. That doesn't =
seem like a bad thing...

--Paul Hoffman

From [email-masked]  Thu Apr  7 14:59:33 2011
Date: Thu, 7 Apr 2011 17:47:41 -0400
To: James Cloos <[email-masked]>
From: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

At 12:19 PM -0400 4/7/11, James Cloos wrote:
>  >>>>> "SK" == Stephen Kent <[email-masked]> writes:
>
>SK> I think the steps you cite, while mostly accurate, are not a good
>SK> basis of comparison.  let me explain.
>
>I presume that everyone here has done the csr dance enough that a
>summary was enough...
>
>SK> P.S. I didn't understand your step "append the ca cert to the
>SK> resulting signed cert"
>
>Since the ca cert is only trusted by way of the rr, the server will need
>to send the full chain on each new connection.  So the users have to
>remember the append the certs together whereever the server expects to
>find its cert.

I believe that we have text that calls for a self-signed cert to be 
accepted as a TA for the duration of the session for which the RR was 
retrieved. In that
case there would be no need to send the SS cert in the TLS handshake.

>Failure to append was the most common error I encountered with chained certs.
>
>EE certs in the rr is in all of the drafts, was the original target, is
>easy to understand and explain, and I've read more consensus for than
>against on the list.
>
>Why the sudden backlash against?

It's not sudden :-). A self-signed cert is a CA cert, by definition (see
the cites to RFC 5280 in Paul's I-D. The TLS spec talks in terms of an
"end entity's cert" as representing a a server (or client). From a PKI
perspective, the cert that represents a server or client MUST be an
EE cert, an thus cannot be self-signed.  The fact that many implementations
violate IETF PKI standards in this regard, is unfortunate, but it is not
a basis for issuing a new IETF stanbdard that codifies this behavior.

Steve

From [email-masked]  Thu Apr  7 19:57:05 2011
From: Martin Rex <[email-masked]>
To: [email-masked] (Stephen Kent)
Date: Fri, 8 Apr 2011 04:58:34 +0200 (MEST)
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.
Reply-To: [email-masked]

Stephen Kent wrote:
> 
> James Cloos wrote:
> >
> >EE certs in the rr is in all of the drafts, was the original target, is
> >easy to understand and explain, and I've read more consensus for than
> >against on the list.
> >
> >Why the sudden backlash against?
> 
> It's not sudden :-). A self-signed cert is a CA cert, by definition (see
> the cites to RFC 5280 in Paul's I-D.

RFC 5280 is about X.509v3 certs _ONLY_.

There is NO problem creating X.509v1 End-Entity certs that are self-signed.
And there is no problem using any of these with implementations of
SSLv3 and TLSv1.0.

SSLv3 predates IETF PKIX standards, and TLSv1.0 is related to
rfc-2459 rather than rfc-5280 -- but implementations of TLSv1.0
were often shipped before publication of TLSv1.0 (rfc-2246) and
the original PKIX certificate profile (rfc-2459).

For safety, it would be sensible to ALWAYS treat X.509v1 certs as
EndEntity certs (i.e. never accept them as signer of other certs).
Our TLS implementation had done this initially, but we had a customer
that had obtained server certs issued under a VeriSign X.509v1 CA cert
(as late as 2006!), so I had to make our OEM implementation tolerate this.

>
> The TLS spec talks in terms of an "end entity's cert" as representing
> a a server (or client). From a PKI perspective, the cert that represents
> a server or client MUST be an EE cert,

Like an X.509v1 self-signed EE cert.  Works perfectly fine with all
TLS implementations that I've met.

Keep in mind that TLS is not limited to X.509v3 certs.

  TLSv1.0:    http://tools.ietf.org/html/rfc2246#section-7.4.2
  TLSv1.1:    http://tools.ietf.org/html/rfc4346#section-7.4.2

   7.4.2. Server certificate

      [...]

   Meaning of this message:
       The certificate type must be appropriate for the selected cipher
       suite's key exchange algorithm, and is generally an X.509v3
       certificate. It must contain a key which matches the key exchange
       method, as follows.

>
> an thus cannot be self-signed.

TLSv1.0 and TLSv1.1 have neither a problem with X.509v1 nor
with a self-signed X.509v1 End-Entity cert. 

> The fact that many implementations
> violate IETF PKI standards in this regard, is unfortunate, but it is not
> a basis for issuing a new IETF standard that codifies this behavior.

I know that there are lots of commercial CAs that still have CA certs
in every browser that are not valid CA certs according to PKIX / RFC 5280.

But having TLSv1.0&TLSv1.1 (i.e. 99% of the installed base)
accept X.509v1 self-signed EE certs is perfectly fine.

X.509v1 is fairly close to a bare key, supported by all TLS implementations
in the installed base, as well as tools in the installed base, such as
the openssl.exe shell and for transfering keypairs within PKCS#12/PFX.

-Martin

From [email-masked]  Thu Apr  7 20:34:44 2011
Date: Fri, 8 Apr 2011 03:36:26 +0000
From: Phillip Hallam-Baker <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

--bcaec5171ea7452bc704a05feef1
Content-Type: text/plain; charset=ISO-8859-1

Seems to me to be a poor choice of a standards strategy.

X509v1 is obsolete. Implementations may choose to support v1 certs but I am
pretty sure that an IETF standards WG can't build anything new on top of
them.

And I am certain that going to an earlier version to avoid the PKIX
restriction is not going to fly.

This is meant to be a standards WG. One of the things about standards is
that on occasion you end up having to accept something you don't like
because that is the existing standard.

PKIX is the keying infrastructure of TLS. So this WG has to support it
properly. I know that there are alternatives in theory, but in practice they
are used about as often as DSA certs (25 servers worldwide).

I can't see the point of having this debate. Compliance with strict PKIX
does not prevent anyone from doing what they want to do. It is good crypto
hygiene to separate CA certs and EE certs.

If TLS was a simple, implement in an afternoon affair, I could see the point
in arguing for simplification of the cert scheme. But really, simplifying
the cert management its like trying to simplify one clause in the US federal
budget.

On Fri, Apr 8, 2011 at 2:58 AM, Martin Rex <[email-masked]> wrote:

> Stephen Kent wrote:
> >
> > James Cloos wrote:
> > >
> > >EE certs in the rr is in all of the drafts, was the original target, is
> > >easy to understand and explain, and I've read more consensus for than
> > >against on the list.
> > >
> > >Why the sudden backlash against?
> >
> > It's not sudden :-). A self-signed cert is a CA cert, by definition (see
> > the cites to RFC 5280 in Paul's I-D.
>
> RFC 5280 is about X.509v3 certs _ONLY_.
>
> There is NO problem creating X.509v1 End-Entity certs that are self-signed.
> And there is no problem using any of these with implementations of
> SSLv3 and TLSv1.0.
>
> SSLv3 predates IETF PKIX standards, and TLSv1.0 is related to
> rfc-2459 rather than rfc-5280 -- but implementations of TLSv1.0
> were often shipped before publication of TLSv1.0 (rfc-2246) and
> the original PKIX certificate profile (rfc-2459).
>
>
> For safety, it would be sensible to ALWAYS treat X.509v1 certs as
> EndEntity certs (i.e. never accept them as signer of other certs).
> Our TLS implementation had done this initially, but we had a customer
> that had obtained server certs issued under a VeriSign X.509v1 CA cert
> (as late as 2006!), so I had to make our OEM implementation tolerate this.
>
>
>
> >
> > The TLS spec talks in terms of an "end entity's cert" as representing
> > a a server (or client). From a PKI perspective, the cert that represents
> > a server or client MUST be an EE cert,
>
> Like an X.509v1 self-signed EE cert.  Works perfectly fine with all
> TLS implementations that I've met.
>
> Keep in mind that TLS is not limited to X.509v3 certs.
>
>  TLSv1.0:    http://tools.ietf.org/html/rfc2246#section-7.4.2
>  TLSv1.1:    http://tools.ietf.org/html/rfc4346#section-7.4.2
>
>   7.4.2. Server certificate
>
>      [...]
>
>   Meaning of this message:
>       The certificate type must be appropriate for the selected cipher
>       suite's key exchange algorithm, and is generally an X.509v3
>       certificate. It must contain a key which matches the key exchange
>       method, as follows.
>
>
> >
> > an thus cannot be self-signed.
>
> TLSv1.0 and TLSv1.1 have neither a problem with X.509v1 nor
> with a self-signed X.509v1 End-Entity cert.
>
>
> > The fact that many implementations
> > violate IETF PKI standards in this regard, is unfortunate, but it is not
> > a basis for issuing a new IETF standard that codifies this behavior.
>
> I know that there are lots of commercial CAs that still have CA certs
> in every browser that are not valid CA certs according to PKIX / RFC 5280.
>
> But having TLSv1.0&TLSv1.1 (i.e. 99% of the installed base)
> accept X.509v1 self-signed EE certs is perfectly fine.
>
> X.509v1 is fairly close to a bare key, supported by all TLS implementations
> in the installed base, as well as tools in the installed base, such as
> the openssl.exe shell and for transfering keypairs within PKCS#12/PFX.
>
>
> -Martin
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

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

--bcaec5171ea7452bc704a05feef1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Seems to me to be a poor choice of a standards strategy.<div><br></div><div=
>X509v1 is obsolete. Implementations may choose to support v1 certs but I a=
m pretty sure that an IETF standards WG can&#39;t build anything new on top=
 of them.</div>
<div><br></div><div>And I am certain that going to an earlier version to av=
oid the PKIX restriction is not going to fly.=A0</div><div><br></div><div><=
br></div><div>This is meant to be a standards WG. One of the things about s=
tandards is that on occasion you end up having to accept something you don&=
#39;t like because that is the existing standard.</div>
<div><br></div><div>PKIX is the keying infrastructure of TLS. So this WG ha=
s to support it properly. I know that there are alternatives in theory, but=
 in practice they are used about as often as DSA certs (25 servers worldwid=
e).</div>
<div><br></div><div><br></div><div>I can&#39;t see the point of having this=
 debate. Compliance with strict PKIX does not prevent anyone from doing wha=
t they want to do. It is good crypto hygiene to separate CA certs and EE ce=
rts.</div>
<div><br></div><div>If TLS was a simple, implement in an afternoon affair, =
I could see the point in arguing for simplification of the cert scheme. But=
 really, simplifying the cert management its like trying to simplify one cl=
ause in the US federal budget.</div>
<div><br></div><div><br></div><div><br><div class=3D"gmail_quote">On Fri, A=
pr 8, 2011 at 2:58 AM, Martin Rex <span dir=3D"ltr">&lt;<a href=3D"mailto:m=
[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex;">
Stephen Kent wrote:<br>
<div class=3D"im">&gt;<br>
&gt; James Cloos wrote:<br>
&gt; &gt;<br>
&gt; &gt;EE certs in the rr is in all of the drafts, was the original targe=
t, is<br>
&gt; &gt;easy to understand and explain, and I&#39;ve read more consensus f=
or than<br>
&gt; &gt;against on the list.<br>
&gt; &gt;<br>
&gt; &gt;Why the sudden backlash against?<br>
&gt;<br>
&gt; It&#39;s not sudden :-). A self-signed cert is a CA cert, by definitio=
n (see<br>
&gt; the cites to RFC 5280 in Paul&#39;s I-D.<br>
<br>
</div>RFC 5280 is about X.509v3 certs _ONLY_.<br>
<br>
There is NO problem creating X.509v1 End-Entity certs that are self-signed.=
<br>
And there is no problem using any of these with implementations of<br>
SSLv3 and TLSv1.0.<br>
<br>
SSLv3 predates IETF PKIX standards, and TLSv1.0 is related to<br>
rfc-2459 rather than rfc-5280 -- but implementations of TLSv1.0<br>
were often shipped before publication of TLSv1.0 (rfc-2246) and<br>
the original PKIX certificate profile (rfc-2459).<br>
<br>
<br>
For safety, it would be sensible to ALWAYS treat X.509v1 certs as<br>
EndEntity certs (i.e. never accept them as signer of other certs).<br>
Our TLS implementation had done this initially, but we had a customer<br>
that had obtained server certs issued under a VeriSign X.509v1 CA cert<br>
(as late as 2006!), so I had to make our OEM implementation tolerate this.<=
br>
<div class=3D"im"><br>
<br>
<br>
&gt;<br>
&gt; The TLS spec talks in terms of an &quot;end entity&#39;s cert&quot; as=
 representing<br>
&gt; a a server (or client). From a PKI perspective, the cert that represen=
ts<br>
&gt; a server or client MUST be an EE cert,<br>
<br>
</div>Like an X.509v1 self-signed EE cert. =A0Works perfectly fine with all=
<br>
TLS implementations that I&#39;ve met.<br>
<br>
Keep in mind that TLS is not limited to X.509v3 certs.<br>
<br>
 =A0TLSv1.0: =A0 =A0<a href=3D"http://tools.ietf.org/html/rfc2246#section-7=
.4.2" target=3D"_blank">http://tools.ietf.org/html/rfc2246#section-7.4.2</a=
><br>
 =A0TLSv1.1: =A0 =A0<a href=3D"http://tools.ietf.org/html/rfc4346#section-7=
.4.2" target=3D"_blank">http://tools.ietf.org/html/rfc4346#section-7.4.2</a=
><br>
<br>
 =A0 7.4.2. Server certificate<br>
<br>
 =A0 =A0 =A0[...]<br>
<br>
 =A0 Meaning of this message:<br>
 =A0 =A0 =A0 The certificate type must be appropriate for the selected ciph=
er<br>
 =A0 =A0 =A0 suite&#39;s key exchange algorithm, and is generally an X.509v=
3<br>
 =A0 =A0 =A0 certificate. It must contain a key which matches the key excha=
nge<br>
 =A0 =A0 =A0 method, as follows.<br>
<div class=3D"im"><br>
<br>
&gt;<br>
&gt; an thus cannot be self-signed.<br>
<br>
</div>TLSv1.0 and TLSv1.1 have neither a problem with X.509v1 nor<br>
with a self-signed X.509v1 End-Entity cert.<br>
<div class=3D"im"><br>
<br>
&gt; The fact that many implementations<br>
&gt; violate IETF PKI standards in this regard, is unfortunate, but it is n=
ot<br>
</div>&gt; a basis for issuing a new IETF standard that codifies this behav=
ior.<br>
<br>
I know that there are lots of commercial CAs that still have CA certs<br>
in every browser that are not valid CA certs according to PKIX / RFC 5280.<=
br>
<br>
But having TLSv1.0&amp;TLSv1.1 (i.e. 99% of the installed base)<br>
accept X.509v1 self-signed EE certs is perfectly fine.<br>
<br>
X.509v1 is fairly close to a bare key, supported by all TLS implementations=
<br>
in the installed base, as well as tools in the installed base, such as<br>
the openssl.exe shell and for transfering keypairs within PKCS#12/PFX.<br>
<font color=3D"#888888"><br>
<br>
-Martin<br>
</font><div><div></div><div class=3D"h5">__________________________________=
_____________<br>
dane mailing list<br>
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/dane</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--bcaec5171ea7452bc704a05feef1--

From [email-masked]  Thu Apr  7 21:37:28 2011
From: Martin Rex <[email-masked]>
Orig-To: [email-masked] (Phillip Hallam-Baker)
To: [email-masked], [email-masked]
Date: Fri, 8 Apr 2011 06:33:46 +0200 (MEST)
Sender: [email-masked]
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.
Reply-To: [email-masked]

Phillip Hallam-Baker wrote:
> 
> Seems to me to be a poor choice of a standards strategy.
> 
> X509v1 is obsolete. Implementations may choose to support v1 certs but I am
> pretty sure that an IETF standards WG can't build anything new on top of
> them.

X.509v1 is obsolete for PKI(X), but it is a perfect fit as a bare
key format for many existing tools (for the management and creation
of keypairs), protocols (including TLS) and container formats for
exchange (e.g. PKCS12/PFX).

Why should we artificially invent a bare key format to cover the
most common format for TLS Server credentials on the internet,
when there is a format that works just fine with all existing
implementation and has been completely abandonned by PKIX,
such as X.509v1?

> 
> And I am certain that going to an earlier version to avoid the PKIX
> restriction is not going to fly.

Just because you personally do not find it aesthetically pleasing?

> 
> 
> This is meant to be a standards WG. One of the things about standards is
> that on occasion you end up having to accept something you don't like
> because that is the existing standard.

The existing standard is what the "unwashed self-signed masses"
out there on the internet need, and they really want it to work
with as much of the installed base as possible.

Rather than making convolutions to define X.509v3 self-signed EndEntity
certs, simply use the otherwise abandonned X.509v1 format for exactly
this purpose.

> 
> PKIX is the keying infrastructure of TLS.

That is plain wrong. 
PKIX is the keying infrastructure of the Internet PKI.

Bare keys represented by self-signed X.509v1 certs are obviously _NO_ PKI,
therefore PKIX rules do not apply.

You seem to be mostly worried about the business model of your employer.

-Martin

From [email-masked]  Fri Apr  8 03:12:56 2011
Date: Fri, 8 Apr 2011 11:14:37 +0100
From: Ben Laurie <[email-masked]>
To: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

On 7 April 2011 22:47, Stephen Kent <[email-masked]> wrote:
> At 12:19 PM -0400 4/7/11, James Cloos wrote:
>>
>> =A0>>>>> "SK" =3D=3D Stephen Kent <[email-masked]> writes:
>>
>> SK> I think the steps you cite, while mostly accurate, are not a good
>> SK> basis of comparison. =A0let me explain.
>>
>> I presume that everyone here has done the csr dance enough that a
>> summary was enough...
>>
>> SK> P.S. I didn't understand your step "append the ca cert to the
>> SK> resulting signed cert"
>>
>> Since the ca cert is only trusted by way of the rr, the server will need
>> to send the full chain on each new connection. =A0So the users have to
>> remember the append the certs together whereever the server expects to
>> find its cert.
>
> I believe that we have text that calls for a self-signed cert to be accep=
ted
> as a TA for the duration of the session for which the RR was retrieved. I=
n
> that
> case there would be no need to send the SS cert in the TLS handshake.
>
>> Failure to append was the most common error I encountered with chained
>> certs.
>>
>> EE certs in the rr is in all of the drafts, was the original target, is
>> easy to understand and explain, and I've read more consensus for than
>> against on the list.
>>
>> Why the sudden backlash against?
>
> It's not sudden :-). A self-signed cert is a CA cert, by definition (see
> the cites to RFC 5280 in Paul's I-D. The TLS spec talks in terms of an
> "end entity's cert" as representing a a server (or client). From a PKI
> perspective, the cert that represents a server or client MUST be an
> EE cert, an thus cannot be self-signed. =A0The fact that many implementat=
ions
> violate IETF PKI standards in this regard, is unfortunate, but it is not
> a basis for issuing a new IETF stanbdard that codifies this behavior.

Isn't it? What is the argument against allowing a self-signed EE cert,
other than spec lawyering?

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

From [email-masked]  Fri Apr  8 04:58:45 2011
Date: Fri, 8 Apr 2011 12:00:27 +0000
From: Phillip Hallam-Baker <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

--20cf307cfcbcc9298e04a066f8f8
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Apr 8, 2011 at 4:33 AM, Martin Rex <[email-masked]> wrote:

>
> > And I am certain that going to an earlier version to avoid the PKIX
> > restriction is not going to fly.
>
> Just because you personally do not find it aesthetically pleasing?
>

You are projecting here.

Personally, I really could not care less one way or the other on this
particular issue. You are the one who is raising a minor technical issue in
a use cases and requirements thread.

Had I actually cared about the self signed certs issue I would have raised
it before Steve did. However, he has raised it and irritatingly enough, he
happens to be right as far as the X.509v3 standard is concerned.

Proposing use of X.509v1 or a non-standard use of PKIX would require a huge
amount of political effort and introduce a great deal of delay. I can't see
it as being very likely that Steve does not get his way in the end as far as
the standard is concerned.

The actual code is a completely different matter.

If people want to move quickly, this is the type of argument to rule out of
scope and move on over because it really is inconsequential and the issue in
question is in scope of a different working group.

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

--20cf307cfcbcc9298e04a066f8f8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Fri, Apr 8, 2011 at 4:33 AM, Martin Rex <span dir=3D"ltr">&lt;<a href=3D=
"mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><div class=3D"g=
mail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im"><br></div><div class=3D"im">&gt; And I am certain that go=
ing to an earlier version to avoid the PKIX<br>
&gt; restriction is not going to fly.<br>
<br>
</div><div class=3D"im">Just because you personally do not find it aestheti=
cally pleasing?<br></div></blockquote><div><br></div><div>You are projectin=
g here.=A0</div><div><br></div><div>Personally, I really could not care les=
s one way or the other on this particular issue. You are the one who is rai=
sing a minor technical issue in a use cases and requirements thread.</div>
<div><br></div><div>Had I actually cared about the self signed certs issue =
I would have raised it before Steve did. However, he has raised it and irri=
tatingly enough, he happens to be right as far as the X.509v3 standard is c=
oncerned.</div>
<div><br></div><div><br></div><div>Proposing use of X.509v1 or a non-standa=
rd use of PKIX would require a huge amount of political effort and introduc=
e a great deal of delay. I can&#39;t see it as being very likely that Steve=
 does not get his way in the end as far as the standard is concerned.</div>
<div><br></div><div>The actual code is a completely different matter.</div>=
<div><br></div><div><br></div><div>If people want to move quickly, this is =
the type of argument to rule out of scope and move on over because it reall=
y is inconsequential and the issue in question is in scope of a different w=
orking group.</div>
<div><br></div><div><br></div></div>-- <br>Website: <a href=3D"http://halla=
mbaker.com/">http://hallambaker.com/</a><br><br>

--20cf307cfcbcc9298e04a066f8f8--

From [email-masked]  Fri Apr  8 05:32:32 2011
From: Paul Hoffman <[email-masked]>
Date: Fri, 8 Apr 2011 05:33:28 -0700
To: Ben Laurie <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

I note, again, that this has *nothing* to do with use cases or =
requirements. Having said that...

On Apr 8, 2011, at 3:14 AM, Ben Laurie wrote:

> Isn't it? What is the argument against allowing a self-signed EE cert,
> other than spec lawyering?

A PKIX-compliant implementation must make some changes to handle them, =
as described in the current draft. If the use cases and requirements =
chosen by the WG lead to giving end entity certs, the WG can decide =
those changes are fine. If the use cases and requirements chosen by the =
WG lead to not giving end entity certs, we have an easy way to handle =
that.

--Paul Hoffman

From [email-masked]  Fri Apr  8 05:35:14 2011
Date: Fri, 08 Apr 2011 14:36:52 +0200
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
To: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

My question to the list is if we can avoid specifying which X.509 
version the client/server has to use and leave it to the client policy.

Martin's approach seems like a reasonable one, but the question is if we 
can fit it into our draft without advice to break any existing standard.

I know that we are standards group (to reply to PHB later in this 
thread), but we also cannot afford to ignore what's happening in the 
real world otherwise the world is going to ignore us.

I think that usage of self-signed EE cert is a reasonable use case 
(which may or may not make it to the protocol) and it shouldn't be left 
out.  So please everybody let's think harder how to make things for 
non-protocol-geeks out there simpler, so the fruit of our work is a 
tasty one and not bittersweet.

O.

On 4/8/11 4:58 AM, Martin Rex wrote:
> Stephen Kent wrote:
>>
>> James Cloos wrote:
>>>
>>> EE certs in the rr is in all of the drafts, was the original target, is
>>> easy to understand and explain, and I've read more consensus for than
>>> against on the list.
>>>
>>> Why the sudden backlash against?
>>
>> It's not sudden :-). A self-signed cert is a CA cert, by definition (see
>> the cites to RFC 5280 in Paul's I-D.
>
> RFC 5280 is about X.509v3 certs _ONLY_.
>
> There is NO problem creating X.509v1 End-Entity certs that are self-signed.
> And there is no problem using any of these with implementations of
> SSLv3 and TLSv1.0.
>
> SSLv3 predates IETF PKIX standards, and TLSv1.0 is related to
> rfc-2459 rather than rfc-5280 -- but implementations of TLSv1.0
> were often shipped before publication of TLSv1.0 (rfc-2246) and
> the original PKIX certificate profile (rfc-2459).
>
>
> For safety, it would be sensible to ALWAYS treat X.509v1 certs as
> EndEntity certs (i.e. never accept them as signer of other certs).
> Our TLS implementation had done this initially, but we had a customer
> that had obtained server certs issued under a VeriSign X.509v1 CA cert
> (as late as 2006!), so I had to make our OEM implementation tolerate this.
>
>
>
>>
>> The TLS spec talks in terms of an "end entity's cert" as representing
>> a a server (or client). From a PKI perspective, the cert that represents
>> a server or client MUST be an EE cert,
>
> Like an X.509v1 self-signed EE cert.  Works perfectly fine with all
> TLS implementations that I've met.
>
> Keep in mind that TLS is not limited to X.509v3 certs.
>
>    TLSv1.0:    http://tools.ietf.org/html/rfc2246#section-7.4.2
>    TLSv1.1:    http://tools.ietf.org/html/rfc4346#section-7.4.2
>
>     7.4.2. Server certificate
>
>        [...]
>
>     Meaning of this message:
>         The certificate type must be appropriate for the selected cipher
>         suite's key exchange algorithm, and is generally an X.509v3
>         certificate. It must contain a key which matches the key exchange
>         method, as follows.
>
>
>>
>> an thus cannot be self-signed.
>
> TLSv1.0 and TLSv1.1 have neither a problem with X.509v1 nor
> with a self-signed X.509v1 End-Entity cert.
>
>
>> The fact that many implementations
>> violate IETF PKI standards in this regard, is unfortunate, but it is not
>> a basis for issuing a new IETF standard that codifies this behavior.
>
> I know that there are lots of commercial CAs that still have CA certs
> in every browser that are not valid CA certs according to PKIX / RFC 5280.
>
> But having TLSv1.0&TLSv1.1 (i.e. 99% of the installed base)
> accept X.509v1 self-signed EE certs is perfectly fine.
>
> X.509v1 is fairly close to a bare key, supported by all TLS implementations
> in the installed base, as well as tools in the installed base, such as
> the openssl.exe shell and for transfering keypairs within PKCS#12/PFX.

From [email-masked]  Fri Apr  8 05:44:32 2011
Date: Fri, 08 Apr 2011 14:46:15 +0200
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
To: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

Phillip,

the chairs have already asked Richard Barnes to be the editor of the 
use-cases document for the working group and he agreed.  We are sorry 
that we didn't announce it sooner.

However I don't think that this poses a big problem, since you also 
agreed that you would send a list of your use cases to the list and the 
format (email or I-D) doesn't make a real difference. So I think the WG 
would be happy to accept your submission as an input document for the 
discussion on the working group use case document.

O.

On 4/6/11 1:33 AM, Phillip Hallam-Baker wrote:
> OK, as promised at the WG meeting, here is a first cut at a requirements
> document based on the use cases and requirements analysis that I have
> done to support my earlier proposals in this area.
>
> I have cut down the original documents to make this more manageable.
> What I have not done (yet) is to draw up the correspondance matrices
> that link the use cases to the requirements and so on. Nor have I got
> the links in hypertext form.
>
> The idea is that each use case should list the requirements it motivates
> and vice versa. Every requirement should be driven by at least one use case.
>
> What I have not quite worked out at this point is how to make use of the
> attacker model to derive requirements from the use cases. Part of the
> point of specifying the attacker profiles is that a proposal should not
> get credit for blocking an attack A1 that allows attacker X to have
> effect Y if the same attacker can realize Y through attack A2 that is
> also in their capabilities.
>
> http://www.ietf.org/id/draft-hallambaker-dane-requirements-00.txt
>
>
> I have put this in as a personal submission so as not to pre-empt the WG
> decision. But am quite happy if the WG wants to adopt it.
>
> Its also missing an acknowledgements section, many of these use cases
> were captured during our earlier arguments on the list.
>
> Phill
>
>
>
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

From [email-masked]  Fri Apr  8 05:44:58 2011
Date: Fri, 8 Apr 2011 13:46:38 +0100
From: Ben Laurie <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

On 8 April 2011 13:33, Paul Hoffman <[email-masked]> wrote:
> I note, again, that this has *nothing* to do with use cases or requiremen=
ts. Having said that...

I've already stated my requirement (that self-signed certs should be usable=
).

>
> On Apr 8, 2011, at 3:14 AM, Ben Laurie wrote:
>
>> Isn't it? What is the argument against allowing a self-signed EE cert,
>> other than spec lawyering?
>
>
> A PKIX-compliant implementation must make some changes to handle them, as=
 described in the current draft. If the use cases and requirements chosen b=
y the WG lead to giving end entity certs, the WG can decide those changes a=
re fine. If the use cases and requirements chosen by the WG lead to not giv=
ing end entity certs, we have an easy way to handle that.
>
> --Paul Hoffman
>
>

From [email-masked]  Fri Apr  8 05:45:05 2011
From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 8 Apr 2011 08:46:46 -0400
To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

To note again: The phrase "self-signed EE cert" does not make sense.  =
=46rom RFC 5280:
"
Self-issued certificates are generated to support changes in policy or =
operations.  Self-signed certificates are self-issued certificates where =
the digital signature may be verified by the public key bound into the =
certificate.
"
Since a self-signed cert has a cert issued under it (itself), it has to =
be a CA cert.

A self-signed cert *without* the CA bits set is therefore malformed, and =
will not pass PKIX validation. =20

Which brings us back to the point that if you want certs that really =
aren't signed by anybody, you might as well be using bare keys, or some =
new data structure that only carries what you're interested in, e.g., =
key parameters but not key usage, names, issuer, etc.

--Richard

On Apr 8, 2011, at 8:36 AM, Ond=C5=99ej Sur=C3=BD wrote:

> My question to the list is if we can avoid specifying which X.509 =
version the client/server has to use and leave it to the client policy.
>=20
> Martin's approach seems like a reasonable one, but the question is if =
we can fit it into our draft without advice to break any existing =
standard.
>=20
> I know that we are standards group (to reply to PHB later in this =
thread), but we also cannot afford to ignore what's happening in the =
real world otherwise the world is going to ignore us.
>=20
> I think that usage of self-signed EE cert is a reasonable use case =
(which may or may not make it to the protocol) and it shouldn't be left =
out.  So please everybody let's think harder how to make things for =
non-protocol-geeks out there simpler, so the fruit of our work is a =
tasty one and not bittersweet.
>=20
> O.
>=20
> On 4/8/11 4:58 AM, Martin Rex wrote:
>> Stephen Kent wrote:
>>>=20
>>> James Cloos wrote:
>>>>=20
>>>> EE certs in the rr is in all of the drafts, was the original =
target, is
>>>> easy to understand and explain, and I've read more consensus for =
than
>>>> against on the list.
>>>>=20
>>>> Why the sudden backlash against?
>>>=20
>>> It's not sudden :-). A self-signed cert is a CA cert, by definition =
(see
>>> the cites to RFC 5280 in Paul's I-D.
>>=20
>> RFC 5280 is about X.509v3 certs _ONLY_.
>>=20
>> There is NO problem creating X.509v1 End-Entity certs that are =
self-signed.
>> And there is no problem using any of these with implementations of
>> SSLv3 and TLSv1.0.
>>=20
>> SSLv3 predates IETF PKIX standards, and TLSv1.0 is related to
>> rfc-2459 rather than rfc-5280 -- but implementations of TLSv1.0
>> were often shipped before publication of TLSv1.0 (rfc-2246) and
>> the original PKIX certificate profile (rfc-2459).
>>=20
>>=20
>> For safety, it would be sensible to ALWAYS treat X.509v1 certs as
>> EndEntity certs (i.e. never accept them as signer of other certs).
>> Our TLS implementation had done this initially, but we had a customer
>> that had obtained server certs issued under a VeriSign X.509v1 CA =
cert
>> (as late as 2006!), so I had to make our OEM implementation tolerate =
this.
>>=20
>>=20
>>=20
>>>=20
>>> The TLS spec talks in terms of an "end entity's cert" as =
representing
>>> a a server (or client). =46rom a PKI perspective, the cert that =
represents
>>> a server or client MUST be an EE cert,
>>=20
>> Like an X.509v1 self-signed EE cert.  Works perfectly fine with all
>> TLS implementations that I've met.
>>=20
>> Keep in mind that TLS is not limited to X.509v3 certs.
>>=20
>>   TLSv1.0:    http://tools.ietf.org/html/rfc2246#section-7.4.2
>>   TLSv1.1:    http://tools.ietf.org/html/rfc4346#section-7.4.2
>>=20
>>    7.4.2. Server certificate
>>=20
>>       [...]
>>=20
>>    Meaning of this message:
>>        The certificate type must be appropriate for the selected =
cipher
>>        suite's key exchange algorithm, and is generally an X.509v3
>>        certificate. It must contain a key which matches the key =
exchange
>>        method, as follows.
>>=20
>>=20
>>>=20
>>> an thus cannot be self-signed.
>>=20
>> TLSv1.0 and TLSv1.1 have neither a problem with X.509v1 nor
>> with a self-signed X.509v1 End-Entity cert.
>>=20
>>=20
>>> The fact that many implementations
>>> violate IETF PKI standards in this regard, is unfortunate, but it is =
not
>>> a basis for issuing a new IETF standard that codifies this behavior.
>>=20
>> I know that there are lots of commercial CAs that still have CA certs
>> in every browser that are not valid CA certs according to PKIX / RFC =
5280.
>>=20
>> But having TLSv1.0&TLSv1.1 (i.e. 99% of the installed base)
>> accept X.509v1 self-signed EE certs is perfectly fine.
>>=20
>> X.509v1 is fairly close to a bare key, supported by all TLS =
implementations
>> in the installed base, as well as tools in the installed base, such =
as
>> the openssl.exe shell and for transfering keypairs within =
PKCS#12/PFX.
>=20
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

From [email-masked]  Fri Apr  8 05:53:46 2011
Date: Fri, 08 Apr 2011 14:55:28 +0200
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

Richard,

to rephrase my request:  I want to make life easier for people deploying 
the TLS on their sites.  I think that's the whole reason for the 
existence of this working group.  If the self-signed cert without the CA 
bits is malformed then we need some solution for this.

And we cannot simply ignore the fact that the people are using 
"malformed" certificates in the wild.  At least it needs to go to the 
use cases document, because it is a real use case (which is really used 
by people out there).

Ondrej

On 4/8/11 2:46 PM, Richard L. Barnes wrote:
> To note again: The phrase "self-signed EE cert" does not make sense.  From RFC 5280:
> "
> Self-issued certificates are generated to support changes in policy or operations.  Self-signed certificates are self-issued certificates where the digital signature may be verified by the public key bound into the certificate.
> "
> Since a self-signed cert has a cert issued under it (itself), it has to be a CA cert.
>
> A self-signed cert *without* the CA bits set is therefore malformed, and will not pass PKIX validation.
>
> Which brings us back to the point that if you want certs that really aren't signed by anybody, you might as well be using bare keys, or some new data structure that only carries what you're interested in, e.g., key parameters but not key usage, names, issuer, etc.
>
> --Richard
>
>
>
>
> On Apr 8, 2011, at 8:36 AM, OndÅ™ej SurÃ½ wrote:
>
>> My question to the list is if we can avoid specifying which X.509 version the client/server has to use and leave it to the client policy.
>>
>> Martin's approach seems like a reasonable one, but the question is if we can fit it into our draft without advice to break any existing standard.
>>
>> I know that we are standards group (to reply to PHB later in this thread), but we also cannot afford to ignore what's happening in the real world otherwise the world is going to ignore us.
>>
>> I think that usage of self-signed EE cert is a reasonable use case (which may or may not make it to the protocol) and it shouldn't be left out.  So please everybody let's think harder how to make things for non-protocol-geeks out there simpler, so the fruit of our work is a tasty one and not bittersweet.
>>
>> O.
>>
>> On 4/8/11 4:58 AM, Martin Rex wrote:
>>> Stephen Kent wrote:
>>>>
>>>> James Cloos wrote:
>>>>>
>>>>> EE certs in the rr is in all of the drafts, was the original target, is
>>>>> easy to understand and explain, and I've read more consensus for than
>>>>> against on the list.
>>>>>
>>>>> Why the sudden backlash against?
>>>>
>>>> It's not sudden :-). A self-signed cert is a CA cert, by definition (see
>>>> the cites to RFC 5280 in Paul's I-D.
>>>
>>> RFC 5280 is about X.509v3 certs _ONLY_.
>>>
>>> There is NO problem creating X.509v1 End-Entity certs that are self-signed.
>>> And there is no problem using any of these with implementations of
>>> SSLv3 and TLSv1.0.
>>>
>>> SSLv3 predates IETF PKIX standards, and TLSv1.0 is related to
>>> rfc-2459 rather than rfc-5280 -- but implementations of TLSv1.0
>>> were often shipped before publication of TLSv1.0 (rfc-2246) and
>>> the original PKIX certificate profile (rfc-2459).
>>>
>>>
>>> For safety, it would be sensible to ALWAYS treat X.509v1 certs as
>>> EndEntity certs (i.e. never accept them as signer of other certs).
>>> Our TLS implementation had done this initially, but we had a customer
>>> that had obtained server certs issued under a VeriSign X.509v1 CA cert
>>> (as late as 2006!), so I had to make our OEM implementation tolerate this.
>>>
>>>
>>>
>>>>
>>>> The TLS spec talks in terms of an "end entity's cert" as representing
>>>> a a server (or client). From a PKI perspective, the cert that represents
>>>> a server or client MUST be an EE cert,
>>>
>>> Like an X.509v1 self-signed EE cert.  Works perfectly fine with all
>>> TLS implementations that I've met.
>>>
>>> Keep in mind that TLS is not limited to X.509v3 certs.
>>>
>>>    TLSv1.0:    http://tools.ietf.org/html/rfc2246#section-7.4.2
>>>    TLSv1.1:    http://tools.ietf.org/html/rfc4346#section-7.4.2
>>>
>>>     7.4.2. Server certificate
>>>
>>>        [...]
>>>
>>>     Meaning of this message:
>>>         The certificate type must be appropriate for the selected cipher
>>>         suite's key exchange algorithm, and is generally an X.509v3
>>>         certificate. It must contain a key which matches the key exchange
>>>         method, as follows.
>>>
>>>
>>>>
>>>> an thus cannot be self-signed.
>>>
>>> TLSv1.0 and TLSv1.1 have neither a problem with X.509v1 nor
>>> with a self-signed X.509v1 End-Entity cert.
>>>
>>>
>>>> The fact that many implementations
>>>> violate IETF PKI standards in this regard, is unfortunate, but it is not
>>>> a basis for issuing a new IETF standard that codifies this behavior.
>>>
>>> I know that there are lots of commercial CAs that still have CA certs
>>> in every browser that are not valid CA certs according to PKIX / RFC 5280.
>>>
>>> But having TLSv1.0&TLSv1.1 (i.e. 99% of the installed base)
>>> accept X.509v1 self-signed EE certs is perfectly fine.
>>>
>>> X.509v1 is fairly close to a bare key, supported by all TLS implementations
>>> in the installed base, as well as tools in the installed base, such as
>>> the openssl.exe shell and for transfering keypairs within PKCS#12/PFX.
>>
>> _______________________________________________
>> dane mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dane
>

From [email-masked]  Fri Apr  8 06:07:58 2011
From: Paul Hoffman <[email-masked]>
Date: Fri, 8 Apr 2011 06:09:37 -0700
To: Ben Laurie <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

On Apr 8, 2011, at 5:46 AM, Ben Laurie wrote:

> On 8 April 2011 13:33, Paul Hoffman <[email-masked]> wrote:
>> I note, again, that this has *nothing* to do with use cases or =
requirements. Having said that...
>=20
> I've already stated my requirement (that self-signed certs should be =
usable).

Sorry, you're right, you did. (Well, you said that they must be =
"first-class citizens", which is even more specific than "usable").

--Paul Hoffman

From [email-masked]  Fri Apr  8 06:15:19 2011
From: Paul Hoffman <[email-masked]>
Date: Fri, 8 Apr 2011 06:16:58 -0700
To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

On Apr 8, 2011, at 5:55 AM, Ond=C5=99ej Sur=C3=BD wrote:

> Richard,
>=20
> to rephrase my request:  I want to make life easier for people =
deploying the TLS on their sites.  I think that's the whole reason for =
the existence of this working group.  If the self-signed cert without =
the CA bits is malformed then we need some solution for this.

If the requirement is to allow a particular kind of malformed PKIX cert, =
then the solution would be "allow this particular kind of malformation". =
That is what Jakob and I proposed in the current draft.

Note that the WG can specify anything it wants about this type of =
malformed PKIX cert. For example, we might require that the Issuer name =
and the Subject name must be identical, or we might not.

--Paul Hoffman

From [email-masked]  Fri Apr  8 06:16:45 2011
Date: Fri, 08 Apr 2011 09:18:25 -0400
From: Carl Wallace <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>, =?ISO-8859-2?B?T25k+GVq?= =?ISO-8859-2?B?IFN1cv0=?= <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

On 4/8/11 8:46 AM, "Richard L. Barnes" <[email-masked]> wrote:

>To note again: The phrase "self-signed EE cert" does not make sense.
>From RFC 5280:
>"
>Self-issued certificates are generated to support changes in policy or
>operations.  Self-signed certificates are self-issued certificates where
>the digital signature may be verified by the public key bound into the
>certificate.
>"
>Since a self-signed cert has a cert issued under it (itself), it has to
>be a CA cert.
>
>A self-signed cert *without* the CA bits set is therefore malformed, and
>will not pass PKIX validation.

Why would you build a chain with the same certificate twice?  A
self-signed certificate needs to be explicitly trusted (i.e., it needs to
be a TA).  5280 does not mandate any content for a trust anchor other than
name and key so the extensions are not needed.  You would have to put
together a chain that repeated the self-signed certificate three times to
grow requirements for extensions.  Since one can opt to trust any name/key
one pleases, a self-signed EE certificate makes perfect sense, assuming
there's a means to establish trust and constrain its usage.

>Which brings us back to the point that if you want certs that really
>aren't signed by anybody, you might as well be using bare keys, or some
>new data structure that only carries what you're interested in, e.g., key
>parameters but not key usage, names, issuer, etc.
>--Richard

From [email-masked]  Fri Apr  8 06:18:07 2011
Date: Fri, 8 Apr 2011 14:19:46 +0100
From: Ben Laurie <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

On 8 April 2011 13:46, Richard L. Barnes <[email-masked]> wrote:
> To note again: The phrase "self-signed EE cert" does not make sense. =C2=
=A0From RFC 5280:
> "
> Self-issued certificates are generated to support changes in policy or op=
erations. =C2=A0Self-signed certificates are self-issued certificates where=
 the digital signature may be verified by the public key bound into the cer=
tificate.
> "
> Since a self-signed cert has a cert issued under it (itself), it has to b=
e a CA cert.
>
> A self-signed cert *without* the CA bits set is therefore malformed, and =
will not pass PKIX validation.

This may be true in theory, but is far from true in practice - in
practice, I can put a self-signed cert on my website and it works just
fine (in the sense that it is not considered malformed, just rather
untrustworthy).

So, this is just spec lawyering.

>
> Which brings us back to the point that if you want certs that really aren=
't signed by anybody, you might as well be using bare keys, or some new dat=
a structure that only carries what you're interested in, e.g., key paramete=
rs but not key usage, names, issuer, etc.
>
> --Richard
>
>
>
>
> On Apr 8, 2011, at 8:36 AM, Ond=C5=99ej Sur=C3=BD wrote:
>
>> My question to the list is if we can avoid specifying which X.509 versio=
n the client/server has to use and leave it to the client policy.
>>
>> Martin's approach seems like a reasonable one, but the question is if we=
 can fit it into our draft without advice to break any existing standard.
>>
>> I know that we are standards group (to reply to PHB later in this thread=
), but we also cannot afford to ignore what's happening in the real world o=
therwise the world is going to ignore us.
>>
>> I think that usage of self-signed EE cert is a reasonable use case (whic=
h may or may not make it to the protocol) and it shouldn't be left out. =C2=
=A0So please everybody let's think harder how to make things for non-protoc=
ol-geeks out there simpler, so the fruit of our work is a tasty one and not=
 bittersweet.
>>
>> O.
>>
>> On 4/8/11 4:58 AM, Martin Rex wrote:
>>> Stephen Kent wrote:
>>>>
>>>> James Cloos wrote:
>>>>>
>>>>> EE certs in the rr is in all of the drafts, was the original target, =
is
>>>>> easy to understand and explain, and I've read more consensus for than
>>>>> against on the list.
>>>>>
>>>>> Why the sudden backlash against?
>>>>
>>>> It's not sudden :-). A self-signed cert is a CA cert, by definition (s=
ee
>>>> the cites to RFC 5280 in Paul's I-D.
>>>
>>> RFC 5280 is about X.509v3 certs _ONLY_.
>>>
>>> There is NO problem creating X.509v1 End-Entity certs that are self-sig=
ned.
>>> And there is no problem using any of these with implementations of
>>> SSLv3 and TLSv1.0.
>>>
>>> SSLv3 predates IETF PKIX standards, and TLSv1.0 is related to
>>> rfc-2459 rather than rfc-5280 -- but implementations of TLSv1.0
>>> were often shipped before publication of TLSv1.0 (rfc-2246) and
>>> the original PKIX certificate profile (rfc-2459).
>>>
>>>
>>> For safety, it would be sensible to ALWAYS treat X.509v1 certs as
>>> EndEntity certs (i.e. never accept them as signer of other certs).
>>> Our TLS implementation had done this initially, but we had a customer
>>> that had obtained server certs issued under a VeriSign X.509v1 CA cert
>>> (as late as 2006!), so I had to make our OEM implementation tolerate th=
is.
>>>
>>>
>>>
>>>>
>>>> The TLS spec talks in terms of an "end entity's cert" as representing
>>>> a a server (or client). From a PKI perspective, the cert that represen=
ts
>>>> a server or client MUST be an EE cert,
>>>
>>> Like an X.509v1 self-signed EE cert. =C2=A0Works perfectly fine with al=
l
>>> TLS implementations that I've met.
>>>
>>> Keep in mind that TLS is not limited to X.509v3 certs.
>>>
>>> =C2=A0 TLSv1.0: =C2=A0 =C2=A0http://tools.ietf.org/html/rfc2246#section=
-7.4.2
>>> =C2=A0 TLSv1.1: =C2=A0 =C2=A0http://tools.ietf.org/html/rfc4346#section=
-7.4.2
>>>
>>> =C2=A0 =C2=A07.4.2. Server certificate
>>>
>>> =C2=A0 =C2=A0 =C2=A0 [...]
>>>
>>> =C2=A0 =C2=A0Meaning of this message:
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0The certificate type must be appropriate for=
 the selected cipher
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0suite's key exchange algorithm, and is gener=
ally an X.509v3
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0certificate. It must contain a key which mat=
ches the key exchange
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0method, as follows.
>>>
>>>
>>>>
>>>> an thus cannot be self-signed.
>>>
>>> TLSv1.0 and TLSv1.1 have neither a problem with X.509v1 nor
>>> with a self-signed X.509v1 End-Entity cert.
>>>
>>>
>>>> The fact that many implementations
>>>> violate IETF PKI standards in this regard, is unfortunate, but it is n=
ot
>>>> a basis for issuing a new IETF standard that codifies this behavior.
>>>
>>> I know that there are lots of commercial CAs that still have CA certs
>>> in every browser that are not valid CA certs according to PKIX / RFC 52=
80.
>>>
>>> But having TLSv1.0&TLSv1.1 (i.e. 99% of the installed base)
>>> accept X.509v1 self-signed EE certs is perfectly fine.
>>>
>>> X.509v1 is fairly close to a bare key, supported by all TLS implementat=
ions
>>> in the installed base, as well as tools in the installed base, such as
>>> the openssl.exe shell and for transfering keypairs within PKCS#12/PFX.
>>
>> _______________________________________________
>> dane mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dane
>
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

From [email-masked]  Fri Apr  8 06:30:52 2011
Date: Fri, 8 Apr 2011 13:32:35 +0000
From: Phillip Hallam-Baker <[email-masked]>
To: Ben Laurie <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

--20cf307cfc6840850204a0684200
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

The solution to standards lawyering is more standards lawyering.

Strictly speaking a self-signed certificate that does not have the CA bit
set is a valid X.509v3/PKIX certificate with an invalid signature.

Since the signature is invalid, it must be rejected when it is verified.

This is of no consequence because there is no point in checking the
signature on a self signed cert.

So just (1) write the spec accordingly and (2) drop a defect report into th=
e
ITU process proposing to allow self-signed certs in order to align the
standards documentation with actual practice.

On Fri, Apr 8, 2011 at 1:19 PM, Ben Laurie <[email-masked]> wrote:

> On 8 April 2011 13:46, Richard L. Barnes <[email-masked]> wrote:
> > To note again: The phrase "self-signed EE cert" does not make sense.
>  From RFC 5280:
> > "
> > Self-issued certificates are generated to support changes in policy or
> operations.  Self-signed certificates are self-issued certificates where =
the
> digital signature may be verified by the public key bound into the
> certificate.
> > "
> > Since a self-signed cert has a cert issued under it (itself), it has to
> be a CA cert.
> >
> > A self-signed cert *without* the CA bits set is therefore malformed, an=
d
> will not pass PKIX validation.
>
> This may be true in theory, but is far from true in practice - in
> practice, I can put a self-signed cert on my website and it works just
> fine (in the sense that it is not considered malformed, just rather
> untrustworthy).
>
> So, this is just spec lawyering.
>
> >
> > Which brings us back to the point that if you want certs that really
> aren't signed by anybody, you might as well be using bare keys, or some n=
ew
> data structure that only carries what you're interested in, e.g., key
> parameters but not key usage, names, issuer, etc.
> >
> > --Richard
> >
> >
> >
> >
> > On Apr 8, 2011, at 8:36 AM, Ond=C5=99ej Sur=C3=BD wrote:
> >
> >> My question to the list is if we can avoid specifying which X.509
> version the client/server has to use and leave it to the client policy.
> >>
> >> Martin's approach seems like a reasonable one, but the question is if =
we
> can fit it into our draft without advice to break any existing standard.
> >>
> >> I know that we are standards group (to reply to PHB later in this
> thread), but we also cannot afford to ignore what's happening in the real
> world otherwise the world is going to ignore us.
> >>
> >> I think that usage of self-signed EE cert is a reasonable use case
> (which may or may not make it to the protocol) and it shouldn't be left o=
ut.
>  So please everybody let's think harder how to make things for
> non-protocol-geeks out there simpler, so the fruit of our work is a tasty
> one and not bittersweet.
> >>
> >> O.
> >>
> >> On 4/8/11 4:58 AM, Martin Rex wrote:
> >>> Stephen Kent wrote:
> >>>>
> >>>> James Cloos wrote:
> >>>>>
> >>>>> EE certs in the rr is in all of the drafts, was the original target=
,
> is
> >>>>> easy to understand and explain, and I've read more consensus for th=
an
> >>>>> against on the list.
> >>>>>
> >>>>> Why the sudden backlash against?
> >>>>
> >>>> It's not sudden :-). A self-signed cert is a CA cert, by definition
> (see
> >>>> the cites to RFC 5280 in Paul's I-D.
> >>>
> >>> RFC 5280 is about X.509v3 certs _ONLY_.
> >>>
> >>> There is NO problem creating X.509v1 End-Entity certs that are
> self-signed.
> >>> And there is no problem using any of these with implementations of
> >>> SSLv3 and TLSv1.0.
> >>>
> >>> SSLv3 predates IETF PKIX standards, and TLSv1.0 is related to
> >>> rfc-2459 rather than rfc-5280 -- but implementations of TLSv1.0
> >>> were often shipped before publication of TLSv1.0 (rfc-2246) and
> >>> the original PKIX certificate profile (rfc-2459).
> >>>
> >>>
> >>> For safety, it would be sensible to ALWAYS treat X.509v1 certs as
> >>> EndEntity certs (i.e. never accept them as signer of other certs).
> >>> Our TLS implementation had done this initially, but we had a customer
> >>> that had obtained server certs issued under a VeriSign X.509v1 CA cer=
t
> >>> (as late as 2006!), so I had to make our OEM implementation tolerate
> this.
> >>>
> >>>
> >>>
> >>>>
> >>>> The TLS spec talks in terms of an "end entity's cert" as representin=
g
> >>>> a a server (or client). From a PKI perspective, the cert that
> represents
> >>>> a server or client MUST be an EE cert,
> >>>
> >>> Like an X.509v1 self-signed EE cert.  Works perfectly fine with all
> >>> TLS implementations that I've met.
> >>>
> >>> Keep in mind that TLS is not limited to X.509v3 certs.
> >>>
> >>>   TLSv1.0:    http://tools.ietf.org/html/rfc2246#section-7.4.2
> >>>   TLSv1.1:    http://tools.ietf.org/html/rfc4346#section-7.4.2
> >>>
> >>>    7.4.2. Server certificate
> >>>
> >>>       [...]
> >>>
> >>>    Meaning of this message:
> >>>        The certificate type must be appropriate for the selected ciph=
er
> >>>        suite's key exchange algorithm, and is generally an X.509v3
> >>>        certificate. It must contain a key which matches the key
> exchange
> >>>        method, as follows.
> >>>
> >>>
> >>>>
> >>>> an thus cannot be self-signed.
> >>>
> >>> TLSv1.0 and TLSv1.1 have neither a problem with X.509v1 nor
> >>> with a self-signed X.509v1 End-Entity cert.
> >>>
> >>>
> >>>> The fact that many implementations
> >>>> violate IETF PKI standards in this regard, is unfortunate, but it is
> not
> >>>> a basis for issuing a new IETF standard that codifies this behavior.
> >>>
> >>> I know that there are lots of commercial CAs that still have CA certs
> >>> in every browser that are not valid CA certs according to PKIX / RFC
> 5280.
> >>>
> >>> But having TLSv1.0&TLSv1.1 (i.e. 99% of the installed base)
> >>> accept X.509v1 self-signed EE certs is perfectly fine.
> >>>
> >>> X.509v1 is fairly close to a bare key, supported by all TLS
> implementations
> >>> in the installed base, as well as tools in the installed base, such a=
s
> >>> the openssl.exe shell and for transfering keypairs within PKCS#12/PFX=
.
> >>
> >> _______________________________________________
> >> dane mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/dane
> >
> > _______________________________________________
> > dane mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/dane
> >
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

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

--20cf307cfc6840850204a0684200
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div>The solution to standards lawyering is more standards lawyering.</div>=
<div><br></div><div><br></div><div>Strictly speaking a self-signed certific=
ate that does not have the CA bit set is a valid X.509v3/PKIX certificate w=
ith an invalid signature.</div>
<div><br></div><div>Since the signature is invalid, it must be rejected whe=
n it is verified.</div><div><br></div><div>This is of no consequence becaus=
e there is no point in checking the signature on a self signed cert.</div>
<div><br></div><div>So just (1) write the spec accordingly and (2) drop a d=
efect report into the ITU process proposing to allow self-signed certs in o=
rder to align the standards documentation with actual practice.</div><div>
<br></div><div><br></div>On Fri, Apr 8, 2011 at 1:19 PM, Ben Laurie <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>&gt;</=
span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">On 8 April 2011 13:46, Richard L. Barnes &lt;<a href=3D"m=
ailto:[email-masked]">[email-masked]</a>&gt; wrote:<br>
&gt; To note again: The phrase &quot;self-signed EE cert&quot; does not mak=
e sense. =C2=A0From RFC 5280:<br>
&gt; &quot;<br>
&gt; Self-issued certificates are generated to support changes in policy or=
 operations. =C2=A0Self-signed certificates are self-issued certificates wh=
ere the digital signature may be verified by the public key bound into the =
certificate.<br>

&gt; &quot;<br>
&gt; Since a self-signed cert has a cert issued under it (itself), it has t=
o be a CA cert.<br>
&gt;<br>
&gt; A self-signed cert *without* the CA bits set is therefore malformed, a=
nd will not pass PKIX validation.<br>
<br>
</div>This may be true in theory, but is far from true in practice - in<br>
practice, I can put a self-signed cert on my website and it works just<br>
fine (in the sense that it is not considered malformed, just rather<br>
untrustworthy).<br>
<br>
So, this is just spec lawyering.<br>
<div><div></div><div class=3D"h5"><br>
&gt;<br>
&gt; Which brings us back to the point that if you want certs that really a=
ren&#39;t signed by anybody, you might as well be using bare keys, or some =
new data structure that only carries what you&#39;re interested in, e.g., k=
ey parameters but not key usage, names, issuer, etc.<br>

&gt;<br>
&gt; --Richard<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Apr 8, 2011, at 8:36 AM, Ond=C5=99ej Sur=C3=BD wrote:<br>
&gt;<br>
&gt;&gt; My question to the list is if we can avoid specifying which X.509 =
version the client/server has to use and leave it to the client policy.<br>
&gt;&gt;<br>
&gt;&gt; Martin&#39;s approach seems like a reasonable one, but the questio=
n is if we can fit it into our draft without advice to break any existing s=
tandard.<br>
&gt;&gt;<br>
&gt;&gt; I know that we are standards group (to reply to PHB later in this =
thread), but we also cannot afford to ignore what&#39;s happening in the re=
al world otherwise the world is going to ignore us.<br>
&gt;&gt;<br>
&gt;&gt; I think that usage of self-signed EE cert is a reasonable use case=
 (which may or may not make it to the protocol) and it shouldn&#39;t be lef=
t out. =C2=A0So please everybody let&#39;s think harder how to make things =
for non-protocol-geeks out there simpler, so the fruit of our work is a tas=
ty one and not bittersweet.<br>

&gt;&gt;<br>
&gt;&gt; O.<br>
&gt;&gt;<br>
&gt;&gt; On 4/8/11 4:58 AM, Martin Rex wrote:<br>
&gt;&gt;&gt; Stephen Kent wrote:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; James Cloos wrote:<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; EE certs in the rr is in all of the drafts, was the or=
iginal target, is<br>
&gt;&gt;&gt;&gt;&gt; easy to understand and explain, and I&#39;ve read more=
 consensus for than<br>
&gt;&gt;&gt;&gt;&gt; against on the list.<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; Why the sudden backlash against?<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; It&#39;s not sudden :-). A self-signed cert is a CA cert, =
by definition (see<br>
&gt;&gt;&gt;&gt; the cites to RFC 5280 in Paul&#39;s I-D.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; RFC 5280 is about X.509v3 certs _ONLY_.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; There is NO problem creating X.509v1 End-Entity certs that are=
 self-signed.<br>
&gt;&gt;&gt; And there is no problem using any of these with implementation=
s of<br>
&gt;&gt;&gt; SSLv3 and TLSv1.0.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; SSLv3 predates IETF PKIX standards, and TLSv1.0 is related to<=
br>
&gt;&gt;&gt; rfc-2459 rather than rfc-5280 -- but implementations of TLSv1.=
0<br>
&gt;&gt;&gt; were often shipped before publication of TLSv1.0 (rfc-2246) an=
d<br>
&gt;&gt;&gt; the original PKIX certificate profile (rfc-2459).<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; For safety, it would be sensible to ALWAYS treat X.509v1 certs=
 as<br>
&gt;&gt;&gt; EndEntity certs (i.e. never accept them as signer of other cer=
ts).<br>
&gt;&gt;&gt; Our TLS implementation had done this initially, but we had a c=
ustomer<br>
&gt;&gt;&gt; that had obtained server certs issued under a VeriSign X.509v1=
 CA cert<br>
&gt;&gt;&gt; (as late as 2006!), so I had to make our OEM implementation to=
lerate this.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; The TLS spec talks in terms of an &quot;end entity&#39;s c=
ert&quot; as representing<br>
&gt;&gt;&gt;&gt; a a server (or client). From a PKI perspective, the cert t=
hat represents<br>
&gt;&gt;&gt;&gt; a server or client MUST be an EE cert,<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Like an X.509v1 self-signed EE cert. =C2=A0Works perfectly fin=
e with all<br>
&gt;&gt;&gt; TLS implementations that I&#39;ve met.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Keep in mind that TLS is not limited to X.509v3 certs.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; =C2=A0 TLSv1.0: =C2=A0 =C2=A0<a href=3D"http://tools.ietf.org/=
html/rfc2246#section-7.4.2" target=3D"_blank">http://tools.ietf.org/html/rf=
c2246#section-7.4.2</a><br>
&gt;&gt;&gt; =C2=A0 TLSv1.1: =C2=A0 =C2=A0<a href=3D"http://tools.ietf.org/=
html/rfc4346#section-7.4.2" target=3D"_blank">http://tools.ietf.org/html/rf=
c4346#section-7.4.2</a><br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; =C2=A0 =C2=A07.4.2. Server certificate<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; =C2=A0 =C2=A0 =C2=A0 [...]<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; =C2=A0 =C2=A0Meaning of this message:<br>
&gt;&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0The certificate type must be approp=
riate for the selected cipher<br>
&gt;&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0suite&#39;s key exchange algorithm,=
 and is generally an X.509v3<br>
&gt;&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0certificate. It must contain a key =
which matches the key exchange<br>
&gt;&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0method, as follows.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; an thus cannot be self-signed.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; TLSv1.0 and TLSv1.1 have neither a problem with X.509v1 nor<br=
>
&gt;&gt;&gt; with a self-signed X.509v1 End-Entity cert.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; The fact that many implementations<br>
&gt;&gt;&gt;&gt; violate IETF PKI standards in this regard, is unfortunate,=
 but it is not<br>
&gt;&gt;&gt;&gt; a basis for issuing a new IETF standard that codifies this=
 behavior.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; I know that there are lots of commercial CAs that still have C=
A certs<br>
&gt;&gt;&gt; in every browser that are not valid CA certs according to PKIX=
 / RFC 5280.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; But having TLSv1.0&amp;TLSv1.1 (i.e. 99% of the installed base=
)<br>
&gt;&gt;&gt; accept X.509v1 self-signed EE certs is perfectly fine.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; X.509v1 is fairly close to a bare key, supported by all TLS im=
plementations<br>
&gt;&gt;&gt; in the installed base, as well as tools in the installed base,=
 such as<br>
&gt;&gt;&gt; the openssl.exe shell and for transfering keypairs within PKCS=
#12/PFX.<br>
&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; dane mailing list<br>
&gt;&gt; <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
&gt;&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_=
blank">https://www.ietf.org/mailman/listinfo/dane</a><br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; dane mailing list<br>
&gt; <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blan=
k">https://www.ietf.org/mailman/listinfo/dane</a><br>
&gt;<br>
_______________________________________________<br>
dane mailing list<br>
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/dane</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>

--20cf307cfc6840850204a0684200--

From [email-masked]  Fri Apr  8 06:36:31 2011
Date: Fri, 8 Apr 2011 09:38:11 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>
Cc: [email-masked]
Subject: [dane] elephant use case, was Re:  [keyassure] Use cases document.

On Fri, 8 Apr 2011, Richard L. Barnes wrote:

> Which brings us back to the point that if you want certs that really aren't signed by anybody, you might as well be using bare keys, or some new data structure that only carries what you're interested in, e.g., key parameters but not key usage, names, issuer, etc.

Which I have been advocating for before this working group formed. And
for which I've started a TLS extension draft and got some good feedback
to at the IETF in Prague. Expect the draft submission in the next week
or two. I'll notify the TLS and DANE working group when we have submitted
the draft.

Back on the use case document issue, as long as we are ignoring the
elephant in the room, this discussion will get no where. CA based PKIX
has failed. The EFF SSL Observatory data, along with the recent Comodo
disaster clearly shows this.

If you want a use case, look at this: https://www.eff.org/files/colour_map_of_CAs.pdf

650+ organisations world wide can sign a certificate for any website. How
many of these have been hacked? How many more unqualified or RFC1918 space
signed certificates do we need to show? While OCSP on an IPsec gateway is
good to have, putting it in a browser results in a huge privacy problem.
On top of that, the OCSP revoked certificate lists are secret. Knowing
a serial number is revoked does not tell anyone if that misissued
certificate was for one of their domains.  Not only is the trust model
of commercial CA's broken, its execution is too much of a secret for us
to even be able to classify and identify the risks and the attacks on it.

TLS clearly needs an alternative trust model. DANE is about providing
one using DNSSEC. There will be others.

This working group, along with the TLS working group, should ensure that
moving forward, people no longer have to rely on a single failed trust
model, but can have their own client policy pick from a variety of trust
models they believe in. It is up to us to provide them with that. 

A good solution to start with is certificates in DNSSEC. A logical
continuation of that is a TLS mechanism for out of bound trust.

These things were very much happening in the working group, even before the
school principal was sent into the working group meeting to check up on
the teachers and their students. Please let them continue to do their work.

Paul

From [email-masked]  Fri Apr  8 06:48:05 2011
Date: Fri, 08 Apr 2011 14:49:41 +0100
From: Stephen Farrell <[email-masked]>
To: Ben Laurie <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

On 08/04/11 14:19, Ben Laurie wrote:
> On 8 April 2011 13:46, Richard L. Barnes <[email-masked]> wrote:
>> To note again: The phrase "self-signed EE cert" does not make sense.  From RFC 5280:
>> "
>> Self-issued certificates are generated to support changes in policy or operations.  Self-signed certificates are self-issued certificates where the digital signature may be verified by the public key bound into the certificate.
>> "
>> Since a self-signed cert has a cert issued under it (itself), it has to be a CA cert.
>>
>> A self-signed cert *without* the CA bits set is therefore malformed, and will not pass PKIX validation.

I think you're wrong there. RFC 5280, end of 6.2 says:

   Implementations that use self-signed certificates to specify trust
   anchor information are free to process or ignore such information.

The "such information" being certificate extensions. I don't see
anywhere where it says that the basic constraints extension is
any different.

I also think the quoted text above is a tad misleading since its
from a paragraph that discusses how CA's might use self-signed
certs.

5280 is IMO properly silent on how EEs might use self-signed
certs. (Or if not, I've forgotten what it says on that;-)

> This may be true in theory, but is far from true in practice - in
> practice, I can put a self-signed cert on my website and it works just
> fine (in the sense that it is not considered malformed, just rather
> untrustworthy).
> 
> So, this is just spec lawyering.

Some data: both SIP (rfc3261) and S/MIME (rfc5750) explicitly
allow self-signed certs. SDP/TLS (rfc4572) seems to have an
entire section about them. And of course TLS (rfc5246) says
you MAY include them.

So it looks to me like there's nothing whatsoever preventing
this WG from choosing to use EE self-signed certs if you want
to do that.

S.

From [email-masked]  Fri Apr  8 07:01:26 2011
From: Martin Rex <[email-masked]>
To: [email-masked] (Richard L. Barnes)
Date: Fri, 8 Apr 2011 16:01:53 +0200 (MEST)
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.
Reply-To: [email-masked]

Richard L. Barnes wrote:
> 
> To note again: The phrase "self-signed EE cert" does not make sense.
> From RFC 5280:
> "
> Self-issued certificates are generated to support changes in policy
> or operations.  Self-signed certificates are self-issued certificates
> where the digital signature may be verified by the public key bound
> into the certificate.
> "
> Since a self-signed cert has a cert issued under it (itself), it has
> to be a CA cert.
> 
> A self-signed cert *without* the CA bits set is therefore malformed,
> and will not pass PKIX validation.  

You seem to have entirely missed the most important of PKIX

  http://tools.ietf.org/html/rfc5280

   Abstract

   This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use
   in the Internet.

PKIX rules, by their own definition, do not apply to X.509v1 self-signed
EE certs.  And SSLv3, TLSv1.0 and TLSv1.1 are perfectly usable with X.509v1
self-signed EE certs.

It would be interesting to know from the SSLiverse database how many
TLS server certs on the internet are self-signed EE certs vs. CA-signed,
and how many of the self-signed TLS server certs are X.509v1.

-Martin

From [email-masked]  Fri Apr  8 07:44:17 2011
Date: Fri, 8 Apr 2011 14:46:01 +0000
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Wouters <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] elephant use case, was Re: [keyassure] Use cases document.

--bcaec50166a5d9f9c004a06948dd
Content-Type: text/plain; charset=ISO-8859-1

Could people actually take some time to learn about what the EFF data means
before engaging in this hyperbole?

There are not and have never been 600 RA certs. The EFF people do not
understand what the data means or why the certs are configured the way they
are. In fact the pressure that we have had from Mozilla and other sources is
to increase the number of intermediate certs.

The main reason for not doing so is that there are people out there who
appear determined to misrepresent the implications.

An intermediate certificate does not imply an RA capability.
Nor does an RA capability require an intermediate certificate.

The two issues are completely separate. It is like measuring the number of
lawyers in Washington by counting the number of Mercedes on the streets.
There is almost no correlation.

The majority of the intermediate certs turn out to have been issued by one
CA (DFN-Verein) which has adopted the strategy as a means of keeping their
CRL sizes manageably small and/or as a means of locking each customer to a
single intermediate key. Calling the intermediate certs 'RA' certs is
deceptive and wrong.

What is significant is the number of key signing units in service. And that
is impossible to measure from the EFF observatory. There is no way that you
can find out from observing the cert paths whether the intermediate certs
off the DFN-Verein roots are under control of a different party or not.

Contrawise, until a few weeks ago there were Comodo resellers that had RA
capability but did not have an intermediate root at all. As of today there
are precisely 0 Comodo resellers that have RA capability.

This has been explained to you multiple times but you still keep trotting
out this canard time and again.

The fact that someone can put together a very pretty graph does not mean
that it actually means anything. Here the EFF is damaging its credibility by
allowing this group to misrepresent the implications of its work.

We should be encouraging people to deploy intermediate roots. Doing so
improves the robustness of the system. Grandstanding the issue and claiming
that it indicates a weakness is a dis-service to the community.

On Fri, Apr 8, 2011 at 1:38 PM, Paul Wouters <[email-masked]> wrote:

> On Fri, 8 Apr 2011, Richard L. Barnes wrote:
>
> > Which brings us back to the point that if you want certs that really
> aren't signed by anybody, you might as well be using bare keys, or some new
> data structure that only carries what you're interested in, e.g., key
> parameters but not key usage, names, issuer, etc.
>
> Which I have been advocating for before this working group formed. And
> for which I've started a TLS extension draft and got some good feedback
> to at the IETF in Prague. Expect the draft submission in the next week
> or two. I'll notify the TLS and DANE working group when we have submitted
> the draft.
>
> Back on the use case document issue, as long as we are ignoring the
> elephant in the room, this discussion will get no where. CA based PKIX
> has failed. The EFF SSL Observatory data, along with the recent Comodo
> disaster clearly shows this.
>
> If you want a use case, look at this:
> https://www.eff.org/files/colour_map_of_CAs.pdf
>
> 650+ organisations world wide can sign a certificate for any website. How
> many of these have been hacked? How many more unqualified or RFC1918 space
> signed certificates do we need to show? While OCSP on an IPsec gateway is
> good to have, putting it in a browser results in a huge privacy problem.
> On top of that, the OCSP revoked certificate lists are secret. Knowing
> a serial number is revoked does not tell anyone if that misissued
> certificate was for one of their domains.  Not only is the trust model
> of commercial CA's broken, its execution is too much of a secret for us
> to even be able to classify and identify the risks and the attacks on it.
>
> TLS clearly needs an alternative trust model. DANE is about providing
> one using DNSSEC. There will be others.
>
> This working group, along with the TLS working group, should ensure that
> moving forward, people no longer have to rely on a single failed trust
> model, but can have their own client policy pick from a variety of trust
> models they believe in. It is up to us to provide them with that.
>
> A good solution to start with is certificates in DNSSEC. A logical
> continuation of that is a TLS mechanism for out of bound trust.
>
> These things were very much happening in the working group, even before the
> school principal was sent into the working group meeting to check up on
> the teachers and their students. Please let them continue to do their work.
>
> Paul
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

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

--bcaec50166a5d9f9c004a06948dd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Could people actually take some time to learn about what the EFF data means=
 before engaging in this hyperbole?<div><br></div><div>There are not and ha=
ve never been 600 RA certs. The EFF people do not understand what the data =
means or why the certs are configured the way they are. In fact the pressur=
e that we have had from Mozilla and other sources is to increase the number=
 of intermediate certs.</div>
<div><br></div><div>The main reason for not doing so is that there are peop=
le out there who appear determined to misrepresent the implications.</div><=
div><br></div><div><br></div><div>An intermediate certificate does not impl=
y an RA capability.</div>
<div>Nor does an RA capability require an intermediate certificate.</div><d=
iv><br></div><div><br></div><div>The two issues are completely separate. It=
 is like measuring the number of lawyers in Washington by counting the numb=
er of Mercedes on the streets. There is almost no correlation.</div>
<div><br></div><div><br></div><div>The majority of the intermediate certs t=
urn out to have been issued by one CA (DFN-Verein) which has adopted the st=
rategy as a means of keeping their CRL sizes manageably small and/or as a m=
eans of locking each customer to a single intermediate key. Calling the int=
ermediate certs &#39;RA&#39; certs is deceptive and wrong.</div>
<div><br></div><div>What is significant is the number of key signing units =
in service. And that is impossible to measure from the EFF observatory. The=
re is no way that you can find out from observing the cert paths whether th=
e intermediate certs off the DFN-Verein roots are under control of a differ=
ent party or not.</div>
<div><br></div><div>Contrawise, until a few weeks ago there were Comodo res=
ellers that had RA capability but did not have an intermediate root at all.=
 As of today there are precisely 0 Comodo resellers that have RA capability=
.</div>
<div><br></div><div><br></div><div>This has been explained to you multiple =
times but you still keep trotting out this canard time and again.</div><div=
><br></div><div>The fact that someone can put together a very pretty graph =
does not mean that it actually means anything. Here the EFF is damaging its=
 credibility by allowing this group to misrepresent the implications of its=
 work.</div>
<div><br></div><div><br></div><div>We should be encouraging people to deplo=
y intermediate roots. Doing so improves the robustness of the system. Grand=
standing the issue and claiming that it indicates a weakness is a dis-servi=
ce to the community.</div>
<div><br><br><div class=3D"gmail_quote">On Fri, Apr 8, 2011 at 1:38 PM, Pau=
l Wouters <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">paul@=
xelerance.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
On Fri, 8 Apr 2011, Richard L. Barnes wrote:<br>
<br>
&gt; Which brings us back to the point that if you want certs that really a=
ren&#39;t signed by anybody, you might as well be using bare keys, or some =
new data structure that only carries what you&#39;re interested in, e.g., k=
ey parameters but not key usage, names, issuer, etc.<br>

<br>
Which I have been advocating for before this working group formed. And<br>
for which I&#39;ve started a TLS extension draft and got some good feedback=
<br>
to at the IETF in Prague. Expect the draft submission in the next week<br>
or two. I&#39;ll notify the TLS and DANE working group when we have submitt=
ed<br>
the draft.<br>
<br>
Back on the use case document issue, as long as we are ignoring the<br>
elephant in the room, this discussion will get no where. CA based PKIX<br>
has failed. The EFF SSL Observatory data, along with the recent Comodo<br>
disaster clearly shows this.<br>
<br>
If you want a use case, look at this: <a href=3D"https://www.eff.org/files/=
colour_map_of_CAs.pdf" target=3D"_blank">https://www.eff.org/files/colour_m=
ap_of_CAs.pdf</a><br>
<br>
650+ organisations world wide can sign a certificate for any website. How<b=
r>
many of these have been hacked? How many more unqualified or RFC1918 space<=
br>
signed certificates do we need to show? While OCSP on an IPsec gateway is<b=
r>
good to have, putting it in a browser results in a huge privacy problem.<br=
>
On top of that, the OCSP revoked certificate lists are secret. Knowing<br>
a serial number is revoked does not tell anyone if that misissued<br>
certificate was for one of their domains. =A0Not only is the trust model<br=
>
of commercial CA&#39;s broken, its execution is too much of a secret for us=
<br>
to even be able to classify and identify the risks and the attacks on it.<b=
r>
<br>
TLS clearly needs an alternative trust model. DANE is about providing<br>
one using DNSSEC. There will be others.<br>
<br>
This working group, along with the TLS working group, should ensure that<br=
>
moving forward, people no longer have to rely on a single failed trust<br>
model, but can have their own client policy pick from a variety of trust<br=
>
models they believe in. It is up to us to provide them with that.<br>
<br>
A good solution to start with is certificates in DNSSEC. A logical<br>
continuation of that is a TLS mechanism for out of bound trust.<br>
<br>
These things were very much happening in the working group, even before the=
<br>
school principal was sent into the working group meeting to check up on<br>
the teachers and their students. Please let them continue to do their work.=
<br>
<br>
Paul<br>
_______________________________________________<br>
dane mailing list<br>
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/dane</a><br>
</blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a href=3D"htt=
p://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--bcaec50166a5d9f9c004a06948dd--

From [email-masked]  Fri Apr  8 07:48:41 2011
Date: Fri, 08 Apr 2011 16:50:23 +0200
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

On 4/8/11 4:01 PM, Martin Rex wrote:
> Richard L. Barnes wrote:
>>
>> To note again: The phrase "self-signed EE cert" does not make sense.
>>  From RFC 5280:
>> "
>> Self-issued certificates are generated to support changes in policy
>> or operations.  Self-signed certificates are self-issued certificates
>> where the digital signature may be verified by the public key bound
>> into the certificate.
>> "
>> Since a self-signed cert has a cert issued under it (itself), it has
>> to be a CA cert.
>>
>> A self-signed cert *without* the CA bits set is therefore malformed,
>> and will not pass PKIX validation.
>
> You seem to have entirely missed the most important of PKIX
>
>    http://tools.ietf.org/html/rfc5280
>
>     Abstract
>
>     This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use
>     in the Internet.
>
> PKIX rules, by their own definition, do not apply to X.509v1 self-signed
> EE certs.  And SSLv3, TLSv1.0 and TLSv1.1 are perfectly usable with X.509v1
> self-signed EE certs.

So, is this something we can agree on?  I am inclined to open a ticket, 
so we can document this in more compact form with pros and cons, but 
still it seems to be a good approach to not break any standard and 
allowing us to do what we want to.

> It would be interesting to know from the SSLiverse database how many
> TLS server certs on the internet are self-signed EE certs vs. CA-signed,
> and how many of the self-signed TLS server certs are X.509v1.

I wrote to Peter Eckersley@EFF with exactly this question.  Let's see if 
he responds.

Ondrej

From [email-masked]  Fri Apr  8 08:26:50 2011
From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 8 Apr 2011 11:28:33 -0400
To: Ben Laurie <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

To turn the question around, why would we not try to get it right this =
time?  Servers are going to have to do some re-provisioning anyway to =
enable DANE, and it's just not that much extra work to get it right.  I =
just did this myself as an experiment:

To generate a self-signed (CA!) cert:
openssl genrsa -out dane.key 1024
openssl req -new -key dane.key -out dane-ca.csr
openssl x509 -req -days 365 -in dane-ca.csr \
             -signkey dane.key -out dane-ca-cert.pem

To generate an EE cert under that:
# Generate an EE cert under that certificate
openssl req -new -key dane.key -out dane-server.csr
openssl x509 -req -days 365 -in dane-server.csr \
             -CA dane-ca-cert.pem -CAkey dane.key \
             -CAcreateserial -out dane-server-cert.pem

If you want to verify that it worked:
openssl verify -CAfile dane-ca-cert.pem -purpose sslserver =
dane-server-cert.pem

That's it!  You provision the CA cert to DANE, and you use the EE cert =
on the server just like a cert from any other CA.  The effort is once =
per cert expiry, which you as the CA can make as long as you want. =20

--Richard

On Apr 8, 2011, at 9:19 AM, Ben Laurie wrote:

> On 8 April 2011 13:46, Richard L. Barnes <[email-masked]> wrote:
>> To note again: The phrase "self-signed EE cert" does not make sense.  =
=46rom RFC 5280:
>> "
>> Self-issued certificates are generated to support changes in policy =
or operations.  Self-signed certificates are self-issued certificates =
where the digital signature may be verified by the public key bound into =
the certificate.
>> "
>> Since a self-signed cert has a cert issued under it (itself), it has =
to be a CA cert.
>>=20
>> A self-signed cert *without* the CA bits set is therefore malformed, =
and will not pass PKIX validation.
>=20
> This may be true in theory, but is far from true in practice - in
> practice, I can put a self-signed cert on my website and it works just
> fine (in the sense that it is not considered malformed, just rather
> untrustworthy).
>=20
> So, this is just spec lawyering.
>=20
>>=20
>> Which brings us back to the point that if you want certs that really =
aren't signed by anybody, you might as well be using bare keys, or some =
new data structure that only carries what you're interested in, e.g., =
key parameters but not key usage, names, issuer, etc.
>>=20
>> --Richard
>>=20
>>=20
>>=20
>>=20
>> On Apr 8, 2011, at 8:36 AM, Ond=C5=99ej Sur=C3=BD wrote:
>>=20
>>> My question to the list is if we can avoid specifying which X.509 =
version the client/server has to use and leave it to the client policy.
>>>=20
>>> Martin's approach seems like a reasonable one, but the question is =
if we can fit it into our draft without advice to break any existing =
standard.
>>>=20
>>> I know that we are standards group (to reply to PHB later in this =
thread), but we also cannot afford to ignore what's happening in the =
real world otherwise the world is going to ignore us.
>>>=20
>>> I think that usage of self-signed EE cert is a reasonable use case =
(which may or may not make it to the protocol) and it shouldn't be left =
out.  So please everybody let's think harder how to make things for =
non-protocol-geeks out there simpler, so the fruit of our work is a =
tasty one and not bittersweet.
>>>=20
>>> O.
>>>=20
>>> On 4/8/11 4:58 AM, Martin Rex wrote:
>>>> Stephen Kent wrote:
>>>>>=20
>>>>> James Cloos wrote:
>>>>>>=20
>>>>>> EE certs in the rr is in all of the drafts, was the original =
target, is
>>>>>> easy to understand and explain, and I've read more consensus for =
than
>>>>>> against on the list.
>>>>>>=20
>>>>>> Why the sudden backlash against?
>>>>>=20
>>>>> It's not sudden :-). A self-signed cert is a CA cert, by =
definition (see
>>>>> the cites to RFC 5280 in Paul's I-D.
>>>>=20
>>>> RFC 5280 is about X.509v3 certs _ONLY_.
>>>>=20
>>>> There is NO problem creating X.509v1 End-Entity certs that are =
self-signed.
>>>> And there is no problem using any of these with implementations of
>>>> SSLv3 and TLSv1.0.
>>>>=20
>>>> SSLv3 predates IETF PKIX standards, and TLSv1.0 is related to
>>>> rfc-2459 rather than rfc-5280 -- but implementations of TLSv1.0
>>>> were often shipped before publication of TLSv1.0 (rfc-2246) and
>>>> the original PKIX certificate profile (rfc-2459).
>>>>=20
>>>>=20
>>>> For safety, it would be sensible to ALWAYS treat X.509v1 certs as
>>>> EndEntity certs (i.e. never accept them as signer of other certs).
>>>> Our TLS implementation had done this initially, but we had a =
customer
>>>> that had obtained server certs issued under a VeriSign X.509v1 CA =
cert
>>>> (as late as 2006!), so I had to make our OEM implementation =
tolerate this.
>>>>=20
>>>>=20
>>>>=20
>>>>>=20
>>>>> The TLS spec talks in terms of an "end entity's cert" as =
representing
>>>>> a a server (or client). =46rom a PKI perspective, the cert that =
represents
>>>>> a server or client MUST be an EE cert,
>>>>=20
>>>> Like an X.509v1 self-signed EE cert.  Works perfectly fine with all
>>>> TLS implementations that I've met.
>>>>=20
>>>> Keep in mind that TLS is not limited to X.509v3 certs.
>>>>=20
>>>>   TLSv1.0:    http://tools.ietf.org/html/rfc2246#section-7.4.2
>>>>   TLSv1.1:    http://tools.ietf.org/html/rfc4346#section-7.4.2
>>>>=20
>>>>    7.4.2. Server certificate
>>>>=20
>>>>       [...]
>>>>=20
>>>>    Meaning of this message:
>>>>        The certificate type must be appropriate for the selected =
cipher
>>>>        suite's key exchange algorithm, and is generally an X.509v3
>>>>        certificate. It must contain a key which matches the key =
exchange
>>>>        method, as follows.
>>>>=20
>>>>=20
>>>>>=20
>>>>> an thus cannot be self-signed.
>>>>=20
>>>> TLSv1.0 and TLSv1.1 have neither a problem with X.509v1 nor
>>>> with a self-signed X.509v1 End-Entity cert.
>>>>=20
>>>>=20
>>>>> The fact that many implementations
>>>>> violate IETF PKI standards in this regard, is unfortunate, but it =
is not
>>>>> a basis for issuing a new IETF standard that codifies this =
behavior.
>>>>=20
>>>> I know that there are lots of commercial CAs that still have CA =
certs
>>>> in every browser that are not valid CA certs according to PKIX / =
RFC 5280.
>>>>=20
>>>> But having TLSv1.0&TLSv1.1 (i.e. 99% of the installed base)
>>>> accept X.509v1 self-signed EE certs is perfectly fine.
>>>>=20
>>>> X.509v1 is fairly close to a bare key, supported by all TLS =
implementations
>>>> in the installed base, as well as tools in the installed base, such =
as
>>>> the openssl.exe shell and for transfering keypairs within =
PKCS#12/PFX.
>>>=20
>>> _______________________________________________
>>> dane mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/dane
>>=20
>> _______________________________________________
>> dane mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dane
>>=20

From [email-masked]  Fri Apr  8 09:03:13 2011
Date: Fri, 8 Apr 2011 16:04:56 +0000
From: Phillip Hallam-Baker <[email-masked]>
To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

--20cf3054aabf19e0ee04a06a6327
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

No avoiding Kent's issue by using v1 is not something we can agree on. I
think we can get to consensus on using self-signed v3 as EE certs though.

Trying to use X.509v1 certs is a bad idea and it is unnecessary. It would
then mean that DANE had a downref to a spec that the ITU has superseded.

As Stephen Farrell points out, Steve Kent is wrong on this point. And he wa=
s
the editor of the spec. Farrell is the editor of the spec in question and
has pointed out that there is precedence from other working groups.

At this point I suggest a consensus call on the following proposal:

1) Note the objection raised by Kent

2) Note the rebuttal by Farrell

3) Leave the spec unchanged - self signed X.509v3 EE certs allowed.

If Kent continues to disagree he can take his objection up with the securit=
y
AD for DANE or raise the issue in WG or IETF last call.

But in my view the whole discussion is moot since I don't see any need for
DANE to say anything more about the certificate type other than it be PKIX
compliant.

On Fri, Apr 8, 2011 at 2:50 PM, Ond=C5=99ej Sur=C3=BD <[email-masked]> =
wrote:

> On 4/8/11 4:01 PM, Martin Rex wrote:
>
>> Richard L. Barnes wrote:
>>
>>>
>>> To note again: The phrase "self-signed EE cert" does not make sense.
>>>  From RFC 5280:
>>> "
>>> Self-issued certificates are generated to support changes in policy
>>> or operations.  Self-signed certificates are self-issued certificates
>>> where the digital signature may be verified by the public key bound
>>> into the certificate.
>>> "
>>> Since a self-signed cert has a cert issued under it (itself), it has
>>> to be a CA cert.
>>>
>>> A self-signed cert *without* the CA bits set is therefore malformed,
>>> and will not pass PKIX validation.
>>>
>>
>> You seem to have entirely missed the most important of PKIX
>>
>>   http://tools.ietf.org/html/rfc5280
>>
>>    Abstract
>>
>>    This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use
>>    in the Internet.
>>
>> PKIX rules, by their own definition, do not apply to X.509v1 self-signed
>> EE certs.  And SSLv3, TLSv1.0 and TLSv1.1 are perfectly usable with
>> X.509v1
>> self-signed EE certs.
>>
>
> So, is this something we can agree on?  I am inclined to open a ticket, s=
o
> we can document this in more compact form with pros and cons, but still i=
t
> seems to be a good approach to not break any standard and allowing us to =
do
> what we want to.
>
>
>  It would be interesting to know from the SSLiverse database how many
>> TLS server certs on the internet are self-signed EE certs vs. CA-signed,
>> and how many of the self-signed TLS server certs are X.509v1.
>>
>
> I wrote to Peter Eckersley@EFF with exactly this question.  Let's see if
> he responds.
>
> Ondrej
>
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

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

--20cf3054aabf19e0ee04a06a6327
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

No avoiding Kent&#39;s issue by using v1 is not something we can agree on. =
I think we can get to consensus on using self-signed v3 as EE certs though.=
<div><br></div><div><br></div><div>Trying to use X.509v1 certs is a bad ide=
a and it is unnecessary. It would then mean that DANE had a downref to a sp=
ec that the ITU has=A0superseded.=A0</div>
<div><br></div><div>As Stephen Farrell points out, Steve Kent is wrong on t=
his point. And he was the editor of the spec. Farrell is the editor of the =
spec in question and has pointed out that there is precedence from other wo=
rking groups.</div>
<div><br></div><div><br></div><div>At this point I suggest a consensus call=
 on the following proposal:</div><div><br></div><div>1) Note the objection =
raised by Kent</div><div><br></div><div>2) Note the rebuttal by Farrell</di=
v>
<div><br></div><div>3) Leave the spec unchanged - self signed X.509v3 EE ce=
rts allowed.</div><div><br></div><div><br></div><div>If Kent continues to d=
isagree he can take his objection up with the security AD for DANE or raise=
 the issue in WG or IETF last call.</div>
<div><br></div><div>But in my view the whole discussion is moot since I don=
&#39;t see any need for DANE to say anything more about the certificate typ=
e other than it be PKIX compliant.</div><div><br></div><div><br><div class=
=3D"gmail_quote">
On Fri, Apr 8, 2011 at 2:50 PM, Ond=F8ej Sur=FD <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex;">
<div class=3D"im">On 4/8/11 4:01 PM, Martin Rex wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Richard L. Barnes wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<br>
To note again: The phrase &quot;self-signed EE cert&quot; does not make sen=
se.<br>
=A0From RFC 5280:<br>
&quot;<br>
Self-issued certificates are generated to support changes in policy<br>
or operations. =A0Self-signed certificates are self-issued certificates<br>
where the digital signature may be verified by the public key bound<br>
into the certificate.<br>
&quot;<br>
Since a self-signed cert has a cert issued under it (itself), it has<br>
to be a CA cert.<br>
<br>
A self-signed cert *without* the CA bits set is therefore malformed,<br>
and will not pass PKIX validation.<br>
</blockquote>
<br>
You seem to have entirely missed the most important of PKIX<br>
<br>
 =A0 <a href=3D"http://tools.ietf.org/html/rfc5280" target=3D"_blank">http:=
//tools.ietf.org/html/rfc5280</a><br>
<br>
 =A0 =A0Abstract<br>
<br>
 =A0 =A0This memo profiles the X.509 v3 certificate and X.509 v2 CRL for us=
e<br>
 =A0 =A0in the Internet.<br>
<br>
PKIX rules, by their own definition, do not apply to X.509v1 self-signed<br=
>
EE certs. =A0And SSLv3, TLSv1.0 and TLSv1.1 are perfectly usable with X.509=
v1<br>
self-signed EE certs.<br>
</blockquote>
<br></div>
So, is this something we can agree on? =A0I am inclined to open a ticket, s=
o we can document this in more compact form with pros and cons, but still i=
t seems to be a good approach to not break any standard and allowing us to =
do what we want to.<div class=3D"im">
<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
It would be interesting to know from the SSLiverse database how many<br>
TLS server certs on the internet are self-signed EE certs vs. CA-signed,<br=
>
and how many of the self-signed TLS server certs are X.509v1.<br>
</blockquote>
<br></div>
I wrote to Peter Eckersley@EFF with exactly this question. =A0Let&#39;s see=
 if he responds.<br>
<br>
Ondrej<div><div></div><div class=3D"h5"><br>
_______________________________________________<br>
dane mailing list<br>
<a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/dane</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--20cf3054aabf19e0ee04a06a6327--

From [email-masked]  Fri Apr  8 09:10:14 2011
From: Martin Rex <[email-masked]>
To: [email-masked] (Richard L. Barnes)
Date: Fri, 8 Apr 2011 18:11:53 +0200 (MEST)
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.
Reply-To: [email-masked]

Richard L. Barnes wrote:
>
> To turn the question around, why would we not try to get it right
> this time?  Servers are going to have to do some re-provisioning
> anyway to enable DANE, and it's just not that much extra work to
> get it right.

Nothing needs to be done to the servers to enable DANE.
Just insert the self-signed EE cert that your server is currently
using as a TLSA record into the DNSSEC signed zone and you're done.

Creation of new self-signed cert for servers that do not already have one:

openssl genrsa -out myserver.key 2048
openssl req -new -x509 -key myserver.key -out myserver.pem -days 7300 -extensions new_oids

That's it!

There might be a bug in the OpenSSL 0.9.8h on the SLES-11 that I used,
it creates an extension-less X.509 certificate and seems to tag it 
as v3, algthough it ought to be tagged as v1 when it is extension-less.

The distributed openssl.cnf seems to lack an section for X.509v1 certs,
but there was a sufficiently empty section "new_oids" that did the job.

-Martin

From [email-masked]  Fri Apr  8 09:14:44 2011
Date: Fri, 8 Apr 2011 17:16:20 +0100
From: Ben Laurie <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

On 8 April 2011 16:28, Richard L. Barnes <[email-masked]> wrote:
> To turn the question around, why would we not try to get it right this ti=
me? =C2=A0Servers are going to have to do some re-provisioning anyway to en=
able DANE, and it's just not that much extra work to get it right. =C2=A0I =
just did this myself as an experiment:
>
> To generate a self-signed (CA!) cert:
> openssl genrsa -out dane.key 1024
> openssl req -new -key dane.key -out dane-ca.csr
> openssl x509 -req -days 365 -in dane-ca.csr \
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -signkey dane.key -out dane-ca-=
cert.pem
>
> To generate an EE cert under that:
> # Generate an EE cert under that certificate
> openssl req -new -key dane.key -out dane-server.csr
> openssl x509 -req -days 365 -in dane-server.csr \
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -CA dane-ca-cert.pem -CAkey dan=
e.key \
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -CAcreateserial -out dane-serve=
r-cert.pem
>
> If you want to verify that it worked:
> openssl verify -CAfile dane-ca-cert.pem -purpose sslserver dane-server-ce=
rt.pem
>
> That's it! =C2=A0You provision the CA cert to DANE, and you use the EE ce=
rt on the server just like a cert from any other CA. =C2=A0The effort is on=
ce per cert expiry, which you as the CA can make as long as you want.

That's not it - now you have to provision and configure the server(s)
to serve the chain.

>
> --Richard
>
>
>
> On Apr 8, 2011, at 9:19 AM, Ben Laurie wrote:
>
>> On 8 April 2011 13:46, Richard L. Barnes <[email-masked]> wrote:
>>> To note again: The phrase "self-signed EE cert" does not make sense. =
=C2=A0From RFC 5280:
>>> "
>>> Self-issued certificates are generated to support changes in policy or =
operations. =C2=A0Self-signed certificates are self-issued certificates whe=
re the digital signature may be verified by the public key bound into the c=
ertificate.
>>> "
>>> Since a self-signed cert has a cert issued under it (itself), it has to=
 be a CA cert.
>>>
>>> A self-signed cert *without* the CA bits set is therefore malformed, an=
d will not pass PKIX validation.
>>
>> This may be true in theory, but is far from true in practice - in
>> practice, I can put a self-signed cert on my website and it works just
>> fine (in the sense that it is not considered malformed, just rather
>> untrustworthy).
>>
>> So, this is just spec lawyering.
>>
>>>
>>> Which brings us back to the point that if you want certs that really ar=
en't signed by anybody, you might as well be using bare keys, or some new d=
ata structure that only carries what you're interested in, e.g., key parame=
ters but not key usage, names, issuer, etc.
>>>
>>> --Richard
>>>
>>>
>>>
>>>
>>> On Apr 8, 2011, at 8:36 AM, Ond=C5=99ej Sur=C3=BD wrote:
>>>
>>>> My question to the list is if we can avoid specifying which X.509 vers=
ion the client/server has to use and leave it to the client policy.
>>>>
>>>> Martin's approach seems like a reasonable one, but the question is if =
we can fit it into our draft without advice to break any existing standard.
>>>>
>>>> I know that we are standards group (to reply to PHB later in this thre=
ad), but we also cannot afford to ignore what's happening in the real world=
 otherwise the world is going to ignore us.
>>>>
>>>> I think that usage of self-signed EE cert is a reasonable use case (wh=
ich may or may not make it to the protocol) and it shouldn't be left out. =
=C2=A0So please everybody let's think harder how to make things for non-pro=
tocol-geeks out there simpler, so the fruit of our work is a tasty one and =
not bittersweet.
>>>>
>>>> O.
>>>>
>>>> On 4/8/11 4:58 AM, Martin Rex wrote:
>>>>> Stephen Kent wrote:
>>>>>>
>>>>>> James Cloos wrote:
>>>>>>>
>>>>>>> EE certs in the rr is in all of the drafts, was the original target=
, is
>>>>>>> easy to understand and explain, and I've read more consensus for th=
an
>>>>>>> against on the list.
>>>>>>>
>>>>>>> Why the sudden backlash against?
>>>>>>
>>>>>> It's not sudden :-). A self-signed cert is a CA cert, by definition =
(see
>>>>>> the cites to RFC 5280 in Paul's I-D.
>>>>>
>>>>> RFC 5280 is about X.509v3 certs _ONLY_.
>>>>>
>>>>> There is NO problem creating X.509v1 End-Entity certs that are self-s=
igned.
>>>>> And there is no problem using any of these with implementations of
>>>>> SSLv3 and TLSv1.0.
>>>>>
>>>>> SSLv3 predates IETF PKIX standards, and TLSv1.0 is related to
>>>>> rfc-2459 rather than rfc-5280 -- but implementations of TLSv1.0
>>>>> were often shipped before publication of TLSv1.0 (rfc-2246) and
>>>>> the original PKIX certificate profile (rfc-2459).
>>>>>
>>>>>
>>>>> For safety, it would be sensible to ALWAYS treat X.509v1 certs as
>>>>> EndEntity certs (i.e. never accept them as signer of other certs).
>>>>> Our TLS implementation had done this initially, but we had a customer
>>>>> that had obtained server certs issued under a VeriSign X.509v1 CA cer=
t
>>>>> (as late as 2006!), so I had to make our OEM implementation tolerate =
this.
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> The TLS spec talks in terms of an "end entity's cert" as representin=
g
>>>>>> a a server (or client). From a PKI perspective, the cert that repres=
ents
>>>>>> a server or client MUST be an EE cert,
>>>>>
>>>>> Like an X.509v1 self-signed EE cert. =C2=A0Works perfectly fine with =
all
>>>>> TLS implementations that I've met.
>>>>>
>>>>> Keep in mind that TLS is not limited to X.509v3 certs.
>>>>>
>>>>> =C2=A0 TLSv1.0: =C2=A0 =C2=A0http://tools.ietf.org/html/rfc2246#secti=
on-7.4.2
>>>>> =C2=A0 TLSv1.1: =C2=A0 =C2=A0http://tools.ietf.org/html/rfc4346#secti=
on-7.4.2
>>>>>
>>>>> =C2=A0 =C2=A07.4.2. Server certificate
>>>>>
>>>>> =C2=A0 =C2=A0 =C2=A0 [...]
>>>>>
>>>>> =C2=A0 =C2=A0Meaning of this message:
>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0The certificate type must be appropriate f=
or the selected cipher
>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0suite's key exchange algorithm, and is gen=
erally an X.509v3
>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0certificate. It must contain a key which m=
atches the key exchange
>>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0method, as follows.
>>>>>
>>>>>
>>>>>>
>>>>>> an thus cannot be self-signed.
>>>>>
>>>>> TLSv1.0 and TLSv1.1 have neither a problem with X.509v1 nor
>>>>> with a self-signed X.509v1 End-Entity cert.
>>>>>
>>>>>
>>>>>> The fact that many implementations
>>>>>> violate IETF PKI standards in this regard, is unfortunate, but it is=
 not
>>>>>> a basis for issuing a new IETF standard that codifies this behavior.
>>>>>
>>>>> I know that there are lots of commercial CAs that still have CA certs
>>>>> in every browser that are not valid CA certs according to PKIX / RFC =
5280.
>>>>>
>>>>> But having TLSv1.0&TLSv1.1 (i.e. 99% of the installed base)
>>>>> accept X.509v1 self-signed EE certs is perfectly fine.
>>>>>
>>>>> X.509v1 is fairly close to a bare key, supported by all TLS implement=
ations
>>>>> in the installed base, as well as tools in the installed base, such a=
s
>>>>> the openssl.exe shell and for transfering keypairs within PKCS#12/PFX=
.
>>>>
>>>> _______________________________________________
>>>> dane mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/dane
>>>
>>> _______________________________________________
>>> dane mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/dane
>>>
>
>

From [email-masked]  Fri Apr  8 09:16:36 2011
From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 8 Apr 2011 12:18:13 -0400
To: Ben Laurie <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

Ok, but that's just switching out a chain, if the server is already =
using TLS, or provisioning a new chain, which you would have to do =
anyway to use DANE.=20

Either way, it's a relatively small one-time cost.

--Richard

On Apr 8, 2011, at 12:16 PM, Ben Laurie wrote:

> On 8 April 2011 16:28, Richard L. Barnes <[email-masked]> wrote:
>> To turn the question around, why would we not try to get it right =
this time?  Servers are going to have to do some re-provisioning anyway =
to enable DANE, and it's just not that much extra work to get it right.  =
I just did this myself as an experiment:
>>=20
>> To generate a self-signed (CA!) cert:
>> openssl genrsa -out dane.key 1024
>> openssl req -new -key dane.key -out dane-ca.csr
>> openssl x509 -req -days 365 -in dane-ca.csr \
>>             -signkey dane.key -out dane-ca-cert.pem
>>=20
>> To generate an EE cert under that:
>> # Generate an EE cert under that certificate
>> openssl req -new -key dane.key -out dane-server.csr
>> openssl x509 -req -days 365 -in dane-server.csr \
>>             -CA dane-ca-cert.pem -CAkey dane.key \
>>             -CAcreateserial -out dane-server-cert.pem
>>=20
>> If you want to verify that it worked:
>> openssl verify -CAfile dane-ca-cert.pem -purpose sslserver =
dane-server-cert.pem
>>=20
>> That's it!  You provision the CA cert to DANE, and you use the EE =
cert on the server just like a cert from any other CA.  The effort is =
once per cert expiry, which you as the CA can make as long as you want.
>=20
> That's not it - now you have to provision and configure the server(s)
> to serve the chain.
>=20
>>=20
>> --Richard
>>=20
>>=20
>>=20
>> On Apr 8, 2011, at 9:19 AM, Ben Laurie wrote:
>>=20
>>> On 8 April 2011 13:46, Richard L. Barnes <[email-masked]> wrote:
>>>> To note again: The phrase "self-signed EE cert" does not make =
sense.  =46rom RFC 5280:
>>>> "
>>>> Self-issued certificates are generated to support changes in policy =
or operations.  Self-signed certificates are self-issued certificates =
where the digital signature may be verified by the public key bound into =
the certificate.
>>>> "
>>>> Since a self-signed cert has a cert issued under it (itself), it =
has to be a CA cert.
>>>>=20
>>>> A self-signed cert *without* the CA bits set is therefore =
malformed, and will not pass PKIX validation.
>>>=20
>>> This may be true in theory, but is far from true in practice - in
>>> practice, I can put a self-signed cert on my website and it works =
just
>>> fine (in the sense that it is not considered malformed, just rather
>>> untrustworthy).
>>>=20
>>> So, this is just spec lawyering.
>>>=20
>>>>=20
>>>> Which brings us back to the point that if you want certs that =
really aren't signed by anybody, you might as well be using bare keys, =
or some new data structure that only carries what you're interested in, =
e.g., key parameters but not key usage, names, issuer, etc.
>>>>=20
>>>> --Richard
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> On Apr 8, 2011, at 8:36 AM, Ond=C5=99ej Sur=C3=BD wrote:
>>>>=20
>>>>> My question to the list is if we can avoid specifying which X.509 =
version the client/server has to use and leave it to the client policy.
>>>>>=20
>>>>> Martin's approach seems like a reasonable one, but the question is =
if we can fit it into our draft without advice to break any existing =
standard.
>>>>>=20
>>>>> I know that we are standards group (to reply to PHB later in this =
thread), but we also cannot afford to ignore what's happening in the =
real world otherwise the world is going to ignore us.
>>>>>=20
>>>>> I think that usage of self-signed EE cert is a reasonable use case =
(which may or may not make it to the protocol) and it shouldn't be left =
out.  So please everybody let's think harder how to make things for =
non-protocol-geeks out there simpler, so the fruit of our work is a =
tasty one and not bittersweet.
>>>>>=20
>>>>> O.
>>>>>=20
>>>>> On 4/8/11 4:58 AM, Martin Rex wrote:
>>>>>> Stephen Kent wrote:
>>>>>>>=20
>>>>>>> James Cloos wrote:
>>>>>>>>=20
>>>>>>>> EE certs in the rr is in all of the drafts, was the original =
target, is
>>>>>>>> easy to understand and explain, and I've read more consensus =
for than
>>>>>>>> against on the list.
>>>>>>>>=20
>>>>>>>> Why the sudden backlash against?
>>>>>>>=20
>>>>>>> It's not sudden :-). A self-signed cert is a CA cert, by =
definition (see
>>>>>>> the cites to RFC 5280 in Paul's I-D.
>>>>>>=20
>>>>>> RFC 5280 is about X.509v3 certs _ONLY_.
>>>>>>=20
>>>>>> There is NO problem creating X.509v1 End-Entity certs that are =
self-signed.
>>>>>> And there is no problem using any of these with implementations =
of
>>>>>> SSLv3 and TLSv1.0.
>>>>>>=20
>>>>>> SSLv3 predates IETF PKIX standards, and TLSv1.0 is related to
>>>>>> rfc-2459 rather than rfc-5280 -- but implementations of TLSv1.0
>>>>>> were often shipped before publication of TLSv1.0 (rfc-2246) and
>>>>>> the original PKIX certificate profile (rfc-2459).
>>>>>>=20
>>>>>>=20
>>>>>> For safety, it would be sensible to ALWAYS treat X.509v1 certs as
>>>>>> EndEntity certs (i.e. never accept them as signer of other =
certs).
>>>>>> Our TLS implementation had done this initially, but we had a =
customer
>>>>>> that had obtained server certs issued under a VeriSign X.509v1 CA =
cert
>>>>>> (as late as 2006!), so I had to make our OEM implementation =
tolerate this.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>>=20
>>>>>>> The TLS spec talks in terms of an "end entity's cert" as =
representing
>>>>>>> a a server (or client). =46rom a PKI perspective, the cert that =
represents
>>>>>>> a server or client MUST be an EE cert,
>>>>>>=20
>>>>>> Like an X.509v1 self-signed EE cert.  Works perfectly fine with =
all
>>>>>> TLS implementations that I've met.
>>>>>>=20
>>>>>> Keep in mind that TLS is not limited to X.509v3 certs.
>>>>>>=20
>>>>>>   TLSv1.0:    http://tools.ietf.org/html/rfc2246#section-7.4.2
>>>>>>   TLSv1.1:    http://tools.ietf.org/html/rfc4346#section-7.4.2
>>>>>>=20
>>>>>>    7.4.2. Server certificate
>>>>>>=20
>>>>>>       [...]
>>>>>>=20
>>>>>>    Meaning of this message:
>>>>>>        The certificate type must be appropriate for the selected =
cipher
>>>>>>        suite's key exchange algorithm, and is generally an =
X.509v3
>>>>>>        certificate. It must contain a key which matches the key =
exchange
>>>>>>        method, as follows.
>>>>>>=20
>>>>>>=20
>>>>>>>=20
>>>>>>> an thus cannot be self-signed.
>>>>>>=20
>>>>>> TLSv1.0 and TLSv1.1 have neither a problem with X.509v1 nor
>>>>>> with a self-signed X.509v1 End-Entity cert.
>>>>>>=20
>>>>>>=20
>>>>>>> The fact that many implementations
>>>>>>> violate IETF PKI standards in this regard, is unfortunate, but =
it is not
>>>>>>> a basis for issuing a new IETF standard that codifies this =
behavior.
>>>>>>=20
>>>>>> I know that there are lots of commercial CAs that still have CA =
certs
>>>>>> in every browser that are not valid CA certs according to PKIX / =
RFC 5280.
>>>>>>=20
>>>>>> But having TLSv1.0&TLSv1.1 (i.e. 99% of the installed base)
>>>>>> accept X.509v1 self-signed EE certs is perfectly fine.
>>>>>>=20
>>>>>> X.509v1 is fairly close to a bare key, supported by all TLS =
implementations
>>>>>> in the installed base, as well as tools in the installed base, =
such as
>>>>>> the openssl.exe shell and for transfering keypairs within =
PKCS#12/PFX.
>>>>>=20
>>>>> _______________________________________________
>>>>> dane mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/dane
>>>>=20
>>>> _______________________________________________
>>>> dane mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/dane
>>>>=20
>>=20
>>=20

From [email-masked]  Fri Apr  8 09:40:25 2011
From: Martin Rex <[email-masked]>
To: [email-masked] (Phillip Hallam-Baker)
Date: Fri, 8 Apr 2011 18:42:03 +0200 (MEST)
Cc: [email-masked]
Subject: Re: [dane] elephant use case,
Reply-To: [email-masked]

Phillip Hallam-Baker wrote:
> 
> Could people actually take some time to learn about what the EFF data means
> before engaging in this hyperbole?
> 
> There are not and have never been 600 RA certs. The EFF people do not
> understand what the data means or why the certs are configured the way they
> are. In fact the pressure that we have had from Mozilla and other sources is
> to increase the number of intermediate certs.

RA "registration authorities"
   http://en.wikipedia.org/wiki/Registration_authority

do NOT have certificates themselves.  The organizations that have
the certificate with cert signing capabilities are called CAs.

What EFF likely did was that they counted the distinct CA(!!) certificates
that are valid under the trusted roots certs in Browsers as indicated
under "organization name" in those CA certificates.

I would at least expect that CAs that have trust anchors in browsers
check the organization names of CA-certs they issue, otherwise we
really should get rid of all of them.

> 
> An intermediate certificate does not imply an RA capability.
> Nor does an RA capability require an intermediate certificate.

A CA certificate indicates certificate issuing authority and capability,
there is no doubt about it.

The purpose (and definition) of an RA is, that it can get certs
automatically issued from its associated CA without any further
validation on the part of the CA.

I thought this is what happen in the "Commodogate" case.
The RA credentials were abused to get a number of
certs issued by a Commodo (Sub)CA.

> 
> Contrawise, until a few weeks ago there were Comodo resellers that had RA
> capability but did not have an intermediate root at all. As of today there
> are precisely 0 Comodo resellers that have RA capability.

An RA that gets its own CA certificate, turns into a CA.

-Martin

From [email-masked]  Fri Apr  8 09:47:09 2011
From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 8 Apr 2011 12:48:47 -0400
To: "Richard L. Barnes" <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

Clarification:
You only really have to provision the EE cert in the TLS server.  The =
client can get the TA from DANE.

So the alternatives are:
1. Only EE cert in TLS, CA in DANE
2. EE + CA in TLS, hash of CA in DANE

Only on the second case do you have to provision a "chain" in TLS.  In =
the first case, it's just an EE cert.

On Apr 8, 2011, at 12:18 PM, Richard L. Barnes wrote:

> Ok, but that's just switching out a chain, if the server is already =
using TLS, or provisioning a new chain, which you would have to do =
anyway to use DANE.=20
>=20
> Either way, it's a relatively small one-time cost.
>=20
> --Richard
>=20
>=20
> On Apr 8, 2011, at 12:16 PM, Ben Laurie wrote:
>=20
>> On 8 April 2011 16:28, Richard L. Barnes <[email-masked]> wrote:
>>> To turn the question around, why would we not try to get it right =
this time?  Servers are going to have to do some re-provisioning anyway =
to enable DANE, and it's just not that much extra work to get it right.  =
I just did this myself as an experiment:
>>>=20
>>> To generate a self-signed (CA!) cert:
>>> openssl genrsa -out dane.key 1024
>>> openssl req -new -key dane.key -out dane-ca.csr
>>> openssl x509 -req -days 365 -in dane-ca.csr \
>>>            -signkey dane.key -out dane-ca-cert.pem
>>>=20
>>> To generate an EE cert under that:
>>> # Generate an EE cert under that certificate
>>> openssl req -new -key dane.key -out dane-server.csr
>>> openssl x509 -req -days 365 -in dane-server.csr \
>>>            -CA dane-ca-cert.pem -CAkey dane.key \
>>>            -CAcreateserial -out dane-server-cert.pem
>>>=20
>>> If you want to verify that it worked:
>>> openssl verify -CAfile dane-ca-cert.pem -purpose sslserver =
dane-server-cert.pem
>>>=20
>>> That's it!  You provision the CA cert to DANE, and you use the EE =
cert on the server just like a cert from any other CA.  The effort is =
once per cert expiry, which you as the CA can make as long as you want.
>>=20
>> That's not it - now you have to provision and configure the server(s)
>> to serve the chain.
>>=20
>>>=20
>>> --Richard
>>>=20
>>>=20
>>>=20
>>> On Apr 8, 2011, at 9:19 AM, Ben Laurie wrote:
>>>=20
>>>> On 8 April 2011 13:46, Richard L. Barnes <[email-masked]> wrote:
>>>>> To note again: The phrase "self-signed EE cert" does not make =
sense.  =46rom RFC 5280:
>>>>> "
>>>>> Self-issued certificates are generated to support changes in =
policy or operations.  Self-signed certificates are self-issued =
certificates where the digital signature may be verified by the public =
key bound into the certificate.
>>>>> "
>>>>> Since a self-signed cert has a cert issued under it (itself), it =
has to be a CA cert.
>>>>>=20
>>>>> A self-signed cert *without* the CA bits set is therefore =
malformed, and will not pass PKIX validation.
>>>>=20
>>>> This may be true in theory, but is far from true in practice - in
>>>> practice, I can put a self-signed cert on my website and it works =
just
>>>> fine (in the sense that it is not considered malformed, just rather
>>>> untrustworthy).
>>>>=20
>>>> So, this is just spec lawyering.
>>>>=20
>>>>>=20
>>>>> Which brings us back to the point that if you want certs that =
really aren't signed by anybody, you might as well be using bare keys, =
or some new data structure that only carries what you're interested in, =
e.g., key parameters but not key usage, names, issuer, etc.
>>>>>=20
>>>>> --Richard
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> On Apr 8, 2011, at 8:36 AM, Ond=C5=99ej Sur=C3=BD wrote:
>>>>>=20
>>>>>> My question to the list is if we can avoid specifying which X.509 =
version the client/server has to use and leave it to the client policy.
>>>>>>=20
>>>>>> Martin's approach seems like a reasonable one, but the question =
is if we can fit it into our draft without advice to break any existing =
standard.
>>>>>>=20
>>>>>> I know that we are standards group (to reply to PHB later in this =
thread), but we also cannot afford to ignore what's happening in the =
real world otherwise the world is going to ignore us.
>>>>>>=20
>>>>>> I think that usage of self-signed EE cert is a reasonable use =
case (which may or may not make it to the protocol) and it shouldn't be =
left out.  So please everybody let's think harder how to make things for =
non-protocol-geeks out there simpler, so the fruit of our work is a =
tasty one and not bittersweet.
>>>>>>=20
>>>>>> O.
>>>>>>=20
>>>>>> On 4/8/11 4:58 AM, Martin Rex wrote:
>>>>>>> Stephen Kent wrote:
>>>>>>>>=20
>>>>>>>> James Cloos wrote:
>>>>>>>>>=20
>>>>>>>>> EE certs in the rr is in all of the drafts, was the original =
target, is
>>>>>>>>> easy to understand and explain, and I've read more consensus =
for than
>>>>>>>>> against on the list.
>>>>>>>>>=20
>>>>>>>>> Why the sudden backlash against?
>>>>>>>>=20
>>>>>>>> It's not sudden :-). A self-signed cert is a CA cert, by =
definition (see
>>>>>>>> the cites to RFC 5280 in Paul's I-D.
>>>>>>>=20
>>>>>>> RFC 5280 is about X.509v3 certs _ONLY_.
>>>>>>>=20
>>>>>>> There is NO problem creating X.509v1 End-Entity certs that are =
self-signed.
>>>>>>> And there is no problem using any of these with implementations =
of
>>>>>>> SSLv3 and TLSv1.0.
>>>>>>>=20
>>>>>>> SSLv3 predates IETF PKIX standards, and TLSv1.0 is related to
>>>>>>> rfc-2459 rather than rfc-5280 -- but implementations of TLSv1.0
>>>>>>> were often shipped before publication of TLSv1.0 (rfc-2246) and
>>>>>>> the original PKIX certificate profile (rfc-2459).
>>>>>>>=20
>>>>>>>=20
>>>>>>> For safety, it would be sensible to ALWAYS treat X.509v1 certs =
as
>>>>>>> EndEntity certs (i.e. never accept them as signer of other =
certs).
>>>>>>> Our TLS implementation had done this initially, but we had a =
customer
>>>>>>> that had obtained server certs issued under a VeriSign X.509v1 =
CA cert
>>>>>>> (as late as 2006!), so I had to make our OEM implementation =
tolerate this.
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> The TLS spec talks in terms of an "end entity's cert" as =
representing
>>>>>>>> a a server (or client). =46rom a PKI perspective, the cert that =
represents
>>>>>>>> a server or client MUST be an EE cert,
>>>>>>>=20
>>>>>>> Like an X.509v1 self-signed EE cert.  Works perfectly fine with =
all
>>>>>>> TLS implementations that I've met.
>>>>>>>=20
>>>>>>> Keep in mind that TLS is not limited to X.509v3 certs.
>>>>>>>=20
>>>>>>>  TLSv1.0:    http://tools.ietf.org/html/rfc2246#section-7.4.2
>>>>>>>  TLSv1.1:    http://tools.ietf.org/html/rfc4346#section-7.4.2
>>>>>>>=20
>>>>>>>   7.4.2. Server certificate
>>>>>>>=20
>>>>>>>      [...]
>>>>>>>=20
>>>>>>>   Meaning of this message:
>>>>>>>       The certificate type must be appropriate for the selected =
cipher
>>>>>>>       suite's key exchange algorithm, and is generally an =
X.509v3
>>>>>>>       certificate. It must contain a key which matches the key =
exchange
>>>>>>>       method, as follows.
>>>>>>>=20
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> an thus cannot be self-signed.
>>>>>>>=20
>>>>>>> TLSv1.0 and TLSv1.1 have neither a problem with X.509v1 nor
>>>>>>> with a self-signed X.509v1 End-Entity cert.
>>>>>>>=20
>>>>>>>=20
>>>>>>>> The fact that many implementations
>>>>>>>> violate IETF PKI standards in this regard, is unfortunate, but =
it is not
>>>>>>>> a basis for issuing a new IETF standard that codifies this =
behavior.
>>>>>>>=20
>>>>>>> I know that there are lots of commercial CAs that still have CA =
certs
>>>>>>> in every browser that are not valid CA certs according to PKIX / =
RFC 5280.
>>>>>>>=20
>>>>>>> But having TLSv1.0&TLSv1.1 (i.e. 99% of the installed base)
>>>>>>> accept X.509v1 self-signed EE certs is perfectly fine.
>>>>>>>=20
>>>>>>> X.509v1 is fairly close to a bare key, supported by all TLS =
implementations
>>>>>>> in the installed base, as well as tools in the installed base, =
such as
>>>>>>> the openssl.exe shell and for transfering keypairs within =
PKCS#12/PFX.
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> dane mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/dane
>>>>>=20
>>>>> _______________________________________________
>>>>> dane mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/dane
>>>>>=20
>>>=20
>>>=20
>=20
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

From [email-masked]  Fri Apr  8 09:57:26 2011
From: Martin Rex <[email-masked]>
To: [email-masked] (Richard L. Barnes)
Date: Fri, 8 Apr 2011 18:58:49 +0200 (MEST)
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.
Reply-To: [email-masked]

Richard L. Barnes wrote:
> 
> Clarification:
> You only really have to provision the EE cert in the TLS server.
> The client can get the TA from DANE.
> 
> So the alternatives are:
> 1. Only EE cert in TLS, CA in DANE
> 2. EE + CA in TLS, hash of CA in DANE
> 
> Only on the second case do you have to provision a "chain" in TLS.
> In the first case, it's just an EE cert.

I'm sorry, this assertion is wrong.

I know that there are defective TLS implementations that let you get
away with this, but the procotol spec is clear.

A TLS server must send his _entire_ certificate chain  in the Server
Certificate handshake message.  It may optionally omit the self-signed rootCA
cert at the end of the chain.  But in order to know that _only_ the
self-signed rootCA cert at the end of the chain is missing, a TLS
implementation MUST have that self-signed rootCA cert.

Our TLS implementation will refuse to work with a defective PKI credential
where the End-Entity cert is CA-signed and the certification path is
incomplete.  And as you can see in the EFF SSL observatory -- it would
be extremely useful if other TLS implementations would adopt the same
plausibility checks on PKI credentials.  There currently are
a lot of misconfigured servers on the internet causing all kinds
of weird interop problems by sending incomplete cert chains (chains
that lack more than the self-signed rootCA cert at the end),
and also TLS servers that send garbled cert chains (which is also
prohibited by the TLS spec), because of TLS implementations being
overly sloppy with PKI credentials management and with production
of the TLS Server Certificate handshake message.

-Martin

From [email-masked]  Fri Apr  8 10:01:11 2011
From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 8 Apr 2011 13:02:51 -0400
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

>> Clarification:
>> You only really have to provision the EE cert in the TLS server.
>> The client can get the TA from DANE.
>>=20
>> So the alternatives are:
>> 1. Only EE cert in TLS, CA in DANE
>> 2. EE + CA in TLS, hash of CA in DANE
>>=20
>> Only on the second case do you have to provision a "chain" in TLS.
>> In the first case, it's just an EE cert.
>=20
> I'm sorry, this assertion is wrong.
>=20
> I know that there are defective TLS implementations that let you get
> away with this, but the procotol spec is clear.
>=20
> A TLS server must send his _entire_ certificate chain  in the Server
> Certificate handshake message.  It may optionally omit the self-signed =
rootCA
> cert at the end of the chain.  But in order to know that _only_ the
> self-signed rootCA cert at the end of the chain is missing, a TLS
> implementation MUST have that self-signed rootCA cert.

... and it gets that cert from DANE.  The CA that's provisioned in DANE =
in this case *is* the root CA.  It's a two-hop chain (root CA, EE), so =
you're saying exactly the same thing that I said: That the server can =
send either the chain (CA+EE) or the EE cert alone. =20

--Richard=

From [email-masked]  Fri Apr  8 10:14:18 2011
From: Martin Rex <[email-masked]>
To: [email-masked] (Richard L. Barnes)
Date: Fri, 8 Apr 2011 19:15:44 +0200 (MEST)
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.
Reply-To: [email-masked]

Richard L. Barnes wrote:
> 
> >> Clarification:
> >> You only really have to provision the EE cert in the TLS server.
> >> The client can get the TA from DANE.
> >> 
> >> So the alternatives are:
> >> 1. Only EE cert in TLS, CA in DANE
> >> 2. EE + CA in TLS, hash of CA in DANE
> >> 
> >> Only on the second case do you have to provision a "chain" in TLS.
> >> In the first case, it's just an EE cert.
> > 
> > I'm sorry, this assertion is wrong.
> > 
> > I know that there are defective TLS implementations that let you get
> > away with this, but the procotol spec is clear.
> > 
> > A TLS server must send his _entire_ certificate chain  in the Server
> > Certificate handshake message.  It may optionally omit the self-signed rootCA
> > cert at the end of the chain.  But in order to know that _only_ the
> > self-signed rootCA cert at the end of the chain is missing, a TLS
> > implementation MUST have that self-signed rootCA cert.
> 
> ... and it gets that cert from DANE.  The CA that's provisioned in DANE in this case *is* the root CA.  It's a two-hop chain (root CA, EE), so you're saying exactly the same thing that I said: That the server can send either the chain (CA+EE) or the EE cert alone.  

You're missing the point.

Due to its complete lack of a PKI credentials concept, the configuration of
the TLS server with OpenSSL is quite error prone.  And due to the
lack of plausibility checks in the OpenSSL TLS implementation, all
configuration errors of the admin will result in TLS protocol violations
that the TLS communication peer has to deal with (which it often can not),
rather than a local error message to the admin that the configuration
is defective or incomplete and will have to be fixed before it can
be used.

Most, if not all, commercial CAs are using intermediate CA certs these
days when issuing TLS server certificates, so that a correct TLS server
configuration of an OpenSSL-based Web-Server (like Apache) requires
the use of a seperate "SSLCertificateChainFile" (I assume that is the
parameter) in addition to the "SSLCertificateFile".

And if there is more than one intermediate CA cert involved, all of the
intermediate CA certs must be added to SSLCertificateChainFile.
Unfortunately, OpenSSL neither sorts nor weeds out the contents passed
through the Apache SSLCertificateChainFile parameter when composing
the Server Certificate handshake message, which can, and often does
result in TLS protocol violations and interop problems

-Martin

From [email-masked]  Fri Apr  8 10:28:03 2011
From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 8 Apr 2011 13:29:45 -0400
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

Martin,

We're not talking about commercial CAs.  We're talking about when a TLS =
server operator wants to act as his own TA.  So I don't see how your =
last to paragraphs relate to anything.

As for the first paragraph, it's perfectly feasible for admin tools to =
verify the correctness of a self-generated cert chain; see the "openssl =
verify" step in my earlier email.

--Richard

On Apr 8, 2011, at 1:15 PM, Martin Rex wrote:

> Richard L. Barnes wrote:
>>=20
>>>> Clarification:
>>>> You only really have to provision the EE cert in the TLS server.
>>>> The client can get the TA from DANE.
>>>>=20
>>>> So the alternatives are:
>>>> 1. Only EE cert in TLS, CA in DANE
>>>> 2. EE + CA in TLS, hash of CA in DANE
>>>>=20
>>>> Only on the second case do you have to provision a "chain" in TLS.
>>>> In the first case, it's just an EE cert.
>>>=20
>>> I'm sorry, this assertion is wrong.
>>>=20
>>> I know that there are defective TLS implementations that let you get
>>> away with this, but the procotol spec is clear.
>>>=20
>>> A TLS server must send his _entire_ certificate chain  in the Server
>>> Certificate handshake message.  It may optionally omit the =
self-signed rootCA
>>> cert at the end of the chain.  But in order to know that _only_ the
>>> self-signed rootCA cert at the end of the chain is missing, a TLS
>>> implementation MUST have that self-signed rootCA cert.
>>=20
>> ... and it gets that cert from DANE.  The CA that's provisioned in =
DANE in this case *is* the root CA.  It's a two-hop chain (root CA, EE), =
so you're saying exactly the same thing that I said: That the server can =
send either the chain (CA+EE) or the EE cert alone. =20
>=20
>=20
> You're missing the point.
>=20
> Due to its complete lack of a PKI credentials concept, the =
configuration of
> the TLS server with OpenSSL is quite error prone.  And due to the
> lack of plausibility checks in the OpenSSL TLS implementation, all
> configuration errors of the admin will result in TLS protocol =
violations
> that the TLS communication peer has to deal with (which it often can =
not),
> rather than a local error message to the admin that the configuration
> is defective or incomplete and will have to be fixed before it can
> be used.
>=20
> Most, if not all, commercial CAs are using intermediate CA certs these
> days when issuing TLS server certificates, so that a correct TLS =
server
> configuration of an OpenSSL-based Web-Server (like Apache) requires
> the use of a seperate "SSLCertificateChainFile" (I assume that is the
> parameter) in addition to the "SSLCertificateFile".
>=20
> And if there is more than one intermediate CA cert involved, all of =
the
> intermediate CA certs must be added to SSLCertificateChainFile.
> Unfortunately, OpenSSL neither sorts nor weeds out the contents passed
> through the Apache SSLCertificateChainFile parameter when composing
> the Server Certificate handshake message, which can, and often does
> result in TLS protocol violations and interop problems
>=20
>=20
> -Martin

From [email-masked]  Fri Apr  8 10:35:02 2011
Date: Fri, 8 Apr 2011 10:36:44 -0700
From: Kirk Hall <[email-masked]>
To: [email-masked]
Subject: [dane] Use Cases Document
Reply-To: [email-masked]

--20cf30549f456faa7704a06babd3
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

I=92ve been reading the DANE discussion for many weeks, but this is my firs=
t
posting.  My background is with CAs, first as head of authentication
services at GeoTrust and now as COO with AffirmTrust.

The basic concept of DANE =96 binding a public key (either self-signed or f=
rom
a CA) to a domain at the DNS operator level =96 is intriguing and could be =
a
useful function, particularly for machine-to-machine communications.  But I
have some concerns.

I recognize that this is not the place to work out the details concerning
how this function would be implemented, including UI issues, but I notice
from the previous postings that a major DANE goal for some people is to
allow domain owners to authenticate their own servers through self-signed
certs, specifically without using a CA.  In fact, the Abstract for the DANE
proposal states in part =93Instead of trusting a certification authority to
have made this association correctly, the user might instead trust the
authoritative DNS server for the domain name to make that association.=94  =
So
the question of =93trust=94 and how DANE would be used in a practical way h=
as
already been introduced in the Abstract itself.  In addition, some postings
have also explicitly proposed that under DANE, a self-signed cert associate=
d
with the domain at the DNS level should be treated as the equivalent of a
Domain Validated (DV) cert for the same domain.

I=92m concerned that there is a misconception of what CAs do before issuing=
 DV
certificates.  In fact, CAs employ significant anti-fraud safeguards before
issuing DV certs, and it=92s not clear to me whether or not these safeguard=
s
would also apply to self-signed certs under

DANE.ANTI-FRAUD SAFEGUARDS USED BY CAs IN ISSUING DV CERTS

Here are some of the anti-fraud safeguards used by CAs when issuing DV cert=
s
to a domain.

(1) CAs review DV cert requests for =93high risk=94 organization and domain
names that are most commonly targeted in phishing and other fraudulent
schemes, and reject those cert requests.  These lists include (a) internal
databases maintained by the CA that include previously revoked certificates
as well as requests that were previously rejected because of suspected
phishing or other fraudulent usage, and (b) potential phishing targets as
published by the Anti-Phishing Work Group (APWG) and similar groups.

In addition, CAs also review all DV certificate requests against =93denied
lists=94, including government denied lists, lists of prohibited persons, o=
r
other lists that prohibit doing business with an organization or person
under the laws of the country of the CA=92s jurisdiction of operation.

This is not an idle or hypothetical threat to consumers.  For example, *ALL=
*
of the following domain names are available *TODAY* for anyone to register:

your-account-bankofamerica.com

my-email-live.com

google-accounts.com

my-paypal-account.com

After checking these proposed domain names against their high risk and
denied lists, a good CA would not issue a DV cert for the domains, even if
the domain owners prove domain ownership and control.

Does DANE contemplate that the DNS operators would also reject domain
filings based on high risk/blacklist/spam lists, APWG lists, etc.?  Do the
DNS operators want to take that on?

(2) CAs also employ other anti-fraud algorithms of their own against bad DV
cert applications, and are constantly improving the algorithms.  In
addition, many CAs offer warranties and carry E&O/professional malpractice
insurance to cover potential losses from DV cert authentication mistakes =
=96
and these requirements will likely become mandatory for all CAs in the new
Baseline Requirements that the CA-Browser Forum is drafting to apply to all
certificates.

Do you contemplate that DNS operators would do anything similar for
self-signed certs?

(3) DV certs have a clear chain of liability back to the issuing CA. The CA=
s
today do a pretty good job in preventing high risk similar-named domains,
like =93paypall.com=94,  from getting certs for fraud and phishing purposes=
.

Under DANE, if a self-signed certificate issued in the name of =93paypall.c=
om=94
is accepted by a DNS operator and is used in phishing attacks, who would be
responsible for any resulting consumer spoofing - the browsers, the DNS
operators, and/or the registrar/registry that registered the domain name?

(4) CAs must comply with all the security and vetting infrastructure that
Mozilla, Microsoft, Opera and the CA-Browser Forum have imposed over the
years to minimize mistakes and misuse of certificates (e.g., annual WebTrus=
t
audits, insurance minimums, liability and warranty provisions, naming rules=
,
etc.). These processes have generally helped CAs do a good job in regulatin=
g
themselves to prevent rogue certificate requests.

Will similar requirements be imposed on the DNS operators before they can
accept self-signed DANE certificates?

(5) Bad certs can be revoked, and the industry is working very hard right
now on improving the revocation process.

If there is a =93bad=94 self-signed cert associated with a domain by a DNS
operator and/or a DNS operator receives a report of fraud or phishing
associated with a domain, will DANE have a way to remove, revoke, or
otherwise flag the cert as =93bad=94?

Again, I think these questions are relevant to the =93trust=94 issues alrea=
dy
cited in the Abstract for DANE, and will also be very helpful in
establishing relevant use cases for the DANE specifications.

Thanks for your consideration.

--20cf30549f456faa7704a06babd3
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div>I=92ve been reading the DANE discussion for many weeks, but this is my=
 first posting.=A0 My background is with CAs, first as head of authenticati=
on services at GeoTrust and now as COO with AffirmTrust.<br>=A0<br>The basi=
c concept of DANE =96 binding a public key (either self-signed or from a CA=
) to a domain at the DNS operator level =96 is intriguing and could be a us=
eful function, particularly for machine-to-machine communications.=A0 But I=
 have some concerns.</div>

<div><br>I recognize that this is not the place to work out the details con=
cerning how this function would be implemented, including UI issues, but I =
notice from the previous postings that a major DANE goal for some people is=
 to allow domain owners to authenticate their own servers through self-sign=
ed certs, specifically without using a CA.=A0 In fact, the Abstract for the=
 DANE proposal states in part =93Instead of trusting a certification author=
ity to have made this association correctly, the user might instead trust t=
he authoritative DNS server for the domain name to make that association.=
=94=A0 So the question of =93trust=94 and how DANE would be used in a pract=
ical way has already been introduced in the Abstract itself.=A0 In addition=
, some postings have also explicitly proposed that under DANE, a self-signe=
d cert associated with the domain at the DNS level should be treated as the=
 equivalent of a Domain Validated (DV) cert for the same domain.</div>

<div>=A0</div>
<div>I=92m concerned that there is a misconception of what CAs do before is=
suing DV certificates.=A0 In fact, CAs employ significant anti-fraud safegu=
ards before issuing DV certs, and it=92s not clear to me whether or not the=
se safeguards would also apply to self-signed certs under </div>

<div>=A0</div>
<div>DANE.ANTI-FRAUD SAFEGUARDS USED BY CAs IN ISSUING DV CERTS</div>
<div>=A0</div>
<div>Here are some of the anti-fraud safeguards used by CAs when issuing DV=
 certs to a domain.=A0 </div>
<div>=A0</div>
<div>(1) CAs review DV cert requests for =93high risk=94 organization and d=
omain names that are most commonly targeted in phishing and other fraudulen=
t schemes, and reject those cert requests.=A0 These lists include (a) inter=
nal databases maintained by the CA that include previously revoked certific=
ates as well as requests that were previously rejected because of suspected=
 phishing or other fraudulent usage, and (b) potential phishing targets as =
published by the Anti-Phishing Work Group (APWG) and similar groups.=A0 <br=
>
=A0<br>In addition, CAs also review all DV certificate requests against =93=
denied lists=94, including government denied lists, lists of prohibited per=
sons, or other lists that prohibit doing business with an organization or p=
erson under the laws of the country of the CA=92s jurisdiction of operation=
.<br>
=A0<br>This is not an idle or hypothetical threat to consumers.=A0 For exam=
ple, *ALL* of the following domain names are available *TODAY* for anyone t=
o register:<br>=A0<br><a href=3D"http://your-account-bankofamerica.com">you=
r-account-bankofamerica.com</a><br>
=A0<br><a href=3D"http://my-email-live.com">my-email-live.com</a><br>=A0<br=
><a href=3D"http://google-accounts.com">google-accounts.com</a><br>=A0<br><=
a href=3D"http://my-paypal-account.com">my-paypal-account.com</a><br>=A0<br=
>After checking these proposed domain names against their high risk and den=
ied lists, a good CA would not issue a DV cert for the domains, even if the=
 domain owners prove domain ownership and control.=A0 <br>
=A0<br>Does DANE contemplate that the DNS operators would also reject domai=
n filings based on high risk/blacklist/spam lists, APWG lists, etc.?=A0 Do =
the DNS operators want to take that on?<br>=A0<br>(2) CAs also employ other=
 anti-fraud algorithms of their own against bad DV cert applications, and a=
re constantly improving the algorithms.=A0 In addition, many CAs offer warr=
anties and carry E&amp;O/professional malpractice insurance to cover potent=
ial losses from DV cert authentication mistakes =96 and these requirements =
will likely become mandatory for all CAs in the new Baseline Requirements t=
hat the CA-Browser Forum is drafting to apply to all certificates.=A0 <br>
=A0<br>Do you contemplate that DNS operators would do anything similar for =
self-signed certs?=A0 <br>=A0<br>(3) DV certs have a clear chain of liabili=
ty back to the issuing CA. The CAs today do a pretty good job in preventing=
 high risk similar-named domains, like =93<a href=3D"http://paypall.com">pa=
ypall.com</a>=94,=A0 from getting certs for fraud and phishing purposes.<br=
>
=A0<br>Under DANE, if a self-signed certificate issued in the name of =93<a=
 href=3D"http://paypall.com">paypall.com</a>=94 is accepted by a DNS operat=
or and is used in phishing attacks, who would be responsible for any result=
ing consumer spoofing - the browsers, the DNS operators, and/or the registr=
ar/registry that registered the domain name?<br>
=A0<br>(4) CAs must comply with all the security and vetting infrastructure=
 that Mozilla, Microsoft, Opera and the CA-Browser Forum have imposed over =
the years to minimize mistakes and misuse of certificates (e.g., annual Web=
Trust audits, insurance minimums, liability and warranty provisions, naming=
 rules, etc.). These processes have generally helped CAs do a good job in r=
egulating themselves to prevent rogue certificate requests. <br>
=A0<br>Will similar requirements be imposed on the DNS operators before the=
y can accept self-signed DANE certificates? <br>=A0<br>(5) Bad certs can be=
 revoked, and the industry is working very hard right now on improving the =
revocation process.=A0 <br>
=A0<br>If there is a =93bad=94 self-signed cert associated with a domain by=
 a DNS operator and/or a DNS operator receives a report of fraud or phishin=
g associated with a domain, will DANE have a way to remove, revoke, or othe=
rwise flag the cert as =93bad=94?<br>
=A0<br>Again, I think these questions are relevant to the =93trust=94 issue=
s already cited in the Abstract for DANE, and will also be very helpful in =
establishing relevant use cases for the DANE specifications.<br>=A0<br>Than=
ks for your consideration.</div>

--20cf30549f456faa7704a06babd3--

From [email-masked]  Fri Apr  8 10:45:42 2011
From: Martin Rex <[email-masked]>
To: [email-masked] (Richard L. Barnes)
Date: Fri, 8 Apr 2011 19:47:22 +0200 (MEST)
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.
Reply-To: [email-masked]

Richard L. Barnes wrote:
> 
> We're not talking about commercial CAs.  We're talking about when
> a TLS server operator wants to act as his own TA.  So I don't see
> how your last to paragraphs relate to anything.

The TLS server implementation does not know or care whether your
CA cert is from a commercial CA or a do-it-yourself CA.

A TLS Server configuration with a CA-signed server cert is harder to create
and harder to configure that a simple self-signed EE server cert.

> 
> As for the first paragraph, it's perfectly feasible for admin tools
> to verify the correctness of a self-generated cert chain; see the
> "openssl verify" step in my earlier email.

Looks like a very unnecessary usability problem to me.

The code for checking a cert chain already exists in OpenSSL, and
it is used whenever a peer's cert chain is received.  There is really
no excuse for the TLS server side implementation to not check its
own cert chain for _obvious_ inconsistencies, such as missing
intermediate CA certs and garbled cert order, at some point before
composing and sending a Server Certificate TLS handshake message.

A server that serves more than a single connect could perform
this check once on the initial call where the server cert and
cert chain certificates are provided.

-Martin

From [email-masked]  Fri Apr  8 10:49:59 2011
From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 8 Apr 2011 13:51:40 -0400
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

> The TLS server implementation does not know or care whether your
> CA cert is from a commercial CA or a do-it-yourself CA.

Agreed.

> A TLS Server configuration with a CA-signed server cert is harder to =
create
> and harder to configure that a simple self-signed EE server cert.

Disagree.  If the EE cert is signed by a trusted CA cert (acquired from =
DANE), then there is no need to configure the TLS server with anything =
more than the EE cert.  The client can retrieve the CA cert from the DNS =
with DANE.

--Richard=

From [email-masked]  Fri Apr  8 11:04:59 2011
Date: Fri, 08 Apr 2011 19:06:36 +0100
From: Stephen Farrell <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

A couple of clarifications...

On 08/04/11 17:04, Phillip Hallam-Baker wrote:
> As Stephen Farrell points out, Steve Kent is wrong on this point. 

Wrong. I've said nothing either way about anything Steve has
said here on this topic.

I disagreed with Richard's interpretation of 5280 and with his
claim that that means that this group can't use EE self-signed
certs (if that's what he was saying).

> And he
> was the editor of the spec. 

One of them. Dave Cooper really did most of the work, and 5280
is just the latest rfc going back to 2459 so there are lots of
folks with just as much or more heritage. The point is not who
said something, but what the rfc says.

S.

From [email-masked]  Fri Apr  8 11:26:15 2011
Date: Fri, 8 Apr 2011 18:27:59 +0000
From: Phillip Hallam-Baker <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

--bcaec5016413b3d1d904a06c625a
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Apr 8, 2011 at 6:06 PM, Stephen Farrell
<[email-masked]>wrote:

>
> A couple of clarifications...
>
> On 08/04/11 17:04, Phillip Hallam-Baker wrote:
> > As Stephen Farrell points out, Steve Kent is wrong on this point.
>
> Wrong. I've said nothing either way about anything Steve has
> said here on this topic.
>
> I disagreed with Richard's interpretation of 5280 and with his
> claim that that means that this group can't use EE self-signed
> certs (if that's what he was saying).

Oh, in that case appols to Steve K. The thread has metastacized to the point
where attribution is confused.

> And he
> > was the editor of the spec.
>
> One of them. Dave Cooper really did most of the work, and 5280
> is just the latest rfc going back to 2459 so there are lots of
> folks with just as much or more heritage. The point is not who
> said something, but what the rfc says.
>

Well yes and no. What really matters is the running code and how long the
discussion goes on for. We all know that DANE code is going to accept self
signed EE certs regardless of what the WG says on the matter.

Is there any reason why the DANE spec needs to say anything more than 'go
read the PKIX and TLS specs'?

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

--bcaec5016413b3d1d904a06c625a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Fri, Apr 8, 2011 at 6:06 PM, Stephen =
Farrell <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">=
[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex;">
<br>
A couple of clarifications...<br>
<div class=3D"im"><br>
On 08/04/11 17:04, Phillip Hallam-Baker wrote:<br>
&gt; As Stephen Farrell points out, Steve Kent is wrong on this point.<br>
<br>
</div>Wrong. I&#39;ve said nothing either way about anything Steve has<br>
said here on this topic.<br>
<br>
I disagreed with Richard&#39;s interpretation of 5280 and with his<br>
claim that that means that this group can&#39;t use EE self-signed<br>
certs (if that&#39;s what he was saying).</blockquote><div><br></div><div>O=
h, in that case appols to Steve K. The thread has metastacized to the point=
 where attribution is confused.</div><div><br></div><div><br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex;">
<div class=3D"im">
&gt; And he<br>
&gt; was the editor of the spec.<br>
<br>
</div>One of them. Dave Cooper really did most of the work, and 5280<br>
is just the latest rfc going back to 2459 so there are lots of<br>
folks with just as much or more heritage. The point is not who<br>
said something, but what the rfc says.<font class=3D"Apple-style-span" colo=
r=3D"#888888"><br></font></blockquote></div><br clear=3D"all">Well yes and =
no. What really matters is the running code and how long the discussion goe=
s on for. We all know that DANE code is going to accept self signed EE cert=
s regardless of what the WG says on the matter.<div>
<br></div><div>Is there any reason why the DANE spec needs to say anything =
more than &#39;go read the PKIX and TLS specs&#39;?</div><div><br>-- <br>We=
bsite: <a href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br>
<br>
</div>

--bcaec5016413b3d1d904a06c625a--

From [email-masked]  Fri Apr  8 11:27:11 2011
From: Matt McCutchen <[email-masked]>
To: [email-masked]
Date: Fri, 08 Apr 2011 14:28:53 -0400
Cc: [email-masked]
Subject: [dane] CA DV checks other than domain control

On Fri, 2011-04-08 at 10:36 -0700, Kirk Hall wrote:
> I=E2=80=99m concerned that there is a misconception of what CAs do befo=
re
> issuing DV certificates.  In fact, CAs employ significant anti-fraud
> safeguards before issuing DV certs, and it=E2=80=99s not clear to me wh=
ether
> or not these safeguards would also apply to self-signed certs under=20
> DANE.

Thank you so much for providing this list!  This is indeed something we
need to discuss.  In previous discussion in mozilla.dev.security.policy,
Eddy Nigg stated the existence of such measures but declined to work
through them with me in detail
(https://groups.google.com/group/mozilla.dev.security.policy/browse_threa=
d/thread/c52b6de458ad54be/d21853d40b17b870).  I would urge anyone who kno=
ws of more such measures to add them here.

I'll respond to the actual points later.

--=20
Matt

From [email-masked]  Fri Apr  8 11:28:35 2011
Date: Fri, 8 Apr 2011 18:30:19 +0000
From: Phillip Hallam-Baker <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

--bcaec50166a509d91b04a06c6b20
Content-Type: text/plain; charset=ISO-8859-1

Could we start a new thread for the EE certs thing?

It is not a use case.

EG: Alice the administrator wants to configure servers with minimal hassle

It is not a requirement

EG: Allow use of existing certificates installed and used with TLS servers

We have even determined that there isn't even a constraint here!

This is at best a technical detail for a proposal. Since we haven't got past
use cases yet, it would be premature in any case.

--bcaec50166a509d91b04a06c6b20
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Could we start a new thread for the EE certs thing?
<div><br></div><div>It is not a use case.</div><div><br></div><div>EG: Alic=
e the administrator wants to configure servers with minimal hassle</div><di=
v><br></div><div><br></div><div>It is not a requirement</div><div><br>
</div><div>EG: Allow use of existing certificates installed and used with T=
LS servers</div><div><br></div><div><br></div><div>We have even determined =
that there isn&#39;t even a constraint here!</div><div><br></div><div>This =
is at best a technical detail for a proposal. Since we haven&#39;t got past=
 use cases yet, it would be premature in any case.</div>
<div><br></div>

--bcaec50166a509d91b04a06c6b20--

From [email-masked]  Fri Apr  8 11:58:03 2011
From: James Cloos <[email-masked]>
To: [email-masked]
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC
Copyright: Copyright 2011 James Cloos
OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
Date: Fri, 08 Apr 2011 14:14:56 -0400
Lines: 17
Subject: Re: [dane] [keyassure] Use cases document.

>>>>> "RLB" == Richard L Barnes <[email-masked]> writes:

RLB> ... and it gets that cert from DANE.  The CA that's provisioned in
RLB> DANE in this case *is* the root CA.  It's a two-hop chain (root CA,
RLB> EE), so you're saying exactly the same thing that I said: That the
RLB> server can send either the chain (CA+EE) or the EE cert alone.

The existing discussions here went in the direction that the dane trust
path verifies *only* if the cert specified in the RR exactly matches one
the of certs in the chain provided by the d?tls server.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

From [email-masked]  Fri Apr  8 12:02:06 2011
From: Paul Hoffman <[email-masked]>
Date: Fri, 8 Apr 2011 12:03:49 -0700
To: James Cloos <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

On Apr 8, 2011, at 11:14 AM, James Cloos wrote:

>>>>>> "RLB" =3D=3D Richard L Barnes <[email-masked]> writes:
>=20
> RLB> ... and it gets that cert from DANE.  The CA that's provisioned =
in
> RLB> DANE in this case *is* the root CA.  It's a two-hop chain (root =
CA,
> RLB> EE), so you're saying exactly the same thing that I said: That =
the
> RLB> server can send either the chain (CA+EE) or the EE cert alone.
>=20
> The existing discussions here went in the direction that the dane =
trust
> path verifies *only* if the cert specified in the RR exactly matches =
one
> the of certs in the chain provided by the d?tls server.

That is not true at all. For months, we have talked about allowing the =
cert from the TLSA record represent a CA that would validate the EE cert =
from TLS. Please see the last few revs of the draft, for example.

--Paul Hoffman

From [email-masked]  Fri Apr  8 13:01:57 2011
Date: Fri, 8 Apr 2011 16:03:39 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

On Fri, 8 Apr 2011, Richard L. Barnes wrote:

> > A TLS Server configuration with a CA-signed server cert is harder to create
> > and harder to configure that a simple self-signed EE server cert.
> 
> Disagree.  If the EE cert is signed by a trusted CA cert (acquired from DANE), then there is no need to configure the TLS server with anything more than the EE cert.  The client can retrieve the CA cert from the DNS with DANE.

Unfortunately, we would be going through a migration phase, where you have to support
both dane and non-dane clients. So I do forsee the need to have the information in
dane and also provide it in the TLS Server Certificate message.

Paul

From [email-masked]  Fri Apr  8 13:17:06 2011
From: Henry Story <[email-masked]>
Date: Fri, 8 Apr 2011 22:18:36 +0200
To: "Richard L. Barnes" <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

On 8 Apr 2011, at 18:18, Richard L. Barnes wrote:

> Ok, but that's just switching out a chain, if the server is already =
using TLS, or provisioning a new chain, which you would have to do =
anyway to use DANE.=20
>=20
> Either way, it's a relatively small one-time cost.

I think it is worth remembering here that most TLS servers out there are =
running self signed certificts according to the EFF Observatory. (If I =
remember correctly, there are three times more such servers then there =
are TLS servers with functionaing CA certs).=20

One can imagine a DNSsec based dns provider offering the following =
service to users switching over
 1. test the TLS ports and fetch the certs=20
 2. if those are self signed ask the admin if these are indeed the =
certificates legally present on his site
 3. Add those to DNSsec using DANE

This could not be done if one is forced to use a chain, meaning that =
bootstrapping DANE will not be as easy. Imagine the difference in =
browser support if you can tell them that in a year, 10 million sites =
will be DANE enabled.

I see that having a chain is also useful, but those seem useful for =
companies with a relation with a CA.

>=20
> --Richard
>=20
>=20
> On Apr 8, 2011, at 12:16 PM, Ben Laurie wrote:
>=20
>> On 8 April 2011 16:28, Richard L. Barnes <[email-masked]> wrote:
>>> To turn the question around, why would we not try to get it right =
this time?  Servers are going to have to do some re-provisioning anyway =
to enable DANE, and it's just not that much extra work to get it right.  =
I just did this myself as an experiment:
>>>=20
>>> To generate a self-signed (CA!) cert:
>>> openssl genrsa -out dane.key 1024
>>> openssl req -new -key dane.key -out dane-ca.csr
>>> openssl x509 -req -days 365 -in dane-ca.csr \
>>>            -signkey dane.key -out dane-ca-cert.pem
>>>=20
>>> To generate an EE cert under that:
>>> # Generate an EE cert under that certificate
>>> openssl req -new -key dane.key -out dane-server.csr
>>> openssl x509 -req -days 365 -in dane-server.csr \
>>>            -CA dane-ca-cert.pem -CAkey dane.key \
>>>            -CAcreateserial -out dane-server-cert.pem
>>>=20
>>> If you want to verify that it worked:
>>> openssl verify -CAfile dane-ca-cert.pem -purpose sslserver =
dane-server-cert.pem
>>>=20
>>> That's it!  You provision the CA cert to DANE, and you use the EE =
cert on the server just like a cert from any other CA.  The effort is =
once per cert expiry, which you as the CA can make as long as you want.
>>=20
>> That's not it - now you have to provision and configure the server(s)
>> to serve the chain.
>>=20
>>>=20
>>> --Richard
>>>=20
>>>=20
>>>=20
>>> On Apr 8, 2011, at 9:19 AM, Ben Laurie wrote:
>>>=20
>>>> On 8 April 2011 13:46, Richard L. Barnes <[email-masked]> wrote:
>>>>> To note again: The phrase "self-signed EE cert" does not make =
sense.  =46rom RFC 5280:
>>>>> "
>>>>> Self-issued certificates are generated to support changes in =
policy or operations.  Self-signed certificates are self-issued =
certificates where the digital signature may be verified by the public =
key bound into the certificate.
>>>>> "
>>>>> Since a self-signed cert has a cert issued under it (itself), it =
has to be a CA cert.
>>>>>=20
>>>>> A self-signed cert *without* the CA bits set is therefore =
malformed, and will not pass PKIX validation.
>>>>=20
>>>> This may be true in theory, but is far from true in practice - in
>>>> practice, I can put a self-signed cert on my website and it works =
just
>>>> fine (in the sense that it is not considered malformed, just rather
>>>> untrustworthy).
>>>>=20
>>>> So, this is just spec lawyering.
>>>>=20
>>>>>=20
>>>>> Which brings us back to the point that if you want certs that =
really aren't signed by anybody, you might as well be using bare keys, =
or some new data structure that only carries what you're interested in, =
e.g., key parameters but not key usage, names, issuer, etc.
>>>>>=20
>>>>> --Richard
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> On Apr 8, 2011, at 8:36 AM, Ond=C5=99ej Sur=C3=BD wrote:
>>>>>=20
>>>>>> My question to the list is if we can avoid specifying which X.509 =
version the client/server has to use and leave it to the client policy.
>>>>>>=20
>>>>>> Martin's approach seems like a reasonable one, but the question =
is if we can fit it into our draft without advice to break any existing =
standard.
>>>>>>=20
>>>>>> I know that we are standards group (to reply to PHB later in this =
thread), but we also cannot afford to ignore what's happening in the =
real world otherwise the world is going to ignore us.
>>>>>>=20
>>>>>> I think that usage of self-signed EE cert is a reasonable use =
case (which may or may not make it to the protocol) and it shouldn't be =
left out.  So please everybody let's think harder how to make things for =
non-protocol-geeks out there simpler, so the fruit of our work is a =
tasty one and not bittersweet.
>>>>>>=20
>>>>>> O.
>>>>>>=20
>>>>>> On 4/8/11 4:58 AM, Martin Rex wrote:
>>>>>>> Stephen Kent wrote:
>>>>>>>>=20
>>>>>>>> James Cloos wrote:
>>>>>>>>>=20
>>>>>>>>> EE certs in the rr is in all of the drafts, was the original =
target, is
>>>>>>>>> easy to understand and explain, and I've read more consensus =
for than
>>>>>>>>> against on the list.
>>>>>>>>>=20
>>>>>>>>> Why the sudden backlash against?
>>>>>>>>=20
>>>>>>>> It's not sudden :-). A self-signed cert is a CA cert, by =
definition (see
>>>>>>>> the cites to RFC 5280 in Paul's I-D.
>>>>>>>=20
>>>>>>> RFC 5280 is about X.509v3 certs _ONLY_.
>>>>>>>=20
>>>>>>> There is NO problem creating X.509v1 End-Entity certs that are =
self-signed.
>>>>>>> And there is no problem using any of these with implementations =
of
>>>>>>> SSLv3 and TLSv1.0.
>>>>>>>=20
>>>>>>> SSLv3 predates IETF PKIX standards, and TLSv1.0 is related to
>>>>>>> rfc-2459 rather than rfc-5280 -- but implementations of TLSv1.0
>>>>>>> were often shipped before publication of TLSv1.0 (rfc-2246) and
>>>>>>> the original PKIX certificate profile (rfc-2459).
>>>>>>>=20
>>>>>>>=20
>>>>>>> For safety, it would be sensible to ALWAYS treat X.509v1 certs =
as
>>>>>>> EndEntity certs (i.e. never accept them as signer of other =
certs).
>>>>>>> Our TLS implementation had done this initially, but we had a =
customer
>>>>>>> that had obtained server certs issued under a VeriSign X.509v1 =
CA cert
>>>>>>> (as late as 2006!), so I had to make our OEM implementation =
tolerate this.
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> The TLS spec talks in terms of an "end entity's cert" as =
representing
>>>>>>>> a a server (or client). =46rom a PKI perspective, the cert that =
represents
>>>>>>>> a server or client MUST be an EE cert,
>>>>>>>=20
>>>>>>> Like an X.509v1 self-signed EE cert.  Works perfectly fine with =
all
>>>>>>> TLS implementations that I've met.
>>>>>>>=20
>>>>>>> Keep in mind that TLS is not limited to X.509v3 certs.
>>>>>>>=20
>>>>>>>  TLSv1.0:    http://tools.ietf.org/html/rfc2246#section-7.4.2
>>>>>>>  TLSv1.1:    http://tools.ietf.org/html/rfc4346#section-7.4.2
>>>>>>>=20
>>>>>>>   7.4.2. Server certificate
>>>>>>>=20
>>>>>>>      [...]
>>>>>>>=20
>>>>>>>   Meaning of this message:
>>>>>>>       The certificate type must be appropriate for the selected =
cipher
>>>>>>>       suite's key exchange algorithm, and is generally an =
X.509v3
>>>>>>>       certificate. It must contain a key which matches the key =
exchange
>>>>>>>       method, as follows.
>>>>>>>=20
>>>>>>>=20
>>>>>>>>=20
>>>>>>>> an thus cannot be self-signed.
>>>>>>>=20
>>>>>>> TLSv1.0 and TLSv1.1 have neither a problem with X.509v1 nor
>>>>>>> with a self-signed X.509v1 End-Entity cert.
>>>>>>>=20
>>>>>>>=20
>>>>>>>> The fact that many implementations
>>>>>>>> violate IETF PKI standards in this regard, is unfortunate, but =
it is not
>>>>>>>> a basis for issuing a new IETF standard that codifies this =
behavior.
>>>>>>>=20
>>>>>>> I know that there are lots of commercial CAs that still have CA =
certs
>>>>>>> in every browser that are not valid CA certs according to PKIX / =
RFC 5280.
>>>>>>>=20
>>>>>>> But having TLSv1.0&TLSv1.1 (i.e. 99% of the installed base)
>>>>>>> accept X.509v1 self-signed EE certs is perfectly fine.
>>>>>>>=20
>>>>>>> X.509v1 is fairly close to a bare key, supported by all TLS =
implementations
>>>>>>> in the installed base, as well as tools in the installed base, =
such as
>>>>>>> the openssl.exe shell and for transfering keypairs within =
PKCS#12/PFX.
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> dane mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/dane
>>>>>=20
>>>>> _______________________________________________
>>>>> dane mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/dane
>>>>>=20
>>>=20
>>>=20
>=20
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

Social Web Architect
http://bblfish.net/

From [email-masked]  Fri Apr  8 13:34:25 2011
From: James Cloos <[email-masked]>
To: Paul Hoffman <[email-masked]>
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC
Copyright: Copyright 2011 James Cloos
OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
Date: Fri, 08 Apr 2011 16:25:18 -0400
Lines: 18
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

>>>>> "PH" == Paul Hoffman <[email-masked]> writes:

JC>> The existing discussions here went in the direction that the dane trust
JC>> path verifies *only* if the cert specified in the RR exactly matches one
JC>> the of certs in the chain provided by the d?tls server.

PH> That is not true at all. For months, we have talked about allowing the
PH> cert from the TLSA record represent a CA that would validate the EE
PH> cert from TLS. Please see the last few revs of the draft, for example.

I didn't see any contras to the discussions which concluded that the
dane rr should be ignored unless it exactly matched one the certs in the
chain presented by the tls server.  (Either by reference in the digest
case or bit-for-bit in the explicit case.)

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

From [email-masked]  Fri Apr  8 14:20:45 2011
Sender: [email-masked]
Date: Fri, 8 Apr 2011 14:22:30 -0700
From: Zack Weinberg <[email-masked]>
To: [email-masked]
Subject: [dane] Requirements - HTTPS

I'd like to lay out a short list of requirements on DANE from a web
browser implementor's perspective.  This probably overlaps quite a bit
with other people's requirement lists, but I haven't seen the web use
case pulled together in a neat package.

1) Critical requirements:  If DANE does not provide these things, web
browsers are unlikely to bother adopting it *at all*.

[Exclusion] DANE must allow a site administrator to indicate that
their server(s) will use *only* a particular finite set of keys.

[Hard failure] Clients must be required to refuse to proceed with a
connection to a site if DANE indicates a security error.

[Site compatibility] A client that implements DANE must, when
interacting with a site that has not deployed DANE, behave exactly as
a client that does not implement DANE would behave (except for making
additional DNS lookups).

[Client compatibility] A site must be able to deploy DANE without
rendering itself unavailable to clients that do not implement DANE.

[Encapsulation] If there is a DANE record at a.b.c.example, it must
*only* affect services hosted at a.b.c.example.  (I am reliably
informed that the "trust anchor" language in some revisions of this
spec breaks this requirement.)

[Predictability] Client behavior in response to DANE records must be
spelled out in the DANE specification with as little wiggle room as
possible.

2) Non-critical requirements: These would be nice to have, but their
absence would not render the spec useless to us.

[Inclusion] DANE should provide a way for sites that use self-signed
certificates (for whatever reason) to make their servers trustable
without user intervention.

[Minimal dependencies] It should be possible for a site to deploy DANE
without also deploying anything else, except DNSSEC.

[Minimal knobs] Ideally, DANE should have only one operating mode.
Practically, DANE should have as few operating modes as possible.

zw

From [email-masked]  Fri Apr  8 14:50:23 2011
From: James Cloos <[email-masked]>
To: [email-masked]
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC
Copyright: Copyright 2011 James Cloos
OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
Date: Fri, 08 Apr 2011 17:46:16 -0400
Lines: 27
Cc: Paul Hoffman <[email-masked]>
Subject: Re: [dane] [keyassure] Use cases document.

>>>>> "JC" == James Cloos <[email-masked]> writes:

JC> I didn't see any contras to the discussions which concluded that the
JC> dane rr should be ignored unless it exactly matched one the certs in the
JC> chain presented by the tls server.  (Either by reference in the digest
JC> case or bit-for-bit in the explicit case.)

I should add that I have no objection to supporting a setup where a CA
cert is in the RR and the chain provided by the d?tls server contains
everything up to its CA's cert rather than everything including its CA's
cert.  I just got the impression that the consensus was against that.

But I still want to see a simple scenario where the d?tls server
provides a cert whose sig is in the rr.  The fact that that cert
comes from a remote which is found via an A/AAAA lookup on the
same data as is used to look up the dane rr is sufficient trust
for the majority of d?tls use.  (Provided, of course, that the
dnssec verified.)

(Although I have to ask:  is that the hash of the text as stored in
the pem file or is that the hash of the base64-decoded binary data?
I presume the latter, but have to ask.)

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

From [email-masked]  Fri Apr  8 14:55:29 2011
Date: Fri, 8 Apr 2011 21:57:12 +0000
From: Phillip Hallam-Baker <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dane] elephant use case,

--20cf307f307cf058b104a06f4eee
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Apr 8, 2011 at 4:42 PM, Martin Rex <[email-masked]> wrote:

> Phillip Hallam-Baker wrote:
> >
> > Could people actually take some time to learn about what the EFF data
> means
> > before engaging in this hyperbole?
> >
> > There are not and have never been 600 RA certs. The EFF people do not
> > understand what the data means or why the certs are configured the way
> they
> > are. In fact the pressure that we have had from Mozilla and other sources
> is
> > to increase the number of intermediate certs.
>
> RA "registration authorities"
>   http://en.wikipedia.org/wiki/Registration_authority
>
> do NOT have certificates themselves.  The organizations that have
> the certificate with cert signing capabilities are called CAs.
>
> What EFF likely did was that they counted the distinct CA(!!) certificates
> that are valid under the trusted roots certs in Browsers as indicated
> under "organization name" in those CA certificates.
>

We don't need to speculate as to what EFF did, they describe what they did
which was to assert that every intermediate cert in a chain with a different
subject name was an independent CA.

That was and entirely mistaken as a methodology and for them to continue to
make these claims is ignorant and dishonest.

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

--20cf307f307cf058b104a06f4eee
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Fri, Apr 8, 2011 at 4:42 PM, Martin R=
ex <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Phillip Hallam-Baker wrote:<br>
&gt;<br>
&gt; Could people actually take some time to learn about what the EFF data =
means<br>
&gt; before engaging in this hyperbole?<br>
&gt;<br>
&gt; There are not and have never been 600 RA certs. The EFF people do not<=
br>
&gt; understand what the data means or why the certs are configured the way=
 they<br>
&gt; are. In fact the pressure that we have had from Mozilla and other sour=
ces is<br>
&gt; to increase the number of intermediate certs.<br>
<br>
RA &quot;registration authorities&quot;<br>
 =A0 <a href=3D"http://en.wikipedia.org/wiki/Registration_authority" target=
=3D"_blank">http://en.wikipedia.org/wiki/Registration_authority</a><br>
<br>
do NOT have certificates themselves. =A0The organizations that have<br>
the certificate with cert signing capabilities are called CAs.<br>
<br>
What EFF likely did was that they counted the distinct CA(!!) certificates<=
br>
that are valid under the trusted roots certs in Browsers as indicated<br>
under &quot;organization name&quot; in those CA certificates.<br></blockquo=
te><div><br></div><div>We don&#39;t need to speculate as to what EFF did, t=
hey describe what they did which was to assert that every intermediate cert=
 in a chain with a different subject name was an independent CA.</div>
<div><br></div><div>That was and entirely mistaken as a methodology and for=
 them to continue to make these claims is ignorant and dishonest.</div><div=
><br></div><div>=A0</div></div>-- <br>Website: <a href=3D"http://hallambake=
r.com/">http://hallambaker.com/</a><br>
<br>

--20cf307f307cf058b104a06f4eee--

From [email-masked]  Fri Apr  8 14:59:38 2011
From: James Cloos <[email-masked]>
To: Zack Weinberg <[email-masked]>
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC
Copyright: Copyright 2011 James Cloos
OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
Date: Fri, 08 Apr 2011 17:56:16 -0400
Lines: 17
Cc: [email-masked]
Subject: Re: [dane] Requirements - HTTPS

>>>>> "ZW" == Zack Weinberg <[email-masked]> writes:

ZW> [Hard failure] Clients must be required to refuse to proceed with a
ZW> connection to a site if DANE indicates a security error.

For this porpose, do you agree that a dane-indicated cecurity error can
only occur if the dnssec verified (or, perhaps, if it is provably corrupted)?

Ie, if there is no dnssec at all then fallback to existing still works
notwithstanding a dane rr?  

And when dnssec and dane both exist but the dnssec sigs do not verify,
do you envision hard failure or fallback?

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

From [email-masked]  Fri Apr  8 15:27:37 2011
Sender: [email-masked]
Date: Fri, 8 Apr 2011 15:29:20 -0700
From: Zack Weinberg <[email-masked]>
To: James Cloos <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] Requirements - HTTPS

On Fri, Apr 8, 2011 at 2:56 PM, James Cloos <[email-masked]> wrote:
>>>>>> "ZW" == Zack Weinberg <[email-masked]> writes:
>
> ZW> [Hard failure] Clients must be required to refuse to proceed with a
> ZW> connection to a site if DANE indicates a security error.
>
> For this porpose, do you agree that a dane-indicated cecurity error can
> only occur if the dnssec verified (or, perhaps, if it is provably corrupted)?
>
> Ie, if there is no dnssec at all then fallback to existing still works
> notwithstanding a dane rr?

Yes.  (It's too specific for a "requirements" document, but I want
words to the effect of "TLSA records whose DNSSEC validation status is
'insecure' or 'indeterminate' MUST be ignored" in the final spec.)

> And when dnssec and dane both exist but the dnssec sigs do not verify,
> do you envision hard failure or fallback?

IMO that (specifically, DNSSEC validation status "bogus" on *any*
record returned, TLSA or not) should also be a hard failure.

zw

From [email-masked]  Fri Apr  8 16:03:29 2011
Date: Fri, 8 Apr 2011 16:05:13 -0700
From: Eric Rescorla <[email-masked]>
To: Zack Weinberg <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] Requirements - HTTPS

On Fri, Apr 8, 2011 at 2:22 PM, Zack Weinberg <[email-masked]> wr=
ote:
> I'd like to lay out a short list of requirements on DANE from a web
> browser implementor's perspective. =A0This probably overlaps quite a bit
> with other people's requirement lists, but I haven't seen the web use
> case pulled together in a neat package.
>
> 1) Critical requirements: =A0If DANE does not provide these things, web
> browsers are unlikely to bother adopting it *at all*.
>
> [Exclusion] DANE must allow a site administrator to indicate that
> their server(s) will use *only* a particular finite set of keys.
>
> [Hard failure] Clients must be required to refuse to proceed with a
> connection to a site if DANE indicates a security error.

I think this requires some elaboration. The browser can either:

(a) throw an overrideable error like the existing chrome/firefox errors for
CN mismatch or unknown CA.
(b) throw a non-overrideable error like what happens if it gets an NXDOMAIN=
.

I haven't formed an opinion on which of these is desireable, but surely you=
're
not saying that browser manufacturers won't adopt this without an RFC 2119
MUST for (b). After all, if the manufacturer wants to do so, nothing is sto=
pping
them from refusing the let the user override.

-Ekr

From [email-masked]  Fri Apr  8 16:26:13 2011
Sender: [email-masked]
Date: Fri, 8 Apr 2011 16:27:56 -0700
From: Zack Weinberg <[email-masked]>
To: Eric Rescorla <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] Requirements - HTTPS

On Fri, Apr 8, 2011 at 4:05 PM, Eric Rescorla <[email-masked]> wrote:
>>
>> [Exclusion] DANE must allow a site administrator to indicate that
>> their server(s) will use *only* a particular finite set of keys.
>>
>> [Hard failure] Clients must be required to refuse to proceed with a
>> connection to a site if DANE indicates a security error.
>
> I think this requires some elaboration. The browser can either:
>
> (a) throw an overrideable error like the existing chrome/firefox errors for
> CN mismatch or unknown CA.
> (b) throw a non-overrideable error like what happens if it gets an NXDOMAIN.
>
> I haven't formed an opinion on which of these is desireable, but surely you're
> not saying that browser manufacturers won't adopt this without an RFC 2119
> MUST for (b). After all, if the manufacturer wants to do so, nothing is stopping
> them from refusing the let the user override.

I meant the [hard failure] requirement to be at a lower level.
Suppose DANE tells you that example.com serves HTTPS with certificate
A.  Unbeknownst to you, your traffic to example.com is being
redirected to a malicious server, which presents certificate X.  The
attacker tricked a CA in your trust pool into signing that
certificate; in the absence of DANE information you would trust it.  I
want DANE to say that you MUST NOT trust that certificate.  *That's*
the text whose absence would be a deal-breaker for browsers.

(Why is it a deal-breaker?  Can't we just unilaterally decide that we
WILL NOT trust that certificate under those conditions?  In principle,
yes, but without a hard requirement in a spec to point at, there's
going to be tremendous pushback against doing anything that risks
reducing availability, and there's going to be a headache getting
*all* the browser vendors to agree on the details.)

At the application level, I would like DANE to include text saying
that the error thrown SHOULD be non-overrideable (that is, your (b),
not (a)), but as advice rather than requirement.

zw

From [email-masked]  Fri Apr  8 18:02:32 2011
Date: Fri, 8 Apr 2011 21:04:15 -0400
From: Scott Schmit <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [dane] Requirements - HTTPS

On Fri, Apr 08, 2011 at 02:22:30PM -0700, Zack Weinberg wrote dane:

I like your list, I just have a few things to add to it.

> 1) Critical requirements:  If DANE does not provide these things, web
> browsers are unlikely to bother adopting it *at all*.
> 
[Implementable] DANE must be as easy to implement or add to existing
software as possible.

The spec is useless if it takes more effort than anyone is willing to
expend to implement it, or makes it difficult to continue to support
existing use cases.

> 2) Non-critical requirements: These would be nice to have, but their
> absence would not render the spec useless to us.
> 
> [Inclusion] DANE should provide a way for sites that use self-signed
> certificates (for whatever reason) to make their servers trustable
> without user intervention.

Maybe this isn't critical to browser acceptance, but I think that this
is important to site acceptance. A lot of people use self-signed 
certificates, and I seriously doubt that DANE will suddenly inspire them
to buy a certificate from a CA. But if they can put their cert (or a 
hash of it) into the DNS, signed by DNSSEC, and make the browser 
warnings go away, I can see that happening.

-- 
Scott Schmit

From [email-masked]  Fri Apr  8 18:10:13 2011
Date: Fri, 8 Apr 2011 21:11:50 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Eric Rescorla <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] Requirements - HTTPS

--20cf307cfc68f524ef04a0720654
Content-Type: text/plain; charset=ISO-8859-1

?? As a reality check here, the browser providers have taken ten years to
get round to doing hard fail on OCSP.

So how likely is it that browser providers are going to refuse to implement
a new and untested spec unless it mandates hard fail behavior?

Has anyone actually asked a browser provider what their opinion is? I rather
suspect not.

On Fri, Apr 8, 2011 at 7:05 PM, Eric Rescorla <[email-masked]> wrote:

> On Fri, Apr 8, 2011 at 2:22 PM, Zack Weinberg <[email-masked]>
> wrote:
> > I'd like to lay out a short list of requirements on DANE from a web
> > browser implementor's perspective.  This probably overlaps quite a bit
> > with other people's requirement lists, but I haven't seen the web use
> > case pulled together in a neat package.
> >
> > 1) Critical requirements:  If DANE does not provide these things, web
> > browsers are unlikely to bother adopting it *at all*.
> >
> > [Exclusion] DANE must allow a site administrator to indicate that
> > their server(s) will use *only* a particular finite set of keys.
> >
> > [Hard failure] Clients must be required to refuse to proceed with a
> > connection to a site if DANE indicates a security error.
>
> I think this requires some elaboration. The browser can either:
>
> (a) throw an overrideable error like the existing chrome/firefox errors for
> CN mismatch or unknown CA.
> (b) throw a non-overrideable error like what happens if it gets an
> NXDOMAIN.
>
> I haven't formed an opinion on which of these is desireable, but surely
> you're
> not saying that browser manufacturers won't adopt this without an RFC 2119
> MUST for (b). After all, if the manufacturer wants to do so, nothing is
> stopping
> them from refusing the let the user override.
>
> -Ekr
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

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

--20cf307cfc68f524ef04a0720654
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

?? As a reality check here, the browser providers have taken ten years to g=
et round to doing hard fail on OCSP.<div><br></div><div>So how likely is it=
 that browser providers are going to refuse to implement a new and untested=
 spec unless it mandates hard fail behavior?</div>
<div><br></div><div><br></div><div>Has anyone actually asked a browser prov=
ider what their opinion is? I rather suspect not.</div><div><br></div><div>=
<br><br><div class=3D"gmail_quote">On Fri, Apr 8, 2011 at 7:05 PM, Eric Res=
corla <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">[email-masked]</a=
>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;"><div class=3D"im">On Fri, Apr 8, 2011 at 2:=
22 PM, Zack Weinberg &lt;<a href=3D"mailto:[email-masked]">zack.w=
[email-masked]</a>&gt; wrote:<br>

&gt; I&#39;d like to lay out a short list of requirements on DANE from a we=
b<br>
&gt; browser implementor&#39;s perspective. =A0This probably overlaps quite=
 a bit<br>
&gt; with other people&#39;s requirement lists, but I haven&#39;t seen the =
web use<br>
&gt; case pulled together in a neat package.<br>
&gt;<br>
&gt; 1) Critical requirements: =A0If DANE does not provide these things, we=
b<br>
&gt; browsers are unlikely to bother adopting it *at all*.<br>
&gt;<br>
&gt; [Exclusion] DANE must allow a site administrator to indicate that<br>
&gt; their server(s) will use *only* a particular finite set of keys.<br>
&gt;<br>
&gt; [Hard failure] Clients must be required to refuse to proceed with a<br=
>
&gt; connection to a site if DANE indicates a security error.<br>
<br>
</div>I think this requires some elaboration. The browser can either:<br>
<br>
(a) throw an overrideable error like the existing chrome/firefox errors for=
<br>
CN mismatch or unknown CA.<br>
(b) throw a non-overrideable error like what happens if it gets an NXDOMAIN=
.<br>
<br>
I haven&#39;t formed an opinion on which of these is desireable, but surely=
 you&#39;re<br>
not saying that browser manufacturers won&#39;t adopt this without an RFC 2=
119<br>
MUST for (b). After all, if the manufacturer wants to do so, nothing is sto=
pping<br>
them from refusing the let the user override.<br>
<br>
-Ekr<br>
<div><div></div><div class=3D"h5">_________________________________________=
______<br>
dane mailing list<br>
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/dane</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--20cf307cfc68f524ef04a0720654--

From [email-masked]  Fri Apr  8 18:46:38 2011
Sender: [email-masked]
Date: Fri, 8 Apr 2011 18:48:00 -0700
From: Zack Weinberg <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] Requirements - HTTPS

On Fri, Apr 8, 2011 at 6:11 PM, Phillip Hallam-Baker <[email-masked]> wrote:
> ?? As a reality check here, the browser providers have taken ten years to
> get round to doing hard fail on OCSP.
> So how likely is it that browser providers are going to refuse to implement
> a new and untested spec unless it mandates hard fail behavior?
>
> Has anyone actually asked a browser provider what their opinion is? I rather
> suspect not.

I *am* a browser implementor, and my organization had this
conversation at some length this week (and I thought you were one of
the people dialed in!)  I refer you to
http://www.owlfolio.org/research/securing-the-future-net/ -- but to be
brief, there are major differences between DANE and OCSP that make the
case for hard-fail for DANE enormously easier to make -- provided the
standards back us up.
First, sites opt-in to DANE, whereas OCSP (or more precisely,
revocation checking) is something sites have no control over.  Second,
revocation checking ties a site's availability to the reliability of a
service they have no control over, whereas DANE is entirely under the
control of the site (assuming it's big enough to run its own DNS
servers).  And finally, DANE is new, so there is no ten-year history
of browsers *not* failing on security errors with it.

zw

From [email-masked]  Fri Apr  8 23:16:33 2011
Date: Sat, 9 Apr 2011 16:18:12 +1000
From: Peter Eckersley <[email-masked]>
To: =?utf-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
Sender: [email-masked]
Cc: [email-masked]
Subject: Re: [dane] Question about SSLiverse data (Was: Re: [keyassure] Use cases document)

Hi OndÅ™ej,

In the August 2010 dataset there were about 500,000 self-signed X.509v1
certificates, and 56,000 X.509v3 certs which are self-signed but not CAs.

SELECT count(*) 
FROM all_certs 
WHERE subject=issuer 
  AND NOT LOCATE("TRUE",`X509v3 extensions:X509v3 Basic Constraints:CA`)
  AND version != " 1 (0x0)";
+----------+
| count(*) |
+----------+
|    56195 |
+----------+

SELECT count(*) 
FROM all_certs 
WHERE subject=issuer 
  AND NOT LOCATE("Certificate Sign", `X509v3 extensions:X509v3 Key Usage`)
  AND version != " 1 (0x0)";
+----------+
| count(*) |
+----------+
|   132931 |
+----------+

SELECT count(*) FROM acerts 
WHERE subject=issuer AND version=" 1 (0x0)";
+----------+
| count(*) |
+----------+
|   494022 |
+----------+

On Fri, Apr 08, 2011 at 04:46:49PM +0200, OndÅ™ej SurÃ½ wrote:
> Hi Peter,
> 
> there was an interesting question on the DANE WG list - which you
> might have an answer for:
> 
> > It would be interesting to know from the SSLiverse database how many
> > TLS server certs on the internet are self-signed EE certs vs.
> > CA-signed, and how many of the self-signed TLS server certs are
> > X.509v1.
> 
> Kind regards,
> Ondrej, DANE WG co-chair
> 

From: Martin Rex <[email-masked]>
Subject: Re: [dane] [keyassure] Use cases document.
To: [email-masked] (Richard L. Barnes)
Date: Fri, 8 Apr 2011 16:01:53 +0200 (MEST)
Cc: [email-masked], [email-masked]
> 
> Richard L. Barnes wrote:
> > 
> > To note again: The phrase "self-signed EE cert" does not make sense.
> > From RFC 5280:
> > "
> > Self-issued certificates are generated to support changes in policy
> > or operations.  Self-signed certificates are self-issued certificates
> > where the digital signature may be verified by the public key bound
> > into the certificate.
> > "
> > Since a self-signed cert has a cert issued under it (itself), it has
> > to be a CA cert.
> > 
> > A self-signed cert *without* the CA bits set is therefore malformed,
> > and will not pass PKIX validation.  
> 
> 
> You seem to have entirely missed the most important of PKIX
> 
>   http://tools.ietf.org/html/rfc5280
> 
>    Abstract
> 
>    This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use
>    in the Internet.
> 
> 
> PKIX rules, by their own definition, do not apply to X.509v1 self-signed
> EE certs.  And SSLv3, TLSv1.0 and TLSv1.1 are perfectly usable with X.509v1
> self-signed EE certs.
> 
>  
> 
> It would be interesting to know from the SSLiverse database how many
> TLS server certs on the internet are self-signed EE certs vs. CA-signed,
> and how many of the self-signed TLS server certs are X.509v1.
> 
> 
> -Martin

-- 
Peter Eckersley                            [email-masked]
Senior Staff Technologist         Tel  +1 415 436 9333 x131
Electronic Frontier Foundation    Fax  +1 415 436 9993
-- 
Peter Eckersley                            [email-masked]
Senior Staff Technologist         Tel  +1 415 436 9333 x131
Electronic Frontier Foundation    Fax  +1 415 436 9993

From [email-masked]  Sat Apr  9 09:04:19 2011
From: "Olle E. Johansson" <[email-masked]>
Date: Sat, 9 Apr 2011 18:06:00 +0200
To: Zack Weinberg <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] Requirements - HTTPS

9 apr 2011 kl. 03.48 skrev Zack Weinberg:

> On Fri, Apr 8, 2011 at 6:11 PM, Phillip Hallam-Baker =
<[email-masked]> wrote:
>> ?? As a reality check here, the browser providers have taken ten =
years to
>> get round to doing hard fail on OCSP.
>> So how likely is it that browser providers are going to refuse to =
implement
>> a new and untested spec unless it mandates hard fail behavior?
>>=20
>> Has anyone actually asked a browser provider what their opinion is? I =
rather
>> suspect not.
>=20
> I *am* a browser implementor, and my organization had this
> conversation at some length this week (and I thought you were one of
> the people dialed in!)  I refer you to
> http://www.owlfolio.org/research/securing-the-future-net/ -- but to be
> brief, there are major differences between DANE and OCSP that make the
> case for hard-fail for DANE enormously easier to make -- provided the
> standards back us up.
> First, sites opt-in to DANE, whereas OCSP (or more precisely,
> revocation checking) is something sites have no control over.  Second,
> revocation checking ties a site's availability to the reliability of a
> service they have no control over, whereas DANE is entirely under the
> control of the site (assuming it's big enough to run its own DNS
> servers).  And finally, DANE is new, so there is no ten-year history
> of browsers *not* failing on security errors with it.
>=20
I keep coming back to making the point that we're not creating a =
solution for a single protocol or application.
I don't think that how web browser will implement DANE is a blocking =
issue for this work.=20
I personally need it for other protocols that haven't got a huge =
implementation base that will be blocking progress.

/O=

From [email-masked]  Sat Apr  9 10:03:37 2011
Sender: [email-masked]
Date: Sat, 9 Apr 2011 10:05:22 -0700
From: Zack Weinberg <[email-masked]>
To: "Olle E. Johansson" <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] Requirements - HTTPS

> I keep coming back to making the point that we're not creating a solution for a single protocol or application.
> I don't think that how web browser will implement DANE is a blocking issue for this work.
> I personally need it for other protocols that haven't got a huge implementation base that will be blocking progress.

How do your requirements differ from my requirements?  Please be specific.

zw

From [email-masked]  Sat Apr  9 10:14:11 2011
From: Steve Schultze <[email-masked]>
Date: Sat, 9 Apr 2011 13:15:54 -0400
To: [email-masked]
Subject: Re: [dane] elephant use case,

On Apr 8, 2011, at 5:57 PM, Phillip Hallam-Baker wrote:
>> On Fri, Apr 8, 2011 at 4:42 PM, Martin Rex <[email-masked]> wrote:
>> Phillip Hallam-Baker wrote:
>> >
>> > Could people actually take some time to learn about what the EFF =
data means
>> > before engaging in this hyperbole?
>> >
>> > There are not and have never been 600 RA certs. The EFF people do =
not
>> > understand what the data means or why the certs are configured the =
way they
>> > are. In fact the pressure that we have had from Mozilla and other =
sources is
>> > to increase the number of intermediate certs.
>>=20
>> RA "registration authorities"
>>   http://en.wikipedia.org/wiki/Registration_authority
>>=20
>> do NOT have certificates themselves.  The organizations that have
>> the certificate with cert signing capabilities are called CAs.
>>=20
>> What EFF likely did was that they counted the distinct CA(!!) =
certificates
>> that are valid under the trusted roots certs in Browsers as indicated
>> under "organization name" in those CA certificates.
>=20
> We don't need to speculate as to what EFF did, they describe what they =
did which was to assert that every intermediate cert in a chain with a =
different subject name was an independent CA.
>=20
> That was and entirely mistaken as a methodology and for them to =
continue to make these claims is ignorant and dishonest.

I don't understand why this OT conversation has to be perpetuated on =
this list, but EFF clearly stated:
"651 organizations, but ownerships & jurisdictions overlap"

Their work was the most comprehensive and helpful to date, and they =
released all of the raw data.

Continuing to engage in trash talk here is pointless and distracting.  =
If you want to do some analysis of the data and give your own numbers, =
do so and post it on the Comodo blog or somewhere that it isn't =
off-topic.  You might even consider approving some of the comments on =
that post so that people can have a reasonable back-and-forth.=

From [email-masked]  Sat Apr  9 12:58:35 2011
From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 9 Apr 2011 16:00:09 -0400
To: Steve Schultze <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dane] elephant use case,

I make no apologies for correcting incorrect claims made by others to this l=
ist.=20

I did not raise the claim here. And I get rather fed up of people who claim t=
hat their problem is that something is off topic when their real problem is t=
hat they don't like their facts being challenged

As far as the eff presentation goes, they fail to make the distinction you p=
oint out in their web page sumarising their results or when they draw conclu=
sions=20

Thus I do not feel that I am misrepresenting their claims.=20

Sent from my iPhone

On 9 Apr 2011, at 13:15, Steve Schultze <[email-masked]> wrote:

> On Apr 8, 2011, at 5:57 PM, Phillip Hallam-Baker wrote:
>>> On Fri, Apr 8, 2011 at 4:42 PM, Martin Rex <[email-masked]> wrote:
>>> Phillip Hallam-Baker wrote:
>>>>=20
>>>> Could people actually take some time to learn about what the EFF data m=
eans
>>>> before engaging in this hyperbole?
>>>>=20
>>>> There are not and have never been 600 RA certs. The EFF people do not
>>>> understand what the data means or why the certs are configured the way t=
hey
>>>> are. In fact the pressure that we have had from Mozilla and other sourc=
es is
>>>> to increase the number of intermediate certs.
>>>=20
>>> RA "registration authorities"
>>>  http://en.wikipedia.org/wiki/Registration_authority
>>>=20
>>> do NOT have certificates themselves.  The organizations that have
>>> the certificate with cert signing capabilities are called CAs.
>>>=20
>>> What EFF likely did was that they counted the distinct CA(!!) certificat=
es
>>> that are valid under the trusted roots certs in Browsers as indicated
>>> under "organization name" in those CA certificates.
>>=20
>> We don't need to speculate as to what EFF did, they describe what they di=
d which was to assert that every intermediate cert in a chain with a differe=
nt subject name was an independent CA.
>>=20
>> That was and entirely mistaken as a methodology and for them to continue t=
o make these claims is ignorant and dishonest.
>=20
> I don't understand why this OT conversation has to be perpetuated on this l=
ist, but EFF clearly stated:
> "651 organizations, but ownerships & jurisdictions overlap"
>=20
> Their work was the most comprehensive and helpful to date, and they releas=
ed all of the raw data.
>=20
> Continuing to engage in trash talk here is pointless and distracting.  If y=
ou want to do some analysis of the data and give your own numbers, do so and=
 post it on the Comodo blog or somewhere that it isn't off-topic.  You might=
 even consider approving some of the comments on that post so that people ca=
n have a reasonable back-and-forth.
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

From [email-masked]  Sat Apr  9 13:19:42 2011
Date: Sat, 9 Apr 2011 16:21:26 -0400
From: Scott Schmit <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [dane] Requirements - HTTPS

On Sat, Apr 09, 2011 at 06:06:00PM +0200, Olle E. Johansson wrote dane:
> I keep coming back to making the point that we're not creating a
> solution for a single protocol or application.  I don't think that how
> web browser will implement DANE is a blocking issue for this work.  I
> personally need it for other protocols that haven't got a huge
> implementation base that will be blocking progress.

For what it's worth, when I looked over Zack's requirement set, I tried
to think about how things would be different for non-HTTPS cases, and I
couldn't come up with any different or new requirements. Honestly, I'm
not sure why the subject line talks about HTTPS (other than as an
admission of perspective), as it doesn't seem relevant.

Do you have any new/different requirements?

-- 
Scott Schmit

From [email-masked]  Sat Apr  9 14:10:17 2011
Sender: [email-masked]
Date: Sat, 9 Apr 2011 17:12:01 -0400
From: Adam Langley <[email-masked]>
To: [email-masked]
Subject: [dane] A browser's myopic view

(I hope that the subject makes it esp clear that I feel that browsers
are only part of the TLS ecosystem and a troubled part at that,
burdened, as they are, with a huge legacy base and an obsession with
speed. None the less, a couple of people have asked me to comment on
this list. It's nothing that I haven't said before, but the mailing
list has grown and even changed names in the mean time.)

The proximal trigger for this was PHB:
> So how likely is it that browser providers are going to refuse to implement a new and untested spec unless it mandates hard fail behavior?

So I'll start with exclusion:

The problem with a hard failure on exclusion is that it means that we
*have* to get the DNS information before sending application data on a
TLS connection, or we have to have it cached.

In the event that we don't have it cached, getting the information
from DNS is a problem. I ran an experiment in Chrome doing lookups for
an odd DNS RRTYPE (13172) concurrently with the A lookup for HTTPS
URLs. 2.5% of the time, the result came in over 100ms after we had
completed the A lookup, TCP connection, TLS handshake and certificate
verification! Somewhere between 0.5-1% of the time, we didn't get an
answer within 10s (the limit of the histogram), which suggests that
networks were filtering these requests.

Needless to say, slowing things down to such an extent, and breaking
that many people is a hard sell.

Also, unless the information is DNSSEC authenticated, an attacker can
spoof and DoS a site, and DNSSEC resolvers on the client are rare.
(Or, rather, they would trigger hard failures for random sites until
the user flushed their local browser state. Then the attacker can MITM
the connection that they really wanted.)

But exclusion could be very valuable! However, it seems that HSTS
would be a better channel for this information. We only parse HSTS
headers over HTTPS (so no DoS) and it don't have any of the above
problems. Also, Firefox and we (Chrome) have both shown that we're
happy to make HSTS failures hard errors.

DNS solutions have the advantage of protecting the first connection,
it's true. We have the preloaded list[1] to address that to some
extent but it might have to be something that we trade off. (None of
this is an official statement of what we will or wont do in future
Chrome versions. I'm still writing the code for exclusion at the
moment.)

Switching tacks for a second to the specifics of DANE:

For exclusion we expect that some sites will wish to `pin' to a CA
rather than to their leaf certificate. In this case, you have to hash
public keys (or, rather, SubjectPublicKeyInfos), not certificates.
Certificate chains are built from a pool and the intermediate
certificates that a site presents are simply inserted into the pool.
Intermediate certificates exist in different versions (same public
key, but different expiry times, brands etc) and the constructed chain
might find a path through different versions of the intermediates.
Only the public keys have to match.

Even if you're pinning to a leaf certificate, hashing the public key
means that you can renew the certificate or add extra SANs without
performing an exclusion rollover.

Next, Authentication (or `inclusion'):

The DNS has several nice properties as a PKI: scoped delegation and
short lived signatures rather than problematic revocation systems. I
can see why some sites would like to have a DNSSEC signed HTTPS
connection. They're not going to be major sites though. It will be
hard to justify breaking even a tiny number of users when CA
certificates can be had for free[2].

The issue here is that the DNS protocol isn't a great transport for
DNSSEC information! As noted above, it looks like some networks filter
out odd RRTYPES. Also, DNSSEC resolvers on the client are rare and I
don't really want to drop one into a browser (although Dan Kaminsky is
doing good work here). I'd be much happier if the server did the work
and sent a DNSSEC chain in its certificate. DNSSEC information doesn't
have to be carried via the DNS protocol and carrying it in the
certificate chain works nicely. The code is already in Chrome (Dan
demoed it at Blackhat last year), although it's currently expecting
something like an early draft of CAA I think and it's off by default.

[1] http://dev.chromium.org/sts
[2] https://github.com/ioerror/duraconf/blob/master/startssl/README.markdown

Cheers

AGL

-- 
Adam Langley [email-masked] http://www.imperialviolet.org

From [email-masked]  Sat Apr  9 17:30:40 2011
Date: Sat, 9 Apr 2011 20:32:22 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Adam Langley <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] A browser's myopic view

On Sat, 9 Apr 2011, Adam Langley wrote:

> In the event that we don't have it cached, getting the information
> from DNS is a problem. I ran an experiment in Chrome doing lookups for
> an odd DNS RRTYPE (13172) concurrently with the A lookup for HTTPS
> URLs. 2.5% of the time, the result came in over 100ms after we had
> completed the A lookup, TCP connection, TLS handshake and certificate
> verification! Somewhere between 0.5-1% of the time, we didn't get an
> answer within 10s (the limit of the histogram), which suggests that
> networks were filtering these requests.
>
> Needless to say, slowing things down to such an extent, and breaking
> that many people is a hard sell.

Note that if you first query for HASTLS, and it is not there, then you would
not need to wait for the TLSA record query.

The HASTLS record is very small and does not have the TCP 53 misconfiguration
problem.

Paul

From [email-masked]  Sat Apr  9 18:11:25 2011
Date: Sat, 9 Apr 2011 21:13:09 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Wouters <[email-masked]>
Cc: Adam Langley <[email-masked]>, [email-masked]
Subject: Re: [dane] A browser's myopic view

--20cf3054a11386716904a086293a
Content-Type: text/plain; charset=ISO-8859-1

As currently specified HASTLS has the following issues:

* It uses prefix records but does not have a strategy to avoid the
limitations of using prefixes with wildcards and/or aliases.

* The question of interoperation with use of SRV and URI records is not
addressed.

* It is limited to TLS and does not allow for other security properties to
be described in the same transaction.

I have a very similar approach that allows these limitations to be avoided.
It is relevant to DANE because it is a framework that allows a client to
obtain all the relevant information for establishing a connection through a
single mechanism rather than having one record per property type.

Basically the discovery strategy needs to look for an unprefixed record
first. At the end of the first discovery phase the client has a canonical
name and can apply prefixes to it without problems.

We could combine our proposals. It would serve the community better if we
did.

On Sat, Apr 9, 2011 at 8:32 PM, Paul Wouters <[email-masked]> wrote:

> On Sat, 9 Apr 2011, Adam Langley wrote:
>
>  In the event that we don't have it cached, getting the information
>> from DNS is a problem. I ran an experiment in Chrome doing lookups for
>> an odd DNS RRTYPE (13172) concurrently with the A lookup for HTTPS
>> URLs. 2.5% of the time, the result came in over 100ms after we had
>> completed the A lookup, TCP connection, TLS handshake and certificate
>> verification! Somewhere between 0.5-1% of the time, we didn't get an
>> answer within 10s (the limit of the histogram), which suggests that
>> networks were filtering these requests.
>>
>> Needless to say, slowing things down to such an extent, and breaking
>> that many people is a hard sell.
>>
>
> Note that if you first query for HASTLS, and it is not there, then you
> would
> not need to wait for the TLSA record query.
>
> The HASTLS record is very small and does not have the TCP 53
> misconfiguration
> problem.
>
> Paul
>
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

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

--20cf3054a11386716904a086293a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

As currently specified HASTLS has the following issues:<div><br></div><div>=
* It uses prefix records but does not have a strategy to avoid the limitati=
ons of using prefixes with wildcards and/or aliases.</div><div><br></div>
<div>* The question of interoperation with use of SRV and URI records is no=
t addressed.</div><div><br></div><div>* It is limited to TLS and does not a=
llow for other security properties to be described in the same transaction.=
</div>
<div><br></div><div>I have a very similar approach that allows these limita=
tions to be avoided. It is relevant to DANE because it is a framework that =
allows a client to obtain all the relevant information for establishing a c=
onnection through a single mechanism rather than having one record per prop=
erty type.</div>
<div><br></div><div>Basically the discovery strategy needs to look for an u=
nprefixed record first. At the end of the first discovery phase the client =
has a canonical name and can apply prefixes to it without problems.</div>
<div><br></div><div><br></div><div>We could combine our proposals. It would=
 serve the community better if we did.</div><div><br><br><div class=3D"gmai=
l_quote">On Sat, Apr 9, 2011 at 8:32 PM, Paul Wouters <span dir=3D"ltr">&lt=
;<a href=3D"mailto:[email-masked]">[email-masked]</a>&gt;</span> wr=
ote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;"><div class=3D"im">On Sat, 9 Apr 2011, Adam =
Langley wrote:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
In the event that we don&#39;t have it cached, getting the information<br>
from DNS is a problem. I ran an experiment in Chrome doing lookups for<br>
an odd DNS RRTYPE (13172) concurrently with the A lookup for HTTPS<br>
URLs. 2.5% of the time, the result came in over 100ms after we had<br>
completed the A lookup, TCP connection, TLS handshake and certificate<br>
verification! Somewhere between 0.5-1% of the time, we didn&#39;t get an<br=
>
answer within 10s (the limit of the histogram), which suggests that<br>
networks were filtering these requests.<br>
<br>
Needless to say, slowing things down to such an extent, and breaking<br>
that many people is a hard sell.<br>
</blockquote>
<br></div>
Note that if you first query for HASTLS, and it is not there, then you woul=
d<br>
not need to wait for the TLSA record query.<br>
<br>
The HASTLS record is very small and does not have the TCP 53 misconfigurati=
on<br>
problem.<br><font color=3D"#888888">
<br>
Paul</font><div><div></div><div class=3D"h5"><br>
_______________________________________________<br>
dane mailing list<br>
<a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/dane</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--20cf3054a11386716904a086293a--

From [email-masked]  Sat Apr  9 18:42:23 2011
Date: Sat, 9 Apr 2011 21:44:04 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Adam Langley <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] A browser's myopic view

--20cf3054a1131bdae804a086985b
Content-Type: text/plain; charset=ISO-8859-1

I agree that performance is an issue, quite possible a threshold issue for
deployment. However I don't think we can necessarily hope to meet your
performance goals in every circumstance using the work that is in scope for
DANE on its own.

The deployed DNS is a bit of a mess performance wise - as your figures show.

But we don't necessarily have to limit ourselves to the deployed DNS when
considering performance. If browsers on 2.5% of net connections end up going
slower, well maybe we end up having to propose some sort of work around
strategy to get them plugged into a DNS that offers better performance.

I don't want to discuss the details of that type of proposal here. But it is
something we should bear in mind when negotiating with the browser
providers. And in particular when we are looking to give you the facts that
allow you to go and make the case for these proposals inside your
organization.

On Sat, Apr 9, 2011 at 5:12 PM, Adam Langley <[email-masked]> wrote:

> (I hope that the subject makes it esp clear that I feel that browsers
> are only part of the TLS ecosystem and a troubled part at that,
> burdened, as they are, with a huge legacy base and an obsession with
> speed. None the less, a couple of people have asked me to comment on
> this list. It's nothing that I haven't said before, but the mailing
> list has grown and even changed names in the mean time.)
>
> The proximal trigger for this was PHB:
> > So how likely is it that browser providers are going to refuse to
> implement a new and untested spec unless it mandates hard fail behavior?
>
> So I'll start with exclusion:
>
> The problem with a hard failure on exclusion is that it means that we
> *have* to get the DNS information before sending application data on a
> TLS connection, or we have to have it cached.
>
> In the event that we don't have it cached, getting the information
> from DNS is a problem. I ran an experiment in Chrome doing lookups for
> an odd DNS RRTYPE (13172) concurrently with the A lookup for HTTPS
> URLs. 2.5% of the time, the result came in over 100ms after we had
> completed the A lookup, TCP connection, TLS handshake and certificate
> verification! Somewhere between 0.5-1% of the time, we didn't get an
> answer within 10s (the limit of the histogram), which suggests that
> networks were filtering these requests.
>
> Needless to say, slowing things down to such an extent, and breaking
> that many people is a hard sell.
>
> Also, unless the information is DNSSEC authenticated, an attacker can
> spoof and DoS a site, and DNSSEC resolvers on the client are rare.
> (Or, rather, they would trigger hard failures for random sites until
> the user flushed their local browser state. Then the attacker can MITM
> the connection that they really wanted.)
>
> But exclusion could be very valuable! However, it seems that HSTS
> would be a better channel for this information. We only parse HSTS
> headers over HTTPS (so no DoS) and it don't have any of the above
> problems. Also, Firefox and we (Chrome) have both shown that we're
> happy to make HSTS failures hard errors.
>
> DNS solutions have the advantage of protecting the first connection,
> it's true. We have the preloaded list[1] to address that to some
> extent but it might have to be something that we trade off. (None of
> this is an official statement of what we will or wont do in future
> Chrome versions. I'm still writing the code for exclusion at the
> moment.)
>
> Switching tacks for a second to the specifics of DANE:
>
> For exclusion we expect that some sites will wish to `pin' to a CA
> rather than to their leaf certificate. In this case, you have to hash
> public keys (or, rather, SubjectPublicKeyInfos), not certificates.
> Certificate chains are built from a pool and the intermediate
> certificates that a site presents are simply inserted into the pool.
> Intermediate certificates exist in different versions (same public
> key, but different expiry times, brands etc) and the constructed chain
> might find a path through different versions of the intermediates.
> Only the public keys have to match.
>
> Even if you're pinning to a leaf certificate, hashing the public key
> means that you can renew the certificate or add extra SANs without
> performing an exclusion rollover.
>
>
> Next, Authentication (or `inclusion'):
>
> The DNS has several nice properties as a PKI: scoped delegation and
> short lived signatures rather than problematic revocation systems. I
> can see why some sites would like to have a DNSSEC signed HTTPS
> connection. They're not going to be major sites though. It will be
> hard to justify breaking even a tiny number of users when CA
> certificates can be had for free[2].
>
> The issue here is that the DNS protocol isn't a great transport for
> DNSSEC information! As noted above, it looks like some networks filter
> out odd RRTYPES. Also, DNSSEC resolvers on the client are rare and I
> don't really want to drop one into a browser (although Dan Kaminsky is
> doing good work here). I'd be much happier if the server did the work
> and sent a DNSSEC chain in its certificate. DNSSEC information doesn't
> have to be carried via the DNS protocol and carrying it in the
> certificate chain works nicely. The code is already in Chrome (Dan
> demoed it at Blackhat last year), although it's currently expecting
> something like an early draft of CAA I think and it's off by default.
>
>
> [1] http://dev.chromium.org/sts
> [2]
> https://github.com/ioerror/duraconf/blob/master/startssl/README.markdown
>
>
> Cheers
>
> AGL
>
> --
> Adam Langley [email-masked] http://www.imperialviolet.org
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

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

--20cf3054a1131bdae804a086985b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I agree that performance is an issue, quite possible a threshold issue for =
deployment. However I don&#39;t think we can necessarily hope to meet your =
performance goals in every circumstance using the work that is in scope for=
 DANE on its own.<div>
<br></div><div>The deployed DNS is a bit of a mess performance wise - as yo=
ur figures show.</div><div><br></div><div>But we don&#39;t necessarily have=
 to limit ourselves to the deployed DNS when considering performance. If br=
owsers on 2.5% of net connections end up going slower, well maybe we end up=
 having to propose some sort of work around strategy to get them plugged in=
to a DNS that offers better performance.</div>
<div><br></div><div>I don&#39;t want to discuss the details of that type of=
 proposal here. But it is something we should bear in mind when negotiating=
 with the browser providers. And in particular when we are looking to give =
you the facts that allow you to go and make the case for these proposals in=
side your organization.</div>
<div><br></div><div><br><br><div class=3D"gmail_quote">On Sat, Apr 9, 2011 =
at 5:12 PM, Adam Langley <span dir=3D"ltr">&lt;<a href=3D"mailto:agl@imperi=
alviolet.org">[email-masked]</a>&gt;</span> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex;">
(I hope that the subject makes it esp clear that I feel that browsers<br>
are only part of the TLS ecosystem and a troubled part at that,<br>
burdened, as they are, with a huge legacy base and an obsession with<br>
speed. None the less, a couple of people have asked me to comment on<br>
this list. It&#39;s nothing that I haven&#39;t said before, but the mailing=
<br>
list has grown and even changed names in the mean time.)<br>
<br>
The proximal trigger for this was PHB:<br>
&gt; So how likely is it that browser providers are going to refuse to impl=
ement a new and untested spec unless it mandates hard fail behavior?<br>
<br>
So I&#39;ll start with exclusion:<br>
<br>
The problem with a hard failure on exclusion is that it means that we<br>
*have* to get the DNS information before sending application data on a<br>
TLS connection, or we have to have it cached.<br>
<br>
In the event that we don&#39;t have it cached, getting the information<br>
from DNS is a problem. I ran an experiment in Chrome doing lookups for<br>
an odd DNS RRTYPE (13172) concurrently with the A lookup for HTTPS<br>
URLs. 2.5% of the time, the result came in over 100ms after we had<br>
completed the A lookup, TCP connection, TLS handshake and certificate<br>
verification! Somewhere between 0.5-1% of the time, we didn&#39;t get an<br=
>
answer within 10s (the limit of the histogram), which suggests that<br>
networks were filtering these requests.<br>
<br>
Needless to say, slowing things down to such an extent, and breaking<br>
that many people is a hard sell.<br>
<br>
Also, unless the information is DNSSEC authenticated, an attacker can<br>
spoof and DoS a site, and DNSSEC resolvers on the client are rare.<br>
(Or, rather, they would trigger hard failures for random sites until<br>
the user flushed their local browser state. Then the attacker can MITM<br>
the connection that they really wanted.)<br>
<br>
But exclusion could be very valuable! However, it seems that HSTS<br>
would be a better channel for this information. We only parse HSTS<br>
headers over HTTPS (so no DoS) and it don&#39;t have any of the above<br>
problems. Also, Firefox and we (Chrome) have both shown that we&#39;re<br>
happy to make HSTS failures hard errors.<br>
<br>
DNS solutions have the advantage of protecting the first connection,<br>
it&#39;s true. We have the preloaded list[1] to address that to some<br>
extent but it might have to be something that we trade off. (None of<br>
this is an official statement of what we will or wont do in future<br>
Chrome versions. I&#39;m still writing the code for exclusion at the<br>
moment.)<br>
<br>
Switching tacks for a second to the specifics of DANE:<br>
<br>
For exclusion we expect that some sites will wish to `pin&#39; to a CA<br>
rather than to their leaf certificate. In this case, you have to hash<br>
public keys (or, rather, SubjectPublicKeyInfos), not certificates.<br>
Certificate chains are built from a pool and the intermediate<br>
certificates that a site presents are simply inserted into the pool.<br>
Intermediate certificates exist in different versions (same public<br>
key, but different expiry times, brands etc) and the constructed chain<br>
might find a path through different versions of the intermediates.<br>
Only the public keys have to match.<br>
<br>
Even if you&#39;re pinning to a leaf certificate, hashing the public key<br=
>
means that you can renew the certificate or add extra SANs without<br>
performing an exclusion rollover.<br>
<br>
<br>
Next, Authentication (or `inclusion&#39;):<br>
<br>
The DNS has several nice properties as a PKI: scoped delegation and<br>
short lived signatures rather than problematic revocation systems. I<br>
can see why some sites would like to have a DNSSEC signed HTTPS<br>
connection. They&#39;re not going to be major sites though. It will be<br>
hard to justify breaking even a tiny number of users when CA<br>
certificates can be had for free[2].<br>
<br>
The issue here is that the DNS protocol isn&#39;t a great transport for<br>
DNSSEC information! As noted above, it looks like some networks filter<br>
out odd RRTYPES. Also, DNSSEC resolvers on the client are rare and I<br>
don&#39;t really want to drop one into a browser (although Dan Kaminsky is<=
br>
doing good work here). I&#39;d be much happier if the server did the work<b=
r>
and sent a DNSSEC chain in its certificate. DNSSEC information doesn&#39;t<=
br>
have to be carried via the DNS protocol and carrying it in the<br>
certificate chain works nicely. The code is already in Chrome (Dan<br>
demoed it at Blackhat last year), although it&#39;s currently expecting<br>
something like an early draft of CAA I think and it&#39;s off by default.<b=
r>
<br>
<br>
[1] <a href=3D"http://dev.chromium.org/sts" target=3D"_blank">http://dev.ch=
romium.org/sts</a><br>
[2] <a href=3D"https://github.com/ioerror/duraconf/blob/master/startssl/REA=
DME.markdown" target=3D"_blank">https://github.com/ioerror/duraconf/blob/ma=
ster/startssl/README.markdown</a><br>
<br>
<br>
Cheers<br>
<br>
AGL<br>
<font color=3D"#888888"><br>
--<br>
Adam Langley <a href=3D"mailto:[email-masked]">[email-masked]=
rg</a> <a href=3D"http://www.imperialviolet.org" target=3D"_blank">http://w=
ww.imperialviolet.org</a><br>
_______________________________________________<br>
dane mailing list<br>
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/dane</a><br>
</font></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a href=
=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--20cf3054a1131bdae804a086985b--

From [email-masked]  Sat Apr  9 18:59:48 2011
Date: Sat, 9 Apr 2011 22:00:22 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Zack Weinberg <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] Requirements - HTTPS

--20cf3071cebc68d57604a086d2fc
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Apr 8, 2011 at 9:48 PM, Zack Weinberg <[email-masked]>wrote:

> On Fri, Apr 8, 2011 at 6:11 PM, Phillip Hallam-Baker <[email-masked]>
> wrote:
> > ?? As a reality check here, the browser providers have taken ten years to
> > get round to doing hard fail on OCSP.
> > So how likely is it that browser providers are going to refuse to
> implement
> > a new and untested spec unless it mandates hard fail behavior?
> >
> > Has anyone actually asked a browser provider what their opinion is? I
> rather
> > suspect not.
>
> I *am* a browser implementor, and my organization had this
> conversation at some length this week (and I thought you were one of
> the people dialed in!)  I refer you to
> http://www.owlfolio.org/research/securing-the-future-net/ -- but to be
> brief, there are major differences between DANE and OCSP that make the
> case for hard-fail for DANE enormously easier to make -- provided the
> standards back us up.
> First, sites opt-in to DANE, whereas OCSP (or more precisely,
> revocation checking) is something sites have no control over.  Second,
> revocation checking ties a site's availability to the reliability of a
> service they have no control over, whereas DANE is entirely under the
> control of the site (assuming it's big enough to run its own DNS
> servers).  And finally, DANE is new, so there is no ten-year history
> of browsers *not* failing on security errors with it.
>

Well I made the same arguments when OCSP was brand new as well :-)

I thought I was on a call with the Mozilla security people. I have never
found convincing security people to do security to be a problem.

OPT-in does seem to be the strongest argument for DANE being different.

The area where I am somewhat skeptical is in the response to cases where the
DNSSEC information is stripped out. I don't think we can expect to get hard
fail for that case. And it is a case that I expect to increase rather than
decrease.

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

--20cf3071cebc68d57604a086d2fc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Fri, Apr 8, 2011 at 9:48 PM, Zack Weinberg <span dir=3D"ltr">&lt;<a href=
=3D"mailto:[email-masked]">[email-masked]</a>&gt;</span=
> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">On Fri, Apr 8, 2011 at 6:11 PM, Phillip Hallam-Baker &lt;=
<a href=3D"mailto:[email-masked]">[email-masked]</a>&gt; wrote:<br>
&gt; ?? As a reality check here, the browser providers have taken ten years=
 to<br>
&gt; get round to doing hard fail on OCSP.<br>
&gt; So how likely is it that browser providers are going to refuse to impl=
ement<br>
&gt; a new and untested spec unless it mandates hard fail behavior?<br>
&gt;<br>
&gt; Has anyone actually asked a browser provider what their opinion is? I =
rather<br>
&gt; suspect not.<br>
<br>
</div>I *am* a browser implementor, and my organization had this<br>
conversation at some length this week (and I thought you were one of<br>
the people dialed in!) =A0I refer you to<br>
<a href=3D"http://www.owlfolio.org/research/securing-the-future-net/" targe=
t=3D"_blank">http://www.owlfolio.org/research/securing-the-future-net/</a> =
-- but to be<br>
brief, there are major differences between DANE and OCSP that make the<br>
case for hard-fail for DANE enormously easier to make -- provided the<br>
standards back us up.<br>
First, sites opt-in to DANE, whereas OCSP (or more precisely,<br>
revocation checking) is something sites have no control over. =A0Second,<br=
>
revocation checking ties a site&#39;s availability to the reliability of a<=
br>
service they have no control over, whereas DANE is entirely under the<br>
control of the site (assuming it&#39;s big enough to run its own DNS<br>
servers). =A0And finally, DANE is new, so there is no ten-year history<br>
of browsers *not* failing on security errors with it.<font class=3D"Apple-s=
tyle-span" color=3D"#888888"><br></font></blockquote></div><div><br></div><=
div>Well I made the same arguments when OCSP was brand new as well :-)</div=
>
<div><br></div><div>I thought I was on a call with the Mozilla security peo=
ple. I have never found convincing security people to do security to be a p=
roblem.=A0</div><br clear=3D"all">OPT-in does seem to be the strongest argu=
ment for DANE being different. =A0<br>
<div><br></div><div><br></div><div>The area where I am somewhat skeptical i=
s in the response to cases where the DNSSEC information is stripped out. I =
don&#39;t think we can expect to get hard fail for that case. And it is a c=
ase that I expect to increase rather than decrease.</div>
<div><br></div><div><br></div><div>-- <br>Website: <a href=3D"http://hallam=
baker.com/">http://hallambaker.com/</a><br><br>
</div>

--20cf3071cebc68d57604a086d2fc--

From [email-masked]  Sat Apr  9 19:13:47 2011
From: Steve Schultze <[email-masked]>
Date: Sat, 9 Apr 2011 22:15:31 -0400
To: [email-masked]
Subject: Re: [dane] elephant use case,

On Apr 9, 2011, at 4:00 PM, Phillip Hallam-Baker wrote:
> I make no apologies for correcting incorrect claims made by others to =
this list.=20

This will be my last response on the topic because I don't want to =
contribute to the ongoing sense of DDOS-via-posts that has been long =
felt on this list.  I am simply suggesting that you exercise a bit of =
Postel's Law on yourself and take your issues with EFF or others to the =
appropriate forum.=

From [email-masked]  Sat Apr  9 19:14:59 2011
From: Warren Kumari <[email-masked]>
Date: Sat, 9 Apr 2011 22:16:40 -0400
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] Requirements - HTTPS

On Apr 9, 2011, at 10:00 PM, Phillip Hallam-Baker wrote:

> On Fri, Apr 8, 2011 at 9:48 PM, Zack Weinberg =
<[email-masked]> wrote:
> On Fri, Apr 8, 2011 at 6:11 PM, Phillip Hallam-Baker =
<[email-masked]> wrote:
> > ?? As a reality check here, the browser providers have taken ten =
years to
> > get round to doing hard fail on OCSP.
> > So how likely is it that browser providers are going to refuse to =
implement
> > a new and untested spec unless it mandates hard fail behavior?
> >
> > Has anyone actually asked a browser provider what their opinion is? =
I rather
> > suspect not.
>=20
> I *am* a browser implementor, and my organization had this
> conversation at some length this week (and I thought you were one of
> the people dialed in!)  I refer you to
> http://www.owlfolio.org/research/securing-the-future-net/ -- but to be
> brief, there are major differences between DANE and OCSP that make the
> case for hard-fail for DANE enormously easier to make -- provided the
> standards back us up.
> First, sites opt-in to DANE, whereas OCSP (or more precisely,
> revocation checking) is something sites have no control over.  Second,
> revocation checking ties a site's availability to the reliability of a
> service they have no control over, whereas DANE is entirely under the
> control of the site (assuming it's big enough to run its own DNS
> servers).  And finally, DANE is new, so there is no ten-year history
> of browsers *not* failing on security errors with it.
>=20
> Well I made the same arguments when OCSP was brand new as well :-)
>=20
> I thought I was on a call with the Mozilla security people. I have =
never found convincing security people to do security to be a problem.=20=

>=20
> OPT-in does seem to be the strongest argument for DANE being =
different. =20
>=20
>=20
> The area where I am somewhat skeptical is in the response to cases =
where the DNSSEC information is stripped out.

Um, haven't we gone through this a few times already? Stripping DNSSEC =
causes resolution to fail...

W

> I don't think we can expect to get hard fail for that case. And it is =
a case that I expect to increase rather than decrease.
>=20
>=20
> --=20
> Website: http://hallambaker.com/
>=20
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

From [email-masked]  Sat Apr  9 19:32:10 2011
Date: Sat, 9 Apr 2011 22:33:53 -0400
From: Scott Schmit <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [dane] Requirements - HTTPS

On Sat, Apr 09, 2011 at 10:16:40PM -0400, Warren Kumari wrote:
> On Apr 9, 2011, at 10:00 PM, Phillip Hallam-Baker wrote:
> > Well I made the same arguments when OCSP was brand new as well :-)
> > 
> > I thought I was on a call with the Mozilla security people. I have
> > never found convincing security people to do security to be a
> > problem. 
> > 
> > OPT-in does seem to be the strongest argument for DANE being different.  
> > 
> > 
> > The area where I am somewhat skeptical is in the response to cases
> > where the DNSSEC information is stripped out.
> 
> Um, haven't we gone through this a few times already? Stripping DNSSEC
> causes resolution to fail...

Sure, but what's the browser going to do when the A/AAAA record comes
through fine, signatures and all, but the TLSA record results get
blocked? The client might treat it as a network problem instead of a
security problem.

I think that's what Phillip is concerned about.

-- 
Scott Schmit

From [email-masked]  Sat Apr  9 19:52:24 2011
From: Warren Kumari <[email-masked]>
Date: Sat, 9 Apr 2011 22:53:22 -0400
To: Scott Schmit <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] Requirements - HTTPS

On Apr 9, 2011, at 10:33 PM, Scott Schmit wrote:

> On Sat, Apr 09, 2011 at 10:16:40PM -0400, Warren Kumari wrote:
>> On Apr 9, 2011, at 10:00 PM, Phillip Hallam-Baker wrote:
>>> Well I made the same arguments when OCSP was brand new as well :-)
>>>=20
>>> I thought I was on a call with the Mozilla security people. I have
>>> never found convincing security people to do security to be a
>>> problem.=20
>>>=20
>>> OPT-in does seem to be the strongest argument for DANE being =
different. =20
>>>=20
>>>=20
>>> The area where I am somewhat skeptical is in the response to cases
>>> where the DNSSEC information is stripped out.
>>=20
>> Um, haven't we gone through this a few times already? Stripping =
DNSSEC
>> causes resolution to fail...
>=20
> Sure, but what's the browser going to do when the A/AAAA record comes
> through fine, signatures and all, but the TLSA record results get
> blocked? The client might treat it as a network problem instead of a
> security problem.
>=20
> I think that's what Phillip is concerned about.

Ok, thanks for clarifying. If TLSA records are being stripped the client =
has evidence that someone is playing shenanigans and should panic, =
shouldn't it?

I thought that the current version of the draft had some text that =
covers this (I'm out and don't have it in front of me at the moment) =
somewhere in section 3 (near the "gets zero or more" text), or (AFAIR) =
issue #7. If not, we might need to address this more clearly...

W

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

From [email-masked]  Sun Apr 10 01:43:23 2011
Date: Wed, 06 Apr 2011 15:28:44 +0200
From: Hannes Tschofenig <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>, Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] browser UI out of scope

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3385280668_15531631
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

A few minor notes:=20

Out of scope may mean that you are not going to standardize the UI in IETF
documents. That's perfectly fine.

However, as we have learned with many security protocols there often is use=
r
interaction and in order to have the entire system being useful you also
have to **think** about the UI design.

So, think about it without mandating a specific UI design.

Ciao
Hannes

PS: A similar case from a different area: Quality of Service. While we do
not mandate a specific business model in the IETF it is useful to think
about the business incentives of the solutions we are working on.

On 4/6/11 3:08 PM, "Phillip Hallam-Baker" <[email-masked]> wrote:

> Paul is exactly right here.
>=20
> We have to cover cases where there is no UI at all. Including cases where
> there is no Human Interaction (HI) because there is no human in the loop.
>=20
> STARTTLS is a very good example. The mailing list software that supports =
this
> list has to work without any human intervention whatsoever. No human, no =
human
> interaction.
>=20
>=20
> We can approach the problem in stages. For example, we could decide to de=
sign
> a RR that is extensible so that we can first address the requirement for
> Domain Validated keys and after that is done address the requirement for
> verifying that TLS is used to secure the connection.
>=20
>=20
> On Wed, Apr 6, 2011 at 12:26 PM, Paul Hoffman <[email-masked]> wro=
te:
>> On Apr 6, 2011, at 4:56 AM, Florian Weimer wrote:
>>=20
>>> > * Paul Wouters:
>>> >
>>>> >> This working group is designing a protocol, not a web browser UI. I
>>>> >> suggest we focus on the protocol design, and not get lost in
>>>> >> padlocks, green bars, blue badges or what not.
>>> >
>>> > Oh, could you please clarify what you mean by this: Do you want to
>>> > design a protocol, without consideration for the UI side? =A0Or do you
>>> > want to design a protocol which does not require UI changes? =A0Or
>>> > something else entirely?
>>=20
>> Speaking for myself: the first. TLSA applies to TLS, not "TLS but only i=
n a
>> web browser". This is completely clear in the document. There is no
>> equivalent of a "lock icon" when a mail program downloads mail using IMA=
P or
>> POP using TLS, and this is the wrong place to say that there should be (=
more
>> than a decade later...). Similarly, many TLS-using scenarios involve cli=
ents
>> and servers with no humans watching.
>>=20
>> --Paul Hoffman
>>=20
>> _______________________________________________
>> dane mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dane
>=20
>=20

--B_3385280668_15531631
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [dane] browser UI out of scope</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>A few minor notes: <BR>
<BR>
Out of scope may mean that you are not going to standardize the UI in IETF =
documents. That's perfectly fine. <BR>
<BR>
However, as we have learned with many security protocols there often is use=
r interaction and in order to have the entire system being useful you also h=
ave to **think** about the UI design. <BR>
<BR>
So, think about it without mandating a specific UI design. <BR>
<BR>
Ciao<BR>
Hannes<BR>
<BR>
PS: A similar case from a different area: Quality of Service. While we do n=
ot mandate a specific business model in the IETF it is useful to think about=
 the business incentives of the solutions we are working on. <BR>
<BR>
On 4/6/11 3:08 PM, &quot;Phillip Hallam-Baker&quot; &lt;<a href=3D"hallam@gma=
il.com">[email-masked]</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>Paul is exactly right here.<BR>
<BR>
We have to cover cases where there is no UI at all. Including cases where t=
here is no Human Interaction (HI) because there is no human in the loop.<BR>
<BR>
STARTTLS is a very good example. The mailing list software that supports th=
is list has to work without any human intervention whatsoever. No human, no =
human interaction.<BR>
<BR>
<BR>
We can approach the problem in stages. For example, we could decide to desi=
gn a RR that is extensible so that we can first address the requirement for =
Domain Validated keys and after that is done address the requirement for ver=
ifying that TLS is used to secure the connection.<BR>
<BR>
<BR>
On Wed, Apr 6, 2011 at 12:26 PM, Paul Hoffman &lt;<a href=3D"paul.hoffman@vpn=
c.org">[email-masked]</a>&gt; wrote:<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>On Apr 6, 2011, at 4:56 AM, Florian Weimer wrote=
:<BR>
<BR>
&gt; * Paul Wouters:<BR>
&gt;<BR>
&gt;&gt; This working group is designing a protocol, not a web browser UI. =
I<BR>
&gt;&gt; suggest we focus on the protocol design, and not get lost in<BR>
&gt;&gt; padlocks, green bars, blue badges or what not.<BR>
&gt;<BR>
&gt; Oh, could you please clarify what you mean by this: Do you want to<BR>
&gt; design a protocol, without consideration for the UI side? =A0Or do you<B=
R>
&gt; want to design a protocol which does not require UI changes? =A0Or<BR>
&gt; something else entirely?<BR>
<BR>
Speaking for myself: the first. TLSA applies to TLS, not &quot;TLS but only=
 in a web browser&quot;. This is completely clear in the document. There is =
no equivalent of a &quot;lock icon&quot; when a mail program downloads mail =
using IMAP or POP using TLS, and this is the wrong place to say that there s=
hould be (more than a decade later...). Similarly, many TLS-using scenarios =
involve clients and servers with no humans watching.<BR>
<FONT COLOR=3D"#888888"><BR>
--Paul Hoffman<BR>
</FONT><BR>
_______________________________________________<BR>
dane mailing list<BR>
<a href=3D"[email-masked]">[email-masked]</a><BR>
<a href=3D"https://www.ietf.org/mailman/listinfo/dane">https://www.ietf.org/m=
ailman/listinfo/dane</a><BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">=
<SPAN STYLE=3D'font-size:11pt'><BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>

--B_3385280668_15531631--

From [email-masked]  Sun Apr 10 04:58:58 2011
Date: Sun, 10 Apr 2011 08:00:42 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: [email-masked]
Subject: Re: [dane] Requirements - HTTPS

--bcaec50166a55fd34704a08f350d
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Apr 9, 2011 at 10:33 PM, Scott Schmit <[email-masked]> wrote:

> On Sat, Apr 09, 2011 at 10:16:40PM -0400, Warren Kumari wrote:
> > On Apr 9, 2011, at 10:00 PM, Phillip Hallam-Baker wrote:
> > > Well I made the same arguments when OCSP was brand new as well :-)
> > >
> > > I thought I was on a call with the Mozilla security people. I have
> > > never found convincing security people to do security to be a
> > > problem.
> > >
> > > OPT-in does seem to be the strongest argument for DANE being different.
> > >
> > >
> > > The area where I am somewhat skeptical is in the response to cases
> > > where the DNSSEC information is stripped out.
> >
> > Um, haven't we gone through this a few times already? Stripping DNSSEC
> > causes resolution to fail...
>
> Sure, but what's the browser going to do when the A/AAAA record comes
> through fine, signatures and all, but the TLSA record results get
> blocked? The client might treat it as a network problem instead of a
> security problem.
>
> I think that's what Phillip is concerned about.
>

Yes, I can't see how anyone is going to hard fail that case.

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

--bcaec50166a55fd34704a08f350d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Sat, Apr 9, 2011 at 10:33 PM, Scott S=
chmit <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">i.grok@co=
mcast.net</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">On Sat, Apr 09, 2011 at 10:16:40PM -0400, Warren Kumari w=
rote:<br>
&gt; On Apr 9, 2011, at 10:00 PM, Phillip Hallam-Baker wrote:<br>
</div><div class=3D"im">&gt; &gt; Well I made the same arguments when OCSP =
was brand new as well :-)<br>
&gt; &gt;<br>
&gt; &gt; I thought I was on a call with the Mozilla security people. I hav=
e<br>
&gt; &gt; never found convincing security people to do security to be a<br>
&gt; &gt; problem.<br>
&gt; &gt;<br>
&gt; &gt; OPT-in does seem to be the strongest argument for DANE being diff=
erent.<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; The area where I am somewhat skeptical is in the response to case=
s<br>
&gt; &gt; where the DNSSEC information is stripped out.<br>
&gt;<br>
&gt; Um, haven&#39;t we gone through this a few times already? Stripping DN=
SSEC<br>
&gt; causes resolution to fail...<br>
<br>
</div>Sure, but what&#39;s the browser going to do when the A/AAAA record c=
omes<br>
through fine, signatures and all, but the TLSA record results get<br>
blocked? The client might treat it as a network problem instead of a<br>
security problem.<br>
<br>
I think that&#39;s what Phillip is concerned about.<br></blockquote><div><b=
r></div><div>Yes, I can&#39;t see how anyone is going to hard fail that cas=
e.</div><div><br></div><div>=A0</div></div><br>-- <br>Website: <a href=3D"h=
ttp://hallambaker.com/">http://hallambaker.com/</a><br>
<br>

--bcaec50166a55fd34704a08f350d--

From [email-masked]  Sun Apr 10 07:52:36 2011
Sender: [email-masked]
Date: Sun, 10 Apr 2011 16:54:20 +0200
From: Christopher Morrow <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dane] Use Cases Document

On Fri, Apr 8, 2011 at 7:36 PM, Kirk Hall <[email-masked]> wrote:
>
> (1) CAs review DV cert requests for =93high risk=94 organization and doma=
in
> names that are most commonly targeted in phishing and other fraudulent
> schemes, and reject those cert requests.=A0 These lists include (a) inter=
nal

<insert comodogate here>

> Does DANE contemplate that the DNS operators would also reject domain

I think, from my brief reading, the 'dns operator' here is ... the
owner of the domain. So, 'stolen-bank-of-america-credentials.com' if
owned by 'evil person' could certainly publish a cert record for the
self-signed cert on their website stealing credentials from naive
users.

how many folks really get phished/etc over ssl connections today? (not
many, if any, ssl isn't a factor in this problem space)

>
> (2) CAs also employ other anti-fraud algorithms of their own against bad =
DV

<insert comodogate here>

> Do you contemplate that DNS operators would do anything similar for
> self-signed certs?

why would they? they are putting records into their own zone... if
somone they don't know/trust can make changes to their DNSSEC signed
DNS data... they are sunk anyway.

> (3) DV certs have a clear chain of liability back to the issuing CA. The =
CAs
> today do a pretty good job in preventing high risk similar-named domains,
> like =93paypall.com=94,=A0 from getting certs for fraud and phishing purp=
oses.

<insert comodogate here>

> Under DANE, if a self-signed certificate issued in the name of =93paypall=
.com=94
> is accepted by a DNS operator and is used in phishing attacks, who would =
be

the person that owns paypall.com can certainly make a self-signed
cert... and put the appropriate record into the dns zone they own, and
sign it with the key they have... this isn't significantly different
than where we are today.

> (5) Bad certs can be revoked, and the industry is working very hard right
> now on improving the revocation process.

by completely sidestepping it? (let's hardcode certs into binaries,
because .. oscp is an admitted failure)

> If there is a =93bad=94 self-signed cert associated with a domain by a DN=
S
> operator and/or a DNS operator receives a report of fraud or phishing
> associated with a domain, will DANE have a way to remove, revoke, or
> otherwise flag the cert as =93bad=94?

sure, remove the record from dns (in the zone that publishes it)

-chris

From [email-masked]  Sun Apr 10 10:11:02 2011
From: James Cloos <[email-masked]>
To: Adam Langley <[email-masked]>
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC
Copyright: Copyright 2011 James Cloos
OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
Date: Sun, 10 Apr 2011 13:09:46 -0400
Lines: 18
Cc: [email-masked]
Subject: Re: [dane] A browser's myopic view

Apps probably SHOULD first confirm whether their dns path support dnssec
validation before even considering doing dane lookups.

I run a validating recursive dns server locally (really all dnssec users
should run their own validating recursor; at least on the local lan if
not on the box; else there is no real security) and that makes all
validatable lookups slower.

(A classic example is weather.noaa.gov.  With a cold cache that normally
takes between 90 and 120 seconds.  And you get a validated CNAME which
points to an unvalidated pair of A RRs. :-/ )

Given how long it often takes to validate the A and AAAA RRs, it really
shouldn't take significant extra time also to validate a DTLS RR.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

From [email-masked]  Sun Apr 10 10:26:56 2011
From: James Cloos <[email-masked]>
To: [email-masked]
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC
Copyright: Copyright 2011 James Cloos
OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
Date: Sun, 10 Apr 2011 13:22:29 -0400
Lines: 19
Subject: [dane] Securing by-address IRIs

There are a number of protocols where it is common to specify the remote
side by ip address rather than by a name.  Both sides are often on the
same lan, but the is not universal.

It seems like it would be useful for us also to provide a trust anchor
mechanism for that usage pattern.

But how?

Should the lookup be, eg, _prefix.3.2.1.10.in-addr.arpa. DTLS?  (For
whatever we decide on for prefixing.)  And the like for ipv6?

Or, given that the practice at least originated with a desire to
elimiate dns-induced latency and points of failure, is that style
of addressing out of scope of dns-anchored trust?

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

From [email-masked]  Sun Apr 10 11:53:58 2011
From: Jakob Schlyter <[email-masked]>
Date: Sun, 10 Apr 2011 20:53:46 +0200
To: James Cloos <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] Securing by-address IRIs

On 10 apr 2011, at 19.22, James Cloos wrote:

> Should the lookup be, eg, _prefix.3.2.1.10.in-addr.arpa. DTLS?  (For
> whatever we decide on for prefixing.)  And the like for ipv6?

sure, why not?

(btw, the prefix was issue #19 and has been closed - the format is =
_port._transport.fqdn)

	jakob

--=20
Jakob Schlyter
Kirei AB - www.kirei.se

From [email-masked]  Sun Apr 10 15:29:03 2011
Date: Sun, 10 Apr 2011 18:28:59 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Paul Hoffman <[email-masked]>, [email-masked]
Subject: [dane] Section 2.2 Certificate format question

In section 2.2 it states:

 	The "certificate for association".  This is the bytes containing
 	the full certificate or the hash of the associated certificate
 	(that is, the certificate or the hash of the certificate itself,
 	not of the TLS ASN.1Cert object).

For the full certificate, am I right that this format is the base64
encoding of the DER encoded certificate?  If so, can the section be
updated to state so?

Paul

From [email-masked]  Sun Apr 10 15:50:37 2011
From: Steve Schultze <[email-masked]>
Date: Sun, 10 Apr 2011 18:50:33 -0400
To: [email-masked]
Subject: Re: [dane] Requirements - HTTPS

On Apr 9, 2011, at 10:53 PM, Warren Kumari wrote:
> On Apr 9, 2011, at 10:33 PM, Scott Schmit wrote:
>> On Sat, Apr 09, 2011 at 10:16:40PM -0400, Warren Kumari wrote:
>>> On Apr 9, 2011, at 10:00 PM, Phillip Hallam-Baker wrote:
>>>> The area where I am somewhat skeptical is in the response to cases
>>>> where the DNSSEC information is stripped out.
>>>=20
>>> Um, haven't we gone through this a few times already? Stripping =
DNSSEC
>>> causes resolution to fail...
>>=20
>> Sure, but what's the browser going to do when the A/AAAA record comes
>> through fine, signatures and all, but the TLSA record results get
>> blocked? The client might treat it as a network problem instead of a
>> security problem.
>>=20
>> I think that's what Phillip is concerned about.
>=20
> Ok, thanks for clarifying. If TLSA records are being stripped the =
client has evidence that someone is playing shenanigans and should =
panic, shouldn't it?

Yes, I think it should.  Otherwise we introduce a downgrade attack =
vector (issue #6).=20

> I thought that the current version of the draft had some text that =
covers this (I'm out and don't have it in front of me at the moment) =
somewhere in section 3 (near the "gets zero or more" text), or (AFAIR) =
issue #7. If not, we might need to address this more clearly...

Issue #7 doesn't directly address this.

The text in section 3 also does not clearly address this.  I'd like to =
suggest again that we consider a version of Matt's proposed text for =
Section 3.  It clearly outlines the different responses and results.  =
Back in January, Paul suggested that we wait on deciding this, but =
perhaps now is a good time.

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

Specifically, I believe that this sentence is Matt's proposal would =
address the case at hand:

"If any query cannot be completed or gives a "bogus" result as described
in RFC 4033 section 5, validation MUST fail and the client MUST abort
the TLS handshake (if it has been started) with a "TBD" error."

In this case, I think the described scenario is a "query that cannot be =
completed" because as described there is no positive or negative =
response for the TLSA query.=

From [email-masked]  Sun Apr 10 16:03:22 2011
From: Paul Hoffman <[email-masked]>
Date: Sun, 10 Apr 2011 16:03:19 -0700
To: Paul Wouters <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] Section 2.2 Certificate format question

On Apr 10, 2011, at 3:28 PM, Paul Wouters wrote:

>=20
> In section 2.2 it states:
>=20
> 	The "certificate for association".  This is the bytes containing
> 	the full certificate or the hash of the associated certificate
> 	(that is, the certificate or the hash of the certificate itself,
> 	not of the TLS ASN.1Cert object).
>=20
> For the full certificate, am I right that this format is the base64
> encoding of the DER encoded certificate?  If so, can the section be
> updated to state so?

Let's be careful here. The bytes are not base64-encoded: the =
representation of those bytes are encoded in the record. The =
"certificate for association" is just the bytes themselves.

As for the bytes of a PKIX certificate being DER encoded, that's already =
defined in the PKIX spec. If we put that here and someone adds a =
different certificate for association, such as a bare key (cough cough), =
then that bare key would need to be DER encoded; that may not be what =
the people writing those specs want. It is probably better to let the =
format of the bytes be defined in the other specs.

--Paul Hoffman

From [email-masked]  Sun Apr 10 17:21:29 2011
From: "Richard L. Barnes" <[email-masked]>
Date: Sun, 10 Apr 2011 20:21:23 -0400
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] Section 2.2 Certificate format question

Also, in the presentation format (Section 2.4), the place where it =
*might* make sense to Base64-encode, it says that the certificate is =
"presented in hex".  So, raw hex bytes, not Base64.
<http://tools.ietf.org/html/draft-ietf-dane-protocol-06#section-2.4>
--Richard

On Apr 10, 2011, at 7:03 PM, Paul Hoffman wrote:

> On Apr 10, 2011, at 3:28 PM, Paul Wouters wrote:
>=20
>>=20
>> In section 2.2 it states:
>>=20
>> 	The "certificate for association".  This is the bytes containing
>> 	the full certificate or the hash of the associated certificate
>> 	(that is, the certificate or the hash of the certificate itself,
>> 	not of the TLS ASN.1Cert object).
>>=20
>> For the full certificate, am I right that this format is the base64
>> encoding of the DER encoded certificate?  If so, can the section be
>> updated to state so?
>=20
> Let's be careful here. The bytes are not base64-encoded: the =
representation of those bytes are encoded in the record. The =
"certificate for association" is just the bytes themselves.
>=20
> As for the bytes of a PKIX certificate being DER encoded, that's =
already defined in the PKIX spec. If we put that here and someone adds a =
different certificate for association, such as a bare key (cough cough), =
then that bare key would need to be DER encoded; that may not be what =
the people writing those specs want. It is probably better to let the =
format of the bytes be defined in the other specs.
>=20
> --Paul Hoffman
>=20
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

From [email-masked]  Sun Apr 10 18:10:39 2011
From: Paul Hoffman <[email-masked]>
Date: Sun, 10 Apr 2011 17:58:04 -0700
To: "Richard L. Barnes" <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] Section 2.2 Certificate format question

On Apr 10, 2011, at 5:21 PM, Richard L. Barnes wrote:

> Also, in the presentation format (Section 2.4), the place where it =
*might* make sense to Base64-encode, it says that the certificate is =
"presented in hex".  So, raw hex bytes, not Base64.
> <http://tools.ietf.org/html/draft-ietf-dane-protocol-06#section-2.4>
>=20

Whoops, Richard is right and my last response was wrong. There is no =
base64 encoding in the current spec. Sorry for that brain lapse.

--Paul Hoffman

From [email-masked]  Mon Apr 11 10:19:03 2011
Date: Mon, 11 Apr 2011 13:10:28 -0400
To: Ben Laurie <[email-masked]>
From: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

At 11:14 AM +0100 4/8/11, Ben Laurie wrote:
>...
>  >
>>  It's not sudden :-). A self-signed cert is a CA cert, by definition (see
>>  the cites to RFC 5280 in Paul's I-D. The TLS spec talks in terms of an
>>  "end entity's cert" as representing a a server (or client). From a PKI
>>  perspective, the cert that represents a server or client MUST be an
>>  EE cert, an thus cannot be self-signed.  The fact that many implementations
>>  violate IETF PKI standards in this regard, is unfortunate, but it is not
>>  a basis for issuing a new IETF stanbdard that codifies this behavior.
>
>Isn't it? What is the argument against allowing a self-signed EE cert,
>other than spec lawyering?

You call it spec lawyering; I call it not having WG A contradict the
standards developed by WG B :-).  We've adhered to that model for a long
time. But, folks are free to ask the cognizant ADs.

Steve

From [email-masked]  Mon Apr 11 10:19:04 2011
Date: Mon, 11 Apr 2011 13:13:53 -0400
To: Ben Laurie <[email-masked]>
From: Stephen Kent <[email-masked]>
Cc: Paul Hoffman <[email-masked]>, [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

At 1:46 PM +0100 4/8/11, Ben Laurie wrote:
>On 8 April 2011 13:33, Paul Hoffman <[email-masked]> wrote:
>>  I note, again, that this has *nothing* to do with use cases or 
>>requirements. Having said that...
>
>I've already stated my requirement (that self-signed certs should be usable).
>

and they are, as CA certs :-).

Steve

From [email-masked]  Mon Apr 11 10:21:58 2011
Date: Mon, 11 Apr 2011 13:21:38 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

At 4:58 AM +0200 4/8/11, Martin Rex wrote:
>Stephen Kent wrote:
>>
>>  James Cloos wrote:
>>  >
>>  >EE certs in the rr is in all of the drafts, was the original target, is
>>  >easy to understand and explain, and I've read more consensus for than
>>  >against on the list.
>>  >
>>  >Why the sudden backlash against?
>>
>>  It's not sudden :-). A self-signed cert is a CA cert, by definition (see
>>  the cites to RFC 5280 in Paul's I-D.
>
>RFC 5280 is about X.509v3 certs _ONLY_.

agreed.

>There is NO problem creating X.509v1 End-Entity certs that are self-signed.
>And there is no problem using any of these with implementations of
>SSLv3 and TLSv1.0.

you have provided enough examples to convince me of that :-).

>SSLv3 predates IETF PKIX standards, and TLSv1.0 is related to
>rfc-2459 rather than rfc-5280 -- but implementations of TLSv1.0
>were often shipped before publication of TLSv1.0 (rfc-2246) and
>the original PKIX certificate profile (rfc-2459).

so?

>For safety, it would be sensible to ALWAYS treat X.509v1 certs as
>EndEntity certs (i.e. never accept them as signer of other certs).
>Our TLS implementation had done this initially, but we had a customer
>that had obtained server certs issued under a VeriSign X.509v1 CA cert
>(as late as 2006!), so I had to make our OEM implementation tolerate this.

The fact that v1 certs contained no mechanism to distinguish between
an EE cert and a CA cert was a major vulnerability, one that has been
exploited in the browser context. I doubt that the IESG will approve
an RFC that calls for supporting v1 certs at this time.

Steve

From [email-masked]  Mon Apr 11 10:45:52 2011
Date: Mon, 11 Apr 2011 13:22:07 -0400
To: James Cloos <[email-masked]>
From: Stephen Kent <[email-masked]>
Cc: Paul Hoffman <[email-masked]>, [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

At 6:22 PM -0400 4/5/11, James Cloos wrote:
>...
>
>For those of us who understand how it works and for those who employ
>someone who understands how it works, case 3 has some benefits.
>
>But more most people case 4 is better.

If, as some have said, many (most?) folks use a simple script to 
invoke OpenSSL to generate a self-signed cert, can't we provide a new 
script to address this
issue?

Steve

From [email-masked]  Mon Apr 11 11:50:00 2011
Sender: [email-masked]
Date: Mon, 11 Apr 2011 20:49:57 +0200
From: Christopher Morrow <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dane] Use Cases Document

On Mon, Apr 11, 2011 at 6:21 PM, Kirk Hall <[email-masked]> wrote:
> Chris =96 thanks for your response.=A0 A few comments.
>
>
>
> 1.=A0 What you call =93comodogate=94 was an extreme rarity for the CA ind=
ustry,
> and shouldn=92t have happened.=A0 If we have the correct story, someone o=
utside

absolutely it shouldn't have happened. it's probably the 3rd or fourth
thing that 'shouldn't have happened' to comodo... related to security
and the security of their downstream dependents.

> the external RA was able to gain access to the RA=92s cert issuance syste=
m
> remotely, and then was able to use the RA=92s system to access the CA=92s=
 cert
> issuance system remotely and order issuance of the fake certs.=A0 I=92m n=
ot
> aware of anything like this ever happening to a CA before, and it would h=
ave
> been easy to prevent this breach with basic systems security.

I'm not sure you'd (*or anyone would) know if this was going on
though. it only became 'known' because the alleged/admitted third
party bragged about his actions, in detail. It's interesting that
comodo was supposed (as i understand it) to be checking to be sure
that the didn't re-issue an already known cert to a third-party NOT
the owner of the trademark/domain/etc. It's fairly telling that we
find out about this via the 'hacker' making it very publicly known.
How many times did this happen before from the same RA? or the same
set of dependent RAs?

At this point, anyone depending on this being the only case of this..
is living in a fantasy land.

> In my mind it=92s a mistake to interpret the incident as demonstrating ma=
jor
> vulnerability for the CA industry as a whole.=A0 As an example, if one da=
y
> Wells Fargo Bank=92s international wire service system is breached and
> accessed remotely by an intruder, and the intruder then sends unauthorize=
d
> wire transfers to Nigerian bank accounts before being caught, that would =
be
> a fairly uninteresting case of basic data system security breach, and wou=
ld

different and not related issues above skipped.

> not imply that the entire banking system for international wire transfers
> was in jeopardy or need of overhaul.=A0 Likewise, if a DNS operator=92s s=
ystem
> is breached remotely in a similar fashion, I assume an intruder could pla=
y
> games with the self-signed certificates that have been associated with a

I don't think that's a fair assumption at all. Ideally, in any sane
dnssec secured system the 'domain owner' has the private keys required
to sign his/her/their zone data. If I host my zone on your server(s)
and you are compromised, worst case my zone goes invalid and .. .I
scramble for a provider who's less compromised.

> domain under the DANE proposal =96 but that wouldn=92t weaken DANE.=A0 So=
 in all
> cases, basic security systems are essential.

The basic problem as i see it with the in-place cert/ca system is that
my security (as a customer and a server) is reliant upon a mess of
folks with whom I have very little faith or ability-to-have-faith in.
There exist today systems that will man-in-the-middle SSL connections
making certs appear (that are valid because they are signed by an
in-browser/client ca-store) and be invisible to both sides of the
connection. (see mallory proxy, for a software-only solution). There
are folks that use systems like this to degrade the security of
clients/servers in the field, today.

I don't think we want this situation to exist, I think we want to aim
for the best possible security position for our customers (clients and
servers). This means we need another method than the current CA-store
system to verify that a certificate is valid, one not dependent upon
the CA-store/chain.

> 2.=A0 From your comments it seems you view the association of certs
> (self-signed or from a CA) with a domain under the DANE proposal as
> completely agnostic and mechanical =96 the DNS operator should accept
> literally any cert offered by the domain owner =96 so that DANE a
> technological standard with no implications for =93trust=94 as generally
> associated with digital certificates today.

My feeling is that folks do today, and will tomorrow, own their own
DNS infrastructure. In what I think your terminology is: "They are
both the DOMAIN OWNER and the DNS OPERATOR". Today some folks (domain
owners) outsource their DNS services to third-parties (dns operators),
it's not clear that they need to (or even are) giving their dnssec key
materials to the dns operator though.

Additionally, I'd bet that in many cases the dns operators have a
business relationship (ongoing, monthly recurring costs) with the
domain owners, they ought to be able to tell if the person asking for
a domain to exist own the domain. (they got the NS records pointed
from SLD -> 3rdLD afterall)

> That=92s fine if everyone understands that.=A0 However, it then raises th=
e
> question of utility of the DANE proposal once implemented.=A0 If a known
> phishing domain (see the APWG solutions list at
> http://www.antiphishing.org/solutions.html), or a likely new fraudster wh=
o
> registers an available look-alike domain such as
> your-account-bankofamerica.com or google-accounts.com can then attach a
> self-signed cert to the domain at the DNS level (including fake Organizat=
ion
> information, etc. inserted inside the self-signed cert), and if consumers
> visiting that domain are automatically put into secure encrypted mode wit=
h
> the site with no checking against an OCSP or CRL =85=A0 and if that secur=
e
> domain is given the same favorable UI or other treatment by browsers and
> applications indicating secure mode or domain confirmation as for all oth=
er
> sites =85=A0 then won=92t the public come to see the DANE solution as ins=
ecure and
> untrustworthy?

DANE is not here to help/hurt phishers. SSL doesn't factor into
phishing at all... please stop conflating phishing and SSL/TLS.

DANE is about knowing that your TLS connection to a service is to the
service it intended to connect to... www.bobs-balloons.com on port 443
sent me a cert, I can verify that the destination server's certificate
is the one bobs-balloons created/signed/installed.

> Meaning if there is no way under DANE for a consumer to distinguish betwe=
en
> legitimate sites associated with a self-signed cert and fraudulent sites
> (i.e., those domains already tagged for phishing, or look-alike domains t=
hat
> would be rejected by a CA for a DV cert), what advantage does a consumer

like the one signed by the compromised RA in the comodogate incident?
yea... that fix action worked out well there. Again, phishing isn't in
the purview of DANE, you can't solve the phishing problem... in the
last 15+ years the existing oligarchy of CA folk haven't solved it
(because the two items are not related).

> gain from DANE?=A0 Why not just use self-signed certs today, and ask the
> browsers to stop showing the =93Warning =96 cert comes from an unknown /
> untrusted root=94 display?

this doesn't show the user that the cert delivered over the wire to
the client was in fact the cert that the service-owner installed. the
current CA system doesn't do this either, DANE has a better hope of
doing this, i think.

> 3.=A0 There is a potential solution to this problem.=A0 I know some on th=
is list
> want to get away from having to use a CA, and there=92s a way to do that =
and
> keep DANE useful.

s/'get away from having a CA'/'get away from the trust dependency upon CAs'=
/

less places for risk to inject themselves.

> On some earlier draft list of DANE specifications, I think two basic DANE
> cert categories were proposed: 1=3Dself signed, and 2=3DCA issued.=A0 Why=
 not add
> a third specification: 3=3Dself signed/fraud checked.

because 'fraud checked' means nothing wrt the purpose of DANE?
True/False: "this certificate presented to me is the one the service
owner installed"

> Category =933=94 would be for self-signed certs that have been run throug=
h
> anti-fraud checking by an independent third party like what is done today
> for DV certs (e.g., compare the domain against APWG phishing lists, rejec=
t
> look-alike domains like paypall.com unless the real paypal.com proves
> ownership).=A0 The checking could be done by the DNS operators or someone=
 else
> independent of the domain owner following an industry-standard set of
> anti-fraud criteria =96 but the certs would NOT have to be chained to a C=
A.
> Once checked, the self-signed certs would get a favorable flag (=933=94) =
so that
> browsers, applications, and consumers could choose to trust them, but not
> trust self-signed certs that were not checked against fraud (Category =93=
1=94
> certs).=A0 Or, the user could choose to trust all kinds of certs if the u=
ser
> is not concerned about dealing with fraudulent domains.

it occurs to me that you ought to take this portion of the discussion
to the DNS heirarchy folks (ICANN and their downstream dependents for
DNS zone purchase) The problem you seek to solve has nothing to do
with certificates, and everything to do with DNS.

If you can't sign up for the domain: bank-of-america-auth-stealers.com
... you can't put the DANE cert into the zone.

> the padlock, etc.).=A0 Those DNS operators would no doubt be embarrassed =
to be
> giving known and reported phishing domains and look-alike domains the sam=
e
> DANE treatment as legitimate domains.

this doesn't seem to be a factor today.

> To be clear, under this proposal for DANE implementation ALL self-signed
> certs would be accepted for association with a domain, but they would be
> marked as either being checked using anti-fraud algorithms, or not being

you seem to be backdooring into the UI discussion, which isn't in
scope and isn't relevant.

> checked, so that later applications and consumers could decide if they
> wanted to trust all self-signed certs, or only a subset.=A0 Differentiati=
ng
> certs in this way would mean that DANE is actually useful, and might be

DANE is useful as soon as I can tell that the certificate I'm
presented with is in fact the certificate that the service owner
installed for their service.

> Do you view this as a feasible solution?=A0 Should we add this to the dra=
ft
> specifications?

I think walking down the discussion of fraud and phishing is entirely
the wrong path for DANE to go. DANE, nor CA's really, can not hope to
solve the fraud/phishing problem.

For grins: (http urls sent in spam today so far)
morrowc@fire:/prod/archive/2011/04$ grep http:// 11/*.txt | wc -l
392951

HTTPS
morrowc@fire:/prod/archive/2011/04$ grep https:// 11/*.txt | wc -l
65
(oddly mostly for: sears.r4sys.net which ends up bouncing properly through =
to:
Location: http://www.sears.com/shc/s/v_10153_12605_Tools?lid=3Dtool_header&=
rioptype=3DSC&sid=3DIOx20110411SRSBAUALTSA2MMS80&eml=3D52379066&ruid=3D1003=
337
[following]
   so this is incidental https in something, not a phishing attempt)

I make the ssl-use-in-phishing at a number small enough that DANE
again shouldn't target this as a goal to solve.

-Chris

(in a related qestion, why doesn't affirmtrust use SSL on their forms?
http://www.affirmtrust.com/free-ssl-sign-up.html)

> On Sun, Apr 10, 2011 at 7:54 AM, Christopher Morrow
> <[email-masked]> wrote:
>>
>> On Fri, Apr 8, 2011 at 7:36 PM, Kirk Hall <[email-masked]> wrote:
>> >
>> > (1) CAs review DV cert requests for =93high risk=94 organization and d=
omain
>> > names that are most commonly targeted in phishing and other fraudulent
>> > schemes, and reject those cert requests.=A0 These lists include (a)
>> > internal
>>
>> <insert comodogate here>
>>
>> > Does DANE contemplate that the DNS operators would also reject domain
>>
>> I think, from my brief reading, the 'dns operator' here is ... the
>> owner of the domain. So, 'stolen-bank-of-america-credentials.com' if
>> owned by 'evil person' could certainly publish a cert record for the
>> self-signed cert on their website stealing credentials from naive
>> users.
>>
>> how many folks really get phished/etc over ssl connections today? (not
>> many, if any, ssl isn't a factor in this problem space)
>>
>> >
>> > (2) CAs also employ other anti-fraud algorithms of their own against b=
ad
>> > DV
>>
>> <insert comodogate here>
>>
>> > Do you contemplate that DNS operators would do anything similar for
>> > self-signed certs?
>>
>> why would they? they are putting records into their own zone... if
>> somone they don't know/trust can make changes to their DNSSEC signed
>> DNS data... they are sunk anyway.
>>
>> > (3) DV certs have a clear chain of liability back to the issuing CA. T=
he
>> > CAs
>> > today do a pretty good job in preventing high risk similar-named
>> > domains,
>> > like =93paypall.com=94,=A0 from getting certs for fraud and phishing p=
urposes.
>>
>> <insert comodogate here>
>>
>> > Under DANE, if a self-signed certificate issued in the name of
>> > =93paypall.com=94
>> > is accepted by a DNS operator and is used in phishing attacks, who wou=
ld
>> > be
>>
>> the person that owns paypall.com can certainly make a self-signed
>> cert... and put the appropriate record into the dns zone they own, and
>> sign it with the key they have... this isn't significantly different
>> than where we are today.
>>
>> > (5) Bad certs can be revoked, and the industry is working very hard
>> > right
>> > now on improving the revocation process.
>>
>> by completely sidestepping it? (let's hardcode certs into binaries,
>> because .. oscp is an admitted failure)
>>
>> > If there is a =93bad=94 self-signed cert associated with a domain by a=
 DNS
>> > operator and/or a DNS operator receives a report of fraud or phishing
>> > associated with a domain, will DANE have a way to remove, revoke, or
>> > otherwise flag the cert as =93bad=94?
>>
>> sure, remove the record from dns (in the zone that publishes it)
>>
>> -chris
>
>

From [email-masked]  Mon Apr 11 11:55:31 2011
Date: Mon, 11 Apr 2011 14:55:27 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Stephen Kent <[email-masked]>
Cc: Paul Hoffman <[email-masked]>, [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

--20cf3071cebc7b1dae04a0a91ed5
Content-Type: text/plain; charset=ISO-8859-1

We don't seem capable of deferring discussion on the details of
implementation until after the use cases[1]. So writing a script is quite
probably too much to expect.

This problem is very easily solved: DANE needs say nothing about the issue
at all. Just cite PKIX and move on.

Everyone will get the outcome they care about. DANE will be compatible with
PKIX and the code will recognize self-signed EE certs just like every other
bit of SSL/TLS infrastructure does.

[1] No, calling a demand for a very specific implementation detail a 'use
case' does not make it one. A use case would be 'Alice wants to use the same
tool to generate her certs' or 'Alice wants to be able to credential the
certs already used on the server' or 'Alice wants the web server to work for
Bob and Carol who have old and new browsers respectively.

There are plenty of ways that this could be expressed as a use case, the
ones adopted are not use cases.

On Mon, Apr 11, 2011 at 1:22 PM, Stephen Kent <[email-masked]> wrote:

> At 6:22 PM -0400 4/5/11, James Cloos wrote:
>
>> ...
>>
>>
>> For those of us who understand how it works and for those who employ
>> someone who understands how it works, case 3 has some benefits.
>>
>> But more most people case 4 is better.
>>
>
> If, as some have said, many (most?) folks use a simple script to invoke
> OpenSSL to generate a self-signed cert, can't we provide a new script to
> address this
> issue?
>
> Steve
>
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

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

--20cf3071cebc7b1dae04a0a91ed5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

We don&#39;t seem capable of deferring discussion on the details of impleme=
ntation until after the use cases[1]. So writing a script is quite probably=
 too much to expect.<div><br></div><div>This problem is very easily solved:=
 DANE needs say nothing about the issue at all. Just cite PKIX and move on.=
</div>
<div><br></div><div><br></div><div>Everyone will get the outcome they care =
about. DANE will be compatible with PKIX and the code will recognize self-s=
igned EE certs just like every other bit of SSL/TLS infrastructure does.</d=
iv>
<div><br></div><div><br></div><div>[1] No, calling a demand for a very spec=
ific implementation detail a &#39;use case&#39; does not make it one. A use=
 case would be &#39;Alice wants to use the same tool to generate her certs&=
#39; or &#39;Alice wants to be able to credential the certs already used on=
 the server&#39; or &#39;Alice wants the web server to work for Bob and Car=
ol who have old and new browsers respectively.</div>
<div><br></div><div>There are plenty of ways that this could be expressed a=
s a use case, the ones adopted are not use cases.</div><div><br><div class=
=3D"gmail_quote">On Mon, Apr 11, 2011 at 1:22 PM, Stephen Kent <span dir=3D=
"ltr">&lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote=
:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;">At 6:22 PM -0400 4/5/11, James Cloos wrote:=
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
...<div class=3D"im"><br>
<br>
For those of us who understand how it works and for those who employ<br>
someone who understands how it works, case 3 has some benefits.<br>
<br>
But more most people case 4 is better.<br>
</div></blockquote>
<br>
If, as some have said, many (most?) folks use a simple script to invoke Ope=
nSSL to generate a self-signed cert, can&#39;t we provide a new script to a=
ddress this<br>
issue?<br>
<br>
Steve<div><div></div><div class=3D"h5"><br>
_______________________________________________<br>
dane mailing list<br>
<a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/dane</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--20cf3071cebc7b1dae04a0a91ed5--

From [email-masked]  Mon Apr 11 12:11:49 2011
Date: Mon, 11 Apr 2011 15:11:48 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Christopher Morrow <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [dane] Use Cases Document

--20cf3054a113e415c604a0a95832
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Apr 11, 2011 at 2:49 PM, Christopher Morrow <[email-masked]
> wrote:

>
> I'm not sure you'd (*or anyone would) know if this was going on
> though. it only became 'known' because the alleged/admitted third
> party bragged about his actions, in detail.

No, this is an untrue accusation and must be withdrawn.

The notification of the RA breach incident was made through the normal
process and the timing of the release of the information to the public was
gated on the time taken to roll patches by the major browser providers.

And I am somewhat sick of this approach where one side in a dispute thinks
that it is OK to make unfounded accusations, engage in political hyperbole
(-gate) and rely on false claims while it is somehow improper for the side
they are attacking to make a rebuttal.

Either both sides of this argument are off topic, or both are.

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

--20cf3054a113e415c604a0a95832
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Mon, Apr 11, 2011 at 2:49 PM, Christo=
pher Morrow <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]=
">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex;">
<br>
I&#39;m not sure you&#39;d (*or anyone would) know if this was going on<br>
though. it only became &#39;known&#39; because the alleged/admitted third<b=
r>
party bragged about his actions, in detail.</blockquote><div><br></div><div=
>No, this is an untrue accusation and must be withdrawn.</div><div><br></di=
v><div>The notification of the RA breach incident was made through the norm=
al process and the timing of the release of the information to the public w=
as gated on the time taken to roll patches by the major browser providers.=
=A0</div>
<div><br></div><div><br></div><div><br></div><div>And I am somewhat sick of=
 this approach where one side in a dispute thinks that it is OK to make unf=
ounded accusations, engage in political hyperbole (-gate) and rely on false=
 claims while it is somehow improper for the side they are attacking to mak=
e a rebuttal.</div>
<div><br></div><div>Either both sides of this argument are off topic, or bo=
th are.</div><div><br></div><div><br></div></div><br>-- <br>Website: <a hre=
f=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>

--20cf3054a113e415c604a0a95832--

From [email-masked]  Mon Apr 11 15:25:23 2011
Sender: [email-masked]
Date: Mon, 11 Apr 2011 21:49:33 +0200
From: Christopher Morrow <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [dane] Use Cases Document

On Mon, Apr 11, 2011 at 9:11 PM, Phillip Hallam-Baker <[email-masked]> wrote:
>
>
> On Mon, Apr 11, 2011 at 2:49 PM, Christopher Morrow
> <[email-masked]> wrote:
>>
>> I'm not sure you'd (*or anyone would) know if this was going on
>> though. it only became 'known' because the alleged/admitted third
>> party bragged about his actions, in detail.
>
> No, this is an untrue accusation and must be withdrawn.

pardon? the young man who put out the info did so long before the
browser patches arrived. he even had the private keys and certs, I
believe, available before patches hit for browsers.

> And I am somewhat sick of this approach where one side in a dispute thinks
> that it is OK to make unfounded accusations, engage in political hyperbole
> (-gate) and rely on false claims while it is somehow improper for the side

I could refer to verizonbusiness's method of sending downstream folks
signing certs from their root... though the meta point is that you
can't trust the CA infrastructure today, if you are a client or a
server. (comodo gave out certs signed to not-the-proper-owner(s),
verizonbusiness/cybertrust/b-trusted/baltimore-security released a
signing cert to a downstream who can now sign a cert for anyone)

it doesn't really matter, the whole kit and kaboodle is out of scope
for what we ought to be doing with DANE.

> Either both sides of this argument are off topic, or both are.

I would say that the only item on topic is how to get to the 2 parties
involved in a TLS conversation assurance that they are talking to the
right endpoints, and that their conversation is confidential.

thanks!
-chris

From [email-masked]  Mon Apr 11 15:30:42 2011
Date: Mon, 11 Apr 2011 15:47:59 -0400
To: Stephen Farrell <[email-masked]>
From: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

--============_-909570926==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 2:49 PM +0100 4/8/11, Stephen Farrell wrote:
>...
>
>5280 is IMO properly silent on how EEs might use self-signed
>certs. (Or if not, I've forgotten what it says on that;-)

I'll help with a few cites from 5280:

>3.2:
>
>This specification covers two classes of certificates: CA 
>certificates and end entity certificates.  CA certificates may be 
>further divided into three classes: cross-certificates, self-issued 
>certificates, and self-signed certificates.  Cross-certificates are 
>CA certificates in which the issuer and subject are different 
>entities.  Cross-certificates describe a trust relationship between 
>the two CAs.  Self-issued certificates are CA certificates in which 
>the issuer and subject are the same entity.  Self-issued 
>certificates are generated to support changes in policy or 
>operations.  Self-signed certificates are self-issued certificates 
>where the digital signature may be verified by the public key bound 
>into the certificate.  Self-signed certificates are used to convey a 
>public key for use to begin certification paths.  End entity 
>certificates are issued to subjects that are not authorized to issue 
>certificates.

This text says that a self-signed certificate is a CA certificate, 
period. The last sentence says that an EE certificate cannot be used 
to verify a signature on another certificate, and thus it is not a CA 
certificate, and thus, not self-signed.

>4.2.1.1 (AKI)
>
>The keyIdentifier field of the authorityKeyIdentifier extension MUST 
>be included in all certificates generated by conforming CAs to 
>facilitate certification path construction.  There is one exception; 
>where a CA distributes its public key in the form of a "self-signed" 
>certificate, the authority key identifier MAY be omitted.

This text says further reiterates the notion that a self-signed 
certificate is not an EE certificate. Note that in this text the 
exception discusses the context where a CA distributes its public key 
via a self-signed certificate, i.e., where the self-signed 
certificate is used as a container to distribute a trust anchor. This 
is the relevant case for DANE.

>4.2.1.3 (KU)
>
>The keyCertSign bit is asserted when the subject public key is  used 
>for verifying signatures on public key certificates.  If the 
>keyCertSign bit is asserted, then the cA bit in the basic 
>constraints extension (Section 4.2.1.9) MUST also be asserted.
>
>If the keyUsage extension is present, then the subject public key 
>MUST NOT be used to verify signatures on certificates or CRLs unless 
>the corresponding keyCertSign or cRLSign bit is set.

This text says that a valid CA certificate MUST contain the basic 
constraints extension with the CA flag set TRUE, thus 5280 requires 
CA certificates to be v3. It also establishes required values for key 
usage extension flags if the certificate is to be used to verify 
signatures on other certificates, i.e., if the certificate is to be 
used as a CA certificate.

>4.2.1.9 (Basic Constraints):
>
>The basic constraints extension identifies whether the subject of 
>the certificate is a CA and the maximum depth of valid certification 
>paths that include this certificate.
>
>Conforming CAs MUST include this extension in all CA certificates 
>that contain public keys used to validate digital signatures on 
>certificates and MUST mark the extension as critical in such 
>certificates.

Again, 5280 says that a CA certificate is a v3 certificate.

>
>>  This may be true in theory, but is far from true in practice - in
>>  practice, I can put a self-signed cert on my website and it works just
>>  fine (in the sense that it is not considered malformed, just rather
>>  untrustworthy).
>>
>>  So, this is just spec lawyering.
>
>Some data: both SIP (rfc3261) and S/MIME (rfc5750) explicitly
>allow self-signed certs. SDP/TLS (rfc4572) seems to have an
>entire section about them. And of course TLS (rfc5246) says
>you MAY include them.

I looked at the 4 cites you provided above.  Only two of them support 
your conclusion that it's OK to call for using an SS cert as an EE 
cert.

When I scan 5246 I find one reference to a self-signed cert (page 48).
That text is talking about a "root certificate [sic] authority." So that
reference is NOT talking about SS certs as EE certs.

RFC 5750 appears to contain two references to self-signed certs (page 8)
and both refer to CA certs, not to EE certs. So, again, this 
reference is NOT talking about SS certs as EE certs.

RFC 4572 makes a number of references to SS certs, and it does
envision using them as EE certs. However, the security analysis for using
SS certs here is flawed. For example it says (page 9) that it's OK to
use a SS cert to assert ANY identity in the TLS session or in an 
S/MIME-protected SDP exchange. In the name of interoperability, the 
RFC also says (page 9) that if hop-by-hop integrity is employed for 
SDP, then an SS cert is OK too, even though this allows any SDP 
entity along the path to spoof any other entity. I can't take too 
seriously an endorsement of misuse of SS certs as EE certs in this 
brief
document, given the rest of the bad security analysis.

RFC 3261 has references to SS certs that are clearly used as EE 
certs. The six references to SS certs in that doc (on pages 202-204 
and 248) equate them to "certificates signed by an obscure 
authority."  Oh well, guess nobody who cared about PKIX bothered to 
read 200+ pages into a 270 page doc to find that error :-), back in 
2002.

Steve
--============_-909570926==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: [dane] [keyassure] Use cases
document.</title></head><body>
<div>At 2:49 PM +0100 4/8/11, Stephen Farrell wrote:</div>
<blockquote type="cite" cite>...</blockquote>
<blockquote type="cite" cite><br>
5280 is IMO properly silent on how EEs might use self-signed<br>
certs. (Or if not, I've forgotten what it says on that;-)</blockquote>
<div><br>
<br>
</div>
<div>I'll help with a few cites from 5280:</div>
<div><br></div>
<blockquote type="cite" cite><font
color="#000000">3.2:</font></blockquote>
<blockquote type="cite" cite><font
color="#000000"><br></font></blockquote>
<blockquote type="cite" cite><font color="#000000">This specification
covers two classes of certificates:<u> CA&nbsp; certificates</u> and
end entity certificates.&nbsp;<u> CA certificates</u> may be&nbsp;
further divided into three classes: cross-certificates, self-issued&nbsp;
certificates, and<u> self-signed certificates</u>.&nbsp;
Cross-certificates are CA certificates in which the issuer and subject
are different entities.&nbsp; Cross-certificates describe a trust
relationship between the two CAs.&nbsp; Self-issued certificates are
CA certificates in which&nbsp; the issuer and subject are the same
entity.&nbsp; Self-issued certificates are generated to support
changes in policy or operations.&nbsp;<u> Self-signed certificates are
self-issued certificates where the digital signature may be verified
by the public key bound into the certificate.</u>&nbsp; Self-signed
certificates are used to convey a public key for use to begin
certification paths.&nbsp;<u> End entity certificates are issued to
subjects that are not authorized to issue
certificates.</u></font></blockquote>
<div><font color="#000000"><u><br></u></font></div>
<div><font color="#000000">This text says that a self-signed
certificate is a CA certificate, period. The last sentence says that
an EE certificate cannot be used to verify a signature on another
certificate, and thus it is not a CA certificate, and thus, not
self-signed.</font></div>
<div><br></div>
<blockquote type="cite" cite><font color="#000000">4.2.1.1
(AKI)</font></blockquote>
<blockquote type="cite" cite><font
color="#000000"><br></font></blockquote>
<blockquote type="cite" cite><font color="#000000">The keyIdentifier
field of the authorityKeyIdentifier extension MUST be included in all
certificates generated by conforming CAs to facilitate certification
path construction.&nbsp; There is one exception; where a CA
distributes its public key in the form of a &quot;self-signed&quot;
certificate, the authority key identifier MAY be
omitted.</font></blockquote>
<div><font color="#000000"><br></font></div>
<div><font color="#000000">This text says further reiterates the
notion that a self-signed certificate is not an EE certificate. Note
that in this text the exception discusses the context where a CA
distributes its public key via a self-signed certificate, i.e., where
the self-signed certificate is used as a container to distribute a
trust anchor.</font> This is the relevant case for DANE.</div>
<div><br></div>
<blockquote type="cite" cite><font color="#000000">4.2.1.3
(KU)</font></blockquote>
<blockquote type="cite" cite><font
color="#000000"><br></font></blockquote>
<blockquote type="cite" cite><font color="#000000">The keyCertSign bit
is asserted when the subject public key is&nbsp; used for verifying
signatures on public key certificates.&nbsp; If the keyCertSign bit is
asserted, then the cA bit in the basic constraints extension (Section
4.2.1.9) MUST also be asserted.</font></blockquote>
<blockquote type="cite" cite><font
color="#000000"><br></font></blockquote>
<blockquote type="cite" cite><font color="#000000">If the keyUsage
extension is present, then the subject public key MUST NOT be used to
verify signatures on certificates or CRLs unless the corresponding
keyCertSign or cRLSign bit is set.</font></blockquote>
<div><font color="#000000"><br></font></div>
<div><font color="#000000">This text says that a valid CA certificate
MUST contain the basic constraints extension with the CA flag set
TRUE, thus 5280 requires CA certificates to be v3. It also establishes
required values for key usage extension flags if the certificate is to
be used to verify signatures on other certificates, i.e., if the
certificate is to be used as a CA certificate.</font><br>
</div>
<blockquote type="cite" cite><font color="#000000">4.2.1.9 (Basic
Constraints):</font></blockquote>
<blockquote type="cite" cite><font
color="#000000"><br></font></blockquote>
<blockquote type="cite" cite><font color="#000000">The basic
constraints extension identifies whether the subject of the
certificate is a CA and the maximum depth of valid certification paths
that include this certificate.</font></blockquote>
<blockquote type="cite" cite><font
color="#000000"><br></font></blockquote>
<blockquote type="cite" cite><font color="#000000">Conforming CAs MUST
include this extension in all CA certificates that contain public keys
used to validate digital signatures on certificates and MUST mark the
extension as critical in such certificates.</font></blockquote>
<div><font color="#000000"><br></font></div>
<div><font color="#000000">Again, 5280 says that a CA certificate is a
v3 certificate.</font><br>
</div>
<blockquote type="cite" cite><br>
&gt; This may be true in theory, but is far from true in practice -
in<br>
&gt; practice, I can put a self-signed cert on my website and it works
just<br>
&gt; fine (in the sense that it is not considered malformed, just
rather<br>
&gt; untrustworthy).<br>
&gt;<br>
&gt; So, this is just spec lawyering.<br>
<br>
Some data: both SIP (rfc3261) and S/MIME (rfc5750) explicitly<br>
allow self-signed certs. SDP/TLS (rfc4572) seems to have an<br>
entire section about them. And of course TLS (rfc5246)
says</blockquote>
<blockquote type="cite" cite>you MAY include them.</blockquote>
<div><br></div>
<div>I looked at the 4 cites you provided above.&nbsp; Only two of
them support your conclusion that it's OK to call for using an SS cert
as an EE cert.</div>
<div><br></div>
<div>When I scan 5246 I find one reference to a self-signed cert (page
48).</div>
<div>That text is talking about a &quot;root certificate [sic]
authority.&quot; So that</div>
<div>reference is NOT talking about SS certs as EE certs.</div>
<div><br></div>
<div>RFC 5750 appears to contain two references to self-signed certs
(page 8)</div>
<div>and both refer to CA certs, not to EE certs. So, again, this
reference is NOT talking about SS certs as EE certs.</div>
<div><br></div>
<div>RFC 4572 makes a number of references to SS certs, and it
does</div>
<div>envision using them as EE certs. However, the security analysis
for using</div>
<div>SS certs here is flawed. For example it says (page 9) that it's
OK to</div>
<div>use a SS cert to assert ANY identity in the TLS session or in an
S/MIME-protected SDP exchange. In the name of interoperability, the
RFC also says (page 9) that if hop-by-hop integrity is employed for
SDP, then an SS cert is OK too, even though this allows any SDP entity
along the path to spoof any other entity. I can't take too seriously
an endorsement of misuse of SS certs as EE certs in this brief</div>
<div>document, given the rest of the bad security analysis.</div>
<div><br></div>
<div>RFC 3261 has references to SS certs that are clearly used as EE
certs. The six references to SS certs in that doc (on pages 202-204
and 248) equate them to &quot;<font color="#000000">certificates
signed by an obscure authority</font>.&quot;&nbsp; Oh well, guess
nobody who cared about PKIX bothered to read 200+ pages into a 270
page doc to find that error :-), back in 2002.</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-909570926==_ma============--

From [email-masked]  Mon Apr 11 15:41:05 2011
Date: Mon, 11 Apr 2011 18:41:02 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Christopher Morrow <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [dane] Use Cases Document

--bcaec50166a5375c6d04a0ac450b
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Apr 11, 2011 at 3:49 PM, Christopher Morrow <[email-masked]
> wrote:

> On Mon, Apr 11, 2011 at 9:11 PM, Phillip Hallam-Baker <[email-masked]>
> wrote:
> >
> >
> > On Mon, Apr 11, 2011 at 2:49 PM, Christopher Morrow
> > <[email-masked]> wrote:
> >>
> >> I'm not sure you'd (*or anyone would) know if this was going on
> >> though. it only became 'known' because the alleged/admitted third
> >> party bragged about his actions, in detail.
> >
> > No, this is an untrue accusation and must be withdrawn.
>
> pardon? the young man who put out the info did so long before the
> browser patches arrived. he even had the private keys and certs, I
> believe, available before patches hit for browsers.

Not true. Go read the incident report.

The person who leaked the story while the patches were being prepared was
Jacob Applebaum who had absolutely nothing to do with making the attack. He
then agreed to hold off on publishing the details while one of the patches
was completed.

But the decision to publish was taken long before the attack had leaked. The
attack had already been communicated to several parties who were not under
NDA or any confidentiality agreement.

If you want to make serious accusations you should take the time to find out
the facts first. In this case the facts are very easily determined and show
that you are wrong.

It is quite true that not every detail of the attack has been made public.
This is quite usual when there is a continuing police investigation.

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

--bcaec50166a5375c6d04a0ac450b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Mon, Apr 11, 2011 at 3:49 PM, Christo=
pher Morrow <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]=
">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex;">
<div class=3D"im">On Mon, Apr 11, 2011 at 9:11 PM, Phillip Hallam-Baker &lt=
;<a href=3D"mailto:[email-masked]">[email-masked]</a>&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt; On Mon, Apr 11, 2011 at 2:49 PM, Christopher Morrow<br>
&gt; &lt;<a href=3D"mailto:[email-masked]">[email-masked]=
</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; I&#39;m not sure you&#39;d (*or anyone would) know if this was goi=
ng on<br>
&gt;&gt; though. it only became &#39;known&#39; because the alleged/admitte=
d third<br>
&gt;&gt; party bragged about his actions, in detail.<br>
&gt;<br>
&gt; No, this is an untrue accusation and must be withdrawn.<br>
<br>
</div>pardon? the young man who put out the info did so long before the<br>
browser patches arrived. he even had the private keys and certs, I<br>
believe, available before patches hit for browsers.</blockquote><div><br></=
div><div>Not true. Go read the incident report.</div><div><br></div><div>Th=
e person who leaked the story while the patches were being prepared was Jac=
ob Applebaum who had absolutely nothing to do with making the attack. He th=
en agreed to hold off on publishing the details while one of the patches wa=
s completed.=A0</div>
<div><br></div><div>But the decision to publish was taken long before the a=
ttack had leaked. The attack had already been communicated to several parti=
es who were not under NDA or any confidentiality agreement.</div><div><br>
</div><div><br></div><div>If you want to make serious accusations you shoul=
d take the time to find out the facts first. In this case the facts are ver=
y easily determined and show that you are wrong.</div><div><br></div><div>
It is quite true that not every detail of the attack has been made public. =
This is quite usual when there is a continuing police investigation.=A0</di=
v><div><br></div></div><br>-- <br>Website: <a href=3D"http://hallambaker.co=
m/">http://hallambaker.com/</a><br>
<br>

--bcaec50166a5375c6d04a0ac450b--

From [email-masked]  Mon Apr 11 16:14:30 2011
From: Yoav Nir <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 11 Apr 2011 21:57:53 +0200
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [dane] Use Cases Document

--_000_A46B78714A59413F8762361DF43B94ECcheckpointcom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

On Apr 11, 2011, at 10:11 PM, Phillip Hallam-Baker wrote:

On Mon, Apr 11, 2011 at 2:49 PM, Christopher Morrow <[email-masked]=
m<mailto:[email-masked]>> wrote:

I'm not sure you'd (*or anyone would) know if this was going on
though. it only became 'known' because the alleged/admitted third
party bragged about his actions, in detail.

No, this is an untrue accusation and must be withdrawn.

The notification of the RA breach incident was made through the normal proc=
ess and the timing of the release of the information to the public was gate=
d on the time taken to roll patches by the major browser providers.

I think these kind of rumors thrive because we haven't heard how the breach=
 was found. Common wisdom is that few breaches get discovered. If Comodo ha=
s found it by its own means, that puts it way ahead of the curve.

Anyway, the most worrying part about the incident is not that there was a b=
reach. Sites get defaced, houses get broken into, and banks get robbed all =
the time. Information gets stolen. It's part of the risk of doing business =
and of living in houses. The problem is what needed to be done to fix it. G=
oing forward, is this what we're going to have to do?  Is the response to a=
ny future mis-issue going to be a patch to all browsers with hard-coded CRL=
s?

I hope the commercial CAs can find a better way to do revocation.

As for DANE, while not actually a use-case, the incident highlights two req=
uirements:
- Revocation should be possible (if I pinned or pointed out the wrong certi=
ficate, I should be able to rectify it)
- We need resistance against an attacker who controls the DNS (such as a na=
tional government or a hotspot administrator)

I guess DNSSEC can protect against the malicious hotspots. Not so sure if i=
t's effective against a national government.

--_000_A46B78714A59413F8762361DF43B94ECcheckpointcom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html><head></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode:=
 space; -webkit-line-break: after-white-space; "><br><div><div>On Apr 11, 2=
011, at 10:11 PM, Phillip Hallam-Baker wrote:</div><br class=3D"Apple-inter=
change-newline"><blockquote type=3D"cite"><br><br><div class=3D"gmail_quote=
">On Mon, Apr 11, 2011 at 2:49 PM, Christopher Morrow <span dir=3D"ltr">&lt=
;<a href=3D"mailto:[email-masked]">[email-masked]</a>&gt;=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
I'm not sure you'd (*or anyone would) know if this was going on<br>
though. it only became 'known' because the alleged/admitted third<br>
party bragged about his actions, in detail.</blockquote><div><br></div><div=
>No, this is an untrue accusation and must be withdrawn.</div><div><br></di=
v><div>The notification of the RA breach incident was made through the norm=
al process and the timing of the release of the information to the public w=
as gated on the time taken to roll patches by the major browser providers.&=
nbsp;</div>
</div></blockquote><br></div><div>I think these kind of rumors thrive becau=
se we haven't heard how the breach was found. Common wisdom is that few bre=
aches get discovered. If Comodo has found it by its own means, that puts it=
 way ahead of the curve.</div><div><br></div><div>Anyway, the most worrying=
 part about the incident is not that there was a breach. Sites get defaced,=
 houses get broken into, and banks get robbed all the time. Information get=
s stolen. It's part of the risk of doing business and of living in houses. =
The problem is what needed to be done to fix it. Going forward, is this wha=
t we're going to have to do? &nbsp;Is the response to any future mis-issue =
going to be a patch to all browsers with hard-coded CRLs? &nbsp;</div><div>=
<br></div><div>I hope the commercial CAs can find a better way to do revoca=
tion.</div><div><br></div><div>As for DANE, while not actually a use-case, =
the incident highlights two requirements:</div><div>- Revocation should be =
possible (if I pinned or pointed out the wrong certificate, I should be abl=
e to rectify it)</div><div>- We need resistance against an attacker who con=
trols the DNS (such as a national government or a hotspot administrator)</d=
iv><div><br></div><div>I guess DNSSEC can protect against the malicious hot=
spots. Not so sure if it's effective against a national government.</div><d=
iv><br></div><div><br></div><div><br></div><br></body></html>=

--_000_A46B78714A59413F8762361DF43B94ECcheckpointcom_--

From [email-masked]  Mon Apr 11 17:54:20 2011
From: Warren Kumari <[email-masked]>
Date: Mon, 11 Apr 2011 20:54:10 -0400
To: Yoav Nir <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] Use Cases Document

On Apr 11, 2011, at 3:57 PM, Yoav Nir wrote:

>=20
> On Apr 11, 2011, at 10:11 PM, Phillip Hallam-Baker wrote:
>=20
>>=20
>>=20
>> On Mon, Apr 11, 2011 at 2:49 PM, Christopher Morrow =
<[email-masked]> wrote:
>>=20
>> I'm not sure you'd (*or anyone would) know if this was going on
>> though. it only became 'known' because the alleged/admitted third
>> party bragged about his actions, in detail.
>>=20
>> No, this is an untrue accusation and must be withdrawn.
>>=20
>> The notification of the RA breach incident was made through the =
normal process and the timing of the release of the information to the =
public was gated on the time taken to roll patches by the major browser =
providers.=20
>=20
> I think these kind of rumors thrive because we haven't heard how the =
breach was found. Common wisdom is that few breaches get discovered. If =
Comodo has found it by its own means, that puts it way ahead of the =
curve.
>=20
> Anyway, the most worrying part about the incident is not that there =
was a breach. Sites get defaced, houses get broken into, and banks get =
robbed all the time. Information gets stolen. It's part of the risk of =
doing business and of living in houses. The problem is what needed to be =
done to fix it. Going forward, is this what we're going to have to do?  =
Is the response to any future mis-issue going to be a patch to all =
browsers with hard-coded CRLs? =20
>=20
> I hope the commercial CAs can find a better way to do revocation.
>=20
> As for DANE, while not actually a use-case, the incident highlights =
two requirements:
> - Revocation should be possible (if I pinned or pointed out the wrong =
certificate, I should be able to rectify it)
> - We need resistance against an attacker who controls the DNS (such as =
a national government or a hotspot administrator)
>=20
> I guess DNSSEC can protect against the malicious hotspots. Not so sure =
if it's effective against a national government.

Well, it depends upon what all you think a national government can / is =
willing to do...

If you believe that they can break the crypto, then no, DNSSEC (and by =
extension DANE) is not effective against a NG but then neither is =
anything that relies upon crypto stuff (like TLS).

If you believe that they are willing to seize the domain and replace the =
records at the registry / parent then no, DNSSEC isn't effective -- but, =
if they are willing to seize the domain you have lost in any case (and =
they need to be in county to do this).

If they are willing to force all of their citizens / resolver operators =
to install a root key that they control, and then clone / mirror the DNS =
tree (and block access to the "real" DNS and sign on the fly and all =
sorts of other tricks) then they can forge DNSSEC responses... In this =
case you have lost anyway (they could (and probably would) also force =
installation of their own TA as well).

Other than that (oh, and rubber-hose cryptanalysis) AFAIK the best that =
a gvmnt can do is the same that any other attacker can do -- block / =
corrupt DNSSEC resolution, making responses bogus. Under these =
conditions the client cannot get a valid TLSA record and so cannot =
continue. So, the best that an attacker can manage under these =
conditions is a DoS (which they can cause regardless of the existence of =
DANE.

W

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

From [email-masked]  Mon Apr 11 18:42:51 2011
From: Jakob Schlyter <[email-masked]>
Date: Mon, 11 Apr 2011 21:57:34 +0200
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [dane] [keyassure] Use cases document.

On 11 apr 2011, at 20.55, Phillip Hallam-Baker wrote:

> This problem is very easily solved: DANE needs say nothing about the =
issue at all. Just cite PKIX and move on.

I agree, and I see no point in spending the WG's time trying to move =
(this part of) the PKIX mountain.

	jakob

From [email-masked]  Mon Apr 11 19:36:31 2011
Date: Mon, 11 Apr 2011 22:36:29 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Warren Kumari <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] Use Cases Document

--20cf3054a11339e9ac04a0af8f38
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Apr 11, 2011 at 8:54 PM, Warren Kumari <[email-masked]> wrote:

>
> > I think these kind of rumors thrive because we haven't heard how the
> breach was found. Common wisdom is that few breaches get discovered. If
> Comodo has found it by its own means, that puts it way ahead of the curve.
>

It is in the incident report.

The CA has a mechanism that notifies the RA every time a certificate is
issued. The RA knew it had not requested the certs and that they must
therefore have been a breach.

This is not an isolated incident either. VeriSign detected the codesigning
breach ten years ago and self-reported that as well.

> Well, it depends upon what all you think a national government can / is
> willing to do...
>
> If you believe that they can break the crypto, then no, DNSSEC (and by
> extension DANE) is not effective against a NG but then neither is anything
> that relies upon crypto stuff (like TLS).
>

I don't think anyone who can break the crypto would want the fact to be
known. So I would exclude this attack.

> If you believe that they are willing to seize the domain and replace the
> records at the registry / parent then no, DNSSEC isn't effective -- but, if
> they are willing to seize the domain you have lost in any case (and they
> need to be in county to do this).
>

We have seen this attack several times.

> If they are willing to force all of their citizens / resolver operators to
> install a root key that they control, and then clone / mirror the DNS tree
> (and block access to the "real" DNS and sign on the fly and all sorts of
> other tricks) then they can forge DNSSEC responses... In this case you have
> lost anyway (they could (and probably would) also force installation of
> their own TA as well).
>

That is the 'attack' that I expect and it is not even really an 'attack'
from certain points of view. If the Russian government decides that it
disagrees that the US has the right to appoint the general custodian of root
DNS, then that is a diplomatic dispute rather than a technical attack.

In fact there was the time back in the mists of time when Jon Postel and the
root operators did the same sort of thing of their own accord.

Given that Russia and China have signed a treaty on this subject I really
don't doubt their intention to follow through on it.

This is why I think we are going to need DPLS and some other stuff in the
loop. I do not raise these issues because of some hidden agenda, my reason
for raising them is that I want to protect against them.

Other than that (oh, and rubber-hose cryptanalysis) AFAIK the best that a
> gvmnt can do is the same that any other attacker can do -- block / corrupt
> DNSSEC resolution, making responses bogus. Under these conditions the client
> cannot get a valid TLSA record and so cannot continue. So, the best that an
> attacker can manage under these conditions is a DoS (which they can cause
> regardless of the existence of DANE.

It all comes down to what your fallback mechanism is.

If you are going to fall back to 'site unavailable' then you lose.

If you fall back to 'route DNS over alternative mechanism to trusted source'
then you can win even when you have a government level DoS.

There is other stuff that can be done as well. I do not accept that this
particular attack model is hopeless.

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

--20cf3054a11339e9ac04a0af8f38
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Mon, Apr 11, 2011 at 8:54 PM, Warren =
Kumari <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">warren@ku=
mari.net</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class=3D"h5"><br>
&gt; I think these kind of rumors thrive because we haven&#39;t heard how t=
he breach was found. Common wisdom is that few breaches get discovered. If =
Comodo has found it by its own means, that puts it way ahead of the curve.<=
br>

</div></div></blockquote><div><br></div><div>It is in the incident report.<=
/div><div><br></div><div>The CA has a mechanism that notifies the RA every =
time a certificate is issued. The RA knew it had not requested the certs an=
d that they must therefore have been a breach.</div>
<div><br></div><div>This is not an isolated incident either. VeriSign detec=
ted the codesigning breach ten years ago and self-reported that as well.</d=
iv><div><br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Well, it depends upon what all you think a national government can / is wil=
ling to do...<br>
<br>
If you believe that they can break the crypto, then no, DNSSEC (and by exte=
nsion DANE) is not effective against a NG but then neither is anything that=
 relies upon crypto stuff (like TLS).<br></blockquote><div><br></div><div>
I don&#39;t think anyone who can break the crypto would want the fact to be=
 known. So I would exclude this attack.</div><div><br></div><div>=A0</div><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex;">

If you believe that they are willing to seize the domain and replace the re=
cords at the registry / parent then no, DNSSEC isn&#39;t effective -- but, =
if they are willing to seize the domain you have lost in any case (and they=
 need to be in county to do this).<br>
</blockquote><div><br></div><div>We have seen this attack several times.</d=
iv><div><br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
If they are willing to force all of their citizens / resolver operators to =
install a root key that they control, and then clone / mirror the DNS tree =
(and block access to the &quot;real&quot; DNS and sign on the fly and all s=
orts of other tricks) then they can forge DNSSEC responses... In this case =
you have lost anyway (they could (and probably would) also force installati=
on of their own TA as well).<br>
</blockquote><div><br></div><div>That is the &#39;attack&#39; that I expect=
 and it is not even really an &#39;attack&#39; from certain points of view.=
 If the Russian government decides that it disagrees that the US has the ri=
ght to appoint the general custodian of root DNS, then that is a diplomatic=
 dispute rather than a technical attack.</div>
<div><br></div><div>In fact there was the time back in the mists of time wh=
en Jon Postel and the root operators did the same sort of thing of their ow=
n accord.</div><div><br></div><div>Given that Russia and China have signed =
a treaty on this subject I really don&#39;t doubt their intention to follow=
 through on it.</div>
<div><br></div><div>This is why I think we are going to need DPLS and some =
other stuff in the loop. I do not raise these issues because of some hidden=
 agenda, my reason for raising them is that I want to protect against them.=
</div>
<div><br></div><div>=A0</div><div><br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"=
>
Other than that (oh, and rubber-hose cryptanalysis) AFAIK the best that a g=
vmnt can do is the same that any other attacker can do -- block / corrupt D=
NSSEC resolution, making responses bogus. Under these conditions the client=
 cannot get a valid TLSA record and so cannot continue. So, the best that a=
n attacker can manage under these conditions is a DoS (which they can cause=
 regardless of the existence of DANE.</blockquote>
<div><br></div><div>It all comes down to what your fallback mechanism is.</=
div><div><br></div><div>If you are going to fall back to &#39;site unavaila=
ble&#39; then you lose.</div><div><br></div><div>If you fall back to &#39;r=
oute DNS over alternative mechanism to trusted source&#39; then you can win=
 even when you have a government level DoS.</div>
<div><br></div><div><br></div><div>There is other stuff that can be done as=
 well. I do not accept that this particular attack model is hopeless.</div>=
<div>=A0</div></div>-- <br>Website: <a href=3D"http://hallambaker.com/">htt=
p://hallambaker.com/</a><br>
<br>

--20cf3054a11339e9ac04a0af8f38--

From [email-masked]  Mon Apr 11 20:13:17 2011
From: Martin Rex <[email-masked]>
To: [email-masked] (Phillip Hallam-Baker)
Date: Tue, 12 Apr 2011 05:13:13 +0200 (MEST)
Cc: [email-masked]
Subject: Re: [dane] Use Cases Document
Reply-To: [email-masked]

Phillip Hallam-Baker wrote:
> 
> On Mon, Apr 11, 2011 at 8:54 PM, Warren Kumari <[email-masked]> wrote:
> >
> > > I think these kind of rumors thrive because we haven't heard how the
> > breach was found. Common wisdom is that few breaches get discovered. If
> > Comodo has found it by its own means, that puts it way ahead of the curve.
> >
> 
> It is in the incident report.
> 
> The CA has a mechanism that notifies the RA every time a certificate is
> issued. The RA knew it had not requested the certs and that they must
> therefore have been a breach.

So they did not detect the break-in, only the abuse.

> 
> This is not an isolated incident either. VeriSign detected the codesigning
> breach ten years ago and self-reported that as well.

You mean the two ActiveX codesign/Authenticode certificates that are still
in every MSIE Browser in the "Untrusted Publishers" section today?

IIRC it took VeriSign 5 weeks after issue to notice their mistake.

And both VeriSign and Microsoft realized that they had not thought
about certificate revocation at all and Microsoft resorted to explicitly
blacklisting the certificate in all of their MSIE browsers.

Looking at the rush of browser patches after the Commodo breach 10 years
later, there hasn't been much progress with respect to "certificate
revocation does not work", it seems.  And this time around, it affected
many other browser vendors/suppliers as well, not just Microsoft...

-Martin

From [email-masked]  Mon Apr 11 20:26:31 2011
Sender: [email-masked]
Date: Tue, 12 Apr 2011 05:26:28 +0200
From: Christopher Morrow <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [dane] Use Cases Document

On Tue, Apr 12, 2011 at 12:41 AM, Phillip Hallam-Baker <[email-masked]> wrote:
>
>
> On Mon, Apr 11, 2011 at 3:49 PM, Christopher Morrow
> <[email-masked]> wrote:
>>
>> On Mon, Apr 11, 2011 at 9:11 PM, Phillip Hallam-Baker <[email-masked]>
>> wrote:
>> >
>> >
>> > On Mon, Apr 11, 2011 at 2:49 PM, Christopher Morrow
>> > <[email-masked]> wrote:
>> >>
>> >> I'm not sure you'd (*or anyone would) know if this was going on
>> >> though. it only became 'known' because the alleged/admitted third
>> >> party bragged about his actions, in detail.
>> >
>> > No, this is an untrue accusation and must be withdrawn.
>>
>> pardon? the young man who put out the info did so long before the
>> browser patches arrived. he even had the private keys and certs, I
>> believe, available before patches hit for browsers.
>
> Not true. Go read the incident report.

for the record:
3/21/2011 marks when the cert blacklist hit chrome (easy to find this
info, for me):
<http://googlechromereleases.blogspot.com/2011/03/stable-and-beta-channel-updates_17.html>

and this is the young man releasing some/most of the relevant details:
<http://pastebin.com/74KXCaEZ>
(also 3/21/2011)

this is the comodo blog entry:
<http://blogs.comodo.com/it-security/data-security/the-recent-ra-compromise/>
3/23/2011

so... 21 is before 23. So at least the public finds out about the
incident before a fix is available. In the end the real point here
isn't one CA is causing problems, it's the the entire system is a
house of cards. That millions of folks depend upon (as service owners
or as customers of services) a set of third parties to attest that the
connection the customer/service-owner create is 'secure' (that the
'customer' is conencted to the 'service').

We can do better, DANE potentially does much better from a risk
perspective, it removes one layer of abstraction, the service owner
can put in a public place a checksum for the ssl certificate she/he/it
installed for the service in question. A customer of that service can
validate that data in an open and simple/standards-based manner.

-chris

From [email-masked]  Mon Apr 11 21:17:46 2011
Sender: [email-masked]
Date: Tue, 12 Apr 2011 06:17:42 +0200
From: Christopher Morrow <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dane] Use Cases Document

On Tue, Apr 12, 2011 at 1:40 AM, Kirk Hall <[email-masked]> wrote:
> Chris, thanks for your response.
>
>
>
> I agree there=92s no point in trying to define UI specs in this DANE prop=
osal
> =96 but the Abstract for DANE does say =93Instead of trusting a certifica=
tion
> authority to have made this association correctly, the user might instead
> trust the authoritative DNS server for the domain name to make that
> association.=94=A0 So the question of trust and even user reaction under =
DANE
> (trust a self-signed cert instead of a CA cert) has been introduced.=A0 A=
nd
> some people have already posted that they want browsers and other
> applications to treat a self-signed cert as equal to a DV cert under DANE=
,
> so the question of desired UI result has been introduced to the discussio=
n.

ok. perhaps they mean 'the service owner installed the cert hash in
dns'  which is a short-hand for 'a dv cert' (the owner of the domain
that the cert is being issueed for did in fact install the cert hash
into the dns).

> If the ONLY thing you want DANE to do is allow an automatic TLS connectio=
n
> at the DNS level using any cert =96 then I can see why you would think

hrm, to be careful/clear, I really want a way for a client to validate
that the serivce they connect to (https on www.you.com for example)
is:
  1) the server the service owner expected (and the cusotmer expects)
  2) the service is what the service owner setup (and the customer expects)

I think this could happen with the service-owner installs a hash of
their cert (for example) into the DNS in a DNSSEC secured zone, the
client connects to the service, receives the certificate and checks
the hash against the DNSSEC secured record.

If things check out, success. if the dnssec verification and hash
verification fails, there is a clear message that monkey-business is
afoot.

> requiring what I called an anti-fraud check is irrelevant.=A0 However, I =
fear

I don't think it's effective so it's not worth doing, and the message
to the user isn't helpful. (they don't understand anyway, generally)

> You=92re correct that phishing and fraud haven=92t used SSL much in the p=
ast =96
> I=92d argue that=92s partly because CAs generally filter out cert request=
s from
> those guys.=A0 Every day at GeoTrust we received numerous requests from

or because the bad folk know that they don't have to do this, they get
their money without the added work of getting a cert. much simpler.
much less work.

> to get the trust indicators.=A0 That=92s why I think the browsers won=92t=
 grant
> any trust indicator to DANE self-signed certs unless you provide a flag o=
r
> some other means of identification for self-signed certs that have been
> fraud-checked so they can be distinguished from other self-signed certs.

it doesn't seem helpful to me, but if it's not hurting progress of
DANE, I guess I don't care either.

> One question to you:=A0 what practical, actual, real world problem is DAN=
E
> trying to solve?=A0 Is there, in fact, a real security need today for som=
eone
> to =93know=94 that they have reached the domain they intended to reach?=
=A0 (Today,
> browsers tell you if there is a mismatch between a domain name and a
> CA-issued cert on that domain=92s servers, so to some degree that potenti=
al

they can't tell me that the cert is the cert installed by the service
owner. If the cert isn't the one the service owner installed, the
client really shouldn't connect to it, I think.

> security issue is already resolved.)=A0 Do you have examples today of act=
ual
> problems where people are unsure if they have connected with the domains
> they wanted, and there is a bad result?=A0 (And if your example depends o=
n
> =93assume there has been a compromise of the DNS=94 =96 aren=92t all bets=
 off in
> that situation, where no solution is reliable?)=A0 I=92m not trying to be

green revolution folk in iran + facebook compromises
egyptian gov't actions (monitoring of dissidents/etc)
chinese gov't actions (gfw)

all COULD monkey with dns, all more than likely were monkeying with ssl cer=
ts.

> provocative =96 I really want to know what problem that actually exists t=
oday
> would be solved with DANE.

fair enough. we can do better than today, we really should.

-Chris

>
> Thanks.
>
> On Mon, Apr 11, 2011 at 11:49 AM, Christopher Morrow
> <[email-masked]> wrote:
>>
>> On Mon, Apr 11, 2011 at 6:21 PM, Kirk Hall <[email-masked]> wrote=
:
>> > Chris =96 thanks for your response.=A0 A few comments.
>> >
>> >
>> >
>> > 1.=A0 What you call =93comodogate=94 was an extreme rarity for the CA
>> > industry,
>> > and shouldn=92t have happened.=A0 If we have the correct story, someon=
e
>> > outside
>>
>> absolutely it shouldn't have happened. it's probably the 3rd or fourth
>> thing that 'shouldn't have happened' to comodo... related to security
>> and the security of their downstream dependents.
>>
>> > the external RA was able to gain access to the RA=92s cert issuance sy=
stem
>> > remotely, and then was able to use the RA=92s system to access the CA=
=92s
>> > cert
>> > issuance system remotely and order issuance of the fake certs.=A0 I=92=
m not
>> > aware of anything like this ever happening to a CA before, and it woul=
d
>> > have
>> > been easy to prevent this breach with basic systems security.
>>
>> I'm not sure you'd (*or anyone would) know if this was going on
>> though. it only became 'known' because the alleged/admitted third
>> party bragged about his actions, in detail. It's interesting that
>> comodo was supposed (as i understand it) to be checking to be sure
>> that the didn't re-issue an already known cert to a third-party NOT
>> the owner of the trademark/domain/etc. It's fairly telling that we
>> find out about this via the 'hacker' making it very publicly known.
>> How many times did this happen before from the same RA? or the same
>> set of dependent RAs?
>>
>> At this point, anyone depending on this being the only case of this..
>> is living in a fantasy land.
>>
>> > In my mind it=92s a mistake to interpret the incident as demonstrating
>> > major
>> > vulnerability for the CA industry as a whole.=A0 As an example, if one=
 day
>> > Wells Fargo Bank=92s international wire service system is breached and
>> > accessed remotely by an intruder, and the intruder then sends
>> > unauthorized
>> > wire transfers to Nigerian bank accounts before being caught, that wou=
ld
>> > be
>> > a fairly uninteresting case of basic data system security breach, and
>> > would
>>
>> different and not related issues above skipped.
>>
>> > not imply that the entire banking system for international wire
>> > transfers
>> > was in jeopardy or need of overhaul.=A0 Likewise, if a DNS operator=92=
s
>> > system
>> > is breached remotely in a similar fashion, I assume an intruder could
>> > play
>> > games with the self-signed certificates that have been associated with=
 a
>>
>> I don't think that's a fair assumption at all. Ideally, in any sane
>> dnssec secured system the 'domain owner' has the private keys required
>> to sign his/her/their zone data. If I host my zone on your server(s)
>> and you are compromised, worst case my zone goes invalid and .. .I
>> scramble for a provider who's less compromised.
>>
>> > domain under the DANE proposal =96 but that wouldn=92t weaken DANE.=A0=
 So in
>> > all
>> > cases, basic security systems are essential.
>>
>> The basic problem as i see it with the in-place cert/ca system is that
>> my security (as a customer and a server) is reliant upon a mess of
>> folks with whom I have very little faith or ability-to-have-faith in.
>> There exist today systems that will man-in-the-middle SSL connections
>> making certs appear (that are valid because they are signed by an
>> in-browser/client ca-store) and be invisible to both sides of the
>> connection. (see mallory proxy, for a software-only solution). There
>> are folks that use systems like this to degrade the security of
>> clients/servers in the field, today.
>>
>> I don't think we want this situation to exist, I think we want to aim
>> for the best possible security position for our customers (clients and
>> servers). This means we need another method than the current CA-store
>> system to verify that a certificate is valid, one not dependent upon
>> the CA-store/chain.
>>
>> > 2.=A0 From your comments it seems you view the association of certs
>> > (self-signed or from a CA) with a domain under the DANE proposal as
>> > completely agnostic and mechanical =96 the DNS operator should accept
>> > literally any cert offered by the domain owner =96 so that DANE a
>> > technological standard with no implications for =93trust=94 as general=
ly
>> > associated with digital certificates today.
>>
>> My feeling is that folks do today, and will tomorrow, own their own
>> DNS infrastructure. In what I think your terminology is: "They are
>> both the DOMAIN OWNER and the DNS OPERATOR". Today some folks (domain
>> owners) outsource their DNS services to third-parties (dns operators),
>> it's not clear that they need to (or even are) giving their dnssec key
>> materials to the dns operator though.
>>
>> Additionally, I'd bet that in many cases the dns operators have a
>> business relationship (ongoing, monthly recurring costs) with the
>> domain owners, they ought to be able to tell if the person asking for
>> a domain to exist own the domain. (they got the NS records pointed
>> from SLD -> 3rdLD afterall)
>>
>> > That=92s fine if everyone understands that.=A0 However, it then raises=
 the
>> > question of utility of the DANE proposal once implemented.=A0 If a kno=
wn
>> > phishing domain (see the APWG solutions list at
>> > http://www.antiphishing.org/solutions.html), or a likely new fraudster
>> > who
>> > registers an available look-alike domain such as
>> > your-account-bankofamerica.com or google-accounts.com can then attach =
a
>> > self-signed cert to the domain at the DNS level (including fake
>> > Organization
>> > information, etc. inserted inside the self-signed cert), and if
>> > consumers
>> > visiting that domain are automatically put into secure encrypted mode
>> > with
>> > the site with no checking against an OCSP or CRL =85=A0 and if that se=
cure
>> > domain is given the same favorable UI or other treatment by browsers a=
nd
>> > applications indicating secure mode or domain confirmation as for all
>> > other
>> > sites =85=A0 then won=92t the public come to see the DANE solution as =
insecure
>> > and
>> > untrustworthy?
>>
>> DANE is not here to help/hurt phishers. SSL doesn't factor into
>> phishing at all... please stop conflating phishing and SSL/TLS.
>>
>> DANE is about knowing that your TLS connection to a service is to the
>> service it intended to connect to... www.bobs-balloons.com on port 443
>> sent me a cert, I can verify that the destination server's certificate
>> is the one bobs-balloons created/signed/installed.
>>
>> > Meaning if there is no way under DANE for a consumer to distinguish
>> > between
>> > legitimate sites associated with a self-signed cert and fraudulent sit=
es
>> > (i.e., those domains already tagged for phishing, or look-alike domain=
s
>> > that
>> > would be rejected by a CA for a DV cert), what advantage does a consum=
er
>>
>> like the one signed by the compromised RA in the comodogate incident?
>> yea... that fix action worked out well there. Again, phishing isn't in
>> the purview of DANE, you can't solve the phishing problem... in the
>> last 15+ years the existing oligarchy of CA folk haven't solved it
>> (because the two items are not related).
>>
>> > gain from DANE?=A0 Why not just use self-signed certs today, and ask t=
he
>> > browsers to stop showing the =93Warning =96 cert comes from an unknown=
 /
>> > untrusted root=94 display?
>>
>> this doesn't show the user that the cert delivered over the wire to
>> the client was in fact the cert that the service-owner installed. the
>> current CA system doesn't do this either, DANE has a better hope of
>> doing this, i think.
>>
>> > 3.=A0 There is a potential solution to this problem.=A0 I know some on=
 this
>> > list
>> > want to get away from having to use a CA, and there=92s a way to do th=
at
>> > and
>> > keep DANE useful.
>>
>> s/'get away from having a CA'/'get away from the trust dependency upon
>> CAs'/
>>
>> less places for risk to inject themselves.
>>
>> > On some earlier draft list of DANE specifications, I think two basic
>> > DANE
>> > cert categories were proposed: 1=3Dself signed, and 2=3DCA issued.=A0 =
Why not
>> > add
>> > a third specification: 3=3Dself signed/fraud checked.
>>
>> because 'fraud checked' means nothing wrt the purpose of DANE?
>> True/False: "this certificate presented to me is the one the service
>> owner installed"
>>
>> > Category =933=94 would be for self-signed certs that have been run thr=
ough
>> > anti-fraud checking by an independent third party like what is done
>> > today
>> > for DV certs (e.g., compare the domain against APWG phishing lists,
>> > reject
>> > look-alike domains like paypall.com unless the real paypal.com proves
>> > ownership).=A0 The checking could be done by the DNS operators or some=
one
>> > else
>> > independent of the domain owner following an industry-standard set of
>> > anti-fraud criteria =96 but the certs would NOT have to be chained to =
a
>> > CA.
>> > Once checked, the self-signed certs would get a favorable flag (=933=
=94) so
>> > that
>> > browsers, applications, and consumers could choose to trust them, but
>> > not
>> > trust self-signed certs that were not checked against fraud (Category
>> > =931=94
>> > certs).=A0 Or, the user could choose to trust all kinds of certs if th=
e
>> > user
>> > is not concerned about dealing with fraudulent domains.
>>
>> it occurs to me that you ought to take this portion of the discussion
>> to the DNS heirarchy folks (ICANN and their downstream dependents for
>> DNS zone purchase) The problem you seek to solve has nothing to do
>> with certificates, and everything to do with DNS.
>>
>> If you can't sign up for the domain: bank-of-america-auth-stealers.com
>> ... you can't put the DANE cert into the zone.
>>
>> > the padlock, etc.).=A0 Those DNS operators would no doubt be embarrass=
ed
>> > to be
>> > giving known and reported phishing domains and look-alike domains the
>> > same
>> > DANE treatment as legitimate domains.
>>
>> this doesn't seem to be a factor today.
>>
>> > To be clear, under this proposal for DANE implementation ALL self-sign=
ed
>> > certs would be accepted for association with a domain, but they would =
be
>> > marked as either being checked using anti-fraud algorithms, or not bei=
ng
>>
>> you seem to be backdooring into the UI discussion, which isn't in
>> scope and isn't relevant.
>>
>> > checked, so that later applications and consumers could decide if they
>> > wanted to trust all self-signed certs, or only a subset.
>> > Differentiating
>> > certs in this way would mean that DANE is actually useful, and might b=
e
>>
>> DANE is useful as soon as I can tell that the certificate I'm
>> presented with is in fact the certificate that the service owner
>> installed for their service.
>>
>> > Do you view this as a feasible solution?=A0 Should we add this to the
>> > draft
>> > specifications?
>>
>> I think walking down the discussion of fraud and phishing is entirely
>> the wrong path for DANE to go. DANE, nor CA's really, can not hope to
>> solve the fraud/phishing problem.
>>
>> For grins: (http urls sent in spam today so far)
>> morrowc@fire:/prod/archive/2011/04$ grep http:// 11/*.txt | wc -l
>> 392951
>>
>> HTTPS
>> morrowc@fire:/prod/archive/2011/04$ grep https:// 11/*.txt | wc -l
>> 65
>> (oddly mostly for: sears.r4sys.net which ends up bouncing properly throu=
gh
>> to:
>> Location:
>> http://www.sears.com/shc/s/v_10153_12605_Tools?lid=3Dtool_header&rioptyp=
e=3DSC&sid=3DIOx20110411SRSBAUALTSA2MMS80&eml=3D52379066&ruid=3D1003337
>> [following]
>> =A0 so this is incidental https in something, not a phishing attempt)
>>
>> I make the ssl-use-in-phishing at a number small enough that DANE
>> again shouldn't target this as a goal to solve.
>>
>> -Chris
>>
>> (in a related qestion, why doesn't affirmtrust use SSL on their forms?
>> http://www.affirmtrust.com/free-ssl-sign-up.html)
>>
>> > On Sun, Apr 10, 2011 at 7:54 AM, Christopher Morrow
>> > <[email-masked]> wrote:
>> >>
>> >> On Fri, Apr 8, 2011 at 7:36 PM, Kirk Hall <[email-masked]>
>> >> wrote:
>> >> >
>> >> > (1) CAs review DV cert requests for =93high risk=94 organization an=
d
>> >> > domain
>> >> > names that are most commonly targeted in phishing and other
>> >> > fraudulent
>> >> > schemes, and reject those cert requests.=A0 These lists include (a)
>> >> > internal
>> >>
>> >> <insert comodogate here>
>> >>
>> >> > Does DANE contemplate that the DNS operators would also reject doma=
in
>> >>
>> >> I think, from my brief reading, the 'dns operator' here is ... the
>> >> owner of the domain. So, 'stolen-bank-of-america-credentials.com' if
>> >> owned by 'evil person' could certainly publish a cert record for the
>> >> self-signed cert on their website stealing credentials from naive
>> >> users.
>> >>
>> >> how many folks really get phished/etc over ssl connections today? (no=
t
>> >> many, if any, ssl isn't a factor in this problem space)
>> >>
>> >> >
>> >> > (2) CAs also employ other anti-fraud algorithms of their own agains=
t
>> >> > bad
>> >> > DV
>> >>
>> >> <insert comodogate here>
>> >>
>> >> > Do you contemplate that DNS operators would do anything similar for
>> >> > self-signed certs?
>> >>
>> >> why would they? they are putting records into their own zone... if
>> >> somone they don't know/trust can make changes to their DNSSEC signed
>> >> DNS data... they are sunk anyway.
>> >>
>> >> > (3) DV certs have a clear chain of liability back to the issuing CA=
.
>> >> > The
>> >> > CAs
>> >> > today do a pretty good job in preventing high risk similar-named
>> >> > domains,
>> >> > like =93paypall.com=94,=A0 from getting certs for fraud and phishin=
g
>> >> > purposes.
>> >>
>> >> <insert comodogate here>
>> >>
>> >> > Under DANE, if a self-signed certificate issued in the name of
>> >> > =93paypall.com=94
>> >> > is accepted by a DNS operator and is used in phishing attacks, who
>> >> > would
>> >> > be
>> >>
>> >> the person that owns paypall.com can certainly make a self-signed
>> >> cert... and put the appropriate record into the dns zone they own, an=
d
>> >> sign it with the key they have... this isn't significantly different
>> >> than where we are today.
>> >>
>> >> > (5) Bad certs can be revoked, and the industry is working very hard
>> >> > right
>> >> > now on improving the revocation process.
>> >>
>> >> by completely sidestepping it? (let's hardcode certs into binaries,
>> >> because .. oscp is an admitted failure)
>> >>
>> >> > If there is a =93bad=94 self-signed cert associated with a domain b=
y a
>> >> > DNS
>> >> > operator and/or a DNS operator receives a report of fraud or phishi=
ng
>> >> > associated with a domain, will DANE have a way to remove, revoke, o=
r
>> >> > otherwise flag the cert as =93bad=94?
>> >>
>> >> sure, remove the record from dns (in the zone that publishes it)
>> >>
>> >> -chris
>> >
>> >
>
>

From [email-masked]  Mon Apr 11 21:19:02 2011
Sender: [email-masked]
Date: Tue, 12 Apr 2011 06:19:01 +0200
From: Christopher Morrow <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [dane] Use Cases Document

On Tue, Apr 12, 2011 at 5:26 AM, Christopher Morrow
<[email-masked]> wrote:
> On Tue, Apr 12, 2011 at 12:41 AM, Phillip Hallam-Baker <[email-masked]> wrote:
>>
>>
>> On Mon, Apr 11, 2011 at 3:49 PM, Christopher Morrow
>> <[email-masked]> wrote:
>>>
>>> On Mon, Apr 11, 2011 at 9:11 PM, Phillip Hallam-Baker <[email-masked]>
>>> wrote:
>>> >
>>> >
>>> > On Mon, Apr 11, 2011 at 2:49 PM, Christopher Morrow
>>> > <[email-masked]> wrote:
>>> >>
>>> >> I'm not sure you'd (*or anyone would) know if this was going on
>>> >> though. it only became 'known' because the alleged/admitted third
>>> >> party bragged about his actions, in detail.
>>> >
>>> > No, this is an untrue accusation and must be withdrawn.
>>>
>>> pardon? the young man who put out the info did so long before the
>>> browser patches arrived. he even had the private keys and certs, I
>>> believe, available before patches hit for browsers.
>>
>> Not true. Go read the incident report.
>
> for the record:
> 3/21/2011 marks when the cert blacklist hit chrome (easy to find this
> info, for me):
> <http://googlechromereleases.blogspot.com/2011/03/stable-and-beta-channel-updates_17.html>
>
> and this is the young man releasing some/most of the relevant details:
> <http://pastebin.com/74KXCaEZ>
> (also 3/21/2011)

this is dated 3/26 actually, i read the wrong date and I've deleted
the mail I had on this at the time of the cert blacklist checkin +
discussion.

-chris

From [email-masked]  Tue Apr 12 06:42:59 2011
Date: Tue, 12 Apr 2011 09:42:58 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Christopher Morrow <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [dane] Use Cases Document

--bcaec53f920bbc9aa704a0b8de7a
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Apr 12, 2011 at 12:19 AM, Christopher Morrow <
[email-masked]> wrote:
>
> > and this is the young man releasing some/most of the relevant details:
> > <http://pastebin.com/74KXCaEZ>
> > (also 3/21/2011)
>
> this is dated 3/26 actually, i read the wrong date and I've deleted
> the mail I had on this at the time of the cert blacklist checkin +
> discussion.
>
> -chris
>

So you are withdrawing your accusation?

The one thing that is known with absolute certainty about the attacker is
that they are a liar and manipulator.

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

--bcaec53f920bbc9aa704a0b8de7a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Tue, Apr 12, 2011 at 12:19 AM, Christ=
opher Morrow <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]=
m">[email-masked]</a>&gt;</span> wrote:<blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex;">
<div class=3D"im">
&gt; and this is the young man releasing some/most of the relevant details:=
<br>
&gt; &lt;<a href=3D"http://pastebin.com/74KXCaEZ" target=3D"_blank">http://=
pastebin.com/74KXCaEZ</a>&gt;<br>
&gt; (also 3/21/2011)<br>
<br>
</div>this is dated 3/26 actually, i read the wrong date and I&#39;ve delet=
ed<br>
the mail I had on this at the time of the cert blacklist checkin +<br>
discussion.<br>
<br>
-chris<br>
</blockquote></div><br>So you are withdrawing your accusation?<br clear=3D"=
all"><br><div>The one thing that is known with absolute certainty about the=
 attacker is that they are a liar and manipulator.</div><div><br>-- <br>
Website: <a href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br=
><br>
</div>

--bcaec53f920bbc9aa704a0b8de7a--

From [email-masked]  Tue Apr 12 06:57:25 2011
From: Peter Gutmann <[email-masked]>
To: [email-masked], [email-masked]
Date: Wed, 13 Apr 2011 01:57:23 +1200
Cc: [email-masked]
Subject: Re: [dane] Use Cases Document

Phillip Hallam-Baker <[email-masked]> writes:

>The CA has a mechanism that notifies the RA every time a certificate is
>issued. The RA knew it had not requested the certs and that they must
>therefore have been a breach.

This statement, while technically correct, is right up there with "Our CA key
was never compromised, therefore everything's OK".  According to ComodoHacker,
the number of certs this RA processes is practically nonexistent (one every
four or five days).  So what caused the RA to become suspicious isn't any
careful checking of the details of the certs that were issued but surprise at
the fact that any certs had been issued at all.  In addition ComodoHacker
pretty comprehensively owned the RA, their machines, email accounts, the lot.
If this had been a real attack rather than a kid having some fun then the
notification to the attacker-controlled RA would have had no effect.

Finally, looking at the claim that the CA didn't know about the compromise
until the attacker told them about it:

  the Comodo Partner Account that suffered the security breach has (totally,
  utterly and definitely) *not* mis-issued any further certificates, and we
  are not aware that any other Accounts have been breached
  - Rod Stradling, Comodo, 18 March 2011

  I hacked so much Comodo reseller account, but all of them was not able to
  use ApplySSL API. [...] From listed resellers of Comodo, I owned 3 of them,
  not only Italian one
  -- ComodoHacker, 29 March 2011

Still, detecting one out of three isn't so bad.  Somewhat worse than flipping
a coin, but not quite as bad as a broken clock.

So far from being a case of "our audit mechanisms were working as intended" it
was "man, was that ever a string of lucky breaks for us".

Peter.

From [email-masked]  Tue Apr 12 07:04:06 2011
Date: Tue, 12 Apr 2011 10:04:03 -0400
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: [dane] Concentrating on document? (was:  Use Cases Document)

Dear colleagues,

This is not to pick on Phill, but to suggest that this thread is not
going to yield results.  I would like to suggest that we stop debating
this sub-topic and focus on those areas where we can produce useful
results, such as the actual statement of things we are positively
going to be able to do.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

From [email-masked]  Tue Apr 12 07:06:21 2011
Date: Tue, 12 Apr 2011 10:06:19 -0400
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [dane] Use Cases Document

On Wed, Apr 13, 2011 at 01:57:23AM +1200, Peter Gutmann wrote:
> 
> This statement, while technically correct, is right up there with "Our CA key
> was never compromised, therefore everything's OK".  

Ok, I just asked vaguely, but now I will ask more pointedly: what in
the world does that have to do with advancing the problem statement?
If you have text that should go in a problem statement draft, then
propose it.  But fighting about someone's operational practices --
regardless of how anyone feels about it -- is completely irrelevant
here to what we are trying to do.  We will never make any progress at
all if we sink ourselves in this debate.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

From [email-masked]  Tue Apr 12 07:42:50 2011
From: Warren Kumari <[email-masked]>
To: Andrew Sullivan <[email-masked]>
Date: Tue, 12 Apr 2011 10:42:46 -0400
Cc: [email-masked]
Subject: Re: [dane] Use Cases Document

Yup, Andrew is 100% correct -- on my todo list for this morning was to  
rein (reign?!) in this discussion, both because it has gotten  
completely off-topic and because it is becoming needlessly personal...  
I should have done this a few days ago, but to be entirely honest I  
got sucked in and wanted to see where the rabbit-hole led...

I think that we can safely say (as our doc currently does) that "Some  
people want a different way to authenticate the association of the  
server's certificate with the intended domain name without trusting a  
CA.", further exploration of why is only going to lead to tears...

Thanks again to Andrew for helping keep us on-topic. Those of you who  
know me personally know how easily distracted (and prone to ratholing)  
I am...

W

On Apr 12, 2011, at 10:06 AM, Andrew Sullivan wrote:

> On Wed, Apr 13, 2011 at 01:57:23AM +1200, Peter Gutmann wrote:
>>
>> This statement, while technically correct, is right up there with  
>> "Our CA key
>> was never compromised, therefore everything's OK".
>
> Ok, I just asked vaguely, but now I will ask more pointedly: what in
> the world does that have to do with advancing the problem statement?
> If you have text that should go in a problem statement draft, then
> propose it.  But fighting about someone's operational practices --
> regardless of how anyone feels about it -- is completely irrelevant
> here to what we are trying to do.  We will never make any progress at
> all if we sink ourselves in this debate.
>
> A
>
> -- 
> Andrew Sullivan
> [email-masked]
> Shinkuro, Inc.
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

From [email-masked]  Tue Apr 12 08:23:58 2011
Date: Tue, 12 Apr 2011 11:23:57 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Andrew Sullivan <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] Concentrating on document? (was: Use Cases Document)

--20cf3054a113e8257804a0ba472e
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Apr 12, 2011 at 10:04 AM, Andrew Sullivan <[email-masked]> wrote:

> Dear colleagues,
>
> This is not to pick on Phill, but to suggest that this thread is not
> going to yield results.  I would like to suggest that we stop debating
> this sub-topic and focus on those areas where we can produce useful
> results, such as the actual statement of things we are positively
> going to be able to do.
>

I don't think we have yet got people to an understanding of what a use case
is. The point of use case analysis is to consider requirements at a higher
level of abstraction. Most of the 'use cases' being proposed are of the form
'Alice wants to use technology X'.

A use case should only relate to issues that the typical user is going to be
faced with. In the case of DANE it would be at the level of the instructions
that a typical client would give their network administration contractor to
implement.

Technical issues are introduced into a use case analysis by means of
constraints.

So a use case for email would be 'Alice wants to send a message to Bob', the
requirement to support SMTP would come from the constraint 'SMTP is the only
email protocol supported by 100% of Internet email servers'.

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

--20cf3054a113e8257804a0ba472e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Tue, Apr 12, 2011 at 10:04 AM, Andrew=
 Sullivan <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">ajs@shi=
nkuro.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Dear colleagues,<br>
<br>
This is not to pick on Phill, but to suggest that this thread is not<br>
going to yield results. =A0I would like to suggest that we stop debating<br=
>
this sub-topic and focus on those areas where we can produce useful<br>
results, such as the actual statement of things we are positively<br>
going to be able to do.<br></blockquote><div><br></div><div>I don&#39;t thi=
nk we have yet got people to an understanding of what a use case is. The po=
int of use case analysis is to consider requirements at a higher level of a=
bstraction. Most of the &#39;use cases&#39; being proposed are of the form =
&#39;Alice wants to use technology X&#39;.=A0</div>
<div><br></div><div>A use case should only relate to issues that the typica=
l user is going to be faced with. In the case of DANE it would be at the le=
vel of the instructions that a typical client would give their network admi=
nistration contractor to implement.</div>
<div><br></div><div><br></div><div>Technical issues are introduced into a u=
se case analysis by means of constraints.</div><div><br></div><div>So a use=
 case for email would be &#39;Alice wants to send a message to Bob&#39;, th=
e requirement to support SMTP would come from the constraint &#39;SMTP is t=
he only email protocol supported by 100% of Internet email servers&#39;.</d=
iv>
<div>=A0</div></div><br>-- <br>Website: <a href=3D"http://hallambaker.com/"=
>http://hallambaker.com/</a><br><br>

--20cf3054a113e8257804a0ba472e--

From [email-masked]  Tue Apr 12 09:46:17 2011
From: Martin Rex <[email-masked]>
To: [email-masked] (Stephen Kent)
Date: Tue, 12 Apr 2011 18:45:30 +0200 (MEST)
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.
Reply-To: [email-masked]

Stephen Kent wrote:
> 
> >For safety, it would be sensible to ALWAYS treat X.509v1 certs as
> >EndEntity certs (i.e. never accept them as signer of other certs).
> >Our TLS implementation had done this initially, but we had a customer
> >that had obtained server certs issued under a VeriSign X.509v1 CA cert
> >(as late as 2006!), so I had to make our OEM implementation tolerate this.
> 
> The fact that v1 certs contained no mechanism to distinguish between
> an EE cert and a CA cert was a major vulnerability, one that has been
> exploited in the browser context. I doubt that the IESG will approve
> an RFC that calls for supporting v1 certs at this time.

Leaving the status of X.509v1 certs in limbo is a really bad idea.

>From the SSLiverse data, it seems that there most of the self-signed
certs out there (500.000) are X.509v1.

Since DANE is a new protocol requiring new implementations, it seems
like a pretty bad idea to entirely ignore the installed base or to
leave the behaviour unspecified.

It does not seem sensibe to require 500.000 server admins to recreate
their self-signed server cert either as an X.509v3 CA cert used by
an End-Entity or as a self-signed X.509v3 End-Entity cert that is invalid
according to rfc-5280.

It would be much more sensible to require (a) support for X.509v1
self-signed end-entity certs and require (b) that X.509v1 certs
must NEVER be accepted as signers of other certs in certificate
path validations.

-Martin

From [email-masked]  Tue Apr 12 15:04:53 2011
From: Martin Rex <[email-masked]>
To: [email-masked] (Stephen Kent)
Date: Wed, 13 Apr 2011 00:04:38 +0200 (MEST)
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.
Reply-To: [email-masked]

Stephen Kent wrote:
> 
> At 2:49 PM +0100 4/8/11, Stephen Farrell wrote:
> >...
> >
> >5280 is IMO properly silent on how EEs might use self-signed
> >certs. (Or if not, I've forgotten what it says on that;-)

I agree with Stephen!

> 
> I'll help with a few cites from 5280:
> 
> >3.2:
> >
> >This specification covers two classes of certificates: CA 
> >certificates and end entity certificates.  CA certificates may be 
> >further divided into three classes: cross-certificates, self-issued 
> >certificates, and self-signed certificates.  Cross-certificates are 
> >CA certificates in which the issuer and subject are different 
> >entities.  Cross-certificates describe a trust relationship between 
> >the two CAs.  Self-issued certificates are CA certificates in which 
> >the issuer and subject are the same entity.  Self-issued 
> >certificates are generated to support changes in policy or 
> >operations.  Self-signed certificates are self-issued certificates 
> >where the digital signature may be verified by the public key bound 
> >into the certificate.  Self-signed certificates are used to convey a 
> >public key for use to begin certification paths.  End entity 
> >certificates are issued to subjects that are not authorized to issue 
> >certificates.
> 
> This text says that a self-signed certificate is a CA certificate, 
> period. The last sentence says that an EE certificate cannot be used 
> to verify a signature on another certificate, and thus it is not a CA 
> certificate, and thus, not self-signed.

That is not what rfc5280 says here.  It is really silent on
self-asserted or self-issued End Entity certs.

The quoted paragraph specifies, that rfc5280 profiles _only_ the following
subset of X.509v3 certs:

  1.) CA certs of class "cross-certificates"
  2.) CA certs of class "self-issued certificates"
  3.) CA certs of class "self-signed certificates"
  4.) CA-issued End entity certificates

And what you misread is the definiton:

  CA certificates of class self-issued certificates are certificates
  in which the isser and subject are the same entity.

So with a pedantic reading rfc-5280, the Internet Certificate and CRL
Profile, does not currently define a self-issued X.509v3 End Entity cert.

I'm somwhat puzzled about the description of (1) in 5280 section 3.2
and the lack of description of a regular intermediate CA cert.

My familiarity with X.509 and PKI is limited, so I may be wrong,
but wasn't cross-certificates originally used for CAs that mutually
sign each others public key in order to cross over between independent
CA hierarchies?

> 
> >4.2.1.1 (AKI)
> >
> >The keyIdentifier field of the authorityKeyIdentifier extension MUST 
> >be included in all certificates generated by conforming CAs to 
> >facilitate certification path construction.  There is one exception; 
> >where a CA distributes its public key in the form of a "self-signed" 
> >certificate, the authority key identifier MAY be omitted.
> 
> This text says further reiterates the notion that a self-signed 
> certificate is not an EE certificate. Note that in this text the 
> exception discusses the context where a CA distributes its public key 
> via a self-signed certificate, i.e., where the self-signed 
> certificate is used as a container to distribute a trust anchor. This 
> is the relevant case for DANE.

Any rules in rfc-5280 apply only to the subset of X.509v3 certs
listed in section 3.2 -- so it can, by definition, not apply to
self-issued X.509v3 End-entity certs.

> 
> >4.2.1.3 (KU)
> >
> >The keyCertSign bit is asserted when the subject public key is  used 
> >for verifying signatures on public key certificates.  If the 
> >keyCertSign bit is asserted, then the cA bit in the basic 
> >constraints extension (Section 4.2.1.9) MUST also be asserted.
> >
> >If the keyUsage extension is present, then the subject public key 
> >MUST NOT be used to verify signatures on certificates or CRLs unless 
> >the corresponding keyCertSign or cRLSign bit is set.
> 
> This text says that a valid CA certificate MUST contain the basic 
> constraints extension with the CA flag set TRUE, thus 5280 requires 
> CA certificates to be v3.

Correct.  I'm just fine with this requirement.

I am more than willing to disable the hack that was needed for this
legacy VeriSign X.509v1 TLS SErver CA in 2006!  But those VeriSign
X.509v1 certs are still distributed with all browsers with a
validity until 2026 -- (and a 1024-bit RSA keypair for which
an MD2withRsaEncryption signature was published...).

>
> It also establishes required values for key 
> usage extension flags if the certificate is to be used to verify 
> signatures on other certificates, i.e., if the certificate is to be 
> used as a CA certificate.

"verify signatures on other certificates".  With the exception of
split personalities, this is not the same as verifying the signature
on one's own certificates.

> 
> >4.2.1.9 (Basic Constraints):
> >
> >The basic constraints extension identifies whether the subject of 
> >the certificate is a CA and the maximum depth of valid certification 
> >paths that include this certificate.
> >
> >Conforming CAs MUST include this extension in all CA certificates 
> >that contain public keys used to validate digital signatures on 
> >certificates and MUST mark the extension as critical in such 
> >certificates.
> 
> Again, 5280 says that a CA certificate is a v3 certificate.

It says that conforming CAs must use X.509v3 certs exclusively that
contain the Basic Constraints extension "cA=TRUE" marked critical.

It seems that entirely omitting the KeyUsage extension is fine
with 5280 (to avoid any confusion around keyCertSign for self-issued
end entity certs).

> 
> >
> >>  This may be true in theory, but is far from true in practice - in
> >>  practice, I can put a self-signed cert on my website and it works just
> >>  fine (in the sense that it is not considered malformed, just rather
> >>  untrustworthy).
> >>
> >>  So, this is just spec lawyering.
> >
> >Some data: both SIP (rfc3261) and S/MIME (rfc5750) explicitly
> >allow self-signed certs. SDP/TLS (rfc4572) seems to have an
> >entire section about them. And of course TLS (rfc5246) says
> >you MAY include them.
> 
> I looked at the 4 cites you provided above.  Only two of them support 
> your conclusion that it's OK to call for using an SS cert as an EE 
> cert.
> 
> When I scan 5246 I find one reference to a self-signed cert (page 48).
> That text is talking about a "root certificate [sic] authority." So that
> reference is NOT talking about SS certs as EE certs.

You are looking in the wrong place:

  TLSv1.0:    http://tools.ietf.org/html/rfc2246#section-7.4.2
  TLSv1.1:    http://tools.ietf.org/html/rfc4346#section-7.4.2

   7.4.2. Server certificate

      [...]

   Meaning of this message:
       The certificate type must be appropriate for the selected cipher
       suite's key exchange algorithm, and is generally an X.509v3
       certificate. It must contain a key which matches the key exchange
       method, as follows.

rfc5246 did not supersede nor obsolete any prior TLS specifications,
it describes _only_ TLSv1.2,  The marker on the document is obviously wrong.
IPv6 did not obsolete IPv4,  HTTPv1.1 did no obsolete HTTP1.0.

Btw. OpenSSL does not support TLSv1.2 yet, and Windows 6.1
(aka Windows 7 and Windows Server 2008R2) ships with TLSv1.2 disabled
on the server end (potentially for similiar reasons -- the TLSv1.2 breakage
of the handshake message hash design through SignatureAndHashAlgorithms),
so you hardly find TLSv1.2 being used on the internet.

> 
> RFC 5750 appears to contain two references to self-signed certs (page 8)
> and both refer to CA certs, not to EE certs. So, again, this 
> reference is NOT talking about SS certs as EE certs.

But it says this:

http://tools.ietf.org/html/rfc5750#section-2.2

2.2.  Certificate Choices

   Receiving agents MUST support v1 X.509 and v3 X.509 certificates as
   profiled in [KEYM].  End-entity certificates MAY include an Internet
   mail address, as described in Section 3.

So rfc5750 (issued January 2010) has a "MUST support X.509v1" certs.
And there is _no_ limit in rfc5750 to support X.509v1 self-signed
end entity certs or X.509v3 self-signed end entity certs beyond rfc5280.

> 
> RFC 4572 makes a number of references to SS certs, and it does
> envision using them as EE certs. However, the security analysis for using
> SS certs here is flawed. For example it says (page 9) that it's OK to
> use a SS cert to assert ANY identity in the TLS session or in an 
> S/MIME-protected SDP exchange.

Where is your problem.  It is completely irrelevant which identity
self-signed end entity certificates assert, because these name
must be ignored anyway.  The only thing that really counts in the
public key -- and the public key represents the end entity.
the name in there is only a self-asserted tag within the
X.509 public key container

> 
> In the name of interoperability, the 
> RFC also says (page 9) that if hop-by-hop integrity is employed for 
> SDP, then an SS cert is OK too, even though this allows any SDP 
> entity along the path to spoof any other entity.

Authentication of self-signed entity certs is solely based on the public key,
the identities are completely irrelevant.

> 
> RFC 3261 has references to SS certs that are clearly used as EE 
> certs. The six references to SS certs in that doc (on pages 202-204 
> and 248) equate them to "certificates signed by an obscure 
> authority."  Oh well, guess nobody who cared about PKIX bothered to 
> read 200+ pages into a 270 page doc to find that error :-), back in 
> 2002.

http://tools.ietf.org/html/rfc3261#page-202

                             As an alternative, users MAY create self-
   signed certificates.  The implications of self-signed certificates
   are explored further in Section 26.4.2.  Implementations may also use
   pre-configured certificates in deployments in which a previous trust
   relationship exists between all SIP entities.

http://tools.ietf.org/html/rfc3261#section-26.4.2

The text in section 26.4.2 is pretty clear on the use of self-signed
certificate an it is far from being obscure.  It compares the key
distribution problem for the initial encounter to SSH -- which is
the classical and a quite popular and successful trust management
scheme for bare public keys.  Self-issued X.509 certs are conceptually
the same as bare public keys, just with extra, integrity-protected,
self-asserted stuffing.

-Martin

From [email-masked]  Tue Apr 12 15:34:31 2011
From: Martin Rex <[email-masked]>
To: [email-masked] (Phillip Hallam-Baker)
Date: Wed, 13 Apr 2011 00:34:27 +0200 (MEST)
Cc: [email-masked]
Subject: Re: [dane] Requirements - HTTPS
Reply-To: [email-masked]

Phillip Hallam-Baker wrote:
> 
> ?? As a reality check here, the browser providers have taken ten years to
> get round to doing hard fail on OCSP.

I think that the original concept behind OCSP for online communication
is extremely broken.

The only online communication/authentication architecture in which OCSP
would make sense is when the certificate holder is required to include
fresh (a few hours) copies of all OCSP response to verify all certs
in that entities certificate chain.  Maybe provide an option to each
peer how "fresh" these proof should be.

In such a scenario, the caching of OCSP responses works, there is no
privacy problem because only the holder of the certificate is requesting
OCSP responses from his issuing CA(s) on a regular basis, and the
holder of the certificate is in the best position to make these
communication links available, robust and low-latency (even out-of-band
updating of cached OCSP responses works just fine).

The original design, where the browser has to poll revocation info
from various places doesn't scale at all, in horribly unreliable
and a serious privacy problem.

-Martin

From [email-masked]  Tue Apr 12 19:14:49 2011
From: Peter Gutmann <[email-masked]>
To: [email-masked], [email-masked]
Date: Wed, 13 Apr 2011 14:14:44 +1200
Cc: [email-masked]
Subject: Re: [dane] Use Cases Document

Warren Kumari <[email-masked]> writes:

>Yup, Andrew is 100% correct -- on my todo list for this morning was to rein 
>(reign?!) in this discussion, both because it has gotten completely off-topic

The point in continuing it was to try to get more insight into current failure 
modes.  Theorising over usage cases (real or imagined) didn't seem too useful
unless we could first understand how things are failing today.  So rather than
being a flamewar I saw it as laying useful groundwork for things that needed
fixing.

Peter.

From [email-masked]  Tue Apr 12 20:09:13 2011
Date: Tue, 12 Apr 2011 23:09:09 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: [email-masked]
Subject: [dane] dane DNS record generator (service and software)

Hi,

I wrote a new tool to help people deploy and test DANE style DNS records.

You can use the following service to generate DANE records for your HTTPS
server:

https://dane.xelerance.com/

It currently supports only EE-certs with reference type 0,1 and 2. It
uses the same private RRTYPE number (65468) as Matt's nss-dane patch at:

https://mattmccutchen.net/cryptid/#nss-dane

The website is a small wrapper around the "dane" command, which I added to the
sshfp software package at ftp://ftp.xelerance.com/sshfp/sshfp-1.2.0.tar.gz
(I will probably soon rename the package 'sshfp' to something more appropriate)

Note that Matt's nss dane patch at still uses SHA1 for reference type 1,
and not SHA256 as per current dane 06 specification, so DNS records generated
with the "dane" command do not yet work with the patch at Matt's site.

The software version also supports an AXFR mode to deploy dane records
for all your A/AAAA records. If multple A/AAAA records use different SSL certs,
all are included.

Example use of the dane command:

[paul@thinkpad sshfp]$ ./dane --help
usage: dane [-h] [-n nameserver] [--axfr] [--draft] [--rfc] [--tlsa]
             [--eecert] [--cacert] [--pubkey] [--txt] [--sha256] [--sha512]
             [--full] [--insecure] [-4] [-6] [-q]
             hostname [hostname ...]

Create TLS related DNS records for hosts or an entire zone.

positional arguments:
   hostname

optional arguments:
   -h, --help            show this help message and exit
   -n nameserver, --nameserver nameserver
                         nameserver to query
   --axfr                use AXFR (all A/AAAA records will be scanned)
   --draft               output in draft private rrtype (65468/65469) format
                         (default)
   --rfc                 output in rfc (TLSA/HASTLS) rrtype format
   --tlsa                generate TLSA record (default:yes)
   --eecert              use EEcert for TLSA record (default)
   --cacert              use CAcert for TLSA record
   --pubkey              use pubkey for TLSA record (not supported yet)
   --txt                 generate Kaminsky style TXT record (not supported yet)
   --sha256              use SHA256 for the TLSA cert type
   --sha512              use SHA512 for the TLSA cert type
   --full                use full certificate for the TLSA cert type
   --insecure            allow use of non-dnssec answers to find SSL hosts
   -4                    use ipv4 networking only
   -6                    use ipv6 networking only
   -q, --quiet           suppress warnings and errors

[paul@thinkpad ~]$ dane www.xelerance.com
_443._tcp.www.xelerance.com. IN TYPE65468 \# 34 010130102FA54AE5CD5852D0CFAF1FE5F467C547D766A13410079BB2B01319B702B9

[paul@thinkpad ~]$ dane www.xelerance.com --sha512
_443._tcp.www.xelerance.com. IN TYPE65468 \# 66 01025FFE99D2E9488963FCFB36139BBE2A64B4AB2EBF845C5BEB8FE666BE0490328E6D625A3D6AC522377A4997B0141357A340C1A9771D3AA9A9F72DC102F306974C

[paul@thinkpad ~]$ dane www.eff.org
Aborted: dnssec required but DNS lookup was insecure (use --insecure to override)

[paul@thinkpad ~]$ dane www.eff.org --insecure
_443._tcp.www.eff.org. IN TYPE65468 \# 34 01017E408A6A3B2E9C3A6D21579CCD5C78F300881878AEBD0252974160CB892BD82D

[paul@thinkpad ~]$ dane www.xelerance.com --rfc --full
_443._tcp.www.xelerance.com. IN TLSA 1 0 308207AE30820596A003020102020107300D06092A864886F70D01010505003081C3310B30090603550406130243413110300E060355040813074F6E746172696F310F300D060355040713064F7474617761311E301C060355040A131558656C6572616E636520436F72706F726174696F6E31293027060355040B13204F70656E20536F75726365205365637572697479205370656369616C69737473311C301A0603550403131358656C6572616E63652[...]

[paul@thinkpad ~]$ dane --quiet xelerance.com @vault.xelerance.com
_443._tcp.xelerance.com. IN TYPE65468 \# 34 0101C71024963D065F4F5CFADCDD0CB72BAE0CBF92671F859A0AB1F24D2682E39F2B
_443._tcp.admin.xelerance.com. IN TYPE65468 \# 34 0101C71024963D065F4F5CFADCDD0CB72BAE0CBF92671F859A0AB1F24D2682E39F2B
_443._tcp.bugs.xelerance.com. IN TYPE65468 \# 34 0101354D89598CB94AB59AD5D6781EA49F34BF964548EB4480831EDA0EA47A97A333
_443._tcp.calendar.xelerance.com. IN TYPE65468 \# 34 0101C71024963D065F4F5CFADCDD0CB72BAE0CBF92671F859A0AB1F24D2682E39F2B
_443._tcp.calender.xelerance.com. IN TYPE65468 \# 34 0101C71024963D065F4F5CFADCDD0CB72BAE0CBF92671F859A0AB1F24D2682E39F2B
_443._tcp.certs.xelerance.com. IN TYPE65468 \# 34 01014BE08D87673F3B2FE4981E03ED2871A6ED9C7A6B55C38574FFDBCE482722B1FC
_443._tcp.csis2.xelerance.com. IN TYPE65468 \# 34 010127438F9C4860F788220A3008AAA696A10A6102ABD11378192471173E5337DE6B
_443._tcp.dane.xelerance.com. IN TYPE65468 \# 34 0101E8F192E559F94CA9DD1D16E900DF24D7733BDF76E8497C9E658EAE57E05836F6
_443._tcp.badsig.dane.xelerance.com. IN TYPE65468 \# 34 0101E8F192E559F94CA9DD1D16E900DF24D7733BDF76E8497C9E658EAE57E05836F6
_443._tcp.full.dane.xelerance.com. IN TYPE65468 \# 34 0101E8F192E559F94CA9DD1D16E900DF24D7733BDF76E8497C9E658EAE57E05836F6
_443._tcp.sha256.dane.xelerance.com. IN TYPE65468 \# 34 0101E8F192E559F94CA9DD1D16E900DF24D7733BDF76E8497C9E658EAE57E05836F6
_443._tcp.sha512.dane.xelerance.com. IN TYPE65468 \# 34 0101E8F192E559F94CA9DD1D16E900DF24D7733BDF76E8497C9E658EAE57E05836F6
_443._tcp.demo2.xelerance.com. IN TYPE65468 \# 34 010187FFFC5D8686B396FDB6A833F1FCD1253C5967457D3AF74EC23C495C8164FCED
_443._tcp.demo3.xelerance.com. IN TYPE65468 \# 34 010187FFFC5D8686B396FDB6A833F1FCD1253C5967457D3AF74EC23C495C8164FCED
[...]

For those people testing code, the DANE record for badsig.dane.xelerance.com has been broken on purpose:

_443._tcp.badsig.dane.xelerance.com. 3595 IN TYPE65468 \# 34 ( 01010000000000000000000000000000000000000000
 				000000000000000000000000 )

Paul

From [email-masked]  Tue Apr 12 23:42:08 2011
From: Matt McCutchen <[email-masked]>
To: [email-masked]
Date: Wed, 13 Apr 2011 02:42:04 -0400
Subject: Re: [dane] Proof-of-concept implementation for NSS

On Wed, 2011-02-16 at 00:21 -0500, Matt McCutchen wrote:
> [...] https://mattmccutchen.net/cryptid/#nss-dane

Paul Wouters's work
(https://www.ietf.org/mail-archive/web/dane/current/msg02402.html) has
finally enticed me to update the hash types.  I have posted a new
version that supports the current types 0 (full), 1 (SHA-256), and 2
(SHA-512), and it is easy to add other algorithms supported by NSS.

I have updated the data for https://mattmccutchen.net correspondingly.
The client seems to work with
https://{sha256,sha512,full}.dane.xelerance.com as well.

-- 
Matt

From [email-masked]  Wed Apr 13 08:50:05 2011
Date: Wed, 13 Apr 2011 11:49:59 -0400
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [dane] Use Cases Document

On Wed, Apr 13, 2011 at 02:14:44PM +1200, Peter Gutmann wrote:
> modes.  Theorising over usage cases (real or imagined) didn't seem too useful
> unless we could first understand how things are failing today.  So rather than

Why?  Who cares what fails now?  The question is, "What are things you
want to do?"  The reason you might want to do them (like, for
instance, you think the other way to achieve a similar result is
broken) is not relevant until someone says, "You can already do that."

At such a time, I could see an argument for why we have to debate the
merits of the existing system.  Otherwise, I think it's a distraction.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

From [email-masked]  Wed Apr 13 14:11:56 2011
Date: Wed, 13 Apr 2011 14:11:54 -0700
From: Kirk Hall <[email-masked]>
To: [email-masked], Christopher Morrow <[email-masked]>
Subject: [dane] Expectations for Self-Signed Cert Trust Indicators under DANE
Reply-To: [email-masked]

--bcaec51b1aab21850f04a0d342b7
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

I tried to post this message earlier, but it wasn=92t sent out by the
list-serv.  So I=92ll try again in a new thread.

This conversation started with my first posting,
http://www.ietf.org/mail-archive/web/dane/current/msg02326.html, and the
most recent response was from Chris Morrow at
http://www.ietf.org/mail-archive/web/dane/current/msg02378.html

* * * * *
Chris, thanks for your response.

I agree there=92s no point in trying to define UI specs in this DANE propos=
al
=96 but the Abstract for DANE does say =93Instead of trusting a certificati=
on
authority to have made this association correctly, the user might instead
trust the authoritative DNS server for the domain name to make that
association.=94  So the question of trust and even user reaction under DANE
(trust a self-signed cert instead of a CA cert) has been introduced.  And
some people have already posted that they want browsers and other
applications to treat a self-signed cert as equal to a DV cert under DANE,
so the question of desired UI result has been introduced to the discussion.

If the ONLY thing you want DANE to do is allow an automatic TLS connection
at the DNS level using any cert =96 then I can see why you would think
requiring what I called an anti-fraud check is irrelevant.  However, I fear
that DANE will be leaving consumers / browsers / applications with no way t=
o
distinguish between a self-signed cert that has been checked for fraud
versus a self-signed cert that has not.

That may mean DANE doesn=92t get widespread adoption =96 because browsers a=
nd
applications won=92t give it any recognition.  The browsers have been very
wary in the past of accepting self-signed certs for any purpose connected
with trust indicators, and may not even want to give consumers the basic
trust indicator =93you are in TLS session=94 in DANE with a self-signed cer=
t.
Why?  Because for years the browsers have been telling consumers =93you are
safer if you are encrypted=94 =96 which may or may not be true in DANE with=
 a
self-signed cert from an unknown source.

You=92re correct that phishing and fraud haven=92t used SSL much in the pas=
t =96
I=92d argue that=92s partly because CAs generally filter out cert requests =
from
those guys.  Every day at GeoTrust we received numerous requests from
phishers trying to get look-alike domains (e.g., paypall.com) certified, an=
d
we turned them down. If we had let these request go through simply because
the phishers had control over the domain (which they did), I believe there
would have been many more convincing phishing attacks targeted at consumers
using SSL, and losses would have been substantial.

CAs are already a huge target for phishers, and the phishers will quickly
exploit DANE if they can provide trusted SSL connections to consumers using
a self-signed cert.  For example, if DANE allows a phisher or look-alike
domain to use a self-signed cert at the DNS level, and if the browsers and
applications give that domain the same TLS trust indicators as they do for,
say, DV certs, the phishers will likely move to self-signed certs in order
to get the trust indicators.  That=92s why I think the browsers won=92t gra=
nt
any trust indicator to DANE self-signed certs unless you provide a flag or
some other means of identification for self-signed certs that have been
fraud-checked so they can be distinguished from other self-signed certs.

If you have no expectation of receiving any trust indicators for DANE from
the browsers and other applications =96 fine, you won=92t be disappointed.
Otherwise, I think you will.

One question to you:  what practical, actual, real world problem is DANE
trying to solve?  Is there, in fact, a real security need today for someone
to =93know=94 that they have reached the domain they intended to reach?  (T=
oday,
browsers tell you if there is a mismatch between a domain name and a
CA-issued cert on that domain=92s servers, so to some degree that potential
security issue is already resolved.)  Do you have examples today of actual
problems where people are unsure if they have connected with the domains
they wanted, and there is a bad result?  (And if your example depends on
=93assume there has been a compromise of the DNS=94 =96 aren=92t all bets o=
ff in
that situation, where no solution is reliable?)  I=92m not trying to be
provocative =96 I really want to know what problem that actually exists tod=
ay
would be solved with DANE.

Thanks.

--bcaec51b1aab21850f04a0d342b7
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div>I tried to post this message earlier, but it wasn=92t sent out by the =
list-serv.=A0 So I=92ll try again in a new thread.=A0 </div>
<div>=A0</div>
<div>This conversation started with my first posting, <a href=3D"http://www=
.ietf.org/mail-archive/web/dane/current/msg02326.html" target=3D"_blank">ht=
tp://www.ietf.org/mail-archive/web/dane/current/msg02326.html</a>, and the =
most recent response was from Chris Morrow at <a href=3D"http://www.ietf.or=
g/mail-archive/web/dane/current/msg02378.html" target=3D"_blank">http://www=
.ietf.org/mail-archive/web/dane/current/msg02378.html</a><br>
=A0<br>* * * * *<br>Chris, thanks for your response.<br>=A0<br>I agree ther=
e=92s no point in trying to define UI specs in this DANE proposal =96 but t=
he Abstract for DANE does say =93Instead of trusting a certification author=
ity to have made this association correctly, the user might instead trust t=
he authoritative DNS server for the domain name to make that association.=
=94=A0 So the question of trust and even user reaction under DANE (trust a =
self-signed cert instead of a CA cert) has been introduced.=A0 And some peo=
ple have already posted that they want browsers and other applications to t=
reat a self-signed cert as equal to a DV cert under DANE, so the question o=
f desired UI result has been introduced to the discussion.<br>
=A0<br>If the ONLY thing you want DANE to do is allow an automatic TLS conn=
ection at the DNS level using any cert =96 then I can see why you would thi=
nk requiring what I called an anti-fraud check is irrelevant.=A0 However, I=
 fear that DANE will be leaving consumers / browsers / applications with no=
 way to distinguish between a self-signed cert that has been checked for fr=
aud versus a self-signed cert that has not.=A0 <br>
=A0<br>That may mean DANE doesn=92t get widespread adoption =96 because bro=
wsers and applications won=92t give it any recognition.=A0 The browsers hav=
e been very wary in the past of accepting self-signed certs for any purpose=
 connected with trust indicators, and may not even want to give consumers t=
he basic trust indicator =93you are in TLS session=94 in DANE with a self-s=
igned cert.=A0 Why?=A0 Because for years the browsers have been telling con=
sumers =93you are safer if you are encrypted=94 =96 which may or may not be=
 true in DANE with a self-signed cert from an unknown source.<br>
=A0<br>You=92re correct that phishing and fraud haven=92t used SSL much in =
the past =96 I=92d argue that=92s partly because CAs generally filter out c=
ert requests from those guys.=A0 Every day at GeoTrust we received numerous=
 requests from phishers trying to get look-alike domains (e.g., <a href=3D"=
http://paypall.com/" target=3D"_blank">paypall.com</a>) certified, and we t=
urned them down. If we had let these request go through simply because the =
phishers had control over the domain (which they did), I believe there woul=
d have been many more convincing phishing attacks targeted at consumers usi=
ng SSL, and losses would have been substantial. <br>
=A0<br>CAs are already a huge target for phishers, and the phishers will qu=
ickly exploit DANE if they can provide trusted SSL connections to consumers=
 using a self-signed cert.=A0 For example, if DANE allows a phisher or look=
-alike domain to use a self-signed cert at the DNS level, and if the browse=
rs and applications give that domain the same TLS trust indicators as they =
do for, say, DV certs, the phishers will likely move to self-signed certs i=
n order to get the trust indicators.=A0 That=92s why I think the browsers w=
on=92t grant any trust indicator to DANE self-signed certs unless you provi=
de a flag or some other means of identification for self-signed certs that =
have been fraud-checked so they can be distinguished from other self-signed=
 certs.<br>
=A0<br>If you have no expectation of receiving any trust indicators for DAN=
E from the browsers and other applications =96 fine, you won=92t be disappo=
inted.=A0 Otherwise, I think you will.<br>=A0<br>One question to you:=A0 wh=
at practical, actual, real world problem is DANE trying to solve?=A0 Is the=
re, in fact, a real security need today for someone to =93know=94 that they=
 have reached the domain they intended to reach?=A0 (Today, browsers tell y=
ou if there is a mismatch between a domain name and a CA-issued cert on tha=
t domain=92s servers, so to some degree that potential security issue is al=
ready resolved.)=A0 Do you have examples today of actual problems where peo=
ple are unsure if they have connected with the domains they wanted, and the=
re is a bad result?=A0 (And if your example depends on =93assume there has =
been a compromise of the DNS=94 =96 aren=92t all bets off in that situation=
, where no solution is reliable?)=A0 I=92m not trying to be provocative =96=
 I really want to know what problem that actually exists today would be sol=
ved with DANE.<br>
=A0<br>Thanks.</div>

--bcaec51b1aab21850f04a0d342b7--

From [email-masked]  Wed Apr 13 14:34:39 2011
From: Nicholas Weaver <[email-masked]>
Date: Wed, 13 Apr 2011 14:34:37 -0700
To: Kirk Hall <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: Re: [dane] Expectations for Self-Signed Cert Trust Indicators under DANE

> One question to you:  what practical, actual, real world problem is =
DANE trying to solve?  Is there, in fact, a real security need today for =
someone to =93know=94 that they have reached the domain they intended to =
reach?  (Today, browsers tell you if there is a mismatch between a =
domain name and a CA-issued cert on that domain=92s servers, so to some =
degree that potential security issue is already resolved.)  Do you have =
examples today of actual problems where people are unsure if they have =
connected with the domains they wanted, and there is a bad result?  (And =
if your example depends on =93assume there has been a compromise of the =
DNS=94 =96 aren=92t all bets off in that situation, where no solution is =
reliable?)  I=92m not trying to be provocative =96 I really want to know =
what problem that actually exists today would be solved with DANE.

The actual, real world problem:

The CA system is irrevocably broken: There are hundreds of potential =
paths of trust, ANY of which can create a DV intercepting certificate =
for a targeted name.

There are incidents we know about happening (Comodo), and there are ones =
we've suspected have happened (governments have the ability to purchase =
"SSL interception boxes" as commercial products that just need a =
wildcard certificate.  Such products wouldn't exist if governments =
couldn't get wildcard certificates) but don't have captured certificates =
to prove.

DANE with just a self-signed certificate reduces the paths of trust to a =
SINGLE path of trust, concurrent with the DNS resolution path for the =
name.

I can NEVER hope to trust "have to trust ALL of a set of hundreds", but =
I MIGHT be able to trust "have to trust just a single path".

There's also an economic problem.  There is no logistical reason why a =
CA should charge 10x for *.mydomain.com when compared with =
www.mydomain.com.  But they do. =20

DANE with self-signed certificates gives *.mydomain.com, able to sign =
anything in .mydomain.com, 'for free'.

The economic driver is IMO, enough to accomplish the real goal: DANE =
with CA certs, which now means that two separate paths of trust (the =
'one of a hundred' CA plus the 'single-path' DNSSEC) needs to be =
compromised.

From [email-masked]  Wed Apr 13 14:50:04 2011
From: James Cloos <[email-masked]>
To: [email-masked]
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC
Copyright: Copyright 2011 James Cloos
OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
Date: Wed, 13 Apr 2011 17:49:23 -0400
Lines: 18
Subject: [dane] Should we rename the "certificate type" octet

The draft posits a one octet value specifying the kind of cert.

Perhaps it would be better to have that octet specify the chain length.

If it is 0, then the tls/dtls client should compare the reference
against the server's immediate cert.  Otherwise it should expect a
chain of n certs (or up to n certs?) and compare the reference to
the anchor of the transmitted chain.

Alternatively, we could rename cert type 2 from a "CA" cert to a
"Trust Anchor (TA)" cert.

Either way it should make the intent more explicit and, with luck,
ameliorate some of the concerns expressed in recent days.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

From [email-masked]  Wed Apr 13 15:03:52 2011
From: Tom Ritter <[email-masked]>
Date: Wed, 13 Apr 2011 18:03:28 -0400
To: [email-masked], [email-masked]
Subject: Re: [dane] Expectations for Self-Signed Cert Trust Indicators under DANE

> However, I fear
> that DANE will be leaving consumers / browsers / applications with no way=
 to
> distinguish between a [cert] that has been checked for fraud
> versus a self-signed cert that has not.

That's a reasonable fear, but I consider it unlikely that the eventual
UI implementations in browsers would do that.
For other applications that don't always provide a UI, these
applications either broke or continued on in case of mismatch.  Only
the scenario of a typo and a typo-squatter would this be a concern.
And applications that provide no UI are used primarily by system
administrators *or* in embedded scenarios where the address is
hardcoded.  If it accepts interactive user input, by definition it has
a UI.

> That may mean DANE doesn=92t get widespread adoption =96 because browsers=
 and
> applications won=92t give it any recognition.=A0 The browsers have been v=
ery
> wary in the past of accepting self-signed certs for any purpose connected
> with trust indicators, and may not even want to give consumers the basic
> trust indicator =93you are in TLS session=94 in DANE with a self-signed c=
ert.
> Why?=A0 Because for years the browsers have been telling consumers =93you=
 are
> safer if you are encrypted=94 =96 which may or may not be true in DANE wi=
th a
> self-signed cert from an unknown source.

I think you're confusing widespread adoption with 'widespread
commercial adoption'.  If an organization has an incentive to
encourage its users to feel safe on their website (e.g. a bank)
they're already using SSL certificates, usually EV ones that light up
the address bar all green and happy and proudly tout that.  They'll
use whatever mechanism gets them the green address bar (the positive
UI indicator).

> CAs are already a huge target for phishers, and the phishers will quickly
> exploit DANE if they can provide trusted SSL connections to consumers usi=
ng
> a self-signed cert.=A0 For example, if DANE allows a phisher or look-alik=
e
> domain to use a self-signed cert at the DNS level, and if the browsers an=
d
> applications give that domain the same TLS trust indicators as they do fo=
r,
> say, DV certs, the phishers will likely move to self-signed certs in orde=
r
> to get the trust indicators.=A0 That=92s why I think the browsers won=92t=
 grant
> any trust indicator to DANE self-signed certs

I agree with these statements (which I cut off early, and corrected
above).  I'm confused by the phrase "self-signed cert that has been
checked for fraud".  I don't understand how such a cert could exist,
because if it was purely self-signed, I could just generate it that
way myself.  I can only imagine that the cert is signed by some
external agency that's checked for fraud - making it not-self-signed.

> If you have no expectation of receiving any trust indicators for DANE fro=
m
> the browsers and other applications =96 fine, you won=92t be disappointed=
.

I don't.  I would like to have a subtle visual indicator, and not a
warning screen.

> One question to you:=A0 what practical, actual, real world problem is DAN=
E
> trying to solve?

I can't speak to the actual mission statement of the list or Working
Group, but for me it's to lower the bar necessary for widespread
implementation of TLS across all websites and other services (mail
where it isn't,  applications that speak HTTP, and so on).  The
actual, real world problem *that* would solve would be preventing the
mass of people between me and the website I'm visiting from reading my
activity.  Sure, my bank is encrypted, but until recently facebook was
not, what articles I'm reading online, what I'm browsing in an online
shop, and so on.  Authenticating the other end is implicit in my
statements.

> Is there, in fact, a real security need today for someone
> to =93know=94 that they have reached the domain they intended to reach?=
=A0 (Today,
> browsers tell you if there is a mismatch between a domain name and a
> CA-issued cert on that domain=92s servers, so to some degree that potenti=
al
> security issue is already resolved.)

I don't think you're paranoid enough.  Yes, I consider it very
important, and a real security need, that my parents wireless router
has not been co-opted into redirecting them.  I'd like to feel
comfortable connecting to an Access Point in Starbucks or McDonalds.
As you mention, a solution exists already (CA's) - but the fact that
TLS has not been adopted universally indicates the barrier to adoption
is still too high.  You can argue that it's not CA's that push off the
adoption, it's CPUs or whatever - that's both irrelevant to this list
*and* being worked on elsewhere.

> Do you have examples today of actual
> problems where people are unsure if they have connected with the domains
> they wanted, and there is a bad result?

https://bugzilla.mozilla.org/show_bug.cgi?id=3D460374

I understand that CA's want to protect their business interests, and I
recognize that if DANE-Provided Self-Signed certs were shown in the
browser in the same manner as EV Certs there wouldn't be any need for
CAs.  But that's hyperbole - I doubt anyone is pushing for that, I
doubt further a browser would consider it.  I expect that institutions
whose image depends on making their users comfortable will *always*
employ CAs, and that the application users use to connect to those
institutions for their critical transactions will *always* provide a
mechanism to show that this institution has used the highest form of
trustworthiness, and everyone gets warm fuzzies - the user, the
institution, and the CA.

Finally, to Nicholas' email, which I mostly agree with:

> The CA system is irrevocably broken: There are hundreds of potential path=
s of trust, ANY of which can create a DV intercepting certificate for a tar=
geted name.
> DANE with just a self-signed certificate reduces the paths of trust to a =
SINGLE path of trust, concurrent with the DNS resolution path for the name.

Maybe this has been discussed, but does DANE provide recommendations
for the scenario where we have conflicting input from different trust
anchors?  A valid CA certificate *and* a valid record via DANE, both
different?  *Should* it?  It seems that for people concerned about the
high-high level problems (such as government interception and whether
you can trust ccTLDs) this would be very important.  Perhaps this
should be broken out into a seperate thread if it has not been raised.

Related to Nicholas' statements: there's been mild discussion about
things like CA-pinning and restricting what TLDs CAs could sign for to
compartmentalize a internet-wide epidemic *if* a Comodo-type attack
happened and went undetected for some time.  They're not applicable to
this list, I just wanted to mention them, anyone can contact me off
list and I'll point you in the right direction.

-tom

From [email-masked]  Wed Apr 13 15:07:43 2011
Date: Wed, 13 Apr 2011 18:07:40 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Nicholas Weaver <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [dane] Expectations for Self-Signed Cert Trust Indicators under DANE

--20cf3071cebca0bf3904a0d40914
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Can we stop the hyperbole?

How many fraudulently issued CA certs in 15 years?
How many subjects lost control of their private key?

It is really easy to poke holes in an existing deployed security control.
And really easy to propose alternatives that work perfectly in theory if yo=
u
assume that they are not subject to the same issues.

There are use cases for DV certs, but not in my view use cases that involve
humans.

On Wed, Apr 13, 2011 at 5:34 PM, Nicholas Weaver
<[email-masked]>wrote:

>
>
> > One question to you:  what practical, actual, real world problem is DAN=
E
> trying to solve?  Is there, in fact, a real security need today for someo=
ne
> to =93know=94 that they have reached the domain they intended to reach?  =
(Today,
> browsers tell you if there is a mismatch between a domain name and a
> CA-issued cert on that domain=92s servers, so to some degree that potenti=
al
> security issue is already resolved.)  Do you have examples today of actua=
l
> problems where people are unsure if they have connected with the domains
> they wanted, and there is a bad result?  (And if your example depends on
> =93assume there has been a compromise of the DNS=94 =96 aren=92t all bets=
 off in
> that situation, where no solution is reliable?)  I=92m not trying to be
> provocative =96 I really want to know what problem that actually exists t=
oday
> would be solved with DANE.
>
> The actual, real world problem:
>
> The CA system is irrevocably broken: There are hundreds of potential path=
s
> of trust, ANY of which can create a DV intercepting certificate for a
> targeted name.
>
> There are incidents we know about happening (Comodo), and there are ones
> we've suspected have happened (governments have the ability to purchase "=
SSL
> interception boxes" as commercial products that just need a wildcard
> certificate.  Such products wouldn't exist if governments couldn't get
> wildcard certificates) but don't have captured certificates to prove.
>
>
> DANE with just a self-signed certificate reduces the paths of trust to a
> SINGLE path of trust, concurrent with the DNS resolution path for the nam=
e.
>
> I can NEVER hope to trust "have to trust ALL of a set of hundreds", but I
> MIGHT be able to trust "have to trust just a single path".
>
>
> There's also an economic problem.  There is no logistical reason why a CA
> should charge 10x for *.mydomain.com when compared with www.mydomain.com.
>  But they do.
>
> DANE with self-signed certificates gives *.mydomain.com, able to sign
> anything in .mydomain.com, 'for free'.
>
>
> The economic driver is IMO, enough to accomplish the real goal: DANE with
> CA certs, which now means that two separate paths of trust (the 'one of a
> hundred' CA plus the 'single-path' DNSSEC) needs to be compromised.
>
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

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

--20cf3071cebca0bf3904a0d40914
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Can we stop the hyperbole?<div><br></div><div>How many fraudulently issued =
CA certs in 15 years?</div><div>How many subjects lost control of their pri=
vate key?<br><br></div><div>It is really easy to poke holes in an existing =
deployed security control. And really easy to propose alternatives that wor=
k perfectly in theory if you assume that they are not subject to the same i=
ssues.</div>
<div><br></div><div><br></div><div>There are use cases for DV certs, but no=
t in my view use cases that involve humans.=A0<br><div class=3D"gmail_quote=
"><br></div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote"=
>On Wed, Apr 13, 2011 at 5:34 PM, Nicholas Weaver <span dir=3D"ltr">&lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>&gt;=
</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;"><div class=3D"im"><br>
<br>
&gt; One question to you: =A0what practical, actual, real world problem is =
DANE trying to solve? =A0Is there, in fact, a real security need today for =
someone to =93know=94 that they have reached the domain they intended to re=
ach? =A0(Today, browsers tell you if there is a mismatch between a domain n=
ame and a CA-issued cert on that domain=92s servers, so to some degree that=
 potential security issue is already resolved.) =A0Do you have examples tod=
ay of actual problems where people are unsure if they have connected with t=
he domains they wanted, and there is a bad result? =A0(And if your example =
depends on =93assume there has been a compromise of the DNS=94 =96 aren=92t=
 all bets off in that situation, where no solution is reliable?) =A0I=92m n=
ot trying to be provocative =96 I really want to know what problem that act=
ually exists today would be solved with DANE.<br>

<br>
</div>The actual, real world problem:<br>
<br>
The CA system is irrevocably broken: There are hundreds of potential paths =
of trust, ANY of which can create a DV intercepting certificate for a targe=
ted name.<br>
<br>
There are incidents we know about happening (Comodo), and there are ones we=
&#39;ve suspected have happened (governments have the ability to purchase &=
quot;SSL interception boxes&quot; as commercial products that just need a w=
ildcard certificate. =A0Such products wouldn&#39;t exist if governments cou=
ldn&#39;t get wildcard certificates) but don&#39;t have captured certificat=
es to prove.<br>

<br>
<br>
DANE with just a self-signed certificate reduces the paths of trust to a SI=
NGLE path of trust, concurrent with the DNS resolution path for the name.<b=
r>
<br>
I can NEVER hope to trust &quot;have to trust ALL of a set of hundreds&quot=
;, but I MIGHT be able to trust &quot;have to trust just a single path&quot=
;.<br>
<br>
<br>
There&#39;s also an economic problem. =A0There is no logistical reason why =
a CA should charge 10x for *.<a href=3D"http://mydomain.com" target=3D"_bla=
nk">mydomain.com</a> when compared with <a href=3D"http://www.mydomain.com"=
 target=3D"_blank">www.mydomain.com</a>. =A0But they do.<br>

<br>
DANE with self-signed certificates gives *.<a href=3D"http://mydomain.com" =
target=3D"_blank">mydomain.com</a>, able to sign anything in .<a href=3D"ht=
tp://mydomain.com" target=3D"_blank">mydomain.com</a>, &#39;for free&#39;.<=
br>

<br>
<br>
The economic driver is IMO, enough to accomplish the real goal: DANE with C=
A certs, which now means that two separate paths of trust (the &#39;one of =
a hundred&#39; CA plus the &#39;single-path&#39; DNSSEC) needs to be compro=
mised.<br>

<br>
_______________________________________________<br>
dane mailing list<br>
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/dane</a><br>
</blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a href=3D"htt=
p://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--20cf3071cebca0bf3904a0d40914--

From [email-masked]  Wed Apr 13 15:17:35 2011
Date: Wed, 13 Apr 2011 18:17:32 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: James Cloos <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] Should we rename the "certificate type" octet

On Wed, 13 Apr 2011, James Cloos wrote:

> The draft posits a one octet value specifying the kind of cert.
>
> Perhaps it would be better to have that octet specify the chain length.
>
> If it is 0, then the tls/dtls client should compare the reference
> against the server's immediate cert.  Otherwise it should expect a
> chain of n certs (or up to n certs?) and compare the reference to
> the anchor of the transmitted chain.
>
> Alternatively, we could rename cert type 2 from a "CA" cert to a
> "Trust Anchor (TA)" cert.
>
> Either way it should make the intent more explicit and, with luck,
> ameliorate some of the concerns expressed in recent days.

That would hinder future non-cert type based authentication, so I am
very much against ingraining more PKIX concepts. TLSA should be as
trust-model agnostic as possible.

Paul

From [email-masked]  Wed Apr 13 15:20:05 2011
Date: Wed, 13 Apr 2011 18:20:02 -0400
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [dane] Expectations for Self-Signed Cert Trust Indicators under DANE

On Wed, Apr 13, 2011 at 02:11:54PM -0700, Kirk Hall wrote:
> â€“ but the Abstract for DANE does say â€œInstead of trusting a certification
> authority to have made this association correctly, the user might instead
> trust the authoritative DNS server for the domain name to make that
> association.â€  So the question of trust and even user reaction under DANE
> (trust a self-signed cert instead of a CA cert) has been introduced.

I would like to propose that the text be changed s/user/client/.  Then
we don't have that problem and we can move on without boiling the
ocean, mapping the known universe, and solving every UI problem in the
world.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

From [email-masked]  Wed Apr 13 15:42:23 2011
Sender: [email-masked]
Date: Wed, 13 Apr 2011 15:42:22 -0700
From: Zack Weinberg <[email-masked]>
To: [email-masked]
Subject: Re: [dane] Requirements - HTTPS

On Sun, Apr 10, 2011 at 5:00 AM, Phillip Hallam-Baker <[email-masked]> wrote:
> On Sat, Apr 9, 2011 at 10:33 PM, Scott Schmit <[email-masked]> wrote:
>>
>> Sure, but what's the browser going to do when the A/AAAA record comes
>> through fine, signatures and all, but the TLSA record results get
>> blocked? The client might treat it as a network problem instead of a
>> security problem.
>>
>> I think that's what Phillip is concerned about.
>
> Yes, I can't see how anyone is going to hard fail that case.

If clients don't treat that case as identical to getting back a TLSA
record with "bogus" validation state, then a downgrade attack is
trivial and TLSA provides no real security benefit.

Perhaps TLSA will end up not being adopted because its requirements
are too hard to implement in a performant way and client vendors make
the decision that performance is more important than whatever security
increment it provides.  But if the specification doesn't provide any
security increment in the first place, we may as well scrap the idea.

zw

From [email-masked]  Wed Apr 13 15:47:56 2011
From: Matt McCutchen <[email-masked]>
To: [email-masked]
Date: Wed, 13 Apr 2011 18:47:52 -0400
Cc: [email-masked]
Subject: Re: [dane] Expectations for Self-Signed Cert Trust Indicators under DANE

On Wed, 2011-04-13 at 14:11 -0700, Kirk Hall wrote:
> If the ONLY thing you want DANE to do is allow an automatic TLS
> connection at the DNS level using any cert =E2=80=93 then I can see why=
 you
> would think requiring what I called an anti-fraud check is irrelevant.
> However, I fear that DANE will be leaving consumers / browsers /
> applications with no way to distinguish between a self-signed cert
> that has been checked for fraud versus a self-signed cert that has
> not.

Well, applications that want to alert users to fraudulent (or harmful)
sites will need a separate mechanism to do so.  A priori, this has
nothing to do with server-authenticated TLS.  I suggest that those
interested in this functionality take a fresh look at the design space
assuming that authentication is now being provided via DANE.  The
existing DV system is one approach, but it may not be the best.

> That may mean DANE doesn=E2=80=99t get widespread adoption =E2=80=93 be=
cause browsers
> and applications won=E2=80=99t give it any recognition.  The browsers h=
ave
> been very wary in the past of accepting self-signed certs for any
> purpose connected with trust indicators,

Of course, because they provide no authentication.

> and may not even want to give consumers the basic trust indicator =E2=80=
=9Cyou
> are in TLS session=E2=80=9D in DANE with a self-signed cert.  Why?  Bec=
ause
> for years the browsers have been telling consumers =E2=80=9Cyou are saf=
er if
> you are encrypted=E2=80=9D =E2=80=93 which may or may not be true in DA=
NE with a
> self-signed cert from an unknown source.

Mozilla has been working to correct that misconception.  The DV UI in
Firefox 4 is carefully designed to indicate only authenticated TLS, so
it could be appropriately applied to a site that has only authenticated
TLS, if Mozilla so chooses.  Ultimately, we may want different
indicators for authenticated TLS without and with a fraud check, but I
definitely want to have the former and would not agree that it is
impossible to do without misleading the user.

In any event, fraud concerns apply only to the identity information
displayed on tabs.  SSL_AuthCertificate can continue to check only
authentication, and XMLHttpRequests and the like can go on their merry
way.

> You=E2=80=99re correct that phishing and fraud haven=E2=80=99t used SSL=
 much in the
> past =E2=80=93 I=E2=80=99d argue that=E2=80=99s partly because CAs gene=
rally filter out cert
> requests from those guys.

I'll buy this.

--=20
Matt

From [email-masked]  Wed Apr 13 15:48:19 2011
Sender: [email-masked]
Date: Wed, 13 Apr 2011 15:48:18 -0700
From: Zack Weinberg <[email-masked]>
To: [email-masked]
Subject: Re: [dane] Requirements - HTTPS

On Sun, Apr 10, 2011 at 3:50 PM, Steve Schultze <[email-masked]> wrote:
>>
>> Ok, thanks for clarifying. If TLSA records are being stripped the client=
 has
>> evidence that someone is playing shenanigans and should panic, shouldn't=
 it?
>
> Yes, I think it should. =C2=A0Otherwise we introduce a downgrade attack v=
ector (issue #6).

I entirely agree.

> The text in section 3 also does not clearly address this. =C2=A0I'd like =
to suggest again that
> we consider a version of Matt's proposed text for Section 3. =C2=A0It cle=
arly outlines the
> different responses and results. =C2=A0Back in January, Paul suggested th=
at we wait on
> deciding this, but perhaps now is a good time.

I also drafted revisions to section 3:
http://www.ietf.org/mail-archive/web/dane/current/msg02056.html

I'm not insisting on mine rather than Matt's, but I do think that
*some* very clearly spelled out language for how the client decides
what to do is desired.  I didn't think to mention "query cannot be
completed" as a failure case, perhaps I should have.

zw

From [email-masked]  Wed Apr 13 16:03:18 2011
From: Matt McCutchen <[email-masked]>
To: dane <[email-masked]>
Date: Wed, 13 Apr 2011 19:03:14 -0400
Subject: [dane] Authentication, and everything else

On Wed, 2011-04-13 at 18:20 -0400, Andrew Sullivan wrote:
> On Wed, Apr 13, 2011 at 02:11:54PM -0700, Kirk Hall wrote:
> > =E2=80=93 but the Abstract for DANE does say =E2=80=9CInstead of trus=
ting a certification
> > authority to have made this association correctly, the user might ins=
tead
> > trust the authoritative DNS server for the domain name to make that
> > association.=E2=80=9D  So the question of trust and even user reactio=
n under DANE
> > (trust a self-signed cert instead of a CA cert) has been introduced.
>=20
> I would like to propose that the text be changed s/user/client/.  Then
> we don't have that problem and we can move on without boiling the
> ocean, mapping the known universe, and solving every UI problem in the
> world.

I don't think we even need to do that.  The draft addresses only
authentication of a TLS service associated with a domain name.  The word
"trust" is used in reference to that association.

The fraud, UI, etc. issues are out of scope of DANE per se, but they are
critical to the goals that I and others have for the bigger picture,
hence we want to discuss them.  If the discussion is not welcome here,
we should find another venue.  You'd think it would be in scope of
mozilla.dev.security.policy, but they don't seem too interested.  I may
start my own mailing list.

--=20
Matt

From [email-masked]  Wed Apr 13 16:08:15 2011
Sender: [email-masked]
Date: Wed, 13 Apr 2011 16:08:13 -0700
From: Zack Weinberg <[email-masked]>
To: [email-masked]
Subject: Re: [dane] A browser's myopic view

On Sat, Apr 9, 2011 at 2:12 PM, Adam Langley <[email-masked]> wrote:
> The problem with a hard failure on exclusion is that it means that we
> *have* to get the DNS information before sending application data on a
> TLS connection, or we have to have it cached.

True.

> In the event that we don't have it cached, getting the information
> from DNS is a problem. I ran an experiment in Chrome doing lookups for
> an odd DNS RRTYPE (13172) concurrently with the A lookup for HTTPS
> URLs. 2.5% of the time, the result came in over 100ms after we had
> completed the A lookup, TCP connection, TLS handshake and certificate
> verification! Somewhere between 0.5-1% of the time, we didn't get an
> answer within 10s (the limit of the histogram), which suggests that
> networks were filtering these requests.

I wonder if this is an argument for Kaminsky's proposal to carry this
information in TXT records instead of a new RRtype.  Can you repeat
the experiment with TXT?

It may also be an argument for not putting full certificates in the
DNS, to keep the records short.  How big were these queries and their
results?

> Needless to say, slowing things down to such an extent, and breaking
> that many people is a hard sell.

My counterargument would be: due to users' general willingness to
click through security warnings without even reading them, the only
way we're going to get an actual in-practice improvement to Web
security out of DANE (for sites that have already deployed SSL) is if
it provides exclusion with hard failure.  So it doesn't matter what
the performance hit is, because without that property there's no point
deploying it at all.

> Also, unless the information is DNSSEC authenticated, an attacker can
> spoof and DoS a site, and DNSSEC resolvers on the client are rare.
> (Or, rather, they would trigger hard failures for random sites until
> the user flushed their local browser state. Then the attacker can MITM
> the connection that they really wanted.)

I have been assuming that the client grows its own DNSSEC-aware
recursive resolver (which can be done without throwing away caching at
the ISP, btw).  This is something Mozilla is definitely willing to do
for our browser, and it's really not that hard - there are BSD-license
libraries already.

... skipping over technical details, which I'd rather keep out of this
subthread ...

> The DNS has several nice properties as a PKI: scoped delegation and
> short lived signatures rather than problematic revocation systems. I
> can see why some sites would like to have a DNSSEC signed HTTPS
> connection. They're not going to be major sites though. It will be
> hard to justify breaking even a tiny number of users when CA
> certificates can be had for free[2].

How do you reconcile this statement with the SSL Observatory data
indicating that self-signed certificates outnumber CA-signed
certificates by a factor of three?  Yeah, those aren't major sites,
but I would argue that the *other* way DANE could provide a
significant increment to Web security is at the margin: if it makes it
easier for sites that *aren't* encrypted now to *become* encrypted.
And the volume of self-signed certs in the wild indicates that the CA
process is a significant burden even to the point where sites are
willing to make their users click through increasingly scary and
intentionally UX-hostile certificate failure screens.

... I'm not sure how StartSSL factors into that, though.  IIRC their
free certificate service has only been around for a year or two, which
is not long as these things go, and if you don't know they have one, I
wonder hard it would be to find out about it.

zw

From [email-masked]  Wed Apr 13 16:59:20 2011
Sender: [email-masked]
Date: Wed, 13 Apr 2011 19:59:17 -0400
From: Adam Langley <[email-masked]>
To: Zack Weinberg <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] A browser's myopic view

On Wed, Apr 13, 2011 at 7:08 PM, Zack Weinberg <[email-masked]> w=
rote:
> I wonder if this is an argument for Kaminsky's proposal to carry this
> information in TXT records instead of a new RRtype. =C2=A0Can you repeat
> the experiment with TXT?

At some point, probably yes, although it takes a while.

> It may also be an argument for not putting full certificates in the
> DNS, to keep the records short. =C2=A0How big were these queries and thei=
r
> results?

The queries were for the names of the sites (i.e. "example.com" for
https://example.com). The responses would have been empty because, I
assume, no site has a DNS record of the given type. The DO bit was not
on.

> My counterargument would be: due to users' general willingness to
> click through security warnings without even reading them, the only
> way we're going to get an actual in-practice improvement to Web
> security out of DANE (for sites that have already deployed SSL) is if
> it provides exclusion with hard failure. =C2=A0So it doesn't matter what
> the performance hit is, because without that property there's no point
> deploying it at all.

But the other contender here is carrying this information via HSTS,
rather then not doing it at all. HSTS doesn't have the performance
issues, but does have a weakness in that it doesn't apply for a first
visit. Given the tradeoffs, I'm currently leaning towards HSTS for
pinning information.

> I have been assuming that the client grows its own DNSSEC-aware
> recursive resolver (which can be done without throwing away caching at
> the ISP, btw). =C2=A0This is something Mozilla is definitely willing to d=
o
> for our browser, and it's really not that hard - there are BSD-license
> libraries already.

Adding a DNSSEC resolver into the browser is possible, although I'd
still prefer not to. I also don't see a need right now. If HSTS
carries pinning data and the DNSSEC data can be more efficiently
carried in the server certificate, this complex and error prone code
doesn't have to live in the browser.

> How do you reconcile this statement with the SSL Observatory data
> indicating that self-signed certificates outnumber CA-signed
> certificates by a factor of three? =C2=A0Yeah, those aren't major sites,
> but I would argue that the *other* way DANE could provide a
> significant increment to Web security is at the margin: if it makes it
> easier for sites that *aren't* encrypted now to *become* encrypted.
> And the volume of self-signed certs in the wild indicates that the CA
> process is a significant burden even to the point where sites are
> willing to make their users click through increasingly scary and
> intentionally UX-hostile certificate failure screens.

Agreed. I suggest that none of the self-signed sites are major sites
but there is still an advantage to pushing up the lower end and making
it easier to deploy HTTPS. There are tradeoffs none the less: if
DNSSEC authenticated sites become popular then users of older browsers
will see an increase in certificate warnings and will be even more
inclined to ignore them. However, that argument implies paralysis and
so I give it little weight.

--=20
Adam Langley [email-masked] http://www.imperialviolet.org

From [email-masked]  Wed Apr 13 17:34:23 2011
Sender: [email-masked]
Date: Wed, 13 Apr 2011 17:34:22 -0700
From: Zack Weinberg <[email-masked]>
To: [email-masked]
Subject: Re: [dane] A browser's myopic view

On Wed, Apr 13, 2011 at 4:59 PM, Adam Langley <[email-masked]> wrot=
e:
> On Wed, Apr 13, 2011 at 7:08 PM, Zack Weinberg <[email-masked]>=
 wrote:
>> It may also be an argument for not putting full certificates in the
>> DNS, to keep the records short. =C2=A0How big were these queries and the=
ir
>> results?
>
> The queries were for the names of the sites (i.e. "example.com" for
> https://example.com). The responses would have been empty because, I
> assume, no site has a DNS record of the given type. The DO bit was not
> on.

Ok, thanks for clarifying.

>> My counterargument would be: due to users' general willingness to
>> click through security warnings without even reading them, the only
>> way we're going to get an actual in-practice improvement to Web
>> security out of DANE (for sites that have already deployed SSL) is if
>> it provides exclusion with hard failure. =C2=A0So it doesn't matter what
>> the performance hit is, because without that property there's no point
>> deploying it at all.
>
> But the other contender here is carrying this information via HSTS,
> rather then not doing it at all. HSTS doesn't have the performance
> issues, but does have a weakness in that it doesn't apply for a first
> visit. Given the tradeoffs, I'm currently leaning towards HSTS for
> pinning information.

Possibly I'm being too purist about it, possibly I count the
first-visit problem as more important than it really is, possibly I've
heard too many web developers (including at "major" sites) tell me
that they *cannot* make any changes to their sites' HTTP headers (and
nobody tell me that they can't roll out DNSSEC :-) but I just can't
see HSTS as anything more than a stopgap.  Putting the information in
the DNS seems like a much more appropriate long-term solution.

> Adding a DNSSEC resolver into the browser is possible, although I'd
> still prefer not to. I also don't see a need right now. If HSTS
> carries pinning data and the DNSSEC data can be more efficiently
> carried in the server certificate, this complex and error prone code
> doesn't have to live in the browser.

I guess this is the other point of disagreement, because it seems to
me that putting a DNSSEC resolver in the browser is a valuable
near-term change in and of itself.  It kneecaps a class of canned
man-in-the-middle exploits that are a live issue right now.  (Yes,
they *could* just switch to route spoofing or on-the-fly tampering,
but AFAIK nobody's canned those exploits yet.)

zw

From [email-masked]  Wed Apr 13 17:35:25 2011
Date: Wed, 13 Apr 2011 20:35:23 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Zack Weinberg <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] A browser's myopic view

--bcaec53f920bd11b6804a0d619b0
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Apr 13, 2011 at 7:08 PM, Zack Weinberg <[email-masked]>wrote:

> On Sat, Apr 9, 2011 at 2:12 PM, Adam Langley <[email-masked]>
> wrote:
> I wonder if this is an argument for Kaminsky's proposal to carry this
> information in TXT records instead of a new RRtype.  Can you repeat
> the experiment with TXT?
>

Possibly, but we would have to run the numbers to find out is TXT is blocked
as well. Could we do that before we go down that rat-hole.

We would also need to look at whether the DNSSEC info is getting through. My
guess is that the 0.5-1% that block new records are stripping out pretty
much everything except for A records and A record like stuff.

> > Needless to say, slowing things down to such an extent, and breaking
> > that many people is a hard sell.
>
> My counterargument would be: due to users' general willingness to
> click through security warnings without even reading them, the only
> way we're going to get an actual in-practice improvement to Web
> security out of DANE (for sites that have already deployed SSL) is if
> it provides exclusion with hard failure.  So it doesn't matter what
> the performance hit is, because without that property there's no point
> deploying it at all.

I disagree. I can see a way to beat the country level SSL proxy. That was
one of the starting points for my design two years ago. But I do not see how
to do it with DANE alone. Nor do I see a need to.

DANE by itself can provide some useful security for some use cases. But if
you want to defeat a nation state adversary you have to be prepared to think
beyond port 53. In other words use DANE to solve one part of the problem and
use something else to solve the rest.

I have been assuming that the client grows its own DNSSEC-aware
> recursive resolver (which can be done without throwing away caching at
> the ISP, btw).  This is something Mozilla is definitely willing to do
> for our browser, and it's really not that hard - there are BSD-license
> libraries already.
>

You have to get hold of the DNSSEC data at the client and you have to be
able to interpret it usefully based on the data available at the client.
That is harder than people credit it.

> How do you reconcile this statement with the SSL Observatory data
> indicating that self-signed certificates outnumber CA-signed
> certificates by a factor of three?

We don't know what those are. Its a tiny number of servers with any type of
SSL supported. If you load an SSL cert onto an IIS server with Exchange on
the same host, Exchange will start offering STARTTLS on SMTP automatically.
Anyone looked to see what IIS does if you load up a self-signed cert for
STARTTLS?

Or it could be devices that ship with embedded TLS to a self signed cert. It
could be anything.

The observatory only examines the servers. We have no idea how the clients
are configured or even if there are clients using the data.

I just discovered that two of my hosts have self-signed certs loaded. They
are test certs I made for various projects.

 Yeah, those aren't major sites,
> but I would argue that the *other* way DANE could provide a
> significant increment to Web security is at the margin: if it makes it
> easier for sites that *aren't* encrypted now to *become* encrypted.
>

Agreed, but to address that use case you also have to provide a way that a
DANE client can make things better for a new DANE aware browser without
causing inconsistent behavior or throwing error messages on legacy browsers.

The is why I have always seen the 'TLS available' signaling as essential. It
allows a new client to add value without getting pulled into the mire of
legacy browser behavior.

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

--bcaec53f920bd11b6804a0d619b0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Apr 13, 2011 at 7:08 PM, Zack Weinberg <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:[email-masked]">[email-masked]</a>&gt;</spa=
n> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">On Sat, Apr 9, 2011 at 2:12 PM, Adam Langley &lt;<a href=
=3D"mailto:[email-masked]">[email-masked]</a>&gt; wrote:<br=
></div>I wonder if this is an argument for Kaminsky&#39;s proposal to carry=
 this<br>

information in TXT records instead of a new RRtype. =A0Can you repeat<br>
the experiment with TXT?<br></blockquote><div><br></div><div>Possibly, but =
we would have to run the numbers to find out is TXT is blocked as well. Cou=
ld we do that before we go down that rat-hole.</div><div><br></div><div>
We would also need to look at whether the DNSSEC info is getting through. M=
y guess is that the 0.5-1% that block new records are stripping out pretty =
much everything except for A records and A record like stuff.=A0</div><div>
<br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class=3D"im">
&gt; Needless to say, slowing things down to such an extent, and breaking<b=
r>
&gt; that many people is a hard sell.<br>
<br>
</div>My counterargument would be: due to users&#39; general willingness to=
<br>
click through security warnings without even reading them, the only<br>
way we&#39;re going to get an actual in-practice improvement to Web<br>
security out of DANE (for sites that have already deployed SSL) is if<br>
it provides exclusion with hard failure. =A0So it doesn&#39;t matter what<b=
r>
the performance hit is, because without that property there&#39;s no point<=
br>
deploying it at all.</blockquote><div><br></div><div>I disagree. I can see =
a way to beat the country level SSL proxy. That was one of the starting poi=
nts for my design two years ago. But I do not see how to do it with DANE al=
one. Nor do I see a need to.</div>
<div><br></div><div>DANE by itself can provide some useful security for som=
e use cases. But if you want to defeat a nation state adversary you have to=
 be prepared to think beyond port 53. In other words use DANE to solve one =
part of the problem and use something else to solve the rest.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex;"><div class=3D"im">I have bee=
n assuming that the client grows its own DNSSEC-aware</div>
recursive resolver (which can be done without throwing away caching at<br>
the ISP, btw). =A0This is something Mozilla is definitely willing to do<br>
for our browser, and it&#39;s really not that hard - there are BSD-license<=
br>
libraries already.<br></blockquote><div><br></div><div>You have to get hold=
 of the DNSSEC data at the client and you have to be able to interpret it u=
sefully based on the data available at the client. That is harder than peop=
le credit it.</div>
<div><br></div><div><br></div><div>=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"=
>How do you reconcile this statement with the SSL Observatory data<br>
indicating that self-signed certificates outnumber CA-signed<br>
certificates by a factor of three? </blockquote><div><br></div><div>We don&=
#39;t know what those are. Its a tiny number of servers with any type of SS=
L supported. If you load an SSL cert onto an IIS server with Exchange on th=
e same host, Exchange will start offering STARTTLS on SMTP automatically. A=
nyone looked to see what IIS does if you load up a self-signed cert for STA=
RTTLS?</div>
<div><br></div><div>Or it could be devices that ship with embedded TLS to a=
 self signed cert. It could be anything.</div><div><br></div><div>The obser=
vatory only examines the servers. We have no idea how the clients are confi=
gured or even if there are clients using the data.</div>
<div><br></div><div>I just discovered that two of my hosts have self-signed=
 certs loaded. They are test certs I made for various projects.=A0</div><di=
v><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex;">
=A0Yeah, those aren&#39;t major sites,<br>
but I would argue that the *other* way DANE could provide a<br>
significant increment to Web security is at the margin: if it makes it<br>
easier for sites that *aren&#39;t* encrypted now to *become* encrypted.<br>=
</blockquote><div><br></div><div>Agreed, but to address that use case you a=
lso have to provide a way that a DANE client can make things better for a n=
ew DANE aware browser without causing inconsistent behavior or throwing err=
or messages on legacy browsers.</div>
<div><br></div><div>The is why I have always seen the &#39;TLS available&#3=
9; signaling as essential. It allows a new client to add value without gett=
ing pulled into the mire of legacy browser behavior.</div><div><br></div>
<div><br></div><div>=A0</div></div>-- <br>Website: <a href=3D"http://hallam=
baker.com/">http://hallambaker.com/</a><br><br>

--bcaec53f920bd11b6804a0d619b0--

From [email-masked]  Wed Apr 13 18:13:40 2011
From: Steve Schultze <[email-masked]>
Date: Wed, 13 Apr 2011 21:13:36 -0400
To: [email-masked]
Subject: Re: [dane] A browser's myopic view

On Apr 13, 2011, at 7:59 PM, Adam Langley wrote:
>> My counterargument would be: due to users' general willingness to
>> click through security warnings without even reading them, the only
>> way we're going to get an actual in-practice improvement to Web
>> security out of DANE (for sites that have already deployed SSL) is if
>> it provides exclusion with hard failure.  So it doesn't matter what
>> the performance hit is, because without that property there's no =
point
>> deploying it at all.
>=20
> But the other contender here is carrying this information via HSTS,
> rather then not doing it at all. HSTS doesn't have the performance
> issues, but does have a weakness in that it doesn't apply for a first
> visit. Given the tradeoffs, I'm currently leaning towards HSTS for
> pinning information.

That's really putting all your TOFU eggs in one basket, no?

It seems like this is the difference between adding another layer to the =
current model versus a more fundamental fix that is admittedly more =
difficult.

I'm tired of patches.=

From [email-masked]  Wed Apr 13 18:18:06 2011
From: Steve Schultze <[email-masked]>
Date: Wed, 13 Apr 2011 21:18:03 -0400
To: [email-masked]
Subject: Re: [dane] A browser's myopic view

On Apr 13, 2011, at 8:35 PM, Phillip Hallam-Baker wrote:
>> > Needless to say, slowing things down to such an extent, and =
breaking
>> > that many people is a hard sell.
>>=20
>> My counterargument would be: due to users' general willingness to
>> click through security warnings without even reading them, the only
>> way we're going to get an actual in-practice improvement to Web
>> security out of DANE (for sites that have already deployed SSL) is if
>> it provides exclusion with hard failure.  So it doesn't matter what
>> the performance hit is, because without that property there's no =
point
>> deploying it at all.
>=20
> I disagree. I can see a way to beat the country level SSL proxy. That =
was one of the starting points for my design two years ago.

You're going to have to expand on this one.

> DANE by itself can provide some useful security for some use cases. =
But if you want to defeat a nation state adversary you have to be =
prepared to think beyond port 53. In other words use DANE to solve one =
part of the problem and use something else to solve the rest.

DANE does not require port 53.=

From [email-masked]  Wed Apr 13 18:58:19 2011
Date: Wed, 13 Apr 2011 21:58:13 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Steve Schultze <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] A browser's myopic view

--20cf3054aabf110fe404a0d74273
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Apr 13, 2011 at 9:18 PM, Steve Schultze <[email-masked]> wrote:

>
> On Apr 13, 2011, at 8:35 PM, Phillip Hallam-Baker wrote:
> >> > Needless to say, slowing things down to such an extent, and breaking
> >> > that many people is a hard sell.
> >>
> >> My counterargument would be: due to users' general willingness to
> >> click through security warnings without even reading them, the only
> >> way we're going to get an actual in-practice improvement to Web
> >> security out of DANE (for sites that have already deployed SSL) is if
> >> it provides exclusion with hard failure.  So it doesn't matter what
> >> the performance hit is, because without that property there's no point
> >> deploying it at all.
> >
> > I disagree. I can see a way to beat the country level SSL proxy. That was
> one of the starting points for my design two years ago.
>
> You're going to have to expand on this one.

It is somewhat old but:
http://tools.ietf.org/html/draft-hallambaker-dpls-00

Its a fairly simple approach to layering DNS over a secure channel without
the need for TCP/IP fallback.

> > DANE by itself can provide some useful security for some use cases. But
> if you want to defeat a nation state adversary you have to be prepared to
> think beyond port 53. In other words use DANE to solve one part of the
> problem and use something else to solve the rest.
>
> DANE does not require port 53.

No, but it does not provide a strategy for avoiding the need to use port 53
either.

I think that what we are going to need to really solve this problem is to
consider the 'user in police state' problem as being completely separate and
accept that they are going to tollerate major delays in their user
experience to get through.

People living in police states cannot just connect up to Google or Mozilla
and download chrome. They can't get untainted AV either. There is a whole
bootstrap problem that has to be thought through.

For that use case we need to either layer over Tor or have an agile approach
that uses port 443 when necessary. It may even be necessary to perform TLS
within TLS to get round some of the attacks.

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

--20cf3054aabf110fe404a0d74273
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Wed, Apr 13, 2011 at 9:18 PM, Steve S=
chultze <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">sjs@prin=
ceton.edu</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im"><br>
On Apr 13, 2011, at 8:35 PM, Phillip Hallam-Baker wrote:<br>
&gt;&gt; &gt; Needless to say, slowing things down to such an extent, and b=
reaking<br>
&gt;&gt; &gt; that many people is a hard sell.<br>
&gt;&gt;<br>
&gt;&gt; My counterargument would be: due to users&#39; general willingness=
 to<br>
&gt;&gt; click through security warnings without even reading them, the onl=
y<br>
&gt;&gt; way we&#39;re going to get an actual in-practice improvement to We=
b<br>
&gt;&gt; security out of DANE (for sites that have already deployed SSL) is=
 if<br>
&gt;&gt; it provides exclusion with hard failure. =A0So it doesn&#39;t matt=
er what<br>
&gt;&gt; the performance hit is, because without that property there&#39;s =
no point<br>
&gt;&gt; deploying it at all.<br>
&gt;<br>
&gt; I disagree. I can see a way to beat the country level SSL proxy. That =
was one of the starting points for my design two years ago.<br>
<br>
</div>You&#39;re going to have to expand on this one.</blockquote><div><br>=
</div><div>It is somewhat old but:</div><div><a href=3D"http://tools.ietf.o=
rg/html/draft-hallambaker-dpls-00">http://tools.ietf.org/html/draft-hallamb=
aker-dpls-00</a></div>
<div><br></div><div>Its a fairly simple approach to layering DNS over a sec=
ure channel without the need for TCP/IP fallback.</div><div><br></div><div>=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">
&gt; DANE by itself can provide some useful security for some use cases. Bu=
t if you want to defeat a nation state adversary you have to be prepared to=
 think beyond port 53. In other words use DANE to solve one part of the pro=
blem and use something else to solve the rest.<br>

<br>
</div>DANE does not require port 53.</blockquote><div><br></div><div>No, bu=
t it does not provide a strategy for avoiding the need to use port 53 eithe=
r.</div><div><br></div><div>I think that what we are going to need to reall=
y solve this problem is to consider the &#39;user in police state&#39; prob=
lem as being completely separate and accept that they are going to tollerat=
e major delays in their user experience to get through.</div>
<div><br></div><div>People living in police states cannot just connect up t=
o Google or Mozilla and download chrome. They can&#39;t get untainted AV ei=
ther. There is a whole bootstrap problem that has to be thought through.</d=
iv>
<div><br></div><div>For that use case we need to either layer over Tor or h=
ave an agile approach that uses port 443 when necessary. It may even be nec=
essary to perform TLS within TLS to get round some of the attacks.</div>
<div><br></div><div>=A0</div></div>-- <br>Website: <a href=3D"http://hallam=
baker.com/">http://hallambaker.com/</a><br><br>

--20cf3054aabf110fe404a0d74273--

From [email-masked]  Wed Apr 13 19:59:27 2011
From: Steve Schultze <[email-masked]>
Date: Wed, 13 Apr 2011 22:59:13 -0400
To: [email-masked]
Subject: Re: [dane] A browser's myopic view

On Apr 13, 2011, at 9:58 PM, Phillip Hallam-Baker wrote:
> On Wed, Apr 13, 2011 at 9:18 PM, Steve Schultze <[email-masked]> =
wrote:
>=20
>> On Apr 13, 2011, at 8:35 PM, Phillip Hallam-Baker wrote:
>> >> > Needless to say, slowing things down to such an extent, and =
breaking
>> >> > that many people is a hard sell.
>> >>
>> >> My counterargument would be: due to users' general willingness to
>> >> click through security warnings without even reading them, the =
only
>> >> way we're going to get an actual in-practice improvement to Web
>> >> security out of DANE (for sites that have already deployed SSL) is =
if
>> >> it provides exclusion with hard failure.  So it doesn't matter =
what
>> >> the performance hit is, because without that property there's no =
point
>> >> deploying it at all.
>> >
>> > I disagree. I can see a way to beat the country level SSL proxy. =
That was one of the starting points for my design two years ago.
>>=20
>> You're going to have to expand on this one.
>=20
> It is somewhat old but:
> http://tools.ietf.org/html/draft-hallambaker-dpls-00

So you envision re-creation of centralized intermediaries.  Perhaps if =
something like what you proposed had enjoyed some adoption, this would =
be an option.

> > DANE by itself can provide some useful security for some use cases. =
But if you want to defeat a nation state adversary you have to be =
prepared to think beyond port 53. In other words use DANE to solve one =
part of the problem and use something else to solve the rest.
>=20
> DANE does not require port 53.
>=20
> No, but it does not provide a strategy for avoiding the need to use =
port 53 either.

abstraction

> I think that what we are going to need to really solve this problem is =
to consider the 'user in police state' problem as being completely =
separate and accept that they are going to tollerate major delays in =
their user experience to get through.
>=20
> People living in police states cannot just connect up to Google or =
Mozilla and download chrome. They can't get untainted AV either. There =
is a whole bootstrap problem that has to be thought through.
>=20
> For that use case we need to either layer over Tor or have an agile =
approach that uses port 443 when necessary. It may even be necessary to =
perform TLS within TLS to get round some of the attacks.

The types of delays we *might* have to face in a DNSSEC-based approach =
is nothing like the major delays currently experienced by users of Tor =
and other anonymization/circumvention tools.  Of course, that's a =
different set of features than DANE's verified encrypted connections to =
an arbitrary endpoint.

I don't think we should create a two-tier system for users in hostile =
jurisdictions and those that are not... after all, one person's National =
Security Agency is the next person's Ministry of Information.

From [email-masked]  Thu Apr 14 06:21:07 2011
From: James Cloos <[email-masked]>
To: Zack Weinberg <[email-masked]>
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC
Copyright: Copyright 2011 James Cloos
OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
Date: Thu, 14 Apr 2011 09:20:27 -0400
Lines: 18
Cc: [email-masked]
Subject: Re: [dane] A browser's myopic view

>>>>> "ZW" == Zack Weinberg <[email-masked]> writes:

ZW> it seems to me that putting a DNSSEC resolver in the browser
ZW> is a valuable near-term change in and of itself.

In a dnssec world both recucursers and resolvers SHOULD validate.

So, yes, validating resolver code in browsers and similar apps is
a welcome addition.

It would be best, though, to separate the resolving code out into
its own library, just as encryption, et al are in separate libs
(nss, gnutls, openssl, et cetera).  That would better facilitate
review, trust and also re-use.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

From [email-masked]  Thu Apr 14 08:46:10 2011
Date: Thu, 14 Apr 2011 11:46:07 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Steve Schultze <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] A browser's myopic view

--bcaec5171ea7e00e1104a0e2d280
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Apr 13, 2011 at 10:59 PM, Steve Schultze <[email-masked]> wrote:

>
> On Apr 13, 2011, at 9:58 PM, Phillip Hallam-Baker wrote:
> > On Wed, Apr 13, 2011 at 9:18 PM, Steve Schultze <[email-masked]>
> wrote:
> >
> >> On Apr 13, 2011, at 8:35 PM, Phillip Hallam-Baker wrote:
> >> >> > Needless to say, slowing things down to such an extent, and
> breaking
> >> >> > that many people is a hard sell.
> >> >>
> >> >> My counterargument would be: due to users' general willingness to
> >> >> click through security warnings without even reading them, the only
> >> >> way we're going to get an actual in-practice improvement to Web
> >> >> security out of DANE (for sites that have already deployed SSL) is if
> >> >> it provides exclusion with hard failure.  So it doesn't matter what
> >> >> the performance hit is, because without that property there's no
> point
> >> >> deploying it at all.
> >> >
> >> > I disagree. I can see a way to beat the country level SSL proxy. That
> was one of the starting points for my design two years ago.
> >>
> >> You're going to have to expand on this one.
> >
> > It is somewhat old but:
> > http://tools.ietf.org/html/draft-hallambaker-dpls-00
>
> So you envision re-creation of centralized intermediaries.  Perhaps if
> something like what you proposed had enjoyed some adoption, this would be an
> option.

The architecture already has several million users. They just don't know
that they are doing it, nor do they care. Currently we use a proprietary
protocol, DPLS is a proposal to create an open standard to replace it.

And since the existing model of the DNS has virtually everyone using random
resolvers as an intermediary, it is clearly not as far fetched as other
proposals.

> > > DANE by itself can provide some useful security for some use cases. But
> if you want to defeat a nation state adversary you have to be prepared to
> think beyond port 53. In other words use DANE to solve one part of the
> problem and use something else to solve the rest.
> >
> > DANE does not require port 53.
> >
> > No, but it does not provide a strategy for avoiding the need to use port
> 53 either.
>
> abstraction
>

It needs a discovery layer. How does the client work out it is being blocked
and find the right data.

> I don't think we should create a two-tier system for users in hostile
> jurisdictions and those that are not... after all, one person's National
> Security Agency is the next person's Ministry of Information.
>

I don't think we have much option. People who are risking their lives are
willing to put up with a browser that is very slow. People surfing to find
lolcats are not.

Its pretty easy to download an untainted version of Chrome or Firefox here
in the US. Very hard for someone to do that in Iran.

Most rifles are good for a single war. After that the opponents respond by
matching or exceeding the capabilities. Its the same with Internet
revolutions.

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

--bcaec5171ea7e00e1104a0e2d280
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Wed, Apr 13, 2011 at 10:59 PM, Steve =
Schultze <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">sjs@pri=
nceton.edu</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im"><br>
On Apr 13, 2011, at 9:58 PM, Phillip Hallam-Baker wrote:<br>
&gt; On Wed, Apr 13, 2011 at 9:18 PM, Steve Schultze &lt;<a href=3D"mailto:=
[email-masked]">[email-masked]</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt; On Apr 13, 2011, at 8:35 PM, Phillip Hallam-Baker wrote:<br>
&gt;&gt; &gt;&gt; &gt; Needless to say, slowing things down to such an exte=
nt, and breaking<br>
&gt;&gt; &gt;&gt; &gt; that many people is a hard sell.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; My counterargument would be: due to users&#39; general wi=
llingness to<br>
&gt;&gt; &gt;&gt; click through security warnings without even reading them=
, the only<br>
&gt;&gt; &gt;&gt; way we&#39;re going to get an actual in-practice improvem=
ent to Web<br>
&gt;&gt; &gt;&gt; security out of DANE (for sites that have already deploye=
d SSL) is if<br>
&gt;&gt; &gt;&gt; it provides exclusion with hard failure. =A0So it doesn&#=
39;t matter what<br>
&gt;&gt; &gt;&gt; the performance hit is, because without that property the=
re&#39;s no point<br>
&gt;&gt; &gt;&gt; deploying it at all.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; I disagree. I can see a way to beat the country level SSL pro=
xy. That was one of the starting points for my design two years ago.<br>
&gt;&gt;<br>
&gt;&gt; You&#39;re going to have to expand on this one.<br>
&gt;<br>
&gt; It is somewhat old but:<br>
&gt; <a href=3D"http://tools.ietf.org/html/draft-hallambaker-dpls-00" targe=
t=3D"_blank">http://tools.ietf.org/html/draft-hallambaker-dpls-00</a><br>
<br>
</div>So you envision re-creation of centralized intermediaries. =A0Perhaps=
 if something like what you proposed had enjoyed some adoption, this would =
be an option.</blockquote><div><br></div><div>The architecture already has =
several million users. They just don&#39;t know that they are doing it, nor=
 do they care. Currently we use a proprietary protocol, DPLS is a proposal =
to create an open standard to replace it.</div>
<div><br></div><div>And since the existing model of the DNS has virtually e=
veryone using random resolvers as an intermediary, it is clearly not as far=
 fetched as other proposals.</div><div><br></div><div><br></div><div><br>
</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class=3D"im">
&gt; &gt; DANE by itself can provide some useful security for some use case=
s. But if you want to defeat a nation state adversary you have to be prepar=
ed to think beyond port 53. In other words use DANE to solve one part of th=
e problem and use something else to solve the rest.<br>

&gt;<br>
&gt; DANE does not require port 53.<br>
&gt;<br>
&gt; No, but it does not provide a strategy for avoiding the need to use po=
rt 53 either.<br>
<br>
</div>abstraction<br></blockquote><div><br></div><div>It needs a discovery =
layer. How does the client work out it is being blocked and find the right =
data.</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class=3D"im">I don&#39;t think we should create a two-tier system for =
users in hostile jurisdictions and those that are not... after all, one per=
son&#39;s National Security Agency is the next person&#39;s Ministry of Inf=
ormation.</div>
</blockquote><div><br></div><div>I don&#39;t think we have much option. Peo=
ple who are risking their lives are willing to put up with a browser that i=
s very slow. People surfing to find lolcats are not.</div><div><br></div>
<div>Its pretty easy to download an untainted version of Chrome or Firefox =
here in the US. Very hard for someone to do that in Iran.</div><div><br></d=
iv><div>Most rifles are good for a single war. After that the opponents res=
pond by matching or exceeding the capabilities. Its the same with Internet =
revolutions.</div>
<div><br></div><div><br></div><div><br></div></div>-- <br>Website: <a href=
=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>

--bcaec5171ea7e00e1104a0e2d280--

From [email-masked]  Thu Apr 14 10:28:08 2011
From: Rick Andrews <[email-masked]>
To: Steve Schultze <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 14 Apr 2011 10:27:51 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dane] A browser's myopic view

On Wednesday, April 13, 2011 6:14 PM, Steve Schultze wrote:
>=20
> On Apr 13, 2011, at 7:59 PM, Adam Langley wrote:
> >> My counterargument would be: due to users' general willingness to
> >> click through security warnings without even reading them, the only
> >> way we're going to get an actual in-practice improvement to Web
> >> security out of DANE (for sites that have already deployed SSL) is
> if
> >> it provides exclusion with hard failure.  So it doesn't matter what
> >> the performance hit is, because without that property there's no
> point
> >> deploying it at all.
> >
> > But the other contender here is carrying this information via HSTS,
> > rather then not doing it at all. HSTS doesn't have the performance
> > issues, but does have a weakness in that it doesn't apply for a first
> > visit. Given the tradeoffs, I'm currently leaning towards HSTS for
> > pinning information.
>=20
> That's really putting all your TOFU eggs in one basket, no?

Chrome preloads a number of STS tokens (http://www.chromium.org/sts), so yo=
u're not really trusting on first use. Perhaps Google's SSL database (http:=
//googleonlinesecurity.blogspot.com/2011/04/improving-ssl-certificate-secur=
ity.html) could be used to preload a huge volume of STS tokens?

-Rick Andrews

From [email-masked]  Thu Apr 14 10:51:58 2011
Date: Thu, 14 Apr 2011 13:51:55 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Rick Andrews <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dane] A browser's myopic view

On Thu, 14 Apr 2011, Rick Andrews wrote:

> Chrome preloads a number of STS tokens (http://www.chromium.org/sts), so you're not really trusting on first use. Perhaps Google's SSL database (http://googleonlinesecurity.blogspot.com/2011/04/improving-ssl-certificate-security.html) could be used to preload a huge volume of STS tokens?

Seems like an excessive solution to save each user a one-time ever DNS lookup of 20ms for the HASTLS record.

HASTLS is distributed and controlled by the domain owner. And requires no added trusted third parties,
or repositories that need to be maintained by browser vendors.

I also see no obvious way to get my STS token in? Does this solution scale at all? It seems to mostly be
beneficial to the "too big to fail" EV carrying websites.

Paul

From [email-masked]  Thu Apr 14 11:06:19 2011
Sender: [email-masked]
Date: Thu, 14 Apr 2011 14:06:18 -0400
From: Adam Langley <[email-masked]>
To: Paul Wouters <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dane] A browser's myopic view

On Thu, Apr 14, 2011 at 1:51 PM, Paul Wouters <[email-masked]> wrote:
> I also see no obvious way to get my STS token in? Does this solution scale
> at all? It seems to mostly be
> beneficial to the "too big to fail" EV carrying websites.

>From the page:

"If you own a site that you would like to see included in the
preloaded HSTS list, contact: <my email>"

The if the overhead of maintaining the preloaded list becomes too
large, then a more automated system will be setup.

Again, HASTLS would need to be a hard fail in order to have a benefit
over HSTS, and that's not likely to work on today's Internet.

Less importantly, in order to avoid spoofing of HASTLS records, the
clients have to implement their own DNSSEC resolver.

(The arguments are just the same as with DANE based exclusion vs HSTS
exclusion.)

AGL

-- 
Adam Langley [email-masked] http://www.imperialviolet.org

From [email-masked]  Thu Apr 14 11:12:59 2011
Date: Thu, 14 Apr 2011 14:12:56 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Wouters <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dane] A browser's myopic view

--20cf307cfcbcefe69104a0e4df4b
Content-Type: text/plain; charset=ISO-8859-1

Or the group could do it my way and combine key publication and notifying
TLS support in the same mechanism and the performance issue goes away.

These are implementation issues, not use cases. 'Secure on first connect' is
a requirement.

The way I think that the process should go is

1) People propose use cases and performance metrics by which to validate
them. Technical constraints are identified.

2) Use cases are analyzed to determine requirements that satisfy them.

3) People make proposals that satisfy as many or as few requirements (and
thus use cases) as they like.

4) People decide which solution they like and we find out if there is
consensus for a single solution or if there is to be some horse trading or
if the divisions turn out to be irreconcilable and we end up with competing
proposals.

So far the approach has been that we have been told what the solution is
going to be and that people who disagree have been accused and abused.

The performance metrics that matter are the performance metrics for the
whole system, not the metrics for one individual component.

I can meet all the requirements and constraints that I have set out in my
proposed use cases document with better performance against the specified
metrics.

So I am quite happy to accept both the use case and the metric.

On Thu, Apr 14, 2011 at 1:51 PM, Paul Wouters <[email-masked]> wrote:

> On Thu, 14 Apr 2011, Rick Andrews wrote:
>
>  Chrome preloads a number of STS tokens (http://www.chromium.org/sts), so
>> you're not really trusting on first use. Perhaps Google's SSL database (
>> http://googleonlinesecurity.blogspot.com/2011/04/improving-ssl-certificate-security.html)
>> could be used to preload a huge volume of STS tokens?
>>
>
> Seems like an excessive solution to save each user a one-time ever DNS
> lookup of 20ms for the HASTLS record.
>
> HASTLS is distributed and controlled by the domain owner. And requires no
> added trusted third parties,
> or repositories that need to be maintained by browser vendors.
>
> I also see no obvious way to get my STS token in? Does this solution scale
> at all? It seems to mostly be
> beneficial to the "too big to fail" EV carrying websites.
>
> Paul
>
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

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

--20cf307cfcbcefe69104a0e4df4b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Or the group could do it my way and combine key publication and notifying T=
LS support in the same mechanism and the performance issue goes away.<div><=
br></div><div>These are implementation issues, not use cases. &#39;Secure o=
n first connect&#39; is a requirement.</div>
<div><br></div><div>The way I think that the process should go is</div><div=
><br></div><div>1) People propose use cases and performance metrics by whic=
h to validate them. Technical constraints are identified.</div><div><br>
</div><div>2) Use cases are analyzed to determine requirements that satisfy=
 them.=A0</div><div><br></div><div>3) People make proposals that satisfy as=
 many or as few requirements (and thus use cases) as they like.</div><div>
<br></div><div><br></div><div>4) People decide which solution they like and=
 we find out if there is consensus for a single solution or if there is to =
be some horse trading or if the divisions turn out to be=A0irreconcilable=
=A0and we end up with competing proposals.</div>
<div><br></div><div><br></div><div>So far the approach has been that we hav=
e been told what the solution is going to be and that people who disagree h=
ave been accused and abused.</div><div><br></div><div>The performance metri=
cs that matter are the performance metrics for the whole system, not the me=
trics for one individual component.</div>
<div><br></div><div>I can meet all the requirements and constraints that I =
have set out in my proposed use cases document with better performance agai=
nst the specified metrics.</div><div><br></div><div>So I am quite happy to =
accept both the use case and the metric.</div>
<div><br></div><div><br><div class=3D"gmail_quote">On Thu, Apr 14, 2011 at =
1:51 PM, Paul Wouters <span dir=3D"ltr">&lt;<a href=3D"mailto:paul@xeleranc=
e.com">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex;">
<div class=3D"im">On Thu, 14 Apr 2011, Rick Andrews wrote:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Chrome preloads a number of STS tokens (<a href=3D"http://www.chromium.org/=
sts" target=3D"_blank">http://www.chromium.org/sts</a>), so you&#39;re not =
really trusting on first use. Perhaps Google&#39;s SSL database (<a href=3D=
"http://googleonlinesecurity.blogspot.com/2011/04/improving-ssl-certificate=
-security.html" target=3D"_blank">http://googleonlinesecurity.blogspot.com/=
2011/04/improving-ssl-certificate-security.html</a>) could be used to prelo=
ad a huge volume of STS tokens?<br>

</blockquote>
<br></div>
Seems like an excessive solution to save each user a one-time ever DNS look=
up of 20ms for the HASTLS record.<br>
<br>
HASTLS is distributed and controlled by the domain owner. And requires no a=
dded trusted third parties,<br>
or repositories that need to be maintained by browser vendors.<br>
<br>
I also see no obvious way to get my STS token in? Does this solution scale =
at all? It seems to mostly be<br>
beneficial to the &quot;too big to fail&quot; EV carrying websites.<br><fon=
t color=3D"#888888">
<br>
Paul</font><div><div></div><div class=3D"h5"><br>
_______________________________________________<br>
dane mailing list<br>
<a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/dane</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--20cf307cfcbcefe69104a0e4df4b--

From [email-masked]  Thu Apr 14 12:01:46 2011
Date: Thu, 14 Apr 2011 15:01:24 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Adam Langley <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dane] A browser's myopic view

On Thu, 14 Apr 2011, Adam Langley wrote:

> "If you own a site that you would like to see included in the
> preloaded HSTS list, contact: <my email>"

I totally missed that on the page. oops :) My bad.

> Again, HASTLS would need to be a hard fail in order to have a benefit
> over HSTS, and that's not likely to work on today's Internet.
>
> Less importantly, in order to avoid spoofing of HASTLS records, the
> clients have to implement their own DNSSEC resolver.
>
> (The arguments are just the same as with DANE based exclusion vs HSTS
> exclusion.)

Yes, but the protocol is secure, it just needs to be deployed, where HSTS is
not secure because of its port 80 initial dependancy (unless you bootstrap it
otherwise)

If keeping a giant list of hosts scaled, we wouldn't be usin DNS :)

Not to say HSTS has no value. It still protects against all passive attacks for
those websites that enable it. And that is very VERY useful. (Though arguably,
the could be said about HASTLS, I would not put any trust in that without dnssec,
since a DNS UDP packet is more easilly forged then a TCP connection to port 80,
knocked up to port 443 with TLS)

Paul

From [email-masked]  Thu Apr 14 19:46:00 2011
Date: Thu, 14 Apr 2011 19:45:55 -0700
From: Kirk Hall <[email-masked]>
To: Matt McCutchen <[email-masked]>, [email-masked]
Subject: Re: [dane] Expectations for Self-Signed Cert Trust Indicators under DANE
Reply-To: [email-masked]

--20cf307d049c82276f04a0ec0a9f
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Just a few more data points on this discussion concerning trust indicators
for self-signed certs under DANE.

1.  Here is a depiction of a typical phishing site, this one for PayPal.

http://www.csupomona.edu/~ehelp/security/security_phishing.html#PhishingExa=
mple

Notice that consumers are warned as follows:

=93The user should consider an unsecured page (no lock icon) as fraudulent.
Sites such as PayPal would process your login information via a HTTPS
session. HTTPS is the secure version of Hyper-Text Transfer Protocol or HTT=
P
that uses Secure Socket Layer (SSL) technology. HTTPS is now a de facto
standard for websites that gather sensitive information (e.g. account and
credit card information, etc.).=94

Consumers have been taught to look for the lock icon as a trust symbol, or
else the site might be dangerous.  Browsers are unlikely to undo this
consumer training.  I assume this group wants self-signed certs under DANE
to get the lock icon from browsers in order to notify consumers they are in
TLS encryption mode =96 so you will have to consider how to satisfy the
browsers=92 concerns.

2. There=92s a list of numerous phishing URLs at:
http://www.phishtank.com/phish_search.php?page=3D1&active=3Dy&verified=3Du

If you scan through them (there are many) you=92ll find that a lot of them =
are
look-alike domains. Under DANE, they could easily associate self-signed
certs with their domain at the DNS operator level.  Their domains would the=
n
receive exactly the SAME trust indicators that YOUR domains will receive
with a self-signed cert under DANE.  So any idea that DANE will create a
better or more trustworthy environment for consumers has to deal with this
fact.

3.  There are lots of look-alike domains available today.  Here=92s a small
sample:

your-account-bankofamerica.com

my-email-live.com

google-accounts.com

my-paypal-account.com

All of these domains could use self-signed certs at the DNS operator level,
and would then receive exactly the SAME trust indicators that YOUR domains
will receive with a self-signed cert.

4.  I said in my earlier posting that this group should not expect browsers
and other consumer-facing applications to give DANE any trust indicators fo=
r
self-signed certs, unless the certs are somehow flagged as having undergone
anti-fraud checking (not known phishing sites, not look-alike domains).  I
can give you a concrete example of how the browsers will likely react.

As many of you know, there are extensive discussions right now about how to
improve certificate revocation checking.  Consumers often don=92t receive a
response from the issuing CA to a revocation checking request via OCSP or
CRL =96 because of connectivity problems and other issues.  Because there a=
re
so many response failures, the browsers today generally treat this as a
=93soft default=94, let the consumer proceed to the site, and even show the
padlock or other trust indicator (e.g., green bar for EV certs).  However,
the browsers are getting tired of this, and looking for a way to make lack
of an OCSP/CRL response a =93hard=94 default.

One browser =96 Opera =96 has already moved in this direction.  If someone =
using
the Opera browser goes to a domain secured by a CA-issued cert (DV, OV, or
EV), and if there is no response to an OCSP revocation check request, Opera
will not show ANY trust indicators for the site =96 no green bar, no lock
icon, no UI to show TLS encryption.  (They don=92t block the site, so it=92=
s not
a full =93hard=94 default.)  This is true even though the cert came from a =
CA
whose roots are in Opera=92s trusted root store =96 if there=92s no OCSP re=
sponse
from a trusted CA, there will be no trust indicators in the UI.

I=92m quite certain this will be DANE=92s fate among browsers and other con=
sumer
facing applications for self-signed certs, unless DANE builds into its spec=
s
some way to distinguish self-signed certs that have gone through an
anti-fraud check from those that have not.  Browsers might give some sort o=
f
trust indicator for fraud-checked certs =96 at least to show the consumer t=
hat
he or she is in TLS encryption.  Otherwise, I=92m pretty sure the UI won=92=
t
even show encryption is happening because of the danger that phishers will
use DANE to trick people into thinking their sites are =93trustworthy=94.

There may even be issues with the browsers concerning revocation of
self-signed certs =96 if certs from CAs have to maintain CRLs and OCSP
responders, someone might have to maintain a revocation list of some sort
for self-signed certs.

How can self-signed certs get a =93designation=94 that they have undergone
anti-fraud checking?  I don=92t know =96 maybe the DNS operator flags the
fraud-tested certs at the DNS system level?  There may be other ideas on ho=
w
to do this from people on this discussion.  But in my opinion, this group
needs to figure out how to keep the =93bad guys=94 from using DANE and gett=
ing
the same trust indicators that the good guys with self-signed certs hope to
get.

Kirk

--20cf307d049c82276f04a0ec0a9f
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<font face=3D"Times New Roman" size=3D"3">
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">Just a few more data p=
oints on this discussion concerning trust indicators for self-signed certs =
under DANE.</p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">=A0</p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">1.<span style=3D"mso-s=
pacerun: yes">=A0 </span>Here is a depiction of a typical phishing site, th=
is one for PayPal.<span style=3D"mso-spacerun: yes">=A0 </span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">=A0</p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt"><a href=3D"http://www.=
csupomona.edu/~ehelp/security/security_phishing.html#PhishingExample">http:=
//www.csupomona.edu/~ehelp/security/security_phishing.html#PhishingExample<=
/a></p>

<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">=A0</p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">Notice that consumers =
are warned as follows:</p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">=A0</p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt 0.5in"><span lang=3D"EN=
" style=3D"mso-ansi-language: EN">=93The user should consider an unsecured =
page (no lock icon) as fraudulent. Sites such as PayPal would process your =
login information via a HTTPS session. HTTPS is the secure version of Hyper=
-Text Transfer Protocol or HTTP that uses Secure Socket Layer (SSL) technol=
ogy. HTTPS is now a de facto standard for websites that gather sensitive in=
formation (e.g. account and credit card information, etc.).=94</span></p>

<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt"><span lang=3D"EN" styl=
e=3D"mso-ansi-language: EN">=A0</span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt"><span lang=3D"EN" styl=
e=3D"mso-ansi-language: EN">Consumers have been taught to look for the lock=
 icon as a trust symbol, or else the site might be dangerous.<span style=3D=
"mso-spacerun: yes">=A0 </span>Browsers are unlikely to undo this consumer =
training.<span style=3D"mso-spacerun: yes">=A0 </span>I assume this group w=
ants self-signed certs under DANE to get the lock icon from browsers in ord=
er to notify consumers they are in TLS encryption mode =96 so you will have=
 to consider how to satisfy the browsers=92 concerns.</span></p>

<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt"><span lang=3D"EN" styl=
e=3D"mso-ansi-language: EN">=A0</span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt"><span lang=3D"EN" styl=
e=3D"mso-ansi-language: EN">2. Th</span>ere=92s a list of numerous phishing=
 URLs at: <a title=3D"http://www.phishtank.com/phish_search.php?page=3D1&am=
p;active=3Dy&amp;verified=3Du" href=3D"http://www.phishtank.com/phish_searc=
h.php?page=3D1&amp;active=3Dy&amp;verified=3Du"><font color=3D"#800080">htt=
p://www.phishtank.com/phish_search.php?page=3D1&amp;active=3Dy&amp;verified=
=3Du</font></a> </p>

<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">=A0</p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">If you scan through th=
em (there are many) you=92ll find that a lot of them are look-alike domains=
. Under DANE, they could easily associate self-signed certs with their doma=
in at the DNS operator level.<span style=3D"mso-spacerun: yes">=A0 </span>T=
heir domains would then receive exactly the SAME trust indicators that YOUR=
 domains will receive with a self-signed cert under DANE.<span style=3D"mso=
-spacerun: yes">=A0 </span>So any idea that DANE will create a better or mo=
re trustworthy environment for consumers has to deal with this fact.</p>

<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">=A0</p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">3.<span style=3D"mso-s=
pacerun: yes">=A0 </span>There are lots of look-alike domains available tod=
ay.<span style=3D"mso-spacerun: yes">=A0 </span>Here=92s a small sample:</p=
>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">=A0</p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt 0.5in"><a href=3D"http:=
//your-account-bankofamerica.com">your-account-bankofamerica.com</a></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt 0.5in"><a href=3D"http:=
//my-email-live.com">my-email-live.com</a></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt 0.5in"><a href=3D"http:=
//google-accounts.com">google-accounts.com</a></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt 0.5in"><a href=3D"http:=
//my-paypal-account.com">my-paypal-account.com</a></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">=A0</p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">All of these domains c=
ould use self-signed certs at the DNS operator level, and would then receiv=
e exactly the SAME trust indicators that YOUR domains will receive with a s=
elf-signed cert.</p>

<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">=A0</p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">4.<span style=3D"mso-s=
pacerun: yes">=A0 </span>I said in my earlier posting that this group shoul=
d not expect browsers and other consumer-facing applications to give DANE a=
ny trust indicators for self-signed certs, unless the certs are somehow fla=
gged as having undergone anti-fraud checking (not known phishing sites, not=
 look-alike domains).<span style=3D"mso-spacerun: yes">=A0 </span>I can giv=
e you a concrete example of how the browsers will likely react.</p>

<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">=A0</p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">As many of you know, t=
here are extensive discussions right now about how to improve certificate r=
evocation checking.<span style=3D"mso-spacerun: yes">=A0 </span>Consumers o=
ften don=92t receive a response from the issuing CA to a revocation checkin=
g request via OCSP or CRL =96 because of connectivity problems and other is=
sues.<span style=3D"mso-spacerun: yes">=A0 </span>Because there are so many=
 response failures, the browsers today generally treat this as a =93soft de=
fault=94, let the consumer proceed to the site, and even show the padlock o=
r other trust indicator (e.g., green bar for EV certs).<span style=3D"mso-s=
pacerun: yes">=A0 </span>However, the browsers are getting tired of this, a=
nd looking for a way to make lack of an OCSP/CRL response a =93hard=94 defa=
ult.<span style=3D"mso-spacerun: yes">=A0 </span></p>

<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">=A0</p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">One browser =96 Opera =
=96 has already moved in this direction.<span style=3D"mso-spacerun: yes">=
=A0 </span>If someone using the Opera browser goes to a domain secured by a=
 CA-issued cert (DV, OV, or EV), and if there is no response to an OCSP rev=
ocation check request, Opera will not show ANY trust indicators for the sit=
e =96 no green bar, no lock icon, no UI to show TLS encryption.<span style=
=3D"mso-spacerun: yes">=A0 </span>(They don=92t block the site, so it=92s n=
ot a full =93hard=94 default.)<span style=3D"mso-spacerun: yes">=A0 </span>=
This is true even though the cert came from a CA whose roots are in Opera=
=92s trusted root store =96 if there=92s no OCSP response from a trusted CA=
, there will be no trust indicators in the UI.</p>

<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">=A0</p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">I=92m quite certain th=
is will be DANE=92s fate among browsers and other consumer facing applicati=
ons for self-signed certs, unless DANE builds into its specs some way to di=
stinguish self-signed certs that have gone through an anti-fraud check from=
 those that have not.<span style=3D"mso-spacerun: yes">=A0 </span>Browsers =
might give some sort of trust indicator for fraud-checked certs =96 at leas=
t to show the consumer that he or she is in TLS encryption.<span style=3D"m=
so-spacerun: yes">=A0 </span>Otherwise, I=92m pretty sure the UI won=92t ev=
en show encryption is happening because of the danger that phishers will us=
e DANE to trick people into thinking their sites are =93trustworthy=94.</p>

<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">=A0</p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">There may even be issu=
es with the browsers concerning revocation of self-signed certs =96 if cert=
s from CAs have to maintain CRLs and OCSP responders, someone might have to=
 maintain a revocation list of some sort for self-signed certs.</p>

<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">=A0</p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">How can self-signed ce=
rts get a =93designation=94 that they have undergone anti-fraud checking?<s=
pan style=3D"mso-spacerun: yes">=A0 </span>I don=92t know =96 maybe the DNS=
 operator flags the fraud-tested certs at the DNS system level?<span style=
=3D"mso-spacerun: yes">=A0 </span>There may be other ideas on how to do thi=
s from people on this discussion.<span style=3D"mso-spacerun: yes">=A0 </sp=
an>But in my opinion, this group needs to figure out how to keep the =93bad=
 guys=94 from using DANE and getting the same trust indicators that the goo=
d guys with self-signed certs hope to get.</p>

<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">=A0</p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt">Kirk</p></font>

--20cf307d049c82276f04a0ec0a9f--

From [email-masked]  Thu Apr 14 20:51:02 2011
Date: Thu, 14 Apr 2011 23:50:57 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dane] Expectations for Self-Signed Cert Trust Indicators under DANE

On Thu, 14 Apr 2011, Kirk Hall wrote:

> “The user should consider an unsecured page (no lock icon) as fraudulent. S

> Consumers have been taught to look for the lock icon as a trust symbol

Note that my firefox does not give me a lock symbol if I go to https://www.paypal.com

> your-account-bankofamerica.com
> my-email-live.com
> google-accounts.com
> my-paypal-account.com
> 
> All of these domains could use self-signed certs at the DNS operator level, and would then receive exactly the SAME trust indicators that YOUR domains will receive with a
> self-signed cert.

Yes. Just like that would be the case for www.xelerence.com (vs
www.xelerance.com). It just happens to be that I'm not paypal or verisign,
so the SSL people don't do as many checks to ensure my domain isn't
typosquatted.  And they can't. With the TLDs being so full legitimate
domains appear as a typosquats for other legitimate domains.

> 4.  I said in my earlier posting that this group should not expect browsers and other consumer-facing applications to give DANE any trust indicators for self-signed certs,
> unless the certs are somehow flagged as having undergone anti-fraud checking (not known phishing sites, not look-alike domains).  I can give you a concrete example of how the
> browsers will likely react.

Anti-fraud detection does not scale. Whether via certs or dane or
otherwise. The reason is works is because some "too big to fail" sites
get special protection. Dane does not really change that from the SSL
situation.  (in fact, DV/EV shows failures too,  seeing the mis-issued
domains we know about, and the large list of serials we don't even know
the domain of, and all the unqualified DV/EVs that have been 'fraud
checked' and are still not revoked)

> I’m quite certain this will be DANE’s fate among browsers and other consumer facing applications for self-signed certs, unless DANE builds into its specs some way to
> distinguish self-signed certs that have gone through an anti-fraud check from those that have not.

fraud detection is really out of scope for dane (both the working group
and the protocol) It is indeed a real problem that needs to be solved. But
no easy solution exists that will work for every domain.

> Browsers might give some sort of trust indicator for fraud-checked certs –

But how is this going to be different from round #1 (DV certs) and round
#2 (EV certs) ?  The fundamental problem being that "fraud checked"
means "pay someome more money" with a free market that slowly destroys
that in a few years. (when an EV certs costs $100, it's a pretty good
investment for a fraud, and with a legit paperwork behind it, they can
get that EV cert without problems)

> at least to show the consumer that he or she is in TLS encryption.  Otherwise, I’m pretty sure the UI won’t even show encryption is happening because of the danger that
> phishers will use DANE to trick people into thinking their sites are “trustworthy”.

How to deal with these are hard unsolved problems. I'll refrain from
further speculation.

> There may even be issues with the browsers concerning revocation of self-signed certs – if certs from CAs have to maintain CRLs and OCSP responders, someone might have to
> maintain a revocation list of some sort for self-signed certs.

The good thing about dane is that you can remove bad/stolen certs from
DNS. As for third parties determining my domain is a "forgery" and
blacklisting my dane backed cert, that in itself is a risky business
I'm sure the brower vendors would love to not get entangled in.

> How can self-signed certs get a “designation” that they have undergone anti-fraud checking?  I don’t know – maybe the DNS operator flags the fraud-tested certs at the DNS
> system level?  There may be other ideas on how to do this from people on this discussion.  But in my opinion, this group needs to figure out how to keep the “bad guys” from
> using DANE and getting the same trust indicators that the good guys with self-signed certs hope to get.

The IETF in general does not try to prevent "bad guys" from using
technology, even if it involves security or crypto. And for good reasons.

Dane does not solve the "fraud check issue". The only partial solutions we have
are the ones that work only because they're applied to so few sites.

However, dane does greatly enhance the move of port 80 to port 443, which in itself
is a huge win for everyone, and should certainly not be slowed down because
people might be fooled by crooks because crooks can now easier use TLS as well.

Paul

From [email-masked]  Thu Apr 14 23:11:30 2011
Date: Fri, 15 Apr 2011 02:11:27 -0400
From: Scott Schmit <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [dane] Expectations for Self-Signed Cert Trust Indicators under DANE

On Thu, Apr 14, 2011 at 07:45:55PM -0700, Kirk Hall wrote:
> 4.  I said in my earlier posting that this group should not expect browsers
> and other consumer-facing applications to give DANE any trust indicators for
> self-signed certs, unless the certs are somehow flagged as having undergone
> anti-fraud checking (not known phishing sites, not look-alike domains).  I
> can give you a concrete example of how the browsers will likely react.

<snip>

> How can self-signed certs get a â€œdesignationâ€ that they have undergone
> anti-fraud checking?  I donâ€™t know â€“ maybe the DNS operator flags the
> fraud-tested certs at the DNS system level?  There may be other ideas on how
> to do this from people on this discussion.  But in my opinion, this group
> needs to figure out how to keep the â€œbad guysâ€ from using DANE and getting
> the same trust indicators that the good guys with self-signed certs hope to
> get.

Attackers control their own DNS (presumably) & therefore are their own
DNS operators, so whatever flag you throw in the TLSA record would be
spoofed by the attackers.

DANE proves that the key on the other end actually belongs to the name
that the client/user specified.

What it doesn't/can't prove is that the client/user specified the right
name (i.e., it doesn't authenticate the mapping between DNS name and
organization/person). That's what CAs are supposed to be doing.

The claim is that DV certs not only bind a key to a (DNS) name, but also
prove that the domain isn't typosquatting some other domain (at least if
they're big enough to "matter"). With DANE vouching for the name/cert
association, the fraud cert question just turns into a DNSSEC-secured
DNSBL/DNSWL (with the advantage that multiple whitelists/blacklists can
be used, so if one of them makes too many mistakes, you can just drop
it from your trusted list with less hesitation).

For EV certs, to get the equivalent multi-CA check, you'd need each CA
to store a copy of the site's cert (bare key wouldn't be enough, since
the CA is actually binding a subject to the key rather than just a DNS
name), e.g.,
_443._tcp.amazon.com.ev.ca.example.com IN TLSA 1 0 1235...

-- 
Scott Schmit

From [email-masked]  Fri Apr 15 02:19:17 2011
Date: Fri, 15 Apr 2011 10:19:12 +0100
From: Ben Laurie <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [dane] Expectations for Self-Signed Cert Trust Indicators under DANE

On 13 April 2011 23:07, Phillip Hallam-Baker <[email-masked]> wrote:
> Can we stop the hyperbole?
> How many fraudulently issued CA certs in 15 years?
> How many subjects lost control of their private key?

You're in a better position to estimate this than me. But taking a
look at Comodo's CRL: it currently has 123 entries. Presumably each
entry is a cert that was either fraudulent or lost its private key in
the last year.

So, let's say there are 100 CAs, for the sake of argument: 15 x 123 x
100 =3D 184,500.

Quite a few.

>
> It is really easy to poke holes in an existing deployed security control.
> And really easy to propose alternatives that work perfectly in theory if =
you
> assume that they are not subject to the same issues.
>
> There are use cases for DV certs, but not in my view use cases that invol=
ve
> humans.
>
>
> On Wed, Apr 13, 2011 at 5:34 PM, Nicholas Weaver <[email-masked]=
du>
> wrote:
>>
>>
>> > One question to you: =A0what practical, actual, real world problem is =
DANE
>> > trying to solve? =A0Is there, in fact, a real security need today for =
someone
>> > to =93know=94 that they have reached the domain they intended to reach=
? =A0(Today,
>> > browsers tell you if there is a mismatch between a domain name and a
>> > CA-issued cert on that domain=92s servers, so to some degree that pote=
ntial
>> > security issue is already resolved.) =A0Do you have examples today of =
actual
>> > problems where people are unsure if they have connected with the domai=
ns
>> > they wanted, and there is a bad result? =A0(And if your example depend=
s on
>> > =93assume there has been a compromise of the DNS=94 =96 aren=92t all b=
ets off in
>> > that situation, where no solution is reliable?) =A0I=92m not trying to=
 be
>> > provocative =96 I really want to know what problem that actually exist=
s today
>> > would be solved with DANE.
>>
>> The actual, real world problem:
>>
>> The CA system is irrevocably broken: There are hundreds of potential pat=
hs
>> of trust, ANY of which can create a DV intercepting certificate for a
>> targeted name.
>>
>> There are incidents we know about happening (Comodo), and there are ones
>> we've suspected have happened (governments have the ability to purchase =
"SSL
>> interception boxes" as commercial products that just need a wildcard
>> certificate. =A0Such products wouldn't exist if governments couldn't get
>> wildcard certificates) but don't have captured certificates to prove.
>>
>>
>> DANE with just a self-signed certificate reduces the paths of trust to a
>> SINGLE path of trust, concurrent with the DNS resolution path for the na=
me.
>>
>> I can NEVER hope to trust "have to trust ALL of a set of hundreds", but =
I
>> MIGHT be able to trust "have to trust just a single path".
>>
>>
>> There's also an economic problem. =A0There is no logistical reason why a=
 CA
>> should charge 10x for *.mydomain.com when compared with www.mydomain.com=
.
>> =A0But they do.
>>
>> DANE with self-signed certificates gives *.mydomain.com, able to sign
>> anything in .mydomain.com, 'for free'.
>>
>>
>> The economic driver is IMO, enough to accomplish the real goal: DANE wit=
h
>> CA certs, which now means that two separate paths of trust (the 'one of =
a
>> hundred' CA plus the 'single-path' DNSSEC) needs to be compromised.
>>
>> _______________________________________________
>> dane mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dane
>
>
>
> --
> Website: http://hallambaker.com/
>
>
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>
>

From [email-masked]  Fri Apr 15 07:49:12 2011
Date: Fri, 15 Apr 2011 16:49:03 +0200
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
To: [email-masked]
Subject: Re: [dane] Expectations for Self-Signed Cert Trust Indicators under DANE

>> Do you have examples today of actual
>> problems where people are unsure if they have connected with the domains
>> they wanted, and there is a bad result?
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=460374
>
>
> I understand that CA's want to protect their business interests, and I
> recognize that if DANE-Provided Self-Signed certs were shown in the
> browser in the same manner as EV Certs there wouldn't be any need for
> CAs.  But that's hyperbole - I doubt anyone is pushing for that, I
> doubt further a browser would consider it.  I expect that institutions
> whose image depends on making their users comfortable will *always*
> employ CAs, and that the application users use to connect to those
> institutions for their critical transactions will *always* provide a
> mechanism to show that this institution has used the highest form of
> trustworthiness, and everyone gets warm fuzzies - the user, the
> institution, and the CA.

I think it's important to distinguish between two needs:

1) need to establish a secure connection (to the site/domain name)
2) need to check for (real) identity of the other side

In my view the DANE work is not trying to say anything about 2), but it 
will help to do more of 1), especially at places where self-signed certs 
are used now.

Also maybe the DV-certs are fraud checked for "well-known" names, but I 
would doubt that they will fraud-reject a DV-cert f.e. for surz.org - 
the very common mistake when switching from EN to CS keyboard (they have 
Z/Y keys interchanged).

The fact is that there are places where people just don't care about the 
identity of the other party, they just need to connect securely to the 
other end of the connection.

O.
--
OndÅ™ej SurÃ½ <[email-masked]>

From [email-masked]  Fri Apr 15 08:02:10 2011
Date: Fri, 15 Apr 2011 17:02:09 +0200
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
To: [email-masked]
Subject: Re: [dane] A browser's myopic view

On 4/14/11 3:20 PM, James Cloos wrote:
>>>>>> "ZW" == Zack Weinberg<[email-masked]>  writes:
>
> ZW>  it seems to me that putting a DNSSEC resolver in the browser
> ZW>  is a valuable near-term change in and of itself.
>
> In a dnssec world both recucursers and resolvers SHOULD validate.
>
> So, yes, validating resolver code in browsers and similar apps is
> a welcome addition.
>
> It would be best, though, to separate the resolving code out into
> its own library, just as encryption, et al are in separate libs
> (nss, gnutls, openssl, et cetera).  That would better facilitate
> review, trust and also re-use.

We have:

- libunbound

- DNSSEC-Tool's validator

O.

From [email-masked]  Fri Apr 15 08:23:33 2011
Date: Fri, 15 Apr 2011 08:23:32 -0700
From: Kirk Hall <[email-masked]>
To: Ben Laurie <[email-masked]>, [email-masked]
Subject: Re: [dane] Expectations for Self-Signed Cert Trust Indicators under DANE
Reply-To: [email-masked]

--00504502bb18efe2da04a0f69f94
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Ben =96 on this one point, I think you have overestimated the number of CRL
entries for fraudulently issued certs among CAs.  Different CAs follow
different practices in when they post a cert to their CRL.  Some post just
about everything =96 expired certs, certs with a month left that have alrea=
dy
been replaced for the customer, certs issued with minor errors to a custome=
r
and then reissued with corrections, certs the customer didn=92t pay for, et=
c.

Others (like my old company GeoTrust) limited their CRLs only to certs wher=
e
a party had explicitly requested revocation per our CPS, or in the rare cas=
e
where we suspected fraud or misuse.  Most GeoTrust revocations were because
of potential private key compromise, not fraud.  As I recall, the number of
certs on GeoTrust=92s CRL was never more than 20 or so at a time =96 and ag=
ain,
most of these were not for fraudulent issuance.  Most CAs do a pretty good
job of sifting through cert requests and rejecting them in advance if they
are from phishers, represent look-alike domains, can=92t produce necessary
proof of ownershipoif the domain or company name, etc. =96 so the cert isn=
=92t
issued, and there=92s no need for revocation.

Kirk

On Fri, Apr 15, 2011 at 2:19 AM, Ben Laurie <[email-masked]> wrote:

> On 13 April 2011 23:07, Phillip Hallam-Baker <[email-masked]> wrote:
> > Can we stop the hyperbole?
> > How many fraudulently issued CA certs in 15 years?
> > How many subjects lost control of their private key?
>
> You're in a better position to estimate this than me. But taking a
> look at Comodo's CRL: it currently has 123 entries. Presumably each
> entry is a cert that was either fraudulent or lost its private key in
> the last year.
>
> So, let's say there are 100 CAs, for the sake of argument: 15 x 123 x
> 100 =3D 184,500.
>
> Quite a few.
>
>
>

--00504502bb18efe2da04a0f69f94
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt"><span style=3D"FONT-SI=
ZE: 10pt; FONT-FAMILY: Arial">Ben =96 on this one point, I think you have o=
verestimated the number of CRL entries for fraudulently issued certs among =
CAs. <span style=3D"mso-spacerun: yes">=A0</span>Different CAs follow diffe=
rent practices in when they post a cert to their CRL. <span style=3D"mso-sp=
acerun: yes">=A0</span>Some post just about everything =96 expired certs, c=
erts with a month left that have already been replaced for the customer, ce=
rts issued with minor errors to a customer and then reissued with correctio=
ns, certs the customer didn=92t pay for, etc. <span style=3D"mso-spacerun: =
yes">=A0</span></span></p>

<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt"><span style=3D"FONT-SI=
ZE: 10pt; FONT-FAMILY: Arial">=A0</span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt"><span style=3D"FONT-SI=
ZE: 10pt; FONT-FAMILY: Arial">Others (like my old company GeoTrust) limited=
 their CRLs only to certs where a party had explicitly requested revocation=
 per our CPS, or in the rare case where we suspected fraud or misuse. <span=
 style=3D"mso-spacerun: yes">=A0</span>Most GeoTrust revocations were becau=
se of potential private key compromise, not fraud. <span style=3D"mso-space=
run: yes">=A0</span>As I recall, the number of certs on GeoTrust=92s CRL wa=
s never more than 20 or so at a time =96 and again, most of these were not =
for fraudulent issuance. <span style=3D"mso-spacerun: yes">=A0</span>Most C=
As do a pretty good job of sifting through cert requests and rejecting them=
 in advance if they are from phishers, represent look-alike domains, can=92=
t produce necessary proof of ownershipoif the domain or company name, etc. =
=96 so the cert isn=92t issued, and there=92s no need for revocation.</span=
></p>

<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt"><span style=3D"FONT-SI=
ZE: 10pt; FONT-FAMILY: Arial">=A0</span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt"><span style=3D"FONT-SI=
ZE: 10pt; FONT-FAMILY: Arial">Kirk</span></p>
<div class=3D"gmail_quote">=A0</div>
<div class=3D"gmail_quote">On Fri, Apr 15, 2011 at 2:19 AM, Ben Laurie <spa=
n dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>&gt=
;</span> wrote:<br></div>
<div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div class=3D"im">On 13 April 2011 23:07, Phillip Hallam-Baker &lt;<a href=
=3D"mailto:[email-masked]">[email-masked]</a>&gt; wrote:<br>&gt; Can we=
 stop the hyperbole?<br>&gt; How many fraudulently issued CA certs in 15 ye=
ars?<br>
&gt; How many subjects lost control of their private key?<br><br></div>You&=
#39;re in a better position to estimate this than me. But taking a<br>look =
at Comodo&#39;s CRL: it currently has 123 entries. Presumably each<br>entry=
 is a cert that was either fraudulent or lost its private key in<br>
the last year.<br><br>So, let&#39;s say there are 100 CAs, for the sake of =
argument: 15 x 123 x<br>100 =3D 184,500.<br><br>Quite a few.<br>
<div>
<div></div>
<div class=3D"h5"><br>=A0</div></div></blockquote></div>

--00504502bb18efe2da04a0f69f94--

From [email-masked]  Fri Apr 15 10:00:22 2011
Date: Fri, 15 Apr 2011 12:57:26 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

At 6:45 PM +0200 4/12/11, Martin Rex wrote:
>Stephen Kent wrote:
>>
>>  >For safety, it would be sensible to ALWAYS treat X.509v1 certs as
>>  >EndEntity certs (i.e. never accept them as signer of other certs).
>>  >Our TLS implementation had done this initially, but we had a customer
>>  >that had obtained server certs issued under a VeriSign X.509v1 CA cert
>>  >(as late as 2006!), so I had to make our OEM implementation tolerate this.
>>
>>  The fact that v1 certs contained no mechanism to distinguish between
>>  an EE cert and a CA cert was a major vulnerability, one that has been
>>  exploited in the browser context. I doubt that the IESG will approve
>>  an RFC that calls for supporting v1 certs at this time.
>
>Leaving the status of X.509v1 certs in limbo is a really bad idea.

I don't think of v1 certs as being in limbo. If one reads the intro to RFC 5280
(and its predecessors) there is a discussion of RFC 1422. That RFC described
how to use X.509 v1 certs in the Internet, specifically for secure 
e-mail (PEM).
That RFC noted many of the deficiencies with v1 certs and CRLs, and 
introduced naming and other conventions to try to compensate for 
these v1 cert/CRL problems. The RFC was a proposed standard. Is now 
historic, because we moved to v3 certs. So, any references to v1 
certs in current Internet standards
are downrefs to an Historic RFC, which is questionable for normative refs
at this date.

PKIX published a series of RFCs profiling v3 certs, starting with 
2459 (in 1999) The title has remained constant: "Internet X.509 
Public Key Infrastructure Certificate and CRL Profile." So, the 
message has always been that if one uses X.509 certs in the Internet, 
these certs should be v3, and CRLs should be v2. V1 certs were 
deprecated, consistent with moving 1422 to Historic. The fact that 
all of the v3 cert RFCs have included a discussion of 1422 and why we 
moved to v3 certs seems to be a pretty clear indication of the status 
of v1 certs.

Steve

From [email-masked]  Fri Apr 15 10:00:31 2011
Date: Fri, 15 Apr 2011 13:00:19 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

Martin,

...
>
>  This text says that a self-signed certificate is a CA certificate,
>  period. The last sentence says that an EE certificate cannot be used
>  to verify a signature on another certificate, and thus it is not a CA
>  certificate, and thus, not self-signed.

>That is not what rfc5280 says here.  It is really silent on
>self-asserted or self-issued End Entity certs.

5280 is not silent on this topic.  It says that a certificate is 
either and EE certificate of a CA certificate, and that CA 
certificates are of 3 types, one of which is self-signed. This is 
pretty clearly a partition of X.509 certificates in to EE and CA, and 
a further delineation of types of CA certificates. there is no 
ambiguity here, nor did I "misread" the RFC.  I am aware of no text 
in 5280 or in X.509 that suggests a self-signed certificate is 
anything other than a CA certificate.

>I'm somwhat puzzled about the description of (1) in 5280 section 3.2
>and the lack of description of a regular intermediate CA cert.

all CA certs that are not trust anchors are intermediate CA certs. I 
don't know why you are puzzled.

>My familiarity with X.509 and PKI is limited, so I may be wrong,
>but wasn't cross-certificates originally used for CAs that mutually
>sign each others public key in order to cross over between independent
>CA hierarchies?

cross-certs need not be issued in pairs, i.e., unilateral cross 
certification is allowed. But, I'm not sure what relevance this has 
to our discussion anyway.

...
>
>  When I scan 5246 I find one reference to a self-signed cert (page 48).
>  That text is talking about a "root certificate [sic] authority." So that
>  reference is NOT talking about SS certs as EE certs.

>You are looking in the wrong place:
>
>   TLSv1.0:    http://tools.ietf.org/html/rfc2246#section-7.4.2
>   TLSv1.1:    http://tools.ietf.org/html/rfc4346#section-7.4.2

no, I was looking in the RFCs cited by Mr. Farrell :-).

Also, the only text I see in 7.4.2 wrt self-signed certs says:

"Because certificate validation requires that root keys be 
distributed independently, the self-signed certificate which 
specifies the root certificate authority may optionally be omitted 
from the chain, under the assumption that the remote end must already 
possess it in order to validate it in any case."

This cites an ss-cert as a "root certificate [sic] authority" which 
is a CA, an not an EE. So the cite you provided does not support the 
notion of an ss-certificate as an EE certificate.

...

>http://tools.ietf.org/html/rfc5750#section-2.2
>
>2.2.  Certificate Choices
>
>    Receiving agents MUST support v1 X.509 and v3 X.509 certificates as
>    profiled in [KEYM].  End-entity certificates MAY include an Internet
>    mail address, as described in Section 3.

I guess the SEC ADs (and the PKIX chairs) missed this one! Thanks for 
noting that.  At the least errata should be issued. I'll confer with 
Sean on that, and he can see what the IESG wants to do about it, 
since this appears to be a normative reference to a cert format 
described in an Historic RFC and
deprecated in PKIX specs since 1999!

>
>  RFC 4572 makes a number of references to SS certs, and it does
>  envision using them as EE certs. However, the security analysis for using
>  SS certs here is flawed. For example it says (page 9) that it's OK to
>  use a SS cert to assert ANY identity in the TLS session or in an
>  S/MIME-protected SDP exchange.

>Where is your problem.  It is completely irrelevant which identity
>self-signed end entity certificates assert, because these name
>must be ignored anyway.

The WG has not yet decided what checks will be performed, so your 
comment is premature, at best.

>   The only thing that really counts in the
>public key -- and the public key represents the end entity.
>the name in there is only a self-asserted tag within the
>X.509 public key container

You are describing one possible solution, not one that has been adopted.
It is possible to use DNSSEC to publish a CA certificate (self-signed 
or not), and pass an EE certificate (issued under that CA certificate 
or via a cert path terminating at that cert) in the TLS handshake. 
That model would work for folks who have existing certificates issued 
under TAs embedded in browsers, as a transition mechanism, so it's 
clearly advantageous. 

>  In the name of interoperability, the
>  RFC also says (page 9) that if hop-by-hop integrity is employed for
>  SDP, then an SS cert is OK too, even though this allows any SDP
>  entity along the path to spoof any other entity.

>Authentication of self-signed entity certs is solely based on the 
>public key, the identities are completely irrelevant.

One does not "authenticate" a certificate (self-signed or otherwise). 
One validates" a certificate, and 5280 describes the validation 
process. It also notes that a self-signed (vs. self-issued) 
certificate is not subject to the validation process. Such a 
certificate must be acquired via some assured mechanism; DANE is a 
good example of such a mechanism.

I'm, not going to pursue this discussion with you any further. It's a 
poor use of my time and, hopefully, yours, and I'm on vacation for 
the next two weeks!

Steve

From [email-masked]  Fri Apr 15 10:44:09 2011
Date: Fri, 15 Apr 2011 10:44:08 -0700
From: Kirk Hall <[email-masked]>
To: Ben Laurie <[email-masked]>, [email-masked]
Subject: Re: [dane] Expectations for Self-Signed Cert Trust Indicators under DANE
Reply-To: [email-masked]

--0016e6d274d5bd14a904a0f89683
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

By the way, the entire revocation checking problem for CAs today (client
failure to get an OCSP response, etc.) could potentially be solved (in my
opinion) if the browsers created a comprehensive browser CRL (a CRL
contained in the browser itself, updated daily or immediately for a major
breach, CAs only allowed to post certs where revocation requested or
security breach - so a very small comprehensive CRL, no need for OCSP pings=
,
etc.) and/or browsers could give a signal to all clients to flush
(refresh) their CRL/OCSP cache in the event of a major security breach.
Here are details:

http://groups.google.com/group/mozilla.dev.security.policy/browse_thread/th=
read/4e14d1282667e9c6
#

With one of these solutions, the existing CA-based PKI infrastructure would
be much more secure for all.

On Fri, Apr 15, 2011 at 8:23 AM, Kirk Hall <[email-masked]> wrote:

> Ben =96 on this one point, I think you have overestimated the number of C=
RL
> entries for fraudulently issued certs among CAs.  Different CAs follow
> different practices in when they post a cert to their CRL.  Some post jus=
t
> about everything =96 expired certs, certs with a month left that have alr=
eady
> been replaced for the customer, certs issued with minor errors to a custo=
mer
> and then reissued with corrections, certs the customer didn=92t pay for, =
etc.
>
>
>
>
> Others (like my old company GeoTrust) limited their CRLs only to certs
> where a party had explicitly requested revocation per our CPS, or in the
> rare case where we suspected fraud or misuse.  Most GeoTrust revocations
> were because of potential private key compromise, not fraud.  As I recall=
,
> the number of certs on GeoTrust=92s CRL was never more than 20 or so at a=
 time
> =96 and again, most of these were not for fraudulent issuance.  Most CAs =
do
> a pretty good job of sifting through cert requests and rejecting them in
> advance if they are from phishers, represent look-alike domains, can=92t
> produce necessary proof of ownershipoif the domain or company name, etc. =
=96
> so the cert isn=92t issued, and there=92s no need for revocation.
>
>
>
> Kirk
>
> On Fri, Apr 15, 2011 at 2:19 AM, Ben Laurie <[email-masked]> wrote:
>
>> On 13 April 2011 23:07, Phillip Hallam-Baker <[email-masked]> wrote:
>> > Can we stop the hyperbole?
>> > How many fraudulently issued CA certs in 15 years?
>> > How many subjects lost control of their private key?
>>
>> You're in a better position to estimate this than me. But taking a
>> look at Comodo's CRL: it currently has 123 entries. Presumably each
>> entry is a cert that was either fraudulent or lost its private key in
>> the last year.
>>
>> So, let's say there are 100 CAs, for the sake of argument: 15 x 123 x
>> 100 =3D 184,500.
>>
>> Quite a few.
>>
>>
>>
>

--0016e6d274d5bd14a904a0f89683
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div>By the way, the entire revocation checking problem for CAs today=A0(cl=
ient failure to get an OCSP response, etc.) could potentially be solved (in=
 my opinion) if the browsers created a comprehensive browser CRL (a CRL con=
tained in the browser itself, updated daily or immediately for a major brea=
ch, CAs only allowed to post certs where revocation requested or security=
=A0breach - so a very small comprehensive CRL, no need for OCSP pings, etc.=
) and/or browsers could give a signal to all clients to flush (refresh)=A0t=
heir CRL/OCSP cache in the event of a major security breach.=A0 Here are de=
tails:</div>

<div>=A0</div>
<div><a href=3D"http://groups.google.com/group/mozilla.dev.security.policy/=
browse_thread/thread/4e14d1282667e9c6">http://groups.google.com/group/mozil=
la.dev.security.policy/browse_thread/thread/4e14d1282667e9c6</a>#</div>
<div>=A0</div>
<div>With one of these solutions, the existing CA-based PKI infrastructure =
would be much more secure for all.<br><br></div>
<div class=3D"gmail_quote">On Fri, Apr 15, 2011 at 8:23 AM, Kirk Hall <span=
 dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">khall@affirmtrust=
.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt"><span style=3D"FONT-SI=
ZE: 10pt; FONT-FAMILY: Arial">Ben =96 on this one point, I think you have o=
verestimated the number of CRL entries for fraudulently issued certs among =
CAs. <span>=A0</span>Different CAs follow different practices in when they =
post a cert to their CRL. <span>=A0</span>Some post just about everything =
=96 expired certs, certs with a month left that have already been replaced =
for the customer, certs issued with minor errors to a customer and then rei=
ssued with corrections, certs the customer didn=92t pay for, etc. <span>=A0=
</span></span></p>

<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt"><span style=3D"FONT-SI=
ZE: 10pt; FONT-FAMILY: Arial">=A0</span></p>
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt"><span style=3D"FONT-SI=
ZE: 10pt; FONT-FAMILY: Arial">Others (like my old company GeoTrust) limited=
 their CRLs only to certs where a party had explicitly requested revocation=
 per our CPS, or in the rare case where we suspected fraud or misuse. <span=
>=A0</span>Most GeoTrust revocations were because of potential private key =
compromise, not fraud. <span>=A0</span>As I recall, the number of certs on =
GeoTrust=92s CRL was never more than 20 or so at a time =96 and again, most=
 of these were not for fraudulent issuance. <span>=A0</span>Most CAs do a p=
retty good job of sifting through cert requests and rejecting them in advan=
ce if they are from phishers, represent look-alike domains, can=92t produce=
 necessary proof of ownershipoif the domain or company name, etc. =96 so th=
e cert isn=92t issued, and there=92s no need for revocation.</span></p>

<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt"><span style=3D"FONT-SI=
ZE: 10pt; FONT-FAMILY: Arial">=A0</span></p><font color=3D"#888888">
<p class=3D"MsoNormal" style=3D"MARGIN: 0in 0in 0pt"><span style=3D"FONT-SI=
ZE: 10pt; FONT-FAMILY: Arial">Kirk</span></p></font>
<div>
<div></div>
<div class=3D"h5">
<div class=3D"gmail_quote">=A0</div>
<div class=3D"gmail_quote">On Fri, Apr 15, 2011 at 2:19 AM, Ben Laurie <spa=
n dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">benl=
@google.com</a>&gt;</span> wrote:<br></div>
<div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"PADDING-LEFT: 1ex; MARGIN: 0px 0=
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div>On 13 April 2011 23:07, Phillip Hallam-Baker &lt;<a href=3D"mailto:hal=
[email-masked]" target=3D"_blank">[email-masked]</a>&gt; wrote:<br>&gt; Ca=
n we stop the hyperbole?<br>&gt; How many fraudulently issued CA certs in 1=
5 years?<br>
&gt; How many subjects lost control of their private key?<br><br></div>You&=
#39;re in a better position to estimate this than me. But taking a<br>look =
at Comodo&#39;s CRL: it currently has 123 entries. Presumably each<br>entry=
 is a cert that was either fraudulent or lost its private key in<br>
the last year.<br><br>So, let&#39;s say there are 100 CAs, for the sake of =
argument: 15 x 123 x<br>100 =3D 184,500.<br><br>Quite a few.<br>
<div>
<div></div>
<div><br>=A0</div></div></blockquote></div></div></div></blockquote></div><=
br>

--0016e6d274d5bd14a904a0f89683--

From [email-masked]  Fri Apr 15 12:29:35 2011
From: Martin Rex <[email-masked]>
To: [email-masked] (Stephen Kent)
Date: Fri, 15 Apr 2011 21:29:23 +0200 (MEST)
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.
Reply-To: [email-masked]

Stephen Kent wrote:
> 
> >http://tools.ietf.org/html/rfc5750#section-2.2
> >
> >2.2.  Certificate Choices
> >
> >    Receiving agents MUST support v1 X.509 and v3 X.509 certificates as
> >    profiled in [KEYM].  End-entity certificates MAY include an Internet
> >    mail address, as described in Section 3.
> 
> I guess the SEC ADs (and the PKIX chairs) missed this one! Thanks for 
> noting that.  At the least errata should be issued.

They didn't miss that one,  It is there for a very reasonable purpose.
Btw. the next paragraph in the above RFC (and its predecessor 3850) reads:

   Receiving agents SHOULD support X.509 version 2 attribute
   certificates.  See [ACAUTH] for details about the profile for
   attribute certificates.

So it doesn't only call for X.509v1 certs, but even for X.509v2 certs!

This definitely is not an error in that document.

-Martin

From [email-masked]  Fri Apr 15 12:35:42 2011
Date: Fri, 15 Apr 2011 15:35:37 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dane] [keyassure] Use cases document.

--20cf3071cebc7b28ff04a0fa25d9
Content-Type: text/plain; charset=ISO-8859-1

Nope, there is no X.509v3.

There is X.509 which describes formats for Certificates, Attribute
Certificates and CRLs each is versioned separately.

We are up to our third format for certs but only the second format for CRLs,
I can't remember what the current version of attribute cert is, but I seem
to remember its v2 (it would cost me money to check).

X.509 Attribute certs don't work anyway so the issue is moot.

On Fri, Apr 15, 2011 at 3:29 PM, Martin Rex <[email-masked]> wrote:

> Stephen Kent wrote:
> >
> > >http://tools.ietf.org/html/rfc5750#section-2.2
> > >
> > >2.2.  Certificate Choices
> > >
> > >    Receiving agents MUST support v1 X.509 and v3 X.509 certificates as
> > >    profiled in [KEYM].  End-entity certificates MAY include an Internet
> > >    mail address, as described in Section 3.
> >
> > I guess the SEC ADs (and the PKIX chairs) missed this one! Thanks for
> > noting that.  At the least errata should be issued.
>
> They didn't miss that one,  It is there for a very reasonable purpose.
> Btw. the next paragraph in the above RFC (and its predecessor 3850) reads:
>
>   Receiving agents SHOULD support X.509 version 2 attribute
>   certificates.  See [ACAUTH] for details about the profile for
>   attribute certificates.
>
> So it doesn't only call for X.509v1 certs, but even for X.509v2 certs!
>
> This definitely is not an error in that document.
>
>
> -Martin
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

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

--20cf3071cebc7b28ff04a0fa25d9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Nope, there is no X.509v3.=A0<div><br></div><div>There is X.509 which descr=
ibes formats for Certificates, Attribute Certificates and CRLs each is vers=
ioned separately.</div><div><br></div><div><br></div><div>We are up to our =
third format for certs but only the second format for CRLs, I can&#39;t rem=
ember what the current version of attribute cert is, but I seem to remember=
 its v2 (it would cost me money to check).</div>
<div><br></div><div>X.509 Attribute certs don&#39;t work anyway so the issu=
e is moot.</div><div><br></div><div><br><div class=3D"gmail_quote">On Fri, =
Apr 15, 2011 at 3:29 PM, Martin Rex <span dir=3D"ltr">&lt;<a href=3D"mailto=
:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;"><div class=3D"im">Stephen Kent wrote:<br>
&gt;<br>
&gt; &gt;<a href=3D"http://tools.ietf.org/html/rfc5750#section-2.2" target=
=3D"_blank">http://tools.ietf.org/html/rfc5750#section-2.2</a><br>
&gt; &gt;<br>
&gt; &gt;2.2. =A0Certificate Choices<br>
&gt; &gt;<br>
&gt; &gt; =A0 =A0Receiving agents MUST support v1 X.509 and v3 X.509 certif=
icates as<br>
&gt; &gt; =A0 =A0profiled in [KEYM]. =A0End-entity certificates MAY include=
 an Internet<br>
&gt; &gt; =A0 =A0mail address, as described in Section 3.<br>
&gt;<br>
&gt; I guess the SEC ADs (and the PKIX chairs) missed this one! Thanks for<=
br>
&gt; noting that. =A0At the least errata should be issued.<br>
<br>
</div>They didn&#39;t miss that one, =A0It is there for a very reasonable p=
urpose.<br>
Btw. the next paragraph in the above RFC (and its predecessor 3850) reads:<=
br>
<br>
 =A0 Receiving agents SHOULD support X.509 version 2 attribute<br>
 =A0 certificates. =A0See [ACAUTH] for details about the profile for<br>
 =A0 attribute certificates.<br>
<br>
So it doesn&#39;t only call for X.509v1 certs, but even for X.509v2 certs!<=
br>
<br>
This definitely is not an error in that document.<br>
<font color=3D"#888888"><br>
<br>
-Martin<br>
</font><div><div></div><div class=3D"h5">__________________________________=
_____________<br>
dane mailing list<br>
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/dane</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--20cf3071cebc7b28ff04a0fa25d9--

From [email-masked]  Fri Apr 15 23:34:51 2011
From: Peter Gutmann <[email-masked]>
To: [email-masked], [email-masked]
Date: Sat, 16 Apr 2011 18:34:46 +1200
Subject: Re: [dane] A browser's myopic view

=?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]> writes:

>We have:
>
>- libunbound

libunbound is nice, but (at least for the Windows incarnation) it's a DNS
server that you have to install and run as a Windows service.  Bzzt, fail.

Peter.

From [email-masked]  Fri Apr 15 23:55:16 2011
From: Peter Gutmann <[email-masked]>
To: [email-masked], [email-masked]
Date: Sat, 16 Apr 2011 18:55:12 +1200
Cc: [email-masked], [email-masked]
Subject: Re: [dane] Expectations for Self-Signed Cert Trust Indicators under DANE

Phillip Hallam-Baker <[email-masked]> writes:

> Can we stop the hyperbole?
> How many fraudulently issued CA certs in 15 years?

The answer to this is "we have absolutely no idea" (and I assume you mean
"certificates issued by commercial CAs" rather than "CAs issuing other CA
certificates").  From the evidence we have, both public and non-public (e.g.
security researchers trying to get a cert for, for example, apple.com, just to
see if they could), anyone who's ever tried to get a fraudulent certificate
has been able to.  In one case an AV researcher at F-Secure managed to trace
through the actions of a virus writer buying a certificate to sign malware,
and the malware author simply shopped around CAs until he found one who'd sell
him the certificate that he wanted.

So a more accurate summary of the situation is that "we have no evidence of
anyone who wanted to obtain a fraudulent certificate being prevented from
doing so".

Peter.

From [email-masked]  Sat Apr 16 06:23:17 2011
Date: Sat, 16 Apr 2011 18:53:10 +0530
From: Gihan Dias <[email-masked]>
Organization: University of Moratuwa
To: [email-masked]
Subject: Re: [dane] Expectations for Self-Signed Cert Trust Indicators under DANE

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 16-04-2011 12:25, Peter Gutmann wrote:
<blockquote cite="mid:[email-masked]"
 type="cite">
  <pre wrap="">From the evidence we have, both public and non-public (e.g.
security researchers trying to get a cert for, for example, apple.com, just to
see if they could), anyone who's ever tried to get a fraudulent certificate
has been able to.</pre>
</blockquote>
<font size="+1">Peter,<br>
<br>
Thanks for the info. Could you provide me some references for such
incidents?<br>
<br>
Regards,<br>
<br>
Gihan<br>
</font>
</body>
</html>

From [email-masked]  Sat Apr 16 10:37:04 2011
From: Wes Hardaker <[email-masked]>
To: Peter Gutmann <[email-masked]>
Date: Sat, 16 Apr 2011 10:36:23 -0700
Cc: [email-masked]
Subject: Re: [dane] A browser's myopic view

>>>>> On Sat, 16 Apr 2011 18:34:46 +1200, Peter Gutmann <[email-masked]> said:

>> - libunbound

PG> libunbound is nice, but (at least for the Windows incarnation) it's a DNS
PG> server that you have to install and run as a Windows service.  Bzzt, fail.

FYI, there are at least 1 maybe two other libraries that have/will-be
coming out (but I won't speak for them).

>From the DNSSEC-Tools side, we actually have two libraries.  One is a
pure resolving library and the second is the DNSSEC validation library.
They're intentionally divided into two pieces specifically so that in
theory the validation library could be re-attached to a different
resolving library (that supported the required features).  In practice,
we haven't actually tried to do this but architecturally it was designed
to meet the goals you're talking about.

The windows version of the library is very new and has been less well
tested, but it's been running on most of the "other OSes" for quite a while.
-- 
Wes Hardaker
Cobham Analytic Solutions

From [email-masked]  Sat Apr 16 14:20:31 2011
Date: Sat, 16 Apr 2011 17:20:26 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Peter Gutmann <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] A browser's myopic view

On Sat, 16 Apr 2011, Peter Gutmann wrote:

> =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]> writes:
>
>> We have:
>>
>> - libunbound
>
> libunbound is nice, but (at least for the Windows incarnation) it's a DNS
> server that you have to install and run as a Windows service.  Bzzt, fail.

No. You are confusing the unbound daemon with libunbound.

The current dane patch uses libunbound as a library within nss within firefox.
No service or daemon needs to be started.

Paul

From [email-masked]  Sat Apr 16 20:10:04 2011
From: Peter Gutmann <[email-masked]>
To: [email-masked], [email-masked]
Date: Sun, 17 Apr 2011 15:09:58 +1200
Cc: [email-masked]
Subject: Re: [dane] A browser's myopic view

Paul Wouters <[email-masked]> writes:

>No. You are confusing the unbound daemon with libunbound.
>
>The current dane patch uses libunbound as a library within nss within
>firefox. No service or daemon needs to be started.

Firefox is just a single case.  For DNSSEC to be useful everything that uses
the DNS has to be able to use it.  Under Windows this would mean a standalone
libunbound.dll that anything that talks TCP or UDP can use.

(I get the feeling that DNSSEC-aware Winsock is only going to be on Win7, and
possibly Vista (although given the IE10 Win7-only decision perhaps not), so
the largest, and most vulnerable user population won't have access to it
unless it's provided by a third party).

Peter.

From [email-masked]  Sun Apr 17 11:59:07 2011
From: Chris Palmer <[email-masked]>
Date: Sun, 17 Apr 2011 11:59:04 -0700
To: [email-masked]
Subject: Re: [dane] A browser's myopic view

On Apr 16, 2011, at 8:09 PM, Peter Gutmann wrote:

> Firefox is just a single case.  For DNSSEC to be useful everything =
that uses
> the DNS has to be able to use it.  Under Windows this would mean a =
standalone
> libunbound.dll that anything that talks TCP or UDP can use.
>=20
> (I get the feeling that DNSSEC-aware Winsock is only going to be on =
Win7, and
> possibly Vista (although given the IE10 Win7-only decision perhaps =
not), so
> the largest, and most vulnerable user population won't have access to =
it
> unless it's provided by a third party).

Skimming this guide to deploying DNSSEC for Windows 7/Server 2008 makes =
it seem like only Windows servers, but not Windows clients, can handle =
DNSSEC. (If that is true, it makes no sense other than to support =
software versioning business models and/or strange theories of network =
administration.) Therefore, the guide suggests you set clients to talk =
to their local recursive resolving servers via IPsec.

=
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=3D7a005a14-f74=
0-4689-8c43-9952b5c3d36f&displaylang=3Den

I haven't read it in full, but this passage is representative:

"""
Deploy Name Resolution Policy to Client Computers

In a DNSSEC deployment, validation of DNS queries by client computers is =
enabled through configuration of the following:

=95	IP security (IPsec). IPsec connection security rules are used to =
authenticate communications between DNS servers and client computers. =
For more information about configuring connection security rules, see =
Deploy IPsec Policy to DNS Servers and Deploy IPsec Policy to Client =
Computers.
=95	Name Resolution Policy Table (NRPT). The NRPT is a new feature =
available in Windows Server=AE 2008 R2 and Windows=AE 7 that contains =
policies and settings used by DNS clients when issuing DNS queries and =
receiving DNS responses. The NRPT enables a client to issue queries =
indicating the knowledge of DNSSEC and to check for validation in the =
response.

The following section provides information you can use to configure the =
NRPT.

You can use Group Policy to deploy DNSSEC settings to client computers =
if clients are domain members.  If all client computers are not domain =
members, you can configure DNSSEC settings in the Windows Registry or =
use registry scripts. For more information about the NRPT, see Appendix =
B: The Name Resolution Policy Table (NRPT).

Note: Client computers are typically configured to use multiple DNS =
servers on a network interface. For consistent client behavior, all DNS =
servers that are configured in client network interface properties =
should be capable of performing DNSSEC authentication of DNS queries.
"""

Phrases like "validation of DNS queries by client computers" suggests =
that clients will validate DNS responses, and yet the instructions have =
you using IPsec to rely on a server that does DNSSEC validation, =
suggesting that we are not enjoying end-to-end DNSSEC validation on =
Windows. I gather that the NRPT enables a client to tell its local =
resolving server, via IPsec, "Hey, do DNSSEC queries when querying on my =
behalf, validate the responses, and tell me the answer via IPsec also."

I am not a Windows network administration expert; hopefully somebody =
else on this list is and can clarify. Let's also just take any =
good-natured IPsec-related ribbing as read. ;)

In any case, if it is necessary to use libunbound as a client resolver =
library, or use the Unbound daemon on each client, I don't see what's so =
bad about that. Configuring a local service on all clients is easy =
enough with GPO or scripts, and is a small price to pay for actual =
end-to-end DNSSEC happiness. And it's better than building it into each =
application separately (which in turn is better than nothing).

--=20
Chris Palmer
Technology Director, Electronic Frontier Foundation
https://www.eff.org/code

From [email-masked]  Sun Apr 17 12:41:57 2011
Date: Sun, 17 Apr 2011 15:41:55 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Chris Palmer <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] A browser's myopic view

--20cf307cfcbcad947704a12277e5
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

When I tried to get Microsoft interested in DNSSEC many moons ago the
response from very senior people there was that they did not see much point
in securing DNS without a trusted routing layer (no BGPSEC would not qualif=
y
even if it existed).

That is one reason why I became interested in keys in the DNS. But it is
still a very uphill battle as DNSSEC is a monolithic single routed hierarch=
y
and the people who make the decisions at Microsoft are very much into model=
s
like Web of Trust and SDSI.

Given the recent announcement that IE10 will only be for Windows 7 and up, =
I
can't see any more development for Vista being likely.

On Sun, Apr 17, 2011 at 2:59 PM, Chris Palmer <[email-masked]> wrote:

> On Apr 16, 2011, at 8:09 PM, Peter Gutmann wrote:
>
> > Firefox is just a single case.  For DNSSEC to be useful everything that
> uses
> > the DNS has to be able to use it.  Under Windows this would mean a
> standalone
> > libunbound.dll that anything that talks TCP or UDP can use.
> >
> > (I get the feeling that DNSSEC-aware Winsock is only going to be on Win=
7,
> and
> > possibly Vista (although given the IE10 Win7-only decision perhaps not)=
,
> so
> > the largest, and most vulnerable user population won't have access to i=
t
> > unless it's provided by a third party).
>
> Skimming this guide to deploying DNSSEC for Windows 7/Server 2008 makes i=
t
> seem like only Windows servers, but not Windows clients, can handle DNSSE=
C.
> (If that is true, it makes no sense other than to support software
> versioning business models and/or strange theories of network
> administration.) Therefore, the guide suggests you set clients to talk to
> their local recursive resolving servers via IPsec.
>
>
> http://www.microsoft.com/downloads/en/details.aspx?FamilyID=3D7a005a14-f7=
40-4689-8c43-9952b5c3d36f&displaylang=3Den
>
> I haven't read it in full, but this passage is representative:
>
> """
> Deploy Name Resolution Policy to Client Computers
>
> In a DNSSEC deployment, validation of DNS queries by client computers is
> enabled through configuration of the following:
>
> =95       IP security (IPsec). IPsec connection security rules are used t=
o
> authenticate communications between DNS servers and client computers. For
> more information about configuring connection security rules, see Deploy
> IPsec Policy to DNS Servers and Deploy IPsec Policy to Client Computers.
> =95       Name Resolution Policy Table (NRPT). The NRPT is a new feature
> available in Windows Server=AE 2008 R2 and Windows=AE 7 that contains pol=
icies
> and settings used by DNS clients when issuing DNS queries and receiving D=
NS
> responses. The NRPT enables a client to issue queries indicating the
> knowledge of DNSSEC and to check for validation in the response.
>
> The following section provides information you can use to configure the
> NRPT.
>
> You can use Group Policy to deploy DNSSEC settings to client computers if
> clients are domain members.  If all client computers are not domain membe=
rs,
> you can configure DNSSEC settings in the Windows Registry or use registry
> scripts. For more information about the NRPT, see Appendix B: The Name
> Resolution Policy Table (NRPT).
>
> Note: Client computers are typically configured to use multiple DNS serve=
rs
> on a network interface. For consistent client behavior, all DNS servers t=
hat
> are configured in client network interface properties should be capable o=
f
> performing DNSSEC authentication of DNS queries.
> """
>
> Phrases like "validation of DNS queries by client computers" suggests tha=
t
> clients will validate DNS responses, and yet the instructions have you us=
ing
> IPsec to rely on a server that does DNSSEC validation, suggesting that we
> are not enjoying end-to-end DNSSEC validation on Windows. I gather that t=
he
> NRPT enables a client to tell its local resolving server, via IPsec, "Hey=
,
> do DNSSEC queries when querying on my behalf, validate the responses, and
> tell me the answer via IPsec also."
>
> I am not a Windows network administration expert; hopefully somebody else
> on this list is and can clarify. Let's also just take any good-natured
> IPsec-related ribbing as read. ;)
>
> In any case, if it is necessary to use libunbound as a client resolver
> library, or use the Unbound daemon on each client, I don't see what's so =
bad
> about that. Configuring a local service on all clients is easy enough wit=
h
> GPO or scripts, and is a small price to pay for actual end-to-end DNSSEC
> happiness. And it's better than building it into each application separat=
ely
> (which in turn is better than nothing).
>
>
> --
> Chris Palmer
> Technology Director, Electronic Frontier Foundation
> https://www.eff.org/code
>
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

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

--20cf307cfcbcad947704a12277e5
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div>When I tried to get Microsoft interested in DNSSEC many moons ago the =
response from very senior people there was that they did not see much point=
 in securing DNS without a trusted routing layer (no BGPSEC would not quali=
fy even if it existed).=A0</div>
<div><br></div><div>That is one reason why I became interested in keys in t=
he DNS. But it is still a very uphill battle as DNSSEC is a monolithic sing=
le routed hierarchy and the people who make the decisions at Microsoft are =
very much into models like Web of Trust and SDSI.=A0</div>
<div><br></div><div><br></div><div>Given the recent announcement that IE10 =
will only be for Windows 7 and up, I can&#39;t see any more development for=
 Vista being likely.=A0</div><div><br></div><div><br><div class=3D"gmail_qu=
ote">
On Sun, Apr 17, 2011 at 2:59 PM, Chris Palmer <span dir=3D"ltr">&lt;<a href=
=3D"mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex;">
<div class=3D"im">On Apr 16, 2011, at 8:09 PM, Peter Gutmann wrote:<br>
<br>
&gt; Firefox is just a single case. =A0For DNSSEC to be useful everything t=
hat uses<br>
&gt; the DNS has to be able to use it. =A0Under Windows this would mean a s=
tandalone<br>
&gt; libunbound.dll that anything that talks TCP or UDP can use.<br>
&gt;<br>
&gt; (I get the feeling that DNSSEC-aware Winsock is only going to be on Wi=
n7, and<br>
&gt; possibly Vista (although given the IE10 Win7-only decision perhaps not=
), so<br>
&gt; the largest, and most vulnerable user population won&#39;t have access=
 to it<br>
&gt; unless it&#39;s provided by a third party).<br>
<br>
</div>Skimming this guide to deploying DNSSEC for Windows 7/Server 2008 mak=
es it seem like only Windows servers, but not Windows clients, can handle D=
NSSEC. (If that is true, it makes no sense other than to support software v=
ersioning business models and/or strange theories of network administration=
.) Therefore, the guide suggests you set clients to talk to their local rec=
ursive resolving servers via IPsec.<br>

<br>
<a href=3D"http://www.microsoft.com/downloads/en/details.aspx?FamilyID=3D7a=
005a14-f740-4689-8c43-9952b5c3d36f&amp;displaylang=3Den" target=3D"_blank">=
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=3D7a005a14-f740=
-4689-8c43-9952b5c3d36f&amp;displaylang=3Den</a><br>

<br>
I haven&#39;t read it in full, but this passage is representative:<br>
<br>
&quot;&quot;&quot;<br>
Deploy Name Resolution Policy to Client Computers<br>
<br>
In a DNSSEC deployment, validation of DNS queries by client computers is en=
abled through configuration of the following:<br>
<br>
=95 =A0 =A0 =A0 IP security (IPsec). IPsec connection security rules are us=
ed to authenticate communications between DNS servers and client computers.=
 For more information about configuring connection security rules, see Depl=
oy IPsec Policy to DNS Servers and Deploy IPsec Policy to Client Computers.=
<br>

=95 =A0 =A0 =A0 Name Resolution Policy Table (NRPT). The NRPT is a new feat=
ure available in Windows Server=AE 2008 R2 and Windows=AE 7 that contains p=
olicies and settings used by DNS clients when issuing DNS queries and recei=
ving DNS responses. The NRPT enables a client to issue queries indicating t=
he knowledge of DNSSEC and to check for validation in the response.<br>

<br>
The following section provides information you can use to configure the NRP=
T.<br>
<br>
You can use Group Policy to deploy DNSSEC settings to client computers if c=
lients are domain members. =A0If all client computers are not domain member=
s, you can configure DNSSEC settings in the Windows Registry or use registr=
y scripts. For more information about the NRPT, see Appendix B: The Name Re=
solution Policy Table (NRPT).<br>

<br>
Note: Client computers are typically configured to use multiple DNS servers=
 on a network interface. For consistent client behavior, all DNS servers th=
at are configured in client network interface properties should be capable =
of performing DNSSEC authentication of DNS queries.<br>

&quot;&quot;&quot;<br>
<br>
Phrases like &quot;validation of DNS queries by client computers&quot; sugg=
ests that clients will validate DNS responses, and yet the instructions hav=
e you using IPsec to rely on a server that does DNSSEC validation, suggesti=
ng that we are not enjoying end-to-end DNSSEC validation on Windows. I gath=
er that the NRPT enables a client to tell its local resolving server, via I=
Psec, &quot;Hey, do DNSSEC queries when querying on my behalf, validate the=
 responses, and tell me the answer via IPsec also.&quot;<br>

<br>
I am not a Windows network administration expert; hopefully somebody else o=
n this list is and can clarify. Let&#39;s also just take any good-natured I=
Psec-related ribbing as read. ;)<br>
<br>
In any case, if it is necessary to use libunbound as a client resolver libr=
ary, or use the Unbound daemon on each client, I don&#39;t see what&#39;s s=
o bad about that. Configuring a local service on all clients is easy enough=
 with GPO or scripts, and is a small price to pay for actual end-to-end DNS=
SEC happiness. And it&#39;s better than building it into each application s=
eparately (which in turn is better than nothing).<br>

<font color=3D"#888888"><br>
<br>
--<br>
Chris Palmer<br>
Technology Director, Electronic Frontier Foundation<br>
<a href=3D"https://www.eff.org/code" target=3D"_blank">https://www.eff.org/=
code</a><br>
</font><div><div></div><div class=3D"h5"><br>
_______________________________________________<br>
dane mailing list<br>
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/dane</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--20cf307cfcbcad947704a12277e5--

From [email-masked]  Sun Apr 17 19:23:25 2011
From: Peter Gutmann <[email-masked]>
To: [email-masked], [email-masked]
Date: Mon, 18 Apr 2011 14:23:13 +1200
Subject: Re: [dane] A browser's myopic view

Chris Palmer <[email-masked]> writes:

>Skimming this guide to deploying DNSSEC for Windows 7/Server 2008 makes it
>seem like only Windows servers, but not Windows clients, can handle DNSSEC.
>(If that is true, it makes no sense other than to support software versioning
>business models and/or strange theories of network administration.)

I can think of several reasons other than that:

- "Turning on DNSSEC by default is going to cause lots of really hard-to- 
diagnose failures in end-user systems sitting behind crappy home networking 
gear and with ISPs that do odd things to DNS.  The support costs will be 
prohibitive (MS tries to optimise things to autoconfig themselves as much as 
possible, see their various auto-discovery protocols like WPAD and UPnP, 
because unlike everyone else even a 0.1% error rate is a crushing support 
load, and also unlike anyone else they'll make the front page of the NY Times 
if there are any problems).  We'll only enable it on the server, which has a 
knowledgeable sysadmin to try and sort things out".

- "DNSSEC isn't really defending against anything that attackers are 
exploiting, so the benefits consist primarily of (completely invisible to the 
user) warm fuzzies.  In addition the support costs [see above], therefore 
we'll only enable it on the server [see above]".

I'm sure there are others.  It's like AD, you'd never try and deploy that to
end-user PCs.

Peter.

From [email-masked]  Mon Apr 18 05:05:09 2011
Date: Mon, 18 Apr 2011 13:04:55 +0100
From: Stephen Farrell <[email-masked]>
To: Stephen Kent <[email-masked]>
Cc: pkix <[email-masked]>, [email-masked]
Subject: [dane] 5280 and self-signed ee certs (was: Re: [keyassure] Use cases document.)

Sorry to drag this out but I think its worth being clear as to
where the possible disagreement lies since that might influence
how dane approaches handling TLS servers with these kind of
self-signed data structures.

On 15/04/11 18:00, Stephen Kent wrote:
> 5280 is not silent on this topic.  

This is where one of the pkix chairs and one of the authors
of 5280 (me:-) disagree. "This topic" is whether or not
self-signed x.509 structures that are not for CAs are
"covered" by 5280. I believe Steve is saying that 5280 says
that such things are not allowed, whereas I believe that
5280 says nothing about them. I guess we both believe our
interpretation is the right one:-)

> It says that a certificate is either
> and EE certificate of a CA certificate, and that CA certificates are of
> 3 types, one of which is self-signed. This is pretty clearly a partition
> of X.509 certificates in to EE and CA, and a further delineation of
> types of CA certificates. there is no ambiguity here, nor did I
> "misread" the RFC.  

Disagree. Quoting (end of p12):

   This specification covers two classes of certificates: CA
   certificates and end entity certificates.  CA certificates may be
   further divided into three classes: cross-certificates, self-issued
   certificates, and self-signed certificates.

That says that some CA certs are self-signed. It does not say that
all self-signed certs are CA certs. It does not partition EE certs
into any classes at all.

A little further down it says that:

   Self-issued certificates are CA certificates in which
   the issuer and subject are the same entity.  Self-issued certificates
   are generated to support changes in policy or operations.  Self-
   signed certificates are self-issued certificates where the digital
   signature may be verified by the public key bound into the
   certificate.  Self-signed certificates are used to convey a public
   key for use to begin certification paths.

I recall this being added as a result of some confusion as to what
a self-issued vs. self-signed cert might be. I do not recall it being
added as anything normative (indeed there is no 2119 language there).
In any case, in context, it clearly is only referring to CA certs
since those are the only kind for which different (informative)
classes are called out.

And finally:

   End entity certificates
   are issued to subjects that are not authorized to issue certificates.

So I think in 5280 terms its probably fair to say that the term
"self-signed end entity cert" is a bit of a misnomer. However, that
is at this stage a fairly well understood term so I'm not sure if
we'll benefit from trying to get folks to use a different term.

> I am aware of no text in 5280 or in X.509 that
> suggests a self-signed certificate is anything other than a CA certificate.

That's consistent with either interpretation.

So I also took a look at the pkix list archives, and found only one
relevant thread from 2004 that unfortunately doesn't really help. [1]

   [1] http://www.imc.org/ietf-pkix/old-archive-04/msg01611.html

I also found some offlist mail from the design team that we had to
develop 3280bis (which became 5280). It just says:

   "Harmonize language in path validation. Some places used the defined
    term “self-issued” certificate while some places states the
    requirement that subject and issuer names are identical. These
    definitions differ since the term “self-issued” also requires that
    names must be non-empty." (That was issue#65 in a spreadsheet
    Dave Cooper constructed collecting issues for 3280bis dated
    Jan 14 2005, not sure if there's a public archive for that
    [email-masked] list or not.)

So again that doesn't help us here. I didn't find any other mails
with "self" in the subject line from my copy of the 3280bis design
team mails.

My conclusion is that neither 5280 nor the pkix archives justify
any conclusion about self-signed end-entity certs.

I guess if more consideration of this is needed, we should move
the discussion to pkix alone, until there's a conclusion that dane
can use. (So if following up on just the pkix aspect, removing
dane from the cc list is probably the right thing to do.)

To the extent it helps, the W3C web security context WG did also
consider this topic, and included text in their recommendation about
self-signed certs. [2] I think that clearly shows that that group
did envisage the use of this kind of thing for some web servers.
(I was involved in that group as an invited expert, but I don't
recall this particular aspect being in any way controversial there.
There was debate about what to do with such things, but not about
the terminology that I recall.)

   [2] http://www.w3.org/TR/wsc-ui/#selfsignedcerts

Stephen.

PS: Note that Steve's on vacation so this might just sit for a
few weeks until he's back to argue his side of the issue.

From [email-masked]  Mon Apr 18 07:52:25 2011
Date: Mon, 18 Apr 2011 10:52:17 -0400
From: "Osterweil, Eric" <[email-masked]>
To: Peter Gutmann <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] A browser's myopic view

On 4/16/11 1:36 PM, "Wes Hardaker" <[email-masked]> wrote:

>>>>>> On Sat, 16 Apr 2011 18:34:46 +1200, Peter Gutmann
>>>>>> <[email-masked]> said:
> 
>>> - libunbound
> 
> PG> libunbound is nice, but (at least for the Windows incarnation) it's a DNS
> PG> server that you have to install and run as a Windows service.  Bzzt, fail.
> 
> FYI, there are at least 1 maybe two other libraries that have/will-be
> coming out (but I won't speak for them).
> 
> From the DNSSEC-Tools side, we actually have two libraries.  One is a
> pure resolving library and the second is the DNSSEC validation library.
> They're intentionally divided into two pieces specifically so that in
> theory the validation library could be re-attached to a different
> resolving library (that supported the required features).  In practice,
> we haven't actually tried to do this but architecturally it was designed
> to meet the goals you're talking about.
> 
> The windows version of the library is very new and has been less well
> tested, but it's been running on most of the "other OSes" for quite a while.
> --

There is also libvdns ( http://www.vantage-points.org/libvdns.html ) that
does validation as well.  A few research groups have been working on it for
a couple of years. 

Eric

From [email-masked]  Mon Apr 18 14:29:02 2011
Date: Mon, 18 Apr 2011 23:28:53 +0200
From: Stefan Santesson <[email-masked]>
To: Stephen Farrell <[email-masked]>, Stephen Kent <[email-masked]>
Cc: pkix <[email-masked]>, [email-masked]
Subject: Re: [dane] [pkix] 5280 and self-signed ee certs (was: Re: [keyassure] Use cases document.)

Stephen,

So let me land somewhere in-between.

I understand what you mean by self-signed end-entity certs, but the term
is misleading.

A self signed cert is simply a convenient way to communicate a public key
for an entity that has not been certified by a CA.
I would say that it is a self signed cert. Period. Disregarding what type
of entity it represents.

The internet is full of them. Denying their valid existence does not help
anyone.
As far as RFC 5280 goes, it only deals with these certificates when used
as trust anchors in path validation.

When self-signed certificates are found in e.g. Signed metadata of an
identity federation, that federation may have its own conventions
regarding their use. They are not subject to 5280 path validation so all
of that is out of scope.

/Stefan

On 11-04-18 2:04 PM, "Stephen Farrell" <[email-masked]> wrote:

>
>Sorry to drag this out but I think its worth being clear as to
>where the possible disagreement lies since that might influence
>how dane approaches handling TLS servers with these kind of
>self-signed data structures.
>
>On 15/04/11 18:00, Stephen Kent wrote:
>> 5280 is not silent on this topic.
>
>This is where one of the pkix chairs and one of the authors
>of 5280 (me:-) disagree. "This topic" is whether or not
>self-signed x.509 structures that are not for CAs are
>"covered" by 5280. I believe Steve is saying that 5280 says
>that such things are not allowed, whereas I believe that
>5280 says nothing about them. I guess we both believe our
>interpretation is the right one:-)
>
>> It says that a certificate is either
>> and EE certificate of a CA certificate, and that CA certificates are of
>> 3 types, one of which is self-signed. This is pretty clearly a partition
>> of X.509 certificates in to EE and CA, and a further delineation of
>> types of CA certificates. there is no ambiguity here, nor did I
>> "misread" the RFC.
>
>Disagree. Quoting (end of p12):
>
>   This specification covers two classes of certificates: CA
>   certificates and end entity certificates.  CA certificates may be
>   further divided into three classes: cross-certificates, self-issued
>   certificates, and self-signed certificates.
>
>That says that some CA certs are self-signed. It does not say that
>all self-signed certs are CA certs. It does not partition EE certs
>into any classes at all.
>
>A little further down it says that:
>
>   Self-issued certificates are CA certificates in which
>   the issuer and subject are the same entity.  Self-issued certificates
>   are generated to support changes in policy or operations.  Self-
>   signed certificates are self-issued certificates where the digital
>   signature may be verified by the public key bound into the
>   certificate.  Self-signed certificates are used to convey a public
>   key for use to begin certification paths.
>
>I recall this being added as a result of some confusion as to what
>a self-issued vs. self-signed cert might be. I do not recall it being
>added as anything normative (indeed there is no 2119 language there).
>In any case, in context, it clearly is only referring to CA certs
>since those are the only kind for which different (informative)
>classes are called out.
>
>And finally:
>
>   End entity certificates
>   are issued to subjects that are not authorized to issue certificates.
>
>So I think in 5280 terms its probably fair to say that the term
>"self-signed end entity cert" is a bit of a misnomer. However, that
>is at this stage a fairly well understood term so I'm not sure if
>we'll benefit from trying to get folks to use a different term.
>
>> I am aware of no text in 5280 or in X.509 that
>> suggests a self-signed certificate is anything other than a CA
>>certificate.
>
>That's consistent with either interpretation.
>
>So I also took a look at the pkix list archives, and found only one
>relevant thread from 2004 that unfortunately doesn't really help. [1]
>
>   [1] http://www.imc.org/ietf-pkix/old-archive-04/msg01611.html
>
>I also found some offlist mail from the design team that we had to
>develop 3280bis (which became 5280). It just says:
>
>   "Harmonize language in path validation. Some places used the defined
>    term =B3self-issued=B2 certificate while some places states the
>    requirement that subject and issuer names are identical. These
>    definitions differ since the term =B3self-issued=B2 also requires that
>    names must be non-empty." (That was issue#65 in a spreadsheet
>    Dave Cooper constructed collecting issues for 3280bis dated
>    Jan 14 2005, not sure if there's a public archive for that
>    [email-masked] list or not.)
>
>So again that doesn't help us here. I didn't find any other mails
>with "self" in the subject line from my copy of the 3280bis design
>team mails.
>
>My conclusion is that neither 5280 nor the pkix archives justify
>any conclusion about self-signed end-entity certs.
>
>I guess if more consideration of this is needed, we should move
>the discussion to pkix alone, until there's a conclusion that dane
>can use. (So if following up on just the pkix aspect, removing
>dane from the cc list is probably the right thing to do.)
>
>To the extent it helps, the W3C web security context WG did also
>consider this topic, and included text in their recommendation about
>self-signed certs. [2] I think that clearly shows that that group
>did envisage the use of this kind of thing for some web servers.
>(I was involved in that group as an invited expert, but I don't
>recall this particular aspect being in any way controversial there.
>There was debate about what to do with such things, but not about
>the terminology that I recall.)
>
>   [2] http://www.w3.org/TR/wsc-ui/#selfsignedcerts
>
>Stephen.
>
>PS: Note that Steve's on vacation so this might just sit for a
>few weeks until he's back to argue his side of the issue.
>
>_______________________________________________
>pkix mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pkix

From [email-masked]  Mon Apr 18 15:00:16 2011
Date: Mon, 18 Apr 2011 18:00:13 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Stefan Santesson <[email-masked]>
Cc: pkix <[email-masked]>, [email-masked]
Subject: Re: [dane] [pkix] 5280 and self-signed ee certs (was: Re: [keyassure] Use cases document.)

--20cf30780e6e1c6a9004a1388481
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I agree that Kent is right on what the spec says.

But the standard is set by the consensus and the running code which
recognize self-signed certs..

I see the following courses of action as being open:

D1) DANE says nothing at all about this issue in the DANE spec (I see no
reason it need be mentioned at all).

D2) DANE says that the EE cert can be a self signed EE cert in accordance
with customary Internet usage

P1) PKIX writes draft on how to specify self signed EE certs so that this i=
s
properly understood. I.E. relying applications MUST NOT rely on any claims
other than the POP of the key and any restrictions on validity/usage.

P2) PKIX ignores the issue.

Note that D1/2 and P1/2 are orthogonal.

These certs exist and I can't see there being a consensus likely to emerge
to require a chain with a CA cert at the head. Nor can I see a requirement
to introduce a downref to X.509v1 to try to circumvent this.

On Mon, Apr 18, 2011 at 5:28 PM, Stefan Santesson <[email-masked]>wrote=
:

> Stephen,
>
> So let me land somewhere in-between.
>
> I understand what you mean by self-signed end-entity certs, but the term
> is misleading.
>
> A self signed cert is simply a convenient way to communicate a public key
> for an entity that has not been certified by a CA.
> I would say that it is a self signed cert. Period. Disregarding what type
> of entity it represents.
>
> The internet is full of them. Denying their valid existence does not help
> anyone.
> As far as RFC 5280 goes, it only deals with these certificates when used
> as trust anchors in path validation.
>
> When self-signed certificates are found in e.g. Signed metadata of an
> identity federation, that federation may have its own conventions
> regarding their use. They are not subject to 5280 path validation so all
> of that is out of scope.
>
> /Stefan
>
>
>
> On 11-04-18 2:04 PM, "Stephen Farrell" <[email-masked]> wrote:
>
> >
> >Sorry to drag this out but I think its worth being clear as to
> >where the possible disagreement lies since that might influence
> >how dane approaches handling TLS servers with these kind of
> >self-signed data structures.
> >
> >On 15/04/11 18:00, Stephen Kent wrote:
> >> 5280 is not silent on this topic.
> >
> >This is where one of the pkix chairs and one of the authors
> >of 5280 (me:-) disagree. "This topic" is whether or not
> >self-signed x.509 structures that are not for CAs are
> >"covered" by 5280. I believe Steve is saying that 5280 says
> >that such things are not allowed, whereas I believe that
> >5280 says nothing about them. I guess we both believe our
> >interpretation is the right one:-)
> >
> >> It says that a certificate is either
> >> and EE certificate of a CA certificate, and that CA certificates are o=
f
> >> 3 types, one of which is self-signed. This is pretty clearly a partiti=
on
> >> of X.509 certificates in to EE and CA, and a further delineation of
> >> types of CA certificates. there is no ambiguity here, nor did I
> >> "misread" the RFC.
> >
> >Disagree. Quoting (end of p12):
> >
> >   This specification covers two classes of certificates: CA
> >   certificates and end entity certificates.  CA certificates may be
> >   further divided into three classes: cross-certificates, self-issued
> >   certificates, and self-signed certificates.
> >
> >That says that some CA certs are self-signed. It does not say that
> >all self-signed certs are CA certs. It does not partition EE certs
> >into any classes at all.
> >
> >A little further down it says that:
> >
> >   Self-issued certificates are CA certificates in which
> >   the issuer and subject are the same entity.  Self-issued certificates
> >   are generated to support changes in policy or operations.  Self-
> >   signed certificates are self-issued certificates where the digital
> >   signature may be verified by the public key bound into the
> >   certificate.  Self-signed certificates are used to convey a public
> >   key for use to begin certification paths.
> >
> >I recall this being added as a result of some confusion as to what
> >a self-issued vs. self-signed cert might be. I do not recall it being
> >added as anything normative (indeed there is no 2119 language there).
> >In any case, in context, it clearly is only referring to CA certs
> >since those are the only kind for which different (informative)
> >classes are called out.
> >
> >And finally:
> >
> >   End entity certificates
> >   are issued to subjects that are not authorized to issue certificates.
> >
> >So I think in 5280 terms its probably fair to say that the term
> >"self-signed end entity cert" is a bit of a misnomer. However, that
> >is at this stage a fairly well understood term so I'm not sure if
> >we'll benefit from trying to get folks to use a different term.
> >
> >> I am aware of no text in 5280 or in X.509 that
> >> suggests a self-signed certificate is anything other than a CA
> >>certificate.
> >
> >That's consistent with either interpretation.
> >
> >So I also took a look at the pkix list archives, and found only one
> >relevant thread from 2004 that unfortunately doesn't really help. [1]
> >
> >   [1] http://www.imc.org/ietf-pkix/old-archive-04/msg01611.html
> >
> >I also found some offlist mail from the design team that we had to
> >develop 3280bis (which became 5280). It just says:
> >
> >   "Harmonize language in path validation. Some places used the defined
> >    term =B3self-issued=B2 certificate while some places states the
> >    requirement that subject and issuer names are identical. These
> >    definitions differ since the term =B3self-issued=B2 also requires th=
at
> >    names must be non-empty." (That was issue#65 in a spreadsheet
> >    Dave Cooper constructed collecting issues for 3280bis dated
> >    Jan 14 2005, not sure if there's a public archive for that
> >    [email-masked] list or not.)
> >
> >So again that doesn't help us here. I didn't find any other mails
> >with "self" in the subject line from my copy of the 3280bis design
> >team mails.
> >
> >My conclusion is that neither 5280 nor the pkix archives justify
> >any conclusion about self-signed end-entity certs.
> >
> >I guess if more consideration of this is needed, we should move
> >the discussion to pkix alone, until there's a conclusion that dane
> >can use. (So if following up on just the pkix aspect, removing
> >dane from the cc list is probably the right thing to do.)
> >
> >To the extent it helps, the W3C web security context WG did also
> >consider this topic, and included text in their recommendation about
> >self-signed certs. [2] I think that clearly shows that that group
> >did envisage the use of this kind of thing for some web servers.
> >(I was involved in that group as an invited expert, but I don't
> >recall this particular aspect being in any way controversial there.
> >There was debate about what to do with such things, but not about
> >the terminology that I recall.)
> >
> >   [2] http://www.w3.org/TR/wsc-ui/#selfsignedcerts
> >
> >Stephen.
> >
> >PS: Note that Steve's on vacation so this might just sit for a
> >few weeks until he's back to argue his side of the issue.
> >
> >_______________________________________________
> >pkix mailing list
> >[email-masked]
> >https://www.ietf.org/mailman/listinfo/pkix
>
>
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

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

--20cf30780e6e1c6a9004a1388481
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I agree that Kent is right on what the spec says.<div><br></div><div>But th=
e standard is set by the consensus and the running code which recognize sel=
f-signed certs..</div><div><br></div><div><br></div><div>I see the followin=
g courses of action as being open:</div>
<div><br></div><div>D1) DANE says nothing at all about this issue in the DA=
NE spec (I see no reason it need be mentioned at all).</div><div><br></div>=
<div>D2) DANE says that the EE cert can be a self signed EE cert in accorda=
nce with customary Internet usage</div>
<div><br></div><div>P1) PKIX writes draft on how to specify self signed EE =
certs so that this is properly understood. I.E. relying applications MUST N=
OT rely on any claims other than the POP of the key and any restrictions on=
 validity/usage.=A0</div>
<div><br></div><div>P2) PKIX ignores the issue.</div><div><br></div><div>No=
te that D1/2 and P1/2 are orthogonal.</div><div><br></div><div><br></div><d=
iv>These certs exist and I can&#39;t see there being a consensus likely to =
emerge to require a chain with a CA cert at the head. Nor can I see a requi=
rement to introduce a downref to X.509v1 to try to circumvent this.</div>
<div><br></div><div><br></div><div><br><div class=3D"gmail_quote">On Mon, A=
pr 18, 2011 at 5:28 PM, Stefan Santesson <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex;">
Stephen,<br>
<br>
So let me land somewhere in-between.<br>
<br>
I understand what you mean by self-signed end-entity certs, but the term<br=
>
is misleading.<br>
<br>
A self signed cert is simply a convenient way to communicate a public key<b=
r>
for an entity that has not been certified by a CA.<br>
I would say that it is a self signed cert. Period. Disregarding what type<b=
r>
of entity it represents.<br>
<br>
The internet is full of them. Denying their valid existence does not help<b=
r>
anyone.<br>
As far as RFC 5280 goes, it only deals with these certificates when used<br=
>
as trust anchors in path validation.<br>
<br>
When self-signed certificates are found in e.g. Signed metadata of an<br>
identity federation, that federation may have its own conventions<br>
regarding their use. They are not subject to 5280 path validation so all<br=
>
of that is out of scope.<br>
<br>
/Stefan<br>
<div><div></div><div class=3D"h5"><br>
<br>
<br>
On 11-04-18 2:04 PM, &quot;Stephen Farrell&quot; &lt;<a href=3D"mailto:step=
[email-masked]">[email-masked]</a>&gt; wrote:<br>
<br>
&gt;<br>
&gt;Sorry to drag this out but I think its worth being clear as to<br>
&gt;where the possible disagreement lies since that might influence<br>
&gt;how dane approaches handling TLS servers with these kind of<br>
&gt;self-signed data structures.<br>
&gt;<br>
&gt;On 15/04/11 18:00, Stephen Kent wrote:<br>
&gt;&gt; 5280 is not silent on this topic.<br>
&gt;<br>
&gt;This is where one of the pkix chairs and one of the authors<br>
&gt;of 5280 (me:-) disagree. &quot;This topic&quot; is whether or not<br>
&gt;self-signed x.509 structures that are not for CAs are<br>
&gt;&quot;covered&quot; by 5280. I believe Steve is saying that 5280 says<b=
r>
&gt;that such things are not allowed, whereas I believe that<br>
&gt;5280 says nothing about them. I guess we both believe our<br>
&gt;interpretation is the right one:-)<br>
&gt;<br>
&gt;&gt; It says that a certificate is either<br>
&gt;&gt; and EE certificate of a CA certificate, and that CA certificates a=
re of<br>
&gt;&gt; 3 types, one of which is self-signed. This is pretty clearly a par=
tition<br>
&gt;&gt; of X.509 certificates in to EE and CA, and a further delineation o=
f<br>
&gt;&gt; types of CA certificates. there is no ambiguity here, nor did I<br=
>
&gt;&gt; &quot;misread&quot; the RFC.<br>
&gt;<br>
&gt;Disagree. Quoting (end of p12):<br>
&gt;<br>
&gt; =A0 This specification covers two classes of certificates: CA<br>
&gt; =A0 certificates and end entity certificates. =A0CA certificates may b=
e<br>
&gt; =A0 further divided into three classes: cross-certificates, self-issue=
d<br>
&gt; =A0 certificates, and self-signed certificates.<br>
&gt;<br>
&gt;That says that some CA certs are self-signed. It does not say that<br>
&gt;all self-signed certs are CA certs. It does not partition EE certs<br>
&gt;into any classes at all.<br>
&gt;<br>
&gt;A little further down it says that:<br>
&gt;<br>
&gt; =A0 Self-issued certificates are CA certificates in which<br>
&gt; =A0 the issuer and subject are the same entity. =A0Self-issued certifi=
cates<br>
&gt; =A0 are generated to support changes in policy or operations. =A0Self-=
<br>
&gt; =A0 signed certificates are self-issued certificates where the digital=
<br>
&gt; =A0 signature may be verified by the public key bound into the<br>
&gt; =A0 certificate. =A0Self-signed certificates are used to convey a publ=
ic<br>
&gt; =A0 key for use to begin certification paths.<br>
&gt;<br>
&gt;I recall this being added as a result of some confusion as to what<br>
&gt;a self-issued vs. self-signed cert might be. I do not recall it being<b=
r>
&gt;added as anything normative (indeed there is no 2119 language there).<b=
r>
&gt;In any case, in context, it clearly is only referring to CA certs<br>
&gt;since those are the only kind for which different (informative)<br>
&gt;classes are called out.<br>
&gt;<br>
&gt;And finally:<br>
&gt;<br>
&gt; =A0 End entity certificates<br>
&gt; =A0 are issued to subjects that are not authorized to issue certificat=
es.<br>
&gt;<br>
&gt;So I think in 5280 terms its probably fair to say that the term<br>
&gt;&quot;self-signed end entity cert&quot; is a bit of a misnomer. However=
, that<br>
&gt;is at this stage a fairly well understood term so I&#39;m not sure if<b=
r>
&gt;we&#39;ll benefit from trying to get folks to use a different term.<br>
&gt;<br>
&gt;&gt; I am aware of no text in 5280 or in X.509 that<br>
&gt;&gt; suggests a self-signed certificate is anything other than a CA<br>
&gt;&gt;certificate.<br>
&gt;<br>
&gt;That&#39;s consistent with either interpretation.<br>
&gt;<br>
&gt;So I also took a look at the pkix list archives, and found only one<br>
&gt;relevant thread from 2004 that unfortunately doesn&#39;t really help. [=
1]<br>
&gt;<br>
&gt; =A0 [1] <a href=3D"http://www.imc.org/ietf-pkix/old-archive-04/msg0161=
1.html" target=3D"_blank">http://www.imc.org/ietf-pkix/old-archive-04/msg01=
611.html</a><br>
&gt;<br>
&gt;I also found some offlist mail from the design team that we had to<br>
&gt;develop 3280bis (which became 5280). It just says:<br>
&gt;<br>
&gt; =A0 &quot;Harmonize language in path validation. Some places used the =
defined<br>
&gt; =A0 =A0term =B3self-issued=B2 certificate while some places states the=
<br>
&gt; =A0 =A0requirement that subject and issuer names are identical. These<=
br>
&gt; =A0 =A0definitions differ since the term =B3self-issued=B2 also requir=
es that<br>
&gt; =A0 =A0names must be non-empty.&quot; (That was issue#65 in a spreadsh=
eet<br>
&gt; =A0 =A0Dave Cooper constructed collecting issues for 3280bis dated<br>
&gt; =A0 =A0Jan 14 2005, not sure if there&#39;s a public archive for that<=
br>
&gt; =A0 =A0<a href=3D"mailto:[email-masked]">[email-masked]</a> list o=
r not.)<br>
&gt;<br>
&gt;So again that doesn&#39;t help us here. I didn&#39;t find any other mai=
ls<br>
&gt;with &quot;self&quot; in the subject line from my copy of the 3280bis d=
esign<br>
&gt;team mails.<br>
&gt;<br>
&gt;My conclusion is that neither 5280 nor the pkix archives justify<br>
&gt;any conclusion about self-signed end-entity certs.<br>
&gt;<br>
&gt;I guess if more consideration of this is needed, we should move<br>
&gt;the discussion to pkix alone, until there&#39;s a conclusion that dane<=
br>
&gt;can use. (So if following up on just the pkix aspect, removing<br>
&gt;dane from the cc list is probably the right thing to do.)<br>
&gt;<br>
&gt;To the extent it helps, the W3C web security context WG did also<br>
&gt;consider this topic, and included text in their recommendation about<br=
>
&gt;self-signed certs. [2] I think that clearly shows that that group<br>
&gt;did envisage the use of this kind of thing for some web servers.<br>
&gt;(I was involved in that group as an invited expert, but I don&#39;t<br>
&gt;recall this particular aspect being in any way controversial there.<br>
&gt;There was debate about what to do with such things, but not about<br>
&gt;the terminology that I recall.)<br>
&gt;<br>
&gt; =A0 [2] <a href=3D"http://www.w3.org/TR/wsc-ui/#selfsignedcerts" targe=
t=3D"_blank">http://www.w3.org/TR/wsc-ui/#selfsignedcerts</a><br>
&gt;<br>
&gt;Stephen.<br>
&gt;<br>
&gt;PS: Note that Steve&#39;s on vacation so this might just sit for a<br>
&gt;few weeks until he&#39;s back to argue his side of the issue.<br>
&gt;<br>
&gt;_______________________________________________<br>
</div></div>&gt;pkix mailing list<br>
&gt;<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
&gt;<a href=3D"https://www.ietf.org/mailman/listinfo/pkix" target=3D"_blank=
">https://www.ietf.org/mailman/listinfo/pkix</a><br>
<div><div></div><div class=3D"h5"><br>
<br>
_______________________________________________<br>
dane mailing list<br>
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/dane</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--20cf30780e6e1c6a9004a1388481--

From [email-masked]  Mon Apr 18 15:49:37 2011
From: Martin Rex <[email-masked]>
To: [email-masked] (Phillip Hallam-Baker)
Date: Tue, 19 Apr 2011 00:49:28 +0200 (MEST)
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [dane] [pkix] 5280 and self-signed ee certs (was: Re:
Reply-To: [email-masked]

Phillip Hallam-Baker wrote:
> 
> But the standard is set by the consensus and the running code which
> recognize self-signed certs..
> 
> 
> I see the following courses of action as being open:
> 
> D1) DANE says nothing at all about this issue in the DANE spec (I see no
> reason it need be mentioned at all).
> 
> D2) DANE says that the EE cert can be a self signed EE cert in accordance
> with customary Internet usage
> 
> P1) PKIX writes draft on how to specify self signed EE certs so that this is
> properly understood. I.E. relying applications MUST NOT rely on any claims
> other than the POP of the key and any restrictions on validity/usage.
> 
> P2) PKIX ignores the issue.
> 
> Note that D1/2 and P1/2 are orthogonal.
> 
> 
> These certs exist and I can't see there being a consensus likely to emerge
> to require a chain with a CA cert at the head.

I have very little experience with / exposure to the discussions
in the PKIX WG, so I don't know how much I like (P1).

>From the data collected by EFF, there appear to be

  ~ 830000 self-signed X.509v3 Web Server Certs installed on the internet
           with the BasicConstraint cA=TRUE
  ~ 494000 self-signed X.509v1 Web Server Certs installed on the internet

  ~  56000 self-signed X.509v3 Web Server certs installed on the internet
           without the BasicConstraint cA=TRUE

There may be a much higher number of use case for self-signed certs
on home networks (HomeNAS, DSL-Router, Set-Top Boxes), but they're
probably irrelevant for DANE because most are on private IP-Addresses and
don't use officially registered DNS domains on their internal networks.

>
> Nor can I see a requirement
> to introduce a downref to X.509v1 to try to circumvent this.

I do not see the particular gripe that you have with X.509v1.

X.509v1 is a proper subset of X.509v3 -- nothing weird or awkard.

The beauty of X.509v1 certs is that they're *MUCH* easier to create
and hard to get wrong in an interop-impairing fashion.

And, the biggest advantage: enforcing a rule "do not accept as signers
of other certs" is trivial and fool-proof to implement, so that you
don't create immediate and serious problems when you add such
certs to the list of trusted keys for your PKI software along
with Trust Anchors from commercial CAs.

When you mix up self-signed CA certs from some web-servers into the
list of trusted keys next to rootCAs from commercial CAs, then
you may put yourself at risk today.

But what are you real options today, with programmatic clients?
Either disable the peer certificate check entirely, or add some
peers self-signed certs to the same file as the self-signed certs
of the commercial rootCAs.

-Martin

From [email-masked]  Tue Apr 19 00:46:12 2011
Date: Tue, 19 Apr 2011 09:45:37 +0200
From: Stefan Santesson <[email-masked]>
To: <[email-masked]>, Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [dane] [pkix]   5280 and self-signed ee certs (was: Re:

Martin,

For self signed certs in general I think X.509 v1 certs are just fine.

/Stefan

On 11-04-19 12:49 AM, "Martin Rex" <[email-masked]> wrote:

>Phillip Hallam-Baker wrote:
>> 
>> But the standard is set by the consensus and the running code which
>> recognize self-signed certs..
>> 
>> 
>> I see the following courses of action as being open:
>> 
>> D1) DANE says nothing at all about this issue in the DANE spec (I see no
>> reason it need be mentioned at all).
>> 
>> D2) DANE says that the EE cert can be a self signed EE cert in
>>accordance
>> with customary Internet usage
>> 
>> P1) PKIX writes draft on how to specify self signed EE certs so that
>>this is
>> properly understood. I.E. relying applications MUST NOT rely on any
>>claims
>> other than the POP of the key and any restrictions on validity/usage.
>> 
>> P2) PKIX ignores the issue.
>> 
>> Note that D1/2 and P1/2 are orthogonal.
>> 
>> 
>> These certs exist and I can't see there being a consensus likely to
>>emerge
>> to require a chain with a CA cert at the head.
>
>
>I have very little experience with / exposure to the discussions
>in the PKIX WG, so I don't know how much I like (P1).
>
>From the data collected by EFF, there appear to be
>
>  ~ 830000 self-signed X.509v3 Web Server Certs installed on the internet
>           with the BasicConstraint cA=TRUE
>  ~ 494000 self-signed X.509v1 Web Server Certs installed on the internet
>
>  ~  56000 self-signed X.509v3 Web Server certs installed on the internet
>           without the BasicConstraint cA=TRUE
>
>There may be a much higher number of use case for self-signed certs
>on home networks (HomeNAS, DSL-Router, Set-Top Boxes), but they're
>probably irrelevant for DANE because most are on private IP-Addresses and
>don't use officially registered DNS domains on their internal networks.
>
>
>>
>> Nor can I see a requirement
>> to introduce a downref to X.509v1 to try to circumvent this.
>
>I do not see the particular gripe that you have with X.509v1.
>
>X.509v1 is a proper subset of X.509v3 -- nothing weird or awkard.
>
>
>The beauty of X.509v1 certs is that they're *MUCH* easier to create
>and hard to get wrong in an interop-impairing fashion.
>
>And, the biggest advantage: enforcing a rule "do not accept as signers
>of other certs" is trivial and fool-proof to implement, so that you
>don't create immediate and serious problems when you add such
>certs to the list of trusted keys for your PKI software along
>with Trust Anchors from commercial CAs.
>
>When you mix up self-signed CA certs from some web-servers into the
>list of trusted keys next to rootCAs from commercial CAs, then
>you may put yourself at risk today.
>
>But what are you real options today, with programmatic clients?
>Either disable the peer certificate check entirely, or add some
>peers self-signed certs to the same file as the self-signed certs
>of the commercial rootCAs.
>
>
>-Martin
>_______________________________________________
>pkix mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pkix

From [email-masked]  Tue Apr 19 07:40:11 2011
Date: Tue, 19 Apr 2011 10:40:07 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: "Kemp, David P." <[email-masked]>
Cc: Stefan Santesson <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [dane] [pkix]  5280 and self-signed ee certs (was: Re:

--bcaec51b199d0eec5204a1467c71
Content-Type: text/plain; charset=ISO-8859-1

There is no problem with using X.509v1 certs.

But there is a very big problem with trying to make a normative reference in
a new standards proposal to a standard that has been deprecated (ITU) or
made HISTORIC (IETF).

Given the vast number of v1 certs in circulation plus the very long
lifetimes on many of them, I can't see a problem with requiring relying
applications to process v1 certs. The use case here would be to support a
device that shipped with a built in v1 device cert without having to rekey
the device.

But I can see a very big problem with attempting to get round the PKIX
lawyering with a requirement that cannot be supported in a reasonable manner
using the current standards.

I really don't see this as a DANE issue. I see it as a requirement to
clarify the PKIX spec as follows:

* CA signing key usage MUST be set for keys used to sign certificates for
any key OTHER THAN THEMSELVES.

* EE certs may be CA signed or self-signed.

* Security considerations for using self-signed certs (probably two pages
worth at least). Specifically, no positive claims can be relied on other
than POP for the key, all use restrictions and validity conditions MUST be
observed.

Since this is currently the largest class of server certificate deployed by
number of certs it would be ostrich-like behavior to ignore them. I can't
see programmers deciding that they want to have applications that generate
self-signed certs create a chain of two certs for no other purpose than to
comply with the spec.

On Tue, Apr 19, 2011 at 9:18 AM, Kemp, David P. <[email-masked]>wrote:

> There's nothing wrong with self-signed X.509 v1 certs except the "X.509"
> part and the "certificate" part.
>
> Self-signed keys have nice properties other than proof of possession -
> they allow an entity to "stake a claim" on a
> cryptographically-guaranteed-unused identity and support
> continuity-based (or reputation-based) trust in that identity, in
> addition to standard out-of-band mechanisms.  If wishes were horses ...
> everyone would use a PKIX-standard signed key assertion that was NOT a
> syntactically-valid X.509 certificate.  I don't see how using X.509v1
> instead of x.509v3 for self-signed end-entity keys prevents applications
> from misusing them as CA certs.
>
> Dave
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Stefan Santesson
> Sent: Tuesday, April 19, 2011 3:46 AM
> To: [email-masked]; Phillip Hallam-Baker
> Cc: [email-masked]; [email-masked]
> Subject: Re: [pkix] [dane] 5280 and self-signed ee certs (was: Re:
>
> Martin,
>
> For self signed certs in general I think X.509 v1 certs are just fine.
>
> /Stefan
>
> On 11-04-19 12:49 AM, "Martin Rex" <[email-masked]> wrote:
>
> >Phillip Hallam-Baker wrote:
> >>
> >> But the standard is set by the consensus and the running code which
> >> recognize self-signed certs..
> >>
> >>
> >> I see the following courses of action as being open:
> >>
> >> D1) DANE says nothing at all about this issue in the DANE spec (I see
> no
> >> reason it need be mentioned at all).
> >>
> >> D2) DANE says that the EE cert can be a self signed EE cert in
> >>accordance
> >> with customary Internet usage
> >>
> >> P1) PKIX writes draft on how to specify self signed EE certs so that
> >>this is
> >> properly understood. I.E. relying applications MUST NOT rely on any
> >>claims
> >> other than the POP of the key and any restrictions on validity/usage.
> >>
> >> P2) PKIX ignores the issue.
> >>
> >> Note that D1/2 and P1/2 are orthogonal.
> >>
> >>
> >> These certs exist and I can't see there being a consensus likely to
> >>emerge
> >> to require a chain with a CA cert at the head.
> >
> >
> >I have very little experience with / exposure to the discussions
> >in the PKIX WG, so I don't know how much I like (P1).
> >
> >From the data collected by EFF, there appear to be
> >
> >  ~ 830000 self-signed X.509v3 Web Server Certs installed on the
> internet
> >           with the BasicConstraint cA=TRUE
> >  ~ 494000 self-signed X.509v1 Web Server Certs installed on the
> internet
> >
> >  ~  56000 self-signed X.509v3 Web Server certs installed on the
> internet
> >           without the BasicConstraint cA=TRUE
> >
> >There may be a much higher number of use case for self-signed certs
> >on home networks (HomeNAS, DSL-Router, Set-Top Boxes), but they're
> >probably irrelevant for DANE because most are on private IP-Addresses
> and
> >don't use officially registered DNS domains on their internal networks.
> >
> >
> >>
> >> Nor can I see a requirement
> >> to introduce a downref to X.509v1 to try to circumvent this.
> >
> >I do not see the particular gripe that you have with X.509v1.
> >
> >X.509v1 is a proper subset of X.509v3 -- nothing weird or awkard.
> >
> >
> >The beauty of X.509v1 certs is that they're *MUCH* easier to create
> >and hard to get wrong in an interop-impairing fashion.
> >
> >And, the biggest advantage: enforcing a rule "do not accept as signers
> >of other certs" is trivial and fool-proof to implement, so that you
> >don't create immediate and serious problems when you add such
> >certs to the list of trusted keys for your PKI software along
> >with Trust Anchors from commercial CAs.
> >
> >When you mix up self-signed CA certs from some web-servers into the
> >list of trusted keys next to rootCAs from commercial CAs, then
> >you may put yourself at risk today.
> >
> >But what are you real options today, with programmatic clients?
> >Either disable the peer certificate check entirely, or add some
> >peers self-signed certs to the same file as the self-signed certs
> >of the commercial rootCAs.
> >
> >
> >-Martin
> >_______________________________________________
> >pkix mailing list
> >[email-masked]
> >https://www.ietf.org/mailman/listinfo/pkix
>
>
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>

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

--bcaec51b199d0eec5204a1467c71
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

There is no problem with using X.509v1 certs.<div><br></div><div>But there =
is a very big problem with trying to make a normative reference in a new st=
andards proposal to a standard that has been deprecated (ITU) or made HISTO=
RIC (IETF).<br>
<br></div><div><br></div><div>Given the vast number of v1 certs in circulat=
ion plus the very long lifetimes on many of them, I can&#39;t see a problem=
 with requiring relying applications to process v1 certs. The use case here=
 would be to support a device that shipped with a built in v1 device cert w=
ithout having to rekey the device.=A0</div>
<div><br></div><div>But I can see a very big problem with attempting to get=
 round the PKIX lawyering with a requirement that cannot be supported in a =
reasonable manner using the current standards.=A0</div><div><br></div><div>
<br></div><div>I really don&#39;t see this as a DANE issue. I see it as a r=
equirement to clarify the PKIX spec as follows:</div><div><br></div><div>* =
CA signing key usage MUST be set for keys used to sign certificates for any=
 key OTHER THAN THEMSELVES.</div>
<div><br></div><div>* EE certs may be CA signed or self-signed.</div><div><=
br></div><div>* Security considerations for using self-signed certs (probab=
ly two pages worth at least). Specifically, no positive claims can be relie=
d on other than POP for the key, all use restrictions and validity conditio=
ns MUST be observed.</div>
<div><br></div><div><br></div><div>Since this is currently the largest clas=
s of server certificate deployed by number of certs it would be ostrich-lik=
e behavior to ignore them. I can&#39;t see programmers deciding that they w=
ant to have applications that generate self-signed certs create a chain of =
two certs for no other purpose than to comply with the spec.</div>
<div><br></div><div><br></div><div><br></div><div><br></div><div><br><div c=
lass=3D"gmail_quote">On Tue, Apr 19, 2011 at 9:18 AM, Kemp, David P. <span =
dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">[email-masked].=
mil</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;">There&#39;s nothing wrong with self-signed =
X.509 v1 certs except the &quot;X.509&quot;<br>
part and the &quot;certificate&quot; part.<br>
<br>
Self-signed keys have nice properties other than proof of possession -<br>
they allow an entity to &quot;stake a claim&quot; on a<br>
cryptographically-guaranteed-unused identity and support<br>
continuity-based (or reputation-based) trust in that identity, in<br>
addition to standard out-of-band mechanisms. =A0If wishes were horses ...<b=
r>
everyone would use a PKIX-standard signed key assertion that was NOT a<br>
syntactically-valid X.509 certificate. =A0I don&#39;t see how using X.509v1=
<br>
instead of x.509v3 for self-signed end-entity keys prevents applications<br=
>
from misusing them as CA certs.<br>
<br>
Dave<br>
<br>
<br>
-----Original Message-----<br>
From: <a href=3D"mailto:[email-masked]">[email-masked]</a> [m=
ailto:<a href=3D"mailto:[email-masked]">[email-masked]</a>] O=
n Behalf Of<br>
Stefan Santesson<br>
Sent: Tuesday, April 19, 2011 3:46 AM<br>
To: <a href=3D"mailto:[email-masked]">[email-masked]</a>; Phillip Hallam-Baker<=
br>
Cc: <a href=3D"mailto:[email-masked]">[email-masked]</a>; <a href=3D"mailto:d=
[email-masked]">[email-masked]</a><br>
Subject: Re: [pkix] [dane] 5280 and self-signed ee certs (was: Re:<br>
<div><div></div><div class=3D"h5"><br>
Martin,<br>
<br>
For self signed certs in general I think X.509 v1 certs are just fine.<br>
<br>
/Stefan<br>
<br>
On 11-04-19 12:49 AM, &quot;Martin Rex&quot; &lt;<a href=3D"mailto:mrex@sap=
.com">[email-masked]</a>&gt; wrote:<br>
<br>
&gt;Phillip Hallam-Baker wrote:<br>
&gt;&gt;<br>
&gt;&gt; But the standard is set by the consensus and the running code whic=
h<br>
&gt;&gt; recognize self-signed certs..<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; I see the following courses of action as being open:<br>
&gt;&gt;<br>
&gt;&gt; D1) DANE says nothing at all about this issue in the DANE spec (I =
see<br>
no<br>
&gt;&gt; reason it need be mentioned at all).<br>
&gt;&gt;<br>
&gt;&gt; D2) DANE says that the EE cert can be a self signed EE cert in<br>
&gt;&gt;accordance<br>
&gt;&gt; with customary Internet usage<br>
&gt;&gt;<br>
&gt;&gt; P1) PKIX writes draft on how to specify self signed EE certs so th=
at<br>
&gt;&gt;this is<br>
&gt;&gt; properly understood. I.E. relying applications MUST NOT rely on an=
y<br>
&gt;&gt;claims<br>
&gt;&gt; other than the POP of the key and any restrictions on validity/usa=
ge.<br>
&gt;&gt;<br>
&gt;&gt; P2) PKIX ignores the issue.<br>
&gt;&gt;<br>
&gt;&gt; Note that D1/2 and P1/2 are orthogonal.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; These certs exist and I can&#39;t see there being a consensus like=
ly to<br>
&gt;&gt;emerge<br>
&gt;&gt; to require a chain with a CA cert at the head.<br>
&gt;<br>
&gt;<br>
&gt;I have very little experience with / exposure to the discussions<br>
&gt;in the PKIX WG, so I don&#39;t know how much I like (P1).<br>
&gt;<br>
&gt;From the data collected by EFF, there appear to be<br>
&gt;<br>
&gt; =A0~ 830000 self-signed X.509v3 Web Server Certs installed on the<br>
internet<br>
&gt; =A0 =A0 =A0 =A0 =A0 with the BasicConstraint cA=3DTRUE<br>
&gt; =A0~ 494000 self-signed X.509v1 Web Server Certs installed on the<br>
internet<br>
&gt;<br>
&gt; =A0~ =A056000 self-signed X.509v3 Web Server certs installed on the<br=
>
internet<br>
&gt; =A0 =A0 =A0 =A0 =A0 without the BasicConstraint cA=3DTRUE<br>
&gt;<br>
&gt;There may be a much higher number of use case for self-signed certs<br>
&gt;on home networks (HomeNAS, DSL-Router, Set-Top Boxes), but they&#39;re<=
br>
&gt;probably irrelevant for DANE because most are on private IP-Addresses<b=
r>
and<br>
&gt;don&#39;t use officially registered DNS domains on their internal netwo=
rks.<br>
&gt;<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; Nor can I see a requirement<br>
&gt;&gt; to introduce a downref to X.509v1 to try to circumvent this.<br>
&gt;<br>
&gt;I do not see the particular gripe that you have with X.509v1.<br>
&gt;<br>
&gt;X.509v1 is a proper subset of X.509v3 -- nothing weird or awkard.<br>
&gt;<br>
&gt;<br>
&gt;The beauty of X.509v1 certs is that they&#39;re *MUCH* easier to create=
<br>
&gt;and hard to get wrong in an interop-impairing fashion.<br>
&gt;<br>
&gt;And, the biggest advantage: enforcing a rule &quot;do not accept as sig=
ners<br>
&gt;of other certs&quot; is trivial and fool-proof to implement, so that yo=
u<br>
&gt;don&#39;t create immediate and serious problems when you add such<br>
&gt;certs to the list of trusted keys for your PKI software along<br>
&gt;with Trust Anchors from commercial CAs.<br>
&gt;<br>
&gt;When you mix up self-signed CA certs from some web-servers into the<br>
&gt;list of trusted keys next to rootCAs from commercial CAs, then<br>
&gt;you may put yourself at risk today.<br>
&gt;<br>
&gt;But what are you real options today, with programmatic clients?<br>
&gt;Either disable the peer certificate check entirely, or add some<br>
&gt;peers self-signed certs to the same file as the self-signed certs<br>
&gt;of the commercial rootCAs.<br>
&gt;<br>
&gt;<br>
&gt;-Martin<br>
&gt;_______________________________________________<br>
&gt;pkix mailing list<br>
&gt;<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
&gt;<a href=3D"https://www.ietf.org/mailman/listinfo/pkix" target=3D"_blank=
">https://www.ietf.org/mailman/listinfo/pkix</a><br>
<br>
<br>
_______________________________________________<br>
pkix mailing list<br>
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/pkix" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/pkix</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--bcaec51b199d0eec5204a1467c71--

From [email-masked]  Tue Apr 19 07:51:38 2011
Date: Tue, 19 Apr 2011 15:51:30 +0100
From: Stephen Farrell <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: Stefan Santesson <[email-masked]>, "Kemp, David P." <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [dane] [pkix]  5280 and self-signed ee certs (was: Re:

So can we take the discussion over to pkix then and have this be
the last message on this topic to dane until pkix has come to some
conclusion?

So *please* remove dane from followups.

S.

On 19/04/11 15:40, Phillip Hallam-Baker wrote:
> There is no problem with using X.509v1 certs.
> 
> But there is a very big problem with trying to make a normative
> reference in a new standards proposal to a standard that has been
> deprecated (ITU) or made HISTORIC (IETF).
> 
> 
> Given the vast number of v1 certs in circulation plus the very long
> lifetimes on many of them, I can't see a problem with requiring relying
> applications to process v1 certs. The use case here would be to support
> a device that shipped with a built in v1 device cert without having to
> rekey the device. 
> 
> But I can see a very big problem with attempting to get round the PKIX
> lawyering with a requirement that cannot be supported in a reasonable
> manner using the current standards. 
> 
> 
> I really don't see this as a DANE issue. I see it as a requirement to
> clarify the PKIX spec as follows:
> 
> * CA signing key usage MUST be set for keys used to sign certificates
> for any key OTHER THAN THEMSELVES.
> 
> * EE certs may be CA signed or self-signed.
> 
> * Security considerations for using self-signed certs (probably two
> pages worth at least). Specifically, no positive claims can be relied on
> other than POP for the key, all use restrictions and validity conditions
> MUST be observed.
> 
> 
> Since this is currently the largest class of server certificate deployed
> by number of certs it would be ostrich-like behavior to ignore them. I
> can't see programmers deciding that they want to have applications that
> generate self-signed certs create a chain of two certs for no other
> purpose than to comply with the spec.
> 
> 
> 
> 
> 
> On Tue, Apr 19, 2011 at 9:18 AM, Kemp, David P. <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     There's nothing wrong with self-signed X.509 v1 certs except the "X.509"
>     part and the "certificate" part.
> 
>     Self-signed keys have nice properties other than proof of possession -
>     they allow an entity to "stake a claim" on a
>     cryptographically-guaranteed-unused identity and support
>     continuity-based (or reputation-based) trust in that identity, in
>     addition to standard out-of-band mechanisms.  If wishes were horses ...
>     everyone would use a PKIX-standard signed key assertion that was NOT a
>     syntactically-valid X.509 certificate.  I don't see how using X.509v1
>     instead of x.509v3 for self-signed end-entity keys prevents applications
>     from misusing them as CA certs.
> 
>     Dave
> 
> 
>     -----Original Message-----
>     From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>] On
>     Behalf Of
>     Stefan Santesson
>     Sent: Tuesday, April 19, 2011 3:46 AM
>     To: [email-masked] <mailto:[email-masked]>; Phillip Hallam-Baker
>     Cc: [email-masked] <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>
>     Subject: Re: [pkix] [dane] 5280 and self-signed ee certs (was: Re:
> 
>     Martin,
> 
>     For self signed certs in general I think X.509 v1 certs are just fine.
> 
>     /Stefan
> 
>     On 11-04-19 12:49 AM, "Martin Rex" <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>     >Phillip Hallam-Baker wrote:
>     >>
>     >> But the standard is set by the consensus and the running code which
>     >> recognize self-signed certs..
>     >>
>     >>
>     >> I see the following courses of action as being open:
>     >>
>     >> D1) DANE says nothing at all about this issue in the DANE spec (I see
>     no
>     >> reason it need be mentioned at all).
>     >>
>     >> D2) DANE says that the EE cert can be a self signed EE cert in
>     >>accordance
>     >> with customary Internet usage
>     >>
>     >> P1) PKIX writes draft on how to specify self signed EE certs so that
>     >>this is
>     >> properly understood. I.E. relying applications MUST NOT rely on any
>     >>claims
>     >> other than the POP of the key and any restrictions on validity/usage.
>     >>
>     >> P2) PKIX ignores the issue.
>     >>
>     >> Note that D1/2 and P1/2 are orthogonal.
>     >>
>     >>
>     >> These certs exist and I can't see there being a consensus likely to
>     >>emerge
>     >> to require a chain with a CA cert at the head.
>     >
>     >
>     >I have very little experience with / exposure to the discussions
>     >in the PKIX WG, so I don't know how much I like (P1).
>     >
>     >From the data collected by EFF, there appear to be
>     >
>     >  ~ 830000 self-signed X.509v3 Web Server Certs installed on the
>     internet
>     >           with the BasicConstraint cA=TRUE
>     >  ~ 494000 self-signed X.509v1 Web Server Certs installed on the
>     internet
>     >
>     >  ~  56000 self-signed X.509v3 Web Server certs installed on the
>     internet
>     >           without the BasicConstraint cA=TRUE
>     >
>     >There may be a much higher number of use case for self-signed certs
>     >on home networks (HomeNAS, DSL-Router, Set-Top Boxes), but they're
>     >probably irrelevant for DANE because most are on private IP-Addresses
>     and
>     >don't use officially registered DNS domains on their internal networks.
>     >
>     >
>     >>
>     >> Nor can I see a requirement
>     >> to introduce a downref to X.509v1 to try to circumvent this.
>     >
>     >I do not see the particular gripe that you have with X.509v1.
>     >
>     >X.509v1 is a proper subset of X.509v3 -- nothing weird or awkard.
>     >
>     >
>     >The beauty of X.509v1 certs is that they're *MUCH* easier to create
>     >and hard to get wrong in an interop-impairing fashion.
>     >
>     >And, the biggest advantage: enforcing a rule "do not accept as signers
>     >of other certs" is trivial and fool-proof to implement, so that you
>     >don't create immediate and serious problems when you add such
>     >certs to the list of trusted keys for your PKI software along
>     >with Trust Anchors from commercial CAs.
>     >
>     >When you mix up self-signed CA certs from some web-servers into the
>     >list of trusted keys next to rootCAs from commercial CAs, then
>     >you may put yourself at risk today.
>     >
>     >But what are you real options today, with programmatic clients?
>     >Either disable the peer certificate check entirely, or add some
>     >peers self-signed certs to the same file as the self-signed certs
>     >of the commercial rootCAs.
>     >
>     >
>     >-Martin
>     >_______________________________________________
>     >pkix mailing list
>     >[email-masked] <mailto:[email-masked]>
>     >https://www.ietf.org/mailman/listinfo/pkix
> 
> 
>     _______________________________________________
>     pkix mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/pkix
> 
> 
> 
> 
> -- 
> Website: http://hallambaker.com/
> 
> 
> 
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

From [email-masked]  Tue Apr 19 08:01:33 2011
From: Peter Gutmann <[email-masked]>
To: [email-masked], [email-masked]
Date: Wed, 20 Apr 2011 03:01:19 +1200
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [dane] [pkix]  5280 and self-signed ee certs (was: Re:

Stephen Farrell <[email-masked]> writes:

>So can we take the discussion over to pkix then and have this be the last
>message on this topic to dane until pkix has come to some conclusion?

What if they never come to a conclusion (which is not unusual whenever a tough
topic comes up)?  We should probably set a timer to expire after which
(shudder) things start up here again.

(Sorry, still sent to DANE since it's relevant here.  "Kick it over to PKIX"
presupposes that it'll converge on a solution at some point).

Peter.

From [email-masked]  Tue Apr 19 08:28:08 2011
Date: Tue, 19 Apr 2011 12:28:04 -0300
From: Hugo Salgado <[email-masked]>
To: [email-masked]
OpenPGP: id=B525FA6E
Subject: [dane] Mnemonics in draft-ietf-dane-protocol

Hi.
I think it should be a lot clearer if we use mnemonics with
the certificate types, adding another column in the 5.2 table,
besides the "value" number. Maybe something like "ENDCERT" and
"CACERT"?

I count seven times "type 1" referring to the certificates, two
of them having an explicit explanatory text "client certificate..."

Regards,

Hugo

From [email-masked]  Tue Apr 19 13:15:28 2011
From: Jakob Schlyter <[email-masked]>
Date: Tue, 19 Apr 2011 22:15:20 +0200
To: Hugo Salgado <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] Mnemonics in draft-ietf-dane-protocol

On 19 apr 2011, at 17.28, Hugo Salgado wrote:

> I think it should be a lot clearer if we use mnemonics with
> the certificate types, adding another column in the 5.2 table,
> besides the "value" number. Maybe something like "ENDCERT" and
> "CACERT"?

One potential problem with this is that parsers implementing support for =
TLSA need to be updated every time a new certificate type is defined, =
most likely resulting in end user confusion. We do believe new types =
will be added in the future.

	jakob

From [email-masked]  Tue Apr 19 13:24:43 2011
Sender: [email-masked]
Date: Tue, 19 Apr 2011 13:21:24 -0700
From: Zack Weinberg <[email-masked]>
To: Jakob Schlyter <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] Mnemonics in draft-ietf-dane-protocol

Maybe there could be mnemonics in the standard but not in the record
presentation format?  I do like the idea of not having to say "type 1
cert" / "type 2 cert" all over the place in the spec.

zw

On Tue, Apr 19, 2011 at 1:15 PM, Jakob Schlyter <[email-masked]> wrote:
> On 19 apr 2011, at 17.28, Hugo Salgado wrote:
>
>> I think it should be a lot clearer if we use mnemonics with
>> the certificate types, adding another column in the 5.2 table,
>> besides the "value" number. Maybe something like "ENDCERT" and
>> "CACERT"?
>
> One potential problem with this is that parsers implementing support for =
TLSA need to be updated every time a new certificate type is defined, most =
likely resulting in end user confusion. We do believe new types will be add=
ed in the future.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0jakob
>
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

From [email-masked]  Tue Apr 19 06:19:14 2011
Content-class: urn:content-classes:message
Date: Tue, 19 Apr 2011 09:18:48 -0400
From: "Kemp, David P." <[email-masked]>
To: "Stefan Santesson" <[email-masked]>, <[email-masked]>, "Phillip Hallam-Baker" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [dane] [pkix]   5280 and self-signed ee certs (was: Re:

There's nothing wrong with self-signed X.509 v1 certs except the "X.509"
part and the "certificate" part.

Self-signed keys have nice properties other than proof of possession -
they allow an entity to "stake a claim" on a
cryptographically-guaranteed-unused identity and support
continuity-based (or reputation-based) trust in that identity, in
addition to standard out-of-band mechanisms.  If wishes were horses ...
everyone would use a PKIX-standard signed key assertion that was NOT a
syntactically-valid X.509 certificate.  I don't see how using X.509v1
instead of x.509v3 for self-signed end-entity keys prevents applications
from misusing them as CA certs.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stefan Santesson
Sent: Tuesday, April 19, 2011 3:46 AM
To: [email-masked]; Phillip Hallam-Baker
Cc: [email-masked]; [email-masked]
Subject: Re: [pkix] [dane] 5280 and self-signed ee certs (was: Re:

Martin,

For self signed certs in general I think X.509 v1 certs are just fine.

/Stefan

On 11-04-19 12:49 AM, "Martin Rex" <[email-masked]> wrote:

>Phillip Hallam-Baker wrote:
>>=20
>> But the standard is set by the consensus and the running code which
>> recognize self-signed certs..
>>=20
>>=20
>> I see the following courses of action as being open:
>>=20
>> D1) DANE says nothing at all about this issue in the DANE spec (I see
no
>> reason it need be mentioned at all).
>>=20
>> D2) DANE says that the EE cert can be a self signed EE cert in
>>accordance
>> with customary Internet usage
>>=20
>> P1) PKIX writes draft on how to specify self signed EE certs so that
>>this is
>> properly understood. I.E. relying applications MUST NOT rely on any
>>claims
>> other than the POP of the key and any restrictions on validity/usage.
>>=20
>> P2) PKIX ignores the issue.
>>=20
>> Note that D1/2 and P1/2 are orthogonal.
>>=20
>>=20
>> These certs exist and I can't see there being a consensus likely to
>>emerge
>> to require a chain with a CA cert at the head.
>
>
>I have very little experience with / exposure to the discussions
>in the PKIX WG, so I don't know how much I like (P1).
>
>From the data collected by EFF, there appear to be
>
>  ~ 830000 self-signed X.509v3 Web Server Certs installed on the
internet
>           with the BasicConstraint cA=3DTRUE
>  ~ 494000 self-signed X.509v1 Web Server Certs installed on the
internet
>
>  ~  56000 self-signed X.509v3 Web Server certs installed on the
internet
>           without the BasicConstraint cA=3DTRUE
>
>There may be a much higher number of use case for self-signed certs
>on home networks (HomeNAS, DSL-Router, Set-Top Boxes), but they're
>probably irrelevant for DANE because most are on private IP-Addresses
and
>don't use officially registered DNS domains on their internal networks.
>
>
>>
>> Nor can I see a requirement
>> to introduce a downref to X.509v1 to try to circumvent this.
>
>I do not see the particular gripe that you have with X.509v1.
>
>X.509v1 is a proper subset of X.509v3 -- nothing weird or awkard.
>
>
>The beauty of X.509v1 certs is that they're *MUCH* easier to create
>and hard to get wrong in an interop-impairing fashion.
>
>And, the biggest advantage: enforcing a rule "do not accept as signers
>of other certs" is trivial and fool-proof to implement, so that you
>don't create immediate and serious problems when you add such
>certs to the list of trusted keys for your PKI software along
>with Trust Anchors from commercial CAs.
>
>When you mix up self-signed CA certs from some web-servers into the
>list of trusted keys next to rootCAs from commercial CAs, then
>you may put yourself at risk today.
>
>But what are you real options today, with programmatic clients?
>Either disable the peer certificate check entirely, or add some
>peers self-signed certs to the same file as the self-signed certs
>of the commercial rootCAs.
>
>
>-Martin
>_______________________________________________
>pkix mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pkix

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

From [email-masked]  Wed Apr 20 11:30:05 2011
From: [email-masked]
To: [email-masked]
Date: Wed, 20 Apr 2011 11:30:05 -0700
Cc: [email-masked]
Subject: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF.

	Title           : Use Cases and Requirements for DNS-based Authentication of Named Entities
	Author(s)       : R. Barnes
	Filename        : draft-ietf-dane-use-cases-00.txt
	Pages           : 8
	Date            : 2011-04-20

Many current applications use the certificate-based authentication
features in TLS to allow clients to verify that a connected server
properly represents a desired domain name.  Traditionally, this
authentication has been based on PKIX trust hierarchies, rooted in
well-known CAs, but additional information can be provided via the
DNS itself.  This document describes a set of use cases in which the
DNS and DNSSEC could be used to make assertions that support the TLS
authentication process.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dane-use-cases-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body; name="draft-ietf-dane-use-cases-00.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart--

From [email-masked]  Wed Apr 20 11:39:41 2011
From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 20 Apr 2011 14:39:39 -0400
To: [email-masked]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt

This document is an attempt to capture
(1) A brief problem statement,
(2) The three main use cases discussed on the list, and
(3) A few additional requirements =20

Thanks especially to Eric, Zack, and Phil, from whom most of the =
underlying material is drawn.

Comments are welcome.

--Richard=20

On Apr 20, 2011, at 2:30 PM, [email-masked] wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
> This draft is a work item of the DNS-based Authentication of Named =
Entities Working Group of the IETF.
>=20
>=20
> 	Title           : Use Cases and Requirements for DNS-based =
Authentication of Named Entities
> 	Author(s)       : R. Barnes
> 	Filename        : draft-ietf-dane-use-cases-00.txt
> 	Pages           : 8
> 	Date            : 2011-04-20
>=20
> Many current applications use the certificate-based authentication
> features in TLS to allow clients to verify that a connected server
> properly represents a desired domain name.  Traditionally, this
> authentication has been based on PKIX trust hierarchies, rooted in
> well-known CAs, but additional information can be provided via the
> DNS itself.  This document describes a set of use cases in which the
> DNS and DNSSEC could be used to make assertions that support the TLS
> authentication process.
>=20
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-dane-use-cases-00.txt
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> <Mail Attachment>_______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

From [email-masked]  Wed Apr 20 11:58:01 2011
Date: Wed, 20 Apr 2011 12:57:58 -0600
From: Peter Saint-Andre <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Cc: [email-masked]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt

This is a cryptographically signed message in MIME format.

--------------ms050009030106010700090900
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 4/20/11 12:39 PM, Richard L. Barnes wrote:
> This document is an attempt to capture
> (1) A brief problem statement,
> (2) The three main use cases discussed on the list, and
> (3) A few additional requirements =20
>=20
> Thanks especially to Eric, Zack, and Phil, from whom most of the underl=
ying material is drawn.
>=20
> Comments are welcome.

My only comment is that this is a well-written and helpful document.

Peter

--=20
Peter Saint-Andre
https://stpeter.im/

--------------ms050009030106010700090900
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

AAAA
--------------ms050009030106010700090900--

From [email-masked]  Wed Apr 20 14:02:14 2011
Date: Wed, 20 Apr 2011 17:02:10 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt

On Wed, 20 Apr 2011, [email-masked] wrote:

> 	Title           : Use Cases and Requirements for DNS-based Authentication of Named Entities

Section 3 talks about "the two main use cases". I would rephrase that as
"two example use cases", as I doubt those are really the two main use
cases. In fact, they appear mostly to be one use case of "confirm PKIX
CA via DNSSEC". I think that the case of "no CA" is in fact the main use
case, if "main" is calculated in number of certificates deployed. I do
agree the second "main" use case is that of confirming the CA via DNSSEC
to avoid mis-issue by other CAs.

I would really like to see one of the use cases replaced with the
non-CA use case - preferably the one stating it *could* be used without
DNSSEC. I'd rather see that all DANE deployments insist on a mandatory
DNSSEC validation.

I like  the use cases in Section 4, but I miss the "HASTLS" type use
cases, where the DANE record can avoid a dangerous port 80 connect by
asserting via DANE with DNSSEC that all communication to a certain entity
is prefered or mandated to happen with TLS.

Paul

From [email-masked]  Wed Apr 20 14:06:27 2011
Date: Wed, 20 Apr 2011 17:06:25 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt

On Wed, 20 Apr 2011, Paul Wouters wrote:

And one more thing I forgot,

I don't see any use case where the TLS server can use DANE to
identify the TLS client via DANE, or somehow confirm the
client TLS certificate via DNS. Using such channel-binding could
give the TLS client additional access to resources on the TLS
server (in similar ways to the IPsec BTNS proposals)

Paul

From [email-masked]  Wed Apr 20 14:51:06 2011
From: Henry Story <[email-masked]>
Date: Wed, 20 Apr 2011 23:51:00 +0200
To: [email-masked]
Subject: [dane] Identity in the Browser at W3C

Hi all,

   there is a meeting "Idenitity in the Browser" at the W3C, with =
position papers due in
on 27th of this month.

    http://www.w3.org/2011/identity-ws/

   I hope this group will have a paper to present there. The WebID group =
mentions DANE
in the paper we are still writing. You can find the latest draft of that =
here

    http://bblfish.net/tmp/2011/04/20/

   All the best,

	Henry Story

Social Web Architect
http://bblfish.net/

From [email-masked]  Wed Apr 20 15:32:16 2011
Sender: [email-masked]
Date: Wed, 20 Apr 2011 15:32:14 -0700
From: Zack Weinberg <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt

On Wed, Apr 20, 2011 at 11:39 AM, Richard L. Barnes <[email-masked]> wrote:
> This document is an attempt to capture
> (1) A brief problem statement,
> (2) The three main use cases discussed on the list, and
> (3) A few additional requirements

Thanks for writing this up (and for incorporating my ideas :)
I generally like it, but I have a few small suggestions...

> 3.  Use Cases
>
>    In this section, we describe the two major use cases that the DANE
>    mechanism should support.  This list is not intended to represent all
>    possible ways that the DNS can be used to support TLS authentication.
>    Rather it represents the specific cases that comprise the initial
>    goal for DANE.

Sections 3.1, 3.2, and 3.3 currently each read as if they present an
independent use case, but you say there are only two use cases.
The connection between 3.1 and 3.2 should be made more obvious,
by factoring out the common text and describing them as two related
scenarios that fall under the same use case.

Or you could just change "two" to "three", but I think I prefer it if
CA-constraints and cert-constraints are lumped under the same
use case -- that leaves room for other mechanisms for limiting
the set of valid certificates.

>    Because these constraints do not increase the scope of PKIX-based
>    assertions about domains, there is not a strict requirement for
>    DNSSEC.  Deletion of records removes the protection provided by this
>    constraint, but the client is still protected by CA practices (as
>    now).  Injected or modified false records are not useful unless the
>    attacker can also obtain an unauthorized certificate.  In the worst
>    case, tampering with these constraints degrades security to the level
>    that is now standard.

Injected or modified false records can be used for denial of service
even if the attacker does not have an unauthorized certificate.  This
doesn't let an attacker who can tamper with DNS responses do anything
they couldn't already do by messing up the A record for the server.
DNSSEC wouldn't help, because the attacker could still cause a denial
of service by blocking *all* DNS responses for the target domain.  But
it should still be mentioned.

You should maybe also be clearer about what you mean by "unauthorized
certificate".  The attacker can of course generate keypairs, and over
in research land we usually assume an attacker can get a legitimate
cert (EV, even) *for a domain that they legitimately control*.  I
think by "unauthorized" you mean "certificate for the *target* domain,
illicitly signed by some CA."

>    Providing trust anchor material in this way clearly requires DNSSEC,
>    since corrupted or injected records could be used by an attacker to
>    cause clients to trust an attacker's certificate.  Deleted records
>    will only result in connection failure and denial of service,
>    although this could result on a bid-down to an unsecured protocol,
>    depending on the application.

... "bid-down to unsecured" is what we call a "downgrade attack" over
in research land.  Therefore, for this use case to be safe, clients
*must not* fall back to unsecured if records appear to have been deleted.

>    By the same token, this use case puts the most power in the hands of
>    DNS operators.  Since the operator of the appropriate DNS zone has de
>    facto control over the content and signing of the zone, he can create
>    false DANE records that bind a malicious party's certificate to a
>    domain.

Nice point.

>    This is not a significant incremental risk relative to the
>    current PKIX-based system, however, since it is possible for domain
>    operators to obtain certificates for domains under some well-known
>    certificate authorities today.

I can't parse this sentence.

>    Simple Key Management:  DANE must have a mode in which the domain
>       owner only needs to maintain a single long-lived public/private
>       key pair.

This one's new to me.  Why is it a must rather than a should?

>    Hard Failure:  Clients must be required to refuse to proceed with a
>       connection to a site if DANE indicates a security error.

People found this problematic.  Suggested replacement:

    No Downgrade: An attacker who can tamper with DNS responses should
    not be able to make a DANE-compliant client treat a site that has
    deployed DANE and DNSSEC like a site that has deployed neither.

I think that avoids all the objections while still getting at what I
wanted to get at in the first place.

>    Predictability:  Client behavior in response to DANE records must be
>       spelled out in the DANE specification as precisely as possible.

"DANE information" might be more appropriate than "DANE records",
since the actual record is probably not going to be called IN DANE.

Add "particularly for cases where DANE information is in conflict with
PKIX information", please.

zw

From [email-masked]  Wed Apr 20 16:05:44 2011
Date: Wed, 20 Apr 2011 19:05:43 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt

--20cf307d045c081bba04a161aa99
Content-Type: text/plain; charset=ISO-8859-1

These are not use cases.

:"Alice would like to be able to use generate and use certificates for her
website on alice.example.com

No, Alice has never wanted to do that. Certificates are merely a means to an
end.

A use case is the end objective of the stakeholder, e.g Alice wants to let
Bob come to her Web site without Mallet intercepting the conversation.

Restating the answer in the form of a question does not make it a use case.
The whole point of this exercise is to raise the level of abstraction above
the technical implementation.

There was a very clear consensus in the room at Prague that the group had
failed to adequately define the use cases and requirements. In particular
there was no way to evaluate many of the design choices.

Restating the architecture in the form of use cases does not address that
problem. We need to have use cases that describe the actual end purpose of
the stakeholders and parties.

On Wed, Apr 20, 2011 at 2:39 PM, Richard L. Barnes <[email-masked]> wrote:

> This document is an attempt to capture
> (1) A brief problem statement,
> (2) The three main use cases discussed on the list, and
> (3) A few additional requirements
>
> Thanks especially to Eric, Zack, and Phil, from whom most of the underlying
> material is drawn.
>
> Comments are welcome.
>
> --Richard
>
>
> On Apr 20, 2011, at 2:30 PM, [email-masked] wrote:
>
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the DNS-based Authentication of Named
> Entities Working Group of the IETF.
> >
> >
> >       Title           : Use Cases and Requirements for DNS-based
> Authentication of Named Entities
> >       Author(s)       : R. Barnes
> >       Filename        : draft-ietf-dane-use-cases-00.txt
> >       Pages           : 8
> >       Date            : 2011-04-20
> >
> > Many current applications use the certificate-based authentication
> > features in TLS to allow clients to verify that a connected server
> > properly represents a desired domain name.  Traditionally, this
> > authentication has been based on PKIX trust hierarchies, rooted in
> > well-known CAs, but additional information can be provided via the
> > DNS itself.  This document describes a set of use cases in which the
> > DNS and DNSSEC could be used to make assertions that support the TLS
> > authentication process.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-dane-use-cases-00.txt
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> > <Mail Attachment>_______________________________________________
> > dane mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/dane
>
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

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

--20cf307d045c081bba04a161aa99
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

These are not use cases.<div><br></div><div>:&quot;<meta charset=3D"utf-8">=
<span class=3D"Apple-style-span" style=3D"font-family: Times; font-size: me=
dium; "><span class=3D"Apple-style-span" style=3D"font-family: monospace; w=
hite-space: pre-wrap; ">Alice would like to be able to use generate and use=
 certificates for her website on <a href=3D"http://alice.example.com">alice=
.example.com</a> <br>
</span></span><br><div class=3D"gmail_quote">No, Alice has never wanted to =
do that. Certificates are merely a means to an end.</div><div class=3D"gmai=
l_quote"><br></div><div class=3D"gmail_quote">A use case is the end objecti=
ve of the stakeholder, e.g Alice wants to let Bob come to her Web site with=
out Mallet intercepting the conversation.</div>
<div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote"><br></div><=
div class=3D"gmail_quote">Restating the answer in the form of a question do=
es not make it a use case. The whole point of this exercise is to raise the=
 level of abstraction above the technical implementation.</div>
<div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">There was a=
 very clear consensus in the room at Prague that the group had failed to ad=
equately define the use cases and requirements. In particular there was no =
way to evaluate many of the design choices.</div>
<div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Restating t=
he architecture in the form of use cases does not address that problem. We =
need to have use cases that describe the actual end purpose of the stakehol=
ders and parties.</div>
<div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote"><br></div><=
div class=3D"gmail_quote">On Wed, Apr 20, 2011 at 2:39 PM, Richard L. Barne=
s <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">[email-masked]<=
/a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;">This document is an attempt to capture<br>
(1) A brief problem statement,<br>
(2) The three main use cases discussed on the list, and<br>
(3) A few additional requirements<br>
<br>
Thanks especially to Eric, Zack, and Phil, from whom most of the underlying=
 material is drawn.<br>
<br>
Comments are welcome.<br>
<br>
--Richard<br>
<div><div></div><div class=3D"h5"><br>
<br>
On Apr 20, 2011, at 2:30 PM, <a href=3D"mailto:[email-masked]">In=
[email-masked]</a> wrote:<br>
<br>
&gt; A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories.<br>
&gt; This draft is a work item of the DNS-based Authentication of Named Ent=
ities Working Group of the IETF.<br>
&gt;<br>
&gt;<br>
&gt; =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Use Cases and Requirements for=
 DNS-based Authentication of Named Entities<br>
&gt; =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : R. Barnes<br>
&gt; =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-dane-use-cases-00.txt=
<br>
&gt; =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 8<br>
&gt; =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-04-20<br>
&gt;<br>
&gt; Many current applications use the certificate-based authentication<br>
&gt; features in TLS to allow clients to verify that a connected server<br>
&gt; properly represents a desired domain name. =A0Traditionally, this<br>
&gt; authentication has been based on PKIX trust hierarchies, rooted in<br>
&gt; well-known CAs, but additional information can be provided via the<br>
&gt; DNS itself. =A0This document describes a set of use cases in which the=
<br>
&gt; DNS and DNSSEC could be used to make assertions that support the TLS<b=
r>
&gt; authentication process.<br>
&gt;<br>
&gt; A URL for this Internet-Draft is:<br>
&gt; <a href=3D"http://www.ietf.org/internet-drafts/draft-ietf-dane-use-cas=
es-00.txt" target=3D"_blank">http://www.ietf.org/internet-drafts/draft-ietf=
-dane-use-cases-00.txt</a><br>
&gt;<br>
&gt; Internet-Drafts are also available by anonymous FTP at:<br>
&gt; <a href=3D"ftp://ftp.ietf.org/internet-drafts/" target=3D"_blank">ftp:=
//ftp.ietf.org/internet-drafts/</a><br>
&gt;<br>
&gt; Below is the data which will enable a MIME compliant mail reader<br>
&gt; implementation to automatically retrieve the ASCII version of the<br>
&gt; Internet-Draft.<br>
</div></div>&gt; &lt;Mail Attachment&gt;___________________________________=
____________<br>
&gt; dane mailing list<br>
&gt; <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blan=
k">https://www.ietf.org/mailman/listinfo/dane</a><br>
<br>
_______________________________________________<br>
dane mailing list<br>
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/dane</a><br>
</blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a href=3D"htt=
p://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--20cf307d045c081bba04a161aa99--

From [email-masked]  Wed Apr 20 16:45:41 2011
From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 20 Apr 2011 19:45:37 -0400
To: Paul Wouters <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt

Hey Paul,

Thanks for the quick review.  Responses inline.

> Section 3 talks about "the two main use cases".=20

This is a legacy of an earlier draft, which had two instead of three use =
cases (the "Cert Lock" and "CA Lock" cases were combined).  I'm just =
going to delete the "two", so it applies to however many we end up with =
:)

> I would really like to see one of the use cases replaced with the
> non-CA use case - preferably the one stating it *could* be used =
without
> DNSSEC. I'd rather see that all DANE deployments insist on a mandatory
> DNSSEC validation.

I'm not sure there's consensus around that idea.  Ekr suggested the idea =
initially, and I agree that while there is security benefit to using =
DNSSEC for those cases, there is not additional risk in omitting it.

> I like  the use cases in Section 4, but I miss the "HASTLS" type use
> cases, where the DANE record can avoid a dangerous port 80 connect by
> asserting via DANE with DNSSEC that all communication to a certain =
entity
> is prefered or mandated to happen with TLS.

That was discussed earlier, and there seemed to be agreement that HASTLS =
problem was outside of the scope of DANE, better suited to =
application-layer groups like WEBSEC. =20

From [email-masked]  Wed Apr 20 16:49:34 2011
From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 20 Apr 2011 19:49:32 -0400
To: Paul Wouters <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt

> I don't see any use case where the TLS server can use DANE to
> identify the TLS client via DANE, or somehow confirm the
> client TLS certificate via DNS. Using such channel-binding could
> give the TLS client additional access to resources on the TLS
> server (in similar ways to the IPsec BTNS proposals)

I don't recall having seen discussion of that case on the list, but I =
would be open to adding it if there were a coherent story and others =
agreed. =20

The main question would seem to be what domain name the server would use =
to identify the client, and thus to look up the DANE records.  And the =
answer to that question would seem to vary by application-layer protocol =
(a lot -- think server-to-server XMPP vs. email vs. HTTPS).

How about a note of the following form in the introduction:
"
The use cases in this document are framed in terms of adding protections =
to TLS server certificates, since the use of these certificates to =
authenticate server domain names is very common.  In applications where =
TLS clients are also identified by domain names (e.g., XMPP =
server-to-server channels), the same considerations and use cases apply =
to TLS client certificates.=20
"

--Richard=

From [email-masked]  Wed Apr 20 17:03:58 2011
From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 20 Apr 2011 20:03:55 -0400
To: Zack Weinberg <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt

Hey Zack,

Thanks for the quick review.  Comments inline.

> Or you could just change "two" to "three", but I think I prefer it if
> CA-constraints and cert-constraints are lumped under the same
> use case -- that leaves room for other mechanisms for limiting
> the set of valid certificates.

The "two" is a vestige of an earlier version, in fact one in which the =
CA-constraints and cert-constraints *were* lumped together.  Some folks =
I sought early review from thought it would be clearer to have them =
separate. =20

As far as I'm concerned, it's a matter of taste / style.  I'll go with =
whichever gets the most votes.

> Injected or modified false records can be used for denial of service
> even if the attacker does not have an unauthorized certificate.  This
> doesn't let an attacker who can tamper with DNS responses do anything
> they couldn't already do by messing up the A record for the server.
> DNSSEC wouldn't help, because the attacker could still cause a denial
> of service by blocking *all* DNS responses for the target domain.  But
> it should still be mentioned.

Good point.  I will add something to this effect.

> You should maybe also be clearer about what you mean by "unauthorized
> certificate".  The attacker can of course generate keypairs, and over
> in research land we usually assume an attacker can get a legitimate
> cert (EV, even) *for a domain that they legitimately control*.  I
> think by "unauthorized" you mean "certificate for the *target* domain,
> illicitly signed by some CA.

That's correct.  I think instead of "unauthorized certificate", we can =
just use "a certificate for the target domain".

> ... "bid-down to unsecured" is what we call a "downgrade attack" over
> in research land.  Therefore, for this use case to be safe, clients
> *must not* fall back to unsecured if records appear to have been =
deleted.

Thanks, will change terminology and add text.

>=20
>>   By the same token, this use case puts the most power in the hands =
of
>>   DNS operators.  Since the operator of the appropriate DNS zone has =
de
>>   facto control over the content and signing of the zone, he can =
create
>>   false DANE records that bind a malicious party's certificate to a
>>   domain.
>=20
> Nice point.

Thanks!

>>   This is not a significant incremental risk relative to the
>>   current PKIX-based system, however, since it is possible for domain
>>   operators to obtain certificates for domains under some well-known
>>   certificate authorities today.
>=20
> I can't parse this sentence.

The current threat (as I understand it from others' posts on the list) =
is of the following form:=20
-- CAs need to validate that a CSR comes from a domain owner
-- CAs do this validation based on information about the domain, e.g., =
email addresses in WHOIS or the presence of certain records in the zone
-- DNS operators can control the DNS information that CAs base these =
validation decisions on
-- Therefore DNS operators can obtain certs for domains under their =
control

So the idea is that even though the "Autonomous Certificates" case =
enables an outsourced DNS operator to masquerade as a domain, he already =
has that ability.

Would it help to clarify here that we're talking about a domain =
*operator* versus a domain *owner* -- e.g., GoDaddy vs. me for =
geopriv.info?
=20

>>   Simple Key Management:  DANE must have a mode in which the domain
>>      owner only needs to maintain a single long-lived public/private
>>      key pair.
>=20
> This one's new to me.  Why is it a must rather than a should?

Paul Hoffman suggested this to me offline.  I'm willing to go with a =
should unless he objects.  (Note also that from a procedural POV, these =
are lower-case, so they don't have force of RFC 2119.)

>>   Hard Failure:  Clients must be required to refuse to proceed with a
>>      connection to a site if DANE indicates a security error.
>=20
> People found this problematic.  Suggested replacement:
>=20
>    No Downgrade: An attacker who can tamper with DNS responses should
>    not be able to make a DANE-compliant client treat a site that has
>    deployed DANE and DNSSEC like a site that has deployed neither.

Will change.

>=20
>>   Predictability:  Client behavior in response to DANE records must =
be
>>      spelled out in the DANE specification as precisely as possible.
>=20
> "DANE information" might be more appropriate than "DANE records",
> since the actual record is probably not going to be called IN DANE.

Will do.

> Add "particularly for cases where DANE information is in conflict with
> PKIX information", please.

Will do.=

From [email-masked]  Wed Apr 20 17:21:06 2011
From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 20 Apr 2011 20:21:03 -0400
To: "Richard L. Barnes" <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt

>>>  Hard Failure:  Clients must be required to refuse to proceed with a
>>>     connection to a site if DANE indicates a security error.
>>=20
>> People found this problematic.  Suggested replacement:
>>=20
>>   No Downgrade: An attacker who can tamper with DNS responses should
>>   not be able to make a DANE-compliant client treat a site that has
>>   deployed DANE and DNSSEC like a site that has deployed neither.
>=20
> Will change.

Also, I have taken the liberty of changing this from a "should" to a =
"must", since it's a rather important security requirement.

--Richard=

From [email-masked]  Wed Apr 20 18:01:37 2011
Sender: [email-masked]
Date: Wed, 20 Apr 2011 18:01:34 -0700
From: Zack Weinberg <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt

On Wed, Apr 20, 2011 at 5:03 PM, Richard L. Barnes <[email-masked]> wrote:
> The "two" is a vestige of an earlier version, in fact one in which the CA=
-constraints and cert-constraints *were* lumped together. =C2=A0Some folks =
I sought early review from thought it would be clearer to have them separat=
e.
>
> As far as I'm concerned, it's a matter of taste / style. =C2=A0I'll go wi=
th whichever gets the most votes.

Ok.  I don't care that much either way.

>> Injected or modified false records can be used for denial of service
>> even if the attacker does not have an unauthorized certificate.
>
> Good point. =C2=A0I will add something to this effect.

Thanks.

>> I think by "unauthorized" you mean "certificate for the *target* domain,
>> illicitly signed by some CA.
>
> That's correct. =C2=A0I think instead of "unauthorized certificate", we c=
an just use "a certificate for the target domain".

Sounds good.  It should be clear from context that the attacker isn't
supposed to have one of those.

>>> =C2=A0 This is not a significant incremental risk relative to the
>>> =C2=A0 current PKIX-based system, however, since it is possible for dom=
ain
>>> =C2=A0 operators to obtain certificates for domains under some well-kno=
wn
>>> =C2=A0 certificate authorities today.
>>
>> I can't parse this sentence.
>
> The current threat (as I understand it from others' posts on the list) is=
 of the following form:
> -- CAs need to validate that a CSR comes from a domain owner
> -- CAs do this validation based on information about the domain, e.g., em=
ail addresses in WHOIS or the presence of certain records in the zone
> -- DNS operators can control the DNS information that CAs base these vali=
dation decisions on
> -- Therefore DNS operators can obtain certs for domains under their contr=
ol
>
> So the idea is that even though the "Autonomous Certificates" case enable=
s an outsourced DNS operator to masquerade as a domain, he already has that=
 ability.

Yes, that helps a lot.

> Would it help to clarify here that we're talking about a domain *operator=
* versus a domain *owner* -- e.g., GoDaddy vs. me for geopriv.info?

Yes, I think so.

>> This one's new to me. =C2=A0Why is it a must rather than a should?
>
> Paul Hoffman suggested this to me offline. =C2=A0I'm willing to go with a=
 should unless he objects. =C2=A0(Note also that from a procedural POV, the=
se are lower-case, so they don't have force of RFC 2119.)

Ok, thanks for clarification.

>> =C2=A0 =C2=A0No Downgrade: An attacker who can tamper with DNS responses=
 should
>> =C2=A0 =C2=A0not be able to make a DANE-compliant client treat a site th=
at has
>> =C2=A0 =C2=A0deployed DANE and DNSSEC like a site that has deployed neit=
her.
>
> Will change. Also, I have taken the liberty of changing this from a "shou=
ld" to a "must", since it's a rather important security requirement.

Fine by me.  (I certainly hope that whatever language implements that
requirement in the final standard does get an uppercase MUST.)

zw

From [email-masked]  Wed Apr 20 18:04:36 2011
Date: Wed, 20 Apr 2011 21:04:32 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt

On Wed, 20 Apr 2011, Richard L. Barnes wrote:

> How about a note of the following form in the introduction:
> "
> The use cases in this document are framed in terms of adding protections to TLS server certificates, since the use of these certificates to authenticate server domain names is very common.  In applications where TLS clients are also identified by domain names (e.g., XMPP server-to-server channels), the same considerations and use cases apply to TLS client certificates.
> "

That works for me.

Paul

From [email-masked]  Wed Apr 20 18:05:11 2011
From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 20 Apr 2011 21:05:07 -0400
To: Zack Weinberg <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt

>>>>   This is not a significant incremental risk relative to the
>>>>   current PKIX-based system, however, since it is possible for =
domain
>>>>   operators to obtain certificates for domains under some =
well-known
>>>>   certificate authorities today.
>>>=20
>>> I can't parse this sentence.
>>=20
>> The current threat (as I understand it from others' posts on the =
list) is of the following form:
>> -- CAs need to validate that a CSR comes from a domain owner
>> -- CAs do this validation based on information about the domain, =
e.g., email addresses in WHOIS or the presence of certain records in the =
zone
>> -- DNS operators can control the DNS information that CAs base these =
validation decisions on
>> -- Therefore DNS operators can obtain certs for domains under their =
control
>>=20
>> So the idea is that even though the "Autonomous Certificates" case =
enables an outsourced DNS operator to masquerade as a domain, he already =
has that ability.
>=20
> Yes, that helps a lot.
>=20
>> Would it help to clarify here that we're talking about a domain =
*operator* versus a domain *owner* -- e.g., GoDaddy vs. me for =
geopriv.info?
>=20
> Yes, I think so.

Alright, I'll try to expand this text some to clarify these points.

--Richard

From [email-masked]  Wed Apr 20 18:13:15 2011
Date: Wed, 20 Apr 2011 21:13:12 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt

On Wed, 20 Apr 2011, Richard L. Barnes wrote:

>> I would really like to see one of the use cases replaced with the
>> non-CA use case - preferably the one stating it *could* be used without
>> DNSSEC. I'd rather see that all DANE deployments insist on a mandatory
>> DNSSEC validation.
>
> I'm not sure there's consensus around that idea.  Ekr suggested the idea initially, and I agree that while there is security benefit to using DNSSEC for those cases, there is not additional risk in omitting it.

Getting contradicting data is always a problem, whether it came from
falsification or not. That's why it is better to just draw a clear line
and say "MUST only use DANE information if the DNS answer was validated
with DNSSEC", thus avoiding contradicting data to begin with.

>> I like  the use cases in Section 4, but I miss the "HASTLS" type use
>> cases, where the DANE record can avoid a dangerous port 80 connect by
>> asserting via DANE with DNSSEC that all communication to a certain entity
>> is prefered or mandated to happen with TLS.
>
> That was discussed earlier, and there seemed to be agreement that HASTLS problem was outside of the scope of DANE, better suited to application-layer groups like WEBSEC.

I don't recall that at all. Does this mean the HASTLS work has been
moved out of the dane group? Has it been killed? Do you have a pointer
to information on that?

The risk here as mentioned before is that applications will start to
consider the presence of a TLSA/DANE record (at _443.tcp.*) as a "port
443 only" flag.

Paul

From [email-masked]  Wed Apr 20 18:23:23 2011
Date: Wed, 20 Apr 2011 21:23:22 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt

On Wed, 20 Apr 2011, Richard L. Barnes wrote:

>> I would really like to see one of the use cases replaced with the
>> non-CA use case

You did not answer this part of my question yet, only:

>>- preferably the one stating it *could* be used without
>> DNSSEC. I'd rather see that all DANE deployments insist on a mandatory
>> DNSSEC validation.

The largest use case (by number) is to not use any CA/PKIX, and to phase
out all current warnings from browsers about self signed certs using
dane authenticated certificates.

Paul

From [email-masked]  Wed Apr 20 18:29:29 2011
From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 20 Apr 2011 21:29:26 -0400
To: Paul Wouters <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt

>>> I would really like to see one of the use cases replaced with the
>>> non-CA use case
>=20
> You did not answer this part of my question yet

Sorry, I assumed this was a result of the "two" confusion, which has =
been resolved.  I removed the "two", so now it just says "the main use =
cases". =20

Why do we need to replace any use cases?  The non-CA use case is already =
in there (3.3); do you think one of the others (3.1, 3.2) needs to be =
deleted?

--Richard=

From [email-masked]  Wed Apr 20 18:41:25 2011
From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 20 Apr 2011 21:41:21 -0400
To: Paul Wouters <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt

>>> I would really like to see one of the use cases replaced with the
>>> non-CA use case - preferably the one stating it *could* be used =
without
>>> DNSSEC. I'd rather see that all DANE deployments insist on a =
mandatory
>>> DNSSEC validation.
>>=20
>> I'm not sure there's consensus around that idea.  Ekr suggested the =
idea initially, and I agree that while there is security benefit to =
using DNSSEC for those cases, there is not additional risk in omitting =
it.
>=20
> Getting contradicting data is always a problem, whether it came from
> falsification or not. That's why it is better to just draw a clear =
line
> and say "MUST only use DANE information if the DNS answer was =
validated
> with DNSSEC", thus avoiding contradicting data to begin with.

This document isn't setting those sorts of requirements.  All it's doing =
is saying "If the solution doesn't require DNSSEC in this case, then =
these are the implications."  The protocol document could make this =
requirement, if there's consensus for it.=20

>>> I like  the use cases in Section 4, but I miss the "HASTLS" type use
>>> cases, where the DANE record can avoid a dangerous port 80 connect =
by
>>> asserting via DANE with DNSSEC that all communication to a certain =
entity
>>> is prefered or mandated to happen with TLS.
>>=20
>> That was discussed earlier, and there seemed to be agreement that =
HASTLS problem was outside of the scope of DANE, better suited to =
application-layer groups like WEBSEC.
>=20
> I don't recall that at all. Does this mean the HASTLS work has been
> moved out of the dane group? Has it been killed? Do you have a pointer
> to information on that?

See, e.g., the following mailing list posts:
<http://www.ietf.org/mail-archive/web/dane/current/msg00130.html>
<http://www.ietf.org/mail-archive/web/dane/current/msg00121.html>
<http://www.ietf.org/mail-archive/web/dane/current/msg00803.html>
<http://www.ietf.org/mail-archive/web/dane/current/msg00682.html>

With regard to ESRV (in the last of the above), see also the discussion =
of DNS-based HSTS alternatives at the WEBSEC meeting at IETF 79:
<http://tools.ietf.org/wg/websec/minutes?item=3Dminutes79.html>

--Richard

P.S. While trawling through the list archives, I found this message from =
an earlier version of myself:
"
I won't object very strongly to a problem statement I-D, but I don't =
think one is really necessary.
"
Oh well, so much for that!
<http://www.ietf.org/mail-archive/web/dane/current/msg00813.html>=

From [email-masked]  Wed Apr 20 18:50:03 2011
From: Paul Hoffman <[email-masked]>
Date: Wed, 20 Apr 2011 18:49:17 -0700
To: Paul Wouters <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt

On Apr 20, 2011, at 6:13 PM, Paul Wouters wrote:

>>> I like  the use cases in Section 4, but I miss the "HASTLS" type use
>>> cases, where the DANE record can avoid a dangerous port 80 connect =
by
>>> asserting via DANE with DNSSEC that all communication to a certain =
entity
>>> is prefered or mandated to happen with TLS.
>>=20
>> That was discussed earlier, and there seemed to be agreement that =
HASTLS problem was outside of the scope of DANE, better suited to =
application-layer groups like WEBSEC.
>=20
> I don't recall that at all.

It is not in our charter. Around the end of December, I suggested that =
it should be discussed in the Apps Area. Separately, Jeff Hodges has the =
HSTS draft in the websec WG.

> Does this mean the HASTLS work has been
> moved out of the dane group? Has it been killed? Do you have a pointer
> to information on that?

Yes; no; <https://datatracker.ietf.org/wg/appsawg/>. I am going to =
incorporate comments so far there and issue a new draft.

> The risk here as mentioned before is that applications will start to
> consider the presence of a TLSA/DANE record (at _443.tcp.*) as a "port
> 443 only" flag.

There is nothing in the current TLSA draft that indicates that, is =
there?

--Paul Hoffman

From [email-masked]  Wed Apr 20 19:01:34 2011
Date: Wed, 20 Apr 2011 19:01:32 -0700
From: Eric Rescorla <[email-masked]>
To: Paul Wouters <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt

On Wed, Apr 20, 2011 at 6:23 PM, Paul Wouters <[email-masked]> wrote:
> On Wed, 20 Apr 2011, Richard L. Barnes wrote:
>
>>> I would really like to see one of the use cases replaced with the
>>> non-CA use case
>
> You did not answer this part of my question yet, only:
>
>>> - preferably the one stating it *could* be used without
>>> DNSSEC. I'd rather see that all DANE deployments insist on a mandatory
>>> DNSSEC validation.
>
> The largest use case (by number) is to not use any CA/PKIX, and to phase
> out all current warnings from browsers about self signed certs using
> dane authenticated certificates.

It's not clear to me that this is a valid inference.

Yes, it's true that there are a large number of self-signed certificates in use,
and that the operators deploying those certs could in principle use DANE, but
then said operators could in principle also get CA-issued certs. So, I
don't think
that it's at all clear that said operators will in fact constitute the
majority of
DANE deployments, given that they've already demonstrated that they don't
care much about suppressing browser warnings.

-Ekr

From [email-masked]  Wed Apr 20 19:19:56 2011
Date: Wed, 20 Apr 2011 22:19:54 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt

On Wed, 20 Apr 2011, Richard L. Barnes wrote:

> This document isn't setting those sorts of requirements.  All it's doing is saying "If the solution doesn't require DNSSEC in this case, then these are the implications."  The protocol document could make this requirement, if there's consensus for it.

Okay.

> See, e.g., the following mailing list posts:
> <http://www.ietf.org/mail-archive/web/dane/current/msg00130.html>
> <http://www.ietf.org/mail-archive/web/dane/current/msg00121.html>

Looking through these I just see HSTS, in fact I see draft-hodges-strict-transport-sec-02
which clearly states:

12.2. Bootstrap MITM Vulnerability

    The bootstrap MITM (Man-In-The-Middle) vulnerability is a
    vulnerability users and HSTS Servers encounter in the situation where
    the user manually enters, or follows a link, to a HSTS Server using a
    "http" URI rather than a "https" URI.  Because the UA uses an
    insecure channel in the initial attempt to interact with the
    specified serve, such an initial interaction is vulnerable to various
    attacks [ForceHTTPS] .

> <http://www.ietf.org/mail-archive/web/dane/current/msg00803.html>

One IESG member saying we cannot make any policy claims. And as was discussed before,
and the reason that I believe convinced Paul Hoffman to add the extra byte value,
was that in the absense of being able to tell web clients via DNS that they should
only connect securely, the presence of any indicator of a certificate in DNS will
lead people to implement that as "secure only". And thus it will lead to a non-specified
way of policy in the DNS anyways. The fact that tools like sslstrip are so readilly
available for people to use, and which clearly defeat any HSTS deployment that has
to come in over port 80 only shows the need for a full, not a partial, solution.

> <http://www.ietf.org/mail-archive/web/dane/current/msg00682.html>

That mentions SRV type records to address the problem, which I believed were
very much in the minority compared to the HASTLS solution.

> With regard to ESRV (in the last of the above), see also the discussion of DNS-based HSTS alternatives at the WEBSEC meeting at IETF 79:
> <http://tools.ietf.org/wg/websec/minutes?item=minutes79.html>

Those minutes suggest more that HSTS is a temporary stop-gap then a "let's kill alternatives"
approach.

I don't get the feeling consensus about dropping HASTLS for HSTS was
actually reached.  It seems more some procedural change motivated moving
this to another working group, where the DNS options were not really
discussed. But I'll dive in the websec working group archive to see what
actually happened.

Paul

From [email-masked]  Wed Apr 20 19:21:42 2011
Date: Wed, 20 Apr 2011 22:21:41 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt

--20cf3071cfaedbaeb504a16466dc
Content-Type: text/plain; charset=ISO-8859-1

The use case is to connect to a Web site with certain security properties
for the communication.

Questions as to whether DNSSEC is to be used or not would come under the
heading of constraints, for example:

* Use of DNSSEC requires X, Y, Z to be available
*Use of CA issued cert requires CA involved at issue

etc. etc.

On Wed, Apr 20, 2011 at 7:45 PM, Richard L. Barnes <[email-masked]> wrote:

> Hey Paul,
>
> Thanks for the quick review.  Responses inline.
>
>
> > Section 3 talks about "the two main use cases".
>
> This is a legacy of an earlier draft, which had two instead of three use
> cases (the "Cert Lock" and "CA Lock" cases were combined).  I'm just going
> to delete the "two", so it applies to however many we end up with :)
>
>
> > I would really like to see one of the use cases replaced with the
> > non-CA use case - preferably the one stating it *could* be used without
> > DNSSEC. I'd rather see that all DANE deployments insist on a mandatory
> > DNSSEC validation.
>
> I'm not sure there's consensus around that idea.  Ekr suggested the idea
> initially, and I agree that while there is security benefit to using DNSSEC
> for those cases, there is not additional risk in omitting it.
>
>
> > I like  the use cases in Section 4, but I miss the "HASTLS" type use
> > cases, where the DANE record can avoid a dangerous port 80 connect by
> > asserting via DANE with DNSSEC that all communication to a certain entity
> > is prefered or mandated to happen with TLS.
>
> That was discussed earlier, and there seemed to be agreement that HASTLS
> problem was outside of the scope of DANE, better suited to application-layer
> groups like WEBSEC.
>
>
>
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

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

--20cf3071cfaedbaeb504a16466dc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

The use case is to connect to a Web site with certain security properties f=
or the communication.<div><br></div><div>Questions as to whether DNSSEC is =
to be used or not would come under the heading of constraints, for example:=
</div>
<div><br></div><div>* Use of DNSSEC requires X, Y, Z to be available</div><=
div>*Use of CA issued cert requires CA involved at issue</div><div><br></di=
v><div>etc. etc.</div><div><br></div><div><br><br><div class=3D"gmail_quote=
">
On Wed, Apr 20, 2011 at 7:45 PM, Richard L. Barnes <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex;">
Hey Paul,<br>
<br>
Thanks for the quick review. =A0Responses inline.<br>
<div class=3D"im"><br>
<br>
&gt; Section 3 talks about &quot;the two main use cases&quot;.<br>
<br>
</div>This is a legacy of an earlier draft, which had two instead of three =
use cases (the &quot;Cert Lock&quot; and &quot;CA Lock&quot; cases were com=
bined). =A0I&#39;m just going to delete the &quot;two&quot;, so it applies =
to however many we end up with :)<br>

<div class=3D"im"><br>
<br>
&gt; I would really like to see one of the use cases replaced with the<br>
&gt; non-CA use case - preferably the one stating it *could* be used withou=
t<br>
&gt; DNSSEC. I&#39;d rather see that all DANE deployments insist on a manda=
tory<br>
&gt; DNSSEC validation.<br>
<br>
</div>I&#39;m not sure there&#39;s consensus around that idea. =A0Ekr sugge=
sted the idea initially, and I agree that while there is security benefit t=
o using DNSSEC for those cases, there is not additional risk in omitting it=
.<br>

<div class=3D"im"><br>
<br>
&gt; I like =A0the use cases in Section 4, but I miss the &quot;HASTLS&quot=
; type use<br>
&gt; cases, where the DANE record can avoid a dangerous port 80 connect by<=
br>
&gt; asserting via DANE with DNSSEC that all communication to a certain ent=
ity<br>
&gt; is prefered or mandated to happen with TLS.<br>
<br>
</div>That was discussed earlier, and there seemed to be agreement that HAS=
TLS problem was outside of the scope of DANE, better suited to application-=
layer groups like WEBSEC.<br>
<div><div></div><div class=3D"h5"><br>
<br>
<br>
_______________________________________________<br>
dane mailing list<br>
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/dane</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--20cf3071cfaedbaeb504a16466dc--

From [email-masked]  Wed Apr 20 19:34:27 2011
Date: Wed, 20 Apr 2011 22:34:25 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt

On Wed, 20 Apr 2011, Paul Hoffman wrote:

>>> That was discussed earlier, and there seemed to be agreement that HASTLS problem was outside of the scope of DANE, better suited to application-layer groups like WEBSEC.
>>
>> I don't recall that at all.
>
> It is not in our charter.

 	Specify mechanisms and techniques that allow Internet applications to
 	establish cryptographically secured communications by using information
 	distributed through DNSSEC for discovering and authenticating public
 	keys which are associated with a service located at a domain name.

I think "to establish cryptographically secured communications" does in fact
say just that. Publishing TLSA without making any TLS client behaviour change
to properly utilise that via a HASTLS like record would fall short of achieving
the goals as stated in the charter.

> Around the end of December, I suggested that it should be discussed in the Apps Area.

Did it get discussed there? Was anything from the HASTLS drafts re-used or reviewed?

> Yes; no; <https://datatracker.ietf.org/wg/appsawg/>. I am going to incorporate comments so far there and issue a new draft.

Thanks for this pointer. I see some discusion there at:
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02344.html

>> The risk here as mentioned before is that applications will start to
>> consider the presence of a TLSA/DANE record (at _443.tcp.*) as a "port
>> 443 only" flag.
>
> There is nothing in the current TLSA draft that indicates that, is there?

That's the whole point. If the IETF cannot give guidance on this issue, the
only (non-specified) alternative is to make the assumption that if someone is
advanced enough to publish a TLSA, they probably want you to startout with TLS.

Perhaps the appawg work will proceed well enough thave some kind of DNS record
for this will make it out along with TLSA.

Thanks again for the pointers,

Paul

From [email-masked]  Wed Apr 20 19:37:39 2011
Date: Wed, 20 Apr 2011 22:37:38 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Eric Rescorla <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt

On Wed, 20 Apr 2011, Eric Rescorla wrote:

>> The largest use case (by number) is to not use any CA/PKIX, and to phase
>> out all current warnings from browsers about self signed certs using
>> dane authenticated certificates.
>
> It's not clear to me that this is a valid inference.
>
> Yes, it's true that there are a large number of self-signed certificates in use,
> and that the operators deploying those certs could in principle use DANE, but
> then said operators could in principle also get CA-issued certs.

DNS entries in your own zone have cost nothing. PKIX certificates are expensive,
especially because "*" is prohibitively more expensive.

> So, I don't think
> that it's at all clear that said operators will in fact constitute the majority of
> DANE deployments, given that they've already demonstrated that they don't
> care much about suppressing browser warnings.

They demonstrated they don't want each certificate/hostname change to cost $10-$25,
correct.

Paul

From [email-masked]  Wed Apr 20 19:41:15 2011
From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 20 Apr 2011 22:41:08 -0400
To: Paul Wouters <[email-masked]>
Cc: Paul Hoffman <[email-masked]>, [email-masked]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt

> That's the whole point. If the IETF cannot give guidance on this =
issue, the
> only (non-specified) alternative is to make the assumption that if =
someone is
> advanced enough to publish a TLSA, they probably want you to startout =
with TLS.

Nobody's saying that we're not going to work on the problem, just that =
we're not going to do it here.  Sounds like Paul's working on it over in =
APPSAWG.

--Richard=

From [email-masked]  Wed Apr 20 19:41:36 2011
From: Eric Rescorla <[email-masked]>
Date: Wed, 20 Apr 2011 19:41:28 -0700
To: Paul Wouters <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt

On Apr 20, 2011, at 19:37, Paul Wouters <[email-masked]> wrote:

> On Wed, 20 Apr 2011, Eric Rescorla wrote:
>=20
>>> The largest use case (by number) is to not use any CA/PKIX, and to phase=

>>> out all current warnings from browsers about self signed certs using
>>> dane authenticated certificates.
>>=20
>> It's not clear to me that this is a valid inference.
>>=20
>> Yes, it's true that there are a large number of self-signed certificates i=
n use,
>> and that the operators deploying those certs could in principle use DANE,=
 but
>> then said operators could in principle also get CA-issued certs.
>=20
> DNS entries in your own zone have cost nothing. PKIX certificates are expe=
nsive,
> especially because "*" is prohibitively more expensive.
>=20

On the other hand pkix certs work for basically any browser whereas currentl=
y Dane-based auth works with approximately no browsers now and far will work=
 for far  less than all for quite some time.

>> So, I don't think
>> that it's at all clear that said operators will in fact constitute the ma=
jority of
>> DANE deployments, given that they've already demonstrated that they don't=

>> care much about suppressing browser warnings.
>=20
> They demonstrated they don't want each certificate/hostname change to cost=
 $10-$25,
> correct.

Right. So they must not value suppressing the warnings very much.

Ekr=

From [email-masked]  Wed Apr 20 19:44:17 2011
From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 20 Apr 2011 22:44:14 -0400
To: Paul Wouters <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt

>> Yes, it's true that there are a large number of self-signed =
certificates in use,
>> and that the operators deploying those certs could in principle use =
DANE, but
>> then said operators could in principle also get CA-issued certs.
>=20
> DNS entries in your own zone have cost nothing.=20

Counterexample: GoDaddy sells DNSSEC for 3 USD/month.  You could run =
your own zone, but then you take on the whole cost of running it.

--Richard

From [email-masked]  Wed Apr 20 19:54:37 2011
Date: Wed, 20 Apr 2011 22:54:34 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Eric Rescorla <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt

On Wed, 20 Apr 2011, Eric Rescorla wrote:

>>> Yes, it's true that there are a large number of self-signed certificates in use,
>>> and that the operators deploying those certs could in principle use DANE, but
>>> then said operators could in principle also get CA-issued certs.
>>
>> DNS entries in your own zone have cost nothing. PKIX certificates are expensive,
>> especially because "*" is prohibitively more expensive.
>
> On the other hand pkix certs work for basically any browser whereas currently Dane-based auth works with approximately no browsers now and far will work for far  less than all for quite some time.

I'm not quite following the logic of "since we didn't finish the standard
yet, no one is using it" argument.

Nothing the IETF did or does, prevents those people from getting CA
backed certs right now. Still, they did not do so. Do you have any data
on why that is so? I mean, there could be other reasons beside money. It
could be too hard to do for someone who needs to do this twice a year.
And while it is possible that dane will not change anything, dane will
definitely not make the situation worse.

>>> So, I don't think
>>> that it's at all clear that said operators will in fact constitute the majority of
>>> DANE deployments, given that they've already demonstrated that they don't
>>> care much about suppressing browser warnings.
>>
>> They demonstrated they don't want each certificate/hostname change to cost $10-$25,
>> correct.
>
> Right. So they must not value suppressing the warnings very much.

Every single warning supression per entry within a zone costs more then a
year's worth of the entire zone's registration fees.

But which use cases are mentioned does not matter that much anyway (especially since
we're not naming the elephant "We trust DNSSEC more then commercial PKIX)

Richard: I'm fine with your use cases as-is.

Paul

From [email-masked]  Wed Apr 20 21:14:52 2011
Date: Wed, 20 Apr 2011 21:14:51 -0700
From: Eric Rescorla <[email-masked]>
To: Paul Wouters <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt

On Wed, Apr 20, 2011 at 7:54 PM, Paul Wouters <[email-masked]> wrote:
> On Wed, 20 Apr 2011, Eric Rescorla wrote:
>
>>>> Yes, it's true that there are a large number of self-signed certificat=
es
>>>> in use,
>>>> and that the operators deploying those certs could in principle use
>>>> DANE, but
>>>> then said operators could in principle also get CA-issued certs.
>>>
>>> DNS entries in your own zone have cost nothing. PKIX certificates are
>>> expensive,
>>> especially because "*" is prohibitively more expensive.
>>
>> On the other hand pkix certs work for basically any browser whereas
>> currently Dane-based auth works with approximately no browsers now and f=
ar
>> will work for far =A0less than all for quite some time.
>
> I'm not quite following the logic of "since we didn't finish the standard
> yet, no one is using it" argument.

That's not my argument.

You said that the most important use case by volume is people using self-si=
gned
certs and backing them via DANE. But the value of DANE to the server operat=
or
in that case is primarily in suppressing warnings at the user's browser. Wh=
at I
said is that operators who care about suppressing that warning could get
much more effective warning suppression now and for the foreseeable future
by getting a standard CA certificate. So given that they have not
chosen to do so,
I don't think it's obvious that a large number of those operators will choo=
se to
serve DNSSEC-based DANE certificates at some point in the future.

I agree it's not that particularly important to decide what the most import=
ant
use cases are, but I merely wanted to observe that I didn't think that it w=
as
in fact obvious that this was the most important use case.

-Ekr

From [email-masked]  Wed Apr 20 21:41:24 2011
Date: Thu, 21 Apr 2011 00:41:22 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Eric Rescorla <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt

--20cf3071cfae6ad98004a1665afd
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Apr 21, 2011 at 12:14 AM, Eric Rescorla <[email-masked]> wrote:

> On Wed, Apr 20, 2011 at 7:54 PM, Paul Wouters <[email-masked]> wrote:
> > On Wed, 20 Apr 2011, Eric Rescorla wrote:
> >
> >>>> Yes, it's true that there are a large number of self-signed
> certificates
> >>>> in use,
> >>>> and that the operators deploying those certs could in principle use
> >>>> DANE, but
> >>>> then said operators could in principle also get CA-issued certs.
> >>>
> >>> DNS entries in your own zone have cost nothing. PKIX certificates are
> >>> expensive,
> >>> especially because "*" is prohibitively more expensive.
> >>
> >> On the other hand pkix certs work for basically any browser whereas
> >> currently Dane-based auth works with approximately no browsers now and
> far
> >> will work for far  less than all for quite some time.
> >
> > I'm not quite following the logic of "since we didn't finish the standard
> > yet, no one is using it" argument.
>
> That's not my argument.
>
> You said that the most important use case by volume is people using
> self-signed
> certs and backing them via DANE. But the value of DANE to the server
> operator
> in that case is primarily in suppressing warnings at the user's browser.
> What I
> said is that operators who care about suppressing that warning could get
> much more effective warning suppression now and for the foreseeable future
> by getting a standard CA certificate. So given that they have not
> chosen to do so,
> I don't think it's obvious that a large number of those operators will
> choose to
> serve DNSSEC-based DANE certificates at some point in the future.
>
> I agree it's not that particularly important to decide what the most
> important
> use cases are, but I merely wanted to observe that I didn't think that it
> was
> in fact obvious that this was the most important use case.
>
> -Ekr
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

I think this is best set out in use case form:

Use Case: Alice wants to set up Web site so that Bob can connect without
Mallet or Eve intercepting messages. Bob has a Dane capable browser

Constraint 1: Carol does not want to upgrade her browser, her user
experience MUST NOT be negatively impacted.
Constraint 2: Alice is not willing to pay for a CA issued cert (or
alternatively does not want to apply for one)

DANE does not provide a solution to this use case under these constraints by
itself.

DANE+HASTLS does provide a solution however. When Carol accesses the site
using her obsolete browser, it does not support the HASTLS mechanism and
thus does not know to try TLS and thus does not issue nuisance warnings.

This si the reason that I have been arguing that HASTLS type requirements
and Key publication requirements have to be considered together from the
very start.

Trying to propose a different way for people to do what they can do already
that is not backwards compatible is a futile waste of time.

The compelling use cases for putting keys in the DNS are to provide
additional security controls for CA issued certs (as CAA does), to enable
promiscuous security and to provide keys for Internet protocols that use TLS
but are not encumbered by a legacy base.

There is a reason that I have spent so much time ensuring that my proposal
works correctly and consistently when SRV, NAPTR or URI type discovery
mechanisms are used. It is because I believe that Web Services is the type
of niche use case that can drive a standard like Dane to reach critical
mass.

I can support the requirements of key issue restrictions, key publication
and advertising security features offered in a single framework that is just
as efficient as the current DANE proposal but does not have the limitations
imposed by the limited scope the authors keep insisting on.

Some people keep claiming that there is consensus for the current approach,
but I don't see one in the WG.

Why can't we choose the protocol architecture on the basis of the proposal
that supports the widest range of use cases with the simplest mechanism and
best objective performance metrics wins?

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

--20cf3071cfae6ad98004a1665afd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Thu, Apr 21, 2011 at 12:14 AM, Eric R=
escorla <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">[email-masked]<=
/a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">On Wed, Apr 20, 2011 at 7:54 PM, Paul Wouters &lt;<a href=
=3D"mailto:[email-masked]">[email-masked]</a>&gt; wrote:<br>
&gt; On Wed, 20 Apr 2011, Eric Rescorla wrote:<br>
&gt;<br>
&gt;&gt;&gt;&gt; Yes, it&#39;s true that there are a large number of self-s=
igned certificates<br>
&gt;&gt;&gt;&gt; in use,<br>
&gt;&gt;&gt;&gt; and that the operators deploying those certs could in prin=
ciple use<br>
&gt;&gt;&gt;&gt; DANE, but<br>
&gt;&gt;&gt;&gt; then said operators could in principle also get CA-issued =
certs.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; DNS entries in your own zone have cost nothing. PKIX certifica=
tes are<br>
&gt;&gt;&gt; expensive,<br>
&gt;&gt;&gt; especially because &quot;*&quot; is prohibitively more expensi=
ve.<br>
&gt;&gt;<br>
&gt;&gt; On the other hand pkix certs work for basically any browser wherea=
s<br>
&gt;&gt; currently Dane-based auth works with approximately no browsers now=
 and far<br>
&gt;&gt; will work for far =A0less than all for quite some time.<br>
&gt;<br>
&gt; I&#39;m not quite following the logic of &quot;since we didn&#39;t fin=
ish the standard<br>
&gt; yet, no one is using it&quot; argument.<br>
<br>
</div>That&#39;s not my argument.<br>
<br>
You said that the most important use case by volume is people using self-si=
gned<br>
certs and backing them via DANE. But the value of DANE to the server operat=
or<br>
in that case is primarily in suppressing warnings at the user&#39;s browser=
. What I<br>
said is that operators who care about suppressing that warning could get<br=
>
much more effective warning suppression now and for the foreseeable future<=
br>
by getting a standard CA certificate. So given that they have not<br>
chosen to do so,<br>
I don&#39;t think it&#39;s obvious that a large number of those operators w=
ill choose to<br>
serve DNSSEC-based DANE certificates at some point in the future.<br>
<br>
I agree it&#39;s not that particularly important to decide what the most im=
portant<br>
use cases are, but I merely wanted to observe that I didn&#39;t think that =
it was<br>
in fact obvious that this was the most important use case.<br>
<br>
-Ekr<br>
<div><div></div><div class=3D"h5">_________________________________________=
______<br>
dane mailing list<br>
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/dane</a><br>
</div></div></blockquote></div><br>I think this is best set out in use case=
 form:<div><br></div><div>Use Case: Alice wants to set up Web site so that =
Bob can connect without Mallet or Eve intercepting messages. Bob has a Dane=
 capable browser</div>
<div><br></div><div>Constraint 1: Carol does not want to upgrade her browse=
r, her user experience MUST NOT be negatively impacted.</div><div>Constrain=
t 2: Alice is not willing to pay for a CA issued cert (or alternatively doe=
s not want to apply for one)</div>
<div><br></div><div>DANE does not provide a solution to this use case under=
 these constraints by itself.</div><div><br></div><div>DANE+HASTLS does pro=
vide a solution however. When Carol accesses the site using her obsolete br=
owser, it does not support the HASTLS mechanism and thus does not know to t=
ry TLS and thus does not issue nuisance warnings.</div>
<div><br></div><div><br></div><div>This si the reason that I have been argu=
ing that HASTLS type requirements and Key publication requirements have to =
be considered together from the very start.=A0</div><div><br></div><div>Try=
ing to propose a different way for people to do what they can do already th=
at is not backwards compatible is a futile waste of time.=A0</div>
<div><br></div><div>The compelling use cases for putting keys in the DNS ar=
e to provide additional security controls for CA issued certs (as CAA does)=
, to enable promiscuous security and to provide keys for Internet protocols=
 that use TLS but are not encumbered by a legacy base.</div>
<div><br></div><div>There is a reason that I have spent so much time ensuri=
ng that my proposal works correctly and consistently when SRV, NAPTR or URI=
 type discovery mechanisms are used. It is because I believe that Web Servi=
ces is the type of niche use case that can drive a standard like Dane to re=
ach critical mass.</div>
<div><br></div><div><br></div><div>I can support the requirements of key is=
sue restrictions, key publication and advertising security features offered=
 in a single framework that is just as efficient as the current DANE propos=
al but does not have the limitations imposed by the limited scope the autho=
rs keep insisting on.</div>
<div><br></div><div>Some people keep claiming that there is consensus for t=
he current approach, but I don&#39;t see one in the WG.</div><div><br></div=
><div><br></div><div>Why can&#39;t we choose the protocol architecture on t=
he basis of the proposal that supports the widest range of use cases with t=
he simplest mechanism and best objective performance metrics wins?=A0</div>
<div><br>-- <br>Website: <a href=3D"http://hallambaker.com/">http://hallamb=
aker.com/</a><br><br>
</div>

--20cf3071cfae6ad98004a1665afd--

From [email-masked]  Thu Apr 21 13:24:26 2011
Date: Thu, 21 Apr 2011 13:24:23 -0700
From: =JeffH <[email-masked]>
To: IETF DANE WG list <[email-masked]>
Subject: [dane] of self-signed cert use case (was: I-D Action:draft-ietf-dane-use-cases-00.txt)

Eric Rescorla <[email-masked]> said:
 >
 > I agree it's not that particularly important to decide what the most
 > important use cases are,

agreed.

 > but I merely wanted to observe that I didn't think that it was in fact
 > obvious that [the self-signed cert use case is] the most important use
 > case.

agreed.

Paul Wouters <[email-masked]> had stated:
 >
 > Nothing ... prevents those [self-signed TLS-based service operators] from
 > getting CA backed certs right now. Still, they did not do so. Do [we] have
 > any data on why that is so? I mean, there could be other reasons beside
 > money.

yes, this is an interesting question. It'd be nice if anyone with data could
share it. But answering it is not critical it seems, as long as the DANE 
mechanism ends up supporting non-CA-backed certs/key-pairs.

On Wed, Apr 20, 2011 at 7:54 PM, Paul Wouters <[email-masked]> wrote:
 > On Wed, 20 Apr 2011, Eric Rescorla wrote:
 >> Paul Woulters had replied:
 >>> EKR had stated:
 >>>
 >>>> Yes, it's true that there are a large number of self-signed
 >>>> certificates in use, and that the operators deploying those certs
 >>>> could in principle use DANE, but then said operators could in
 >>>> principle also get CA-issued certs.
 >>>
 >>> DNS entries in your own zone have cost nothing. PKIX certificates are
 >>> expensive, especially because "*" is prohibitively more expensive.
 >>
 >> On the other hand pkix certs work for basically any browser whereas
 >> currently Dane-based auth works with approximately no browsers now and ..
 >> will work for far less than all for quite some time.
 >
 > I'm not quite following the logic of "since we didn't finish the standard
 > yet, no one is using it" argument.

Eric Rescorla <[email-masked]> replied:
 >
 > You said that the most important use case by volume is people using
 > self-signed certs and backing them via DANE. But the value of DANE to the
 > server operator in that case is primarily in suppressing warnings at the
 > user's browser.

I think that obtaining "exclusion" (aka "pinning" or "locking" to a particular
CA or cert (aka key pair)) would also be a first-order consideration [for 
deploying the "DANE mechanism"], yes?

 > What I said is that operators who care about suppressing that warning could
 > get much more effective warning suppression now and for the foreseeable
 > future by getting a standard CA certificate.

Well, yes, that is one thing they could do.

However, they also can have users install their trust anchor CA cert into their 
client apps (which we've been assuming are largely off-the-shelf web browsers; 
how easy it is to distrib-and-install-a-TA depends to some extent on the nature 
of the user population), or they could distribute the(ir) client apps 
pre-configured.

We, here in this discussion anyway, don't really know what [self-signed 
TLS-based service operators] are doing and why, nor whether they in actuality 
"don't care" about warnings, or whether they "do care" but there's some 
reason(s) (effort/cost/awareness/whatever), or whether they have worked around 
warnings in some fashion, or whether warnings haven't mattered (or appeared).

 > ... I don't think it's obvious that a large number of [self-signed TLS-based
 > service operators] will choose to serve DNSSEC-based DANE certificates at
 > some point in the future.

Agreed modulo the notion of "large". It could well be that some chunk of 
[self-signed TLS-based service operators] will choose to employ the DANE 
mechanism. We just don't have a good understanding of the magnitude of the 
"chunk" and how it will evolve over time.

HTH,

=JeffH

From [email-masked]  Thu Apr 21 13:31:00 2011
Date: Thu, 21 Apr 2011 13:30:59 -0700
From: Eric Rescorla <[email-masked]>
To: "=JeffH" <[email-masked]>
Cc: IETF DANE WG list <[email-masked]>
Subject: Re: [dane] of self-signed cert use case (was: I-D Action:draft-ietf-dane-use-cases-00.txt)

On Thu, Apr 21, 2011 at 1:24 PM, =JeffH <[email-masked]> wrote:
> Eric Rescorla <[email-masked]> replied:
>>
>> You said that the most important use case by volume is people using
>> self-signed certs and backing them via DANE. But the value of DANE to the
>> server operator in that case is primarily in suppressing warnings at the
>> user's browser.
>
> I think that obtaining "exclusion" (aka "pinning" or "locking" to a
> particular
> CA or cert (aka key pair)) would also be a first-order consideration [for
> deploying the "DANE mechanism"], yes?

Yes. I tend towards the view that this is the primary value of DANE.
However, it seems
likely that those people already have CA-issued certs.

-Ekr

From [email-masked]  Thu Apr 21 13:48:07 2011
From: Martin Rex <[email-masked]>
To: [email-masked] (Eric Rescorla)
Date: Thu, 21 Apr 2011 22:48:03 +0200 (MEST)
Cc: [email-masked]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
Reply-To: [email-masked]

Eric Rescorla wrote:
> 
> On Wed, Apr 20, 2011 at 6:23 PM, Paul Wouters <[email-masked]> wrote:
> >
> > The largest use case (by number) is to not use any CA/PKIX, and to phase
> > out all current warnings from browsers about self signed certs using
> > dane authenticated certificates.

My impression was that about half of the not-obviously-invalid certs
on the internet are self-signed, the other half is issued under any
of the commercial CAs shipping in browsers.  I don't know how exactly
the number are for "hosts", because the queries that Peter Eckersley
from the EFF did so far where about unique server certs only.

> 
> Yes, it's true that there are a large number of self-signed certificates
> in use, and that the operators deploying those certs could in principle
> use DANE, but then said operators could in principle also get CA-issued
> certs. So, I don't think that it's at all clear that said operators will
> in fact constitute the majority of DANE deployments, given that they've
> already demonstrated that they don't care much about suppressing
> browser warnings.

Certs issued from commercial CAs are a royal PITA.  You have to pay a
yearly recurring fee, they're lifetime limited to one year, and so
if you have a couple of them, you get huge additional overhead.

Being able to create a self-signed cert once with a long lifetime
and use it until you dump or replace the equipment is *MUCH* preferable.

Here in the office, we have an open guest WLAN (internet access) with a
"captive portal".  The captive portal uses TLS with a commercial CA cert,
but there seem to several different boxes that use the exactly same
cert, on the one covering the WLAN for my office used an expired cert
a few weeks ago.  MSIE 7 did show a warning, offering to continue -- but
failed to connect anyway (apparently there was some hard-fail added
somewhere in XPsp3 SChannel).  So I had to resort using an older
firefox browser to be able to authenticate (and not have to wait
until my trouble ticket was processed and that particular network
component updated with a new cert).

-Martin

From [email-masked]  Thu Apr 21 14:19:44 2011
Date: Thu, 21 Apr 2011 14:19:42 -0700
From: =JeffH <[email-masked]>
To: IETF DANE WG list <[email-masked]>
Subject: [dane] wrt HSTS, HASTLS, and DANE  (was: I-D Action:draft-ietf-dane-use-cases-00.txt)

On Wed, 20 Apr 2011 22:19:54 -0400 (EDT) Paul Wouters <[email-masked]> said:
 >
 >> See, e.g., the following mailing list posts:
 >> <http://www.ietf.org/mail-archive/web/dane/current/msg00130.html>
 >> <http://www.ietf.org/mail-archive/web/dane/current/msg00121.html>
 >
 > Looking through these I just see HSTS, in fact I see draft-hodges-strict-
 > transport-sec-02 ...

Just to update folks' pointers, draft-hodges-strict-transport-sec is superseded 
by..

   http://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec

 > The fact that tools like sslstrip are so readilly available for people to
 > use, and which clearly defeat any HSTS deployment that has to come in over
 > port 80 only shows the need for a full, not a partial, solution

While I understand your concern here wrt HSTS and the (legit) "Bootstrap MITM 
Vulnerability", it is a more nuanced problem than the way you've been 
portraying it, and I'm compelled to note some of the nuances here in response..

HSTS-enabled clients are only vulnerable to the Bootstrap MITM vuln if the 
website is not already noted in the client's HSTS-store. I.e. the very first 
time they connect, via http/tcp (rather than http/tls), to an uncached 
HSTS-host. Once they have successfully legitimately connected to a HSTS-host, 
they are protected for the max-age of the HSTS policy. Note that clients (ie 
browsers) can (and Chrome does) have a "factory-loaded" HSTS-store (and are 
encouraged to implement such :) -- thus HSTS-hosts listed in the 
"factory-loaded" HSTS-store are never connected to insecurely.

That said, you note..

 > Those minutes suggest more that HSTS is a temporary stop-gap then a "let's
 > kill alternatives" approach.

..and the short answer here is "yes", though I've been calling it an 
"intermediate term" solution rather than a "temporary stop-gap".

On another aspect of this overall HSTS, HASTLS, and DANE multi-faceted topic, 
you said..
 > Paul Hoffman had replied:
 >> You stated:
 >>> The risk here as mentioned before is that applications will start to
 >>> consider the presence of a TLSA/DANE record (at _443.tcp.*) as a "port
 >>> 443 only" flag.
 >>
 >> There is nothing in the current TLSA draft that indicates that, is there?
 >
 > That's the whole point. If the IETF cannot give guidance on this issue, the
 > only (non-specified) alternative is to make the assumption that if someone
 > is advanced enough to publish a TLSA, they probably want you to startout
 > with TLS.

Although I understand your concern and believe it is nominally legit, in the 
broad consumer case it is mostly a matter of ensuring that the (small number 
of) major browser vendors don't do that, which is manageable IMV.

 > Perhaps the appawg work will proceed well enough thave some kind of DNS
 > record for this will make it out along with TLSA.

agreed.

HTH,

=JeffH

From [email-masked]  Thu Apr 21 14:24:17 2011
Date: Thu, 21 Apr 2011 14:24:15 -0700
From: =JeffH <[email-masked]>
To: IETF DANE WG list <[email-masked]>
Subject: Re: [dane] of self-signed cert use case (was: I-D Action:draft-ietf-dane-use-cases-00.txt)

EKR replied:
 > On Thu, Apr 21, 2011 at 1:24 PM, =JeffH <[email-masked]> wrote:
 >> Eric Rescorla <[email-masked]> replied:
 >>>
 >>> You said that the most important use case by volume is people using
 >>> self-signed certs and backing them via DANE. But the value of DANE to the
 >>> server operator in that case is primarily in suppressing warnings at the
 >>> user's browser.
 >>
 >> I think that obtaining "exclusion" (aka "pinning" or "locking" to a
 >> particular CA or cert (aka key pair)) would also be a first-order
 >> consideration [for deploying the "DANE mechanism"], yes?
 >
 > Yes. I tend towards the view that this is the primary value of DANE.

me too.

 > However, it seems likely that those people already have CA-issued certs.

s/ that those people / that many of those people/

=JeffH

From [email-masked]  Thu Apr 21 14:26:27 2011
Date: Thu, 21 Apr 2011 14:26:26 -0700
From: Eric Rescorla <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt

On Thu, Apr 21, 2011 at 1:48 PM, Martin Rex <[email-masked]> wrote:
> Eric Rescorla wrote:
>> Yes, it's true that there are a large number of self-signed certificates
>> in use, and that the operators deploying those certs could in principle
>> use DANE, but then said operators could in principle also get CA-issued
>> certs. So, I don't think that it's at all clear that said operators will
>> in fact constitute the majority of DANE deployments, given that they've
>> already demonstrated that they don't care much about suppressing
>> browser warnings.
>
> Certs issued from commercial CAs are a royal PITA.

Sure.

>=A0You have to pay a
> yearly recurring fee,

Or you pay upfront, which, many CAs are happy to allow.

> they're lifetime limited to one year,

Not true. For instance:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            1f:19:f6:de:35:dd:63:a1:42:91:8a:d5:2c:c0:ab:12
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=3DZA, O=3DThawte Consulting (Pty) Ltd., CN=3DThawte SGC C=
A
        Validity
            Not Before: Dec 18 00:00:00 2009 GMT
            Not After : Dec 18 23:59:59 2011 GMT
        Subject: C=3DUS, ST=3DCalifornia, L=3DMountain View, O=3DGoogle Inc=
,
CN=3Dmail.google.com

or:
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            25:f5:d1:2d:5e:6f:0b:d4:ea:f2:a2:c9:66:f3:b4:ce
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=3DUS, O=3DVeriSign, Inc., OU=3DVeriSign Trust Network,
OU=3DTerms of use at https://www.verisign.com/rpa (c)09, CN=3DVeriSign
Class 3 Secure Server CA - G2
        Validity
            Not Before: Jul 15 00:00:00 2010 GMT
            Not After : Jul 14 23:59:59 2013 GMT
        Subject: C=3DUS, ST=3DWashington, L=3DSeattle, O=3DAmazon.com Inc.,
CN=3Dwww.amazon.com

> and so
> if you have a couple of them, you get huge additional overhead.

Well, it's not like having to run DNSSEC is somehow overhead free. I think =
it's
an open question whether DANE will in fact be more convenient.

-Ekr

From [email-masked]  Thu Apr 21 16:01:15 2011
From: Martin Rex <[email-masked]>
To: [email-masked] (Eric Rescorla)
Date: Fri, 22 Apr 2011 01:01:12 +0200 (MEST)
Cc: [email-masked]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
Reply-To: [email-masked]

Eric Rescorla wrote:
> 
> > 
> > Certs issued from commercial CAs are a royal PITA.
> 
> Sure.
> 
> 
> > You have to pay a yearly recurring fee,
> 
> Or you pay upfront, which, many CAs are happy to allow.
> 
> 
> > they're lifetime limited to one year,
> 
> Not true.

You mean like this here:

http://www.sslshopper.com/cheapest-ssl-certificates.html

Yes you buy certs that are valid for several years, but
you have to pay several times as much, have to pay upfront,
and it doesn't look like that you get a 4 year refund if
you want to or have to move to a different hostname or
different domain after 1 year.

> 
> > and so if you have a couple of them, you get huge additional overhead.
> 
> Well, it's not like having to run DNSSEC is somehow overhead free.
> I think it's an open question whether DANE will in fact be more
> convenient.

When using DNSSEC, you only incur costs for setting it up once,
but then it can untouched for years until you want to or have to
change it (or want to rekey after a break-in) and you don't loose
money (fees and administrative overhead) like you do with commercial CAs.

The difference of maintaining one vs. two DNS records is negligible.
and you will have to maintain just as much with records with a cert
from commercial CA (just a different dane record type).

-Martin

From [email-masked]  Thu Apr 21 16:23:17 2011
Date: Thu, 21 Apr 2011 16:23:16 -0700
From: Eric Rescorla <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt

On Thu, Apr 21, 2011 at 4:01 PM, Martin Rex <[email-masked]> wrote:
> Eric Rescorla wrote:
>>
>> >
>> > Certs issued from commercial CAs are a royal PITA.
>>
>> Sure.
>>
>>
>> >=A0You have to pay a yearly recurring fee,
>>
>> Or you pay upfront, which, many CAs are happy to allow.
>>
>>
>> > they're lifetime limited to one year,
>>
>> Not true.
>
> You mean like this here:
>
> http://www.sslshopper.com/cheapest-ssl-certificates.html
>
>
> Yes you buy certs that are valid for several years, but
> you have to pay several times as much, have to pay upfront,

I don't recall claiming otherwise. What I claimed was that, your assertion =
to
the contrary, you could in fact get certificates that were valid for >1 yea=
r.
As the certificates I posted [and you deleted] clearly demonstrate, I am co=
rrect
on this point.

-Ekr

From [email-masked]  Thu Apr 21 17:21:58 2011
From: "Jim Schaad" <[email-masked]>
To: "'Paul Wouters'" <[email-masked]>, "'Eric Rescorla'" <[email-masked]>
Date: Thu, 21 Apr 2011 17:47:49 -0700
Cc: [email-masked]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Paul Wouters
> Sent: Wednesday, April 20, 2011 7:38 PM
> To: Eric Rescorla
> Cc: [email-masked]
> Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
> 
> On Wed, 20 Apr 2011, Eric Rescorla wrote:
> 
> >> The largest use case (by number) is to not use any CA/PKIX, and to
> >> phase out all current warnings from browsers about self signed certs
> >> using dane authenticated certificates.
> >
> > It's not clear to me that this is a valid inference.
> >
> > Yes, it's true that there are a large number of self-signed
> > certificates in use, and that the operators deploying those certs
> > could in principle use DANE, but then said operators could in principle
also
> get CA-issued certs.
> 
> DNS entries in your own zone have cost nothing. PKIX certificates are
> expensive, especially because "*" is prohibitively more expensive.

This is not what I have found.  Since my DNS entries are maintained by a 3rd
party company they charge me for every DNS entry change that I want to make.

> 
> > So, I don't think
> > that it's at all clear that said operators will in fact constitute the
> > majority of DANE deployments, given that they've already demonstrated
> > that they don't care much about suppressing browser warnings.
> 
> They demonstrated they don't want each certificate/hostname change to
> cost $10-$25, correct.
> 
> Paul
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

From [email-masked]  Thu Apr 21 18:43:47 2011
Date: Thu, 21 Apr 2011 21:43:46 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Jim Schaad <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt

--20cf3071cfae1925d704a177fd80
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Apr 21, 2011 at 8:47 PM, Jim Schaad <[email-masked]> wrote:

>
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf Of
> > Paul Wouters
> > Sent: Wednesday, April 20, 2011 7:38 PM
> > To: Eric Rescorla
> > Cc: [email-masked]
> > Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt
> >
> > On Wed, 20 Apr 2011, Eric Rescorla wrote:
> >
> > >> The largest use case (by number) is to not use any CA/PKIX, and to
> > >> phase out all current warnings from browsers about self signed certs
> > >> using dane authenticated certificates.
> > >
> > > It's not clear to me that this is a valid inference.
> > >
> > > Yes, it's true that there are a large number of self-signed
> > > certificates in use, and that the operators deploying those certs
> > > could in principle use DANE, but then said operators could in principle
> also
> > get CA-issued certs.
> >
> > DNS entries in your own zone have cost nothing. PKIX certificates are
> > expensive, especially because "*" is prohibitively more expensive.
>
> This is not what I have found.  Since my DNS entries are maintained by a
> 3rd
> party company they charge me for every DNS entry change that I want to
> make.

Such considerations are in any case a poor basis for making protocol design
decisions. Prices change in response to market conditions.

Back in the day two companies decided that the cost of using a US telephone
in London was so exorbitant that they would make a fortune out of a network
of geodesic satellites allowing someone to make a call from anywhere using
the same phone. By the time the service launched the mobile carriers had
dropped their prices and a phone now worked in 95% of the places people
wanted to use one and few saw the value in paying $5/min for the rest.

DNSSEC is going to cost registrars money to deploy so people should not
expect it to be cost free.

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

--20cf3071cfae1925d704a177fd80
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Thu, Apr 21, 2011 at 8:47 PM, Jim Sch=
aad <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">ietf@au=
gustcellars.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
<br>
&gt; -----Original Message-----<br>
&gt; From: <a href=3D"mailto:[email-masked]">[email-masked]</=
a> [mailto:<a href=3D"mailto:[email-masked]">[email-masked]</=
a>] On Behalf Of<br>
&gt; Paul Wouters<br>
&gt; Sent: Wednesday, April 20, 2011 7:38 PM<br>
&gt; To: Eric Rescorla<br>
&gt; Cc: <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
&gt; Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt<br>
<div class=3D"im">&gt;<br>
&gt; On Wed, 20 Apr 2011, Eric Rescorla wrote:<br>
&gt;<br>
&gt; &gt;&gt; The largest use case (by number) is to not use any CA/PKIX, a=
nd to<br>
&gt; &gt;&gt; phase out all current warnings from browsers about self signe=
d certs<br>
&gt; &gt;&gt; using dane authenticated certificates.<br>
&gt; &gt;<br>
&gt; &gt; It&#39;s not clear to me that this is a valid inference.<br>
&gt; &gt;<br>
&gt; &gt; Yes, it&#39;s true that there are a large number of self-signed<b=
r>
&gt; &gt; certificates in use, and that the operators deploying those certs=
<br>
&gt; &gt; could in principle use DANE, but then said operators could in pri=
nciple<br>
also<br>
&gt; get CA-issued certs.<br>
&gt;<br>
&gt; DNS entries in your own zone have cost nothing. PKIX certificates are<=
br>
&gt; expensive, especially because &quot;*&quot; is prohibitively more expe=
nsive.<br>
<br>
</div>This is not what I have found. =A0Since my DNS entries are maintained=
 by a 3rd<br>
party company they charge me for every DNS entry change that I want to make=
.</blockquote><div><br></div><div>Such considerations are in any case a poo=
r basis for making protocol design decisions. Prices change in response to =
market conditions.</div>
<div><br></div><div>Back in the day two companies decided that the cost of =
using a US telephone in London was so exorbitant that they would make a for=
tune out of a network of geodesic satellites allowing someone to make a cal=
l from anywhere using the same phone. By the time the service launched the =
mobile carriers had dropped their prices and a phone now worked in 95% of t=
he places people wanted to use one and few saw the value in paying $5/min f=
or the rest.</div>
<div><br></div><div>DNSSEC is going to cost registrars money to deploy so p=
eople should not expect it to be cost free.</div><div><br></div></div><br>-=
- <br>Website: <a href=3D"http://hallambaker.com/">http://hallambaker.com/<=
/a><br>
<br>

--20cf3071cfae1925d704a177fd80--

From [email-masked]  Thu Apr 21 19:49:24 2011
From: Peter Gutmann <[email-masked]>
To: [email-masked]
Date: Fri, 22 Apr 2011 14:49:19 +1200
Cc: [email-masked]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt

Martin Rex <[email-masked]> writes:

>So I had to resort using an older firefox browser to be able to authenticate
>(and not have to wait until my trouble ticket was processed and that
>particular network component updated with a new cert).

Are there any browser extensions that deal with this braindamage?  Since it's
a capative portal (and presumably a non-publicly-visible device) Perspectives
can't help, and Certificate Patrol will warn of expired certs/changes but not
allow you to override false-positive ones.  Is there anything else?

(Anecdote about broken certificate handling in browsers: There's a web forum
that I participate in that has a slight mismatch between the cert issued and
the domain name.  Every single time I go there Firefox does the usual scary-
warning-dance, and a few seconds later Perspectives leaps in and swats aside
the false alarm saying "This is nonsense, the cert has been in use for this
site forever, continuing anyway".  So every single day I get reminded that
this is just broken security theatre that hampers rather than helps.

OK, so I could permanently trust the cert, but I get a modest degree of
satisfaction out of seeing the "This nonsensical error removed by
Perspectives" message that pops up :-).

Peter.

From [email-masked]  Fri Apr 22 04:23:00 2011
From: Jakob Schlyter <[email-masked]>
Date: Fri, 22 Apr 2011 13:22:59 +0200
To: Phillip Hallam-Baker <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt

22 apr 2011 kl. 03:43 skrev Phillip Hallam-Baker <[email-masked]>:

> DNSSEC is going to cost registrars money to deploy so people should not ex=
pect it to be cost free.

I believe many registrars offering DNS services will choose to just add DNSS=
EC for free in order to keep it's customers. Just implementing a low assuran=
ce DNSSEC service for all its domains is less expensive and easier to operat=
e, than adding opt-in/out and the additional charging. Implementing high ass=
urance (e.g. using HSM) DNSSEC will most likely cost more.=20

  Jakob

From [email-masked]  Fri Apr 22 05:22:10 2011
Date: Fri, 22 Apr 2011 08:22:08 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Jakob Schlyter <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt

--20cf3071cfae186bf904a180e841
Content-Type: text/plain; charset=ISO-8859-1

I remember back in 2001 when certain people argued that registrars would
deploy DNSSEC to compete irrespective of whether the spec was changed to
make deployment economically feasible. that didn't work out so well.

Email costs next to nothing to provide, so does Web hosting, so do most of
the services ISPs provide. And not coincidentally, the cost of hosting
services are next to nothing.

But they are not zero.

There sare good reasons for working on DANE, but saving money on existing
security measures is not one of them. Promiscuous security, Pinning,
Security Policy, Web Services are all important and useful use cases.

On Fri, Apr 22, 2011 at 7:22 AM, Jakob Schlyter <[email-masked]> wrote:

> 22 apr 2011 kl. 03:43 skrev Phillip Hallam-Baker <[email-masked]>:
>
> > DNSSEC is going to cost registrars money to deploy so people should not
> expect it to be cost free.
>
> I believe many registrars offering DNS services will choose to just add
> DNSSEC for free in order to keep it's customers. Just implementing a low
> assurance DNSSEC service for all its domains is less expensive and easier to
> operate, than adding opt-in/out and the additional charging. Implementing
> high assurance (e.g. using HSM) DNSSEC will most likely cost more.
>
>  Jakob
>
>

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

--20cf3071cfae186bf904a180e841
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I remember back in 2001 when certain people argued that registrars would de=
ploy DNSSEC to compete irrespective of whether the spec was changed to make=
 deployment economically feasible. that didn&#39;t work out so well.<div>
<br></div><div>Email costs next to nothing to provide, so does Web hosting,=
 so do most of the services ISPs provide. And not coincidentally, the cost =
of hosting services are next to nothing.</div><div><br></div><div>But they =
are not zero.</div>
<div><br></div><div><br></div><div>There sare good reasons for working on D=
ANE, but saving money on existing security measures is not one of them. Pro=
miscuous security, Pinning, Security Policy, Web Services are all important=
 and useful use cases.</div>
<div><br></div><div><br><div class=3D"gmail_quote">On Fri, Apr 22, 2011 at =
7:22 AM, Jakob Schlyter <span dir=3D"ltr">&lt;<a href=3D"mailto:jakob@kirei=
.se">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;=
">
22 apr 2011 kl. 03:43 skrev Phillip Hallam-Baker &lt;<a href=3D"mailto:hall=
[email-masked]">[email-masked]</a>&gt;:<br>
<div class=3D"im"><br>
&gt; DNSSEC is going to cost registrars money to deploy so people should no=
t expect it to be cost free.<br>
<br>
</div>I believe many registrars offering DNS services will choose to just a=
dd DNSSEC for free in order to keep it&#39;s customers. Just implementing a=
 low assurance DNSSEC service for all its domains is less expensive and eas=
ier to operate, than adding opt-in/out and the additional charging. Impleme=
nting high assurance (e.g. using HSM) DNSSEC will most likely cost more.<br=
>

<font color=3D"#888888"><br>
 =A0Jakob<br>
<br>
</font></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a href=
=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--20cf3071cfae186bf904a180e841--

From [email-masked]  Fri Apr 22 05:32:03 2011
From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 22 Apr 2011 08:32:00 -0400
To: [email-masked]
Subject: [dane] Fwd: New Version Notification for draft-ietf-dane-use-cases-01

This is an updated version of the use cases draft, which incorporates =
feedback on -00 and makes several editorial changes.  Diff is here:
<http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-dane-use-cases-01.txt>

Chairs: I believe this version is ready for WGLC.

--Richard

Begin forwarded message:

> From: IETF I-D Submission Tool <[email-masked]>
> Date: April 22, 2011 8:30:04 AM EDT
> To: [email-masked]
> Subject: New Version Notification for draft-ietf-dane-use-cases-01=20
>=20
>=20
> A new version of I-D, draft-ietf-dane-use-cases-01.txt has been =
successfully submitted by Richard Barnes and posted to the IETF =
repository.
>=20
> Filename:	 draft-ietf-dane-use-cases
> Revision:	 01
> Title:		 Use Cases and Requirements for DNS-based =
Authentication of Named Entities (DANE)
> Creation_date:	 2011-04-22
> WG ID:		 dane
> Number_of_pages: 9
>=20
> Abstract:
> Many current applications use the certificate-based authentication
> features in TLS to allow clients to verify that a connected server
> properly represents a desired domain name.  Traditionally, this
> authentication has been based on PKIX trust hierarchies, rooted in
> well-known CAs, but additional information can be provided via the
> DNS itself.  This document describes a set of use cases in which the
> DNS and DNSSEC could be used to make assertions that support the TLS
> authentication process.
>=20
>=20
>=20
> The IETF Secretariat.
>=20
>=20

From [email-masked]  Fri Apr 22 05:45:03 2011
From: [email-masked]
To: [email-masked]
Date: Fri, 22 Apr 2011 05:45:03 -0700
Cc: [email-masked]
Subject: [dane] I-D Action:draft-ietf-dane-use-cases-01.txt

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF.

	Title           : Use Cases and Requirements for DNS-based Authentication of Named Entities (DANE)
	Author(s)       : R. Barnes
	Filename        : draft-ietf-dane-use-cases-01.txt
	Pages           : 9
	Date            : 2011-04-22

Many current applications use the certificate-based authentication
features in TLS to allow clients to verify that a connected server
properly represents a desired domain name.  Traditionally, this
authentication has been based on PKIX trust hierarchies, rooted in
well-known CAs, but additional information can be provided via the
DNS itself.  This document describes a set of use cases in which the
DNS and DNSSEC could be used to make assertions that support the TLS
authentication process.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dane-use-cases-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body; name="draft-ietf-dane-use-cases-01.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart--

From [email-masked]  Fri Apr 22 05:49:15 2011
Date: Fri, 22 Apr 2011 08:49:13 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] Fwd: New Version Notification for draft-ietf-dane-use-cases-01

--20cf304346f4f6f09b04a181483f
Content-Type: text/plain; charset=ISO-8859-1

I do not think it is ready.

There is a section titled 'other requirements', but the preceding sections
are titled 'use cases'. A use case is not a requirement. A use case is what
the set of requirements is deduced from

I think that Promiscuous Security and Web Services support should be added
to the use cases. TLS is used for much more than just Web Browsing and the
non-Web browsing use cases are rather more important in my view.

The section 'other requirements' appears to be mostly specifying
constraints, though they are stated as requirements.

One very important constraint is the need to support mechanisms for protocol
discovery that do not rely on port numbers.

Since we are running out of port numbers, this is an essential requirement.

The necessary text can be found in:
http://tools.ietf.org/html/draft-hallambaker-dane-requirements-01

As a matter of style, the ESA format that has the requirements tagged with a
reference number (e.g. [U-S-TRUST]) makes it easier to refer to the
requirements when determining if a proposal meets them.

On Fri, Apr 22, 2011 at 8:32 AM, Richard L. Barnes <[email-masked]> wrote:

> This is an updated version of the use cases draft, which incorporates
> feedback on -00 and makes several editorial changes.  Diff is here:
> <http://tools.ietf.org/rfcdiff?url2=draft-ietf-dane-use-cases-01.txt>
>
> Chairs: I believe this version is ready for WGLC.
>
> --Richard
>
>
>
>
> Begin forwarded message:
>
> > From: IETF I-D Submission Tool <[email-masked]>
> > Date: April 22, 2011 8:30:04 AM EDT
> > To: [email-masked]
> > Subject: New Version Notification for draft-ietf-dane-use-cases-01
> >
> >
> > A new version of I-D, draft-ietf-dane-use-cases-01.txt has been
> successfully submitted by Richard Barnes and posted to the IETF repository.
> >
> > Filename:      draft-ietf-dane-use-cases
> > Revision:      01
> > Title:                 Use Cases and Requirements for DNS-based
> Authentication of Named Entities (DANE)
> > Creation_date:         2011-04-22
> > WG ID:                 dane
> > Number_of_pages: 9
> >
> > Abstract:
> > Many current applications use the certificate-based authentication
> > features in TLS to allow clients to verify that a connected server
> > properly represents a desired domain name.  Traditionally, this
> > authentication has been based on PKIX trust hierarchies, rooted in
> > well-known CAs, but additional information can be provided via the
> > DNS itself.  This document describes a set of use cases in which the
> > DNS and DNSSEC could be used to make assertions that support the TLS
> > authentication process.
> >
> >
> >
> > The IETF Secretariat.
> >
> >
>
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

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

--20cf304346f4f6f09b04a181483f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I do not think it is ready.<div><br></div><div>There is a section titled &#=
39;other requirements&#39;, but the preceding sections are titled &#39;use =
cases&#39;. A use case is not a requirement. A use case is what the set of =
requirements is deduced from</div>
<div><br></div><div>I think that Promiscuous Security and Web Services supp=
ort should be added to the use cases. TLS is used for much more than just W=
eb Browsing and the non-Web browsing use cases are rather more important in=
 my view.</div>
<div><br></div><div><br></div><div>The section &#39;other requirements&#39;=
 appears to be mostly specifying constraints, though they are stated as req=
uirements.=A0</div><div><br></div><div>One very important constraint is the=
 need to support mechanisms for protocol discovery that do not rely on port=
 numbers.</div>
<div><br>Since we are running out of port numbers, this is an essential req=
uirement.</div><div><br></div><div><meta charset=3D"utf-8"><div>The necessa=
ry text can be found in:</div><div><a href=3D"http://tools.ietf.org/html/dr=
aft-hallambaker-dane-requirements-01">http://tools.ietf.org/html/draft-hall=
ambaker-dane-requirements-01</a></div>
</div><div><br></div><div><br></div><div>As a matter of style, the ESA form=
at that has the requirements tagged with a reference number (e.g.=A0<span c=
lass=3D"Apple-style-span" style=3D"font-family: monospace; font-size: 16px;=
 white-space: pre; ">[<a name=3D"ref-U-S-TRUST" id=3D"ref-U-S-TRUST">U-S-TR=
UST</a>]</span>) makes it easier to refer to the requirements when determin=
ing if a proposal meets them.</div>
<div><br></div><div><br></div><div><br><div class=3D"gmail_quote">On Fri, A=
pr 22, 2011 at 8:32 AM, Richard L. Barnes <span dir=3D"ltr">&lt;<a href=3D"=
mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex;">
This is an updated version of the use cases draft, which incorporates feedb=
ack on -00 and makes several editorial changes. =A0Diff is here:<br>
&lt;<a href=3D"http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-dane-use-cas=
es-01.txt" target=3D"_blank">http://tools.ietf.org/rfcdiff?url2=3Ddraft-iet=
f-dane-use-cases-01.txt</a>&gt;<br>
<br>
Chairs: I believe this version is ready for WGLC.<br>
<br>
--Richard<br>
<br>
<br>
<br>
<br>
Begin forwarded message:<br>
<br>
&gt; From: IETF I-D Submission Tool &lt;<a href=3D"mailto:idsubmission@ietf=
.org">[email-masked]</a>&gt;<br>
&gt; Date: April 22, 2011 8:30:04 AM EDT<br>
&gt; To: <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
&gt; Subject: New Version Notification for draft-ietf-dane-use-cases-01<br>
&gt;<br>
&gt;<br>
&gt; A new version of I-D, draft-ietf-dane-use-cases-01.txt has been succes=
sfully submitted by Richard Barnes and posted to the IETF repository.<br>
&gt;<br>
&gt; Filename: =A0 =A0 =A0draft-ietf-dane-use-cases<br>
&gt; Revision: =A0 =A0 =A001<br>
&gt; Title: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Use Cases and Requirements for =
DNS-based Authentication of Named Entities (DANE)<br>
&gt; Creation_date: =A0 =A0 =A0 =A0 2011-04-22<br>
&gt; WG ID: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 dane<br>
&gt; Number_of_pages: 9<br>
&gt;<br>
&gt; Abstract:<br>
&gt; Many current applications use the certificate-based authentication<br>
&gt; features in TLS to allow clients to verify that a connected server<br>
&gt; properly represents a desired domain name. =A0Traditionally, this<br>
&gt; authentication has been based on PKIX trust hierarchies, rooted in<br>
&gt; well-known CAs, but additional information can be provided via the<br>
&gt; DNS itself. =A0This document describes a set of use cases in which the=
<br>
&gt; DNS and DNSSEC could be used to make assertions that support the TLS<b=
r>
&gt; authentication process.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; The IETF Secretariat.<br>
&gt;<br>
&gt;<br>
<br>
_______________________________________________<br>
dane mailing list<br>
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/dane</a><br>
</blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a href=3D"htt=
p://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--20cf304346f4f6f09b04a181483f--

From [email-masked]  Fri Apr 22 06:01:57 2011
From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 22 Apr 2011 09:01:55 -0400
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] Fwd: New Version Notification for draft-ietf-dane-use-cases-01

> I think that Promiscuous Security and Web Services support should be =
added to the use cases. TLS is used for much more than just Web Browsing =
and the non-Web browsing use cases are rather more important in my view.

The use cases as described are in no way specific to web browsing.  They =
apply generally to applications using TLS that require authentication of =
domain names.  In any case, I do not see use cases titled "Promiscuous =
Security" or "Web Services" in draft-hallambaker-dane-requirements, so =
please propose text.

> One very important constraint is the need to support mechanisms for =
protocol discovery that do not rely on port numbers.

Protocol discovery is not in scope, not least because it varies from one =
application to another.  The use cases described apply equally well to =
dual-port (dedicated TLS port) and STARTTLS design patterns.  Indeed, =
examples of both are referenced in the introduction.

Key/cert discovery is in scope, but that does not have anything to do =
with port exhaustion.  The question there is whether a client can =
disambiguate services on different ports.

> As a matter of style, the ESA format that has the requirements tagged =
with a reference number (e.g. [U-S-TRUST]) makes it easier to refer to =
the requirements when determining if a proposal meets them.

I think we have few enough requirements here that there's not a need for =
a formalism.

--Richard

>=20
>=20
> On Fri, Apr 22, 2011 at 8:32 AM, Richard L. Barnes <[email-masked]> =
wrote:
> This is an updated version of the use cases draft, which incorporates =
feedback on -00 and makes several editorial changes.  Diff is here:
> <http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-dane-use-cases-01.txt>
>=20
> Chairs: I believe this version is ready for WGLC.
>=20
> --Richard
>=20
>=20
>=20
>=20
> Begin forwarded message:
>=20
> > From: IETF I-D Submission Tool <[email-masked]>
> > Date: April 22, 2011 8:30:04 AM EDT
> > To: [email-masked]
> > Subject: New Version Notification for draft-ietf-dane-use-cases-01
> >
> >
> > A new version of I-D, draft-ietf-dane-use-cases-01.txt has been =
successfully submitted by Richard Barnes and posted to the IETF =
repository.
> >
> > Filename:      draft-ietf-dane-use-cases
> > Revision:      01
> > Title:                 Use Cases and Requirements for DNS-based =
Authentication of Named Entities (DANE)
> > Creation_date:         2011-04-22
> > WG ID:                 dane
> > Number_of_pages: 9
> >
> > Abstract:
> > Many current applications use the certificate-based authentication
> > features in TLS to allow clients to verify that a connected server
> > properly represents a desired domain name.  Traditionally, this
> > authentication has been based on PKIX trust hierarchies, rooted in
> > well-known CAs, but additional information can be provided via the
> > DNS itself.  This document describes a set of use cases in which the
> > DNS and DNSSEC could be used to make assertions that support the TLS
> > authentication process.
> >
> >
> >
> > The IETF Secretariat.
> >
> >
>=20
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>=20
>=20
>=20
> --=20
> Website: http://hallambaker.com/
>=20

From [email-masked]  Fri Apr 22 06:14:58 2011
Date: Fri, 22 Apr 2011 15:14:55 +0200
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
To: [email-masked]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt

On 4/21/11 6:41 AM, Phillip Hallam-Baker wrote:
>
>
> On Thu, Apr 21, 2011 at 12:14 AM, Eric Rescorla <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     On Wed, Apr 20, 2011 at 7:54 PM, Paul Wouters <[email-masked]
>     <mailto:[email-masked]>> wrote:
>      > On Wed, 20 Apr 2011, Eric Rescorla wrote:
>      >
>      >>>> Yes, it's true that there are a large number of self-signed
>     certificates
>      >>>> in use,
>      >>>> and that the operators deploying those certs could in
>     principle use
>      >>>> DANE, but
>      >>>> then said operators could in principle also get CA-issued certs.
>      >>>
>      >>> DNS entries in your own zone have cost nothing. PKIX
>     certificates are
>      >>> expensive,
>      >>> especially because "*" is prohibitively more expensive.
>      >>
>      >> On the other hand pkix certs work for basically any browser whereas
>      >> currently Dane-based auth works with approximately no browsers
>     now and far
>      >> will work for far  less than all for quite some time.
>      >
>      > I'm not quite following the logic of "since we didn't finish the
>     standard
>      > yet, no one is using it" argument.
>
>     That's not my argument.
>
>     You said that the most important use case by volume is people using
>     self-signed
>     certs and backing them via DANE. But the value of DANE to the server
>     operator
>     in that case is primarily in suppressing warnings at the user's
>     browser. What I
>     said is that operators who care about suppressing that warning could get
>     much more effective warning suppression now and for the foreseeable
>     future
>     by getting a standard CA certificate. So given that they have not
>     chosen to do so,
>     I don't think it's obvious that a large number of those operators
>     will choose to
>     serve DNSSEC-based DANE certificates at some point in the future.
>
>     I agree it's not that particularly important to decide what the most
>     important
>     use cases are, but I merely wanted to observe that I didn't think
>     that it was
>     in fact obvious that this was the most important use case.
>
>     -Ekr
>     _______________________________________________
>     dane mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/dane
>
>
> I think this is best set out in use case form:
>
> Use Case: Alice wants to set up Web site so that Bob can connect without
> Mallet or Eve intercepting messages. Bob has a Dane capable browser
>
> Constraint 1: Carol does not want to upgrade her browser, her user
> experience MUST NOT be negatively impacted.
> Constraint 2: Alice is not willing to pay for a CA issued cert (or
> alternatively does not want to apply for one)
>
> DANE does not provide a solution to this use case under these
> constraints by itself.
>
> DANE+HASTLS does provide a solution however. When Carol accesses the
> site using her obsolete browser, it does not support the HASTLS
> mechanism and thus does not know to try TLS and thus does not issue
> nuisance warnings.
>
>
> This si the reason that I have been arguing that HASTLS type
> requirements and Key publication requirements have to be considered
> together from the very start.
>
> Trying to propose a different way for people to do what they can do
> already that is not backwards compatible is a futile waste of time.
>
> The compelling use cases for putting keys in the DNS are to provide
> additional security controls for CA issued certs (as CAA does), to
> enable promiscuous security and to provide keys for Internet protocols
> that use TLS but are not encumbered by a legacy base.
>
> There is a reason that I have spent so much time ensuring that my
> proposal works correctly and consistently when SRV, NAPTR or URI type
> discovery mechanisms are used. It is because I believe that Web Services
> is the type of niche use case that can drive a standard like Dane to
> reach critical mass.

We have already discussed SRV in issue#1 and we the WG rejected the idea 
of using SRV.

> I can support the requirements of key issue restrictions, key
> publication and advertising security features offered in a single
> framework that is just as efficient as the current DANE proposal but
> does not have the limitations imposed by the limited scope the authors
> keep insisting on.
>
> Some people keep claiming that there is consensus for the current
> approach, but I don't see one in the WG.
>
>
> Why can't we choose the protocol architecture on the basis of the
> proposal that supports the widest range of use cases with the simplest
> mechanism and best objective performance metrics wins?

Anyway Phillip,

care to split your requirements into clear individual issues (as you see 
them)?  I'll log them into our issue tracker for reference, the mailing 
list is too crowded to keep track of anything.

Thanks,
O.

From [email-masked]  Fri Apr 22 06:19:22 2011
Date: Fri, 22 Apr 2011 15:19:21 +0200
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
To: [email-masked]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt

On 4/22/11 3:43 AM, Phillip Hallam-Baker wrote:
> DNSSEC is going to cost registrars money to deploy so people should
> not expect it to be cost free.

Speaking for .CZ which has highest DNSSEC penetration in the world
(122563/794330) - our DNSSEC registrars provide DNSSEC as free and those
two with highest number of DNSSEC provide it as default.

So lets stick to what you said earlier in the email:

> Such considerations are in any case a poor basis for making protocol
> design decisions.  Prices change in response to market conditions.

O.

From [email-masked]  Fri Apr 22 10:35:59 2011
From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 22 Apr 2011 13:35:38 -0400
To: "Richard L. Barnes" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dane] Fwd: New Version Notification for draft-ietf-dane-use-cases-01

Working with the Internet architecture is in scope

Thus continuing to work with Ipv6 an without well known port discovery is in=
 scope

And in any case the point of this exercise is that the consensus in Prague w=
as that the wg had not shown   It is solving the right problem

Sent from my iPhone

On 22 Apr 2011, at 09:01, "Richard L. Barnes" <[email-masked]> wrote:

>> I think that Promiscuous Security and Web Services support should be adde=
d to the use cases. TLS is used for much more than just Web Browsing and the=
 non-Web browsing use cases are rather more important in my view.
>=20
> The use cases as described are in no way specific to web browsing.  They a=
pply generally to applications using TLS that require authentication of doma=
in names.  In any case, I do not see use cases titled "Promiscuous Security"=
 or "Web Services" in draft-hallambaker-dane-requirements, so please propose=
 text.
>=20
>=20
>> One very important constraint is the need to support mechanisms for proto=
col discovery that do not rely on port numbers.
>=20
> Protocol discovery is not in scope, not least because it varies from one a=
pplication to another.  The use cases described apply equally well to dual-p=
ort (dedicated TLS port) and STARTTLS design patterns.  Indeed, examples of b=
oth are referenced in the introduction.
>=20
> Key/cert discovery is in scope, but that does not have anything to do with=
 port exhaustion.  The question there is whether a client can disambiguate s=
ervices on different ports.
>=20
>=20
>> As a matter of style, the ESA format that has the requirements tagged wit=
h a reference number (e.g. [U-S-TRUST]) makes it easier to refer to the requ=
irements when determining if a proposal meets them.
>=20
> I think we have few enough requirements here that there's not a need for a=
 formalism.
>=20
> --Richard
>=20
>=20
>=20
>=20
>=20
>>=20
>>=20
>> On Fri, Apr 22, 2011 at 8:32 AM, Richard L. Barnes <[email-masked]> wrot=
e:
>> This is an updated version of the use cases draft, which incorporates fee=
dback on -00 and makes several editorial changes.  Diff is here:
>> <http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-dane-use-cases-01.txt>
>>=20
>> Chairs: I believe this version is ready for WGLC.
>>=20
>> --Richard
>>=20
>>=20
>>=20
>>=20
>> Begin forwarded message:
>>=20
>>> From: IETF I-D Submission Tool <[email-masked]>
>>> Date: April 22, 2011 8:30:04 AM EDT
>>> To: [email-masked]
>>> Subject: New Version Notification for draft-ietf-dane-use-cases-01
>>>=20
>>>=20
>>> A new version of I-D, draft-ietf-dane-use-cases-01.txt has been successf=
ully submitted by Richard Barnes and posted to the IETF repository.
>>>=20
>>> Filename:      draft-ietf-dane-use-cases
>>> Revision:      01
>>> Title:                 Use Cases and Requirements for DNS-based Authenti=
cation of Named Entities (DANE)
>>> Creation_date:         2011-04-22
>>> WG ID:                 dane
>>> Number_of_pages: 9
>>>=20
>>> Abstract:
>>> Many current applications use the certificate-based authentication
>>> features in TLS to allow clients to verify that a connected server
>>> properly represents a desired domain name.  Traditionally, this
>>> authentication has been based on PKIX trust hierarchies, rooted in
>>> well-known CAs, but additional information can be provided via the
>>> DNS itself.  This document describes a set of use cases in which the
>>> DNS and DNSSEC could be used to make assertions that support the TLS
>>> authentication process.
>>>=20
>>>=20
>>>=20
>>> The IETF Secretariat.
>>>=20
>>>=20
>>=20
>> _______________________________________________
>> dane mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dane
>>=20
>>=20
>>=20
>> --=20
>> Website: http://hallambaker.com/
>>=20
>=20

From [email-masked]  Fri Apr 22 10:54:55 2011
From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 22 Apr 2011 13:54:53 -0400
To: Phillip Hallam-Baker <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dane] Fwd: New Version Notification for draft-ietf-dane-use-cases-01

> Working with the Internet architecture is in scope
>=20
> Thus continuing to work with Ipv6 an without well known port discovery =
is in scope

Continuing to work with these things is clearly a goal, but it's =
satisfied trivially by having a clean interface: You give us a domain =
name and maybe a port number, and we'll help you authenticate that =
someone has the authorization to use them.

It doesn't matter if the domain name / port number came from
-- User entry
-- A URL
-- SRV
-- NAPTR
-- An SDP body in a SIP message
-- etc.

We support all these discovery use cases (and more!) by not doing =
anything with them and simply accepting their outputs.  Wei wu wei. =20

--Richard

> And in any case the point of this exercise is that the consensus in =
Prague was that the wg had not shown   It is solving the right problem
>=20
> Sent from my iPhone
>=20
> On 22 Apr 2011, at 09:01, "Richard L. Barnes" <[email-masked]> wrote:
>=20
>>> I think that Promiscuous Security and Web Services support should be =
added to the use cases. TLS is used for much more than just Web Browsing =
and the non-Web browsing use cases are rather more important in my view.
>>=20
>> The use cases as described are in no way specific to web browsing.  =
They apply generally to applications using TLS that require =
authentication of domain names.  In any case, I do not see use cases =
titled "Promiscuous Security" or "Web Services" in =
draft-hallambaker-dane-requirements, so please propose text.
>>=20
>>=20
>>> One very important constraint is the need to support mechanisms for =
protocol discovery that do not rely on port numbers.
>>=20
>> Protocol discovery is not in scope, not least because it varies from =
one application to another.  The use cases described apply equally well =
to dual-port (dedicated TLS port) and STARTTLS design patterns.  Indeed, =
examples of both are referenced in the introduction.
>>=20
>> Key/cert discovery is in scope, but that does not have anything to do =
with port exhaustion.  The question there is whether a client can =
disambiguate services on different ports.
>>=20
>>=20
>>> As a matter of style, the ESA format that has the requirements =
tagged with a reference number (e.g. [U-S-TRUST]) makes it easier to =
refer to the requirements when determining if a proposal meets them.
>>=20
>> I think we have few enough requirements here that there's not a need =
for a formalism.
>>=20
>> --Richard
>>=20
>>=20
>>=20
>>=20
>>=20
>>>=20
>>>=20
>>> On Fri, Apr 22, 2011 at 8:32 AM, Richard L. Barnes <[email-masked]> =
wrote:
>>> This is an updated version of the use cases draft, which =
incorporates feedback on -00 and makes several editorial changes.  Diff =
is here:
>>> =
<http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-dane-use-cases-01.txt>
>>>=20
>>> Chairs: I believe this version is ready for WGLC.
>>>=20
>>> --Richard
>>>=20
>>>=20
>>>=20
>>>=20
>>> Begin forwarded message:
>>>=20
>>>> From: IETF I-D Submission Tool <[email-masked]>
>>>> Date: April 22, 2011 8:30:04 AM EDT
>>>> To: [email-masked]
>>>> Subject: New Version Notification for draft-ietf-dane-use-cases-01
>>>>=20
>>>>=20
>>>> A new version of I-D, draft-ietf-dane-use-cases-01.txt has been =
successfully submitted by Richard Barnes and posted to the IETF =
repository.
>>>>=20
>>>> Filename:      draft-ietf-dane-use-cases
>>>> Revision:      01
>>>> Title:                 Use Cases and Requirements for DNS-based =
Authentication of Named Entities (DANE)
>>>> Creation_date:         2011-04-22
>>>> WG ID:                 dane
>>>> Number_of_pages: 9
>>>>=20
>>>> Abstract:
>>>> Many current applications use the certificate-based authentication
>>>> features in TLS to allow clients to verify that a connected server
>>>> properly represents a desired domain name.  Traditionally, this
>>>> authentication has been based on PKIX trust hierarchies, rooted in
>>>> well-known CAs, but additional information can be provided via the
>>>> DNS itself.  This document describes a set of use cases in which =
the
>>>> DNS and DNSSEC could be used to make assertions that support the =
TLS
>>>> authentication process.
>>>>=20
>>>>=20
>>>>=20
>>>> The IETF Secretariat.
>>>>=20
>>>>=20
>>>=20
>>> _______________________________________________
>>> dane mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/dane
>>>=20
>>>=20
>>>=20
>>> --=20
>>> Website: http://hallambaker.com/
>>>=20
>>=20

From [email-masked]  Fri Apr 22 11:12:51 2011
Date: Fri, 22 Apr 2011 14:12:50 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt

--20cf304346f4454fc304a185ce2d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Apr 22, 2011 at 9:14 AM, Ond=C5=99ej Sur=C3=BD <[email-masked]>=
 wrote:

> On 4/21/11 6:41 AM, Phillip Hallam-Baker wrote:
>
>>
>> There is a reason that I have spent so much time ensuring that my
>> proposal works correctly and consistently when SRV, NAPTR or URI type
>> discovery mechanisms are used. It is because I believe that Web Services
>> is the type of niche use case that can drive a standard like Dane to
>> reach critical mass.
>>
>
> We have already discussed SRV in issue#1 and we the WG rejected the idea =
of
> using SRV.
>
>
That decision is now irrelevant. The WG has been required to go back and
consider use cases for keys in the DNS.

The WG may decide not to meet all the proposed use cases but they should al=
l
be documented.

And one of the consequences of not meeting a use case is that it may well
mean that we end up with two keys in the DNS protocols rather than one.

I would much prefer there to be one joint proposal that meets all our needs
but when a WG decides not to support a use case or constraint it is also
saying 'we do not object to others meeting that use case in a different
way'. If there is a WG consensus that you would all prefer me to address my
use case my way and not bother the group, that is fine with me. But if the
WG decides that is what they want to do they are going to have to take all
the responsibility for there being two protocols instead of one.

The purpose of this exercise is to find out if we can find common ground.
The point is lost if a people decide that because they are 5 out of the 8
active people in a WG that whatever they decide has consensus.

Why can't we choose the protocol architecture on the basis of the
>> proposal that supports the widest range of use cases with the simplest
>> mechanism and best objective performance metrics wins?
>>
>
> Anyway Phillip,
>
> care to split your requirements into clear individual issues (as you see
> them)?  I'll log them into our issue tracker for reference, the mailing l=
ist
> is too crowded to keep track of anything.
>

I would prefer to capture them in the use cases document as constraints.

I have the text but it will probably be Monday or Tuesday before I can get
access to the machine.

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

--20cf304346f4454fc304a185ce2d
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Fri, Apr 22, 2011 at 9:14 AM, Ond=F8e=
j Sur=FD <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">ondrej=
[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">On 4/21/11 6:41 AM, Phillip Hallam-Baker wrote:<br>
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div class=3D"im"><br></div><div><div =
class=3D"h5">
There is a reason that I have spent so much time ensuring that my<br>
proposal works correctly and consistently when SRV, NAPTR or URI type<br>
discovery mechanisms are used. It is because I believe that Web Services<br=
>
is the type of niche use case that can drive a standard like Dane to<br>
reach critical mass.<br>
</div></div></blockquote>
<br>
We have already discussed SRV in issue#1 and we the WG rejected the idea of=
 using SRV.<div class=3D"im"><br></div></blockquote><div><br></div><div>Tha=
t decision is now irrelevant. The WG has been required to go back and consi=
der use cases for keys in the DNS.=A0</div>
<div><br></div><div>The WG may decide not to meet all the proposed use case=
s but they should all be documented.</div><div><br></div><div><br></div><di=
v>And one of the consequences of not meeting a use case is that it may well=
 mean that we end up with two keys in the DNS protocols rather than one.</d=
iv>
<div><br></div><div>I would much prefer there to be one joint proposal that=
 meets all our needs but when a WG decides not to support a use case or con=
straint it is also saying &#39;we do not object to others meeting that use =
case in a different way&#39;. If there is a WG consensus that you would all=
 prefer me to address my use case my way and not bother the group, that is =
fine with me. But if the WG decides that is what they want to do they are g=
oing to have to take all the responsibility for there being two protocols i=
nstead of one.</div>
<div><br></div><div><br></div><div>The purpose of this exercise is to find =
out if we can find common ground. The point is lost if a people decide that=
 because they are 5 out of the 8 active people in a WG that whatever they d=
ecide has consensus.=A0</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex;"><div class=3D"im"><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">
Why can&#39;t we choose the protocol architecture on the basis of the<br>
proposal that supports the widest range of use cases with the simplest<br>
mechanism and best objective performance metrics wins?<br>
</blockquote>
<br></div>
Anyway Phillip,<br>
<br>
care to split your requirements into clear individual issues (as you see th=
em)? =A0I&#39;ll log them into our issue tracker for reference, the mailing=
 list is too crowded to keep track of anything.<br></blockquote><div><br>
</div><div>I would prefer to capture them in the use cases document as cons=
traints.</div><div><br></div><div>I have the text but it will probably be M=
onday or Tuesday before I can get access to the machine.</div><div><br>
</div><div>=A0</div></div>-- <br>Website: <a href=3D"http://hallambaker.com=
/">http://hallambaker.com/</a><br><br>

--20cf304346f4454fc304a185ce2d--

From [email-masked]  Fri Apr 22 11:19:57 2011
Date: Fri, 22 Apr 2011 14:19:55 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dane] Fwd: New Version Notification for draft-ietf-dane-use-cases-01

--bcaec548a0679f645b04a185e779
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Apr 22, 2011 at 1:54 PM, Richard L. Barnes <[email-masked]> wrote:

> > Working with the Internet architecture is in scope
> >
> > Thus continuing to work with Ipv6 an without well known port discovery is
> in scope
>
> Continuing to work with these things is clearly a goal, but it's satisfied
> trivially by having a clean interface: You give us a domain name and maybe a
> port number, and we'll help you authenticate that someone has the
> authorization to use them.
>
> It doesn't matter if the domain name / port number came from
> -- User entry
> -- A URL
> -- SRV
> -- NAPTR
> -- An SDP body in a SIP message
> -- etc.
>
> We support all these discovery use cases (and more!) by not doing anything
> with them and simply accepting their outputs.  Wei wu wei.

That does not work very well for Web Services because there are typically
multiple services on the same port.

It can probably be made to work, but the spec has to explain how to make it
work.

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

--bcaec548a0679f645b04a185e779
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Fri, Apr 22, 2011 at 1:54 PM, Richard=
 L. Barnes <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">rbarnes=
@bbn.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">&gt; Working with the Internet architecture is in scope<b=
r>
&gt;<br>
&gt; Thus continuing to work with Ipv6 an without well known port discovery=
 is in scope<br>
<br>
</div>Continuing to work with these things is clearly a goal, but it&#39;s =
satisfied trivially by having a clean interface: You give us a domain name =
and maybe a port number, and we&#39;ll help you authenticate that someone h=
as the authorization to use them.<br>

<br>
It doesn&#39;t matter if the domain name / port number came from<br>
-- User entry<br>
-- A URL<br>
-- SRV<br>
-- NAPTR<br>
-- An SDP body in a SIP message<br>
-- etc.<br>
<br>
We support all these discovery use cases (and more!) by not doing anything =
with them and simply accepting their outputs. =A0Wei wu wei.</blockquote><d=
iv><br></div><div>That does not work very well for Web Services because the=
re are typically multiple services on the same port.</div>
<div><br></div><div>It can probably be made to work, but the spec has to ex=
plain how to make it work.=A0</div><div><br></div></div>-- <br>Website: <a =
href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>

--bcaec548a0679f645b04a185e779--

From [email-masked]  Fri Apr 22 11:29:20 2011
From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= <[email-masked]>
Date: Fri, 22 Apr 2011 20:28:55 +0200
To: Phillip Hallam-Baker <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt

--Apple-Mail-2-919711709
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

[replying on my phone, so sorry for being terse and for any errors]

On 22.4.2011, at 20:12, Phillip Hallam-Baker <[email-masked]> wrote:

>=20
>=20
> On Fri, Apr 22, 2011 at 9:14 AM, Ond=C5=99ej Sur=C3=BD <[email-masked]=
> wrote:
> On 4/21/11 6:41 AM, Phillip Hallam-Baker wrote:
>=20
> There is a reason that I have spent so much time ensuring that my
> proposal works correctly and consistently when SRV, NAPTR or URI type
> discovery mechanisms are used. It is because I believe that Web Services
> is the type of niche use case that can drive a standard like Dane to
> reach critical mass.
>=20
> We have already discussed SRV in issue#1 and we the WG rejected the idea o=
f using SRV.
>=20
>=20
> That decision is now irrelevant. The WG has been required to go back and c=
onsider use cases for keys in the DNS.=20

Here we don't agree. The WG was requested to write use cases document and no=
t to throw away all past work and restart from scratch.

> The WG may decide not to meet all the proposed use cases but they should a=
ll be documented.
>=20
>=20
> And one of the consequences of not meeting a use case is that it may well m=
ean that we end up with two keys in the DNS protocols rather than one.
>=20
> I would much prefer there to be one joint proposal that meets all our need=
s but when a WG decides not to support a use case or constraint it is also s=
aying 'we do not object to others meeting that use case in a different way'.=
 If there is a WG consensus that you would all prefer me to address my use c=
ase my way and not bother the group, that is fine with me. But if the WG dec=
ides that is what they want to do they are going to have to take all the res=
ponsibility for there being two protocols instead of one.
>=20

Rejecting a use case doesn't mean that WG don't object to others picking it u=
p. I really don't think the implication is there as you're suggesting.

> The purpose of this exercise is to find out if we can find common ground. T=
he point is lost if a people decide that because they are 5 out of the 8 act=
ive people in a WG that whatever they decide has consensus.=20

Nobody is implying that. The WG sticks to the IETF protocols for WG. If you h=
ave any specific objections how any issue and it's call for consensus were d=
one please contact the chairs (me or Warren).

> Why can't we choose the protocol architecture on the basis of the
> proposal that supports the widest range of use cases with the simplest
> mechanism and best objective performance metrics wins?
>=20
> Anyway Phillip,
>=20
> care to split your requirements into clear individual issues (as you see t=
hem)?  I'll log them into our issue tracker for reference, the mailing list i=
s too crowded to keep track of anything.
>=20
> I would prefer to capture them in the use cases document as constraints.
>=20
> I have the text but it will probably be Monday or Tuesday before I can get=
 access to the machine.

Fine with me.

O.=

--Apple-Mail-2-919711709
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><body bgcolor=3D"#FFFFFF"><div>[replying on my phone, so sorry for bei=
ng terse and for any errors]</div><div><br></div><div>On 22.4.2011, at 20:12=
, Phillip Hallam-Baker &lt;<a href=3D"mailto:[email-masked]">hallam@gmail.=
com</a>&gt; wrote:<br><br></div><div></div><blockquote type=3D"cite"><div><b=
r><br><div class=3D"gmail_quote">On Fri, Apr 22, 2011 at 9:14 AM, Ond=C5=99e=
j Sur=C3=BD <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]"><a h=
ref=3D"mailto:[email-masked]">[email-masked]</a></a>&gt;</span> wrot=
e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">On 4/21/11 6:41 AM, Phillip Hallam-Baker wrote:<br>
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div class=3D"im"><br></div><div><div cl=
ass=3D"h5">
There is a reason that I have spent so much time ensuring that my<br>
proposal works correctly and consistently when SRV, NAPTR or URI type<br>
discovery mechanisms are used. It is because I believe that Web Services<br>=

is the type of niche use case that can drive a standard like Dane to<br>
reach critical mass.<br>
</div></div></blockquote>
<br>
We have already discussed SRV in issue#1 and we the WG rejected the idea of u=
sing SRV.<div class=3D"im"><br></div></blockquote><div><br></div><div>That d=
ecision is now irrelevant. The WG has been required to go back and consider u=
se cases for keys in the DNS.&nbsp;</div></div></div></blockquote><div><br><=
/div><div>Here we don't agree. The WG was requested to write use cases docum=
ent and not to throw away all past work and restart from scratch.</div><br><=
blockquote type=3D"cite"><div><div class=3D"gmail_quote"><div>The WG may dec=
ide not to meet all the proposed use cases but they should all be documented=
.</div><div><br></div><div><br></div><div>And one of the consequences of not=
 meeting a use case is that it may well mean that we end up with two keys in=
 the DNS protocols rather than one.</div>
<div><br></div><div>I would much prefer there to be one joint proposal that m=
eets all our needs but when a WG decides not to support a use case or constr=
aint it is also saying 'we do not object to others meeting that use case in a=
 different way'. If there is a WG consensus that you would all prefer me to a=
ddress my use case my way and not bother the group, that is fine with me. Bu=
t if the WG decides that is what they want to do they are going to have to t=
ake all the responsibility for there being two protocols instead of one.</di=
v>
<div><br></div></div></div></blockquote><div><br></div><div>Rejecting a use c=
ase doesn't mean that WG don't object to others picking it up. I really don'=
t think the implication is there as you're suggesting.</div><br><blockquote t=
ype=3D"cite"><div><div class=3D"gmail_quote"><div>The purpose of this exerci=
se is to find out if we can find common ground. The point is lost if a peopl=
e decide that because they are 5 out of the 8 active people in a WG that wha=
tever they decide has consensus.&nbsp;</div></div></div></blockquote><div><b=
r></div><div>Nobody is implying that. The WG sticks to the IETF protocols fo=
r WG. If you have any specific objections how any issue and it's call for co=
nsensus were done please contact the chairs (me or Warren).</div><br><blockq=
uote type=3D"cite"><div><div class=3D"gmail_quote"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex;"><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Why can't we choose the protocol architecture on the basis of the<br>
proposal that supports the widest range of use cases with the simplest<br>
mechanism and best objective performance metrics wins?<br>
</blockquote>
<br></div>
Anyway Phillip,<br>
<br>
care to split your requirements into clear individual issues (as you see the=
m)? &nbsp;I'll log them into our issue tracker for reference, the mailing li=
st is too crowded to keep track of anything.<br></blockquote><div><br>
</div><div>I would prefer to capture them in the use cases document as const=
raints.</div><div><br></div><div>I have the text but it will probably be Mon=
day or Tuesday before I can get access to the machine.</div></div>
</div></blockquote><br><div>Fine with me.</div><div><br></div><div>O.</div><=
/body></html>=

--Apple-Mail-2-919711709--

From [email-masked]  Fri Apr 22 11:53:08 2011
Date: Fri, 22 Apr 2011 14:53:04 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt

--20cf30780e6e276e8504a1865e04
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Apr 22, 2011 at 2:28 PM, Ond=C5=99ej Sur=C3=BD <[email-masked]>=
 wrote:

> [replying on my phone, so sorry for being terse and for any errors
>
>
> That decision is now irrelevant. The WG has been required to go back and
> consider use cases for keys in the DNS.
>
>
> Here we don't agree. The WG was requested to write use cases document and
> not to throw away all past work and restart from scratch.
>

So you think it is going to be ok to make no changes to what you propose to
do and just give more of an explanation of why?

> Rejecting a use case doesn't mean that WG don't object to others picking =
it
> up. I really don't think the implication is there as you're suggesting.
>

No, but rejecting a use case means that the WG has forfeited the right to
make an objection.

If a WG wants people to use their proposal then they support their use
cases. If they refuse to support a use cases they accept that there may be
alternatives.

Whether people mind or not is irrelevant. If you want there to be one
protocol to meet this set of needs then you need to look to support 95% of
the use cases. If you decide that you don't want to support a use case you
are telling people to look elsewhere. That is what use cases mean.

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

--20cf30780e6e276e8504a1865e04
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Fri, Apr 22, 2011 at 2:28 PM, Ond=C5=
=99ej Sur=C3=BD <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]"=
>[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;=
">
<div bgcolor=3D"#FFFFFF"><div>[replying on my phone, so sorry for being ter=
se and for any errors</div><div class=3D"im"><blockquote type=3D"cite"><div=
><div class=3D"gmail_quote"><div><br></div><div>That decision is now irrele=
vant. The WG has been required to go back and consider use cases for keys i=
n the DNS.=C2=A0</div>
</div></div></blockquote><div><br></div></div><div>Here we don&#39;t agree.=
 The WG was requested to write use cases document and not to throw away all=
 past work and restart from scratch.</div></div></blockquote><div><br></div=
>
<div>So you think it is going to be ok to make no changes to what you propo=
se to do and just give more of an explanation of why?</div><div><br></div><=
div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex;">
<div bgcolor=3D"#FFFFFF"><div>Rejecting a use case doesn&#39;t mean that WG=
 don&#39;t object to others picking it up. I really don&#39;t think the imp=
lication is there as you&#39;re suggesting.</div></div></blockquote><div>
<br></div><div>No, but rejecting a use case means that the WG has forfeited=
 the right to make an objection.</div><div><br></div><div>If a WG wants peo=
ple to use their proposal then they support their use cases. If they refuse=
 to support a use cases they accept that there may be alternatives.=C2=A0</=
div>
<div><br></div><div>Whether people mind or not is irrelevant. If you want t=
here to be one protocol to meet this set of needs then you need to look to =
support 95% of the use cases. If you decide that you don&#39;t want to supp=
ort a use case you are telling people to look elsewhere. That is what use c=
ases mean.</div>
<div><br></div><div><br></div></div>-- <br>Website: <a href=3D"http://halla=
mbaker.com/">http://hallambaker.com/</a><br><br>

--20cf30780e6e276e8504a1865e04--

From [email-masked]  Fri Apr 22 20:49:24 2011
From: "Jim Schaad" <[email-masked]>
To: "'Richard L. Barnes'" <[email-masked]>, <[email-masked]>
Date: Fri, 22 Apr 2011 21:15:28 -0700
Subject: Re: [dane] Fwd: New Version Notification for	draft-ietf-dane-use-cases-01

Comments on the draft:

Abstract:
1.  "Traditionally, this
   authentication has been based on PKIX trust hierarchies, rooted in
   well-known CAs, but additional information can be provided via the
   DNS itself. "
 I don't know that this is true based on the messages that have been sent on
the list.  Given the amount of apparent self-signed certs that are used for
TLS I don't think it can be said that this is the tradition.  One might be
able to say conceptually but not traditionally.

Section 1. Introduction
1. "After locating the server via an A or AAAA record,"  This is what gives
you an address for a server, however the process of locating the server is
much more complicated and involves all sorts of different DNS records (MX,
CNAME, SRV, ...).   Better would be "After obtaining the address of a server
via an A or AAAA record,"

2.  The last sentence in this paragraph should refer to the new RFC on how
to do this process, since it is complicated and may depend on DNS records
not  mentioned above.

3.  "In most current applications, this decision process is based on PKIX
validation and name matching."  This text implies that the name matching is
also a PKIX defined functionality.  It is not it is based on the protocol
that is using the TLS process.  (See note on PSA draft above.)  Suggested
text would be "PKIX path validation and protocol based name matching."

Section 3.

I want to add a number of actors to this list since I have a set of use
cases that are not covered that I think should be.

Add Trent a well-known CA that is installed as a trust anchor on Bobs
machine.

Charlie becomes a CA that issues certificates with domain names as
identifiers.  Charlie may be the same as Trent, operator as an intermediate
CA below Trent either being the same as or independent of Alice.

Diane is the operator of a TLS-protected service for Alice. 
(Or make Alice the owner and administrator of the domain and say that Diane
and Alice could be the same entity.)

Now in the CA constraints, Alice may want to restrict to either Trent (a
known trust point) or Charlie (an intermediate CA).

The reason for the restrict is now possibly down to Trent or Charlie.  Or it
can be that there is a restriction to what Diane is permitted to use (this
is also the 3.2 example I assume.)

The following  is not a use case?  I thought this was constantly coming up
on the list.
Alice runs the domain alice.example.com, but Diane (diane.example.com)
operates a TLS secured service for Alice.

3.2 is, I assume supposed to be a restriction on the EE certificate - and
thus would restrict both Bob and Diane in what they can do.

In 3.3 - there are now two different cases that can come about.  1) Alice is
now running her own CA that is not well-known or trusted and 2) Alice wants
Bob to trust Trent (or maybe Charlie), but Bob does not either by default or
by policy.

Section 4 - Other Requirements

In some cases is the statement about Encapsulation correct?  In the event of
an SRV or CNAME or MX record (and so forth).  Should you be able to make
statements about the party that is actually going to provide the services if
they are outsourced?

Predictability - Given that we are making statements that we don't care
about cases where things like SRV records exist.  What is the likelihood
that protocols are going to want to change the DANE behavior about thinks
like encapsulation and which DANE record formats exist.   How are you
defining PKIX information in this case given that it can be defined by
different protocols and how the domain information is dealt with in those
cases is going to be treated differently.  Are you going to define the DANE
values as inputs to the PKIX path validation process?  So that they are
constrained by name constraints?

For the Wild Cards and CNAME items, does this mean we need to have a BCP
statement for how to fill in your DNS so that people will get it correct?
It is of much greater importance that people who do not correctly understand
how DNS wild card matching works get top of the line guidance on how to
configure and fill in their DNS structure in order to get it working
correct.  This is of special importance since much of the group believes
that this work is going to be done by non-specialists who are not willing to
pay for additional security services (i.e. getting a certificate from a
well-known CA).

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Richard L. Barnes
> Sent: Friday, April 22, 2011 5:32 AM
> To: [email-masked]
> Subject: [dane] Fwd: New Version Notification for
draft-ietf-dane-use-cases-
> 01
> 
> This is an updated version of the use cases draft, which incorporates
> feedback on -00 and makes several editorial changes.  Diff is here:
> <http://tools.ietf.org/rfcdiff?url2=draft-ietf-dane-use-cases-01.txt>
> 
> Chairs: I believe this version is ready for WGLC.
> 
> --Richard
> 
> 
> 
> 
> Begin forwarded message:
> 
> > From: IETF I-D Submission Tool <[email-masked]>
> > Date: April 22, 2011 8:30:04 AM EDT
> > To: [email-masked]
> > Subject: New Version Notification for draft-ietf-dane-use-cases-01
> >
> >
> > A new version of I-D, draft-ietf-dane-use-cases-01.txt has been
> successfully submitted by Richard Barnes and posted to the IETF
repository.
> >
> > Filename:	 draft-ietf-dane-use-cases
> > Revision:	 01
> > Title:		 Use Cases and Requirements for DNS-based
Authentication
> of Named Entities (DANE)
> > Creation_date:	 2011-04-22
> > WG ID:		 dane
> > Number_of_pages: 9
> >
> > Abstract:
> > Many current applications use the certificate-based authentication
> > features in TLS to allow clients to verify that a connected server
> > properly represents a desired domain name.  Traditionally, this
> > authentication has been based on PKIX trust hierarchies, rooted in
> > well-known CAs, but additional information can be provided via the DNS
> > itself.  This document describes a set of use cases in which the DNS
> > and DNSSEC could be used to make assertions that support the TLS
> > authentication process.
> >
> >
> >
> > The IETF Secretariat.
> >
> >
> 
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

From [email-masked]  Sat Apr 23 10:03:16 2011
From: "Richard L. Barnes" <[email-masked]>
Date: Sat, 23 Apr 2011 13:03:14 -0400
To: Phillip Hallam-Baker <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [dane] Fwd: New Version Notification for draft-ietf-dane-use-cases-01

> That does not work very well for Web Services because there are =
typically multiple services on the same port.
>=20
> It can probably be made to work, but the spec has to explain how to =
make it work.=20

Could you be a little more explicit?  The Web Services Security =
framework I'm aware of [1] does not use TLS, and thus is not something =
germane to this working group.

[1] <http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=3Dwss>=

From [email-masked]  Sat Apr 23 11:29:13 2011
From: Richard L. Barnes <[email-masked]>
Date: Sat, 23 Apr 2011 14:29:11 -0400
To: "Jim Schaad" <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] Fwd: New Version Notification for	draft-ietf-dane-use-cases-01

Hey Jim,

Thanks for the comments.  Responses inline.

> Abstract:
> 1.  "Traditionally, this
>   authentication has been based on PKIX trust hierarchies, rooted in
>   well-known CAs, but additional information can be provided via the
>   DNS itself. "
> I don't know that this is true based on the messages that have been =
sent on
> the list.  Given the amount of apparent self-signed certs that are =
used for
> TLS I don't think it can be said that this is the tradition.  One =
might be
> able to say conceptually but not traditionally.

Well, I guess the self-signed case as it exists today is still PKIX, but =
with very ad-hoc TA management.  I think the sense is probably clear =
enough to set context in the Abstract.

> Section 1. Introduction
> 1. "After locating the server via an A or AAAA record,"  This is what =
gives
> you an address for a server, however the process of locating the =
server is
> much more complicated and involves all sorts of different DNS records =
(MX,
> CNAME, SRV, ...).   Better would be "After obtaining the address of a =
server
> via an A or AAAA record,"

Good point.  This also relates to Phil's point about other discovery =
mechanisms.  Revised paragraph:
One feature that is common to most uses of TLS is the use of =
certificates to authenticate domain names for services. The TLS client =
begins the TLS connection process with the goal of connecting to a =
server with a specific domain name.  (The process of obtaining this =
domain name is application-specific.  It could be entered by a user or =
found through an automated discovery process, e.g., via an SRV or NAPTR =
record.) After obtaining the address of the server via an A or AAAA =
record, the client conducts a TLS handshake with the server, during =
which the server presents a PKIX certificate for itself [RFC5280]. Based =
on this certificate, the client decides whether the server properly =
represents the desired domain name, and thus whether to proceed with the =
TLS connection or not.

> 2.  The last sentence in this paragraph should refer to the new RFC on =
how
> to do this process, since it is complicated and may depend on DNS =
records
> not  mentioned above.

Are you referring to RFC 6125?  There's to that a reference in the next =
paragraph, which actually discusses the decision process.

> 3.  "In most current applications, this decision process is based on =
PKIX
> validation and name matching."  This text implies that the name =
matching is
> also a PKIX defined functionality.  It is not it is based on the =
protocol
> that is using the TLS process.  (See note on PSA draft above.)  =
Suggested
> text would be "PKIX path validation and protocol based name matching."

Done.  (Using "application-specific" instead of "protocol based")

> The reason for the restrict is now possibly down to Trent or Charlie.  =
Or it
> can be that there is a restriction to what Diane is permitted to use =
(this
> is also the 3.2 example I assume.)
>=20
> The following  is not a use case?  I thought this was constantly =
coming up
> on the list.
> Alice runs the domain alice.example.com, but Diane (diane.example.com)
> operates a TLS secured service for Alice.

So you're saying that publishing DANE records also constrains what certs =
an outsourced service provider can use?  What's the threat here?  =20

> 3.2 is, I assume supposed to be a restriction on the EE certificate - =
and
> thus would restrict both Bob and Diane in what they can do.

I think that going into that level of detail in this document isn't =
really necessary -- we can just say that the cert we're concerned about =
is "the cert for the server" regardless of the specific characteristics =
of that cert.  But you're correct that the DANE record also constrains =
Diane.

> In 3.3 - there are now two different cases that can come about.  1) =
Alice is
> now running her own CA that is not well-known or trusted and 2) Alice =
wants
> Bob to trust Trent (or maybe Charlie), but Bob does not either by =
default or
> by policy.

Two valid cases, but they look basically the same from a technical point =
of view: Either way, it's a TA that the rest of the world doesn't know =
about.  How about a clarifying sentence at the end of the second =
paragraph of 3.3 (or possibly as a separate para):
"
[In dramatis personae:]
Trent: A CA that issues certificates with domain names as identifiers, =
but is not generally well-known.

This use case is functionally equivalent to the case where Alice doesn't =
issue her own certificates, but uses a CA Trent that is not well-known.  =
In this case, Alice would be advising Bob that he should treat Trent as =
a trust anchor for purposes of validating Alice's certificates.
"

> Section 4 - Other Requirements
>=20
> In some cases is the statement about Encapsulation correct?  In the =
event of
> an SRV or CNAME or MX record (and so forth).  Should you be able to =
make
> statements about the party that is actually going to provide the =
services if
> they are outsourced?

This seems like an application-layer question, and it depends on a few =
things, such as (1) whether the outsourcing is done securely or =
insecurely, and (2) whether the outsourcing is visible to the client =
(via CNAME/MX/etc) or not (via A/AAAA).  For example, if you get a =
secure SRV to a different domain, that seems like an explicit, secure =
delegation of services, in which case the client is OK to authenticate =
the outsourcing provider directly.

All of these questions, though, relate to what name a client is looking =
for.  So there is a clean interface to DANE:
1. Identify the name of the service you want to connect to (either the =
starting name or the name of the outsourcing provider)
2. Use DANE + TLS to authenticate that name

(And regardless of these distinctions, the domain owner still has =
control by choosing how to outsource, and whom to outsource to.  It's =
just a question of whether the control is in SRV or TLSA.)

Net of these concerns, I think the encapsulation requirement is still =
correct.

> Predictability - Given that we are making statements that we don't =
care
> about cases where things like SRV records exist.  What is the =
likelihood
> that protocols are going to want to change the DANE behavior about =
thinks
> like encapsulation and which DANE record formats exist.   How are you
> defining PKIX information in this case given that it can be defined by
> different protocols and how the domain information is dealt with in =
those
> cases is going to be treated differently.  Are you going to define the =
DANE
> values as inputs to the PKIX path validation process?  So that they =
are
> constrained by name constraints?

In this case, we have exactly one set of PKIX information, the cert =
chain in the TLS handshake.  DANE will address whether that cert =
properly represents a domain; applications can choose which domain to =
use, and check other things if they want.  DANE will probably override =
some of RFC 6125, but that's part of the idea.  These are also more =
questions for the mechanism draft, rather than use cases / requirements.

> For the Wild Cards and CNAME items, does this mean we need to have a =
BCP
> statement for how to fill in your DNS so that people will get it =
correct?

Of course, general advice about configuring DNS properly is not the =
domain (haha) of this group, but of DNSOP.  I would think that we would =
have some provisioning advice in our documents, though, at the level of =
RECOMMENDED patterns.

From [email-masked]  Sat Apr 23 11:47:50 2011
Date: Sat, 23 Apr 2011 11:47:48 -0700
From: =JeffH <[email-masked]>
To: IETF DANE WG list <[email-masked]>
Subject: Re: [dane] Fwd: New Version Notification for draft-ietf-dane-use-cases-01

 >> That does not work very well for Web Services because there are typically
 >> multiple services on the same port.
 >>
 >> It can probably be made to work, but the spec has to explain how to make
 >> it work.
 >
 >
 > Could you be a little more explicit?

Indeed -- i.e. what do you (PHB) mean by "web services" ?   There's a plethora 
of things out there calling themselves "web services".

thanks,

=JeffH

From [email-masked]  Sat Apr 23 19:53:10 2011
Date: Sat, 23 Apr 2011 22:53:08 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: "=JeffH" <[email-masked]>
Cc: IETF DANE WG list <[email-masked]>
Subject: Re: [dane] Fwd: New Version Notification for draft-ietf-dane-use-cases-01

--20cf3071cfaedfd0ee04a1a13070
Content-Type: text/plain; charset=ISO-8859-1

Web Services are generally understood to be machine-machine protocols
running over the 'Web' platform.

That minimally means using URIs as identifiers, DNS as the naming scheme but
in the typical case also means layering over HTTP as transport.

There are two main camps in Web Services, SOAP and non-SOAP (usually
referred to as REST regardless of whether it is). At this point it seems
fairly settled that both are to be called 'Web Services'. There is something
of an ideological divide and both sides probably have a point.

SOAP is really designed to make it easy to wrap a network wrapper around an
existing piece of infrastructure like a .COM library or an SQL database. It
provides little if any value for protocols like SAML or XKMS which are
scratch built and use their own security mechanisms. Both would run just as
well over raw HTTP as far as I can remember.

I am aware of the WS-* series of specifications being an author of the
original proposal and an editor of the OASIS spec. They are not designed to
provide security at the same layer as TLS though. TLS gives transport layer
security while WS-* is message layer. So WS-* can deliver non-repudiation
while TLS secures both the body and the headers. Both are needed.

Its the same situation with email. There are pros and cons to using S/MIME
and TLS and neither is really a complete substitute for the other.

WS-* is deeply embedded in SOAP anyway, so it only works for some Web
Services.

The big challenge in both cases is that we have been lacking a model for how
Web Services work out what security enhancements are on offer and how to
apply them. In the original scheme proposed by Microsoft and IBM, this was
going to be the job of UDDI. But that went the way of every other 'replace
the DNS' project to date leaving a hole in the Web Services architecture.

Most Web Services use TLS for security today and not WS-*. But the approach
to doing so is pretty ad hoc and confused. There is a real opportunity there
to clarify matters.

On Sat, Apr 23, 2011 at 2:47 PM, =JeffH <[email-masked]>wrote:

> >> That does not work very well for Web Services because there are
> typically
> >> multiple services on the same port.
> >>
> >> It can probably be made to work, but the spec has to explain how to make
> >> it work.
> >
> >
> > Could you be a little more explicit?
>
> Indeed -- i.e. what do you (PHB) mean by "web services" ?   There's a
> plethora of things out there calling themselves "web services".
>
> thanks,
>
> =JeffH
>
>
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

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

--20cf3071cfaedfd0ee04a1a13070
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Web Services are generally understood to be machine-machine protocols runni=
ng over the &#39;Web&#39; platform.=A0<div><br></div><div>That minimally me=
ans using URIs as identifiers, DNS as the naming scheme but in the typical =
case also means layering over HTTP as transport.</div>
<div><br></div><div>There are two main camps in Web Services, SOAP and non-=
SOAP (usually referred to as REST regardless of whether it is). At this poi=
nt it seems fairly settled that both are to be called &#39;Web Services&#39=
;. There is something of an ideological divide and both sides probably have=
 a point.</div>
<div><br></div><div>SOAP is really designed to make it easy to wrap a netwo=
rk wrapper around an existing piece of infrastructure like a .COM library o=
r an SQL database. It provides little if any value for protocols like SAML =
or XKMS which are scratch built and use their own security mechanisms. Both=
 would run just as well over raw HTTP as far as I can remember.</div>
<div><br></div><div><br></div><div>I am aware of the WS-* series of specifi=
cations being an author of the original proposal and an editor of the OASIS=
 spec. They are not designed to provide security at the same layer as TLS t=
hough. TLS gives transport layer security while WS-* is message layer. So W=
S-* can deliver non-repudiation while TLS secures both the body and the hea=
ders. Both are needed.</div>
<div><br></div><div>Its the same situation with email. There are pros and c=
ons to using S/MIME and TLS and neither is really a complete substitute for=
 the other.</div><div><br></div><div>WS-* is deeply embedded in SOAP anyway=
, so it only works for some Web Services.=A0</div>
<div><br></div><div><br></div><div>The big challenge in both cases is that =
we have been lacking a model for how Web Services work out what security en=
hancements are on offer and how to apply them. In the original scheme propo=
sed by Microsoft and IBM, this was going to be the job of UDDI. But that we=
nt the way of every other &#39;replace the DNS&#39; project to date leaving=
 a hole in the Web Services architecture.=A0</div>
<div><br>Most Web Services use TLS for security today and not WS-*. But the=
 approach to doing so is pretty ad hoc and confused. There is a real opport=
unity there to clarify matters.</div><div><br></div><div><br><div class=3D"=
gmail_quote">
On Sat, Apr 23, 2011 at 2:47 PM, =3DJeffH <span dir=3D"ltr">&lt;<a href=3D"=
mailto:[email-masked]">[email-masked]</a>&gt;=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">&gt;&gt; That does not work very well for Web Services be=
cause there are typically<br>
&gt;&gt; multiple services on the same port.<br>
&gt;&gt;<br>
&gt;&gt; It can probably be made to work, but the spec has to explain how t=
o make<br>
&gt;&gt; it work.<br>
&gt;<br>
&gt;<br>
&gt; Could you be a little more explicit?<br>
<br></div>
Indeed -- i.e. what do you (PHB) mean by &quot;web services&quot; ? =A0 The=
re&#39;s a plethora of things out there calling themselves &quot;web servic=
es&quot;.<br>
<br>
thanks,<br><font color=3D"#888888">
<br>
=3DJeffH</font><div><div></div><div class=3D"h5"><br>
<br>
_______________________________________________<br>
dane mailing list<br>
<a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/dane</a><br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--20cf3071cfaedfd0ee04a1a13070--

From [email-masked]  Sun Apr 24 19:36:20 2011
From: "Richard L. Barnes" <[email-masked]>
Date: Sun, 24 Apr 2011 22:36:17 -0400
To: Phillip Hallam-Baker <[email-masked]>
Cc: IETF DANE WG list <[email-masked]>
Subject: Re: [dane] Fwd: New Version Notification for draft-ietf-dane-use-cases-01

Ok, thanks for being a little clearer.  So the question is then how all =
this translates into use cases / requirements for DANE.

It seems like to the extent that these systems are labeling service =
points with HTTPS URIs and using 2818-style authentication, the existing =
use cases cover web services as well.

Are you suggesting that clients should be able to use some sort of =
supra-HTTP-layer identifiers to look up keys/certs using DANE?  If so, =
that seems pretty different from what people have generally envisioned =
this technology to cover, namely looking up keys/certs based on domain =
names.

--Richard

On Apr 23, 2011, at 10:53 PM, Phillip Hallam-Baker wrote:

> Web Services are generally understood to be machine-machine protocols =
running over the 'Web' platform.=20
>=20
> That minimally means using URIs as identifiers, DNS as the naming =
scheme but in the typical case also means layering over HTTP as =
transport.
>=20
> There are two main camps in Web Services, SOAP and non-SOAP (usually =
referred to as REST regardless of whether it is). At this point it seems =
fairly settled that both are to be called 'Web Services'. There is =
something of an ideological divide and both sides probably have a point.
>=20
> SOAP is really designed to make it easy to wrap a network wrapper =
around an existing piece of infrastructure like a .COM library or an SQL =
database. It provides little if any value for protocols like SAML or =
XKMS which are scratch built and use their own security mechanisms. Both =
would run just as well over raw HTTP as far as I can remember.
>=20
>=20
> I am aware of the WS-* series of specifications being an author of the =
original proposal and an editor of the OASIS spec. They are not designed =
to provide security at the same layer as TLS though. TLS gives transport =
layer security while WS-* is message layer. So WS-* can deliver =
non-repudiation while TLS secures both the body and the headers. Both =
are needed.
>=20
> Its the same situation with email. There are pros and cons to using =
S/MIME and TLS and neither is really a complete substitute for the =
other.
>=20
> WS-* is deeply embedded in SOAP anyway, so it only works for some Web =
Services.=20
>=20
>=20
> The big challenge in both cases is that we have been lacking a model =
for how Web Services work out what security enhancements are on offer =
and how to apply them. In the original scheme proposed by Microsoft and =
IBM, this was going to be the job of UDDI. But that went the way of =
every other 'replace the DNS' project to date leaving a hole in the Web =
Services architecture.=20
>=20
> Most Web Services use TLS for security today and not WS-*. But the =
approach to doing so is pretty ad hoc and confused. There is a real =
opportunity there to clarify matters.
>=20
>=20
> On Sat, Apr 23, 2011 at 2:47 PM, =3DJeffH =
<[email-masked]> wrote:
> >> That does not work very well for Web Services because there are =
typically
> >> multiple services on the same port.
> >>
> >> It can probably be made to work, but the spec has to explain how to =
make
> >> it work.
> >
> >
> > Could you be a little more explicit?
>=20
> Indeed -- i.e. what do you (PHB) mean by "web services" ?   There's a =
plethora of things out there calling themselves "web services".
>=20
> thanks,
>=20
> =3DJeffH
>=20
>=20
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>=20
>=20
>=20
> --=20
> Website: http://hallambaker.com/
>=20
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

From [email-masked]  Sun Apr 24 20:30:02 2011
From: "Jim Schaad" <[email-masked]>
To: "'Richard L.Barnes'" <[email-masked]>
Date: Sun, 24 Apr 2011 20:56:05 -0700
Cc: [email-masked]
Subject: Re: [dane] Fwd: New Version Notification for	draft-ietf-dane-use-cases-01

> -----Original Message-----
> From: Richard L.Barnes [mailto:[email-masked]]
> Sent: Saturday, April 23, 2011 11:29 AM
> To: Jim Schaad
> Cc: [email-masked]
> Subject: Re: [dane] Fwd: New Version Notification for draft-ietf-dane-use-
> cases-01
> 
> Hey Jim,
> 
> Thanks for the comments.  Responses inline.
> 
> > Abstract:
> > 1.  "Traditionally, this
> >   authentication has been based on PKIX trust hierarchies, rooted in
> >   well-known CAs, but additional information can be provided via the
> >   DNS itself. "
> > I don't know that this is true based on the messages that have been
> > sent on the list.  Given the amount of apparent self-signed certs that
> > are used for TLS I don't think it can be said that this is the
> > tradition.  One might be able to say conceptually but not traditionally.
> 
> Well, I guess the self-signed case as it exists today is still PKIX, but
with very
> ad-hoc TA management.  I think the sense is probably clear enough to set
> context in the Abstract.
> 
> 
> 
> > 2.  The last sentence in this paragraph should refer to the new RFC on
> > how to do this process, since it is complicated and may depend on DNS
> > records not  mentioned above.
> 
> Are you referring to RFC 6125?  There's to that a reference in the next
> paragraph, which actually discusses the decision process.

Personal preference is to put this type of thing early or have something to
say I am expanding on this later.

> 
> > The reason for the restrict is now possibly down to Trent or Charlie.
> > Or it can be that there is a restriction to what Diane is permitted to
> > use (this is also the 3.2 example I assume.)
> >
> > The following  is not a use case?  I thought this was constantly
> > coming up on the list.
> > Alice runs the domain alice.example.com, but Diane (diane.example.com)
> > operates a TLS secured service for Alice.
> 
> So you're saying that publishing DANE records also constrains what certs
an
> outsourced service provider can use?  What's the threat here?

Yes, I would like this to happen.

If Diane is running a service for multiple people and is running it on the
same port, then no single DANE record published by Diane would correctly
state the CA restrictions that Alice wants to place on the certificates that
are to be used by Bob for contacting her.   Diane may, in the back end,
redirect the conversation from Bob based on the domain named passed in as
part of the TLS hello message and it would end up at a different server or
using different keys based on the party Bob wants to talk to.  However this
may still be all on one port.

So the situations are:
1.  Alice has the A/AAAA records in her DNS and can sign them along with the
DANE record, but Diane and Alice now need to have tight coordination if the
address and/or the DANE records change.

2.  Alice refers to Diane's DNS w/ a domain name and has no control over the
DANE, HASTLS or any other pieces under Diane's control.

3.  Alice can put DANE records into her DNS, but the address records are in
Diane's DNS.  This means that Alice can control the usage of certificates
but Diane is free to move the servers around as needed.  The only
coordination needed is when the certificates change, and then it would
depend on how the DANE record is setup (i.e. a CA or an EE certificate
pointer).

It is just as much in Alice's interest to restrict Diane from getting a
certificate from a CA that Alice does not trust as it is to not allow Bob to
validate to such a certificate if an attacker gets it into Alice's systems.

> 
> 
> > 3.2 is, I assume supposed to be a restriction on the EE certificate -
> > and thus would restrict both Bob and Diane in what they can do.
> 
> I think that going into that level of detail in this document isn't really
> necessary -- we can just say that the cert we're concerned about is "the
cert
> for the server" regardless of the specific characteristics of that cert.
But
> you're correct that the DANE record also constrains Diane.
> 

I find the term "the certificate for the server" to be sufficiently fuzzy
that I can never be too sure what it is referring to.   If I have the chain
of certs Trent->Charlie->Alice->Alice's Service.  Section 3.2 could be
talking about the cert for Alice or the cert for Alice's Service.  Both of
those certificates are presented, but if the cert for Alice is presented it
could be under section 3.1 or under section 3.2.  Also I find it hard to
believe that the security constraints are the same.  If the really are the
same then I don't understand any need to distinguish between sections 3.1
and 3.2.  I assume there is a real reason for presenting them as separate
cases, but in that case they need to be readily distinguished.

> 
> > In 3.3 - there are now two different cases that can come about.  1)
> > Alice is now running her own CA that is not well-known or trusted and
> > 2) Alice wants Bob to trust Trent (or maybe Charlie), but Bob does not
> > either by default or by policy.
> 
> Two valid cases, but they look basically the same from a technical point
of
> view: Either way, it's a TA that the rest of the world doesn't know about.
> How about a clarifying sentence at the end of the second paragraph of 3.3
(or
> possibly as a separate para):
> "
> [In dramatis personae:]
> Trent: A CA that issues certificates with domain names as identifiers, but
is
> not generally well-known.
> 
> This use case is functionally equivalent to the case where Alice doesn't
issue
> her own certificates, but uses a CA Trent that is not well-known.  In this
case,
> Alice would be advising Bob that he should treat Trent as a trust anchor
for
> purposes of validating Alice's certificates.
> "

In my mind there is a vast difference, especially in the way things should
be treated, between three different cases here:

1.  The trust anchor certificate claims to be owned by and signed by Alice
and is referenced in Alice's DNS records
2.  The trust anchor certificate is owned by Trent, who is not well known to
Bob but is vouched for by Alice in Alice's DNS record, and
3.  The trust anchor certificate is owned by Trish, who is well known to Bob
and is either explicitly not trusted or maybe even distrusted, but is
vouched for by Alice in Alice's DNS record.

The way and amount of trust that Bob might give in each of these cases is
vastly different going to - Yes I might automatically trust to I would never
trust.

> 
> 
> > Section 4 - Other Requirements
> >
> > In some cases is the statement about Encapsulation correct?  In the
> > event of an SRV or CNAME or MX record (and so forth).  Should you be
> > able to make statements about the party that is actually going to
> > provide the services if they are outsourced?
> 
> This seems like an application-layer question, and it depends on a few
things,
> such as (1) whether the outsourcing is done securely or insecurely, and
(2)
> whether the outsourcing is visible to the client (via CNAME/MX/etc) or not
> (via A/AAAA).  For example, if you get a secure SRV to a different domain,
> that seems like an explicit, secure delegation of services, in which case
the
> client is OK to authenticate the outsourcing provider directly.
> 
> All of these questions, though, relate to what name a client is looking
for.  So
> there is a clean interface to DANE:
> 1. Identify the name of the service you want to connect to (either the
> starting name or the name of the outsourcing provider) 2. Use DANE + TLS
to
> authenticate that name
> 
> (And regardless of these distinctions, the domain owner still has control
by
> choosing how to outsource, and whom to outsource to.  It's just a question
> of whether the control is in SRV or TLSA.)
> 
> Net of these concerns, I think the encapsulation requirement is still
correct.

See above.

> 
> 
> > Predictability - Given that we are making statements that we don't
> > care about cases where things like SRV records exist.  What is the
> > likelihood that protocols are going to want to change the DANE behavior
> about thinks
> > like encapsulation and which DANE record formats exist.   How are you
> > defining PKIX information in this case given that it can be defined by
> > different protocols and how the domain information is dealt with in
> > those cases is going to be treated differently.  Are you going to
> > define the DANE values as inputs to the PKIX path validation process?
> > So that they are constrained by name constraints?
> 
> In this case, we have exactly one set of PKIX information, the cert chain
in
> the TLS handshake.  DANE will address whether that cert properly
represents
> a domain; applications can choose which domain to use, and check other
> things if they want.  DANE will probably override some of RFC 6125, but
that's
> part of the idea.  These are also more questions for the mechanism draft,
> rather than use cases / requirements.
> 

I don't believe DANE addresses if a cert properly represents a domain
(depending on how you parse that language).  I believe it is addressing
issues of does a Domain represent that a certificate should be trusted for a
domain.   Overriding behavior of 6125 is not, in my mind, a way to lead to
predictability, issues of that type should be left strictly up to the
application/protocol in question.  I think that this may be a very hard
thing to produce given other issues.

> 
> > For the Wild Cards and CNAME items, does this mean we need to have a
> > BCP statement for how to fill in your DNS so that people will get it
correct?
> 
> Of course, general advice about configuring DNS properly is not the domain
> (haha) of this group, but of DNSOP.  I would think that we would have some
> provisioning advice in our documents, though, at the level of
> RECOMMENDED patterns.

However this is a security protocol, and misconfiguration is a security
issue.  As such, I believe that this is an important issue to be covered.

> 
> 
> 

From [email-masked]  Mon Apr 25 06:30:39 2011
Date: Mon, 25 Apr 2011 09:30:37 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>
Cc: IETF DANE WG list <[email-masked]>
Subject: Re: [dane] Fwd: New Version Notification for draft-ietf-dane-use-cases-01

--001636ef0ac48abf7a04a1be3640
Content-Type: text/plain; charset=ISO-8859-1

The way that I look at this problem is that key discovery is actually a
special case of the generalized service discovery problem.

This makes little difference in terms of order of operations but it has some
implications for extensibility requirements.

So when a client is trying to connect up to a Web Service the starting point
for the process is that the client knows only the domain name of the Web
Service and the protocol identifier. The client's objective is to find the
'best' connection to that Web Service according to criteria that are decided
by the client.

Amongst the criteria that would be relevant are:

* Application protocol supported
* Protocol version supported
* Security enhancements offered
* Security enhancements mandated (strict security)
* Trust assertions offered
* Redundancy
* Endpoint identifier

I don't think we want to address all of those in DANE, but I do want to have
an extensible framework that allows them to be supported. Its not that
difficult to do either. Tag-Value pairs have done just fine for SMTP and
HTTP.

Basically the difference that shows through in the architecture is how
special cases are handled. At the moment the proposal is to use prefix
records, which allows the special case 'many hosts' to be addressed.
Essentially we have taken one specific special case and made it the general
case.

A few iterations back we had a proposal where the client first looked for
the general case and only did more if it was told there was special handling
required. With a few small changes, that approach provides for a general
framework that is capable of being arbitrarily expressive.

What this comes down to is whether you see DANE as being an Application
protocol or a DNS protocol. It is a DNS record certainly, but its purpose is
to support an application protocol which is why I see the application layer
idiom of tag-value pairs as being more appropriate as a design.

On Sun, Apr 24, 2011 at 10:36 PM, Richard L. Barnes <[email-masked]> wrote:

> Ok, thanks for being a little clearer.  So the question is then how all
> this translates into use cases / requirements for DANE.
>
> It seems like to the extent that these systems are labeling service points
> with HTTPS URIs and using 2818-style authentication, the existing use cases
> cover web services as well.
>
> Are you suggesting that clients should be able to use some sort of
> supra-HTTP-layer identifiers to look up keys/certs using DANE?  If so, that
> seems pretty different from what people have generally envisioned this
> technology to cover, namely looking up keys/certs based on domain names.
>
> --Richard
>
>
>
> On Apr 23, 2011, at 10:53 PM, Phillip Hallam-Baker wrote:
>
> > Web Services are generally understood to be machine-machine protocols
> running over the 'Web' platform.
> >
> > That minimally means using URIs as identifiers, DNS as the naming scheme
> but in the typical case also means layering over HTTP as transport.
> >
> > There are two main camps in Web Services, SOAP and non-SOAP (usually
> referred to as REST regardless of whether it is). At this point it seems
> fairly settled that both are to be called 'Web Services'. There is something
> of an ideological divide and both sides probably have a point.
> >
> > SOAP is really designed to make it easy to wrap a network wrapper around
> an existing piece of infrastructure like a .COM library or an SQL database.
> It provides little if any value for protocols like SAML or XKMS which are
> scratch built and use their own security mechanisms. Both would run just as
> well over raw HTTP as far as I can remember.
> >
> >
> > I am aware of the WS-* series of specifications being an author of the
> original proposal and an editor of the OASIS spec. They are not designed to
> provide security at the same layer as TLS though. TLS gives transport layer
> security while WS-* is message layer. So WS-* can deliver non-repudiation
> while TLS secures both the body and the headers. Both are needed.
> >
> > Its the same situation with email. There are pros and cons to using
> S/MIME and TLS and neither is really a complete substitute for the other.
> >
> > WS-* is deeply embedded in SOAP anyway, so it only works for some Web
> Services.
> >
> >
> > The big challenge in both cases is that we have been lacking a model for
> how Web Services work out what security enhancements are on offer and how to
> apply them. In the original scheme proposed by Microsoft and IBM, this was
> going to be the job of UDDI. But that went the way of every other 'replace
> the DNS' project to date leaving a hole in the Web Services architecture.
> >
> > Most Web Services use TLS for security today and not WS-*. But the
> approach to doing so is pretty ad hoc and confused. There is a real
> opportunity there to clarify matters.
> >
> >
> > On Sat, Apr 23, 2011 at 2:47 PM, =JeffH <[email-masked]>
> wrote:
> > >> That does not work very well for Web Services because there are
> typically
> > >> multiple services on the same port.
> > >>
> > >> It can probably be made to work, but the spec has to explain how to
> make
> > >> it work.
> > >
> > >
> > > Could you be a little more explicit?
> >
> > Indeed -- i.e. what do you (PHB) mean by "web services" ?   There's a
> plethora of things out there calling themselves "web services".
> >
> > thanks,
> >
> > =JeffH
> >
> >
> > _______________________________________________
> > dane mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/dane
> >
> >
> >
> > --
> > Website: http://hallambaker.com/
> >
> > _______________________________________________
> > dane mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/dane
>
>

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

--001636ef0ac48abf7a04a1be3640
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

The way that I look at this problem is that key discovery is actually a spe=
cial case of the generalized service discovery problem.<div><br></div><div>=
This makes little difference in terms of order of operations but it has som=
e implications for extensibility requirements.=A0</div>
<div><br></div><div><br></div><div>So when a client is trying to connect up=
 to a Web Service the starting point for the process is that the client kno=
ws only the domain name of the Web Service and the protocol identifier. The=
 client&#39;s objective is to find the &#39;best&#39; connection to that We=
b Service according to criteria that are decided by the client.</div>
<div><br></div><div>Amongst the criteria that would be relevant are:</div><=
div><br></div><div>* Application protocol supported=A0</div><div>* Protocol=
 version supported</div><div>* Security enhancements offered</div><div>* Se=
curity enhancements mandated (strict security)</div>
<div>* Trust assertions offered</div><div>* Redundancy</div><div>* Endpoint=
 identifier<br><div><br></div><div>I don&#39;t think we want to address all=
 of those in DANE, but I do want to have an extensible framework that allow=
s them to be supported. Its not that difficult to do either. Tag-Value pair=
s have done just fine for SMTP and HTTP.=A0</div>
<div><br></div><div>Basically the difference that shows through in the arch=
itecture is how special cases are handled. At the moment the proposal is to=
 use prefix records, which allows the special case &#39;many hosts&#39; to =
be addressed. Essentially we have taken one specific special case and made =
it the general case.</div>
<div><br></div><div>A few iterations back we had a proposal where the clien=
t first looked for the general case and only did more if it was told there =
was special handling required. With a few small changes, that approach prov=
ides for a general framework that is capable of being arbitrarily expressiv=
e.</div>
<div><br></div><div><br></div><div>What this comes down to is whether you s=
ee DANE as being an Application protocol or a DNS protocol. It is a DNS rec=
ord certainly, but its purpose is to support an application protocol which =
is why I see the application layer idiom of tag-value pairs as being more a=
ppropriate as a design.</div>
<div><br><div class=3D"gmail_quote">On Sun, Apr 24, 2011 at 10:36 PM, Richa=
rd L. Barnes <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">rbarn=
[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Ok, thanks for being a little clearer. =A0So the question is then how all t=
his translates into use cases / requirements for DANE.<br>
<br>
It seems like to the extent that these systems are labeling service points =
with HTTPS URIs and using 2818-style authentication, the existing use cases=
 cover web services as well.<br>
<br>
Are you suggesting that clients should be able to use some sort of supra-HT=
TP-layer identifiers to look up keys/certs using DANE? =A0If so, that seems=
 pretty different from what people have generally envisioned this technolog=
y to cover, namely looking up keys/certs based on domain names.<br>

<font color=3D"#888888"><br>
--Richard<br>
</font><div><div></div><div class=3D"h5"><br>
<br>
<br>
On Apr 23, 2011, at 10:53 PM, Phillip Hallam-Baker wrote:<br>
<br>
&gt; Web Services are generally understood to be machine-machine protocols =
running over the &#39;Web&#39; platform.<br>
&gt;<br>
&gt; That minimally means using URIs as identifiers, DNS as the naming sche=
me but in the typical case also means layering over HTTP as transport.<br>
&gt;<br>
&gt; There are two main camps in Web Services, SOAP and non-SOAP (usually r=
eferred to as REST regardless of whether it is). At this point it seems fai=
rly settled that both are to be called &#39;Web Services&#39;. There is som=
ething of an ideological divide and both sides probably have a point.<br>

&gt;<br>
&gt; SOAP is really designed to make it easy to wrap a network wrapper arou=
nd an existing piece of infrastructure like a .COM library or an SQL databa=
se. It provides little if any value for protocols like SAML or XKMS which a=
re scratch built and use their own security mechanisms. Both would run just=
 as well over raw HTTP as far as I can remember.<br>

&gt;<br>
&gt;<br>
&gt; I am aware of the WS-* series of specifications being an author of the=
 original proposal and an editor of the OASIS spec. They are not designed t=
o provide security at the same layer as TLS though. TLS gives transport lay=
er security while WS-* is message layer. So WS-* can deliver non-repudiatio=
n while TLS secures both the body and the headers. Both are needed.<br>

&gt;<br>
&gt; Its the same situation with email. There are pros and cons to using S/=
MIME and TLS and neither is really a complete substitute for the other.<br>
&gt;<br>
&gt; WS-* is deeply embedded in SOAP anyway, so it only works for some Web =
Services.<br>
&gt;<br>
&gt;<br>
&gt; The big challenge in both cases is that we have been lacking a model f=
or how Web Services work out what security enhancements are on offer and ho=
w to apply them. In the original scheme proposed by Microsoft and IBM, this=
 was going to be the job of UDDI. But that went the way of every other &#39=
;replace the DNS&#39; project to date leaving a hole in the Web Services ar=
chitecture.<br>

&gt;<br>
&gt; Most Web Services use TLS for security today and not WS-*. But the app=
roach to doing so is pretty ad hoc and confused. There is a real opportunit=
y there to clarify matters.<br>
&gt;<br>
&gt;<br>
&gt; On Sat, Apr 23, 2011 at 2:47 PM, =3DJeffH &lt;<a href=3D"mailto:Jeff.H=
[email-masked]">[email-masked]</a>&gt; wrote:<br>
&gt; &gt;&gt; That does not work very well for Web Services because there a=
re typically<br>
&gt; &gt;&gt; multiple services on the same port.<br>
&gt; &gt;&gt;<br>
&gt; &gt;&gt; It can probably be made to work, but the spec has to explain =
how to make<br>
&gt; &gt;&gt; it work.<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; Could you be a little more explicit?<br>
&gt;<br>
&gt; Indeed -- i.e. what do you (PHB) mean by &quot;web services&quot; ? =
=A0 There&#39;s a plethora of things out there calling themselves &quot;web=
 services&quot;.<br>
&gt;<br>
&gt; thanks,<br>
&gt;<br>
&gt; =3DJeffH<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; dane mailing list<br>
&gt; <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blan=
k">https://www.ietf.org/mailman/listinfo/dane</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; Website: <a href=3D"http://hallambaker.com/" target=3D"_blank">http://=
hallambaker.com/</a><br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; dane mailing list<br>
&gt; <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/dane" target=3D"_blan=
k">https://www.ietf.org/mailman/listinfo/dane</a><br>
<br>
</div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a=
 href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div></div>

--001636ef0ac48abf7a04a1be3640--

From [email-masked]  Mon Apr 25 09:50:00 2011
Date: Mon, 25 Apr 2011 09:49:57 -0700
From: =JeffH <[email-masked]>
To: IETF DANE WG list <[email-masked]>
Subject: Re: [dane] Fwd: New Version Notification for draft-ietf-dane-use-cases-01

 > Web Services are generally understood to be machine-machine protocols
 > running over the 'Web' platform.
 >
 > That minimally means using URIs as identifiers, DNS as the naming scheme but
 > in the typical case also means layering over HTTP as transport.
 >
 > There are two main camps in Web Services, SOAP and non-SOAP (usually
 > referred to as REST regardless of whether it is). At this point it seems
 > fairly settled that both are to be called 'Web Services'. There is something
 > of an ideological divide and both sides probably have a point.

thx, that answers the question wrt the breadth of the (ambiguous) term "web 
services" when you use it.

It's even more ambiguous because there's multiple SOAP-based "web services 
stacks" and "web services architectures", not only ws-* (e.g. Liberty).

but that's off topic for this list.

=JeffH

From [email-masked]  Mon Apr 25 10:14:06 2011
Date: Mon, 25 Apr 2011 10:14:03 -0700
From: =JeffH <[email-masked]>
To: IETF DANE WG list <[email-masked]>
Subject: Re: [dane] DANE mech semantics and RFC6125 (was: Fwd: New Version Notification for draft-ietf-dane-use-cases-01)

"Jim Schaad" <[email-masked]> replied:
 >  "'Richard L.Barnes'" <[email-masked]> said
 >> In this case, we have exactly one set of PKIX information, the cert chain
 >> in the TLS handshake.  DANE will address whether that cert properly
 >> represents a domain; applications can choose which domain to use, and
 >> check other things if they want.  DANE will probably override some of RFC
 >> 6125, but that's part of the idea.  These are also more questions for the
 >> mechanism draft, rather than use cases / requirements.
 >
 > I don't believe DANE addresses if a cert properly represents a domain
 > (depending on how you parse that language).  I believe it is addressing
 > issues of does a Domain represent that a certificate should be trusted for a
 > domain. ..

I tend to agree with Jim's assessment here. To me, the draft DANE mechanism 
allows a domain administrator, of a particular domain name, to assert that one 
must receive certs certified by a particular CA, or particular certs, during 
TLS establishment with the end entity host whose network address is obtained by 
dereferencing that particular domain name.

 > ..  Overriding behavior of 6125 is not, in my mind, a way to lead to
 > predictability, issues of that type should be left strictly up to the
 > application/protocol in question. ...

agreed in the sense that RFC6125 is strictly about *application layer dns 
domain name matching* in the context of PKIX certs and TLS establishment. IMHO, 
it prescribes matching/checking that an app service client implementation 
really should perform, whether or not the DANE mechanism is employed and 
successfully verifies during the TLS handshake.

If there's anything anyone sees in RFC6125 that is in conflict with the above 
assessment, please explicitly identify it.

thanks,

=JeffH

From [email-masked]  Mon Apr 25 15:18:22 2011
From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 25 Apr 2011 18:18:12 -0400
To: =JeffH <[email-masked]>
Cc: IETF DANE WG list <[email-masked]>
Subject: Re: [dane] DANE mech semantics and RFC6125 (was: Fwd: New Version Notification for draft-ietf-dane-use-cases-01)

> > I don't believe DANE addresses if a cert properly represents a =
domain
> > (depending on how you parse that language).  I believe it is =
addressing
> > issues of does a Domain represent that a certificate should be =
trusted for a
> > domain. ..
>=20
> I tend to agree with Jim's assessment here. To me, the draft DANE =
mechanism allows a domain administrator, of a particular domain name, to =
assert that one must receive certs certified by a particular CA, or =
particular certs, during TLS establishment with the end entity host =
whose network address is obtained by dereferencing that particular =
domain name.

This seems like mostly an issue of wording to me.  Care to suggest =
something?

> > ..  Overriding behavior of 6125 is not, in my mind, a way to lead to
> > predictability, issues of that type should be left strictly up to =
the
> > application/protocol in question. ...
>=20
> agreed in the sense that RFC6125 is strictly about *application layer =
dns domain name matching* in the context of PKIX certs and TLS =
establishment. IMHO, it prescribes matching/checking that an app service =
client implementation really should perform, whether or not the DANE =
mechanism is employed and successfully verifies during the TLS =
handshake.
>=20
> If there's anything anyone sees in RFC6125 that is in conflict with =
the above assessment, please explicitly identify it.

Fair enough.  Perhaps a better way to say it is that DANE is an =
independent check to RFC 6125, which applications / clients can choose =
to take or leave.  Sort of like the various checks that mail servers =
apply to vet other MTAs that send them mail.  Is there a text impact =
here?

--Richard

From [email-masked]  Mon Apr 25 20:18:32 2011
From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 25 Apr 2011 23:18:25 -0400
To: =JeffH <[email-masked]>
Cc: IETF DANE WG list <[email-masked]>
Subject: Re: [dane] Fwd: New Version Notification for draft-ietf-dane-use-cases-01

> > Web Services are generally understood to be machine-machine =
protocols
> > running over the 'Web' platform.
> >
> > That minimally means using URIs as identifiers, DNS as the naming =
scheme but
> > in the typical case also means layering over HTTP as transport.
> >
> > There are two main camps in Web Services, SOAP and non-SOAP (usually
> > referred to as REST regardless of whether it is). At this point it =
seems
> > fairly settled that both are to be called 'Web Services'. There is =
something
> > of an ideological divide and both sides probably have a point.
>=20
> thx, that answers the question wrt the breadth of the (ambiguous) term =
"web services" when you use it.
>=20
> It's even more ambiguous because there's multiple SOAP-based "web =
services stacks" and "web services architectures", not only ws-* (e.g. =
Liberty).

Thanks to both of you for making this a little more concrete.

As I said before, it seems like the document already supports these =
services to the extent that they use URIs as identifiers and DNS as a =
naming scheme.  If there's a further authentication (e.g., of individual =
SOAP message handlers?) that you think should also be supported, could =
you please write a 1-2 paragraph use case?

Thanks,
--Richard=

From [email-masked]  Mon Apr 25 21:17:04 2011
From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 26 Apr 2011 00:17:00 -0400
To: Jim Schaad <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] Fwd: New Version Notification for	draft-ietf-dane-use-cases-01

>>> 2.  The last sentence in this paragraph should refer to the new RFC =
on
>>> how to do this process, since it is complicated and may depend on =
DNS
>>> records not  mentioned above.
>>=20
>> Are you referring to RFC 6125?  There's to that a reference in the =
next
>> paragraph, which actually discusses the decision process.
>=20
> Personal preference is to put this type of thing early or have =
something to
> say I am expanding on this later.

Think I'm going to leave this as-is.  The difference is only from one =
sentence to the next.

>>> The reason for the restrict is now possibly down to Trent or =
Charlie.
>>> Or it can be that there is a restriction to what Diane is permitted =
to
>>> use (this is also the 3.2 example I assume.)
>>>=20
>>> The following  is not a use case?  I thought this was constantly
>>> coming up on the list.
>>> Alice runs the domain alice.example.com, but Diane =
(diane.example.com)
>>> operates a TLS secured service for Alice.
>>=20
>> So you're saying that publishing DANE records also constrains what =
certs
> an
>> outsourced service provider can use?  What's the threat here?
>=20
> Yes, I would like this to happen.
>=20
> If Diane is running a service for multiple people and is running it on =
the
> same port, then no single DANE record published by Diane would =
correctly
> state the CA restrictions that Alice wants to place on the =
certificates that
> are to be used by Bob for contacting her.   Diane may, in the back =
end,
> redirect the conversation from Bob based on the domain named passed in =
as
> part of the TLS hello message and it would end up at a different =
server or
> using different keys based on the party Bob wants to talk to.  However =
this
> may still be all on one port.
>=20
> So the situations are:
> 1.  Alice has the A/AAAA records in her DNS and can sign them along =
with the
> DANE record, but Diane and Alice now need to have tight coordination =
if the
> address and/or the DANE records change.
>=20
> 2.  Alice refers to Diane's DNS w/ a domain name and has no control =
over the
> DANE, HASTLS or any other pieces under Diane's control.
>=20
> 3.  Alice can put DANE records into her DNS, but the address records =
are in
> Diane's DNS.  This means that Alice can control the usage of =
certificates
> but Diane is free to move the servers around as needed.  The only
> coordination needed is when the certificates change, and then it would
> depend on how the DANE record is setup (i.e. a CA or an EE certificate
> pointer).
>=20
> It is just as much in Alice's interest to restrict Diane from getting =
a
> certificate from a CA that Alice does not trust as it is to not allow =
Bob to
> validate to such a certificate if an attacker gets it into Alice's =
systems.

OK, I think I get this.  The idea is that the owner of the domain might =
use DANE to constrain not only what certificates CAs can issue (and =
still be accepted by clients), but also what certificates outsourcing =
providers can use.

It doesn't seem like this is a fully independent use case, since at base =
what's happening is that Alice is making assertions about her domain.  =
I've added the following text to Sections 3, 3.1, 3.2
"
Oscar: An outsourcing provider that operates TLS-protected services on =
behalf of customers.
...
In addition to guarding against CA mis-issue, CA constraints can also be =
used to constrain the set of certificates that can be used by an =
outsourcing provider.  Suppose that Oscar operates alice.example.com on =
behalf of Alice.  In particular, Oscar then has de facto control over =
what certificates to present in TLS handshakes for alice.example.com.  =
Alice can use the same mechanism for advising about CA constraints to =
advise Bob that Oscar should present a certificate under a given CA.
...
As in Section 3.1., Alice's assertions about server certificates can be =
used to constrain the behavior of an outsourcing provider Oscar as well =
as the CA Charlie and other CAs.  Such a certificate constraint requires =
Oscar to present the specified certificate to clients and not another.
"

The specific provisioning cases are valuable, but probably better suited =
for the mechanism document.

> I find the term "the certificate for the server" to be sufficiently =
fuzzy
> that I can never be too sure what it is referring to.   If I have the =
chain
> of certs Trent->Charlie->Alice->Alice's Service.  Section 3.2 could be
> talking about the cert for Alice or the cert for Alice's Service.  =
Both of
> those certificates are presented, but if the cert for Alice is =
presented it
> could be under section 3.1 or under section 3.2.  Also I find it hard =
to
> believe that the security constraints are the same.  If the really are =
the
> same then I don't understand any need to distinguish between sections =
3.1
> and 3.2.  I assume there is a real reason for presenting them as =
separate
> cases, but in that case they need to be readily distinguished.

Actually, I thought the term "certificate for the server" was one of the =
more concrete terms in the document -- it's the one with the public key =
that Bob uses to compute the PreMasterSecret in TLS.  In RFC 5246 terms, =
it's the first cert in the certificate_list payload:
"
   certificate_list
      This is a sequence (chain) of certificates.  The sender's
      certificate MUST come first in the list.  Each following
      certificate MUST directly certify the one preceding it.  Because
      certificate validation requires that root keys be distributed
      independently, the self-signed certificate that specifies the root
      certificate authority MAY be omitted from the chain, under the
      assumption that the remote end must already possess it in order to
      validate it in any case.
"

I was trying to avoid saying "EE cert", because that explicitly places a =
constraint on the form of the certificate beyond what TLS says (which =
puts it beyond this WG's remit). Instead, the intent of 3.1 and 3.2 is =
to say:

3.1. The indicated cert MUST appear in the certificate_list
3.2. The indicated cert MUST be the first in the certificate_list

I'll try to be a little more explicit about this:
"
In TLS terms, Alice is letting Bob know that Charlie's certificate must =
appear somewhere in the server Certificate message certificate_list =
structure.
...
In TLS terms, Alice is letting Bob know that her certificate must appear =
as the first certificate in the server Certificate message.
"

The security concerns are different, as discussed in the use case: 3.1. =
addresses other CAs, while 3.2. addresses Charlie.  The other concerns, =
namely the way that this changes the balance of power between the DNS =
operator and the CA, are the same between the two cases.  I've changed =
the text in 3.2. to say "The other security considerations..."

> In my mind there is a vast difference, especially in the way things =
should
> be treated, between three different cases here:
>=20
> 1.  The trust anchor certificate claims to be owned by and signed by =
Alice
> and is referenced in Alice's DNS records
> 2.  The trust anchor certificate is owned by Trent, who is not well =
known to
> Bob but is vouched for by Alice in Alice's DNS record, and
> 3.  The trust anchor certificate is owned by Trish, who is well known =
to Bob
> and is either explicitly not trusted or maybe even distrusted, but is
> vouched for by Alice in Alice's DNS record.
>=20
> The way and amount of trust that Bob might give in each of these cases =
is
> vastly different going to - Yes I might automatically trust to I would =
never
> trust.

As with PKIX certificates, it's always up to Bob to decide who he =
trusts.  All DANE is doing is letting Alice assert who she thinks should =
be trusted.  Ignoring Bob, cases 2 and 3 are the same.

Nonetheless, this might be a good comment for the mechanism document, =
which might note that a relying party MAY apply additional criteria =
beyond DANE to decide whether or not to accept a DANE-asserted TA.  For =
example, checking against a white- or black-list as you suggest.

> I don't believe DANE addresses if a cert properly represents a domain
> (depending on how you parse that language).  I believe it is =
addressing
> issues of does a Domain represent that a certificate should be trusted =
for a
> domain.   Overriding behavior of 6125 is not, in my mind, a way to =
lead to
> predictability, issues of that type should be left strictly up to the
> application/protocol in question.  I think that this may be a very =
hard
> thing to produce given other issues.

See my responses to =3DJeffH. =20

Summary:
1. Glad to change wording.
2. "Override" is the wrong word; these are independent checks/assertions =
from 6125 and apps can decide how to composite them.

>> Of course, general advice about configuring DNS properly is not the =
domain
>> (haha) of this group, but of DNSOP.  I would think that we would have =
some
>> provisioning advice in our documents, though, at the level of
>> RECOMMENDED patterns.
>=20
> However this is a security protocol, and misconfiguration is a =
security
> issue.  As such, I believe that this is an important issue to be =
covered.

Definitely agree.  But I see this more as a mechanism / implementation =
issue than a use case / requirements issue. =20

From [email-masked]  Tue Apr 26 20:44:20 2011
From: "Jim Schaad" <[email-masked]>
To: "'Richard L. Barnes'" <[email-masked]>
Date: Tue, 26 Apr 2011 21:10:28 -0700
Cc: [email-masked]
Subject: Re: [dane] Fwd: New Version Notification for	draft-ietf-dane-use-cases-01

> -----Original Message-----
> From: Richard L. Barnes [mailto:[email-masked]]
> Sent: Monday, April 25, 2011 9:17 PM
> To: Jim Schaad
> Cc: [email-masked]
> Subject: Re: [dane] Fwd: New Version Notification for draft-ietf-dane-use-
> cases-01
> 
> >>> 2.  The last sentence in this paragraph should refer to the new RFC
> >>> on how to do this process, since it is complicated and may depend on
> >>> DNS records not  mentioned above.
> >>
> >> Are you referring to RFC 6125?  There's to that a reference in the
> >> next paragraph, which actually discusses the decision process.
> >
> > Personal preference is to put this type of thing early or have
> > something to say I am expanding on this later.
> 
> Think I'm going to leave this as-is.  The difference is only from one
sentence
> to the next.
> 
> 
> >>> The reason for the restrict is now possibly down to Trent or Charlie.
> >>> Or it can be that there is a restriction to what Diane is permitted
> >>> to use (this is also the 3.2 example I assume.)
> >>>
> >>> The following  is not a use case?  I thought this was constantly
> >>> coming up on the list.
> >>> Alice runs the domain alice.example.com, but Diane
> >>> (diane.example.com) operates a TLS secured service for Alice.
> >>
> >> So you're saying that publishing DANE records also constrains what
> >> certs
> > an
> >> outsourced service provider can use?  What's the threat here?
> >
> > Yes, I would like this to happen.
> >
> > If Diane is running a service for multiple people and is running it on
> > the same port, then no single DANE record published by Diane would
> > correctly state the CA restrictions that Alice wants to place on the
> certificates that
> > are to be used by Bob for contacting her.   Diane may, in the back end,
> > redirect the conversation from Bob based on the domain named passed in
> > as part of the TLS hello message and it would end up at a different
> > server or using different keys based on the party Bob wants to talk
> > to.  However this may still be all on one port.
> >
> > So the situations are:
> > 1.  Alice has the A/AAAA records in her DNS and can sign them along
> > with the DANE record, but Diane and Alice now need to have tight
> > coordination if the address and/or the DANE records change.
> >
> > 2.  Alice refers to Diane's DNS w/ a domain name and has no control
> > over the DANE, HASTLS or any other pieces under Diane's control.
> >
> > 3.  Alice can put DANE records into her DNS, but the address records
> > are in Diane's DNS.  This means that Alice can control the usage of
> > certificates but Diane is free to move the servers around as needed.
> > The only coordination needed is when the certificates change, and then
> > it would depend on how the DANE record is setup (i.e. a CA or an EE
> > certificate pointer).
> >
> > It is just as much in Alice's interest to restrict Diane from getting
> > a certificate from a CA that Alice does not trust as it is to not
> > allow Bob to validate to such a certificate if an attacker gets it into
Alice's
> systems.
> 
> OK, I think I get this.  The idea is that the owner of the domain might
use
> DANE to constrain not only what certificates CAs can issue (and still be
> accepted by clients), but also what certificates outsourcing providers can
use.
> 
> It doesn't seem like this is a fully independent use case, since at base
what's
> happening is that Alice is making assertions about her domain.  I've added
> the following text to Sections 3, 3.1, 3.2 "
> Oscar: An outsourcing provider that operates TLS-protected services on
> behalf of customers.
> ...
> In addition to guarding against CA mis-issue, CA constraints can also be
used
> to constrain the set of certificates that can be used by an outsourcing
> provider.  Suppose that Oscar operates alice.example.com on behalf of
Alice.
> In particular, Oscar then has de facto control over what certificates to
present
> in TLS handshakes for alice.example.com.  Alice can use the same mechanism
> for advising about CA constraints to advise Bob that Oscar should present
a
> certificate under a given CA.
> ...
> As in Section 3.1., Alice's assertions about server certificates can be
used to
> constrain the behavior of an outsourcing provider Oscar as well as the CA
> Charlie and other CAs.  Such a certificate constraint requires Oscar to
present
> the specified certificate to clients and not another.
> "
> 
> The specific provisioning cases are valuable, but probably better suited
for
> the mechanism document.
> 

I would like to disagree.  I think that I have presented many interesting
and useful, for the purposes of discussion, cases that, while variations on
a theme, are important things that need to be considered in how the other
documents progress.  One could just as easily say - oh no they belong in the
implementation guidelines document.   But in any case of all of these
nuances are not captured here then we can basically say that all of them are
unimportant as only those which would be implemented by the main document
could ever be covered.  I.e. I don't expect it to say what it cannot due in
cases where it was not told that it needed to do it.

> 
> 
> 
> > I find the term "the certificate for the server" to be sufficiently
fuzzy
> > that I can never be too sure what it is referring to.   If I have the
chain
> > of certs Trent->Charlie->Alice->Alice's Service.  Section 3.2 could be
> > talking about the cert for Alice or the cert for Alice's Service.
> > Both of those certificates are presented, but if the cert for Alice is
> > presented it could be under section 3.1 or under section 3.2.  Also I
> > find it hard to believe that the security constraints are the same.
> > If the really are the same then I don't understand any need to
> > distinguish between sections 3.1 and 3.2.  I assume there is a real
> > reason for presenting them as separate cases, but in that case they need
to
> be readily distinguished.
> 
> Actually, I thought the term "certificate for the server" was one of the
more
> concrete terms in the document -- it's the one with the public key that
Bob
> uses to compute the PreMasterSecret in TLS.  In RFC 5246 terms, it's the
first
> cert in the certificate_list payload:
> "

A much better term would be "certificate for the service" as the server may
have multiple certificates for different services and a single service could
have the same public key used by multiple servers.

>    certificate_list
>       This is a sequence (chain) of certificates.  The sender's
>       certificate MUST come first in the list.  Each following
>       certificate MUST directly certify the one preceding it.  Because
>       certificate validation requires that root keys be distributed
>       independently, the self-signed certificate that specifies the root
>       certificate authority MAY be omitted from the chain, under the
>       assumption that the remote end must already possess it in order to
>       validate it in any case.
> "
> 
> I was trying to avoid saying "EE cert", because that explicitly places a
> constraint on the form of the certificate beyond what TLS says (which puts
it
> beyond this WG's remit). Instead, the intent of 3.1 and 3.2 is to say:
> 
> 3.1. The indicated cert MUST appear in the certificate_list 3.2. The
indicated
> cert MUST be the first in the certificate_list
> 
> I'll try to be a little more explicit about this:
> "
> In TLS terms, Alice is letting Bob know that Charlie's certificate must
appear
> somewhere in the server Certificate message certificate_list structure.
> ...
> In TLS terms, Alice is letting Bob know that her certificate must appear
as the
> first certificate in the server Certificate message.
> "
> 
> The security concerns are different, as discussed in the use case: 3.1.
> addresses other CAs, while 3.2. addresses Charlie.  The other concerns,
> namely the way that this changes the balance of power between the DNS
> operator and the CA, are the same between the two cases.  I've changed the
> text in 3.2. to say "The other security considerations..."
> 

See above suggested text change - talking about the service certificate
rather than the server certificate makes it clear what certificate is being
discussed.

> 
> 
> > In my mind there is a vast difference, especially in the way things
> > should be treated, between three different cases here:
> >
> > 1.  The trust anchor certificate claims to be owned by and signed by
> > Alice and is referenced in Alice's DNS records 2.  The trust anchor
> > certificate is owned by Trent, who is not well known to Bob but is
> > vouched for by Alice in Alice's DNS record, and 3.  The trust anchor
> > certificate is owned by Trish, who is well known to Bob and is either
> > explicitly not trusted or maybe even distrusted, but is vouched for by
> > Alice in Alice's DNS record.
> >
> > The way and amount of trust that Bob might give in each of these cases
> > is vastly different going to - Yes I might automatically trust to I
> > would never trust.
> 
> As with PKIX certificates, it's always up to Bob to decide who he trusts.
All
> DANE is doing is letting Alice assert who she thinks should be trusted.
> Ignoring Bob, cases 2 and 3 are the same.
> 
> Nonetheless, this might be a good comment for the mechanism document,
> which might note that a relying party MAY apply additional criteria beyond
> DANE to decide whether or not to accept a DANE-asserted TA.  For example,
> checking against a white- or black-list as you suggest.
> 

And is also good to have in this document.  It may be that the main DANE
documents will choose to ignore this case as they currently do not discuss
many of these types of issues.  They are left up to the protocol or
implementation.

> 
> > I don't believe DANE addresses if a cert properly represents a domain
> > (depending on how you parse that language).  I believe it is
> > addressing issues of does a Domain represent that a certificate should
be
> trusted for a
> > domain.   Overriding behavior of 6125 is not, in my mind, a way to lead
to
> > predictability, issues of that type should be left strictly up to the
> > application/protocol in question.  I think that this may be a very
> > hard thing to produce given other issues.
> 
> See my responses to =JeffH.
> 
> Summary:
> 1. Glad to change wording.
> 2. "Override" is the wrong word; these are independent checks/assertions
> from 6125 and apps can decide how to composite them.
> 
> 
> >> Of course, general advice about configuring DNS properly is not the
> >> domain
> >> (haha) of this group, but of DNSOP.  I would think that we would have
> >> some provisioning advice in our documents, though, at the level of
> >> RECOMMENDED patterns.
> >
> > However this is a security protocol, and misconfiguration is a
> > security issue.  As such, I believe that this is an important issue to
be
> covered.
> 
> Definitely agree.  But I see this more as a mechanism / implementation
issue
> than a use case / requirements issue.

I needed to go back and figure out what this was in response to.  I believe
that this is a valid topic to be addressed in the security considerations
section.

jim

From [email-masked]  Wed Apr 27 11:25:17 2011
Date: Wed, 27 Apr 2011 14:25:14 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: [email-masked]
Subject: [dane] Requested Use Cases

--0016e644cf92d632ef04a1ea8f82
Content-Type: text/plain; charset=ISO-8859-1

OK here are the additional use cases for Web Services and for motivating
promiscuous security.

Use Case: Promiscuous Security in Web Browsing

Alice wishes to publish her Web site so that Bob will always have the
benefit of the best security his client is capable of without resulting in a
negative user experience when using a legacy browser. In particular Bob uses
two browsers on different machines, one is a legacy browser that does not
support DANE and cannot be updated, the other is a browser that has full
support for DANE.

Derived requirement: An enabled client must be able to determine that DANE
security is available for a site.

Use Case: DNS Driven Web Services

A Web Service is an Internet protocol designed to support direct
machine-to-machine communication without the intervention of a human
operator or other form of supervisor. Since Web Services are application
protocols, the one aspect of Internet architecture that is essential as far
as a Web Service is concerned is that the DNS be used as the naming system
for service discovery.

Web Services typically evolve over time. A service provider must frequently
support legacy clients alongside new and in many cases multiple versions of
each protocol.

Discovering the certificates or keys to be used to secure the connection to
the Web service represents merely one aspect of the more general problem of
Web Service property discovery.

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

--0016e644cf92d632ef04a1ea8f82
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

OK here are the additional use cases for Web Services and for motivating pr=
omiscuous security.<div><br></div><div><br></div><div>Use Case: Promiscuous=
 Security in Web Browsing</div><div><br></div><div>Alice wishes to publish =
her Web site so that Bob will always have the benefit of the best security =
his client is capable of without resulting in a negative user experience wh=
en using a legacy browser. In particular Bob uses two browsers on different=
 machines, one is a legacy browser that does not support DANE and cannot be=
 updated, the other is a browser that has full support for DANE.</div>
<div><br></div><div>Derived requirement: An enabled client must be able to =
determine that DANE security is available for a site.</div><div><br></div><=
div><br></div><div>Use Case: DNS Driven Web Services</div><div><br></div>
<div>A Web Service is an Internet protocol designed to support direct machi=
ne-to-machine communication without the intervention of a human operator or=
 other form of supervisor. Since Web Services are application protocols, th=
e one aspect of Internet architecture that is essential as far as a Web Ser=
vice is concerned is that the DNS be used as the naming system for service =
discovery.</div>
<div><br></div><div>Web Services typically evolve over time. A service prov=
ider must frequently support legacy clients alongside new and in many cases=
 multiple versions of each protocol.</div><div><br></div><div>Discovering t=
he certificates or keys to be used to secure the connection to the Web serv=
ice represents merely one aspect of the more general problem of Web Service=
 property discovery.</div>
<div><br></div><div><br>-- <br>Website: <a href=3D"http://hallambaker.com/"=
>http://hallambaker.com/</a><br><br>
</div>

--0016e644cf92d632ef04a1ea8f82--

From [email-masked]  Wed Apr 27 21:31:15 2011
From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 28 Apr 2011 00:31:11 -0400
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] Requested Use Cases

Thanks, these are good.  I'll get them added.
--Richard

On Apr 27, 2011, at 2:25 PM, Phillip Hallam-Baker wrote:

> OK here are the additional use cases for Web Services and for =
motivating promiscuous security.
>=20
>=20
> Use Case: Promiscuous Security in Web Browsing
>=20
> Alice wishes to publish her Web site so that Bob will always have the =
benefit of the best security his client is capable of without resulting =
in a negative user experience when using a legacy browser. In particular =
Bob uses two browsers on different machines, one is a legacy browser =
that does not support DANE and cannot be updated, the other is a browser =
that has full support for DANE.
>=20
> Derived requirement: An enabled client must be able to determine that =
DANE security is available for a site.
>=20
>=20
> Use Case: DNS Driven Web Services
>=20
> A Web Service is an Internet protocol designed to support direct =
machine-to-machine communication without the intervention of a human =
operator or other form of supervisor. Since Web Services are application =
protocols, the one aspect of Internet architecture that is essential as =
far as a Web Service is concerned is that the DNS be used as the naming =
system for service discovery.
>=20
> Web Services typically evolve over time. A service provider must =
frequently support legacy clients alongside new and in many cases =
multiple versions of each protocol.
>=20
> Discovering the certificates or keys to be used to secure the =
connection to the Web service represents merely one aspect of the more =
general problem of Web Service property discovery.
>=20
>=20
> --=20
> Website: http://hallambaker.com/
>=20
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

From [email-masked]  Wed Apr 27 21:43:26 2011
From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 28 Apr 2011 00:43:24 -0400
To: Jim Schaad <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] Fwd: New Version Notification for	draft-ietf-dane-use-cases-01

> I would like to disagree.  I think that I have presented many =
interesting
> and useful, for the purposes of discussion, cases that, while =
variations on
> a theme, are important things that need to be considered in how the =
other
> documents progress.  One could just as easily say - oh no they belong =
in the
> implementation guidelines document.   But in any case of all of these
> nuances are not captured here then we can basically say that all of =
them are
> unimportant as only those which would be implemented by the main =
document
> could ever be covered.  I.e. I don't expect it to say what it cannot =
due in
> cases where it was not told that it needed to do it.

Ok, fair enough.  I'll pull this stuff into an independent use case.  =
I'll send you some proposed text off-list to avoid thread bloat.

> A much better term would be "certificate for the service" as the =
server may
> have multiple certificates for different services and a single service =
could
> have the same public key used by multiple servers.

The term "server" is well-defined in TLS, in that TLS is a client-server =
protocol.  So a server in TLS is actually what you're calling a service.

I've added a note to the Terminology section to clarify:
"
Note in particular that the term "server" in this document refers to the =
server role in TLS, rather than to a physical server.  Multiple servers =
of this type may be co-located on a single physical server, using =
different ports, and each of these can use different certificates.
"

>> As with PKIX certificates, it's always up to Bob to decide who he =
trusts.
> All
>> DANE is doing is letting Alice assert who she thinks should be =
trusted.
>> Ignoring Bob, cases 2 and 3 are the same.
>>=20
>> Nonetheless, this might be a good comment for the mechanism document,
>> which might note that a relying party MAY apply additional criteria =
beyond
>> DANE to decide whether or not to accept a DANE-asserted TA.  For =
example,
>> checking against a white- or black-list as you suggest.
>>=20
>=20
> And is also good to have in this document.  It may be that the main =
DANE
> documents will choose to ignore this case as they currently do not =
discuss
> many of these types of issues.  They are left up to the protocol or
> implementation.

Suggested additional text for 3.3:
"
Alice's advertising of trust anchor material in this way does not =
guarantee that Bob will accept the advertised trust anchor.  For =
example, Bob might have out-of-band information (such as a pre-existing =
local policy) that indicates that the CA Trent advertised by Alice is =
not trustworthy, which would lead him to decide not to accept Trent as a =
TA, and thus to reject Alice's certificate if it is issued under Trent. =20=

"

From [email-masked]  Thu Apr 28 10:22:45 2011
From: Warren Kumari <[email-masked]>
Date: Thu, 28 Apr 2011 13:22:40 -0400
To: Richard L. Barnes <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt

Hi all,

It has now been just over a week since this came out (but it fells much =
much longer) and it has generated a large amount of traffic and =
comments. That said, it feels to me like we have covered the largest =
issues and are moving towards having some consensus...

So, I would like us to start wrapping up the discussions soon so that we =
(well, Richard :-P) can get -02 out, we can review it to make sure that =
folk are happy and have been heard, and then move to WGLC.

Please note: I'm not trying to censor / limit anyone, but rather trying =
to avoid us moving into the pontificating and navel gazing stage...=20

W

On Apr 20, 2011, at 2:39 PM, Richard L. Barnes wrote:

> This document is an attempt to capture
> (1) A brief problem statement,
> (2) The three main use cases discussed on the list, and
> (3) A few additional requirements =20
>=20
> Thanks especially to Eric, Zack, and Phil, from whom most of the =
underlying material is drawn.
>=20
> Comments are welcome.
>=20
> --Richard=20
>=20
>=20
> On Apr 20, 2011, at 2:30 PM, [email-masked] wrote:
>=20
>> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
>> This draft is a work item of the DNS-based Authentication of Named =
Entities Working Group of the IETF.
>>=20
>>=20
>> 	Title           : Use Cases and Requirements for DNS-based =
Authentication of Named Entities
>> 	Author(s)       : R. Barnes
>> 	Filename        : draft-ietf-dane-use-cases-00.txt
>> 	Pages           : 8
>> 	Date            : 2011-04-20
>>=20
>> Many current applications use the certificate-based authentication
>> features in TLS to allow clients to verify that a connected server
>> properly represents a desired domain name.  Traditionally, this
>> authentication has been based on PKIX trust hierarchies, rooted in
>> well-known CAs, but additional information can be provided via the
>> DNS itself.  This document describes a set of use cases in which the
>> DNS and DNSSEC could be used to make assertions that support the TLS
>> authentication process.
>>=20
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-dane-use-cases-00.txt
>>=20
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>=20
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>> <Mail Attachment>_______________________________________________
>> dane mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dane
>=20
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>=20

From [email-masked]  Thu Apr 28 11:08:32 2011
Date: Thu, 28 Apr 2011 11:08:30 -0700
From: =JeffH <[email-masked]>
To: IETF DANE WG list <[email-masked]>
Subject: Re: [dane] Fwd: New Version Notification for draft-ietf-dane-use-cases-01

 >> A much better term would be "certificate for the service" as the server
 >> may have multiple certificates for different services and a single
 >> service could have the same public key used by multiple servers.
 >
 > The term "server" is well-defined in TLS, in that TLS is a client-server
 > protocol.  So a server in TLS is actually what you're calling a service.
 >
 > I've added a note to the Terminology section to clarify: " Note in
 > particular that the term "server" in this document refers to the server
 > role in TLS, rather than to a physical server.  Multiple servers of this
 > type may be co-located on a single physical server, using different ports,
 > and each of these can use different certificates. "

Good, I was about to suggest this.

Also, we might want/need to define "single physical server" as a "host", but
can wait to see.

thanks,

=JeffH

From [email-masked]  Thu Apr 28 11:08:57 2011
Date: Thu, 28 Apr 2011 11:08:56 -0700
From: =JeffH <[email-masked]>
To: IETF DANE WG list <[email-masked]>
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt

 > I would like us to start wrapping up the discussions soon so that we (well,
 > Richard :-P) can get -02 out, we can review it to make sure that folk are
 > happy and have been heard, and then move to WGLC.

I will do a detailed review & feedback of the use cases doc, but am thinking I 
ought to do it on a -02 that incorps the settled feedback-so-far.

=JeffH

From [email-masked]  Thu Apr 28 12:14:55 2011
From: Warren Kumari <[email-masked]>
Date: Thu, 28 Apr 2011 15:14:53 -0400
To: =JeffH <[email-masked]>
Cc: IETF DANE WG list <[email-masked]>
Subject: Re: [dane] I-D Action:draft-ietf-dane-use-cases-00.txt

On Apr 28, 2011, at 2:08 PM, =3DJeffH wrote:

> > I would like us to start wrapping up the discussions soon so that we =
(well,
> > Richard :-P) can get -02 out, we can review it to make sure that =
folk are
> > happy and have been heard, and then move to WGLC.
>=20
> I will do a detailed review & feedback of the use cases doc, but am =
thinking I ought to do it on a -02 that incorps the settled =
feedback-so-far.

Ok, I believe that Richard will submit -02 tonight / tomorrow, =
incorporating comments received so far, and then we will kick off WGLC.

W

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

From [email-masked]  Thu Apr 28 16:16:35 2011
From: Martin Rex <[email-masked]>
To: [email-masked] (=JeffH)
Date: Fri, 29 Apr 2011 01:16:27 +0200 (MEST)
Cc: [email-masked]
Subject: Re: [dane] Fwd: New Version Notification for
Reply-To: [email-masked]

=JeffH wrote:
> 
>  >> A much better term would be "certificate for the service" as the server
>  >> may have multiple certificates for different services and a single
>  >> service could have the same public key used by multiple servers.
>  >
>  > The term "server" is well-defined in TLS, in that TLS is a client-server
>  > protocol.  So a server in TLS is actually what you're calling a service.
>  >
>  > I've added a note to the Terminology section to clarify: " Note in
>  > particular that the term "server" in this document refers to the server
>  > role in TLS, rather than to a physical server.  Multiple servers of this
>  > type may be co-located on a single physical server, using different ports,
>  > and each of these can use different certificates. "
> 
> Good, I was about to suggest this.
> 
> Also, we might want/need to define "single physical server" as a "host", but
> can wait to see.

I assume he meant that there could be many (virtual) host(names) all
pointing to the same physical server.  In order to support virtual
hosting with TLS, you either need TLS server certs with lots of
subjectAltNames, or support (and use) of the TLS extension
"server name indication" (SNI) by both, TLS client and TLS server.

"host" / "hostname" is an abstract logical/virtual concept of an entity,
and in general needs to be carefully distinguished from real servers.

-Martin

From [email-masked]  Thu Apr 28 20:51:34 2011
From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 28 Apr 2011 23:51:22 -0400
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dane] Fwd: New Version Notification for

>>> I've added a note to the Terminology section to clarify: " Note in
>>> particular that the term "server" in this document refers to the =
server
>>> role in TLS, rather than to a physical server.  Multiple servers of =
this
>>> type may be co-located on a single physical server, using different =
ports,
>>> and each of these can use different certificates. "
>>=20
>> Good, I was about to suggest this.
>>=20
>> Also, we might want/need to define "single physical server" as a =
"host", but
>> can wait to see.
>=20
> I assume he meant that there could be many (virtual) host(names) all
> pointing to the same physical server.  In order to support virtual
> hosting with TLS, you either need TLS server certs with lots of
> subjectAltNames, or support (and use) of the TLS extension
> "server name indication" (SNI) by both, TLS client and TLS server.
>=20
> "host" / "hostname" is an abstract logical/virtual concept of an =
entity,
> and in general needs to be carefully distinguished from real servers.

No, I actually meant what I wrote: Separate servers on separate ports.  =
Like, say, an SMTP server, an IMAP server, an XMPP server, and an HTTPS =
server.

It's not really this group's job to deal with distinguishing which host =
name the client should be looking for and which the server should =
present.  As you note, there are already existing technologies to do =
that, including multiple subjectAltNames, SNI, and STARTTLS. =20

--Richard=

From [email-masked]  Thu Apr 28 21:15:06 2011
From: [email-masked]
To: [email-masked]
Date: Thu, 28 Apr 2011 21:15:01 -0700
Cc: [email-masked]
Subject: [dane] I-D Action:draft-ietf-dane-use-cases-02.txt

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF.

	Title           : Use Cases and Requirements for DNS-based Authentication of Named Entities (DANE)
	Author(s)       : R. Barnes
	Filename        : draft-ietf-dane-use-cases-02.txt
	Pages           : 11
	Date            : 2011-04-28

Many current applications use the certificate-based authentication
features in TLS to allow clients to verify that a connected server
properly represents a desired domain name.  Traditionally, this
authentication has been based on PKIX trust hierarchies, rooted in
well-known CAs, but additional information can be provided via the
DNS itself.  This document describes a set of use cases in which the
DNS and DNSSEC could be used to make assertions that support the TLS
authentication process.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dane-use-cases-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body; name="draft-ietf-dane-use-cases-02.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart--

From [email-masked]  Fri Apr 29 09:03:22 2011
From: Warren Kumari <[email-masked]>
Date: Fri, 29 Apr 2011 12:03:12 -0400
To: [email-masked]
Subject: [dane] Starting WGLC on: draft-ietf-dane-use-cases-02

Hi all,

I think that Richard has integrated most of the comments received =
on-list into this most recent version of the doc and so, as I mentioned, =
we are going to kick off WGLC...

Please get y'er comments in --  WGLC will be closing on 2011-05-13 at =
16:00UTC (noonish EDT).

W

On Apr 29, 2011, at 12:15 AM, [email-masked] wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
> This draft is a work item of the DNS-based Authentication of Named =
Entities Working Group of the IETF.
>=20
>=20
> 	Title           : Use Cases and Requirements for DNS-based =
Authentication of Named Entities (DANE)
> 	Author(s)       : R. Barnes
> 	Filename        : draft-ietf-dane-use-cases-02.txt
> 	Pages           : 11
> 	Date            : 2011-04-28
>=20
> Many current applications use the certificate-based authentication
> features in TLS to allow clients to verify that a connected server
> properly represents a desired domain name.  Traditionally, this
> authentication has been based on PKIX trust hierarchies, rooted in
> well-known CAs, but additional information can be provided via the
> DNS itself.  This document describes a set of use cases in which the
> DNS and DNSSEC could be used to make assertions that support the TLS
> authentication process.
>=20
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-dane-use-cases-02.txt
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> <Mail Attachment>_______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

From [email-masked]  Sat Apr 30 18:24:10 2011
From: Warren Kumari <[email-masked]>
Date: Sat, 30 Apr 2011 21:24:02 -0400
To: Warren Kumari <[email-masked]>
Cc: [email-masked]
Subject: Re: [dane] Starting WGLC on: draft-ietf-dane-use-cases-02

On Apr 29, 2011, at 12:03 PM, Warren Kumari wrote:

> Hi all,
>=20
> I think that Richard has integrated most of the comments received =
on-list into this most recent version of the doc and so, as I mentioned, =
we are going to kick off WGLC...
>=20
> Please get y'er comments in --  WGLC will be closing on 2011-05-13 at =
16:00UTC (noonish EDT).

Oh, also I wanted to make sure that everyone was aware / on the same =
page -- we are planning on releasing this as it's own doc (and not =
folding it into the other document).

W

>=20
> W
>=20
> On Apr 29, 2011, at 12:15 AM, [email-masked] wrote:
>=20
>> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
>> This draft is a work item of the DNS-based Authentication of Named =
Entities Working Group of the IETF.
>>=20
>>=20
>> 	Title           : Use Cases and Requirements for DNS-based =
Authentication of Named Entities (DANE)
>> 	Author(s)       : R. Barnes
>> 	Filename        : draft-ietf-dane-use-cases-02.txt
>> 	Pages           : 11
>> 	Date            : 2011-04-28
>>=20
>> Many current applications use the certificate-based authentication
>> features in TLS to allow clients to verify that a connected server
>> properly represents a desired domain name.  Traditionally, this
>> authentication has been based on PKIX trust hierarchies, rooted in
>> well-known CAs, but additional information can be provided via the
>> DNS itself.  This document describes a set of use cases in which the
>> DNS and DNSSEC could be used to make assertions that support the TLS
>> authentication process.
>>=20
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-dane-use-cases-02.txt
>>=20
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>=20
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>> <Mail Attachment>_______________________________________________
>> dane mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dane
>=20
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>=20