Subject: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious?

From: Warren Kumari <[email-masked]>
Date: Sat, 15 Jan 2011 22:15:46 -0500

Buoyed by actual progress on getting the first issue resolved, I'm proposing that we jump right into... the 17th issue.

Issue #17: Should draft-ietf-dane-protocol support TLS only or be more ambitious? (http://trac.tools.ietf.org/wg/dane/trac/ticket/17):

Description:
-------
Please note: This is not the "what all protocols can / do we want to support" issue. That will be a separate (and probably lively!) discussion.

The current version of draft-ietf-dane-protocol is titled "Using Secure DNS to Associate Certificates with Domain Names For TLS" and first goal / milestone is "First WG draft of standards-track protocol for using DNS to associate hosts with keys for TLS and DTLS".

What I would like us to discuss is:
Should *this* document simply specify how to support TLS and future protocols can be supported by saying "TLSA, but interpret field Foo to contain Bar" (or "Similar to TLSA, but this different RR, formatted like Baz"). Note that some other protocols already have similar RRtypes; for example SSH already has SSHFP.

The other alternative would be to make *this* document be much more generic and able to support arbitrary key bindings.
------

Getting consensus on this issue soon would be good, as it affects how the document is written...

W

---

From: Warren Kumari <[email-masked]>
Date: Sat, 15 Jan 2011 23:00:40 -0500

> Should *this* document simply specify how to support TLS and future protocols can be supported by saying "TLSA, but interpret field Foo to contain Bar" (or "Similar to TLSA, but this different RR,…

<no hats>

This approach is my personal preference.
Having a document that clearly explains how something works for one simple, concrete use case is (IMO) much easier to understand than a document that tried to be all things to all people and cover all cases. 
This approach should also allow us to make much faster progress, and will allow us to gain experience and will address the largest use case up front.

> The other alternative would be to make *this* document be much more generic and able to support arbitrary key bindings.

I am concerned that, no matter how well the document is written, trying to make it sufficiently generic will end up hard to understand, vague and difficult to implement from. Even getting the terminology sufficiently precise for clear discussions while still being generic is tricky....

W
</no hats>

---

From: Paul Wouters <[email-masked]>
Date: Sun, 16 Jan 2011 01:40:45 -0500 (EST)

> I am concerned that, no matter how well the document is written, trying to make it sufficiently generic will end up hard to understand, vague and difficult to implement from. Even getting the termi…

I think so too.

SSH and IPsec already have their own RRTYPE. TLS is the big one missing here. Other ones I can
think of are PGP or S/MIME related, but those are user based and not host based identities,
which are probably better handled seperately.

Paul

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 16 Jan 2011 09:25:44 +0200

On Sun, Jan 16, 2011 at 01:40:45AM -0500, Paul Wouters wrote:
> >>The other alternative would be to make *this* document be much more
> >> generic and able to support arbitrary key bindings.
> >
> >I am concerned that, no matter how well the document is written, trying
> >to make it sufficiently generic will end up hard to understand, vague and
> >difficult to implement from.
> 
> SSH and IPsec already have their own RRTYPE. TLS is the big one missing
> here. Other ones I can think of are PGP or S/MIME related, but those are
> user based and not host based identities, which are probably better
> handled seperately.

Agreed.

I looked at the SSHFP and IPSECKEY RFCs. They both appear to be fairly
solid. And PGP and S/MIME are not even closely related to TLS (IPSec and
SECSH are at least somewhat related to TLS).

So I would go with TLS-only for the document.

-Ilari

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 16 Jan 2011 08:50:10 -0500

There are actually three issues here

1) Should the protocol only support TLS
2) Should the protocol only support TLS+HTTP
3) Should the protocol only support TLS+HTTP for Web browsing.

Options 1 and 2 are both very broad. Only option 3 is actually narrowly
focused but it is rather hard to separate out.

Currently TLS is in use to secure practically every application layer
protocol - SMTP, POP, IMAP, HTTP. It is also used to support several
thousand Web Services protocols built on HTTP. Over the next few years that
number of protocols will grow to tens of thousands.

Deciding only to support TLS gives the illusion of focus but does not
provide any focus whatsoever because we use TLS to secure 99% of stuff
today. As a historical matter, X.509 was designed long before TLS but worked
fine for TLS keying because the architecture was right.

Stove pipe protocols tend to be too narrowly focused so that they end up not
even supporting their own needs.

Take a look a PKIX, it did not get complex overnight. It got complex because
the initial design was inadequate for real-world needs and was only extended
piecemeal.

Working out how to apply a scheme to multiple protocols is the best way to
make sure that what is produced is worth producing.

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 16 Jan 2011 15:27:05 +0100

> 3) Should the protocol only support TLS+HTTP for Web browsing.

As a reminder, TLS supports more than X.509.  The current draft is hard
wired for X.509 only.  So it is more like:

1) Should the protocol only support TLS with X.509
2) Should the protocol only support TLS with X.509 + HTTP
3) Should the protocol only support TLS with X.509 + HTTP for Web browsing.

Our WG charter does not say "X.509" so I think a proposal for TLS that
encompass other certificate formats would be useful.  I'm considering
updating my early proposal that has this support:

http://tools.ietf.org/html/draft-josefsson-keyassure-tls-00

/Simon

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 16 Jan 2011 10:01:28 -0500

People have written drafts which purport to show use of different keying
modes. That is not the same thing at all.

At the end of the day the cert format is just a packaging issue and the only
things that really matter are that it is acceptably secure and everyone does
the same thing.

We seem to have a very peculiar set of priorities here. Support for SPKI
keying which nobody uses and support for PGP key signature formats which are
not designed for directory based PKI are discussed as if they were important
and useful options.

Meanwhile support for widely used protocols is treated as if it was a
somewhat eccentric idea.

I think some people have their priorities wrong here.

There are only two key formats that are widely used: X.509 and PGP. The PGP
format is expressly designed to support Web of trust and so is irrelevant
here because what we are doing is the exact opposite of what Phil Zimmerman
proposed.

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

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 16 Jan 2011 07:59:13 -0800

On 1/15/11 10:40 PM, Paul Wouters wrote:
>> I am concerned that, no matter how well the document is written,
>> trying to make it sufficiently generic will end up hard to understand,
>> vague and difficult to implement from. Even getting the terminology
>> sufficiently precise for clear discussions while still being generic
>> is tricky....
>
> I think so too.
>
> SSH and IPsec already have their own RRTYPE.

Right. Unless developers from those communities come to us and say "we 
want to abandon our existing RRtype and use yours, please expand yours", 
I don't think that this WG should try to shoe-horn them into our base 
protocol.

> TLS is the big one missing
> here. Other ones I can

Actually, S/MIME *does* have a host-based identity solution, as shown in 
draft-turner-dnssec-centric-pki-00.txt. However, that one is far enough 
away from the model of "this cert/CA is for this transaction" that we 
are using that I would say that those folks could do their own. It can 
be done as a new RRtype that looks a lot like ours, or they could choose 
to repurpose ours with different semantics.

---

From: James Cloos <[email-masked]>
Date: Sun, 16 Jan 2011 12:47:05 -0500

>>>>> "WK" == Warren Kumari <[email-masked]> writes:

WK> The other alternative would be to make *this* document be much more
WK> generic and able to support arbitrary key bindings.

It should be more generic.  There is no value in wasting time on a draft
which only supports one particular use case when we could produce a way to
use DNSSEC to anchor trust paths for essentially all trustable IP traffic.

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

---

From: James Cloos <[email-masked]>
Date: Sun, 16 Jan 2011 12:42:34 -0500

>>>>> "PW" == Paul Wouters <[email-masked]> writes:

PW> but [PGP is] user based and not host based identities,

No, OpenPGP is nym based.  That can by anything, user, host, whatever.

-JimC

---

From: Paul Wouters <[email-masked]>
Date: Sun, 16 Jan 2011 14:03:38 -0500 (EST)

> updating my early proposal that has this support:

And non-certificat formats, such as bare public key where the pubkey is
obtained via DNSSEC.

Paul

---

From: Jakob Schlyter <[email-masked]>
Date: Sun, 16 Jan 2011 22:14:47 +0100

> This approach should also allow us to make much faster progress, and will allow us to gain experience and will address the largest use case up front.

Speaking as author of RFC 4255 (SSHFP), I agree with the above and believe that draft-ietf-dane-protocol should support TLS only.

	jakob

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 16 Jan 2011 17:40:51 -0500

Working at a general level creates standards that are of higher quality
overall and less likely to have the corner cases swept under the rug.

I would separate out the documentation of the trust mechanism itself from
the specific binding to TLS / HTTP and Web browsing considerations. I don't
propose actually writing an IPSEC or SSH binding. But we should be pretty
confident we could write one if necessary.

If the architecture is right the distinction between the two should be very
clear. If there is excessive special pleading it is a sign that the
architecture is wrong. Its like having the warnings flag on a compiler - it
helps avoid mistakes.

We have done this in SAML, Web Services and pretty much every other
specification of this type that I am familiar with.

On Sun, Jan 16, 2011 at 4:14 PM, Jakob Schlyter <[email-masked]> wrote:

> > Having a document that clearly explains how something works for one
> simple, concrete use case is (IMO) much easier to understand than a document
> that tried to be all things to all people and cover all cases.
> > This approach should also allow us to make much faster progress, and will
> allow us to gain experience and will address the largest use case up front.
>
> Speaking as author of RFC 4255 (SSHFP), I agree with the above and believe
> that draft-ietf-dane-protocol should support TLS only.
>
>        jakob
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

---

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

On 16.1.2011 05:00, Warren Kumari wrote:
>> Buoyed by actual progress on getting the first issue resolved, I'm
>> proposing that we jump right into... the 17th issue.
>>
>> Issue #17: Should draft-ietf-dane-protocol support TLS only or be
>> more ambitious?
>> (http://trac.tools.ietf.org/wg/dane/trac/ticket/17):
>>
>> Description: ------- Please note: This is not the "what all
>> protocols can / do we want to support" issue. That will be a
>> separate (and probably lively!) discussion.
>>
>> The current version of draft-ietf-dane-protocol is titled "Using
>> Secure DNS to Associate Certificates with Domain Names For TLS"
>> and first goal / milestone is "First WG draft of standards-track
>> protocol for using DNS to associate hosts with keys for TLS and
>> DTLS".
>>
>> What I would like us to discuss is: Should *this* document simply
>> specify how to support TLS and future protocols can be supported
>> by saying "TLSA, but interpret field Foo to contain Bar" (or
>> "Similar to TLSA, but this different RR, formatted like Baz"). Note
>> that some other protocols already have similar RRtypes; for example
>> SSH already has SSHFP.
>
> <no hats>
>
> This approach is my personal preference. Having a document that
> clearly explains how something works for one simple, concrete use
> case is (IMO) much easier to understand than a document that tried
> to be all things to all people and cover all cases. This approach
> should also allow us to make much faster progress, and will allow us
> to gain experience and will address the largest use case up front.

<no hat>

+1

On 16.1.2011 15:27, Simon Josefsson wrote:
> As a reminder, TLS supports more than X.509.  The current draft is
> hard wired for X.509 only.

Can we untie the draft from X.509?

> 3) Should the protocol only support TLS with X.509 + HTTP for Web

I certainly don't want to limit this to just HTTP.  One of my initial 
drives for this WG was to support and improve SMTP, where lot's of 
unsigned certs happen to reside.

</no hat>

<chair hat>

Anyway I think the issue #17 is TLS-only or more.  So we should focus on 
that and make separate issue out of the TLS+<any_proto> or TLS+HTTP. 
Let's not widen our issues unless absolutely necessary.

</chair hat>

Ondrej
-- 
  Ondřej Surý
  vedoucí výzkumu/Head of R&D department
  -------------------------------------------
  CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
  Americka 23, 120 00 Praha 2, Czech Republic
  mailto:[email-masked]    http://nic.cz/
  tel:+420.222745110       fax:+420.222745112
  -------------------------------------------

---

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

The only reason to narrow consideration to TLS would be to try to save time.

AsI am pointing out here, we have three choices.

1) TLS only
2) X.509 only
3) HTTP only

Any decent PKI architecture is going to be independent of the protocol that
consumes the key. Choosing to only document TLS will save a some time. But
only designing for TLS will not.

Choosing to support multiple key formats does greatly increase the
complexity of the specification but delivers zero value as the only people
who care about the use of the key format are a narrow technical clique.
Support for different key formats will not increase the practical value of
the spec in any way whatsoever.

Support for multiple application protocols is essential. There are more
application protocols that may be used than there is code space for DNS RRs.
If we don't address this use case the whole scheme is worthless.

So suggest that we stop talking about #17 at this point because it is not
the most relevant decision. It is a choice that people are wanting to take
to fool themselves that they are getting focused when they are doing no such
thing.

We should solve the hardest problem first.

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

> drives for this WG was to support and improve SMTP, where lot's of unsigned
> certs happen to reside.
>
> </no hat>
>
> <chair hat>
>
> that and make separate issue out of the TLS+<any_proto> or TLS+HTTP. Let's
> not widen our issues unless absolutely necessary.
>
> </chair hat>
>
> Ondrej
> --
>  Ondřej Surý

---

From: James Cloos <[email-masked]>
Date: Sun, 16 Jan 2011 20:42:08 -0500

>>>>> "PH" == Phillip Hallam-Baker <[email-masked]> writes:

PH> I would separate out the documentation of the trust mechanism itself
PH> from the specific binding to TLS / HTTP and Web browsing considerations.
PH> I don't propose actually writing an IPSEC or SSH binding. But we should
PH> be pretty confident we could write one if necessary.

That makes very good sense.

-JimC

---

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

> The only reason to narrow consideration to TLS would be to try to

Eh, I got lost, at first you wrote:

> 3) Should the protocol only support TLS+HTTP for Web browsing.

and now you are writing:

On 17.1.2011 14:02, Phillip Hallam-Baker wrote:
> As I am pointing out here, we have three choices.
>
> 1) TLS only
> 2) X.509 only
> 3) HTTP only

I guess you have changed that on the basis of Simon's mail.  Alright.

Anyway the issue #17 is about: TLS-only or more, ie. widen the scope

Your options are to be more specific, ie. narrow the scope.

Or am I missing something?  Or is this a language barrier issue?

If I am mistaken (on the narrow vs widen) could you please explain it in 
some other wording (preferably be as concrete as possible, so we don't 
get entangled into general statements), thanks.

> Any decent PKI architecture is going to be independent of the
> protocol that consumes the key. Choosing to only document TLS will
> save a some time. But only designing for TLS will not.
>
> complexity of the specification but delivers zero value as the only
> people who care about the use of the key format are a narrow
> technical clique. Support for different key formats will not increase
> the practical value of the spec in any way whatsoever.

So could you please express your proposal on the issue #17 (ie. be
constructive) instead of telling us what is not going to work (ie. being
destructive)?

> Support for multiple application protocols is essential. There are
> more application protocols that may be used than there is code space
>  for DNS RRs. If we don't address this use case the whole scheme is
> worthless.

I don't remember that we ever talked about encoding application
protocols into DNS RRTYPEs, but I may have missed something.  So I don't
really get what you are talking about.

> So suggest that we stop talking about #17 at this point because it is
> not the most relevant decision.

I don't agree with you.  The draft-ietf-dane-protocol talks about TLS at
all place and the decision on whether TLS-only or more could have
serious impact on the document.

> It is a choice that people are wanting to take to fool themselves
> that they are getting focused when they are doing no such thing.

I suggest we leave "the people" out of technical discussion.

> We should solve the hardest problem first.

Which in your opinion is?

O.

---

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

> Support for multiple application protocols is essential. There are more application protocols that may be used than there is code space for DNS
> RRs. If we don't address this use case the whole scheme is worthless.

I think its fair to say that most custom application that might want to get hooked into
DANE are using a http protocol using x.509 with tls. (or IPsec or ssh)

But DANE currently actually does not care if you use TLS or X.509 or http. It just
cares about the cert/pubkey used for crypto and on which port it will be (with HASTLS)

So I think it covers the vast majority of use cases, even for proprietary protocols.

We might currently not be covering user identities, but I thought people in general thought
this was not the protocol for user identities.

Paul

---

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

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

> Which in your opinion is?

Working out how to support HTTP over TLS, SMTP over TLS and protocol X over
TLS without conflict.

---

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

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

> Working out how to support HTTP over TLS, SMTP over TLS and protocol X over TLS without conflict.

Using which certificate validation scheme? DANE or PKIX/CA's? or Both?

The last one is out of scope for DANE. The first one is by generating
TLSA/HASTLS records that the application can look up - ignoring everything
else in the certificate container.

The combination of the two, which can be conflicting, can only be left
as local site/vendor policy.

So I am not sure what there is left to "solve"

Paul

---

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

2011/1/17 Paul Wouters <[email-masked]>

> else in the certificate container.

DANE has to prove that it can co-exist in the existing infrastructure
without causing damage.

---

From: Martin Rex <[email-masked]>
Date: Mon, 17 Jan 2011 16:45:49 +0100 (MET)

> here because what we are doing is the exact opposite of what Phil Zimmerman

Two-factor authentication has become popular for humans, because if
adequately set up, administrated and used it will require the two
simultaneous security breaches for an unauthorized access.

The X.509 architecture has a design flaw that limits the security to
n-factor (n<=1).  For the existing TLS X.509 PKI n is around 1/600  (0.00167)

The PGP web of trust provides n-factor security  (n>=1), and obtaining
(n>>1) is easy and straightforward.

keyassurance through DNSSEC might be used to get back an n-factor security
with X.509 TLS PKI closer to n=1 (or even slightly better).  

While it's true that a PGP n-factor server authentication based on
pre-shared PGP trust anchors would work entirely without DNSSEC-based
key assurance (requiring PGP-enabled TLS on both ends, of course),
it might still be useful for the situation where there are no
pre-shared PGP trust anchors and either trusting DNSSEC or
allowing a leap-of-faith distribution of PGP keys or trust anchors
under protection of DNSSEC keys.

-Martin

---

From: Stephen Kent <[email-masked]>
Date: Mon, 17 Jan 2011 17:11:02 -0500

Warren,

I agree that getting DANE right for one protocol, e.g., TLS, is a lot 
easier than trying to get it right for more than one.  The big issue 
that we need to keep in mind is to not impose design constraints, or 
make design assumptions, at this stage that will conflict with late 
use of DANE with IPsec, etc.

Steve

---

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

>under protection of DNSSEC keys.

The use of the phrase "n-factor authentication" in your message does 
not match what is commonly accepted in the security field.  In 
multi-factor authentication the factors represent different types of 
authentication data, not multiple instances of auth data of the same 
type. So, for example, using a password and a challenge-response 
token is an example of two-factor authentication, but using two 
passwords is not. Thus, in the PGP web of trust context, having a 
cert with signatures from multiple individuals is not an example of 
multi-factor authentication.  Similarly, have multiple X.509 certs, 
each with the same public key, but issued by different CAs, also 
would not be an example of multi-factor authentication.  BTW, PGP and 
X.509 are really comparable in this respect, so I disagree with what 
appears to be the general thrust of your example.

Steve

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 17 Jan 2011 15:23:51 -0800

On 1/17/11 2:11 PM, Stephen Kent wrote:
> easier than trying to get it right for more than one. The big issue that
> we need to keep in mind is to not impose design constraints, or make
> design assumptions, at this stage that will conflict with late use of
> DANE with IPsec, etc.

As an IPsec person who tests IPsec with PKIX certificates 
(<http://www.vpnc.org/testing.html#CertIKEv1Interop>), I am quite sure 
that nothing in the current draft will conflict with a future profile 
for IPsec, if that community wants such a profile. As co-author of the 
current draft, I'm pretty sure I would notice if a change was made that 
brought up such conflict and would prevent it.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Wouters <[email-masked]>
Date: Mon, 17 Jan 2011 18:30:31 -0500 (EST)

On Mon, 17 Jan 2011, Paul Hoffman wrote:

> (<http://www.vpnc.org/testing.html#CertIKEv1Interop>), I am quite sure that 
> nothing in the current draft will conflict with a future profile for IPsec, 
> if that community wants such a profile. As co-author of the current draft, 
> I'm pretty sure I would notice if a change was made that brought up such 
> conflict and would prevent it.

Just a FYI:

I also see no reason to actually use DANE over IPSECKEY (RFC 4025) and OE (RFC 4322)

Those offer some more flexibility actually such as sending IP traffic for a certain
host indirectly via IPsec to a specific IPsec gateway.

Paul

---

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

That is all I was ever arguing for, not to box ourselves into a corner
unnecessarily.

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

> As an IPsec person who tests IPsec with PKIX certificates (<
> http://www.vpnc.org/testing.html#CertIKEv1Interop>), I am quite sure that

---

From: Warren Kumari <[email-masked]>
Date: Mon, 17 Jan 2011 22:02:46 -0500

On Jan 17, 2011, at 5:11 PM, Stephen Kent wrote:

> Warren,
> 
> I agree that getting DANE right for one protocol, e.g., TLS, is a lot easier than trying to get it right for more than one.  The big issue that we need to keep in mind is to not impose design constraints, or make design assumptions, at this stage that will conflict with late use of DANE with IPsec, etc.

Oh, yes, I fully, completely, 100% agree with you.

I still think that we should stick with TLS in the current doc so that we can have a clean, clear and concise document -- while writing it (and future documents) we will ensure that we are not constraining the design, or making assumptions that preclude supporting other protocols.

I'm trying to avoid ending up with a document that is vague and hand-wavy -- "the first field can contain a hash, or a key, or a cert, or a means of getting a cert, or a further identifier that specifies that the filed is extended in some way, or a protocol identifier, or a small eggplant, or a bunch of parameters, or a coordinate on a plane, or a hostname. The length of this field varies according to what you put in it. The interpretation of all of the following fields is determined by the value of this field."

W

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 18 Jan 2011 13:47:52 +0100

> Can we untie the draft from X.509?

It is technically simple to do (compare my draft with the current one),
but the impression I got was that authors preferred not to.

/Simon

---

From: Martin Rex <[email-masked]>
Date: Tue, 18 Jan 2011 15:17:17 +0100 (MET)

Stephen Kent wrote:
> type.

You're correct.  The term(s) 2-Factor and Multi-Factor have been
squatted by marketeers and regulators for a very specific purpose.

I was trying to describe a specific security feature at an abstract
level using invalid terminology.

X.509/PKIX credentials are confirmed as valid with one single digital
signature. There is no means (native to X.509) to require multiple
independent signatures (logical "AND").  On the contrary, when there
are multiple omipotent CA trusted as credential signers (logical "OR"),
then the bottom-line security is significantly impaired.

In the existing TLS X.509 PKI there is currently no means for a server
or domain admin to limit/restrict which CAs are allowed to confirm
a server credential as valid.  Any single one will do.  And according
to this research:  http://www.eff.org/files/DefconSSLiverse.pdf
(page 19) there are plenty of CAs for attackers to choose from.

DANE could become a band-aid to mitigate this PKIX security problem,
by establishing a secondary requirement vaguely similar to "dual control"
(http://www.yourwindow.to/information-security/gl_dualcontrol.htm)

One possible usage of DANE would be to limit which specific CAs from
those considered valid CAs under the TLS X.509 PKI, are also valid
signers for a particular server or a particular DNS domain.

With the PGP web-of-trust model, it would be technically possible
to require any number of additional signers for a server credential
before it is considered valid.

But in order to gauge the effective security, one needs to look at
the overall picture not just one specific procedure.

The TLS X.509 PKI traditionally has weaknesses, because it keys off
the WHOIS database for issuing server certs, and some CA issuing procedures
involven unauthenticated SMTP Email.  DANE will inherit its properties
from the DNS administration procedures, so what matters is the difficulty
of getting malicious DNS records into the DNS database that feeds
into the automatic DNSSEC record signing service.

Two factor authentication schemes for humans may have similar problems.
Although an authentication scheme involving a fingerprint and a token
counts as two factor, a successful attack on this scheme usually
requires only one single assault on one person.

Similarly, a procedure to register/establish new multi-factor authentication
credentials might require only one single proof of identity (ID-card).  

Requiring multiple signatures on a server key in a PGP web-of-trust style
may improve security.  But if all of the necessary signatures can be
obtained with the exact same "proof of ownership", then this mostly
adds complexity without value (it would only protect from exploration
of accidental unique flaws in the validation/issuing procedures
of individual signers).

-Martin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 18 Jan 2011 10:14:49 -0500

Martin seems to be referring to the original PGP paper rather than the code
that Phil Z. actually implemented.

In practice X.509 started to absorb features from PGP very early on. The
single rooted hierarchy was gone in 1995 and cross certification was
introduced about the same time and is increasingly deployed and used.

In practice it has been possible to do everything that can be done in PGP in
X.509 for some time now. The only practical difference is that in PGP
everyone is a trust provider and every key can be used for trust provision
and in X.509 anyone can be a trust provider but this is a distinct role and
the keys used for this purpose are separate from end entity keys.

The systems have already converged. PGP key signing has never enjoyed any
real market success as a host authentication mechanism and even if it had
the idea of a monolithic PKI hierarchy like DNSSEC is entirely antithetical
to the PGP design goals.

Its like demanding that the Playboy mansion car park be redesigned to
accomodate the Pope-mobile.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 18 Jan 2011 07:59:24 -0800

On 1/18/11 4:47 AM, Simon Josefsson wrote:
> Ondřej Surý<[email-masked]>  writes:
>

There was not much interest originally in doing so, but it sounds like 
more people are interested now. I just sent a proposal to untie types 1 
and 2 from PKIX or even certificates at all. However, if you want to 
possibly untie types 3 and 4 from PKIX, it would be really useful to see 
text first. I have no idea how to make OpenPGP work with them, and they 
make no sense for bare keys, I think.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 18 Jan 2011 13:30:11 -0500

>level using invalid terminology.

agreed.

>then the bottom-line security is significantly impaired.

agreed

>(page 19) there are plenty of CAs for attackers to choose from.

yep.

>(http://www.yourwindow.to/information-security/gl_dualcontrol.htm)

this is NOT a PKIX problem. It is a browser design problem. One could 
enable users to manage the TAs offered by browser vendors in ways 
that limit the scope of them, e.g., through the use of name 
constraints.  See the work in the SIDR WG on local TA management, for 
example (draft-ietf-sidr-ltamgmt-00.txt).

>signers for a particular server or a particular DNS domain.

I understand the attraction for this notion, but it does conflict with the
concept that, ultimately, the client (software) gets to make 
decisions of this sort.

>before it is considered valid.

yes, and with X.509 one could require that an EE cert for a server 
link to a specific TA (or set of TAs).

>into the automatic DNSSEC record signing service.

The statement about using whois data may be true for some CAs, but it 
not part of X.509 or PKIX standards, nor it it mandated by browser 
vendors.  I think it best to focus on what DANE can do, based on DNS, 
not on the CP/S for every possible CA that becomes a TA in some 
browser.

>requires only one single assault on one person.

Absent a discussion of a threat model, one cannot judge the extent to 
which a multi-factor authentication scheme represents a useful 
improvement over a specific, single-factor scheme.  In your example, 
if the threat is perceived to be hackers, then use of a fingerprint 
probably does make a big, positive difference. if the threat is a 
criminal with physical access to the user, it's not so impressive :-).

>credentials might require only one single proof of identity (ID-card).

In this case the concern is not whether the registered user is 
securely authenticated, but rather whether the ID asserted by that 
individual is accurate.  Those are different security issues.

>of accidental unique flaws in the validation/issuing procedures

There are lots of ways a multi-signature cert may offer little 
improvement over a single signature cert.

Steve

---

From: Paul Wouters <[email-masked]>
Date: Tue, 18 Jan 2011 15:51:29 -0500 (EST)

On Tue, 18 Jan 2011, Stephen Kent wrote:

> concept that, ultimately, the client (software) gets to make decisions of 
> this sort.

Leave that to the CAA draft please.

Paul

---

From: Martin Rex <[email-masked]>
Date: Tue, 18 Jan 2011 22:34:10 +0100 (MET)

Stephen Kent wrote:
> this is NOT a PKIX problem. It is a browser design problem.

I'm sorry for another mixup of terminology
PKIX (the technology/protocols) vs. PKI (the use of PKIX protocols
with a certain set of trust anchors, such as the TLS X.509 PKI).

The fact that browsers are using a large set of independent trust-anchors
from commercial CAS (TLS X.509 PKI) is admittedly a browser problem.
But one that is hardly avoidable for a browser, the way that HTTPS
is currently used on the internet.

The issue that X.509 does not provide room for an additional signature
is an X.509/PKIX shortcoming.  Would X.509 provide room to accomodate
an secondary signature, then one would not need DNSSEC/DANE to convey
a secondary signature (authenticated through the independent DNS PKI).

>
> One could enable users to manage the TAs offered by browser vendors
> in ways that limit the scope of them, e.g., through the use of name 

Name Constraints have the prerequisite of a strict X.509 hierarchy
with only one single globally trusted root and another prerequisite
that name constraints are fully supported by the entire installed base.

Neither the existing TLS X.509 PKI nor most of the installed base of PKI
software meets these prerequisites, and frankly, I don't see a realistic
migration path for the former and no incentive for the latter.

While it is possible to build PKIs (and obtain software) that fulfills
these prerequisite, I personally doubt that they scale beyond a small
set of closely related organizations.

The only reason why this kind-of-works in the DNSSEC case is that
is uses an existing delegation hierarchy, is not abused as a business
model, incurs fairly minor costs and does not need to scale beyond DNS
(only a fraction of internet users are DNS domain admins).

> I understand the attraction for this notion, but it does conflict with
> the concept that, ultimately, the client (software) gets to make 
> decisions of this sort.

There are two distinct issues that ought not to be confused.

Ignoring information provided by the admin of a DNS domain about
valid certificate signers for a host in that domain would be much worse
than ignoring Certificate revocation information (CRLs/OCSP).  But
there currently is no means for an DNS admin or server admin to
convey such information.  DANE could convey this information.

Not checking whether such information exist (or ignoring it) is ultimately 
the clients decision, but may put the client at risk.

While PKIX provides a means to convey revocation information from
certificate signers to clients, PKIX provides no means to credentials
bearers to convey independent confirmation of an identity asserted
by an X.509 certificate.

> link to a specific TA (or set of TAs).

With X.509, this option is available only to the client, not the
server and/or DNS admin.

One possible client-side solution for such a requirement would be
"pinning" of a server cert (or a server cert signer) similar to what
is described here:
    http://www.w3.org/TR/wsc-ui/#selfsignedcerts

However some folks in the IETF decided to completely subvert this:
http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-14#section-6.6.1

by having a name match of a cert from any CA under the TLS X.509 PKI
_unconditionally_ override client cert pinning.

Maybe the IETF can make at least have DANE provide some risk mitigation
capabilities for the server and DNS admins?

-Martin

---

From: James Cloos <[email-masked]>
Date: Tue, 18 Jan 2011 17:23:43 -0500

>>>>> "PH" == Phillip Hallam-Baker <[email-masked]> writes:

PH> the idea of a monolithic PKI hierarchy like DNSSEC is entirely
PH> antithetical to the PGP design goals.

Not antithetical but rather just another path in the trust graph;
one which starts at the . DS rather than at another OpenPGP key.
(Unless, of course, one trusts the . DS /because/ of a trust path
back to an OpenPGP key. :)

OpenPGP's choice to make the trust graph explicit, and the choice
by most software authors to allow users to configure how much they
trust any given key, how much less trust they allocate to keys which
are signed by trusted keys and how much more trust they allocate to
additional paths through the graph is one of its biggest strengths.

Signing OpenPGP keys with DNSSEC fits nicely into that model.  The
value of a chain of RRSIGs probably should be a bit different than
the value of a chain of OpenPGP sigs, but the concept is the same.

-JimC

---

From: James Cloos <[email-masked]>
Date: Tue, 18 Jan 2011 17:33:07 -0500

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

>> signers for a particular server or a particular DNS domain.

SK> I understand the attraction for this notion, but it does conflict
SK> with the concept that, ultimately, the client (software) gets to
SK> make decisions of this sort.

This really isn't a client-server issue, since both sides have a need
to, when necessary, authenticate themselves to the other.  Like anything
communicating over IP we should think of each side as a peer.

So feel free to invert client and server below.

Even though a client always has the right to decide how it will
authenticate a server, and how much it trusts any given authentication,
it cannot hurt for the server to provide (essentially) out-of-band
hints on its preferred method(s) of authenticating itself.

The client still has to choose to trust any DNS-specified hint that the
server only uses some specified trust anchor.

-JimC

---

From: Stephen Kent <[email-masked]>
Date: Tue, 18 Jan 2011 17:41:09 -0500

At
>...

It is a deliberate design decision. In X.509/PKIX the issuer takes 
responsibility for the  certs that it issues, and it has sole 
authority for revocation of those certs.  if one has multiple sigs, 
the revocation policy
becomes more complex, at best. (The X.509 CRL relies on uniqueness of 
the serial number associated with a cert, and that is a per-CA 
identifier.) There is also
the issue of chaining complexity re validation, etc.

>that name constraints are fully supported by the entire installed base.

The name constraints extension does not require a single root; it 
does require a hierarchic name space. Don't confuse hierarchic name 
spaces (like the DNS) and hierarchic CA models. As PHB noted, cross 
certification has long been a feature of X.509 and that implies 
support for non-hierarchic CA relationships.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 18 Jan 2011 17:48:58 -0500

>Leave that to the CAA draft please.

I see no reference to "CAA" in the charter.  To what does that acronym refer?

Steve

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Tue, 18 Jan 2011 16:21:55 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Stephen Kent

> I see no reference to "CAA" in the charter.  To what does that acronym

DNS Certification Authority Authorization (CAA) Resource Record
http://tools.ietf.org/html/draft-hallambaker-donotissue-01

- Andy

---

From: Martin Rex <[email-masked]>
Date: Wed, 19 Jan 2011 01:45:43 +0100 (MET)

Phillip Hallam-Baker wrote:
> 
> In practice X.509 started to absorb features from PGP very early on.

I guess we live in different universes.

X.509 never adopted the capability of multiple signers, and a lot
of the PKIX features (basically everything with the word constraint in it)
has the prerequisite of a CA hierarchy with only one single trust anchor
(because constraints do not work across independent trust anchors).

PGP, on the other hand, faced the reality from the beginning
and provides the necessary capabilities to deal with large numbers
of independent trust communities and varying levels of trust.
And in order to cope with this, allows for multiple signers on
associations of keys and identites.  The concept of multiple
signers covers the gaps created by independent trust anchors.

With X.509 it is is pretty difficult to establish a notion of
varying levels of trust.  Which might be a reason why the
CA/Browser forum came up with an approach (DV-,OV-,EV-certs)
that is entirely invisible/ignored by IETF protocols
http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-14

But one area where PGP has traditionally been lacking is a
reliable/deterministic approach to revocation.  (I do not mean
revoking your own key, but revoking your signature on someone
else's key).

> real market success as a host authentication mechanism.

The idea behind PGP were pretty successful authenticating host in the
form of SSH.  The SSH keyring is called "known_hosts".

>
> even if it had the idea of a monolithic PKI hierarchy like DNSSEC
> is entirely antithetical to the PGP design goals.

To the contrary.  PGP _could_ support arbitrary numbers of monolithic PKI
hierarchies alongside the web of trust of individuals just fine.
But honestly, it is extremely dangerous and negligent to let others
update the list of signers that you should trust without your explicit
consent, and for the area where PGP is being used, it has been completely
unnecessary.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 19 Jan 2011 03:30:51 +0100 (MET)

Stephen Kent wrote:
> the revocation policy becomes more complex, at best.
> (The X.509 CRL relies on uniqueness of the serial number
>  associated with a cert, and that is a per-CA identifier.)
> There is also the issue of chaining complexity re validation, etc.

I agree that support for multiple fully-equivalent signatures on
a certificate, similar to multiple signers in PKCS#7, would be
more than just complex to define (and process), especially in
combination with the existing constraints and revocation architecture.

For the IETF it is more reasonable to allow a secondary validation
of certs originating somewhere out of the "TLS X.509 PKI" cloud
through DANE for significantly improved risk management,
rather than trying to touch the X.509 can of worms.
As a bonus, this creates additional incentive to deploy DNSSEC.  

> support for non-hierarchic CA relationships.

I don't think this is a correct characterization.

Without a single root, (name) constraints extensions simply
dont work.  The "cross-certification" hack subjugates a signer that
was originally born somewhere else under your own root with constraints
in order to make the (name) constraints work.

When creating a cross-certification, you have one of two choices:
impose (name) constraints on the cross cert (path) and fail to validate all
certs issued by that foreign signer (perfectly valid under the foreign root)
that don't fit the name constraints imposed by your own root or hierarchy,
or create a cross-cert without (name) constraints and loose the ability
to enforce constraints (for signers originally operating under different
roots).

If you think of special environments where names and attributes are
created in allegedly independent hierarchies in a specific mandated
fashion so that there is no interference when cross-certing, then
this is essentially one hierarchy with a single root authority, just
that the root isn't actually created as a real _key_, and the cross-certs
are used as workarounds for the lack of a real root _key_.
That the root authority, which has the power to mandate rules doesn't
have the power/capability to sign keys is a mere implementation detail.

Cross-certing existing PKIs that were established without a single
root authority that layed out rules/guidelines for issuing certs
is an entirely different situation, where constraints fail badly.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 19 Jan 2011 04:56:16 +0100 (MET)

Martin Rex wrote:
> 
> > 
> > ... and with X.509 one could require that an EE cert for a server 

I hadn't noticed that the original w3.org/TR document provides the same
poor guidance in section 5.2 of unconditionally overriding a cert
"pinned" by the user when receiving a certificate that validates
under the TLS X.509 PKI.

For the behaviour currently specified in above two documents, the use of
the term "pinning a cert" is inappropriate and quite misleading.

What the specified behaviour really amounts to is pinning the decision
"Don't bother me again about this exact error situation"

-Martin

---

From: Stephen Kent <[email-masked]>
Date: Wed, 19 Jan 2011 11:16:19 -0500

>http://tools.ietf.org/html/draft-hallambaker-donotissue-01

thanks,

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 19 Jan 2011 18:57:23 -0500

agreed

>As a bonus, this creates additional incentive to deploy DNSSEC.

DANE can offer raw keys to do this, or it can offer X.509./PKIX certs 
to be used as TAs.  That's why I am picky about distinguishing 
between issues that are intrinsic to X.509/PKIX and ones that are 
browser-specific. Some of the latter can be avoided while still using 
X.509 certs.

>I don't think this is a correct characterization.

it is.

>dont work.

not true.

>The "cross-certification" hack subjugates a signer that

yes, that's what it does, and that's OK, because every RP is supposed to be
able to choose its set of TAs.  One example of how to do this, the 
one proposed in the SIDR work, is to have every RP be its own TA, and 
"subjugate" every purported TA under the RP.

roots).

not quite true, perhaps because you didn't mean to put "all" where 
you did.  if you impose (that is the target of that cross cert) that 
will no longer validate. It depends on the name scope of certs that 
the target CA issues, and what constraints you impose.

>have the power/capability to sign keys is a mere implementation detail.

not true, again. Let me give an example.  if BBN issues certs for its 
employees, and SAP did the same for its employees, each could 
cross-certify the other with obvious name constraints. these cross 
certs would ensure that folks in each company would not believe certs 
issued by the other company, when the names were outside the scope of 
the company in question. This assumes a hierarchic name space, but 
does not make either BBN nor SAP a "root" etc.

>is an entirely different situation, where constraints fail badly.

That statement is sufficiently vague that I'm not sure what to say. 
But, I will note that each RP can manage TAs any way it wants, and, 
if the RP (or an organizational CA) is careful, it can achieve a 
reasonable level re cert names, irrespective of any conventions of 
PKI-wide security conventions.

Anyway, this discussion is largely not critical to DANE, except in so 
far as it is important for folks to not make inaccurate assumptions 
re what X.509/PKKIX requires, vs. what browsers imply :-).

Steve

---

From: "Carl Wallace" <[email-masked]>
Date: Thu, 20 Jan 2011 07:44:10 -0500

> >Without a single root, (name) constraints extensions simply dont
work.
> 
> not true.
> 
> >The "cross-certification" hack subjugates a signer that was
originally
> >born somewhere else under your own root with constraints in order to
> >make the (name) constraints work.
> 
> able to choose its set of TAs.  One example of how to do this, the one
> proposed in the SIDR work, is to have every RP be its own TA, and

Another approach is to include constraints in each TA definition and
enforce them during path validation (a la RFC 5914 and 5937).  No
subjugation required.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 20 Jan 2011 10:18:17 -0500

> enforce them during path validation (a la RFC 5914 and 5937).  No

Either way, you're changing the TA from its published format (a self-signed certificate) to something else, and changing the contents of the cert/TA in the process (adding name constraints).  The only difference between these two proposals is whether you change TAs as published into certs signed under your own TA or just convert them all into RFC 5914 TAs.  The former, cert-based approach makes validation slightly easier, because there's lots of support for self-signed certs as TAs in crypto libraries and not so much RFC 5914, but the two are really equivalent.

--Richard

---

From: "Carl Wallace" <[email-masked]>
Date: Thu, 20 Jan 2011 10:30:51 -0500

> Either way, you're changing the TA from its published format (a
self-signed
> certificate) to something else, and changing the contents of the
cert/TA in
> the process (adding name constraints).  The only difference between
these
> two proposals is whether you change TAs as published into certs signed
> under your own TA or just convert them all into RFC 5914 TAs.  The
former,
> cert-based approach makes validation slightly easier, because there's
lots of
> support for self-signed certs as TAs in crypto libraries and not so
much RFC
> 5914, but the two are really equivalent.

The cert-based approach requires you to make revocation information
available.  Defining your TAs to be constrained from the outset does
not.  Agree re: support for self-signed certs vs 5914.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 20 Jan 2011 12:07:32 -0500

>enforce them during path validation (a la RFC 5914 and 5937).  No

yes. RFC 5914 assumes local TA management of a specific form which 
achieves the same effect. 5937 assumes use of a more sophisticated TA 
management environment that can do even more that what we're 
discussing here.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 20 Jan 2011 12:10:02 -0500

At 10:30 AM -0500 1/20/11, Carl Wallace wrote:
>available.

but only for the re-issued (formerly TA certs), and only VERY 
locally. If this is a per-RP mechanism, revocation of these certs is 
within your cert store. I'd just delete the cert, not put it on a 
CRL, in that case :-).

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 20 Jan 2011 17:38:07 -0500

>communicating over IP we should think of each side as a peer.

Sorry, I should have used more precise terminology. Each relying 
party gets to choose its TAs. The entity offering a cert is free to 
propose a TA (or a cert path terminating at a TA) to the other end, 
but it cannot mandate that the RP use that path. Also, of course, TLS 
is NOT a peer protocol; the protocol distinguishes between client and 
server.  I know that the server can send a cert path to the client, 
but does TLS support the client sending other than an EE cert to the 
server?  In contrast, I believe IKEv2 does support more of a peer 
approach to this data exchange. (I'm not certain, but I bet Paul 
knows :-).)

agreed.

>server only uses some specified trust anchor.

I think what you mean to say here is that the RP can choose to ignore 
the hint provided by the entity that offered the cert path, but if it 
is going to make use of DANE in the first place ...

Steve

---

From: Geoff Beier <[email-masked]>
Date: Thu, 20 Jan 2011 19:21:49 -0500

On Thu, Jan 20, 2011 at 17:38, Stephen Kent <[email-masked]> wrote:
> Also, of course, TLS is NOT a peer protocol; the
> protocol distinguishes between client and server.  I know that the server
> can send a cert path to the client, but does TLS support the client sending
> other than an EE cert to the server?  In contrast, I believe IKEv2 does

TLS does support this. From RFC 5246, section 7.4.6:

"This message conveys the client's certificate chain to the server;
the server will use it when verifying the CertificateVerify message"

I've seen interoperability problems when the client sends a
certification path that the server does not trust even though the
server could build an alternative path using certificates in its own
trust store. For example:

Client's trust store contains Root A. Root A has issued a cert to CA
B, which has issued a cert to CA C. The server sends CA C in the hint
list. The client then sends its EE cert along with CA C, CA B and Root
A in the Client Certificate message. The server's trust store contains
root D, which has issued a cert to CA C. The server then rejects the
client because the path the client sent doesn't terminate in root D,
even though it should have enough information to trust the EE cert
based on the cert its own trust anchor issued.

That's a little hard to explain but isn't hypothetical at all. I've
seen it in the wild. It comes about because people are much more
likely to have narrowed their server's trust store than their
client's, and some cert processing libraries have been known to prefer
longer certification paths over shorter ones when choosing from
multiple possible paths.

Geoff

---

From: Martin Rex <[email-masked]>
Date: Fri, 21 Jan 2011 15:42:38 +0100 (MET)

Stephen Kent wrote:
> but it cannot mandate that the RP use that path.

But the entity should expect that the reciepient checks the _offered_path_,
even when the recipient uses a different path for acutal certificate
path validation, and therefore entities should refrain from sending
a path that they themselves can easily determine to be invalid.

>
> I know that the server can send a cert path to the client, 
> server?

In TLS, when the server explicitly requests a client certificate,
then the client must either indicate that it does not have a
(suitable) client cert, or the client MUST send the FULL cert path.
Only the the self-signed cert at the end of the path may be omitted.
   http://tools.ietf.org/html/rfc2246#page-39

Since the TLS Server is supposed to (in SSLv3&TLSv1.0 the server MUST)
announce the certificate signers that it trusts, when it requests a
client certificate, one may argue that sending a client certificate
with cert path up to at least one of the trusted signers, as announced
by the server, should be OK.

-Martin

---

From: Stephen Kent <[email-masked]>
Date: Fri, 21 Jan 2011 10:28:17 -0500

>longer certification paths over shorter ones when choosing from

Geoff,

Thanks for the clarification.

Your example points out the complexity that arises when one entity 
offers more than just an EE cert to authenticate itself, and the RP 
receiving the cert path has to decide how to handle it. rejecting the 
path even when the RP could have
validated the EE cert, via another path, is something we ought to try 
to avoid.  I believe IKE has encountered analogous problems.

DANE needs to ask whether it makes sense to send a cert path, vs. 
just an EE cert, given the potential for confusion, or whether we 
need to mandate more sophisticated processing for RPs, so that we 
avoid this sort of problem.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 21 Jan 2011 10:38:55 -0500

>a path that they themselves can easily determine to be invalid.

I disagree. The only path that is relevant to an RP is the one that 
the RP chooses to employ for cert validation.  If one tries to use an 
offered path, life can become more complex, and, in this example, an 
unnecessary validation failure occurs.

>by the server, should be OK.

Thanks for reminding me of the server->client TA list.  I agree that 
if the client send a path that terminates at one of those TAs, the 
server SHOULD accept it. But, isn't this an example of asymmetry in 
TLS, i.e., the client has no analogous capability to let he server 
know what set of TAs it will accept. So there is still a problem when 
one tries to use TLS as a peer secruity protocol, as opposed to the 
client/server model that is common for most public web site access.

Steve

---

From: Martin Rex <[email-masked]>
Date: Fri, 21 Jan 2011 17:45:52 +0100 (MET)

Stephen Kent wrote:
> the RP chooses to employ for cert validation.

I'm sorry, I did not mean to imply a duty for the receipient to perform
cert path validation on the original path.

But any assumption on the side of the sender, to throw garbage at the
server in a security protocol and expect the server to simply ignore
anything that doesn't fit a very clear and explicit protocol specification,
would be totally flawed.

Several protocol are in a poor shape because early implementations
were "liberal in what they accept"ed far beyond reasonable levels.

>
> If one tries to use an offered path, life can become more complex,
> and, in this example, an unnecessary validation failure occurs.

If all that it takes to build a cert path, for which a full cert
path validation can be performed, is to ignore certs at
the end of the original/given certs path, then there certainly
is a bug in the code doing the cert path validation.

Cross-cert scenarios are pretty messy, and there seem to be some
very unresponsible approaches a cert path validation out in the wild,
like automatic/silent AIA-chasing.

The straight-forward way for making cert path validation work
in cross certification scenarios is to distribute cross-certs
as trust anchors.

> client/server model that is common for most public web site access.

For the big majority of TLS servers, this is not a problem.  They have
just one single credential/cert anyway, and if that doesn't work, there
would not be a way to handshake around this problem.

The "Server Name Indication" is an existing TLS extension intended
to help the server select a suitable server credential, for servers
that have more than one available.  So for situations, where the
server needs to know which TAs the client has available to verify
the servers cert path, the obvious solution would be to define
another TLS extension to convey this information and have the
client include it in the ClientHello handshake message.

For SSL/TLS, announcing the "standard" list of TAs from the
TLS X.509 PKI is very undesirable.  There are simply too
many of them (~60), and when stuffing those into ClientHello,
the size of the ClientHello would increase from typically <100
octets today to >16 KByte, requiring a fragmentation of ClientHello
(which a lot of implementations will break on, although it has
always been a MUST support feature since SSLv3), and might
incur a penalty from TCP slow start, besides wasting a lot
of network bandwidth (on average).

The original design behind SSL was the real world.  An extremely
weak server endpoint identification was considered good enough,
which is why hardly anyone appears to have security concerns
about a TLS X.509 PKI with a set of ~60 independent TAs that
bootstrap trust to like ~600 seperately operated, omnipotent CAs,
providing server admins a choice of functionally equivalent
server certs over a very broad price range.

For TLS client certs, if they're used at all, the most reasonable and
most manageable setup is when the server admin (organization) issues
those themselves, similar to the membership plastic cards that inhabit
everybodies wallets.  And then, the announcement of the trusted CAs
by the server when asking for the client cert is somewhat similar
to the logos at the door of businesses which plastic cards they
will accept from clients.

-Martin

---

From: Stephen Kent <[email-masked]>
Date: Mon, 24 Jan 2011 16:26:21 -0500

>were "liberal in what they accept"ed far beyond reasonable levels.

I a very much in agreement with your observation that, in the 
secruity space, Jon's pithy sound bite is often the wrong thing to do.

>is a bug in the code doing the cert path validation.

I can imagine an implementer just taking whatever is offered by the 
other end and plugging it into the local path validation code.  if if 
fails, the RP give up. Also, if the server offered a list of TAs to 
which it could validate, then there is a sort of shared 
responsibility here The client should have sent a path that it knows 
terminates at one of those TAs, if it knows the TAs.  Of course, if 
the client does not know, it's not clear if sending just the EE cert 
is better than sending a path.

>like automatic/silent AIA-chasing.

Path building in a cross-certified environment is complex, period. 
Note that PKIX does not standardize path building, only path 
validation.  Path building is covered by an informational RFC.

>in cross certification scenarios is to distribute cross-certs

that does make life easier, but it may not always be practical.

>would not be a way to handshake around this problem.

agreed, but that does support my observation about the asymmetry here.

>client include it in the ClientHello handshake message.

that would make the exchange more symmetric re cert oath info.

>of network bandwidth (on average).

agreed. it would not be useful to send all of them.

>server certs over a very broad price range.

I don't think I agree with your characterization of the "original 
design" rationale. Long ago there were many fewer TAs in browsers, 
and the power shifted between CAs and browser vendors over time.  I 
served as CTO for a major CA in the mid-90's, so I recall what things 
were like then.

>will accept from clients.

agreed.  see my MILCOM paper from 1997 "How Many CAs are Enough?" 
(or Google the title and find PPT slides based on the paper :-))

Steve

---

From: Martin Rex <[email-masked]>
Date: Mon, 24 Jan 2011 23:44:39 +0100 (MET)

> served as CTO for a major CA in the mid-90's, so I recall what things 

Netscape 3.01 (~1996) already had 16 independent rootCA certs.
(just looked at it -- yup, I still got one of those around).

I remember that around year 2000,

Thawte sold regular server certs a USD 100 and wildcard certs at USD 400,
and if you paid for 2 years in advance, you could get a server cert
with 2 years lifetime.

while VeriSign wanted USD 700 for a regular server cert and didn't
offer any wildcard certs at all.

So both, the multiple independent rootCA certs and the widely varying
prices are really pretty old stuff.

-Martin

---

From: Warren Kumari <[email-masked]>
Date: Mon, 24 Jan 2011 18:35:00 -0500

While this is an interesting thread (and demonstrates the need for  
this), I was wondering if we could try and return to the original  
question....

For a while it looked like we were getting somewhere on that, but I  
think that we have drifted sufficiently off course that a gentle nudge  
is in order...

So, <nudge>.

W

--
The plural of anecdote is not evidence.
         -- Bill Lockyer, California Attorney General

---

From: Warren Kumari <[email-masked]>
Date: Thu, 27 Jan 2011 16:18:14 -0500

Hi all,

I just wanted to clarify that this was not intended to be a reprimand  
towards Steve, Martin (or anyone else) -- I was just trying to make  
sure that we got clear consensus on the original question, but that  
may not have been clear from my tone.

Apologies,
   W

On Jan 24, 2011, at 6:35 PM, Warren Kumari wrote:

> think that we have drifted sufficiently off course that a gentle  
> nudge is in order...
>
> So, <nudge>.
>
> W
>

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 28 Jan 2011 17:32:05 +0100

Hi all,

upon discussion with my fellow co-chair I hereby call for consensus on 
issue #17.

The consensus would be that the initial document 
(draft-ietf-dane-protocol) would support only TLS.

If there is ever need to expand it will be worked on in different I-Ds 
referencing draft-ietf-dane-protocol and either expanding TLSA or 
specifying their on RR Type (similar SSHFP or IPSECKEY).

Regards,
Ondrej

P.S.: As a side note the Issue #17 is only on TLS-only or not.  Let's 
not get to X.509/HTTP/etc. discussions in this issue again.  If you feel 
this needs to be discussed, drop us a note and we will open a separate 
issue in the tracker.  Thanks.

On 16.1.2011 04:15, Warren Kumari wrote:
> more ambitious? (http://trac.tools.ietf.org/wg/dane/trac/ticket/17):
>
> Description: ------- Please note: This is not the "what all protocols
> can / do we want to support" issue. That will be a separate (and
> probably lively!) discussion.
>
> Secure DNS to Associate Certificates with Domain Names For TLS" and
> first goal / milestone is "First WG draft of standards-track protocol
> for using DNS to associate hosts with keys for TLS and DTLS".
>
> specify how to support TLS and future protocols can be supported by
> saying "TLSA, but interpret field Foo to contain Bar" (or "Similar to
> TLSA, but this different RR, formatted like Baz"). Note that some
> other protocols already have similar RRtypes; for example SSH already
> has SSHFP.
>
> generic and able to support arbitrary key bindings. ------
>

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 28 Jan 2011 18:24:24 +0100

> (draft-ietf-dane-protocol) would support only TLS.

Does this exclude DTLS?  DTLS is not the same protocol as TLS.

/Simon

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 28 Jan 2011 10:14:50 -0800

> Does this exclude DTLS?  DTLS is not the same protocol as TLS.

DTLS is clearly and completely covered in every WG draft so far. If it 
is not clear, let the authors know; that would be an error on our part.

---

From: Warren Kumari <[email-masked]>
Date: Fri, 28 Jan 2011 13:26:34 -0500

On Jan 28, 2011, at 1:14 PM, Paul Hoffman wrote:

>> Does this exclude DTLS?

No... Good catch though!

Apologies for not being clearer -- the document uses the term TLS to  
refer to both TLS and DTLS, and we have fallen into doing the same  
thing.

I have a procmail rule that I pass outgoing mail through that does  
'sed/exmaple.com/example.com' on outgoing mail, perhaps I should add  
's/TLS/TLS\/DTLS/' :-)

>>  DTLS is not the same protocol as TLS.
>
> DTLS is clearly and completely covered in every WG draft so far. If  
> it is not clear, let the authors know; that would be an error on our  
> part.

Nope, I believe it is perfectly clear in the doc (clear enough that I  
automatically see the implied DTLS)

W

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 28 Jan 2011 19:57:01 +0100

> refer to both TLS and DTLS, and we have fallen into doing the same

Just checking.  I don't think DTLS is important, but it is easy to
support if we support TLS already.

However supporting both TLS and DTLS has consequences for naming.  Port
1234 over TCP does not necessarily run the same service as port 1234
over UDP.  Thus my preferred naming scheme would then be:

_1234._tcp.mail.example.com
_1234._udp.mail.example.com

/Simon