Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-05.txt
From: Stephen Kent <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Mon, 28 Feb 2011 13:40:46 -0500
List-Id: Key Assurance With DNSSEC <keyassure.ietf.org>

At 6:27 PM +0100 2/24/11, Martin Rex wrote:
>...
>  > In the IETF, PKIX profiles X.509 for use with IETF security protocols,
>>  so it probably makes sense to stick with the PKIX label here. This is
>>  certainly true for EE certs. For a self-signed cert used to convey
>>  trust anchor material, we may need some additional/different text.
>
>
>But this would imply that EE certs will have to be issued by commercial CAs.

no. anyone can be a CA.

>I thought that one of the purposes of DANE was to allow server admins
>to create their own certificate and distribute it through DNS(SEC) TLSA
>records.

see comment above.

>Maybe we should distinguish more types:
>
>    1 -- An end-entity X.509 certificate in ASN.1 DER encoding
>
>    2 -- A certification authority's X.509 certificate in ASN.1 DER encoding
>
>    3 -- An end-entity PKIX certificate from the TLS X.509 PKI
>
>    4 -- A certification authority's PKIX certificate from the TLS X.509 PKI
>
>For (1), the client would match the server certificate with the TLSA
>record and be done with it, for (3), besides matching the server certificate
>with the TLSA record, the client is expected to perform a regular
>certificate path validation.

as others have pointed out, X.509 vs. PKIX is not generally a 
meaningful distinction in this context, so the wording above is 
confusing, at best.

I plan to work with Paul to generate appropriate text, to match
PKIX standards, while preserving the intent of the DANE docs.

Steve

Date: Mon, 28 Feb 2011 10:12:01 -0500
To: Ben Laurie <[email-masked]>
From: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-04.txt

At 3:12 PM +0000 2/25/11, Ben Laurie wrote:
>...
>  > if you issue a cert, you are a CA
>
>Eh? If I make a self-signed cert, am I a CA?

yes.

>If I publish an EE cert issued by someone else, am I a CA?

no. publishing is not the same as issuing. any 3rd party can publish any cert.

>Presumably at least one of these is a "no", so the zone operator is
>not necessarily a CA. This was my point.

OK.

>...
>  > It would not be useful to you, but rather to someone who puts it in a
>>  DNS record, if that someone does so on your behalf. Otherwise that entity
>>  does not know if the public key really is yours.  But, I don't know that
>>  this results in a vulnerability for the DANE context.
>
>Ah. If I am asking someone else to update DNS for me, then indeed a
>PoP might be appropriate. But surely that's an issue for whatever
>protocol I am using for speaking with my DNS provider?

seems reasonable to me.

Steve

Date: Sun, 27 Feb 2011 09:28:34 -0800
From: Paul Hoffman <[email-masked]>
To: Jakob Schlyter <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto algorithms and certificate types are mandatory to implement"

On 2/27/11 4:27 AM, Jakob Schlyter wrote:
> On 25 feb 2011, at 23.02, Paul Hoffman wrote:
>
>> Hash algorithm:
>>
>> - All implementations must support SHA-256.
>
> i.e., reference type 2.
>
>> - All implementations should have the facility to later use other hash algorithms.
>
> Also, all implementations must support reference type 0 (aka "full certificate").

Er, right, of course. That too.

From: Jakob Schlyter <[email-masked]>
Date: Sun, 27 Feb 2011 13:27:35 +0100
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto algorithms and certificate types are mandatory to implement"

On 25 feb 2011, at 23.02, Paul Hoffman wrote:

> Hash algorithm:
>=20
> - All implementations must support SHA-256.

i.e., reference type 2.

> - All implementations should have the facility to later use other hash =
algorithms.

Also, all implementations must support reference type 0 (aka "full =
certificate").

	jakob

From: Warren Kumari <[email-masked]>
Date: Sat, 26 Feb 2011 20:27:16 -0500
To: [email-masked]
Subject: Re: [keyassure] [dane] protocol #19 (new): Format for TLSA DNS lookup.

I believe that this issue has been addressed, both in numerous =
discussions and in version -05 of the draft, section 2.1 ("Requested =
Domain Name")

No-one has objected to the text in the section, so I'm closing this =
issue.   If you do object to the text, you must offer alternative =
(better!)  text...

W

[ DANE is also beta testing the email2trac functionality -- this should =
show up in the issue tracker ]=

Date: Fri, 25 Feb 2011 14:02:38 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto algorithms and certificate types are mandatory to implement"

On 2/25/11 1:31 PM, Warren Kumari wrote:
> Hi all,
>
> While we are all ruminating on the other issues, I figured we might as
> well try address this one:
>
> Need to specify which crypto algorithms and certificate types are
> mandatory to implement -- http://trac.tools.ietf.org/wg/dane/trac/ticket/21
>
> Description:
> Currently, the draft is silent on which crypto algorithms and
> certificate types must be implemented for interoperability. It should be
> specific before the document is finished.

Certificate type:

- Writing both type 1 and 2 must be supported by all DNS implementations

- Processing type 1 must be supported by all TLS clients.

- Processing type 2 should be supported by all TLS clients. The 
exceptions are TLS clients that do not use the PKIX certificate format 
for trust anchors.

Hash algorithm:

- All implementations must support SHA-256.

- All implementations should have the facility to later use other hash 
algorithms.

Date: Fri, 25 Feb 2011 16:52:06 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Warren Kumari <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto algorithms and certificate types are mandatory to implement"

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

Currently, the only digest algorithm that can be recommended is SHA-2

We really do need SHA2 in here as a MUST, unless we are still discussing
this when the SHA3 competition results are out.

I would strongly suggest NOT supporting SHA1 in any form.

On Fri, Feb 25, 2011 at 4:31 PM, Warren Kumari <[email-masked]> wrote:

> Hi all,
>
> While we are all ruminating on the other issues, I figured we might as well
> try address this one:
>
> Need to specify which crypto algorithms and certificate types are mandatory
> to implement -- http://trac.tools.ietf.org/wg/dane/trac/ticket/21
>
> Description:
> Currently, the draft is silent on which crypto algorithms and certificate
> types must be implemented for interoperability. It should be specific before
> the document is finished.
>
>
> W
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

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

Currently, the only digest algorithm that can be recommended is SHA-2<div><=
br></div><div>We really do need SHA2 in here as a MUST, unless we are still=
 discussing this when the SHA3 competition results are out.</div><div><br>
</div><div><div><br></div><div>I would strongly suggest NOT supporting SHA1=
 in any form.<br><br><div class=3D"gmail_quote">On Fri, Feb 25, 2011 at 4:3=
1 PM, Warren Kumari <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]=
et">[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 all,<br>
<br>
While we are all ruminating on the other issues, I figured we might as well=
 try address this one:<br>
<br>
Need to specify which crypto algorithms and certificate types are mandatory=
 to implement -- <a href=3D"http://trac.tools.ietf.org/wg/dane/trac/ticket/=
21" target=3D"_blank">http://trac.tools.ietf.org/wg/dane/trac/ticket/21</a>=
<br>

<br>
Description:<br>
Currently, the draft is silent on which crypto algorithms and certificate t=
ypes must be implemented for interoperability. It should be specific before=
 the document is finished.<br>
<br>
<br>
W<br>
_______________________________________________<br>
keyassure 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/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>
</div></div>

--001636c5bc0f4fd965049d225780--

From: Warren Kumari <[email-masked]>
To: [email-masked]
Date: Fri, 25 Feb 2011 16:31:40 -0500
Subject: [keyassure] Opening issue #21: "Need to specify which crypto algorithms and certificate types are mandatory to implement"

Hi all,

While we are all ruminating on the other issues, I figured we might as  
well try address this one:

Need to specify which crypto algorithms and certificate types are  
mandatory to implement -- http://trac.tools.ietf.org/wg/dane/trac/ticket/21

Description:
Currently, the draft is silent on which crypto algorithms and  
certificate types must be implemented for interoperability. It should  
be specific before the document is finished.

W

From: Warren Kumari <[email-masked]>
To: [email-masked]
Date: Fri, 25 Feb 2011 12:15:29 -0500
Subject: [keyassure] Meeting in Prague.

Hello all.

We have been granted a meeting slot in Prague.

If anyone wants agenda time to discuss things *in our charter*, let  
the chairs know well ahead of time so that we can schedule you.
TLS is also scheduled to meet -- if what you want to discuss involves  
changes to TLS (like bare keys), please take it to TLS....

Also, if you want  to suggest something like TLSA for a non-TLS  
protocol that doesn't already have keys, that is fine too, *as long as  
you have a published draft before the meeting*.

Cutoff date for -00 submissions:
2011-03-07 (Monday): Internet Draft Cut-off for initial document (-00)  
submission by 17:00 PT (01:00 Tuesday, March 8 UTC), upload using IETF  
ID Submission Tool.

Thank you and hope to see you in Prague!
W

Date: Fri, 25 Feb 2011 15:12:31 +0000
From: Ben Laurie <[email-masked]>
To: Stephen Kent <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-04.txt

On 22 February 2011 01:01, Stephen Kent <[email-masked]> wrote:
>> ...
>> =A0>
>>>
>>> =A0I agree that the info in the record could be a TA, and not a CA, but=
 not
>>> if
>>> =A0the format of the data is an X.509 cert.
>>
>> You said a minute ago: "if you issue an X.509 cert under which other
>> certs will be validated,
>> you are a CA."
>
> yep.
>
>> This sounds correct to me. However, mostly what's being done here is
>> _not_ the issuing of X.509 certs under which other certs will be
>> validated (though it is an option), so most times the zone operator is
>> not a CA.
>
> I though one option was to place a cert in the DNS and use it as the
> basis for validating a cert chain that terminates at the EE cert for the
> web site. =A0If so, then that cert is used to validate other certs and
> it would generally be viewed as a CA cert. =A0I admit that some ambiguity
> arises when the cert is viewed as a TA. The ambiguity arises because In
> general,
> if you issue a cert, you are a CA

Eh? If I make a self-signed cert, am I a CA?

If I publish an EE cert issued by someone else, am I a CA?

Presumably at least one of these is a "no", so the zone operator is
not necessarily a CA. This was my point.

>, but when a cert used to convey TA data,
> an RP may elect to not check all of the data.
>
> We do have TA format standards that make it clear what data is to be chec=
ked
> and it might be preferable to use them, vs. a self-signed cert (although =
the
> later option might minimize code reuse).
>
>> In any case it does seem worth making clear when we are talking about
>> a PKIX CA vs. any other kind.
>
> It's really =A0not a "PKIX CA" per se; it's an X.509 CA.
>
>> =A0> Also, will not performing PoP be a
>>>
>>> =A0good outcome?
>>
>> What would be the point of proving to myself that I own a key?
>
> It would not be useful to you, but rather to someone who puts it in a
> DNS record, if that someone does so on your behalf. Otherwise that entity
> does not know if the public key really is yours. =A0But, I don't know tha=
t
> this results in a vulnerability for the DANE context.

Ah. If I am asking someone else to update DNS for me, then indeed a
PoP might be appropriate. But surely that's an issue for whatever
protocol I am using for speaking with my DNS provider?

>
> Steve
>

From: Martin Rex <[email-masked]>
To: [email-masked] (Stephen Kent)
Date: Thu, 24 Feb 2011 18:27:32 +0100 (MET)
Cc: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-05.txt
Reply-To: [email-masked]

Stephen Kent wrote:
> 
> At 3:05 PM +0100 2/23/11, Martin Rex wrote:
> >Jakob Schlyter wrote:
> >>
> >>  On 23 feb 2011, at 12.04, Ben Laurie wrote:
> >>
> >>  >         1 -- A PKIX end-entity certificate in DER encoding
> >>  >
> >>  >         2 -- A PKIX certification authority's certificate in DER encoding
> >>
> >>  I agree this is a reasonable clarification.
> >
> >If anything, I would really prefer something like
> >
> >    1 -- An end-entity X.509 certificate in ASN.1 DER encoding
> >
> >    2 -- A certification authority's X.509 certificate in ASN.1 DER encoding
> >
> 
> In the IETF, PKIX profiles X.509 for use with IETF security protocols,
> so it probably makes sense to stick with the PKIX label here. This is 
> certainly true for EE certs. For a self-signed cert used to convey 
> trust anchor material, we may need some additional/different text.

But this would imply that EE certs will have to be issued by commercial CAs.

I thought that one of the purposes of DANE was to allow server admins
to create their own certificate and distribute it through DNS(SEC) TLSA
records.

Maybe we should distinguish more types:

   1 -- An end-entity X.509 certificate in ASN.1 DER encoding

   2 -- A certification authority's X.509 certificate in ASN.1 DER encoding

   3 -- An end-entity PKIX certificate from the TLS X.509 PKI

   4 -- A certification authority's PKIX certificate from the TLS X.509 PKI

For (1), the client would match the server certificate with the TLSA
record and be done with it, for (3), besides matching the server certificate
with the TLSA record, the client is expected to perform a regular
certificate path validation.

-Martin

From: Peter Gutmann <[email-masked]>
To: [email-masked], [email-masked]
Date: Thu, 24 Feb 2011 16:56:46 +1300
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-05.txt

Paul Hoffman <[email-masked]> writes:

>X.509 is a standard that does not contain all of the extensions created by 
>the PKIX Working Group in the IETF. Using "PKIX" makes it clear that we are 
>talking about certificates with the IETF extensions, not certificates missing 
>them.

This is just getting excessively pedantic. Everyone knows what an "X.509 
certificate" is, standards have been specifying this for years and 
implementers have been able to work with them without having to say "An X.509 
certificate conformant to the PKIX profile encoded using X.690 ASN.1 DER 
encoding". In any case since conformance to X.509, PKIX, and DER is more or 
less arbitrary, if you truly required strict X.509 + PKIX + DER, hundreds of 
thousands/millions of certs out there would fail to meet the spec. All you 
need to say is "a vaguely certificate-shaped object", which "X.509 cert" does 
admirably.

Peter.

Date: Wed, 23 Feb 2011 21:08:50 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-05.txt

At 3:05 PM +0100 2/23/11, Martin Rex wrote:
>Jakob Schlyter wrote:
>>
>>  On 23 feb 2011, at 12.04, Ben Laurie wrote:
>>
>>  >         1 -- A PKIX end-entity certificate in DER encoding
>>  >
>>  >         2 -- A PKIX certification authority's certificate in DER encoding
>>
>>  I agree this is a reasonable clarification.
>
>If anything, I would really prefer something like
>
>    1 -- An end-entity X.509 certificate in ASN.1 DER encoding
>
>    2 -- A certification authority's X.509 certificate in ASN.1 DER encoding
>

In the IETF, PKIX profiles X.509 for use with IETF security protocols,
so it probably makes sense to stick with the PKIX label here. This is 
certainly true for EE certs. For a self-signed cert used to convey 
trust anchor material, we may need some additional/different text.

Steve

Date: Wed, 23 Feb 2011 22:23:10 -0500
To: Scott Schmit <[email-masked]>
From: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Interpreting certificates (and summary)

Scott,

Sorry my reply got stuck in my outbox for a day or so.

>On Mon, Feb 21, 2011 at 08:38:43PM -0500, Stephen Kent wrote keyassure:
>>  At 9:45 AM -0500 2/21/11, Scott Schmit wrote:
>>  For DANE we should generate a profile indicating what extensions
>>  MUST be present, MUST be omitted, MAY be present, etc.  We also can
>>  limit the types of values allowed in standard cert fields, to further
>>  simplify generation  and parsing. This is what we did for SIDR.
>
>This assumes that the only certificates that you're interested in using
>with DANE are newly-generated self-signed certificates. What does a web
>site like Amazon or IETF do if they don't want to break existing users
>that don't have DANE support and don't want to setup dane.amazon.com or
>dane.ietf.org? If the rules defined for DANE-compatible certs happen
>to be what they already have, then great, but will that work for all the
>existing certs out there?

I was describing constraints for a cert to be stored in the DNS,
and to be used as a CA/TA. These are newly-generated certs, and I was
addressing the arguments about the potential complexity of using X.509
certs for this purpose.

So, is the motivation here that Amazon wants to use DANE to protect itself
from rogue TAs in browsers?  An X.509 EE cert contains the name of its issuer.
The problem with trying to have the same EE cert be verified by the 
existing, browser-based TA and a TA acquired via DANE, is that they 
would need to have the same Subject name. If that name must match the 
DNS name from which the record was obtained, there is a problem :-) 
trying to convey or reference a common TA.

>I could also imagine putting a CA certificate in the DNS so that the
>organization doesn't need to deal with renewing the CA cert and also
>updating the DNS. EEs have no control over the CA's certs.

What CA cert? A web site has an EE cert, it does mot have a CA cert
to renew (typically). Did you mean not renewing its EE cert?

>...
>  > Not sure what you mean here by "sanitizing."
>
>Not letting the nasty stuff through. Not saying they never make
>mistakes, but stuff that causes outright vulnerabilities I would imagine
>they fix (even if it takes a public shaming first).

I don't know that ASN.1 parsing vulnerabilities are still a valid 
concern, but at least I understand your point.

>  > >Even if we reuse pieces of what's there, they're still invasive changes
>>  >to ASN.1/X.509 parsing code--the very stuff that has had all those
>>  >problems. Also, the non-DANE case isn't going away overnight, so both
>>  >cases must still be covered (complicating the logic), and the more
>>  >difficult DANE is to adopt, the less overnight it'll be.
>>
>>  What non-DANE cases do you have in mind?
>
>The status quo today--the world without DANE.

I now understand what the "non-DANE" cases are, but I don't 
understand your argument. The way the DANE doc reads mow, there do 
not appear to be any changes to cert parsing.

>  > >* Validity vs RRSIG period [take the min period]
>>
>>  This need mot be an issue. You will process the DNS TTL first, and reject
>>  the record if it is expired. If the TTL is OK, then why not process the
>>  cert validity interval separately, when performing cert path validation.
>
>I probably misstated my intent. What you described is what I meant. It's
>probably better stated as "obey both".

OK.

>  > >* CRLs/OCSP vs TTL [Use both if CRL/OCSP is indicated]
>>
>>  TTL is not really equivalent to a CRL or OCSP. It is analogous to the
>>  cert validity interval. The question here is whether a cert retrieved from
>>  the DNS is a TA, or not.  if it is, then it will not be revoked via
>>  a CRL or OCSP, buy the very nature of a TA. But, if the cert is not
>>  a TA, the question of what sort of revocation mechanism is used is
>>  relevant.
>
>I shouldn't have put TTL there. Martin Rex points out TTL isn't covered
>by DNSSEC (and how can it be? it's supposed to count down!), so for as
>long as the RRSIG is valid, an attacker can simply keep resending the
>same record any time the TTL expires. Instead, it's RRSIG (or something
>else).
>
>While you're right that the RRSIG period is basically a validity period,
>it's also not quite the same because of who is doing the signing. With
>CAs today, no one would tolerate a validity of two weeks because they'd
>need to get a cert reissued from the CA constantly. On the other hand,
>shorter periods are typical in DNSSEC. By having the signing keys,
>making the RRSIG period be short isn't so onerous as long as you can
>automate the process.

Some folks issue very short lifetime certs already. It is not done by
CAs where the process costs $, but that would not be a requirement 
for DANE-based certs.  SO, I still think that it is a mistake to 
compare the
RSIG period with a revocation mechanism like CRLs or OCSP.

>  > >* CA flag, path length, etc vs the dane-04 cert type [???]
>>
>>  The Basic Constraints extension needs to be present in a CA cert, but
>>  the path length field is rarely used, and I would profile it away for DANE.
>
>Which works for new certs but not existing ones.

At first I thought that Rex had cited an example of Entrust using a 
v1 cert. But, upon further discussion with him I learned that what he 
was saying is that Entrust has several non-conforming v3 certs in 
some browsers, e.g., certs without a basic constraint extension or 
with such an extension, but not marked critical, etc. None of these 
bad certs have path length in them, so I think that is a red herring.

>
>>  >Other tricky things to resolve:
>>  >* How do EV certs fit in? (Whatever rules we come up with to process
>>  >  subjects can't break the link to EV certs or make it over-permissive)
>>
>>  I don't understand the context here. Are you talking about sites
>>  that have EV certs and want to also use DANE mechanisms?
>
>Yes.

EV certs are issued on the basis of a CA having been audited, and
promising to follow certain procedures when issuing EV certs.  A web site
that wants to use DANE to issue its own CA/TA is not a valid EV cert issuer
absent such an audit.

So, only if there is a way to use DANE to point to the extant EV cert issuer
would it be reasonable to use DANE and simultaneously preserve the EV property
of an extant web site (EE) cert.

Steve

Date: Wed, 23 Feb 2011 17:23:58 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Interpreting certificates (and summary)

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

Which is a profile of X.509 V3:

This memo profiles the X.509 v3 certificate and X.509 v2 certificate
   revocation list (CRL) for use in the Internet.  An overview of this
   approach and model is provided as an introduction.  The X.509 v3
   certificate format is described in detail, with additional
   information regarding the format and semantics of Internet name
   forms.  Standard certificate extensions are described and two
   Internet-specific extensions are defined.

It is pretty important to specify the version number since we are going to
need to revisit the format in the next 40 years as the date field was
botched.

On Wed, Feb 23, 2011 at 5:01 PM, Paul Hoffman <[email-masked]> wrote:

> On 2/23/11 1:03 PM, Zack Weinberg wrote:
>
>> Could we short-circuit this entire argument by deferring to the
>> protocol being secured for the certificate format?  Concretely,
>> wording like
>>
>>       [...] The types defined in this document are:
>>
>>          1 -- An end-entity certificate, in the wire format used by
>> the protocol being secured
>>          2 -- A certification authority's certificate, ditto
>>
>
> The WG already agreed that "the protocol being secured" is TLS, as the
> current draft states. TLS has exactly one certificate type: PKIX
> certificates in the format given in RFC 5280. (There is a
> non-standards-track extension to allow OpenPGP certificates.)
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

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

Which is a profile of X.509 V3:<div><br></div><div><meta charset=3D"utf-8">=
<span class=3D"Apple-style-span" style=3D"font-family: Times; font-size: me=
dium; "><pre style=3D"word-wrap: break-word; white-space: pre-wrap; ">This =
memo profiles the X.509 v3 certificate and X.509 v2 certificate
   revocation list (CRL) for use in the Internet.  An overview of this
   approach and model is provided as an introduction.  The X.509 v3
   certificate format is described in detail, with additional
   information regarding the format and semantics of Internet name
   forms.  Standard certificate extensions are described and two
   Internet-specific extensions are defined.</pre></span><div><br></div>It =
is pretty important to specify the version number since we are going to nee=
d to revisit the format in the next 40 years as the date field was botched.=
</div>
<div><br></div><div><br><div class=3D"gmail_quote">On Wed, Feb 23, 2011 at =
5:01 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><div></div><div class=3D"h5">On 2/23/11 1:03 PM, Zack Weinberg wrote:<=
br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Could we short-circuit this entire argument by deferring to the<br>
protocol being secured for the certificate format? =A0Concretely,<br>
wording like<br>
<br>
 =A0 =A0 =A0 [...] The types defined in this document are:<br>
<br>
 =A0 =A0 =A0 =A0 =A01 -- An end-entity certificate, in the wire format used=
 by<br>
the protocol being secured<br>
 =A0 =A0 =A0 =A0 =A02 -- A certification authority&#39;s certificate, ditto=
<br>
</blockquote>
<br></div></div>
The WG already agreed that &quot;the protocol being secured&quot; is TLS, a=
s the current draft states. TLS has exactly one certificate type: PKIX cert=
ificates in the format given in RFC 5280. (There is a non-standards-track e=
xtension to allow OpenPGP certificates.)<div>
<div></div><div class=3D"h5"><br>
_______________________________________________<br>
keyassure 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/keyassure" target=3D"_blan=
k">https://www.ietf.org/mailman/listinfo/keyassure</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>

--00151747c0709a142c049cfa8d98--

Sender: [email-masked]
Date: Wed, 23 Feb 2011 14:20:41 -0800
From: Zack Weinberg <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Interpreting certificates (and summary)

On Wed, Feb 23, 2011 at 2:01 PM, Paul Hoffman <[email-masked]> wrote:
> On 2/23/11 1:03 PM, Zack Weinberg wrote:
>>
>> Could we short-circuit this entire argument by deferring to the
>> protocol being secured for the certificate format?
>
> The WG already agreed that "the protocol being secured" is TLS, as the
> current draft states. TLS has exactly one certificate type: PKIX
> certificates in the format given in RFC 5280. (There is a
> non-standards-track extension to allow OpenPGP certificates.)

Right.  My suggested edit isn't meant to be a semantic change, just to
arrange that we can stop arguing about what that certificate format is
called.

... It does also mean that OpenPGP-cert extension, if it ever becomes
popular, could also be accomodated by cert types 1 and 2, because they
would still be "certificates in the wire format used by the protocol".
 Personally I see that as a good thing, because (one fervently hopes)
the OpenPGP format is unambiguously distinguishable from the X.509
format, so putting that information into the RR metadata would be a
redundancy and open the possibility of the two being out of sync.

... Come to think of it, the distinction between cert types 1 and 2
(end entity or CA) is *also* a redundancy (with the isCA field and/or
the key usage restrictions) that should perhaps be eliminated.  Why
not just use type 1 for both, and have the client's processing pay
attention to the cert's self-description?  (This is not a rhetorical
question; maybe there's a good reason I don't know about.)

zw

Date: Wed, 23 Feb 2011 14:01:17 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Interpreting certificates (and summary)

On 2/23/11 1:03 PM, Zack Weinberg wrote:
> Could we short-circuit this entire argument by deferring to the
> protocol being secured for the certificate format?  Concretely,
> wording like
>
>        [...] The types defined in this document are:
>
>           1 -- An end-entity certificate, in the wire format used by
> the protocol being secured
>           2 -- A certification authority's certificate, ditto

The WG already agreed that "the protocol being secured" is TLS, as the 
current draft states. TLS has exactly one certificate type: PKIX 
certificates in the format given in RFC 5280. (There is a 
non-standards-track extension to allow OpenPGP certificates.)

Sender: [email-masked]
Date: Wed, 23 Feb 2011 13:03:58 -0800
From: Zack Weinberg <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], Phillip Hallam-Baker <[email-masked]>
Subject: Re: [keyassure] Interpreting certificates (and summary)

Could we short-circuit this entire argument by deferring to the
protocol being secured for the certificate format?  Concretely,
wording like

      [...] The types defined in this document are:

         1 -- An end-entity certificate, in the wire format used by
the protocol being secured
         2 -- A certification authority's certificate, ditto

zw

From: Martin Rex <[email-masked]>
To: [email-masked] (Phillip Hallam-Baker)
Date: Wed, 23 Feb 2011 21:39:32 +0100 (MET)
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] Interpreting certificates (and summary)
Reply-To: [email-masked]

It seems were quoting / replying to the wrong mail.

Phillip Hallam-Baker wrote:
> 
> BER encoding is supported by practically every ASN.1 library. It is
> identical semantically to DER which is a pain in the patootie.
> 
> From a drafting perspective, I would first state that the identifier
> corresponds to an X.509v3 cert without mentioning encoding at all.

I don't think that mentioning the encoding creates a problem.  My main
concern at this point was about "DER" alone rather than "ASN.1 DER".

> 
> Then I would follow that with a statement that the TLS protocol requires
> certificates to conform to the X.509v3 requirement for DER encoding and the
> requirements of the PKIX certificate profile.

Which is pretty much plain wrong.  ;-)

Nothing in TLS precludes the use of X.509v1 certs,
The last sentence of Section 1 of all TLS documents (2246,4346,5246) reads:

                         The TLS standard, however, does not specify how
   protocols add security with TLS; 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.

Which clearly explains that PKIX is just one possible approach to
interpreting the certificates exchange -- and definitely not the
only one.

Similarily, RFC-2818, the informational RFC which describes how
"HTTP Over TLS" is commonly performed says this:

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

Which describes a case where the TLS server certificate matching
is a PKIX-free memcmp() on X.509 certificates.

> 
> Specifying X.509v3

If you keep sticking the v3 onto X.509, then you're creating
a necessity for a bare public key format.

While I'm pretty sure that self-signed end-entity X.509v1 certs
interoperate with all TLS implementations I've tested, I'm not aware
of a definition of a self-signed EndEntity X.509v3 cert (that isn't
in conflict with some version of X.509v3).

>                    in DER encoding may appear to be more precise and less
> ambiguous, but might well actually introduces ambiguity since another
> interpretation of the statement is that there should be an additional ASN.1
> structure wrapping the cert.

If there was a wrapping ASN.1 structure, it would be named and its
ASN.1 definition appear in an Appendix of the document.  I don't think
that the document will grow the necessary level of ambiguity for this
to happen.

-Martin

Date: Wed, 23 Feb 2011 14:45:31 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: [email-masked]
Cc: Scott Schmit <[email-masked]>, [email-masked]
Subject: Re: [keyassure] Interpreting certificates (and summary)

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

BER encoding is supported by practically every ASN.1 library. It is
identical semantically to DER which is a pain in the patootie.

>From a drafting perspective, I would first state that the identifier
corresponds to an X.509v3 cert without mentioning encoding at all.

Then I would follow that with a statement that the TLS protocol requires
certificates to conform to the X.509v3 requirement for DER encoding and the
requirements of the PKIX certificate profile.

Specifying X.509v3 in DER encoding may appear to be more precise and less
ambiguous, but might well actually introduces ambiguity since another
interpretation of the statement is that there should be an additional ASN.1
structure wrapping the cert.

On Wed, Feb 23, 2011 at 1:57 PM, Martin Rex <[email-masked]> wrote:

> Scott Schmit wrote:
> >
> > An item for security considerations:
> > * Now that CAs aren't necessarily issuing these certs, the client needs
> >   to be much more careful in its parsing (the null terminated vs length-
> >   delimited string bug comes to mind)
>
> This sounds somewhat strange to me.
>
> When doing TLS authentication of a peer, the peer's certificate
> is always untrusted at the time when it is parsed.  Parsing the
> received X.509 cert is a prerequisite to being able to validate
> the cert and determining whether it is trusted/trustworthy or not.
>
> An ASN.1 parser that is not careful is an unconditionally bad idea
> and asking for trouble; lots of trouble.  Tolerance to common
> bugs of encodings produced by peers should never be accepted
> "by accident", only by conscious trade-off decisions that are
> clearly documented for the caller/consumer of the technology.
>
>
> -Martin
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

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

BER encoding is supported by practically every ASN.1 library. It is identic=
al semantically to DER which is a pain in the patootie.<div><br></div><div>=
<br></div><div>From a drafting perspective, I would first state that the id=
entifier corresponds to an X.509v3 cert without mentioning encoding at all.=
=A0</div>
<div><br></div><div>Then I would follow that with a statement that the TLS =
protocol requires certificates to conform to the X.509v3 requirement for DE=
R encoding and the requirements of the PKIX certificate profile.</div><div>
<br></div><div><br></div><div>Specifying X.509v3 in DER encoding may appear=
 to be more precise and less ambiguous, but might well actually introduces =
ambiguity since another interpretation of the statement is that there shoul=
d be an additional ASN.1 structure wrapping the cert.</div>
<div><br></div><div><br><div class=3D"gmail_quote">On Wed, Feb 23, 2011 at =
1:57 PM, Martin Rex <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">m=
[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">Scott Schmit wrote:<br>
&gt;<br>
&gt; An item for security considerations:<br>
&gt; * Now that CAs aren&#39;t necessarily issuing these certs, the client =
needs<br>
&gt; =A0 to be much more careful in its parsing (the null terminated vs len=
gth-<br>
&gt; =A0 delimited string bug comes to mind)<br>
<br>
</div>This sounds somewhat strange to me.<br>
<br>
When doing TLS authentication of a peer, the peer&#39;s certificate<br>
is always untrusted at the time when it is parsed. =A0Parsing the<br>
received X.509 cert is a prerequisite to being able to validate<br>
the cert and determining whether it is trusted/trustworthy or not.<br>
<br>
An ASN.1 parser that is not careful is an unconditionally bad idea<br>
and asking for trouble; lots of trouble. =A0Tolerance to common<br>
bugs of encodings produced by peers should never be accepted<br>
&quot;by accident&quot;, only by conscious trade-off decisions that are<br>
clearly documented for the caller/consumer of the technology.<br>
<font color=3D"#888888"><br>
<br>
-Martin<br>
</font><div><div></div><div class=3D"h5">__________________________________=
_____________<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>
</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>

--001636c5a8a4f1c855049cf85667--

From: Martin Rex <[email-masked]>
To: [email-masked] (Scott Schmit)
Date: Wed, 23 Feb 2011 19:57:28 +0100 (MET)
Cc: [email-masked]
Subject: Re: [keyassure] Interpreting certificates (and summary)
Reply-To: [email-masked]

Scott Schmit wrote:
> 
> An item for security considerations:
> * Now that CAs aren't necessarily issuing these certs, the client needs
>   to be much more careful in its parsing (the null terminated vs length-
>   delimited string bug comes to mind)

This sounds somewhat strange to me.

When doing TLS authentication of a peer, the peer's certificate
is always untrusted at the time when it is parsed.  Parsing the
received X.509 cert is a prerequisite to being able to validate
the cert and determining whether it is trusted/trustworthy or not.

An ASN.1 parser that is not careful is an unconditionally bad idea
and asking for trouble; lots of trouble.  Tolerance to common
bugs of encodings produced by peers should never be accepted
"by accident", only by conscious trade-off decisions that are
clearly documented for the caller/consumer of the technology.

-Martin

Date: Wed, 23 Feb 2011 08:44:28 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-05.txt

On 2/23/11 8:29 AM, Martin Rex wrote:
> "PKIX certificates" looks somewhat undefined to me.

Would "PKIX [RFC5280] certificates" define it better?

> For me, it suggests the rules defined in rfc-5280 for X.509v3 End-entity
> and CA path certificates only, but excludes both TrustAnchors and
> self-signed X.509v1 certs for use as public key containers.

Why do you feel that the latter two are excluded? I admit that I may be 
missing something, but I don't see anything in 5280 or in TLS that 
prohibits either. We might need to add text in our document explicitly 
calling them out as OK, but not much more, do we?

From: Martin Rex <[email-masked]>
To: [email-masked] (Paul Hoffman)
Date: Wed, 23 Feb 2011 17:29:23 +0100 (MET)
Cc: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-05.txt
Reply-To: [email-masked]

Paul Hoffman wrote:
> 
> On 2/23/11 6:05 AM, Martin Rex wrote:
> > Jakob Schlyter wrote:
> >>
> >> On 23 feb 2011, at 12.04, Ben Laurie wrote:
> >>
> >>>          1 -- A PKIX end-entity certificate in DER encoding
> >>>
> >>>          2 -- A PKIX certification authority's certificate in DER encoding
> >>
> >> I agree this is a reasonable clarification.
> >
> > If anything, I would really prefer something like
> >
> >     1 -- An end-entity X.509 certificate in ASN.1 DER encoding
> >
> >     2 -- A certification authority's X.509 certificate in ASN.1 DER encoding
> 
> X.509 is a standard that does not contain all of the extensions created 
> by the PKIX Working Group in the IETF. Using "PKIX" makes it clear that 
> we are talking about certificates with the IETF extensions, not 
> certificates missing them.

"PKIX certificates" looks somewhat undefined to me.

For me, it suggests the rules defined in rfc-5280 for X.509v3 End-entity
and CA path certificates only, but excludes both TrustAnchors and
self-signed X.509v1 certs for use as public key containers.

-Martin

Date: Wed, 23 Feb 2011 08:05:17 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-05.txt

On 2/23/11 6:05 AM, Martin Rex wrote:
> Jakob Schlyter wrote:
>>
>> On 23 feb 2011, at 12.04, Ben Laurie wrote:
>>
>>>          1 -- A PKIX end-entity certificate in DER encoding
>>>
>>>          2 -- A PKIX certification authority's certificate in DER encoding
>>
>> I agree this is a reasonable clarification.
>
> If anything, I would really prefer something like
>
>     1 -- An end-entity X.509 certificate in ASN.1 DER encoding
>
>     2 -- A certification authority's X.509 certificate in ASN.1 DER encoding

X.509 is a standard that does not contain all of the extensions created 
by the PKIX Working Group in the IETF. Using "PKIX" makes it clear that 
we are talking about certificates with the IETF extensions, not 
certificates missing them.

From: Martin Rex <[email-masked]>
To: [email-masked] (Jakob Schlyter)
Date: Wed, 23 Feb 2011 15:05:06 +0100 (MET)
Cc: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-05.txt
Reply-To: [email-masked]

Jakob Schlyter wrote:
> 
> On 23 feb 2011, at 12.04, Ben Laurie wrote:
> 
> >         1 -- A PKIX end-entity certificate in DER encoding
> > 
> >         2 -- A PKIX certification authority's certificate in DER encoding
> 
> I agree this is a reasonable clarification.

If anything, I would really prefer something like

   1 -- An end-entity X.509 certificate in ASN.1 DER encoding

   2 -- A certification authority's X.509 certificate in ASN.1 DER encoding

-Martin

From: Jakob Schlyter <[email-masked]>
Date: Wed, 23 Feb 2011 13:07:37 +0100
To: Ben Laurie <[email-masked]>
Cc: keyassure <[email-masked]>
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-05.txt

On 23 feb 2011, at 12.04, Ben Laurie wrote:

>         1 -- A PKIX end-entity certificate in DER encoding
> 
>         2 -- A PKIX certification authority's certificate in DER encoding

I agree this is a reasonable clarification.

	jakob

Date: Wed, 23 Feb 2011 11:04:24 +0000
From: Ben Laurie <[email-masked]>
To: Jakob Schlyter <[email-masked]>
Cc: keyassure <[email-masked]>
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-05.txt

On 23 February 2011 07:06, Jakob Schlyter <[email-masked]> wrote:
> On 23 feb 2011, at 08.00, [email-masked] wrote:
>
>> A New Internet-Draft is available from the on-line Internet-Drafts direc=
tories.
>> This draft is a work item of the DNS-based Authentication of Named Entit=
ies Working Group of the IETF.
>>
>>
>> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Using Secure DNS to Associate Ce=
rtificates with Domain Names For TLS
>> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : P. Hoffman, J. Schlyter
>> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-dane-protocol-05.txt
>> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 12
>> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-02-22
>
> We've made some updates and clarifications based on input from Scott Schm=
it and others, and also addressed issue #20.
> Diff and full history can be found at http://tools.ietf.org/wg/dane/draft=
-ietf-dane-protocol/.

In this version you define cert types like this:

         1 -- An end-entity certificate in DER encoding

         2 -- A certification authority's certificate in DER encoding

and later say:

   Certificate types 1 and 2 explicitly only apply to PKIX-formatted
   certificates.  If TLS allows other formats later, or if extensions to
   this protocol are made that accept other formats for certificates,
   those certificates will need certificate types.

Since DER encoding can be applied to anything specified in ASN.1,
perhaps this explicitness should be in the definitions, e.g.:

         1 -- A PKIX end-entity certificate in DER encoding

         2 -- A PKIX certification authority's certificate in DER encoding

From: Peter Gutmann <[email-masked]>
To: [email-masked]
Date: Wed, 23 Feb 2011 21:08:27 +1300
Cc: [email-masked]
Subject: Re: [keyassure] Interpreting certificates (and summary)

Martin Rex <[email-masked]> writes:

>While in theory, it should be possible to ASN.1 re-encode -- I would be
>careful.  There are CAs out there with defective PKI-Software, distributing
>X.509 certs that are not valid ASN.1 DER.

You never, ever try to re-encode certs, because waaaay too many of them break
if you try it.  This has been standard practice for about 15-20 years now, the
rule of thumb is "there is only one (re-)encoding rule and its name is
memcpy()" (with a corollay of "there is only one X.500 name comparison rule
and it's name is memcmp()").

Peter.

From: Peter Gutmann <[email-masked]>
To: [email-masked], [email-masked]
Date: Wed, 23 Feb 2011 20:28:44 +1300
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of the two fields to have fewer certificate types

Paul Wouters <[email-masked]> writes:

>There is also the OpenPGP container I believe? That might be called
>"certificate" as well?

Yeah, Phil named his key format after the one used by the mechanism that PGP
was diamtrically opposed to (PEM).  How about doing some checking instead of
just inventing things to support your argument?

>Why are not calling it "PKIX certificate" to avoid confusion?

Because it isn't?  At most it's an "X.509 certificate", but "certificate"
pretty much implies that anyway.

Peter.

Date: Wed, 23 Feb 2011 02:07:57 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of

At 7:26 PM +0100 2/22/11, Martin Rex wrote:
>Stephen Kent wrote:
>>  >
>>  >Simplicity and robustness.
>>  >
>>  >When simple public keys for servers are to be used with DANE, these
>>  >will usually be X.509v1 certificates, which do not contain
>>  >a BasicConstraints extension.
>>
>>  Why would they be v1 certs?
>>
>>  We know that using v1 certs introduced vulnerabilities in browsers,
>>  e.g., it enabled EEs to issue subordinate certs.
>
>Getting all X.509v3 attributes into a usable consistent fashion is
>pretty difficult -- and a complete waste if they're supposed to be
>entirely ignored.

I agree, but that seems orthogonal to what I proposed, i.e., a profile
for certs that would be stored in TLSA records.

>Also self-signed X.509v3 End-Entity certs don't really exist.

I agree that if the cert is self-signed, it should, be a CA cert based
on fundamental X.509/PKIX rules, but if an SS cert is a TA package, this
is a bit less clear.

>I know that self-signed X.509v1 certs work fine with TLS implementations.
>I wouldn't know which exact attributes I would have to add to a
>self-signed X.509v3 certificate in order to not run into interop
>problems.  E.g. a KeyUsage constraint _without_ keyCertSign in an
>X.509v3 self-signed certificate would obviously be self-contradictory.

because a self-signed cert used as a TA pkg is special, it's hard to argue what
is required.

>  > I thought that browsers were fixed and that most commercial CAs used
>  > v3 certs now, since v3 has been the current standard for a very long
>>  time. I'm surprised to hear that Entrust still has a v1 cert out
>>  there
>
>That Entrust cert is a v3 cert -- which is why our software rejects it.

I (and I think some others) got the opposite impression from your 
message.  Nevermind.

>But it seems that most other PKI-Software (MS-CryptoAPI, Firefox, ...)
>did not complain about this malformed X.509v3 TrustAnchor, because they're
>shipping it as trust anchor.

I can believe that, because if you view it as a TA package, then there are
no hard and fast rules about what needs to be verified.

>  > Anyway, why should we think in terms of v1 certs for servers at this
>  > point in time? Do you statistics that suggest that most (many?) web
>>  sites are using v1 certs?  if we're talking about certs that sites
>>  can issue themselves (vs. buying certs), then there is a lot of v3
>>  cert CA SW available.
>
>selfsigned X.509v1 containers are the X.509 public key bag that
>we're looking for for TLSA EE certs -- those where NO PKIX certificate
>path validation is to be performed on the certificate.

You really can't perform path validation on an SS cert, because there 
is no path :-). The issue is what other cert validation checks one 
should perform, and what use one should make of the fields in the 
cert wrt path validation for certs that chain to it.

Steve

From: Jakob Schlyter <[email-masked]>
Date: Wed, 23 Feb 2011 08:06:53 +0100
To: keyassure <[email-masked]>
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-05.txt

On 23 feb 2011, at 08.00, [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           : Using Secure DNS to Associate Certificates =
with Domain Names For TLS
> 	Author(s)       : P. Hoffman, J. Schlyter
> 	Filename        : draft-ietf-dane-protocol-05.txt
> 	Pages           : 12
> 	Date            : 2011-02-22

We've made some updates and clarifications based on input from Scott =
Schmit and others, and also addressed issue #20.
Diff and full history can be found at =
http://tools.ietf.org/wg/dane/draft-ietf-dane-protocol/.

	jakob

From: [email-masked]
To: [email-masked]
Date: Tue, 22 Feb 2011 23:00:01 -0800
Cc: [email-masked]
Subject: [keyassure] I-D Action:draft-ietf-dane-protocol-05.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           : Using Secure DNS to Associate Certificates with Domain Names For TLS
	Author(s)       : P. Hoffman, J. Schlyter
	Filename        : draft-ietf-dane-protocol-05.txt
	Pages           : 12
	Date            : 2011-02-22

TLS and DTLS use certificates for authenticating the server.  Users
want their applications to verify that the certificate provided by
the TLS server is in fact associated with the domain name they
expect.  DNSSEC provides a mechanism for a zone operator to sign DNS
information directly.  This way, bindings of keys to domains are
asserted not by external entities, but by the entities that operate
the DNS.  This document describes how to use secure DNS to associate
the TLS server's certificate with the the intended domain name.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dane-protocol-05.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-protocol-05.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart--

Date: Tue, 22 Feb 2011 19:56:55 -0500
To: Henry Story <[email-masked]>
From: Stephen Kent <[email-masked]>
Cc: WebID Incubator Group WG <[email-masked]>, [email-masked]
Subject: Re: [keyassure] publishing the public key

At 10:17 AM +0100 2/22/11, Henry Story wrote:
>...
>  >
>>  I don't think that most users, who often can't even tell if they 
>>have contacted a TLS-secured site, would think of a public key as 
>>part of the identity for the service. I also don't think that most 
>>of them think about the port either.
>
>I was not speaking to most users but to this group of security 
>specialists during a discussion on a protocol. The public key is a 
>definite description that uniquely identifies the agent for the 
>purpose of computers, not for the general public.

The context you envisioned was not clear from your statement. a 
public key can be a UID for an object, but I'd hesitate to call it 
descriptive.

>...
>
>I am aware of symmetric cryptography's role. But it is public key 
>cryptography that is core in authenticating the server, and setting 
>up the symmetric crypto channel. Symmetric cryptography is used 
>because it is less cpu intensive.

I think it best to be precise when discussing what one would like
to see become a standard.

Steve

Date: Tue, 22 Feb 2011 19:52:44 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Carl Wallace <[email-masked]>
Cc: Phillip Hallam-Baker <[email-masked]>, [email-masked], dane issue tracker <[email-masked]>
Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of the two fields to have fewer certificate types

On Tue, 22 Feb 2011, Carl Wallace wrote:

> > According to the standard, a certificate is not X.509 or PKIX unless DER encoded, thus it is unnecessary to
> specify in either case.�
> 
> True enough but there are plenty of base64 encoded certs kicking around. �Clarifying the hash is calculated
> over the DER encoded certificate seems inoffensive enough while making a useful distinction. �

There is also the OpenPGP container I believe? That might be called "certificate" as well?

Why are not calling it "PKIX certificate" to avoid confusion?

Paul

Date: Tue, 22 Feb 2011 19:51:44 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked], dane issue tracker <[email-masked]>
Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of the two fields to have fewer certificate types

On Tue, 22 Feb 2011, Phillip Hallam-Baker wrote:

> I would also like to see some justification for supporting SHA1 in a new specification. We really want all
> PKIX compliant code to support SHA2 and that is going to need to be the must, so what is the value to having
> SHA1 in there at all?

The reasoning at section 2.2 states:

 	Using the same hash algorithm as is used in
 	the signature in the certificate will make it more likely that the
 	TLS client will understand this TLSA data.

I think a lot (most?) certificates still use SHA1?

Paul

Date: Tue, 22 Feb 2011 19:20:17 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Carl Wallace <[email-masked]>
Cc: [email-masked], dane issue tracker <[email-masked]>
Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of the two fields to have fewer certificate types

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

Then we should specify BINARY as in the MIME specification.

Specifying DER encoding is going to lead some twits to try re-DER encoding.

On Tue, Feb 22, 2011 at 6:47 PM, Carl Wallace <[email-masked]>wrote:

> > According to the standard, a certificate is not X.509 or PKIX unless DER
> encoded, thus it is unnecessary to specify in either case.
>
> True enough but there are plenty of base64 encoded certs kicking around.
>  Clarifying the hash is calculated over the DER encoded certificate seems
> inoffensive enough while making a useful distinction.
>

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

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

Then we should specify BINARY as in the MIME specification.<div><br></div><=
div>Specifying DER encoding is going to lead some twits to try re-DER encod=
ing.<br><br><div class=3D"gmail_quote">On Tue, Feb 22, 2011 at 6:47 PM, Car=
l Wallace <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 style=3D"word-wrap:break-word;color:rg=
b(0, 0, 0);font-size:14px;font-family:Calibri, sans-serif"><div class=3D"im=
"><div>
&gt; According to the standard, a certificate is not X.509 or PKIX unless D=
ER encoded, thus it is unnecessary to specify in either case.=A0</div><div>=
<br></div></div><span><div class=3D"gmail_quote"><div>True enough but there=
 are plenty of base64 encoded certs kicking around. =A0Clarifying the hash =
is calculated over the DER encoded certificate seems inoffensive enough whi=
le making a useful distinction. =A0</div>
</div></span></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>

--00151747c070c12e29049ce80fff--

Date: Tue, 22 Feb 2011 18:47:33 -0500
From: Carl Wallace <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>, Ilari Liusvaara <[email-masked]>
Cc: dane issue tracker <[email-masked]>, [email-masked]
Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of the two fields to have fewer certificate types

> 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_3381245256_2351080
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

> According to the standard, a certificate is not X.509 or PKIX unless DER
encoded, thus it is unnecessary to specify in either case.

True enough but there are plenty of base64 encoded certs kicking around.
Clarifying the hash is calculated over the DER encoded certificate seems
inoffensive enough while making a useful distinction.

--B_3381245256_2351080
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: s=
pace; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size:=
 14px; font-family: Calibri, sans-serif; "><div>&gt; According to the standa=
rd, a certificate is not X.509 or PKIX unless DER encoded, thus it is unnece=
ssary to specify in either case.&nbsp;</div><div><br></div><span id=3D"OLK_SRC=
_BODY_SECTION"><div class=3D"gmail_quote"><div>True enough but there are plent=
y of base64 encoded certs kicking around. &nbsp;Clarifying the hash is calcu=
lated over the DER encoded certificate seems inoffensive enough while making=
 a useful distinction. &nbsp;</div></div></span></body></html>

--B_3381245256_2351080--

Date: Tue, 22 Feb 2011 18:38:20 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Ilari Liusvaara <[email-masked]>
Cc: [email-masked], dane issue tracker <[email-masked]>
Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of the two fields to have fewer certificate types

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

On Tue, Feb 22, 2011 at 5:39 PM, Ilari Liusvaara <
[email-masked]> wrote:

> On Tue, Feb 22, 2011 at 05:06:21PM -0500, Warren Kumari wrote:
> > Ok, so it sounds to me as though their is consensus for this change
> > / text.
> >
> > Please clearly state if I have misread / misunderstood your views,
> > otherwise I'm going to mark it as fixed....
> >
> > W
>
> > On Feb 20, 2011, at 2:59 PM, dane issue tracker wrote:
> >
> > >#20: Change the format of the two fields to have fewer certificate
> > >types
> > >
> > >To reduce the chance that someone could give a certificate type that
> > >doesn't match the hash type, change the fields as follows:
> > >
> > >o  A one-octet value, called "certificate type", specifying the
> > >
> > >      1 -- An end-entity certificate
> > >      2 -- A certification authority's certificate
> > >
> > >o  A one-octet value, called "reference type", specifying how the
> > >
> > >      0 -- Full certificate in DER encoding
> > >      1 -- SHA-1 hash of the certificate in DER encoding
> > >      2 -- SHA-256 hash of the certificate in DER encoding
> > >      3 -- SHA-384 hash of the certificate in DER encoding
> > >
>
> What does DER encoding mean for possible future non-ASN.1 certificate
> types?
>
> I think it should be done this way:
>
> Certificate type:
>      1 -- An end-entity certificate in DER encoding
>      2 -- A certification authority's certificate in DER encoding
>
> Reference type:
>
>      0 -- Full certificate
>       1 -- SHA-1 hash of the certificate
>       2 -- SHA-256 hash of the certificate
>       3 -- SHA-384 hash of the certificate
>
> This way it doesn't assume that future certificate types are
> DER-encodable. The result will be the same with cert types 1 and 2
> anyway.

According to the standard, a certificate is not X.509 or PKIX unless DER
encoded, thus it is unnecessary to specify in either case. Thus I propose
simply:

Object type:
     1 -- An end-entity certificate
     2 -- A certification authority's certificate

Reference type:

     0 -- Full object
     1 -- SHA-1 hash of the object
     2 -- SHA-256 hash of the object
     3 -- SHA-384 hash of the object

I would also like to see some justification for supporting SHA1 in a new
specification. We really want all PKIX compliant code to support SHA2 and
that is going to need to be the must, so what is the value to having SHA1 in
there at all?

I can see choosing values so as not to tread on the DNSSEC hash value
registry, but would prefer to simply specify 'unassigned' than assign a
value to an algorithm we are starting to decommission.

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

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

<br><br><div class=3D"gmail_quote">On Tue, Feb 22, 2011 at 5:39 PM, Ilari L=
iusvaara <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]=
i">[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 Tue, Feb 22, 2011 at 05:06:21PM -0500, Warren Kumari w=
rote:<br>
&gt; Ok, so it sounds to me as though their is consensus for this change<br=
>
&gt; / text.<br>
&gt;<br>
&gt; Please clearly state if I have misread / misunderstood your views,<br>
&gt; otherwise I&#39;m going to mark it as fixed....<br>
&gt;<br>
&gt; W<br>
<br>
&gt; On Feb 20, 2011, at 2:59 PM, dane issue tracker wrote:<br>
&gt;<br>
&gt; &gt;#20: Change the format of the two fields to have fewer certificate=
<br>
&gt; &gt;types<br>
&gt; &gt;<br>
&gt; &gt;To reduce the chance that someone could give a certificate type th=
at<br>
&gt; &gt;doesn&#39;t match the hash type, change the fields as follows:<br>
&gt; &gt;<br>
&gt; &gt;o =A0A one-octet value, called &quot;certificate type&quot;, speci=
fying the<br>
&gt; &gt;<br>
</div><div class=3D"im">&gt; &gt; =A0 =A0 =A01 -- An end-entity certificate=
<br>
&gt; &gt; =A0 =A0 =A02 -- A certification authority&#39;s certificate<br>
&gt; &gt;<br>
&gt; &gt;o =A0A one-octet value, called &quot;reference type&quot;, specify=
ing how the<br>
&gt; &gt;<br>
</div><div class=3D"im">&gt; &gt; =A0 =A0 =A00 -- Full certificate in DER e=
ncoding<br>
&gt; &gt; =A0 =A0 =A01 -- SHA-1 hash of the certificate in DER encoding<br>
&gt; &gt; =A0 =A0 =A02 -- SHA-256 hash of the certificate in DER encoding<b=
r>
&gt; &gt; =A0 =A0 =A03 -- SHA-384 hash of the certificate in DER encoding<b=
r>
&gt; &gt;<br>
<br>
</div>What does DER encoding mean for possible future non-ASN.1 certificate=
<br>
types?<br>
<br>
I think it should be done this way:<br>
<br>
Certificate type:<br>
 =A0 =A0 =A01 -- An end-entity certificate in DER encoding<br>
 =A0 =A0 =A02 -- A certification authority&#39;s certificate in DER encodin=
g<br>
<br>
Reference type:<br>
<br>
 =A0 =A0 =A00 -- Full certificate<br>
<div class=3D"im"> =A0 =A0 =A01 -- SHA-1 hash of the certificate<br>
</div><div class=3D"im"> =A0 =A0 =A02 -- SHA-256 hash of the certificate<br=
>
</div><div class=3D"im"> =A0 =A0 =A03 -- SHA-384 hash of the certificate<br=
>
<br>
</div>This way it doesn&#39;t assume that future certificate types are<br>
DER-encodable. The result will be the same with cert types 1 and 2<br>
anyway.</blockquote><div><br></div><div><br></div><div>According to the sta=
ndard, a certificate is not X.509 or PKIX unless DER encoded, thus it is un=
necessary to specify in either case. Thus I propose simply:</div><div>
<br></div></div><div><br></div><div><meta charset=3D"utf-8">Object type:<br=
>=A0 =A0 =A01 -- An end-entity certificate<br>=A0 =A0 =A02 -- A certificati=
on authority&#39;s certificate<br><br>Reference type:<br><br>=A0 =A0 =A00 -=
- Full object<br>
<div class=3D"im">=A0 =A0 =A01 -- SHA-1 hash of the object<br></div><div cl=
ass=3D"im">=A0 =A0 =A02 -- SHA-256 hash of the=A0object</div><meta charset=
=3D"utf-8"><div class=3D"im">=A0 =A0 =A03 -- SHA-384 hash of the=A0object</=
div><meta charset=3D"utf-8"></div>
<div><br></div><div>I would also like to see some justification for support=
ing SHA1 in a new specification. We really want all PKIX compliant code to =
support SHA2 and that is going to need to be the must, so what is the value=
 to having SHA1 in there at all?</div>
<div><br></div><div>I can see choosing values so as not to tread on the DNS=
SEC hash value registry, but would prefer to simply specify &#39;unassigned=
&#39; than assign a value to an algorithm we are starting to decommission.<=
/div>
<br>-- <br>Website: <a href=3D"http://hallambaker.com/">http://hallambaker.=
com/</a><br><br>

--0016e6dd8942b95870049ce7793c--

Date: Tue, 22 Feb 2011 18:25:53 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [keyassure] Interpreting certificates (and summary)

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

On Tue, Feb 22, 2011 at 5:40 PM, Martin Rex <[email-masked]> wrote:

While in theory, it should be possible to ASN.1 re-encode -- I would
> be careful.  There are CAs out there with defective PKI-Software,
> distributing X.509 certs that are not valid ASN.1 DER.
>

Give people options where getting it wrong will not cause the software to
fail and some people will get it wrong.

> One of the GlobalSign RootCA TrustAnchors, as distributed in Browsers,
> used to be incorrect ASN.1 DER (IIRC, incorrect encoding of
> the unused KeyUsage bits).  Which is probably one reason why some ASN.1
> decoders keep an original copy of the ASN.1 DER ToBeSigned around for
> decoded X.509 certs...

Since none of the roots was DER encoded until quite a few years in, this has
always been true. If you want a cert to work you have to keep the original
binary.

Given that a cert has never been as large as a maximal TCP packet, I have
never considered canonicalization or DER encoding to have any value
whatsoever. It is simply an idiot idea that came up in an X.500 committee
when there was an idea that certs would be stored in X.500 directories.

All that is necessary in a certificate is that the signature validates the
bits presented. It is not a problem if the same semantics could have been
encoded in other bits.

I don't see much value in XML canonicalization either.

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

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

On Tue, Feb 22, 2011 at 5:40 PM, Martin Rex <span dir=3D"ltr">&lt;<a href=
=3D"mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><div class=
=3D"gmail_quote"><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">While in theory, it should be possible to ASN.1 re-encode=
 -- I would</div>
be careful. =A0There are CAs out there with defective PKI-Software,<br>
distributing X.509 certs that are not valid ASN.1 DER.<br></blockquote><div=
><br></div><div>Give people options where getting it wrong will not cause t=
he software to fail and some people will get it wrong.</div><div><br></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;">
One of the GlobalSign RootCA TrustAnchors, as distributed in Browsers,<br>
used to be incorrect ASN.1 DER (IIRC, incorrect encoding of<br>
the unused KeyUsage bits). =A0Which is probably one reason why some ASN.1<b=
r>
decoders keep an original copy of the ASN.1 DER ToBeSigned around for<br>
decoded X.509 certs...</blockquote><div><br></div><div>Since none of the ro=
ots was DER encoded until quite a few years in, this has always been true. =
If you want a cert to work you have to keep the original binary.</div>
<div><br></div><div>Given that a cert has never been as large as a maximal =
TCP packet, I have never considered canonicalization or DER encoding to hav=
e any value whatsoever. It is simply an idiot idea that came up in an X.500=
 committee when there was an idea that certs would be stored in X.500 direc=
tories.</div>
<div>=A0</div></div><div><br></div>All that is necessary in a certificate i=
s that the signature validates the bits presented. It is not a problem if t=
he same semantics could have been encoded in other bits.<div><br></div><div=
>
I don&#39;t see much value in XML canonicalization either.<br clear=3D"all"=
><br>-- <br>Website: <a href=3D"http://hallambaker.com/">http://hallambaker=
.com/</a><br><br>
</div>

--0016e6dd89423b7486049ce74dce--

Date: Tue, 22 Feb 2011 18:17:27 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [keyassure] Interpreting certificates (and summary)

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

On Tue, Feb 22, 2011 at 5:40 PM, Martin Rex <[email-masked]> wrote:

While in theory, it should be possible to ASN.1 re-encode -- I would
> be careful.  There are CAs out there with defective PKI-Software,
> distributing X.509 certs that are not valid ASN.1 DER.
>

Give people options where getting it wrong will not cause the software to
fail and some people will get it wrong.

> One of the GlobalSign RootCA TrustAnchors, as distributed in Browsers,
> used to be incorrect ASN.1 DER (IIRC, incorrect encoding of
> the unused KeyUsage bits).  Which is probably one reason why some ASN.1
> decoders keep an original copy of the ASN.1 DER ToBeSigned around for
> decoded X.509 certs...

Since none of the roots was DER encoded until quite a few years in, this has
always been true. If you want a cert to work you have to keep the original
binary.

Given that a cert has never been as large as a maximal TCP packet, I have
never considered canonicalization or DER encoding to have any value
whatsoever. It is simply an idiot idea that came up in an X.500 committee
when there was an idea that certs would be stored in X.500 directories.

All that is necessary in a certificate is that the signature validates the
bits presented. It is not a problem if the same semantics could have been
encoded in other bits.

I don't see much value in XML canonicalization either.

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

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

On Tue, Feb 22, 2011 at 5:40 PM, Martin Rex <span dir=3D"ltr">&lt;<a href=
=3D"mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><div class=
=3D"gmail_quote"><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">While in theory, it should be possible to ASN.1 re-encode=
 -- I would</div>
be careful. =A0There are CAs out there with defective PKI-Software,<br>
distributing X.509 certs that are not valid ASN.1 DER.<br></blockquote><div=
><br></div><div>Give people options where getting it wrong will not cause t=
he software to fail and some people will get it wrong.</div><div><br></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;">
One of the GlobalSign RootCA TrustAnchors, as distributed in Browsers,<br>
used to be incorrect ASN.1 DER (IIRC, incorrect encoding of<br>
the unused KeyUsage bits). =A0Which is probably one reason why some ASN.1<b=
r>
decoders keep an original copy of the ASN.1 DER ToBeSigned around for<br>
decoded X.509 certs...</blockquote><div><br></div><div>Since none of the ro=
ots was DER encoded until quite a few years in, this has always been true. =
If you want a cert to work you have to keep the original binary.</div>
<div><br></div><div>Given that a cert has never been as large as a maximal =
TCP packet, I have never considered canonicalization or DER encoding to hav=
e any value whatsoever. It is simply an idiot idea that came up in an X.500=
 committee when there was an idea that certs would be stored in X.500 direc=
tories.</div>
<div>=A0</div></div><div><br></div>All that is necessary in a certificate i=
s that the signature validates the bits presented. It is not a problem if t=
he same semantics could have been encoded in other bits.<div><br></div><div=
>
I don&#39;t see much value in XML canonicalization either.<br clear=3D"all"=
><br>-- <br>Website: <a href=3D"http://hallambaker.com/">http://hallambaker=
.com/</a><br><br>
</div>

--0016e6de01640f3fe6049ce72fb1--

From: Jakob Schlyter <[email-masked]>
Date: Tue, 22 Feb 2011 23:43:04 +0100
To: Ilari Liusvaara <[email-masked]>
Cc: keyassure <[email-masked]>, dane issue tracker <[email-masked]>
Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of the two fields to have fewer certificate types

On 22 feb 2011, at 23.39, Ilari Liusvaara wrote:
> I think it should be done this way:
> 
> Certificate type:
>      1 -- An end-entity certificate in DER encoding
>      2 -- A certification authority's certificate in DER encoding
> 
> Reference type:
> 
>      0 -- Full certificate
>      1 -- SHA-1 hash of the certificate
>      2 -- SHA-256 hash of the certificate
>      3 -- SHA-384 hash of the certificate
> 
> This way it doesn't assume that future certificate types are
> DER-encodable. The result will be the same with cert types 1 and 2
> anyway.

+1

	jakob

-- 
Jakob Schlyter
Kirei AB - www.kirei.se

From: Martin Rex <[email-masked]>
To: [email-masked] (Phillip Hallam-Baker)
Date: Tue, 22 Feb 2011 23:40:29 +0100 (MET)
Cc: [email-masked]
Subject: Re: [keyassure] Interpreting certificates (and summary)
Reply-To: [email-masked]

> 
> Well you would have to design a packaging format, which as Peter explained
> is going to mean ASN.1 for all practical purposes.
> 
> ASN.1 is what the cryptomodules spew out. And over time that is going to be
> how most public key ends up being implemented.

If there was an urgent necessity to represent bare keys in a protocol,
I personally would also appreciate if it recycled the ASN.1 DER of
subjectPublicKeyInfo from PKIX/X.509.

Implementing XMLdsig KeyValue conversions to make that stuff usable
with common crypto toolkit APIs is a royal PITA -- so no, I really
don't want to see yet another public key format standardized just
to ensure that again absolutely no-one will be able to reuse existing code.

The issue with existing X.509 parsers is that they usually decompose
then entire cert and do not return subjectPublicKeyInfo as an
ASN.1 DER blob.

While in theory, it should be possible to ASN.1 re-encode -- I would
be careful.  There are CAs out there with defective PKI-Software,
distributing X.509 certs that are not valid ASN.1 DER.

One of the GlobalSign RootCA TrustAnchors, as distributed in Browsers,
used to be incorrect ASN.1 DER (IIRC, incorrect encoding of
the unused KeyUsage bits).  Which is probably one reason why some ASN.1
decoders keep an original copy of the ASN.1 DER ToBeSigned around for
decoded X.509 certs...

-Martin

Date: Wed, 23 Feb 2011 00:39:06 +0200
From: Ilari Liusvaara <[email-masked]>
To: Warren Kumari <[email-masked]>
Sender: Ilari Liusvaara <[email-masked]>
Cc: [email-masked], dane issue tracker <[email-masked]>
Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of the two fields to have fewer certificate types

On Tue, Feb 22, 2011 at 05:06:21PM -0500, Warren Kumari wrote:
> Ok, so it sounds to me as though their is consensus for this change
> / text.
> 
> Please clearly state if I have misread / misunderstood your views,
> otherwise I'm going to mark it as fixed....
> 
> W

> On Feb 20, 2011, at 2:59 PM, dane issue tracker wrote:
> 
> >#20: Change the format of the two fields to have fewer certificate
> >types
> >
> >To reduce the chance that someone could give a certificate type that
> >doesn't match the hash type, change the fields as follows:
> >
> >o  A one-octet value, called "certificate type", specifying the
> >
> >      1 -- An end-entity certificate
> >      2 -- A certification authority's certificate
> >
> >o  A one-octet value, called "reference type", specifying how the
> >
> >      0 -- Full certificate in DER encoding
> >      1 -- SHA-1 hash of the certificate in DER encoding
> >      2 -- SHA-256 hash of the certificate in DER encoding
> >      3 -- SHA-384 hash of the certificate in DER encoding
> >

What does DER encoding mean for possible future non-ASN.1 certificate
types?

I think it should be done this way:

Certificate type:
      1 -- An end-entity certificate in DER encoding
      2 -- A certification authority's certificate in DER encoding

Reference type:

      0 -- Full certificate
      1 -- SHA-1 hash of the certificate
      2 -- SHA-256 hash of the certificate
      3 -- SHA-384 hash of the certificate

This way it doesn't assume that future certificate types are
DER-encodable. The result will be the same with cert types 1 and 2
anyway.

-Ilari

Date: Tue, 22 Feb 2011 17:25:05 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Wouters <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Interpreting certificates (and summary)

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

Well you would have to design a packaging format, which as Peter explained
is going to mean ASN.1 for all practical purposes.

ASN.1 is what the cryptomodules spew out. And over time that is going to be
how most public key ends up being implemented.

And once we get into ECC issues, the difficulty of ASN.1 encoding really is
moot, as is the problem of signature or cert size.

I could see the point of this if you think we would be moving to a new cert
format before we move beyond RSA2048. But once we are in ECC land we have
compact signatures and short keys and the added overhead of the cert
signature is no longer important.

So yes, it can be supported and I would not want to see the draft actually
foreclose that option for future development. But I can't see it being very
useful either.

On Tue, Feb 22, 2011 at 3:56 PM, Paul Wouters <[email-masked]> wrote:

> On Tue, 22 Feb 2011, Phillip Hallam-Baker wrote:
>
>  Since TLS has the ability to use other cert types it certainly makes sense
>> to have the ability to propose extensions to support them in DANE, including
>> bare key.
>>
>
> Thanks.
>
>
>  The current draft already has that.
>>
>
> But there were issues raised that the types in section 2.2 would not
> facilitate non-RSA public keys, such as ECC.
>
> Paul
>

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

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

Well you would have to design a packaging format, which as Peter explained =
is going to mean ASN.1 for all practical purposes.=A0<div><br></div><div>AS=
N.1 is what the cryptomodules spew out. And over time that is going to be h=
ow most public key ends up being implemented.</div>
<div><br></div><div>And once we get into ECC issues, the difficulty of ASN.=
1 encoding really is moot, as is the problem of signature or cert size.</di=
v><div><br></div><div><br></div><div>I could see the point of this if you t=
hink we would be moving to a new cert format before we move beyond RSA2048.=
 But once we are in ECC land we have compact signatures and short keys and =
the added overhead of the cert signature is no longer important.</div>
<div><br></div><div><br></div><div>So yes, it can be supported and I would =
not want to see the draft actually foreclose that option for future develop=
ment. But I can&#39;t see it being very useful either.</div><div><br><br>
<div class=3D"gmail_quote">On Tue, Feb 22, 2011 at 3:56 PM, Paul Wouters <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">[email-masked]=
m</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">On Tue, 22 Feb 2011, Phillip Hallam-Baker wrote:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Since TLS has the ability to use other cert types it certainly makes sense =
to have the ability to propose extensions to support them in DANE, includin=
g bare key.=A0<br>
</blockquote>
<br></div>
Thanks.<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">
The current draft already has that.<br>
</blockquote>
<br></div>
But there were issues raised that the types in section 2.2 would not facili=
tate non-RSA public keys, such as ECC.<br><font color=3D"#888888">
<br>
Paul<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>

--0016e6de0164c60564049ce6730b--

From: Warren Kumari <[email-masked]>
To: "dane issue tracker" <[email-masked]>
Date: Tue, 22 Feb 2011 17:06:21 -0500
Cc: [email-masked]
Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of the two fields to have fewer certificate types

Ok, so it sounds to me as though their is consensus for this change / =20=

text.

Please clearly state if I have misread / misunderstood your views, =20
otherwise I'm going to mark it as fixed....

W
On Feb 20, 2011, at 2:59 PM, dane issue tracker wrote:

> #20: Change the format of the two fields to have fewer certificate =20
> types
>
> To reduce the chance that someone could give a certificate type that
> doesn't match the hash type, change the fields as follows:
>
> o  A one-octet value, called "certificate type", specifying the
>    provided association that will be used to match the target
>    certificate.  This will be an IANA registry in order to make it
>    easier to add additional certificate types in the future.  The
>    types defined in this document are:
>
>       1 -- An end-entity certificate
>
>       2 -- A certification authority's certificate
>
> o  A one-octet value, called "reference type", specifying how the
>    certificate association is presented.  This value is defined in a
>    new IANA registry.  The types defined in this document are:
>
>       0 -- Full certificate in DER encoding
>
>       1 -- SHA-1 hash of the certificate in DER encoding
>
>       2 -- SHA-256 hash of the certificate in DER encoding
>
>       3 -- SHA-384 hash of the certificate in DER encoding
>
>    Using the same hash algorithm as is used in the signature in the
>    certificate will make it more likely that the TLS client will
>    understand this TLSA data.
> =EF=BB=BF
>
> --=20
> -----------------------------------=20
> +----------------------------------------
> Reporter:  paul.hoffman@=E2=80=A6         |       Owner:
>     Type:  defect                 |      Status:  new
> Priority:  major                  |   Milestone:
> Component:  protocol               |     Version:
> Severity:  -                      |    Keywords:
> -----------------------------------=20
> +----------------------------------------
>
> Ticket URL: <http://trac.tools.ietf.org/wg/dane/trac/ticket/20>
> dane <http://tools.ietf.org/dane/>
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

--
"Build a man a fire, and he'll be warm for a day. Set a man on fire, =20
and he'll be warm for the rest of his life." -- Terry Pratchett

Date: Tue, 22 Feb 2011 15:56:58 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Interpreting certificates (and summary)

On Tue, 22 Feb 2011, Phillip Hallam-Baker wrote:

> Since TLS has the ability to use other cert types it certainly makes sense to have the ability to propose extensions to support them in DANE, including bare key.�

Thanks.

> The current draft already has that.

But there were issues raised that the types in section 2.2 would not facilitate non-RSA public keys, such as ECC.

Paul

Date: Tue, 22 Feb 2011 15:27:49 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Wouters <[email-masked]>
Cc: Scott Schmit <[email-masked]>, [email-masked]
Subject: Re: [keyassure] Interpreting certificates (and summary)

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

On Tue, Feb 22, 2011 at 12:02 PM, Paul Wouters <[email-masked]> wrote:

> On Mon, 21 Feb 2011, Phillip Hallam-Baker wrote:
>
>  CAA should do its job without adding a single line of code to any client
>> or server library.
>>
>> The only parties that are required to implement CAA are CAs.
>>
>
> So the CAA record meant to protect against bad CAs will only be used by
> CAs?
>
> Odd. I thought it was clients checking the CAA record to see if the record
> authorized
> a particular CA for signing the cert for the server.....

Well maybe you should read the spec.

CAA means that CAs that mis-issue against an explicit instruction will have
been clearly an unambiguously at fault. The checks can be automated.

Either a CA is going to have to comply with instructions in CAA or it is
going to find that it's roots are rejected by the browser providers. So I do
not expect there to be a very significant population of non-compliant
certificates and hence the value of client side checking is likely to be
rather small.

It is still worth making the check in new code. But CAA delivers immediate
benefit to all browser users irrespective of whether they update their
browser or not.

You can implement the client side checks if you want to. But the effect
should be achieved without widespread client side deployment.

If you are okay with taking into account that TLSA should be able to support
> a bare public key
> type in the future, we're done with this discussion.

Well oddly enough, CAA actually has that capability already.

Since TLS has the ability to use other cert types it certainly makes sense
to have the ability to propose extensions to support them in DANE, including
bare key.

The current draft already has that.

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

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

<br><br><div class=3D"gmail_quote">On Tue, Feb 22, 2011 at 12:02 PM, Paul W=
outers <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">paul@xel=
erance.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 Mon, 21 Feb 2011, Phillip Hallam-Baker wrote:<br>
<br>
</div><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
CAA should do its job without adding a single line of code to any client or=
 server library.<br>
<br>
The only parties that are required to implement CAA are CAs.<br>
</blockquote>
<br></div>
So the CAA record meant to protect against bad CAs will only be used by CAs=
?<br>
<br>
Odd. I thought it was clients checking the CAA record to see if the record =
authorized<br>
a particular CA for signing the cert for the server.....</blockquote><div><=
br></div><div>Well maybe you should read the spec.</div><div><br></div><div=
>CAA means that CAs that mis-issue against an explicit instruction will hav=
e been clearly an unambiguously at fault. The checks can be automated.</div=
>
<div><br></div><div>Either a CA is going to have to comply with instruction=
s in CAA or it is going to find that it&#39;s roots are rejected by the bro=
wser providers. So I do not expect there to be a very significant populatio=
n of non-compliant certificates and hence the value of client side checking=
 is likely to be rather small.</div>
<div><br></div><div><br></div><div>It is still worth making the check in ne=
w code. But CAA delivers immediate benefit to all browser users irrespectiv=
e of whether they update their browser or not.</div><div><br></div><div>
<br></div><div>You can implement the client side checks if you want to. But=
 the effect should be achieved without widespread client side deployment.=
=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;">
If you are okay with taking into account that TLSA should be able to suppor=
t a bare public key<br>
type in the future, we&#39;re done with this discussion. </blockquote><div>=
<br></div><div>Well oddly enough, CAA actually has that capability already.=
</div><div><br></div><div>Since TLS has the ability to use other cert types=
 it certainly makes sense to have the ability to propose extensions to supp=
ort them in DANE, including bare key.=A0</div>
<div><br></div><div>The current draft already has that.</div><div><br></div=
></div><br clear=3D"all"><br>-- <br>Website: <a href=3D"http://hallambaker.=
com/">http://hallambaker.com/</a><br><br>

--0016e6dee78866c0fd049ce4d034--

From: Henry Story <[email-masked]>
Date: Tue, 22 Feb 2011 19:57:15 +0100
To: Paul Hoffman <[email-masked]>, [email-masked]
Subject: Re: [keyassure] publishing the public key

Ok so the following off list conversation between me and Paul, should =
have helped reduce the=20
bandwidth pressure on the group. I'll send it back to the list because I =
think that at least
I am in sync with how Paul is thinking, so that should help.

On 22 Feb 2011, at 19:16, Paul Hoffman wrote:

> On 2/22/11 9:28 AM, Henry Story wrote:
>>=20
>> On 22 Feb 2011, at 18:23, Paul Hoffman wrote:
>>=20
>>> On 2/22/11 9:14 AM, Henry Story wrote:
>>>> The TLS protocol currently has the server send the client a
>>>> certificate. The client then just needs to look in DNS to find out =
if
>>>> the public key in the certificate sent by the server matches the
>>>> public key for the service in DNSsec. So bare public keys in DNSsec
>>>> should work.
>>>=20
>>> You have yet to say how the TLS client knows what the public key is =
for the cert they get in TLS. This was discussed multiple times on the =
list, and (all?) the other supporters of bare keys have agreed that this =
is not a trivial thing to do, and have backed down from it. You haven't =
even addressed the issue. Instead, you keep coming back to "we want to =
do this in WebID".
>>=20
>> Does the following sound ok, or am I answering a different question:
>>=20
>> 1. TLS client receives cert from TLS server.
>> 2. TLS client extracts key from cert using normal x509 libs
>> 3. TLS client looks up hosname:port in DNSsec, and finds the bare key
>> 4. TLS client matches key found in 2 with the one found in 3
>>=20
>> Is that the kind of thing I should send to the list?  I am not sure =
at which point the problem arises.
>=20
> You can send it to the list, but as has been said on the list already, =
normal X.509 libraries do not let you extract the key. The few that do =
might have it in different formats, so doing a direct comparison is =
impossible. So it feels like the relevant part of your list, step 2, is =
not based in reality. If you can show me wrong, that's great, but if =
not, you posting the above list doesn't really help.

Ok. So at this point we are back to WebID.  I am speaking here of WebId =
only because we needed the same tools as you need in Dane. So we have =
some experience - not perfect - to go by.
  =20
  WebID  also requires the public key from the X509 certificate to be =
extracted. It needs to be extracted on the server (in Dane it will be on =
the client), and the certificate is the client certificate (in Dane it =
is the server certificate), but the tools to do that will be the same.=20=

  http://esw.w3.org/foaf+ssl has listed the many implementations of the =
above on servers for every widespread programming language. That is we =
have WebID working in perl, python, c, java, ruby(?), javascript, and =
others....  Now it is true that for php and javascript there was a lack =
of ASN.1 parsing tools, so people initially used opensso to parse the =
key, and extract the relevant information that way. Not very nice but we =
were trying to see if it works.

The Scala code which we can launch directly into the java SSL layer, and =
which is an OSGI component is here

=
https://svn.apache.org/repos/asf/incubator/clerezza/trunk/parent/platform.=
security.foafssl/core/src/main/scala/org/apache/clerezza/foafssl/ssl/X509T=
rustManagerWrapperService.scala

as you can see there getting the public key from the certificate is one =
line of code

    val publicKey =3D cert0.getPublicKey

In WeBID there is a reason to publish the "bare" public key in a web =
format such as XML, RDF, html, ... If one wants to put they key in HTML =
it makes more sense to put the key in a format where people can verify =
visually the correspondence with what their browser tells them. A big =
ugly PEM blob is just in my view too much of an eysore, and contains too =
much mystification.

This issue does not perhaps exist in the same way in DNS and so with =
DANE, as I think the format there is also quite old, and it is unlikely =
that people will be looking at DNS records without tools. I just don't =
know that aspect of DNS very well, so I may be wrong.

   I think that if there were java libs to do a DNSSEC lookup it =
probably would not be that much work to change the SSL layer reasoner to =
do a Dane lookup.=20

	Henry

Social Web Architect
http://bblfish.net/

From: Martin Rex <[email-masked]>
To: [email-masked] (Stephen Kent)
Date: Tue, 22 Feb 2011 19:26:14 +0100 (MET)
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of
Reply-To: [email-masked]

Stephen Kent wrote:
> >
> >Simplicity and robustness.
> >
> >When simple public keys for servers are to be used with DANE, these
> >will usually be X.509v1 certificates, which do not contain
> >a BasicConstraints extension.
> 
> Why would they be v1 certs?
> 
> We know that using v1 certs introduced vulnerabilities in browsers, 
> e.g., it enabled EEs to issue subordinate certs.

Getting all X.509v3 attributes into a usable consistent fashion is
pretty difficult -- and a complete waste if they're supposed to be
entirely ignored.

Also self-signed X.509v3 End-Entity certs don't really exist.
I know that self-signed X.509v1 certs work fine with TLS implementations.
I wouldn't know which exact attributes I would have to add to a
self-signed X.509v3 certificate in order to not run into interop
problems.  E.g. a KeyUsage constraint _without_ keyCertSign in an
X.509v3 self-signed certificate would obviously be self-contradictory.

> 
> I thought that browsers were fixed and that most commercial CAs used 
> v3 certs now, since v3 has been the current standard for a very long 
> time. I'm surprised to hear that Entrust still has a v1 cert out 
> there

That Entrust cert is a v3 cert -- which is why our software rejects it.
But it seems that most other PKI-Software (MS-CryptoAPI, Firefox, ...)
did not complain about this malformed X.509v3 TrustAnchor, because they're
shipping it as trust anchor.

> 
> Anyway, why should we think in terms of v1 certs for servers at this 
> point in time? Do you statistics that suggest that most (many?) web 
> sites are using v1 certs?  if we're talking about certs that sites 
> can issue themselves (vs. buying certs), then there is a lot of v3 
> cert CA SW available.

selfsigned X.509v1 containers are the X.509 public key bag that
we're looking for for TLSA EE certs -- those where NO PKIX certificate
path validation is to be performed on the certificate.

-Martin

Date: Tue, 22 Feb 2011 12:02:27 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: Scott Schmit <[email-masked]>, [email-masked]
Subject: Re: [keyassure] Interpreting certificates (and summary)

On Mon, 21 Feb 2011, Phillip Hallam-Baker wrote:

> CAA should do its job without adding a single line of code to any client or server library.
> 
> The only parties that are required to implement CAA are CAs.

So the CAA record meant to protect against bad CAs will only be used by CAs?

Odd. I thought it was clients checking the CAA record to see if the record authorized
a particular CA for signing the cert for the server.....

> Nobody else need write a single line of code. If the scheme works correctly it should deter CAs
> from mis-issue and give them the tools to avoid doing so at the same time.

If the CAA record is only meant for CAs to "deter" them from being bad CAs, then I have to
voice against the draft after all.

> There is a client side capability in CAA, and that is certainly something that would be very useful to have. But that functionality should only ever be
> relevant when we are having the type of events we have been having in the past few weeks when governments have actually been out co-ercing Internet
> technology providers.

Reality check. This is the only use of the CAA record. To protect against bogus CAs on the
client side.

>       That discussion can be had when we have a draft for TLS bare public key.
> 
> Well this is the wrong WG to go to for that. If you want to do bare key in TLS then you should go to the TLS list and see what type of reception you get.

I already stated that I have no problem leaving out bare public key in TLSA until we have one,
but what DOES need to be taken into account by this WG and the TLSA draft is a design that
allows this to be later put in as a TLSA type. To which you replied with 5.8MB EXE files.

If you are okay with taking into account that TLSA should be able to support a bare public key
type in the future, we're done with this discussion. If not, then please come up with why it
is harmful to the current TLSA draft to take this into account. Please try to come up with
short bullet point style concrete reasons, and avoid talking about 20 years of experience,
arguing from authority, or going of in 3 paragraph generalities about policy making.
(bonus points for not mangling the reply quoting characters as shown below)

> So you are arguing that CAA should be dropped as well?
> 
> 
> First CAA does not mandate client code.

See above. CAA without client verification is snake oil.

> Second, I have never sold CAA as being a mechanism to simplify PKI code. Thus a minor increase in complexity of the code is irrelevant for my proposal but
> fatal for yours where the only intended purpose is a purported reduction in code complexity.

You know that some (including me) are looking at not using any PKIX in the future. That is
a strong reduction in code complexity and a strong reduction root trust anchors. It is a
very valid security concern that PKIX has not managed to address in 20 years.

I was not accusing you of using CAA to simplify PKI. I brought it up to show that adding a few
lines of code to an overly complex PKIX system actually can make it stronger, just like adding
a few lines of DNSSEC validation can make TLS a lot stronger.

Paul

From: Henry Story <[email-masked]>
Date: Tue, 22 Feb 2011 17:24:35 +0100
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] publishing the public key

On 22 Feb 2011, at 16:38, Paul Hoffman wrote:

> Henry: It feels like you are pushing for DANE and WebID to have "bare =
public key" as a way of doing certificate identification without =
justification for how this could be useful in DANE.
> Without taking any stance on WebID, I find this frustrating as the =
document co-author in DANE. The two protocols do not have the same =
targets and do not even run over the same transports.
> Could you please re-split the discussion and, in the DANE part, be =
much more specific about how you see bare public keys in DANE being used =
with just TLS? Thanks!

So splitting the discussion here, and stopping the cross posting.

Advantages for DANE
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

I think my main reason for why this could be better for DANE were:

 - much shorter entry in the DNS, which has to be fast and efficient
 - simpler to understand (few people understand what is in X509)
=20
I understand why others think that it's easier to put a full X509 in the =
DNS. The parsing libs are there, and there is the idea that they could =
re-use the semantics of X509, which I don't have enough understanding =
of.=20

  So just by myself I would not know at this point what the right thing =
to do is. I hope my arguments have helped sort out some good arguments =
from some less good ones so that the right decision, whatever it is can =
be made.

WebID will work logically just as well with DANE if it has full X509 =
certs in the DNS as if it has bare public keys - especially if whatever =
the outcome, browser vendors adopt DANE for the purpose described in 1 =
above.=20

WebID is putting bare public keys in the Profile Pages, so I was =
wondering why DANE does not do it too.=20

Reasons for interest of WebID
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D

Here are a few reasons for my interest in DANE, which does not get to =
answering the bare public key part of your question, but I'll just use =
it to frame my recent contribution.

 1. DANE should make it easy for the self signed https end points that =
are currently 3 times more numerous than CA signed https end points to =
be authenticated by browsers. Those browsers will no longer need then to =
display ugly warnings messages that users are now taught to bypass. This =
is good for https, for security and so for WebID

 2. The cheaper and easier https endpoint deployment is the better for =
WebID. Dane should make that possible I hope by allowing site owners to =
publish the public keys (bare or inside X509 certs) for the services in =
DNS

 3. DANE and WebID are using different transports but the authentication =
logic are nearly the same. Where Dane can be used to authenticate =
servers, WebID is used to authenticate clients. Semantically it's nearly =
a mirror image - though WebId would end up building on top of DANE.

 =20
=09

Henry

Social Web Architect
http://bblfish.net/

Date: Tue, 22 Feb 2011 07:38:13 -0800
From: Paul Hoffman <[email-masked]>
To: Henry Story <[email-masked]>
Cc: WebID Incubator Group WG <[email-masked]>, [email-masked]
Subject: Re: [keyassure] publishing the public key

Henry: It feels like you are pushing for DANE and WebID to have "bare 
public key" as a way of doing certificate identification without 
justification for how this could be useful in DANE. Without taking any 
stance on WebID, I find this frustrating as the document co-author in 
DANE. The two protocols do not have the same targets and do not even run 
over the same transports.

Could you please re-split the discussion and, in the DANE part, be much 
more specific about how you see bare public keys in DANE being used with 
just TLS? Thanks!

From: Henry Story <[email-masked]>
Date: Tue, 22 Feb 2011 10:17:44 +0100
To: Stephen Kent <[email-masked]>
Cc: WebID Incubator Group WG <[email-masked]>, [email-masked]
Subject: Re: [keyassure] publishing the public key

On 22 Feb 2011, at 03:00, Stephen Kent wrote:

> At 12:49 AM +0100 2/22/11, Henry Story wrote:
>> ...
>> >
>>> Do you mean "identifies" or "authenticates?" I think most folks view =
the DNS name (or URL) as the identity of the web site.
>>=20
>> Partly. The DNS domain name is a name that one could think of as =
referring to a set of services, each of those having a name of the form =
name:port. The relation between the service name and the public key =
forms an identifying description, or I should say  a definite =
description  as it is known in philosophy. I used the following example:
>>=20
>>  name:port knowsPrivateKeyof pubK
>=20
> I don't think that most users, who often can't even tell if they have =
contacted a TLS-secured site, would think of a public key as part of the =
identity for the service. I also don't think that most of them think =
about the port either.

I was not speaking to most users but to this group of security =
specialists during a discussion on a protocol. The public key is a =
definite description that uniquely identifies the agent for the purpose =
of computers, not for the general public.

>=20
>> That sentence does not authenticate, it describes. But it is part of =
the TLS authentication protocol. Authentication is the process that uses =
that information to prove the authorship of the messages sent down a =
socket.
>=20
> once the TLS session has been established, it is symmetric crypto, =
using a key
> delivered or derived using a public key (or pair thereof) that =
provides the
> data origin authentication and connection-oriented integrity =
guarantees to
> which you allude.

I am aware of symmetric cryptography's role. But it is public key =
cryptography that is core in authenticating the server, and setting up =
the symmetric crypto channel. Symmetric cryptography is used because it =
is less cpu intensive.

>=20
>> > We're debating the mechanics of how to enable a client to verify =
that the asserted identity matches the client's expectations, based on =
the content of a series of DNS records.
>>=20
>> Yes, that is what the next part of my e-mail was describing the logic =
of. Now in the case of server identity the client knows what it wants =
the server's identity to be, since it initiated the call, went to DNS, =
found the ip address, and connected. The clienet can then use the public =
key found in DNS (or returned  by the server) to authenticate the =
service it is connected to.
>=20
> right.
>=20
> Steve

Social Web Architect
http://bblfish.net/

Date: Mon, 21 Feb 2011 23:43:58 -0500
From: Scott Schmit <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [keyassure] Interpreting certificates (and summary)

On Mon, Feb 21, 2011 at 08:38:43PM -0500, Stephen Kent wrote keyassure:
> At 9:45 AM -0500 2/21/11, Scott Schmit wrote:
> For DANE we should generate a profile indicating what extensions
> MUST be present, MUST be omitted, MAY be present, etc.  We also can
> limit the types of values allowed in standard cert fields, to further
> simplify generation  and parsing. This is what we did for SIDR.

This assumes that the only certificates that you're interested in using
with DANE are newly-generated self-signed certificates. What does a web
site like Amazon or IETF do if they don't want to break existing users
that don't have DANE support and don't want to setup dane.amazon.com or
dane.ietf.org? If the rules defined for DANE-compatible certs happen
to be what they already have, then great, but will that work for all the
existing certs out there?

I could also imagine putting a CA certificate in the DNS so that the
organization doesn't need to deal with renewing the CA cert and also
updating the DNS. EEs have no control over the CA's certs.

> >While our current focus is TLS/DTLS, general but simple solutions are
> >usually the better ones, so that's another reason for the call for bare
> >keys--it seems so much simpler.
> 
> The apparent simplicity may not prevail when viewed in the larger app
> context.

I agree. Hence "seems" :-)

> >security libraries (and all the risks that implies).  That said, the
> >error paths of those libraries are going to take more of a beating, now
> >that CAs with a reputation to protect aren't sanitizing the certificate
> >fields.
> 
> Not sure what you mean here by "sanitizing."

Not letting the nasty stuff through. Not saying they never make
mistakes, but stuff that causes outright vulnerabilities I would imagine
they fix (even if it takes a public shaming first).

> >Even if we reuse pieces of what's there, they're still invasive changes
> >to ASN.1/X.509 parsing code--the very stuff that has had all those
> >problems. Also, the non-DANE case isn't going away overnight, so both
> >cases must still be covered (complicating the logic), and the more
> >difficult DANE is to adopt, the less overnight it'll be.
> 
> What non-DANE cases do you have in mind?

The status quo today--the world without DANE.

> >* Validity vs RRSIG period [take the min period]
> 
> This need mot be an issue. You will process the DNS TTL first, and reject
> the record if it is expired. If the TTL is OK, then why not process the
> cert validity interval separately, when performing cert path validation.

I probably misstated my intent. What you described is what I meant. It's
probably better stated as "obey both".

> >* CRLs/OCSP vs TTL [Use both if CRL/OCSP is indicated]
> 
> TTL is not really equivalent to a CRL or OCSP. It is analogous to the
> cert validity interval. The question here is whether a cert retrieved from
> the DNS is a TA, or not.  if it is, then it will not be revoked via
> a CRL or OCSP, buy the very nature of a TA. But, if the cert is not
> a TA, the question of what sort of revocation mechanism is used is
> relevant.

I shouldn't have put TTL there. Martin Rex points out TTL isn't covered
by DNSSEC (and how can it be? it's supposed to count down!), so for as
long as the RRSIG is valid, an attacker can simply keep resending the
same record any time the TTL expires. Instead, it's RRSIG (or something
else).

While you're right that the RRSIG period is basically a validity period,
it's also not quite the same because of who is doing the signing. With
CAs today, no one would tolerate a validity of two weeks because they'd
need to get a cert reissued from the CA constantly. On the other hand,
shorter periods are typical in DNSSEC. By having the signing keys,
making the RRSIG period be short isn't so onerous as long as you can
automate the process.

> >* CA flag, path length, etc vs the dane-04 cert type [???]
> 
> The Basic Constraints extension needs to be present in a CA cert, but
> the path length field is rarely used, and I would profile it away for DANE.

Which works for new certs but not existing ones.

> >Other tricky things to resolve:
> >* How do EV certs fit in? (Whatever rules we come up with to process
> >  subjects can't break the link to EV certs or make it over-permissive)
> 
> I don't understand the context here. Are you talking about sites
> that have EV certs and want to also use DANE mechanisms?

Yes.

-- 
Scott Schmit

Date: Mon, 21 Feb 2011 18:54:52 -0800
From: Phillip Hallam-Baker <[email-masked]>
To: Stephen Kent <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of the

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

On Mon, Feb 21, 2011 at 5:08 PM, Stephen Kent <[email-masked]> wrote:

> At 6:39 PM +0100 2/21/11, Martin Rex wrote:
>
>> Stephen Kent wrote:
>>
>>>
>>>  At 7:59 PM +0000 2/20/11, dane issue tracker wrote:
>>>  >#20: Change the format of the two fields to have fewer certificate
>>> types
>>>  >
>>>  >  To reduce the chance that someone could give a certificate type that
>>>  >  doesn't match the hash type, change the fields as follows:
>>>  >
>>>  >  o  A one-octet value, called "certificate type", specifying the
>>>  >     provided association that will be used to match the target
>>>  >     certificate.  This will be an IANA registry in order to make it
>>>  >     easier to add additional certificate types in the future.  The
>>>  >     types defined in this document are:
>>>  >
>>>  >        1 -- An end-entity certificate
>>>  >
>>>  >        2 -- A certification authority's certificate
>>>
>>>  if we're talking about X.509 certs, this distinction is already
>>> expressed
>>>  within the cert itself, via the BasicConstraints extension. Not sure
>>>  why one would need to express this cert type in the record as well,
>>>  when a cert (vs. hash) is present).
>>>
>>
>> Simplicity and robustness.
>>
>> When simple public keys for servers are to be used with DANE, these
>> will usually be X.509v1 certificates, which do not contain
>> a BasicConstraints extension.
>>
>
> Why would they be v1 certs?
>
> We know that using v1 certs introduced vulnerabilities in browsers, e.g.,
> it enabled EEs to issue subordinate certs.
>
> I thought that browsers were fixed and that most commercial CAs used v3
> certs now, since v3 has been the current standard for a very long time. I'm
> surprised to hear that Entrust still has a v1 cert out there, but it may be
> that it has been around for a very long time and they don't want to pay to
> replace it.
>
> Anyway, why should we think in terms of v1 certs for servers at this point
> in time? Do you statistics that suggest that most (many?) web sites are
> using v1 certs?  if we're talking about certs that sites can issue
> themselves (vs. buying certs), then there is a lot of v3 cert CA SW
> available.

I would be surprised if Entrust had issued a v1 cert recently as a CA. But
there are other ways that the same situation can emerge.

One is that some of the earliest root keys have been re-certified. I am not
aware that any of the current roots embedded in current browsers was still
v1 and it would seem rather odd if it was due to the issues that Steve
mentions above. But that does not mean that you can't or shouldn't be able
to form a valid trust chain to one of the old v1 roots.

If we are comparing like with like, we are talking about current software
that is being actively maintained and has a current root store.

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

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

<br><br><div class=3D"gmail_quote">On Mon, Feb 21, 2011 at 5:08 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:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">At 6:39 PM +0100 2/21/11, 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">
Stephen Kent wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<br>
=A0At 7:59 PM +0000 2/20/11, dane issue tracker wrote:<br>
=A0&gt;#20: Change the format of the two fields to have fewer certificate t=
ypes<br>
=A0&gt;<br>
=A0&gt; =A0To reduce the chance that someone could give a certificate type =
that<br>
=A0&gt; =A0doesn&#39;t match the hash type, change the fields as follows:<b=
r>
=A0&gt;<br>
=A0&gt; =A0o =A0A one-octet value, called &quot;certificate type&quot;, spe=
cifying the<br>
=A0&gt; =A0 =A0 provided association that will be used to match the target<=
br>
=A0&gt; =A0 =A0 certificate. =A0This will be an IANA registry in order to m=
ake it<br>
=A0&gt; =A0 =A0 easier to add additional certificate types in the future. =
=A0The<br>
=A0&gt; =A0 =A0 types defined in this document are:<br>
=A0&gt;<br>
=A0&gt; =A0 =A0 =A0 =A01 -- An end-entity certificate<br>
=A0&gt;<br>
=A0&gt; =A0 =A0 =A0 =A02 -- A certification authority&#39;s certificate<br>
<br>
=A0if we&#39;re talking about X.509 certs, this distinction is already expr=
essed<br>
=A0within the cert itself, via the BasicConstraints extension. Not sure<br>
=A0why one would need to express this cert type in the record as well,<br>
=A0when a cert (vs. hash) is present).<br>
</blockquote>
<br>
Simplicity and robustness.<br>
<br>
When simple public keys for servers are to be used with DANE, these<br>
will usually be X.509v1 certificates, which do not contain<br>
a BasicConstraints extension.<br>
</blockquote>
<br></div>
Why would they be v1 certs?<br>
<br>
We know that using v1 certs introduced vulnerabilities in browsers, e.g., i=
t enabled EEs to issue subordinate certs.<br>
<br>
I thought that browsers were fixed and that most commercial CAs used v3 cer=
ts now, since v3 has been the current standard for a very long time. I&#39;=
m surprised to hear that Entrust still has a v1 cert out there, but it may =
be that it has been around for a very long time and they don&#39;t want to =
pay to replace it.<br>

<br>
Anyway, why should we think in terms of v1 certs for servers at this point =
in time? Do you statistics that suggest that most (many?) web sites are usi=
ng v1 certs? =A0if we&#39;re talking about certs that sites can issue thems=
elves (vs. buying certs), then there is a lot of v3 cert CA SW available.</=
blockquote>
<div><br></div><div>I would be surprised if Entrust had issued a v1 cert re=
cently as a CA. But there are other ways that the same situation can emerge=
.</div><div><br></div><div>One is that some of the earliest root keys have =
been re-certified. I am not aware that any of the current roots embedded in=
 current browsers was still v1 and it would seem rather odd if it was due t=
o the issues that Steve mentions above. But that does not mean that you can=
&#39;t or shouldn&#39;t be able to form a valid trust chain to one of the o=
ld v1 roots.</div>
<div><br></div><div><br></div><div>If we are comparing like with like, we a=
re talking about current software that is being actively maintained and has=
 a current root store.=A0</div><div><br></div></div>-- <br>Website: <a href=
=3D"http://hallambaker.com/">http://hallambaker.com/</a><br>
<br>

--0016e6de0164c5a2b1049cd61a2b--

Date: Mon, 21 Feb 2011 21:00:14 -0500
To: Henry Story <[email-masked]>
From: Stephen Kent <[email-masked]>
Cc: WebID Incubator Group WG <[email-masked]>, [email-masked]
Subject: Re: [keyassure] publishing the public key

At 12:49 AM +0100 2/22/11, Henry Story wrote:
>...
>  >
>>  Do you mean "identifies" or "authenticates?" I think most folks 
>>view the DNS name (or URL) as the identity of the web site.
>
>Partly. The DNS domain name is a name that one could think of as 
>referring to a set of services, each of those having a name of the 
>form name:port. The relation between the service name and the public 
>key forms an identifying description, or I should say  a definite 
>description  as it is known in philosophy. I used the following 
>example:
>
>   name:port knowsPrivateKeyof pubK

I don't think that most users, who often can't even tell if they have 
contacted a TLS-secured site, would think of a public key as part of 
the identity for the service. I also don't think that most of them 
think about the port either.

>That sentence does not authenticate, it describes. But it is part of 
>the TLS authentication protocol. Authentication is the process that 
>uses that information to prove the authorship of the messages sent 
>down a socket.

once the TLS session has been established, it is symmetric crypto, using a key
delivered or derived using a public key (or pair thereof) that provides the
data origin authentication and connection-oriented integrity guarantees to
which you allude.

>  > We're debating the mechanics of how to enable a client to verify 
>that the asserted identity matches the client's expectations, based 
>on the content of a series of DNS records.
>
>Yes, that is what the next part of my e-mail was describing the 
>logic of. Now in the case of server identity the client knows what 
>it wants the server's identity to be, since it initiated the call, 
>went to DNS, found the ip address, and connected. The clienet can 
>then use the public key found in DNS (or returned  by the server) to 
>authenticate the service it is connected to.

right.

Steve

Date: Mon, 21 Feb 2011 20:38:43 -0500
To: Scott Schmit <[email-masked]>
From: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Interpreting certificates (and summary)

At 9:45 AM -0500 2/21/11, Scott Schmit wrote:
>[Partly a summary, partly an attempt to re-focus the conversation.]
>
>I think we can all appreciate that complexity is the antithesis of
>security, and simpler is better. There have been a significant number of
>vulnerabilities in ASN.1 and X.509 parsing, and there will probably be
>more. And I've also seen expressed (though I can no longer find the
>webpage that went through the problems) that X.509 is a disaster because
>rules for parsing and certificate generation are so ambiguous or
>inconsistent that clients must violate the spec to work in the real
>world. Even if the specs have been fixed, there is almost certainly
>still stuff out there that hasn't changed.

A few problems with ASN.1 parsing in some libraries were identified, 
and rectified, many years ago. This does not seem to be a current 
problem.

I know of no "ambiguities" in X.509 cert formats that cause problems. 
(Which is not to say that some CAs and some RP software have bugs 
:-). it's SW.)

For DANE we should generate a profile indicating what extensions MUST 
be present, MUST be omitted, MAY be present, etc.  We also can limit 
the
types of values allowed in standard cert fields, to further simplify
generation  and parsing. This is what we did for SIDR.

>So, it's entirely believable that some people decided that this was just
>too much trouble and came up with their own solution (e.g., SSH). With
>DNSSEC providing a secure place to associate keys with nodes, one could
>imagine future protocols (or existing ones) being interested in using
>the DNS, and DANE seems like a good mechanism for that.

SSH has an option to use X.509 certs :-).

>And this is is the attraction of bare keys--in DNSSEC, you have a chain
>of DS records and DNSKEY records linked to some domain name, all
>authenticated using RRSIG records. So clearly, DNSSEC already can do
>certificates (in the sense of a binding of a name to a key), we just
>need a generic way for applications to use that mechanism.

DNSSEC does have a way to distribute keys; nobody is arguing against that.
The question is whether it's worth the trouble to modify apps that 
know how to use certs to use bare keys instead.

>While our current focus is TLS/DTLS, general but simple solutions are
>usually the better ones, so that's another reason for the call for bare
>keys--it seems so much simpler.

The apparent simplicity may not prevail when viewed in the larger app context.

>Even if you accept all that (and you may not), TLS/DTLS uses X.509
>certs.  Listening to Peter, I have a better appreciation now that
>because the TLS protocol has no native way to say "here's my key, check
>out of band to see if you trust it", the existing code doesn't provide
>the right kind of capabilities or interfaces for the programmer to do
>that reliably, as there was no requirement at the time for such a
>feature.

yes.

>If we want to see DANE adopted in the near future (or at all) in
>protocols that already exist (i.e. using TLS), we must respect that a
>lot of people aren't going to see the security benefits of DANE being
>worth starting from scratch or significantly rewriting existing, working
>security libraries (and all the risks that implies).  That said, the
>error paths of those libraries are going to take more of a beating, now
>that CAs with a reputation to protect aren't sanitizing the certificate
>fields.

Not sure what you mean here by "sanitizing."

>Even if we reuse pieces of what's there, they're still invasive changes
>to ASN.1/X.509 parsing code--the very stuff that has had all those
>problems. Also, the non-DANE case isn't going away overnight, so both
>cases must still be covered (complicating the logic), and the more
>difficult DANE is to adopt, the less overnight it'll be.

What non-DANE cases do you have in mind?

>So I would suggest (and I have no hat, it's just a suggestion) that the
>question of bare keys be put aside for the moment. To go with PKIX
>certificates, we need to deal with the problem that PKIX certificates
>have fields that duplicate what DNSSEC is telling the relying party.
>And duplication of information means an opportunity for that information
>to conflict.

Agreed. We need to decide whether we want to compare redundant fields, or
ignore cert fields in favor of DNS data, or whatever.

>Looking at some typical certs, here are some sources of conflict I see:
>* Subject identification (including alt names) vs domain name [???]

the preferred Subject name for TLS is a DNS SAN. we have accommodated several
hacks in the Subject DN field for backward compatibility, but for any 
user-generated certs this ought mot be an issue.

>* Validity vs RRSIG period [take the min period]

This need mot be an issue. You will process the DNS TTL first, and reject
the record if it is expired. If the TTL is OK, then why not process the
cert validity interval separately, when performing cert path validation.

>* Name constraints vs domain name [???]

If the cert is used as a TA, this extension need not be processed.  (This
is a pet peve of mine, as I think it should, but the X.509 and PKIX specs
do not require such behavior.)

>* CRLs/OCSP vs TTL [Use both if CRL/OCSP is indicated]

TTL is not really equivalent to a CRL or OCSP. It is analogous to the
cert validity interval. The question here is whether a cert retrieved from
the DNS is a TA, or not.  if it is, then it will not be revoked via a 
CRL or OCSP, buy the very nature of a TA. But, if the cert is not a 
TA, the
question of what sort of revocation mechanism is used is relevant.

>* CA flag, path length, etc vs the dane-04 cert type [???]

The Basic Constraints extension needs to be present in a CA cert, but
the path length field is rarely used, and I would profile it away for DANE.

>Other tricky things to resolve:
>* How do EV certs fit in? (Whatever rules we come up with to process
>   subjects can't break the link to EV certs or make it over-permissive)

I don't understand the context here. Are you talking about sites that 
have EV certs and want to also use DANE mechanisms?

>* Are there any other PKIX fields that clients use and trust, but are
>   only trustworthy if issued by a third party?

good question.

>* Are the changes to certificate validation required to made DANE
>   meaningful just as bad as or worse than adding support for bare keys?
>   (This won't be evident until we answer the above, which is part of why
>   I suggest setting aside the bare key question.)

depending on what DANE does, this could be very easy, or not so trivial. If
we profile DANE certs to be simple, and use them only as TA material, 
this might be very easy.

>An item for security considerations:
>* Now that CAs aren't necessarily issuing these certs, the client needs
>   to be much more careful in its parsing (the null terminated vs length-
>   delimited string bug comes to mind)

Peter Gutman has a large collection of mangled certs issued by "real" CAs, so
defensive parsing has always been appropriate.

Steve

Date: Mon, 21 Feb 2011 20:08:22 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of the

At 6:39 PM +0100 2/21/11, Martin Rex wrote:
>Stephen Kent wrote:
>>
>>  At 7:59 PM +0000 2/20/11, dane issue tracker wrote:
>>  >#20: Change the format of the two fields to have fewer certificate types
>>  >
>>  >  To reduce the chance that someone could give a certificate type that
>>  >  doesn't match the hash type, change the fields as follows:
>>  >
>>  >  o  A one-octet value, called "certificate type", specifying the
>>  >     provided association that will be used to match the target
>>  >     certificate.  This will be an IANA registry in order to make it
>>  >     easier to add additional certificate types in the future.  The
>>  >     types defined in this document are:
>>  >
>>  >        1 -- An end-entity certificate
>>  >
>>  >        2 -- A certification authority's certificate
>>
>>  if we're talking about X.509 certs, this distinction is already expressed
>>  within the cert itself, via the BasicConstraints extension. Not sure
>>  why one would need to express this cert type in the record as well,
>>  when a cert (vs. hash) is present).
>
>Simplicity and robustness.
>
>When simple public keys for servers are to be used with DANE, these
>will usually be X.509v1 certificates, which do not contain
>a BasicConstraints extension.

Why would they be v1 certs?

We know that using v1 certs introduced vulnerabilities in browsers, 
e.g., it enabled EEs to issue subordinate certs.

I thought that browsers were fixed and that most commercial CAs used 
v3 certs now, since v3 has been the current standard for a very long 
time. I'm surprised to hear that Entrust still has a v1 cert out 
there, but it may be that it has been around for a very long time and 
they don't want to pay to replace it.

Anyway, why should we think in terms of v1 certs for servers at this 
point in time? Do you statistics that suggest that most (many?) web 
sites are using v1 certs?  if we're talking about certs that sites 
can issue themselves (vs. buying certs), then there is a lot of v3 
cert CA SW available.

Steve

Date: Mon, 21 Feb 2011 20:01:55 -0500
To: Ben Laurie <[email-masked]>
From: Stephen Kent <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-04.txt

>...
>  >
>>  I agree that the info in the record could be a TA, and not a CA, but not if
>>  the format of the data is an X.509 cert.
>
>You said a minute ago: "if you issue an X.509 cert under which other
>certs will be validated,
>you are a CA."

yep.

>This sounds correct to me. However, mostly what's being done here is
>_not_ the issuing of X.509 certs under which other certs will be
>validated (though it is an option), so most times the zone operator is
>not a CA.

I though one option was to place a cert in the DNS and use it as the
basis for validating a cert chain that terminates at the EE cert for the
web site.  If so, then that cert is used to validate other certs and
it would generally be viewed as a CA cert.  I admit that some 
ambiguity arises when the cert is viewed as a TA. The ambiguity 
arises because In general,
if you issue a cert, you are a CA, but when a cert used to convey TA data,
an RP may elect to not check all of the data.

We do have TA format standards that make it clear what data is to be 
checked and it might be preferable to use them, vs. a self-signed 
cert (although the later option might minimize code reuse).

>In any case it does seem worth making clear when we are talking about
>a PKIX CA vs. any other kind.

It's really  not a "PKIX CA" per se; it's an X.509 CA.

>  > Also, will not performing PoP be a
>>  good outcome?
>
>What would be the point of proving to myself that I own a key?

It would not be useful to you, but rather to someone who puts it in a
DNS record, if that someone does so on your behalf. Otherwise that entity
does not know if the public key really is yours.  But, I don't know that
this results in a vulnerability for the DANE context.

Steve

Date: Mon, 21 Feb 2011 17:49:41 -0800
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of the two fields to have fewer certificate types

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

On Mon, Feb 21, 2011 at 3:17 PM, Paul Hoffman <[email-masked]> wrote:
>
> No, because the cert from TLSA won't match the cert in TLS. If the TLSA
> cert is an EE cert that is erroneously marked as a CA cert, the TLS client
> will try to match it against a trust anchor in the chain after the cert
> offered by the TLS server and won't find it. If the TLSA cert is a CA cert
> that is erroneously marked as an EE cert, the TLS server won't have the
> private key for that CA.

I think this is OK and that Steve's concern is not going to be realized
because there is going to be a very high probability that most if not all
code is going to recognize this distinction.

This could be a problem if there was a risk that only a small number of
clients would make the check in this fashion; In practice admins tend to use
trial and error as their basis for configuration. But I think there should
be a high probability that this is going to be rejected by most clients.

We should probably make it a MUST though. For a cert to be accepted as a
signing cert it has to be marked as such in BOTH places. For a cert to be
accepted as EE it has to be marked as such in the DNS.

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

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

<br><br><div class=3D"gmail_quote">On Mon, Feb 21, 2011 at 3:17 PM, Paul Ho=
ffman <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">paul.h=
[email-masked]</a>&gt;</span> wrote:<blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

No, because the cert from TLSA won&#39;t match the cert in TLS. If the TLSA=
 cert is an EE cert that is erroneously marked as a CA cert, the TLS client=
 will try to match it against a trust anchor in the chain after the cert of=
fered by the TLS server and won&#39;t find it. If the TLSA cert is a CA cer=
t that is erroneously marked as an EE cert, the TLS server won&#39;t have t=
he private key for that CA.</blockquote>
<div><br></div><div>I think this is OK and that Steve&#39;s concern is not =
going to be realized because there is going to be a very high probability t=
hat most if not all code is going to recognize this distinction.=A0</div>
</div><div><br></div>This could be a problem if there was a risk that only =
a small number of clients would make the check in this fashion; In practice=
 admins tend to use trial and error as their basis for configuration. But I=
 think there should be a high probability that this is going to be rejected=
 by most clients.<br clear=3D"all">
<br><div><br></div><div>We should probably make it a MUST though. For a cer=
t to be accepted as a signing cert it has to be marked as such in BOTH plac=
es. For a cert to be accepted as EE it has to be marked as such in the DNS.=
</div>
<div><br></div><div><br>-- <br>Website: <a href=3D"http://hallambaker.com/"=
>http://hallambaker.com/</a><br><br>
</div>

--0016e6dee788a59c16049cd53196--

Date: Mon, 21 Feb 2011 17:43:07 -0800
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Wouters <[email-masked]>
Cc: Scott Schmit <[email-masked]>, [email-masked]
Subject: Re: [keyassure] Interpreting certificates (and summary)

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

On Mon, Feb 21, 2011 at 4:36 PM, Paul Wouters <[email-masked]> wrote:

> On Mon, 21 Feb 2011, Phillip Hallam-Baker wrote:
>
> [ silly bytes discussion ]
>
>
>  I get rather fed up of this form of argument where issues that affect all
>> forms of PKI are to be held against X.509 and discounted or ignored as far
>> as your
>> alternative proposal goes.
>>
>
> That's because you yourself are not consistent, don't shoot the
> messenger.

No, I am not shooting the messenger, I am finding him to be hopelessly
biased, ill informed and confused.

> You can't selectively claim 20 years of operational experience
> as an asset in every other email, yet complain when that same operational
> experience, and the inherit faults of those systems of the last 20 years
> are pointed out.

I complain that your comments are biased and poorly informed. I am aware
that there are issues with PKIX, there are issues with all deployed
protocols. But I also take the time to understand the reasons behind the
issues.

> Faults which are the reason for developing a DANE system.
>

The operational experience comes from people implementing and using the
system. I don't see any real difference in the architecture, the syntax or
the people involved. Insanity is doing the same thing twice and expecting a
different result.

ASN.1 is a real dog to implement. I know, I have implemented several DER
encoders and parsers and it is just abominable. But so is the DNS  record
format.

PKIX path math is tedious, but so is DNSSEC chain validation. Now you can
make PKIX path math considerably worse than DNSSEC chain validation, but to
do so you have to implement the set of features whose sole purpose is to
keep government contractors in business.

> Also, I never heard you argue against CAA because it adds "bytes and
> complexity" to the resolver code and TLS client. So clearly the situation
> is a little more broad then 5MB of windows binary.
>

CAA should do its job without adding a single line of code to any client or
server library.

The only parties that are required to implement CAA are CAs. Nobody else
need write a single line of code. If the scheme works correctly it should
deter CAs from mis-issue and give them the tools to avoid doing so at the
same time.

There is a client side capability in CAA, and that is certainly something
that would be very useful to have. But that functionality should only ever
be relevant when we are having the type of events we have been having in the
past few weeks when governments have actually been out co-ercing Internet
technology providers.

> In other words, you are cherry picking your arguments. Others have already
> stated that implementing bare public key at worst is a subset of ASN.1,
> so let's just drop this whole "added complexity is not justified".
>

Not at all, I actually bothered to talk about this with the code maintainer
last week. I also have rather more experience with the range of code
libraries that are used. TLS libraries that currently exist have APIs that
assume that an X.509/PKIX certificate will be offered during the initial TLS
handshake.

> That discussion can be had when we have a draft for TLS bare public key.
>

Well this is the wrong WG to go to for that. If you want to do bare key in
TLS then you should go to the TLS list and see what type of reception you
get.

We are proposing an alternative code path here. That is inevitably going to
>> result in a net increase in the complexity of the system, unless the code
>> paths
>> are rejected in their entirety.
>>
>
> So you are arguing that CAA should be dropped as well?

First CAA does not mandate client code.

Second, I have never sold CAA as being a mechanism to simplify PKI code.
Thus a minor increase in complexity of the code is irrelevant for my
proposal but fatal for yours where the only intended purpose is a purported
reduction in code complexity.

If I propose using motor oil as a lubricant in my car, the fact that it does
not taste good as a desert topping for jello is not relevant. If on the
other hand you are proposing an alternative lubricant on the basis that it
can be used as a desert topping, the fact that it tastes terrible and is
probably carcinogenic is rather relevant to the debate.

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

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

<br><br><div class=3D"gmail_quote">On Mon, Feb 21, 2011 at 4:36 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;">
<div class=3D"im">On Mon, 21 Feb 2011, Phillip Hallam-Baker wrote:<br>
<br></div>
[ silly bytes discussion ]<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">
I get rather fed up of this form of argument where issues that affect all f=
orms of PKI are to be held against X.509 and discounted or ignored as far a=
s your<br>
alternative proposal goes.<br>
</blockquote>
<br></div>
That&#39;s because you yourself are not consistent, don&#39;t shoot the<br>
messenger.</blockquote><div><br></div><div>No, I am not shooting the messen=
ger, I am finding him to be hopelessly biased, ill informed and confused.</=
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;">
 You can&#39;t selectively claim 20 years of operational experience<br>
as an asset in every other email, yet complain when that same operational<b=
r>
experience, and the inherit faults of those systems of the last 20 years<br=
>
are pointed out. </blockquote><div><br></div><div>I complain that your comm=
ents are biased and poorly informed. I am aware that there are issues with =
PKIX, there are issues with all deployed protocols. But I also take the tim=
e to understand the reasons behind the issues.=A0</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;">Faults which a=
re the reason for developing a DANE system.<br></blockquote><div><br></div>=
<div>
The operational experience comes from people implementing and using the sys=
tem. I don&#39;t see any real difference in the architecture, the syntax or=
 the people involved. Insanity is doing the same thing twice and expecting =
a different result.</div>
<div><br></div><div>ASN.1 is a real dog to implement. I know, I have implem=
ented several DER encoders and parsers and it is just abominable. But so is=
 the DNS =A0record format.</div><div><br></div><div>PKIX path math is tedio=
us, but so is DNSSEC chain validation. Now you can make PKIX path math cons=
iderably worse than DNSSEC chain validation, but to do so you have to imple=
ment the set of features whose sole purpose is to keep government contracto=
rs in business.=A0</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;">Also, I never =
heard you argue against CAA because it adds &quot;bytes and<br>
complexity&quot; to the resolver code and TLS client. So clearly the situat=
ion<br>
is a little more broad then 5MB of windows binary.<br></blockquote><div><br=
></div><div>CAA should do its job without adding a single line of code to a=
ny client or server library.</div><div><br></div><div>The only parties that=
 are required to implement CAA are CAs. Nobody else need write a single lin=
e of code. If the scheme works correctly it should deter CAs from mis-issue=
 and give them the tools to avoid doing so at the same time.</div>
<div><br></div><div>There is a client side capability in CAA, and that is c=
ertainly something that would be very useful to have. But that functionalit=
y should only ever be relevant when we are having the type of events we hav=
e been having in the past few weeks when governments have actually been out=
 co-ercing Internet technology providers.</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;">
In other words, you are cherry picking your arguments. Others have already<=
br>
stated that implementing bare public key at worst is a subset of ASN.1,<br>
so let&#39;s just drop this whole &quot;added complexity is not justified&q=
uot;.<br></blockquote><div><br></div><div>Not at all, I actually bothered t=
o talk about this with the code maintainer last week. I also have rather mo=
re experience with the range of code libraries that are used. TLS libraries=
 that currently exist have APIs that assume that an X.509/PKIX certificate =
will be offered during the initial TLS handshake. =A0</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;"=
>
That discussion can be had when we have a draft for TLS bare public key.<br=
></blockquote><div><br></div><div>Well this is the wrong WG to go to for th=
at. If you want to do bare key in TLS then you should go to the TLS list an=
d see what type of reception you get.</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">
We are proposing an alternative code path here. That is inevitably going to=
 result in a net increase in the complexity of the system, unless the code =
paths<br>
are rejected in their entirety.<br>
</blockquote>
<br></div>
So you are arguing that CAA should be dropped as well?</blockquote><div><br=
></div><div>First CAA does not mandate client code.</div><div><br></div><di=
v>Second, I have never sold CAA as being a mechanism to simplify PKI code. =
Thus a minor increase in complexity of the code is irrelevant for my propos=
al but fatal for yours where the only intended purpose is a purported reduc=
tion in code complexity.</div>
<div><br></div><div><br></div><div>If I propose using motor oil as a lubric=
ant in my car, the fact that it does not taste good as a desert topping for=
 jello is not relevant. If on the other hand you are proposing an alternati=
ve lubricant on the basis that it can be used as a desert topping, the fact=
 that it tastes terrible and is probably carcinogenic is rather relevant to=
 the debate.</div>
<div><br></div></div>-- <br>Website: <a href=3D"http://hallambaker.com/">ht=
tp://hallambaker.com/</a><br><br>

--0016e6d59eac219282049cd51a9b--

Date: Mon, 21 Feb 2011 19:36:47 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: Scott Schmit <[email-masked]>, [email-masked]
Subject: Re: [keyassure] Interpreting certificates (and summary)

On Mon, 21 Feb 2011, Phillip Hallam-Baker wrote:

[ silly bytes discussion ]

> I get rather fed up of this form of argument where issues that affect all forms of PKI are to be held against X.509 and discounted or ignored as far as your
> alternative proposal goes.

That's because you yourself are not consistent, don't shoot the
messenger. You can't selectively claim 20 years of operational experience
as an asset in every other email, yet complain when that same operational
experience, and the inherit faults of those systems of the last 20 years
are pointed out. Faults which are the reason for developing a DANE system.

Also, I never heard you argue against CAA because it adds "bytes and
complexity" to the resolver code and TLS client. So clearly the situation
is a little more broad then 5MB of windows binary.

In other words, you are cherry picking your arguments. Others have already
stated that implementing bare public key at worst is a subset of ASN.1,
so let's just drop this whole "added complexity is not justified".

That discussion can be had when we have a draft for TLS bare public key.

And like others have stated here, the minimum we need to do for DANE
now is to ensure that if such a TLS method is added, TLSA will be able
to add support for it without a total rewrite.

> We are proposing an alternative code path here. That is inevitably going to result in a net increase in the complexity of the system, unless the code paths
> are rejected in their entirety.

So you are arguing that CAA should be dropped as well?

> 
> The only way that an existing legacy infrastructure can be made simpler is to profile and subset. That is often valuable work. And efforts like DANE can
> provide features that enable a future simplification step.

Indeed, and bare public key is one of the items people are looking at
to vastly simplify for the immediate future.

Paul

Date: Mon, 21 Feb 2011 16:02:04 -0800
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Wouters <[email-masked]>
Cc: Scott Schmit <[email-masked]>, [email-masked]
Subject: Re: [keyassure] Interpreting certificates (and summary)

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

On Mon, Feb 21, 2011 at 1:11 PM, Paul Wouters <[email-masked]> wrote:

> On Mon, 21 Feb 2011, Phillip Hallam-Baker wrote:
>
> On windows, I assume that a DNSSEC resolver library will come with the OS
> in the near future, so no
> additional bytes are added.
>

Ah so complexity in the operating system does not count?

If you are going to pull that one, then your whole argument falls because
X.509 is built into the core of Windows and has been for a decade. So by
your measure the complexity of X.509 does not count either.

I get rather fed up of this form of argument where issues that affect all
forms of PKI are to be held against X.509 and discounted or ignored as far
as your alternative proposal goes.

We are proposing an alternative code path here. That is inevitably going to
result in a net increase in the complexity of the system, unless the code
paths are rejected in their entirety.

The only way that an existing legacy infrastructure can be made simpler is
to profile and subset. That is often valuable work. And efforts like DANE
can provide features that enable a future simplification step. But that lies
far in the future, in the near term the result will be more complexity.

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

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

On Mon, Feb 21, 2011 at 1:11 PM, Paul Wouters <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" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">On Mon, 21 Feb 2011, Phillip Hallam-Baker wrote:<br><br><=
/div>
On windows, I assume that a DNSSEC resolver library will come with the OS i=
n the near future, so no<br>
additional bytes are added.<br></blockquote><div><br></div><div>Ah so compl=
exity in the operating system does not count?</div><div><br></div><div>If y=
ou are going to pull that one, then your whole argument falls because X.509=
 is built into the core of Windows and has been for a decade. So by your me=
asure the complexity of X.509 does not count either.</div>
<div><br></div><div><br></div><div>I get rather fed up of this form of argu=
ment where issues that affect all forms of PKI are to be held against X.509=
 and discounted or ignored as far as your alternative proposal goes.</div>
<div><br></div><div>We are proposing an alternative code path here. That is=
 inevitably going to result in a net increase in the complexity of the syst=
em, unless the code paths are rejected in their entirety.</div><div><br>
</div><div><br></div><div>The only way that an existing legacy infrastructu=
re can be made simpler is to profile and subset. That is often valuable wor=
k. And efforts like DANE can provide features that enable a future simplifi=
cation step. But that lies far in the future, in the near term the result w=
ill be more complexity.</div>
</div><br>-- <br>Website: <a href=3D"http://hallambaker.com/">http://hallam=
baker.com/</a><br><br>

--0016e6d59eacc44735049cd3b067--

From: Henry Story <[email-masked]>
Date: Tue, 22 Feb 2011 00:49:38 +0100
To: Stephen Kent <[email-masked]>
Cc: WebID Incubator Group WG <[email-masked]>, [email-masked]
Subject: Re: [keyassure] publishing the public key

On 21 Feb 2011, at 23:10, Stephen Kent wrote:

> At 4:29 PM +0100 2/21/11, Henry Story wrote:
>> (Just a summary of what I understood of this thread, and a few new =
ideas)
>>=20
>> On 20 Feb 2011, at 23:58, Paul Hoffman wrote:
>>=20
>>> On 2/20/11 2:51 PM, Paul Wouters wrote:
>>>> The whole point is we do not want to identify a cert. We want to =
identify a key.
>>>=20
>>> That's not the case currently, at least for many of us. Given that =
the only thing that can be used in TLS to identify the server is a =
certificate, most of us want to identify that certificate (or a trust =
anchor that the certificate chains to).
>>=20
>> One needs to go beyond appearances a little here. My argument is that =
what identifies a server in TLS is a public key.
>=20
> Do you mean "identifies" or "authenticates?" I think most folks view =
the DNS name (or URL) as the identity of the web site.

Partly. The DNS domain name is a name that one could think of as =
referring to a set of services, each of those having a name of the form =
name:port. The relation between the service name and the public key =
forms an identifying description, or I should say  a definite =
description  as it is known in philosophy. I used the following example:

  name:port knowsPrivateKeyof pubK=20

That sentence does not authenticate, it describes. But it is part of the =
TLS authentication protocol. Authentication is the process that uses =
that information to prove the authorship of the messages sent down a =
socket.

> We're debating the mechanics of how to enable a client to verify that =
the asserted identity matches the client's expectations, based on the =
content of a series of DNS records.

Yes, that is what the next part of my e-mail was describing the logic =
of. Now in the case of server identity the client knows what it wants =
the server's identity to be, since it initiated the call, went to DNS, =
found the ip address, and connected. The clienet can then use the public =
key found in DNS (or returned  by the server) to authenticate the =
service it is connected to.

>=20
> Steve

Social Web Architect
http://bblfish.net/

Date: Mon, 21 Feb 2011 15:17:14 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of the two fields to have fewer certificate types

On 2/21/11 2:16 PM, Stephen Kent wrote:
> At 8:47 AM -0800 2/21/11, Paul Hoffman wrote:
>> On 2/21/11 4:55 AM, Stephen Kent wrote:
>>> At 7:59 PM +0000 2/20/11, dane issue tracker wrote:
>>>> #20: Change the format of the two fields to have fewer certificate
>>>> types
>>>>
>>>> To reduce the chance that someone could give a certificate type that
>>>> doesn't match the hash type, change the fields as follows:
>>>>
>>>> o A one-octet value, called "certificate type", specifying the
>>>> provided association that will be used to match the target
>>>> certificate. This will be an IANA registry in order to make it
>>>> easier to add additional certificate types in the future. The
>>>> types defined in this document are:
>>>>
>>>> 1 -- An end-entity certificate
>>>>
>>>> 2 -- A certification authority's certificate
>>>
>>> if we're talking about X.509 certs, this distinction is already
>>> expressed
>>> within the cert itself, via the BasicConstraints extension. Not sure why
>>> one would need to express this cert type in the record as well, when a
>>> cert (vs. hash) is present).
>>
>> Simplicity. If you know you are holding an EE cert, you do this; if
>> you know you are holding a CA cert, you do that. If we remove the
>> differentiation in TLSA protocol, we force every client to do
>> something they don't have to do now, namely to disassemble the cert to
>> determine the type. That currently happens in the path processing
>> software, but that software is usually a black box to the main TLS
>> software. If we eliminate the certificate type differentiation, it has
>> to happen before certificate comparison can happen.
>
> Thanks. That's a good rationale.
>>
>>> Even if a cert hash is the record content,
>>> when the
>>> relying party matches the hash against the cert, the cert will still say
>>> whether it is an E or a CA cert. If we put this info here, it creates an
>>> opportunity
>>> for a mismatch between the two, and a need to describe (and defend) why
>>> one trumps the other.
>>
>> Fully agree on the possibility of the mismatch, but in that case the
>> TLSA association will fail for everyone and the DNS admin will hear
>> about it. The cost of the possibility of mismatch should be weighed
>> against the cost of making everyone add new ASN.1 parsing code to look
>> for the cA bit in the basicConstraints extension.
>
> The association will fail because we have decided which marking takes
> precedence?

No, because the cert from TLSA won't match the cert in TLS. If the TLSA 
cert is an EE cert that is erroneously marked as a CA cert, the TLS 
client will try to match it against a trust anchor in the chain after 
the cert offered by the TLS server and won't find it. If the TLSA cert 
is a CA cert that is erroneously marked as an EE cert, the TLS server 
won't have the private key for that CA.

Date: Mon, 21 Feb 2011 17:16:11 -0500
To: Paul Hoffman <[email-masked]>
From: Stephen Kent <[email-masked]>
Cc: [email-masked], dane issue tracker <[email-masked]>
Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of the two fields to have fewer certificate types

At 8:47 AM -0800 2/21/11, Paul Hoffman wrote:
>On 2/21/11 4:55 AM, Stephen Kent wrote:
>>At 7:59 PM +0000 2/20/11, dane issue tracker wrote:
>>>#20: Change the format of the two fields to have fewer certificate types
>>>
>>>To reduce the chance that someone could give a certificate type that
>>>doesn't match the hash type, change the fields as follows:
>>>
>>>o A one-octet value, called "certificate type", specifying the
>>>provided association that will be used to match the target
>>>certificate. This will be an IANA registry in order to make it
>>>easier to add additional certificate types in the future. The
>>>types defined in this document are:
>>>
>>>1 -- An end-entity certificate
>>>
>>>2 -- A certification authority's certificate
>>
>>if we're talking about X.509 certs, this distinction is already expressed
>>within the cert itself, via the BasicConstraints extension. Not sure why
>>one would need to express this cert type in the record as well, when a
>>cert (vs. hash) is present).
>
>Simplicity. If you know you are holding an EE cert, you do this; if 
>you know you are holding a CA cert, you do that. If we remove the 
>differentiation in TLSA protocol, we force every client to do 
>something they don't have to do now, namely to disassemble the cert 
>to determine the type. That currently happens in the path processing 
>software, but that software is usually a black box to the main TLS 
>software. If we eliminate the certificate type differentiation, it 
>has to happen before certificate comparison can happen.

Thanks.  That's a good rationale.
>
>>Even if a cert hash is the record content,
>>when the
>>relying party matches the hash against the cert, the cert will still say
>>whether it is an E or a CA cert. If we put this info here, it creates an
>>opportunity
>>for a mismatch between the two, and a need to describe (and defend) why
>>one trumps the other.
>
>Fully agree on the possibility of the mismatch, but in that case the 
>TLSA association will fail for everyone and the DNS admin will hear 
>about it. The cost of the possibility of mismatch should be weighed 
>against the cost of making everyone add new ASN.1 parsing code to 
>look for the cA bit in the basicConstraints extension.

The association will fail because we have decided which marking takes 
precedence?

Steve

Date: Mon, 21 Feb 2011 17:13:54 -0500
To: Phillip Hallam-Baker <[email-masked]>
From: Stephen Kent <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of the two fields to have fewer certificate types

At 5:37 AM -0800 2/21/11, Phillip Hallam-Baker wrote:
>There are two sets of issues:
>
>1) To distinguish between different types of X.509v3 cert
>
>2) To distinguish between different types of cert (X.509, SAML, PGP, etc...)
>
>
>The first is covered by the X.509 spec, the second is not. So either 
>the spec has to say that it only allows use of X.509 keys or there 
>has to be a mechanism to allow the client to work out what type of 
>information it is handling.

For a non-X.59 cert that does not express CA vs. EE attribute this 
marking might be useful. What types of certs are benign considered 
that have these attributes but do not encode it internally?

Steve

Date: Mon, 21 Feb 2011 17:10:53 -0500
To: Henry Story <[email-masked]>
From: Stephen Kent <[email-masked]>
Cc: WebID Incubator Group WG <[email-masked]>, [email-masked]
Subject: Re: [keyassure] publishing the public key

At 4:29 PM +0100 2/21/11, Henry Story wrote:
>(Just a summary of what I understood of this thread, and a few new ideas)
>
>On 20 Feb 2011, at 23:58, Paul Hoffman wrote:
>
>>  On 2/20/11 2:51 PM, Paul Wouters wrote:
>>>  The whole point is we do not want to identify a cert. We want to 
>>>identify a key.
>>
>>  That's not the case currently, at least for many of us. Given that 
>>the only thing that can be used in TLS to identify the server is a 
>>certificate, most of us want to identify that certificate (or a 
>>trust anchor that the certificate chains to).
>
>One needs to go beyond appearances a little here. My argument is 
>that what identifies a server in TLS is a public key.

Do you mean "identifies" or "authenticates?" I think most folks view 
the DNS name (or URL) as the identity of the web site. We're debating 
the mechanics
of how to enable a client to verify that the asserted identity 
matches the client's expectations, based on the content of a series 
of DNS records.

Steve

From: Henry Story <[email-masked]>
Date: Mon, 21 Feb 2011 23:01:31 +0100
To: Scott Schmit <[email-masked]>
Cc: WebID Incubator Group WG <[email-masked]>, [email-masked]
Subject: Re: [keyassure] dane-04 trust anchors

On 20 Feb 2011, at 06:35, Scott Schmit wrote:

> On Sun, Feb 13, 2011 at 02:58:29PM -0500, Paul Wouters wrote:
>> On Fri, 11 Feb 2011, Yaron Sheffer wrote:
>>> The client MUST obey any constraints included in the trust anchor,
>>> including but not limited to:
>>> - Validity period.
>>=20
>> What to do if that period does not match the DNS TTL/RRSIG period?
>=20
> The DNS TTL should be used to determine when the client MUST forget =
the
> certificate association and refetch the TLSA record if it needs it
> again.  I think that's the DANE equivalent to revocation (if the TLSA
> record is replaced, the old cert was revoked).

<webid parallel=3D"cool" =
thread=3D"http://www.ietf.org/mail-archive/web/keyassure/current/msg01877.=
html">

 1. the DNS Time To Live (TTL) is in WebID the HTTP Expires header
 2. In WebID if the public key is no longer listed at the WebID Profile =
then the client certificate is revoked. In Dane when the key is removed =
from DNSsec the same happens.
 3. In WebID there is an interesting twist: the client certificate =
not-before, not-after time constraints can be very useful for end users =
that are perhaps on less trusted machines and wish to create themselves =
a time limited certificate. Those people should get their Social Web =
server to create them a 1 hour certificate so that misuse of the =
certificate can only last so long.

</webid>

>=20
> The RRSIG period serves a similar role to the Validity period in =
X.509,
> though it'll be much shorter than we're used to for PKIX. I would =
think
> that the most restrictive value wins. The notAfter field can always be
> set to be never to avoid needing to regenerate the certificate.
>=20
> You could probably argue that what I'm saying to use the TTL for is =
what
> the RRSIG period is for, but in my experience with DNSSEC tools, it's =
a
> lot more obvious to me how I'd control (without affecting the period =
for
> other records) the rate a client rechecks the certificate validity via
> the TTL.
>=20
> --=20
> Scott Schmit
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Social Web Architect
http://bblfish.net/

From: Martin Rex <[email-masked]>
To: [email-masked] (Scott Schmit)
Date: Mon, 21 Feb 2011 22:38:10 +0100 (MET)
Cc: [email-masked]
Subject: Re: [keyassure] dane-04 trust anchors
Reply-To: [email-masked]

Scott Schmit wrote:
> 
> On Sun, Feb 13, 2011 at 02:58:29PM -0500, Paul Wouters wrote:
> > On Fri, 11 Feb 2011, Yaron Sheffer wrote:
> > >The client MUST obey any constraints included in the trust anchor,
> > >including but not limited to:
> > >- Validity period.
> > 
> > What to do if that period does not match the DNS TTL/RRSIG period?
> 
> The DNS TTL should be used to determine when the client MUST forget the
> certificate association and refetch the TLSA record if it needs it
> again.  I think that's the DANE equivalent to revocation (if the TLSA
> record is replaced, the old cert was revoked).

There seems to be confusion about the purpose of TTLs in DNS
(and and the fact that TTL is _not_ protected by DNSSEC).

See previous discussion, e.g.
http://www.ietf.org/mail-archive/web/keyassure/current/msg01190.html

While expiring cached records at TTL time make sense with or without
DNSSEC, one must be aware that an attacker could replay DNSSEC signed
records for as long as the RRSIG signature allows.  Therefore, TTL
can not be considered a revocation mechanism.

-Martin

Date: Mon, 21 Feb 2011 16:13:56 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Scott Schmit <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Interpreting certificates (and summary)

On Mon, 21 Feb 2011, Scott Schmit wrote:

> So I would suggest (and I have no hat, it's just a suggestion) that the
> question of bare keys be put aside for the moment.

Agreed.

> Looking at some typical certs, here are some sources of conflict I see:
> * Subject identification (including alt names) vs domain name [???]
> * Validity vs RRSIG period [take the min period]
> * Name constraints vs domain name [???]
> * CRLs/OCSP vs TTL [Use both if CRL/OCSP is indicated]
> * CA flag, path length, etc vs the dane-04 cert type [???]

I believe for DANE not to be reduced to the security of PKIX, DANE should
be able ignore all of these. Otherwise DANE just becomes a vehicle for
PKIX extensions like CAA - those might be a useful side effect, but not
the main goal of DANE, which is to level DNSSEC for TLS services. But
this is easilly done by not specifying those properties in your certificate.
It needs no DANE protocol support.

When specifying CRLs or OCSP or EV in the certs, and certifying the cert
in DANE, these properties become validatable by DANE provided the Issuer
can be validated as well - but in this case just DANE should not be enough,
as DANE cannot speak for items like EV.

> An item for security considerations:
> * Now that CAs aren't necessarily issuing these certs, the client needs
>  to be much more careful in its parsing (the null terminated vs length-
>  delimited string bug comes to mind)

Uhm no. Any code should already have taken everything into account. Such
asusmptions caused the wildcard signed cert and the \0 CN. If the client
trusted the CAs for this, it was already very broken. It is precisely
why some rather trust their DNSOPS then any of the CA orgs, and is the
reason why more respected CAs want to limit the impact of less respected
CAs using DNSSEC validation.

Paul

Date: Mon, 21 Feb 2011 16:11:27 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: Scott Schmit <[email-masked]>, [email-masked]
Subject: Re: [keyassure] Interpreting certificates (and summary)

On Mon, 21 Feb 2011, Phillip Hallam-Baker wrote:

> On the contrary,
>
>  What he has shown is that the changes to SSL are minor, �after adding in the DNSSEC resolver library
>
>  I just pulled down the Windows binary from http://unbound.net/, it is 5.3 Mb.

That's the server. If you want to compare raw sizes (which is silly to begin with but ok), then use:

-rwxr-xr-x. 1 root root 807880 Jan 25 17:19 /usr/lib64/libunbound.so.2.8.0

On windows, I assume that a DNSSEC resolver library will come with the OS in the near future, so no
additional bytes are added.

Anyway, Henry Story also did a nice write up showing code complexity is a red herring when it comes
to supporting bare public keys - because that was your argument, that a new format of bare public
keys couldn't be done because the already complicated addition of DNSSEC validation in a TLS stack
that has to support DANE.

Paul

Date: Mon, 21 Feb 2011 11:48:49 -0800
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Wouters <[email-masked]>
Cc: Scott Schmit <[email-masked]>, [email-masked]
Subject: Re: [keyassure] Interpreting certificates (and summary)

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

On the contrary,

What he has shown is that the changes to SSL are minor,  *after adding
in the DNSSEC resolver library*

I just pulled down the Windows binary from http://unbound.net/, it is 5.3 Mb.

Now that may not seem complex to you but it certainly does to me. And
it is still going to be a lot of additional complexity if that can be
reduced to the 50kb or so that is round about where it should be.

security/nss/README.dane           |   78 +++++++++++++
 security/nss/cmd/tstclnt/tstclnt.c |    7 +-
 security/nss/lib/ssl/config.mk     |    3 +
 security/nss/lib/ssl/manifest.mn   |    1 +
 security/nss/lib/ssl/ssl.def       |    6 +
 security/nss/lib/ssl/ssl.h         |    3 +
 security/nss/lib/ssl/sslauth.c     |    9 ++
 security/nss/lib/ssl/ssldane.c     |  218 ++++++++++++++++++++++++++++++++++++
 security/nss/lib/ssl/sslerr.h      |    7 +
 security/nss/lib/ssl/sslimpl.h     |    4 +
 security/nss/lib/ssl/sslsecur.c    |   26 +++++
 security/nss/lib/ssl/sslsock.c     |    1 +
 12 files changed, 362 insertions(+), 1 deletions(-)

diff --git a/security/nss/README.dane b/security/nss/README.dane
new file mode 100644
index 0000000..ecbf442
--- /dev/null
+++ b/security/nss/README.dane
@@ -0,0 +1,78 @@
+This modified version of NSS contains a proof-of-concept implementation of the
+draft DANE protocol (see https://tools.ietf.org/wg/dane/) for DNSSEC-based
+authentication of TLS services.  The implementation uses the libunbound DNSSEC
+stub resolver (http://unbound.net/).  It is far from ready for production or
+upstream consideration, but it should be fun for experimentation.

On Mon, Feb 21, 2011 at 11:35 AM, Paul Wouters <[email-masked]> wrote:

> On Mon, 21 Feb 2011, Phillip Hallam-Baker wrote:
>
>  Adding DNSSEC into the code base is going to be a big enough increase in
>> code complexity as it is.
>>
>
> https://mattmccutchen.net/cryptid/nss-dane-20110215.patch
>
> 12 files changed, 362 insertions(+), 1 deletions(-)
>
> Matt showed it was far from complex.
>
> Paul
>

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

--00151747c070115596049cd02776
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"font-size=
: medium; "><pre style=3D"word-wrap: break-word; white-space: pre-wrap; "><=
font class=3D"Apple-style-span" face=3D"&#39;times new roman&#39;, serif">O=
n the contrary,</font></pre>
<pre style=3D"word-wrap: break-word; white-space: pre-wrap; "><font class=
=3D"Apple-style-span" face=3D"&#39;times new roman&#39;, serif">What he has=
 shown is that the changes to SSL are minor, =A0<b>after adding in the DNSS=
EC resolver library</b></font></pre>
<pre style=3D"word-wrap: break-word; white-space: pre-wrap; "><font class=
=3D"Apple-style-span" face=3D"&#39;times new roman&#39;, serif">I just pull=
ed down the Windows binary from <a href=3D"http://unbound.net/">http://unbo=
und.net/</a>, it is 5.3 Mb.</font></pre>
<pre style=3D"word-wrap: break-word; white-space: pre-wrap; "><font class=
=3D"Apple-style-span" face=3D"&#39;times new roman&#39;, serif">Now that ma=
y not seem complex to you but it certainly does to me. And it is still goin=
g to be a lot of additional complexity if that can be reduced to the 50kb o=
r so that is round about where it should be.</font></pre>
<pre style=3D"word-wrap: break-word; white-space: pre-wrap; font-family: Ti=
mes; "><br></pre><pre style=3D"word-wrap: break-word; white-space: pre-wrap=
; font-family: Times; ">security/nss/README.dane           |   78 +++++++++=
++++
 security/nss/cmd/tstclnt/tstclnt.c |    7 +-
 security/nss/lib/ssl/<a href=3D"http://config.mk">config.mk</a>     |    3=
 +
 security/nss/lib/ssl/<a href=3D"http://manifest.mn">manifest.mn</a>   |   =
 1 +
 security/nss/lib/ssl/ssl.def       |    6 +
 security/nss/lib/ssl/ssl.h         |    3 +
 security/nss/lib/ssl/sslauth.c     |    9 ++
 security/nss/lib/ssl/ssldane.c     |  218 ++++++++++++++++++++++++++++++++=
++++
 security/nss/lib/ssl/sslerr.h      |    7 +
 security/nss/lib/ssl/sslimpl.h     |    4 +
 security/nss/lib/ssl/sslsecur.c    |   26 +++++
 security/nss/lib/ssl/sslsock.c     |    1 +
 12 files changed, 362 insertions(+), 1 deletions(-)

diff --git a/security/nss/README.dane b/security/nss/README.dane
new file mode 100644
index 0000000..ecbf442
--- /dev/null
+++ b/security/nss/README.dane
@@ -0,0 +1,78 @@
+This modified version of NSS contains a proof-of-concept implementation of=
 the
+draft DANE protocol (see <a href=3D"https://tools.ietf.org/wg/dane/">https=
://tools.ietf.org/wg/dane/</a>) for DNSSEC-based
+authentication of TLS services.  The implementation uses the libunbound DN=
SSEC
+stub resolver (<a href=3D"http://unbound.net/">http://unbound.net/</a>).  =
It is far from ready for production or
+upstream consideration, but it should be fun for experimentation.</pre></s=
pan><br><div class=3D"gmail_quote">On Mon, Feb 21, 2011 at 11:35 AM, Paul W=
outers <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">paul@xel=
erance.com</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 Mon, 21 Feb 2011, Phil=
lip Hallam-Baker wrote:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Adding DNSSEC into the code base is going to be a big enough increase in co=
de complexity as it is.<br>
</blockquote>
<br>
</div><a href=3D"https://mattmccutchen.net/cryptid/nss-dane-20110215.patch"=
 target=3D"_blank">https://mattmccutchen.net/cryptid/nss-dane-20110215.patc=
h</a><br>
<br>
12 files changed, 362 insertions(+), 1 deletions(-)<br>
<br>
Matt showed it was far from complex.<br><font color=3D"#888888">
<br>
Paul<br>
</font></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a href=
=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>

--00151747c070115596049cd02776--

Date: Mon, 21 Feb 2011 14:35:32 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: Scott Schmit <[email-masked]>, [email-masked]
Subject: Re: [keyassure] Interpreting certificates (and summary)

On Mon, 21 Feb 2011, Phillip Hallam-Baker wrote:

> Adding DNSSEC into the code base is going to be a big enough increase in code complexity as it is.

https://mattmccutchen.net/cryptid/nss-dane-20110215.patch

12 files changed, 362 insertions(+), 1 deletions(-)

Matt showed it was far from complex.

Paul

From: Martin Rex <[email-masked]>
To: [email-masked] (Stephen Kent)
Date: Mon, 21 Feb 2011 18:39:13 +0100 (MET)
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of the
Reply-To: [email-masked]

Stephen Kent wrote:
> 
> At 7:59 PM +0000 2/20/11, dane issue tracker wrote:
> >#20: Change the format of the two fields to have fewer certificate types
> >
> >  To reduce the chance that someone could give a certificate type that
> >  doesn't match the hash type, change the fields as follows:
> >
> >  o  A one-octet value, called "certificate type", specifying the
> >     provided association that will be used to match the target
> >     certificate.  This will be an IANA registry in order to make it
> >     easier to add additional certificate types in the future.  The
> >     types defined in this document are:
> >
> >        1 -- An end-entity certificate
> >
> >        2 -- A certification authority's certificate
> 
> if we're talking about X.509 certs, this distinction is already expressed
> within the cert itself, via the BasicConstraints extension. Not sure 
> why one would need to express this cert type in the record as well, 
> when a cert (vs. hash) is present).

Simplicity and robustness.

When simple public keys for servers are to be used with DANE, these
will usually be X.509v1 certificates, which do not contain
a BasicConstraints extension.  Based on X.509 itself, a certificate
without the BasisConstraints extension "cA=FALSE" is _not_ limited
to be an end-entity cert.  The requirement that a CA certificate
is required to contain a "BasicConstraints cA=TRUE" marked critical
extension is specific to PKIX (rfc-5280 and predecessors).

But the CA-certificate conveyed through dane is more of a trust anchor
than a CA to an rfc5280 path validation, so it may be difficult to
enforce the Basic Constraints attribute check.

Keep in mind that even "renowned" commercial CAs get this wrong !!
My Firefox 3.5.13 contains a Trust Anchor called
"Entrust.net Certification Authority (2048)" that does not carry
a BasicConstraints extension.

I know that Entrust is (or has been) issuing Web Server certificates
under this TA, because I received a few customer problems where our
software rejected server credentials under this rootCA due to its lack
of the BasicConstraints extension in an X.509v3(!) certificate.

-Martin

Date: Mon, 21 Feb 2011 08:50:36 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-04.txt

On 2/21/11 4:57 AM, Stephen Kent wrote:
> At 12:10 PM -0800 2/20/11, Paul Hoffman wrote:
>> On 2/19/11 8:21 PM, Scott Schmit wrote:
>>> Some of these are nits, some not:
>>
>> And all are appreciated.
>>
>>> Abstract:
>>> ---------
>>>
>>>> TLS and DTLS use certificates for authenticating the server. Users
>>>> want their applications to verify that the certificate provided by
>>>> the TLS server is in fact associated with the domain name they
>>>> expect. 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. This document describes how to use secure DNS to
>>>> associate the TLS server's certificate with the the intended domain
>>>> name.
>>>
>>> I would argue that in DNSSEC, each zone operator is a CA, just not a
>>> PKIX CA.
>>
>> I would disagree. It is a trust anchor, not a certification authority.
>> Yes, most users today don't understand the difference, but we should
>> still be fairly precise in our language because some do. In specific,
>> certification authorities do many things that are unimportant to most
>> users but are definitely not done by zone operators. For example, zone
>> operators probably do not do proof-of-possession checks for the the
>> private key paired to the public key in the certificate, whereas most
>> CAs do.
>
> I agree that the info in the record could be a TA, and not a CA, but not if
> the format of the data is an X.509 cert.

The data might not always be an X.509 cert. TLS might be extended to use 
bare keys in the server's certificate message, and/or using OpenPGP 
certificates might end up being a standard, and/or other certification 
methods might appear in the future. I don't think that limiting TLSA to 
PKIX now is good planning for the future.

> Also, will not performing PoP
> be a good outcome?

What would be the security reason for a DNS admin who has been told 
"please announce this certificate for this domain name" to need to learn 
about proof-of-possession?

Date: Mon, 21 Feb 2011 08:47:13 -0800
From: Paul Hoffman <[email-masked]>
To: Stephen Kent <[email-masked]>
Cc: [email-masked], dane issue tracker <[email-masked]>
Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of the two fields to have fewer certificate types

On 2/21/11 4:55 AM, Stephen Kent wrote:
> At 7:59 PM +0000 2/20/11, dane issue tracker wrote:
>> #20: Change the format of the two fields to have fewer certificate types
>>
>> To reduce the chance that someone could give a certificate type that
>> doesn't match the hash type, change the fields as follows:
>>
>> o A one-octet value, called "certificate type", specifying the
>> provided association that will be used to match the target
>> certificate. This will be an IANA registry in order to make it
>> easier to add additional certificate types in the future. The
>> types defined in this document are:
>>
>> 1 -- An end-entity certificate
>>
>> 2 -- A certification authority's certificate
>
> if we're talking about X.509 certs, this distinction is already expressed
> within the cert itself, via the BasicConstraints extension. Not sure why
> one would need to express this cert type in the record as well, when a
> cert (vs. hash) is present).

Simplicity. If you know you are holding an EE cert, you do this; if you 
know you are holding a CA cert, you do that. If we remove the 
differentiation in TLSA protocol, we force every client to do something 
they don't have to do now, namely to disassemble the cert to determine 
the type. That currently happens in the path processing software, but 
that software is usually a black box to the main TLS software. If we 
eliminate the certificate type differentiation, it has to happen before 
certificate comparison can happen.

> Even if a cert hash is the record content,
> when the
> relying party matches the hash against the cert, the cert will still say
> whether it is an E or a CA cert. If we put this info here, it creates an
> opportunity
> for a mismatch between the two, and a need to describe (and defend) why
> one trumps the other.

Fully agree on the possibility of the mismatch, but in that case the 
TLSA association will fail for everyone and the DNS admin will hear 
about it. The cost of the possibility of mismatch should be weighed 
against the cost of making everyone add new ASN.1 parsing code to look 
for the cA bit in the basicConstraints extension.

Date: Mon, 21 Feb 2011 08:36:33 -0800
From: Phillip Hallam-Baker <[email-masked]>
To: [email-masked]
Cc: Scott Schmit <[email-masked]>
Subject: Re: [keyassure] Interpreting certificates (and summary)

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

There is plenty of ambiguity in PKI, but it comes from the complexity of the
tasks and the constraints of the implementations.

The idea that these issues are going to go away because of a syntax change
or a move to DNSSEC is wishful thinking.

We had this particular fight fifteen years ago. I was on the other side at
the time. The last time there was a serious effort to make a change was in
1999 when VeriSign commissioned me to write an XML based spec for certs that
eventually became the foundation for SAML.

Having seen implementation of SAML grow to at least the same degree of
complexity as PKI, this strikes me as a profoundly pointless exercise.

At best it is going to add an option to the spec which Peter has already
indicated he has no interest in implementing or maintaining. Since he is the
maintainer of the main code base here and this issue is primarily one of
code complexity, I think this is rather more his call than that of the
group.

Adding DNSSEC into the code base is going to be a big enough increase in
code complexity as it is.

On Mon, Feb 21, 2011 at 6:45 AM, Scott Schmit <[email-masked]> wrote:

> [Partly a summary, partly an attempt to re-focus the conversation.]
>
> I think we can all appreciate that complexity is the antithesis of
> security, and simpler is better. There have been a significant number of
> vulnerabilities in ASN.1 and X.509 parsing, and there will probably be
> more. And I've also seen expressed (though I can no longer find the
> webpage that went through the problems) that X.509 is a disaster because
> rules for parsing and certificate generation are so ambiguous or
> inconsistent that clients must violate the spec to work in the real
> world. Even if the specs have been fixed, there is almost certainly
> still stuff out there that hasn't changed.
>
> So, it's entirely believable that some people decided that this was just
> too much trouble and came up with their own solution (e.g., SSH). With
> DNSSEC providing a secure place to associate keys with nodes, one could
> imagine future protocols (or existing ones) being interested in using
> the DNS, and DANE seems like a good mechanism for that.
>
> And this is is the attraction of bare keys--in DNSSEC, you have a chain
> of DS records and DNSKEY records linked to some domain name, all
> authenticated using RRSIG records. So clearly, DNSSEC already can do
> certificates (in the sense of a binding of a name to a key), we just
> need a generic way for applications to use that mechanism.
>
> While our current focus is TLS/DTLS, general but simple solutions are
> usually the better ones, so that's another reason for the call for bare
> keys--it seems so much simpler.
>
> Even if you accept all that (and you may not), TLS/DTLS uses X.509
> certs.  Listening to Peter, I have a better appreciation now that
> because the TLS protocol has no native way to say "here's my key, check
> out of band to see if you trust it", the existing code doesn't provide
> the right kind of capabilities or interfaces for the programmer to do
> that reliably, as there was no requirement at the time for such a
> feature.
>
> If we want to see DANE adopted in the near future (or at all) in
> protocols that already exist (i.e. using TLS), we must respect that a
> lot of people aren't going to see the security benefits of DANE being
> worth starting from scratch or significantly rewriting existing, working
> security libraries (and all the risks that implies).  That said, the
> error paths of those libraries are going to take more of a beating, now
> that CAs with a reputation to protect aren't sanitizing the certificate
> fields.
>
> Even if we reuse pieces of what's there, they're still invasive changes
> to ASN.1/X.509 parsing code--the very stuff that has had all those
> problems. Also, the non-DANE case isn't going away overnight, so both
> cases must still be covered (complicating the logic), and the more
> difficult DANE is to adopt, the less overnight it'll be.
>
> So I would suggest (and I have no hat, it's just a suggestion) that the
> question of bare keys be put aside for the moment. To go with PKIX
> certificates, we need to deal with the problem that PKIX certificates
> have fields that duplicate what DNSSEC is telling the relying party.
> And duplication of information means an opportunity for that information
> to conflict.
>
> Looking at some typical certs, here are some sources of conflict I see:
> * Subject identification (including alt names) vs domain name [???]
> * Validity vs RRSIG period [take the min period]
> * Name constraints vs domain name [???]
> * CRLs/OCSP vs TTL [Use both if CRL/OCSP is indicated]
> * CA flag, path length, etc vs the dane-04 cert type [???]
>
> Other tricky things to resolve:
> * How do EV certs fit in? (Whatever rules we come up with to process
>  subjects can't break the link to EV certs or make it over-permissive)
> * Are there any other PKIX fields that clients use and trust, but are
>  only trustworthy if issued by a third party?
> * Are the changes to certificate validation required to made DANE
>  meaningful just as bad as or worse than adding support for bare keys?
>  (This won't be evident until we answer the above, which is part of why
>  I suggest setting aside the bare key question.)
>
> An item for security considerations:
> * Now that CAs aren't necessarily issuing these certs, the client needs
>  to be much more careful in its parsing (the null terminated vs length-
>  delimited string bug comes to mind)
>
> I'm sure there are other issues, too, but that's a start.
>
> [I hope this helps & fairly represents everyone's positions.]
>
> --
> Scott Schmit
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

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

There is plenty of ambiguity in PKI, but it comes from the complexity of th=
e tasks and the constraints of the implementations.<div><br></div><div>The =
idea that these issues are going to go away because of a syntax change or a=
 move to DNSSEC is wishful thinking.</div>
<div><br></div><div><br></div><div>We had this particular fight fifteen yea=
rs ago. I was on the other side at the time. The last time there was a seri=
ous effort to make a change was in 1999 when VeriSign=A0commissioned=A0me t=
o write an XML based spec for certs that eventually became the foundation f=
or SAML.=A0</div>
<div><br></div><div>Having seen implementation of SAML grow to at least the=
 same degree of complexity as PKI, this strikes me as a profoundly pointles=
s exercise.</div><div><br></div><div>At best it is going to add an option t=
o the spec which Peter has already indicated he has no interest in implemen=
ting or maintaining. Since he is the maintainer of the main code base here =
and this issue is primarily one of code complexity, I think this is rather =
more his call than that of the group.</div>
<div><br></div><div>Adding DNSSEC into the code base is going to be a big e=
nough increase in code complexity as it is.</div><div><br></div><div><br></=
div><div><br><div class=3D"gmail_quote">On Mon, Feb 21, 2011 at 6:45 AM, Sc=
ott Schmit <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">i.gr=
[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;">[Partly a summary, partly an attempt to re-=
focus the conversation.]<br>
<br>
I think we can all appreciate that complexity is the antithesis of<br>
security, and simpler is better. There have been a significant number of<br=
>
vulnerabilities in ASN.1 and X.509 parsing, and there will probably be<br>
more. And I&#39;ve also seen expressed (though I can no longer find the<br>
webpage that went through the problems) that X.509 is a disaster because<br=
>
rules for parsing and certificate generation are so ambiguous or<br>
inconsistent that clients must violate the spec to work in the real<br>
world. Even if the specs have been fixed, there is almost certainly<br>
still stuff out there that hasn&#39;t changed.<br>
<br>
So, it&#39;s entirely believable that some people decided that this was jus=
t<br>
too much trouble and came up with their own solution (e.g., SSH). With<br>
DNSSEC providing a secure place to associate keys with nodes, one could<br>
imagine future protocols (or existing ones) being interested in using<br>
the DNS, and DANE seems like a good mechanism for that.<br>
<br>
And this is is the attraction of bare keys--in DNSSEC, you have a chain<br>
of DS records and DNSKEY records linked to some domain name, all<br>
authenticated using RRSIG records. So clearly, DNSSEC already can do<br>
certificates (in the sense of a binding of a name to a key), we just<br>
need a generic way for applications to use that mechanism.<br>
<br>
While our current focus is TLS/DTLS, general but simple solutions are<br>
usually the better ones, so that&#39;s another reason for the call for bare=
<br>
keys--it seems so much simpler.<br>
<br>
Even if you accept all that (and you may not), TLS/DTLS uses X.509<br>
certs. =A0Listening to Peter, I have a better appreciation now that<br>
because the TLS protocol has no native way to say &quot;here&#39;s my key, =
check<br>
out of band to see if you trust it&quot;, the existing code doesn&#39;t pro=
vide<br>
the right kind of capabilities or interfaces for the programmer to do<br>
that reliably, as there was no requirement at the time for such a<br>
feature.<br>
<br>
If we want to see DANE adopted in the near future (or at all) in<br>
protocols that already exist (i.e. using TLS), we must respect that a<br>
lot of people aren&#39;t going to see the security benefits of DANE being<b=
r>
worth starting from scratch or significantly rewriting existing, working<br=
>
security libraries (and all the risks that implies). =A0That said, the<br>
error paths of those libraries are going to take more of a beating, now<br>
that CAs with a reputation to protect aren&#39;t sanitizing the certificate=
<br>
fields.<br>
<br>
Even if we reuse pieces of what&#39;s there, they&#39;re still invasive cha=
nges<br>
to ASN.1/X.509 parsing code--the very stuff that has had all those<br>
problems. Also, the non-DANE case isn&#39;t going away overnight, so both<b=
r>
cases must still be covered (complicating the logic), and the more<br>
difficult DANE is to adopt, the less overnight it&#39;ll be.<br>
<br>
So I would suggest (and I have no hat, it&#39;s just a suggestion) that the=
<br>
question of bare keys be put aside for the moment. To go with PKIX<br>
certificates, we need to deal with the problem that PKIX certificates<br>
have fields that duplicate what DNSSEC is telling the relying party.<br>
And duplication of information means an opportunity for that information<br=
>
to conflict.<br>
<br>
Looking at some typical certs, here are some sources of conflict I see:<br>
* Subject identification (including alt names) vs domain name [???]<br>
* Validity vs RRSIG period [take the min period]<br>
* Name constraints vs domain name [???]<br>
* CRLs/OCSP vs TTL [Use both if CRL/OCSP is indicated]<br>
* CA flag, path length, etc vs the dane-04 cert type [???]<br>
<br>
Other tricky things to resolve:<br>
* How do EV certs fit in? (Whatever rules we come up with to process<br>
 =A0subjects can&#39;t break the link to EV certs or make it over-permissiv=
e)<br>
* Are there any other PKIX fields that clients use and trust, but are<br>
 =A0only trustworthy if issued by a third party?<br>
* Are the changes to certificate validation required to made DANE<br>
 =A0meaningful just as bad as or worse than adding support for bare keys?<b=
r>
 =A0(This won&#39;t be evident until we answer the above, which is part of =
why<br>
 =A0I suggest setting aside the bare key question.)<br>
<br>
An item for security considerations:<br>
* Now that CAs aren&#39;t necessarily issuing these certs, the client needs=
<br>
 =A0to be much more careful in its parsing (the null terminated vs length-<=
br>
 =A0delimited string bug comes to mind)<br>
<br>
I&#39;m sure there are other issues, too, but that&#39;s a start.<br>
<br>
[I hope this helps &amp; fairly represents everyone&#39;s positions.]<br>
<font color=3D"#888888"><br>
--<br>
Scott Schmit<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>
</font></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a href=
=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--00032555ae8278f4fd049ccd7795--

From: Henry Story <[email-masked]>
Date: Mon, 21 Feb 2011 16:29:30 +0100
To: Paul Hoffman <[email-masked]>
Cc: WebID Incubator Group WG <[email-masked]>, [email-masked]
Subject: Re: [keyassure] publishing the public key

(Just a summary of what I understood of this thread, and a few new =
ideas)

On 20 Feb 2011, at 23:58, Paul Hoffman wrote:

> On 2/20/11 2:51 PM, Paul Wouters wrote:
>> The whole point is we do not want to identify a cert. We want to =
identify a key.
>=20
> That's not the case currently, at least for many of us. Given that the =
only thing that can be used in TLS to identify the server is a =
certificate, most of us want to identify that certificate (or a trust =
anchor that the certificate chains to).

One needs to go beyond appearances a little here. My argument is that =
what identifies a server in TLS is a public key. That this comes in a =
certificate is a distraction, which ends up creating a lot of mail on =
formats and makes it difficult to concentrate on the key point. I will =
put forward the argument why this is so in a semi formal way, and then =
look at the pros and cons I noticed that came up on this thread

  1. A connection by a client C to a TLS service domain:port enables the =
service to prove to C that it has access to the private key privK of the =
corresponding public key pubK.

  2. After the client C has stepped through the protocol it knows that =
the service it is connected to, which it hopes is domain:port knows the =
private key of pubK . Call the handle it has on the service _connSrvc, =
in order to distinguish it from the real referent of domain:port . So C =
knows

   _connSrvc knowsPrivateKeyOf pubK . [0]

  But what it wants to know is=20

   _connSrvc =3D=3D domain:port .  [1]

 If knowsPrivateKeyOf is an identifying description - which it is - then =
what C wants to know is

   domain:port knowsPrivateKeyOf pubK .  [2]

 =46rom [2] and [0] it can deduce [1]. The advantage of [2] is that it =
contains no local variable such as _connSrvc, ie it can be published =
globally.

 2.1 CAs
=20
   Currently that is what a certificate signed by a CA  does. It =
essentially says

   CAx saysAndSigns "domain:port knowsPrivateKeyOf pubK. "

   Because C trusts CAx it ends up concluding [2] and then [1] above.

 2.2 DNSsec lookup

   DNSSec lookup works in a similar way, with a twist. The owner of a =
DNS domain can define the meaning of terms in his namespace. So he can =
say of any services under his domain what properties they have. The =
client asking the domain will know, because of the hierarchy of DNSsec =
signatures that

   domainOwner saysAndSigns "domain:port knowsPrivateKeyOf pubK" .

   This is definitional. The domain owner is the one who is allowed to =
specify the meaning of the namespace. He can even specify what the ip =
addresses of the domain is. To use those DNS names is to agree to that: =
each player is the definer of the meaning of the names under his domain, =
which he can the delegate subdomains to other players.

Pros and Cons
-------------

  1. Verification of possession of private key

     Writing the above out made me understand Paul Hoffman's point=20
  =20
    "In specific, certification authorities do many things that are =
unimportant to most users but are definitely not done by zone operators. =
For example, zone operators probably do not do proof-of-possession =
checks for the the private key paired to the public key in the =
certificate, whereas most CAs do."

    http://www.ietf.org/mail-archive/web/keyassure/current/msg01881.html

    Yes, so when I sent my CA a certificate they asked me to send them a =
self signed certificate containing a Domain Name. They then made a DNS =
lookup to find the Administrator's e-mail listed there, where they sent =
the CA signed certificate with that domain name. As I was the =
administrator and the e-mail was correct, I ended up correctly receiving =
the cert for which I had the matching private key.

    In the situation described in 2.2 it would be possible for me to get =
the public key from the Amazon.com certificate, and put it into my =
bblfish.com DNSsec entry where I would also enter Amazon.com's ip =
addresses (if I entered other IP addresses, then connections to port 443 =
of bblfish.com would of course fail). So then it may be thought that =
people coming to bblfish.com would end up on Amazon.com's site. Their =
browser would do the DNSsec verification described in 2.2 and be =
satisfied that bblfish.com had been contacted. Their users might thing =
bblfish.com was an excellent book store, which oddly enough had =
amazon.com written all over it (the issue is less fun if my domain is =
amzon.com). =46rom time to time I could change the ip addresses and =
point them to my credit card collection server. And that is frightening.

    BUT! It's not that simple. On connecting the browser supporting the =
algorithm 2.2, must simply be required to use the 1.2 TLS server_name =
extension which was designed to support virtual hosting. Then the server =
will refuse the connection if the domain it is serving does not match =
the one requested. Furthermore  at present, since the server is sending =
a certificate containing the domain name, the client can also verify =
what the server wishes to be known as. So possession of private key =
verification does not seem to be needed.

  2. On difficulty of comparing ECC keys

    Peter Gutmann made an interesting point that ECC public keys can be =
expressed in a number of equivalent ways which are mathematically =
difficult to compare for equivalence.
http://www.ietf.org/mail-archive/web/keyassure/current/msg01849.html
   =20
    possible answer: I suppose that using the public ECC in the the =
proof of the TLS connection would be ok, but that would push the =
verification very low.=20

    It looks like the Java does equality between X509 key objects based =
on their DER encoding. So my guess is that, unless the internal object =
encodings are somehow canonicalised, then there could be a problem. The =
bouncycastle class has what looks like a mathematically detailed proof =
procedure for testing equality
=
http://www.docjar.com/html/api/org/bouncycastle/jce/provider/JCEECPublicKe=
y.java.html

   If one of them can do it, then it all the rest can do it. ECC is =
still new, and I don't know of many applications that use it. For a =
programmer using the library in the end it will just be a one method =
call=20
pk.equals(pk2).

   We have not found it difficult to do RSA comparisons. One just needs =
to compare a couple of Big Integers. In fact I think it is good for =
people to get out of the certificate magic, and learn how public keys =
really work. If it is really impossible to do ECC key comparison, then =
that's important to know. I would like a few ECC keys that I can prove =
somehow are equal and see what these libraries do.
 =20
  3. Size of keys

     public keys are going to be bigger than signatures, but smaller =
than certificates. I am still not sure what the difference is, and have =
heard different claims here. Of course we should look at minimal, self =
signed certificates and compare those to the public key and to the =
signature and work out what the packet size difference is when it's =
wrapped into the DNSsec wrapper. I know that the main criticism of the =
Dan Bernstein of DNSsec was the size of the packets and how this could =
be used for denial of service attacks. See his talk "High-speed =
high-security cryptography: encrypting and authenticating the whole =
Internet" http://www.youtube.com/watch?v=3Dljt1cxUcZMM . Dan Kaminsky =
had a long response to it
http://dankaminsky.com/2011/01/05/djb-ccc/ but I still think one should =
be careful not to increase the opening here if possible.

  4. X509 richness in extensibility
 =20
   Peter Gutmann wrote: =
http://www.ietf.org/mail-archive/web/keyassure/current/msg01864.html

  "Another reason to stick with X.509 as key bags is that eventually =
you're going
to want to put policy in the DNS ("must connect with TLS", "must use EV
certs", "must use a PFS algorithm like DH/ECDH", "cannot use non-FIPS
algorithms", and so on).  Guess what X.509v3 key bags were specifically
designed for?"
      =20
   That makes sense, but I am not sure how hypothetical those extensions =
are.=20

It is true for example that the SAN extension in X509 would allow a =
WebID to be placed there, that would for example allow the service to be =
described somewhere on the web in more webby, easier to understand and =
to extend manner. That would then furthermore be linkeable, so that one =
could develop linked webs of trust much more easily. For example the SAN =
of a service could point to a profile https://amazon.com/srv/443 which =
could contain in N3/Turtle

 <https://amazon.com/srv/443> co:ownedBy <https://nasdaq.com/co/AMAZN> =
...

And other things describing the service.... Well at least one should =
consider that the extensibility need not be placed inside the X509 cert, =
making it therefore smaller and the DNSsec less prone to attacks.

  5. Complexity of code

     This is I think the weakest argument against raw public keys.

    - I showed that it takes 2 lines of code with existing java =
libraries to parse an X509 public
      key =
http://www.ietf.org/mail-archive/web/keyassure/current/msg01878.html
    - Yaron Sheffer and Paul Wouters point to existing protocols that =
use public keys
      =
http://www.ietf.org/mail-archive/web/keyassure/current/msg01811.html

>=20
> As one of the document editors, if the WG says that it also wants to =
have keys as targets, I will also need (a) a rationale for why this is =
wanted=20

At present I think a lot depends on the difference in size of the keys =
and the load on DNS. Keys can just be more useful than signatures. But =
the extensibility of X509 is a point in its favour too.

> and (b) text explaining how to make a certificate association between =
the key and the certificate that comes from the TLS server. I have asked =
a few times for these, with no luck so far. I don't know that the WG can =
actually decide to add bare keys without knowing how they will be used.

That is perfectly reasonable. But before giving text out it was useful =
to understand the problem space.  I'll leave it at this for the moment. =
This was a very useful conversation, thanks a lot.

   Henry

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

Social Web Architect
http://bblfish.net/

Date: Mon, 21 Feb 2011 09:45:27 -0500
From: Scott Schmit <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: [keyassure] Interpreting certificates (and summary)

[Partly a summary, partly an attempt to re-focus the conversation.]

I think we can all appreciate that complexity is the antithesis of
security, and simpler is better. There have been a significant number of
vulnerabilities in ASN.1 and X.509 parsing, and there will probably be
more. And I've also seen expressed (though I can no longer find the
webpage that went through the problems) that X.509 is a disaster because
rules for parsing and certificate generation are so ambiguous or
inconsistent that clients must violate the spec to work in the real
world. Even if the specs have been fixed, there is almost certainly
still stuff out there that hasn't changed.

So, it's entirely believable that some people decided that this was just
too much trouble and came up with their own solution (e.g., SSH). With
DNSSEC providing a secure place to associate keys with nodes, one could
imagine future protocols (or existing ones) being interested in using
the DNS, and DANE seems like a good mechanism for that.

And this is is the attraction of bare keys--in DNSSEC, you have a chain
of DS records and DNSKEY records linked to some domain name, all
authenticated using RRSIG records. So clearly, DNSSEC already can do
certificates (in the sense of a binding of a name to a key), we just
need a generic way for applications to use that mechanism.

While our current focus is TLS/DTLS, general but simple solutions are
usually the better ones, so that's another reason for the call for bare
keys--it seems so much simpler.

Even if you accept all that (and you may not), TLS/DTLS uses X.509
certs.  Listening to Peter, I have a better appreciation now that
because the TLS protocol has no native way to say "here's my key, check
out of band to see if you trust it", the existing code doesn't provide
the right kind of capabilities or interfaces for the programmer to do
that reliably, as there was no requirement at the time for such a
feature.

If we want to see DANE adopted in the near future (or at all) in
protocols that already exist (i.e. using TLS), we must respect that a
lot of people aren't going to see the security benefits of DANE being
worth starting from scratch or significantly rewriting existing, working
security libraries (and all the risks that implies).  That said, the
error paths of those libraries are going to take more of a beating, now
that CAs with a reputation to protect aren't sanitizing the certificate
fields.

Even if we reuse pieces of what's there, they're still invasive changes
to ASN.1/X.509 parsing code--the very stuff that has had all those
problems. Also, the non-DANE case isn't going away overnight, so both
cases must still be covered (complicating the logic), and the more
difficult DANE is to adopt, the less overnight it'll be.

So I would suggest (and I have no hat, it's just a suggestion) that the
question of bare keys be put aside for the moment. To go with PKIX
certificates, we need to deal with the problem that PKIX certificates
have fields that duplicate what DNSSEC is telling the relying party.
And duplication of information means an opportunity for that information
to conflict.

Looking at some typical certs, here are some sources of conflict I see:
* Subject identification (including alt names) vs domain name [???]
* Validity vs RRSIG period [take the min period]
* Name constraints vs domain name [???]
* CRLs/OCSP vs TTL [Use both if CRL/OCSP is indicated]
* CA flag, path length, etc vs the dane-04 cert type [???]

Other tricky things to resolve:
* How do EV certs fit in? (Whatever rules we come up with to process
  subjects can't break the link to EV certs or make it over-permissive)
* Are there any other PKIX fields that clients use and trust, but are
  only trustworthy if issued by a third party?
* Are the changes to certificate validation required to made DANE
  meaningful just as bad as or worse than adding support for bare keys?
  (This won't be evident until we answer the above, which is part of why
  I suggest setting aside the bare key question.)

An item for security considerations:
* Now that CAs aren't necessarily issuing these certs, the client needs
  to be much more careful in its parsing (the null terminated vs length-
  delimited string bug comes to mind)

I'm sure there are other issues, too, but that's a start.

[I hope this helps & fairly represents everyone's positions.]

-- 
Scott Schmit

Date: Mon, 21 Feb 2011 16:03:54 +0200
From: Ilari Liusvaara <[email-masked]>
To: Lawrence Conroy <[email-masked]>
Sender: Ilari Liusvaara <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of the two fields to have fewer certificate types

On Mon, Feb 21, 2011 at 01:14:20PM +0000, Lawrence Conroy wrote:
> On 21 Feb 2011, at 12:55, Stephen Kent wrote:
> 
>  Will there ever be more than one DANE record at the owner?
>  If so, and there are two such records, might one refer to one cert with the other refers to a different cert?
>   If that happens, might it be useful for a client to be able to scan the records without processing the certs themselves.
>    [e.g. if the client is interested only in end entity certs]

("Ceritificate" here means certificate in the sense TLS defines it).

Yes. Some usecases:

- Certificate rollover (to avoid getting into trouble with TTLs)[1].
- Multiple (quad-)A records pointing at different hosts having different keys.
- Multiple certificates (hashes, TLS certificate types, etc...)[2]

[1] This should do the trick:

1) Insert TLSA record for new certificate
2) Wait at least one positive TTL.
3) Change the certificate webserver sends.
4) Remove the old TLSA record.

[2] These certificates can share the key if it is strong enough, because
TLS key usage is certificate format independent (key usage is implicit
in TLS 1.0/1.1, and implicit with extensions to override defaults in
TLS 1.2).

-Ilari

Date: Mon, 21 Feb 2011 06:02:43 -0800
From: Ben Laurie <[email-masked]>
To: Stephen Kent <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-04.txt

On 21 February 2011 04:57, Stephen Kent <[email-masked]> wrote:
> At 12:10 PM -0800 2/20/11, Paul Hoffman wrote:
>>
>> On 2/19/11 8:21 PM, Scott Schmit wrote:
>>>
>>> Some of these are nits, some not:
>>
>> And all are appreciated.
>>
>>> Abstract:
>>> ---------
>>>
>>>> =A0TLS and DTLS use certificates for authenticating the server. =A0Use=
rs
>>>> =A0want their applications to verify that the certificate provided by
>>>> =A0the TLS server is in fact associated with the domain name they
>>>> =A0expect. =A0Instead of trusting a certification authority to have ma=
de
>>>
>>> =A0 =A0 =A0 =A0 =A0 =A0 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^=
^^^^^^^^^^^
>>>>
>>>> =A0this association correctly, the user might instead trust the
>>>
>>> =A0 =A0^^^^^^^^^^^^^^^^^^^^^^^^^^
>>>>
>>>> =A0authoritative DNS server for the domain name to make that
>>>> =A0association. =A0This document describes how to use secure DNS to
>>>> =A0associate the TLS server's certificate with the the intended domain
>>>> =A0name.
>>>
>>> I would argue that in DNSSEC, each zone operator is a CA, just not a
>>> PKIX CA.
>>
>> I would disagree. It is a trust anchor, not a certification authority.
>> Yes, most users today don't understand the difference, but we should sti=
ll
>> be fairly precise in our language because some do. In specific,
>> certification authorities do many things that are unimportant to most us=
ers
>> but are definitely not done by zone operators. For example, zone operato=
rs
>> probably do not do proof-of-possession checks for the the private key pa=
ired
>> to the public key in the certificate, whereas most CAs do.
>
> I agree that the info in the record could be a TA, and not a CA, but not =
if
> the format of the data is an X.509 cert.

You said a minute ago: "if you issue an X.509 cert under which other
certs will be validated,
you are a CA."

This sounds correct to me. However, mostly what's being done here is
_not_ the issuing of X.509 certs under which other certs will be
validated (though it is an option), so most times the zone operator is
not a CA.

In any case it does seem worth making clear when we are talking about
a PKIX CA vs. any other kind.

> Also, will not performing PoP be a
> good outcome?

What would be the point of proving to myself that I own a key?

Date: Mon, 21 Feb 2011 05:37:19 -0800
From: Phillip Hallam-Baker <[email-masked]>
To: Peter Gutmann <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of the two fields to have fewer certificate types

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

There are two sets of issues:

1) To distinguish between different types of X.509v3 cert

2) To distinguish between different types of cert (X.509, SAML, PGP, etc...)

The first is covered by the X.509 spec, the second is not. So either the
spec has to say that it only allows use of X.509 keys or there has to be a
mechanism to allow the client to work out what type of information it is
handling.

On Sun, Feb 20, 2011 at 12:15 PM, Peter Gutmann
<[email-masked]>wrote:

> > To reduce the chance that someone could give a certificate type that
> > doesn't match the hash type, change the fields as follows:
> >
> > o  A one-octet value, called "certificate type", specifying the
> >    provided association that will be used to match the target
> >    certificate.  This will be an IANA registry in order to make it
> >    easier to add additional certificate types in the future.  The
> >    types defined in this document are:
> >
> >       1 -- An end-entity certificate
> >       2 -- A certification authority's certificate
>
> What's the thinking behind this?  If I'm looking up a cert by a unique key,
> the hash value, then anything else is superfluous.  How, as an implementer,
> am
> I supposed to use the certificate type?
>
> Peter.
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

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

There are two sets of issues:<div><br></div><div>1) To distinguish between =
different types of X.509v3 cert</div><div><br></div><div>2) To distinguish =
between different types of cert (X.509, SAML, PGP, etc...)</div><div><br>
</div><div><br></div><div>The first is covered by the X.509 spec, the secon=
d is not. So either the spec has to say that it only allows use of X.509 ke=
ys or there has to be a mechanism to allow the client to work out what type=
 of information it is handling.</div>
<div><br></div><div><br><div class=3D"gmail_quote">On Sun, Feb 20, 2011 at =
12:15 PM, Peter Gutmann <span dir=3D"ltr">&lt;<a href=3D"mailto:pgut001@cs.=
auckland.ac.nz">[email-masked]</a>&gt;</span> wrote:<br><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; To reduce the chance that someone could give a certi=
ficate type that<br>
&gt; doesn&#39;t match the hash type, change the fields as follows:<br>
&gt;<br>
&gt; o =A0A one-octet value, called &quot;certificate type&quot;, specifyin=
g the<br>
&gt; =A0 =A0provided association that will be used to match the target<br>
&gt; =A0 =A0certificate. =A0This will be an IANA registry in order to make =
it<br>
&gt; =A0 =A0easier to add additional certificate types in the future. =A0Th=
e<br>
&gt; =A0 =A0types defined in this document are:<br>
&gt;<br>
&gt; =A0 =A0 =A0 1 -- An end-entity certificate<br>
&gt; =A0 =A0 =A0 2 -- A certification authority&#39;s certificate<br>
<br>
</div>What&#39;s the thinking behind this? =A0If I&#39;m looking up a cert =
by a unique key,<br>
the hash value, then anything else is superfluous. =A0How, as an implemente=
r, am<br>
I supposed to use the certificate type?<br>
<font color=3D"#888888"><br>
Peter.<br>
</font><div><div></div><div class=3D"h5">__________________________________=
_____________<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>
</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>

--20cf30549e937dc975049ccaf6e9--

From: Lawrence Conroy <[email-masked]>
Date: Mon, 21 Feb 2011 13:14:20 +0000
To: Stephen Kent <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of the two fields to have fewer certificate types

On 21 Feb 2011, at 12:55, Stephen Kent wrote:

> At 7:59 PM +0000 2/20/11, dane issue tracker wrote:
>> #20: Change the format of the two fields to have fewer certificate =
types
>>=20
>> To reduce the chance that someone could give a certificate type that
>> doesn't match the hash type, change the fields as follows:
>>=20
>> o  A one-octet value, called "certificate type", specifying the
>>    provided association that will be used to match the target
>>    certificate.  This will be an IANA registry in order to make it
>>    easier to add additional certificate types in the future.  The
>>    types defined in this document are:
>>=20
>>       1 -- An end-entity certificate
>>=20
>>       2 -- A certification authority's certificate
>=20
> if we're talking about X.509 certs, this distinction is already =
expressed
> within the cert itself, via the BasicConstraints extension. Not sure =
why one would need to express this cert type in the record as well, when =
a cert (vs. hash) is present).  Even if a cert hash is the record =
content, when the
> relying party matches the hash against the cert, the cert will still =
say whether it is an E or a CA cert.  If we put this info here, it =
creates an opportunity
> for a mismatch between the two, and a need to describe (and defend) =
why
> one trumps the other.
>=20
> Steve

To which I reply, hesitantly:

This may be a really stupid comment, but ...
 Will there ever be more than one DANE record at the owner?
 If so, and there are two such records, might one refer to one cert with =
the other refers to a different cert?
  If that happens, might it be useful for a client to be able to scan =
the records without processing the certs themselves.
   [e.g. if the client is interested only in end entity certs]

With apologies for the lack of clue ...

all the best,
  Lawrence

Date: Mon, 21 Feb 2011 07:57:18 -0500
To: Paul Hoffman <[email-masked]>
From: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-04.txt

At 12:10 PM -0800 2/20/11, Paul Hoffman wrote:
>On 2/19/11 8:21 PM, Scott Schmit wrote:
>>Some of these are nits, some not:
>
>And all are appreciated.
>
>>Abstract:
>>---------
>>
>>>   TLS and DTLS use certificates for authenticating the server.  Users
>>>   want their applications to verify that the certificate provided by
>>>   the TLS server is in fact associated with the domain name they
>>>   expect.  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.  This document describes how to use secure DNS to
>>>   associate the TLS server's certificate with the the intended domain
>>>   name.
>>
>>I would argue that in DNSSEC, each zone operator is a CA, just not a
>>PKIX CA.
>
>I would disagree. It is a trust anchor, not a certification 
>authority. Yes, most users today don't understand the difference, 
>but we should still be fairly precise in our language because some 
>do. In specific, certification authorities do many things that are 
>unimportant to most users but are definitely not done by zone 
>operators. For example, zone operators probably do not do 
>proof-of-possession checks for the the private key paired to the 
>public key in the certificate, whereas most CAs do.

I agree that the info in the record could be a TA, and not a CA, but not if
the format of the data is an X.509 cert. Also, will not performing 
PoP be a good outcome?

Steve

Date: Mon, 21 Feb 2011 07:55:31 -0500
To: "dane issue tracker" <[email-masked]>
From: Stephen Kent <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of the two fields to have fewer certificate types

At 7:59 PM +0000 2/20/11, dane issue tracker wrote:
>#20: Change the format of the two fields to have fewer certificate types
>
>  To reduce the chance that someone could give a certificate type that
>  doesn't match the hash type, change the fields as follows:
>
>  o  A one-octet value, called "certificate type", specifying the
>     provided association that will be used to match the target
>     certificate.  This will be an IANA registry in order to make it
>     easier to add additional certificate types in the future.  The
>     types defined in this document are:
>
>        1 -- An end-entity certificate
>
>        2 -- A certification authority's certificate

if we're talking about X.509 certs, this distinction is already expressed
within the cert itself, via the BasicConstraints extension. Not sure 
why one would need to express this cert type in the record as well, 
when a cert (vs. hash) is present).  Even if a cert hash is the 
record content, when the
relying party matches the hash against the cert, the cert will still 
say whether it is an E or a CA cert.  If we put this info here, it 
creates an opportunity
for a mismatch between the two, and a need to describe (and defend) why
one trumps the other.

Steve

Date: Mon, 21 Feb 2011 07:48:18 -0500
To: Scott Schmit <[email-masked]>
From: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-04.txt

At 11:21 PM -0500 2/19/11, Scott Schmit wrote:
>On Thu, Feb 10, 2011 at 02:45:02PM -0800, [email-masked] wrote:
>>	Title           : Using Secure DNS to Associate Certificates 
>>with Domain Names For TLS
>>	Author(s)       : P. Hoffman, J. Schlyter
>>	Filename        : draft-ietf-dane-protocol-04.txt
>>	Pages           : 11
>>	Date            : 2011-02-10
>
>Some of these are nits, some not:
>
>Abstract:
>---------
>
>>   TLS and DTLS use certificates for authenticating the server.  Users
>>   want their applications to verify that the certificate provided by
>>   the TLS server is in fact associated with the domain name they
>>   expect.  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.  This document describes how to use secure DNS to
>>   associate the TLS server's certificate with the the intended domain
>>   name.
>
>I would argue that in DNSSEC, each zone operator is a CA, just not a
>PKIX CA.

If you issue an X.509 cert under which other certs will be validated,
you are a CA.

Steve

Date: Mon, 21 Feb 2011 01:26:29 -0500
From: Scott Schmit <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of the two fields to have fewer certificate types

On Sun, Feb 20, 2011 at 12:32:39PM -0800, Paul Hoffman wrote keyassure:
> On 2/20/11 12:15 PM, Peter Gutmann wrote:
> >>To reduce the chance that someone could give a certificate type that
> >>doesn't match the hash type, change the fields as follows:
> >>
> >>o  A one-octet value, called "certificate type", specifying the
> >>    provided association that will be used to match the target
> >>    certificate.  This will be an IANA registry in order to make it
> >>    easier to add additional certificate types in the future.  The
> >>    types defined in this document are:
> >>
> >>       1 -- An end-entity certificate
> >>       2 -- A certification authority's certificate
> >
> >What's the thinking behind this?  If I'm looking up a cert by a unique key,
> >the hash value, then anything else is superfluous.  How, as an implementer, am
> >I supposed to use the certificate type?
> 
> Unless we mandate one or more hash functions, we cannot assume a
> hash value. Once we mandate one or more hash functions, getting them
> changed later will cause a gap interoperability. Allowing the full
> cert as one of the identity types allows DNS admins who want to
> assure maximum interop to be able to identify the certificates, at
> the cost of larger DNS responses.

I don't think that was the question that Peter was asking. Instead, he
was asking how the certificate type is used.

dane-04 section 2.3 specifies that for EE certs, the cert/hash is
required to match the first cert in the chain. For CA certs, the
cert/hash is required to match anything but the first cert in the chain.

The draft doesn't explicitly say what use cases these cover, but
presumably the purpose of the EE cert case is to simply state what cert
the server is expected to use (and allow for the simple case: a
self-signed cert).

In the CA cert case, the TLSA record asserts what CA cert is expected to
validate the EE cert. This can be done to maintain compatibility to
non-DANE clients while excluding other CAs from being able to issue
false certificates for DANE clients. Alternatively, it can provide trust
to an internal CA in a way not unlike the EE cert case.

Another question Peter is probably asking is "who cares?" Does the TLSA
record really need to say one way or another?

The certificate already identifies if it's a CA or EE certificate (or
even both, but the chain sent by the TLS server will say how it's being
used). So, in the case of a certificate, this is yet another case where
the data in the DNS could contradict the data in the certificate (and
thus is something for us to describe how to handle). And if your choice
of hash algorithm allows an attacker to find a collision and substitute
one for another, you shouldn't be using that algorithm anymore.

On the other hand, a bare key isn't going to make that assertion by
itself (unless you include more pieces of the certificate structure,
which slides you toward "just use certificates and save everybody the
trouble"), unless the TLSA record says. But the more I think about it,
the more I'm not even sure it needs to--if I as an attacker could use
the EE-intended key in a CA cert, I don't need to bother (I have the
key, just use it!) and vice versa. Is there an attack I'm missing?

Another (probably better) use for the cert type field is to distinguish
between X.509 certificate in DER encoding, OpenPGP, bare key, etc. I
think we want adoption of DANE to be quick and widespread, we must
support the first. The others could be added later. To support later
growth, we'd still need the field, even though it would only have one
assigned value (other than private use).

-- 
Scott Schmit

From: Peter Gutmann <[email-masked]>
To: [email-masked], [email-masked]
Date: Mon, 21 Feb 2011 15:42:52 +1300
Cc: [email-masked]
Subject: Re: [keyassure] publishing the public key

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

>You do not make code simpler by introducing additional code paths. You only
>make code simpler if you remove them. The way to make this code base simpler
>is to remove the code path that you are proposing.

Couldn't have put it better myself.  To respond to the OP, instead of guessing 
what implementers might in theory do if you bothered to ask them, why not 
actually ask them?  As a TLS implementer myself, I have absolutely zero 
interest in supporting yet another arbitrary key format (and the ensuing 
increase in complexity and attack surface), particularly one that serves no 
purpose that I've been able to identify.

Peter.

Date: Sun, 20 Feb 2011 15:59:35 -0800
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Wouters <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] publishing the public key

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

On Sun, Feb 20, 2011 at 2:57 PM, Paul Wouters <[email-masked]> wrote:

> On Sat, 19 Feb 2011, Phillip Hallam-Baker wrote:
>
>  The problem with this approach is that it means that we are going to at
>> best be exercising new code paths in existing
>> code. At worst we are going to force people to write new code.
>>
>> It is impossible to run TLS without X.509 code in the stack. Everything
>> else is superfluous.
>>
>> This is really bikeshedding. It is not going to simplify implementation by
>> an iota and it is going to create yet another
>> special case to support.
>>
>> I don't think the crypto community wants to support yet another key
>> format. Even if that format is 'merely' a subset of
>> an existing format.
>>
>
> The alternative is shipping a bunch of nonsense fields for eternity. If
> you assume that the self signed certs will migrate to DNSSEC validation,
> then that would be the vast majority of certificates out there. The
> crypto community should not want that either, though I don't claim to
> represent them.

Just like the useless Edison light bulb screw fitting that has been the
standard here for over a century despite better options, the existing
standards will continue until there is a paradigm shift that cannot be
accommodated in a backwards compatible manner (e.g. halogen bulbs).

What is being discussed here is not such a paradigm shift.

There are many things in the world that are bad and worth changing. ASN.1 is
bad, but it is not one of them.

You do not make code simpler by introducing additional code paths. You only
make code simpler if you remove them. The way to make this code base simpler
is to remove the code path that you are proposing.

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

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

<br><br><div class=3D"gmail_quote">On Sun, Feb 20, 2011 at 2:57 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;">
<div class=3D"im">On Sat, 19 Feb 2011, Phillip Hallam-Baker wrote:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
The problem with this approach is that it means that we are going to at bes=
t be exercising new code paths in existing<br>
code. At worst we are going to force people to write new code.<br>
<br>
It is impossible to run TLS without X.509 code in the stack. Everything els=
e is superfluous.<br>
<br>
This is really bikeshedding. It is not going to simplify implementation by =
an iota and it is going to create yet another<br>
special case to support.=A0<br>
<br>
I don&#39;t think the crypto community wants to support yet another key for=
mat. Even if that format is &#39;merely&#39; a subset of<br>
an existing format.<br>
</blockquote>
<br></div>
The alternative is shipping a bunch of nonsense fields for eternity. If<br>
you assume that the self signed certs will migrate to DNSSEC validation,<br=
>
then that would be the vast majority of certificates out there. The<br>
crypto community should not want that either, though I don&#39;t claim to<b=
r>
represent them.</blockquote><div><br></div><div><br></div><div>Just like th=
e useless Edison light bulb screw fitting that has been the standard here f=
or over a century despite better options, the existing standards will conti=
nue until there is a paradigm shift that cannot be accommodated in a backwa=
rds compatible manner (e.g. halogen bulbs).</div>
<div><br></div><div>What is being discussed here is not such a paradigm shi=
ft.</div><div><br></div><div><br></div><div>There are many things in the wo=
rld that are bad and worth changing. ASN.1 is bad, but it is not one of the=
m.=A0</div>
<div><br></div><div>You do not make code simpler by introducing additional =
code paths. You only make code simpler if you remove them. The way to make =
this code base simpler is to remove the code path that you are proposing.</=
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>

--20cf30549e930445f5049cbf8a4c--

Date: Sun, 20 Feb 2011 15:32:14 -0800
From: Paul Hoffman <[email-masked]>
To: Paul Wouters <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] publishing the public key

On 2/20/11 3:16 PM, Paul Wouters wrote:
> On Sun, 20 Feb 2011, Paul Hoffman wrote:
>
>> On 2/20/11 2:51 PM, Paul Wouters wrote:
>>> The whole point is we do not want to identify a cert. We want to
>>> identify a key.
>>
>> That's not the case currently, at least for many of us.
>
> I'm unclear if you mean "currently with CAs" or "currently within the
> DANE draft".

Neither: I mean "currently with the WG, as far as this discussion has gone".

>> Given that the only thing that can be used in TLS to identify the
>> server is a certificate, most of us want to identify that certificate
>> (or a trust anchor that the certificate chains to).
>
> You confuse me here too. We have an RRlabel, which replaces the
> validated CN=
> and the key (blob or hash) that replaces the public key part of the cert.

Quite true. But we don't have any text that says that.

>> As one of the document editors, if the WG says that it also wants to
>> have keys as targets, I will also need (a) a rationale for why this is
>> wanted and (b) text explaining how to make a certificate association
>> between the key and the certificate that comes from the TLS server. I
>> have asked a few times for these, with no luck so far. I don't know
>> that the WG can actually decide to add bare keys without knowing how
>> they will be used.
>
> I will get that to you before Prague.

Ah! So we will. If someone comes up with text before then, great, but if 
not, can we put this discussion on hold until we have something concrete 
to discuss?

Date: Sun, 20 Feb 2011 18:16:10 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] publishing the public key

On Sun, 20 Feb 2011, Paul Hoffman wrote:

> On 2/20/11 2:51 PM, Paul Wouters wrote:
>> The whole point is we do not want to identify a cert. We want to
>> identify a key.
>
> That's not the case currently, at least for many of us.

I'm unclear if you mean "currently with CAs" or "currently within the DANE draft".

> Given that the only 
> thing that can be used in TLS to identify the server is a certificate, most 
> of us want to identify that certificate (or a trust anchor that the 
> certificate chains to).

You confuse me here too. We have an RRlabel, which replaces the validated CN=
and the key (blob or hash) that replaces the public key part of the cert.

> As one of the document editors, if the WG says that it also wants to have 
> keys as targets, I will also need (a) a rationale for why this is wanted and 
> (b) text explaining how to make a certificate association between the key and 
> the certificate that comes from the TLS server. I have asked a few times for 
> these, with no luck so far. I don't know that the WG can actually decide to 
> add bare keys without knowing how they will be used.

I will get that to you before Prague.

Paul

Date: Sun, 20 Feb 2011 14:58:28 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] publishing the public key

On 2/20/11 2:51 PM, Paul Wouters wrote:
> The whole point is we do not want to identify a cert. We want to
> identify a key.

That's not the case currently, at least for many of us. Given that the 
only thing that can be used in TLS to identify the server is a 
certificate, most of us want to identify that certificate (or a trust 
anchor that the certificate chains to).

As one of the document editors, if the WG says that it also wants to 
have keys as targets, I will also need (a) a rationale for why this is 
wanted and (b) text explaining how to make a certificate association 
between the key and the certificate that comes from the TLS server. I 
have asked a few times for these, with no luck so far. I don't know that 
the WG can actually decide to add bare keys without knowing how they 
will be used.

Date: Sun, 20 Feb 2011 17:57:00 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] publishing the public key

On Sat, 19 Feb 2011, Phillip Hallam-Baker wrote:

> The problem with this approach is that it means that we are going to at best be exercising new code paths in existing
> code. At worst we are going to force people to write new code.
> 
> It is impossible to run TLS without X.509 code in the stack. Everything else is superfluous.
> 
> This is really bikeshedding. It is not going to simplify implementation by an iota and it is going to create yet another
> special case to support.�
> 
> I don't think the crypto community wants to support yet another key format. Even if that format is 'merely' a subset of
> an existing format.

The alternative is shipping a bunch of nonsense fields for eternity. If
you assume that the self signed certs will migrate to DNSSEC validation,
then that would be the vast majority of certificates out there. The
crypto community should not want that either, though I don't claim to
represent them.

Paul

Date: Sun, 20 Feb 2011 17:51:46 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Peter Gutmann <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] publishing the public key

On Sat, 19 Feb 2011, Peter Gutmann wrote:

> It's not impossible, but close to it (and for ECC algos it may well be
> impossible).  This is a really, really bad way to identify a cert.

The whole point is we do not want to identify a cert. We want to identify a key.

> cert, for which you call memcmp(), thus the "all" in quotes above).  For ECC
> keys there are so many ways to store the same key (different parameter
> encodings, optional parameters, different ways of identifying the same
> parameters and in different formats) that in general there's no really
> reliable way to compare them.  Even with the simplest key type, RSA, it was
> hard enough, I've got code that mostly works most of the time and that's way
> more complicated than it has to be.

But such a method can be standardised in an RFC? And possibly be re-used for
other standards - like DNSKEY.

> If you want to uniquely identify a certificate, use the SHA-1 hash like
> everything else does.

Sure. That's one of the options in the TLSA draft right now.

Paul

Date: Sun, 20 Feb 2011 12:32:39 -0800
From: Paul Hoffman <[email-masked]>
To: Peter Gutmann <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of the two fields to have fewer certificate types

On 2/20/11 12:15 PM, Peter Gutmann wrote:
>> To reduce the chance that someone could give a certificate type that
>> doesn't match the hash type, change the fields as follows:
>>
>> o  A one-octet value, called "certificate type", specifying the
>>     provided association that will be used to match the target
>>     certificate.  This will be an IANA registry in order to make it
>>     easier to add additional certificate types in the future.  The
>>     types defined in this document are:
>>
>>        1 -- An end-entity certificate
>>        2 -- A certification authority's certificate
>
> What's the thinking behind this?  If I'm looking up a cert by a unique key,
> the hash value, then anything else is superfluous.  How, as an implementer, am
> I supposed to use the certificate type?

Unless we mandate one or more hash functions, we cannot assume a hash 
value. Once we mandate one or more hash functions, getting them changed 
later will cause a gap interoperability. Allowing the full cert as one 
of the identity types allows DNS admins who want to assure maximum 
interop to be able to identify the certificates, at the cost of larger 
DNS responses.

From: Peter Gutmann <[email-masked]>
To: [email-masked], [email-masked]
Date: Mon, 21 Feb 2011 09:15:05 +1300
Cc: [email-masked]
Subject: Re: [keyassure] [dane] protocol #20 (new): Change the format of the two fields to have fewer certificate types

> To reduce the chance that someone could give a certificate type that
> doesn't match the hash type, change the fields as follows:
>
> o  A one-octet value, called "certificate type", specifying the
>    provided association that will be used to match the target
>    certificate.  This will be an IANA registry in order to make it
>    easier to add additional certificate types in the future.  The
>    types defined in this document are:
>
>       1 -- An end-entity certificate
>       2 -- A certification authority's certificate

What's the thinking behind this?  If I'm looking up a cert by a unique key,
the hash value, then anything else is superfluous.  How, as an implementer, am
I supposed to use the certificate type?

Peter.

Date: Sun, 20 Feb 2011 12:10:29 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-04.txt

On 2/19/11 8:21 PM, Scott Schmit wrote:
> Some of these are nits, some not:

And all are appreciated.

> Abstract:
> ---------
>
>>   TLS and DTLS use certificates for authenticating the server.  Users
>>   want their applications to verify that the certificate provided by
>>   the TLS server is in fact associated with the domain name they
>>   expect.  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.  This document describes how to use secure DNS to
>>   associate the TLS server's certificate with the the intended domain
>>   name.
>
> I would argue that in DNSSEC, each zone operator is a CA, just not a
> PKIX CA.

I would disagree. It is a trust anchor, not a certification authority. 
Yes, most users today don't understand the difference, but we should 
still be fairly precise in our language because some do. In specific, 
certification authorities do many things that are unimportant to most 
users but are definitely not done by zone operators. For example, zone 
operators probably do not do proof-of-possession checks for the the 
private key paired to the public key in the certificate, whereas most 
CAs do.

>
> How does this sound instead?
>
>     TLS and DTLS use certificates for authenticating the server.  Users
>     want their applications to verify that the certificate provided by
>     the TLS server is in fact associated with the domain name they
>     expect. DNSSEC provides a mechanism for a zone operator to sign DNS
>     information directly.  This way, bindings of keys to domains are
>     asserted not by external entities, but by the entities that operate
>     the DNS.  This document describes how to use secure DNS to associate
>     the TLS server's certificate with the the intended domain name.
>
> (I used the text from the charter, I figured that's the least
> controversial option).

That new text seems fine, and does not assert that DNS operators are CAs 
:-). Having the abstract actually use the words from the charter also 
seems like a good idea.

> Section 2.2:
> ------------
>
> I'm not the first to mention this, but I think the overlap between the
> certificate type and hash type is a bad idea. It allows nonsensical
> combinations to be expressed with all the problems that go with it.
>
> It would make much more sense for the certificate type to only indicate
> the kind of certificate that is referenced, and the second field
> indicates how that reference is formatted in the RDATA. This would
> change the text to something like:
>
>     o  A one-octet value, called "certificate type", specifying the
>        provided association that will be used to match the target
>        certificate.  This will be an IANA registry in order to make it
>        easier to add additional certificate types in the future.  The
>        types defined in this document are:
>
>           1 -- An end-entity certificate
>
>           2 -- A certification authority's certificate
>
>     o  A one-octet value, called "reference type", specifying how the
>        certificate association is presented.  This value is defined in a
>        new IANA registry.  The types defined in this document are:
>
>           0 -- Full certificate in DER encoding
>
>           1 -- SHA-1 hash of the certificate in DER encoding
>
>           2 -- SHA-256 hash of the certificate in DER encoding
>
>           3 -- SHA-384 hash of the certificate in DER encoding
>
>        Using the same hash algorithm as is used in the signature in the
>        certificate will make it more likely that the TLS client will
>        understand this TLSA data.
>
> Unless these are all MUSTs, the document needs to indicate which are
> required and which are not.

Hrm. I like the addition of the 0 type for reference type; it definitely 
solves the silly-state problem. Given that this is an on-the-wire 
change, it needs to be discussed more. I have opened issue #20 for it.

> Section 3:
> ----------
>
> Should "If the application receives zero usable certificate
> associations, it processes TLS in the normal fashion." be a MUST?

It could be, but it doesn't need to be, because that is already covered 
in the TLS spec.

> The last statement in section three should probably be:
>
> "If no match between the usable certificate association(s) and the
> server's end entity certificate in TLS is found, the TLS client MUST
> abort the handshake with an "unknown_ca" error."
>
> This adds "usable" to make clear the distinction between this and the
> "continue as usual" case.

Good catch. Fixed.

> Also, I changed access_denied to unknown_ca.
> According to RFC 5246:
>
>>   unknown_ca
>>      A valid certificate chain or partial chain was received, but the
>>      certificate was not accepted because the CA certificate could not
>>      be located or couldn't be matched with a known, trusted CA.  This
>>      message is always fatal.
>>
>>   access_denied
>>      A valid certificate was received, but when access control was
>>      applied, the sender decided not to proceed with negotiation.  This
>>      message is always fatal.
>
> To me, unknown_ca looks like the correct error -- DANE is about allowing
> DNSSEC to redefine what the trusted CAs are.

However, unknown_ca requires that a chain or partial chain be received, 
and one might not have been sent. For access_denied, you don't need a chain.

> Section 4.2/4.3:
> ----------------
>
> Value 255 is unspecified. Is this a typo, or was that intended to be
> reserved as experimental?

The latter, and yet we forgot to add that to the draft. FWIW, I strongly 
prefer "private use" to "experimental". Fixed in the next version.

> We need to specify which algorithms are required, optional, etc.

Yes we do, but people wanted to push that off to later. I think it is 
still good to delay it until we are sure about the format and so on. I 
have opened this as issue #21 on the tracker.

> I don't think the registry policies are sufficiently restrictive to
> prevent using up the available space. At minimum it should require
> expert review if not IETF Review. Otherwise, the only limitation on
> registration is an independent RFC.

There has been a not great track record with "expert review" for 
registries that have only occasional additions. (Ask Phill about his 
long-delayed request for a new RRtype...)

> Just to demonstrate how quickly the hash type (or whatever it turns
> into) could be used up, NIST is currently holding a competition to
> decide what algorithm will become SHA-3. They are now on their final
> round of competition, and there are no further opportunities for tweaks
> to the algorithms. So, all those algorithms are permanent and readily
> available.

That is an overstatement. NIST has made it clear that it might make 
changes in whatever algorithm it decides.

> So how many would that take up? I count 29 (4 BLAKE, 4 Groestl, 4
> Keccak, 4 JH, 13 Skein). Throw in SHA-224, SHA-512 (from FIPS-180-3),
> SHA-512/224, SHA-512/256 (from FIPS-180-4 once it's finalized), MD5, and
> the existing entries from dane-04, and you have 37 entries--about 1/7th
> of the available space.

And yet none of the SHA-3 candidates have been proposed as hash 
algorithms for this protocol (or any IETF protocol that I know of).

If the registry starts to fill up, the IETF can decide to tighten the 
registration rules at that time. There is no need to over-tighten now.

> Section 5:
> ----------
>
> You have two references to just A records and three to A/AAAA records.
> That's probably incomplete editing to change them all to the latter.

Good catch; done.

> Also, I don't understand this paragraph:
>
>>   A DNS administrator who goes rogue and changes both the A and TLSA
>>   records for a domain name can cause the user to go to an unauthorized
>>   server that will appear authorized, unless the client performs
>>   certificate validation and rejects the certificate.  That
>>   administrator could probably get a certificate issued anyway, so this
>>   is not an additional threat.
>
> What certificate validation is the client going to do that would detect
> this attack?

There is none. The Security Considerations section is for all 
considerations, not just ones that can be easily caught.

> The good news about this kind of attack is that it can be detected (by
> machine, admittedly) since all the certificates/associations are
> published in the DNS (unlike a rogue PKIX CA).

*Might* be caught: an attacker can give different answers to different 
DNS requests. This seems too far down the rathole to want to write 
about, I think, but others might want it.

> Maybe this is a lack of operational experience, but I'm not sure I
> understand why adding or changing TLSA information would be less
> protected than for A/AAAA records?

It isn't: they are identical.

> Hope this helps.

It does indeed. As we move through the open issues, it will be 
interesting to see how the WG feels about the new ones.

From: "dane issue tracker" <[email-masked]>
Auto-Submitted: auto-generated
To: [email-masked]
Date: Sun, 20 Feb 2011 20:01:59 -0000
Cc: [email-masked]
Subject: [keyassure] [dane] protocol #21 (new): Need to specify which crypto algorithms and certificate types are mandatory to implement

#21: Need to specify which crypto algorithms and certificate types are mandatory
to implement

 Currently, the draft is silent on which crypto algorithms and certificate
 types must be implemented for interoperability. It should be specific
 before the document is finished.

-- 
-----------------------------------+----------------------------------------
 Reporter:  paul.hoffman@…         |       Owner:     
     Type:  defect                 |      Status:  new
 Priority:  major                  |   Milestone:     
Component:  protocol               |     Version:     
 Severity:  -                      |    Keywords:     
-----------------------------------+----------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/dane/trac/ticket/21>
dane <http://tools.ietf.org/dane/>

From: "dane issue tracker" <[email-masked]>
Auto-Submitted: auto-generated
To: [email-masked]
Date: Sun, 20 Feb 2011 19:59:26 -0000
Cc: [email-masked]
Subject: [keyassure] [dane] protocol #20 (new): Change the format of the two fields to have fewer certificate types

#20: Change the format of the two fields to have fewer certificate types

 To reduce the chance that someone could give a certificate type that
 doesn't match the hash type, change the fields as follows:

 o  A one-octet value, called "certificate type", specifying the
    provided association that will be used to match the target
    certificate.  This will be an IANA registry in order to make it
    easier to add additional certificate types in the future.  The
    types defined in this document are:

       1 -- An end-entity certificate

       2 -- A certification authority's certificate

 o  A one-octet value, called "reference type", specifying how the
    certificate association is presented.  This value is defined in a
    new IANA registry.  The types defined in this document are:

       0 -- Full certificate in DER encoding

       1 -- SHA-1 hash of the certificate in DER encoding

       2 -- SHA-256 hash of the certificate in DER encoding

       3 -- SHA-384 hash of the certificate in DER encoding

    Using the same hash algorithm as is used in the signature in the
    certificate will make it more likely that the TLS client will
    understand this TLSA data.

-- 
-----------------------------------+----------------------------------------
 Reporter:  paul.hoffman@…         |       Owner:     
     Type:  defect                 |      Status:  new
 Priority:  major                  |   Milestone:     
Component:  protocol               |     Version:     
 Severity:  -                      |    Keywords:     
-----------------------------------+----------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/dane/trac/ticket/20>
dane <http://tools.ietf.org/dane/>

From: Henry Story <[email-masked]>
Date: Sun, 20 Feb 2011 14:15:37 +0100
To: [email-masked]
Cc: WebID Incubator Group WG <[email-masked]>
Subject: Re: [keyassure] publishing the public key

[[
  I am CCing this to the WebID XG Group because it is also relevant =
there
  to ISSUE-39: "Simplify how public keys are expressed"
  which is discussing something very similar to this issue
  http://www.w3.org/2005/Incubator/webid/track/issues/39=20
=20
  For people on that list the thread here is
  http://www.ietf.org/mail-archive/web/keyassure/current/msg01874.html
]]
 =20

On 20 Feb 2011, at 04:01, Peter Gutmann wrote:

> Henry Story <[email-masked]> writes:
>=20
>> Is that the same as X509?=20
>=20
> It *is* X.509, just used as a key bag (with optional attributes).

A bag with only one key though. Sounds more like a singleton.
Just reading RFC5280, I don't see the option of putting more than one =
key in there=20
https://datatracker.ietf.org/doc/rfc5280/

(Though I suppose extensions could be designed for that, though to what =
purpose?...)

Anyway here is how we Dane define the public key. Exactly as in rfc5280

SubjectPublicKeyInfo  ::=3D  SEQUENCE  {
        algorithm            AlgorithmIdentifier,
        subjectPublicKey     BIT STRING  }

Then one just does as they do and point people to more rfcs

[[
4.1.2.7.  Subject Public Key Info

   This field is used to carry the public key and identify the algorithm
   with which the key is used (e.g., RSA, DSA, or Diffie-Hellman).  The
   algorithm is identified using the AlgorithmIdentifier structure
   specified in Section 4.1.1.2.  The object identifiers for the
   supported algorithms and the methods for encoding the public key
   materials (public key and parameters) are specified in [RFC3279],
   [RFC4055], and [RFC4491].
]]

>=20
>> The code to select the subset is going to be at most a few lines.
>=20
> How do you get from CertCreateContext() to =
turn-this-encoded-blob-into-a-
> public-key-context?

Hey, that's a clever way to get free programming time from people: Taunt =
them that they can't do something :-) And you get the added pleasure of =
forcing me to learn ASN.1, which I have been trying to avoid...=20

Note how decoding the key is three lines of code.

So here it goes in Scala (requires Sun JVM).

//
// create an RSA Key
//

import java.security.spec._
import java.math.BigInteger
val keySpec =3D new RSAPublicKeySpec(new =
BigInteger("""E394D1B3CE644D809D8A85B6816E22F6C7741B9A294D2E4CB477733C16FE=
C0C9B346B26078944148114234393CF634A742947E264D1D22A55CF6B5E98ADACD897B9896=
FCDE5836008BBBC8463057F67848F5A31B41B032E4765CD546A1DD7DE3FC2423C88EAC7233=
2AC9174E0BCA4E9FE973D90C3C622617C0CEA69B45C01CFBA90F247C26E1BCE419A251BC46=
287F7B00EDC34B538066CC2A285BB99B423012942768D619D261C1B668EC847E56CCF621D8=
B15E860FC2109317A8261F7AF894F0490703AFF323E88EAD45C4F6B8B34684D81575BF2A78=
AC842FD12AAE5D8EE52C9858087BE3EB8C8C7A0CA9C7ED05EBF411145E20D654A70118D586=
C25332A9""",16), new BigInteger("65537"))

import java.security.KeyFactory;
import java.security.interfaces._
val keyFactory =3D KeyFactory.getInstance("RSA")
val rsaKey =3D =
keyFactory.generatePublic(keySpec).asInstanceOf[RSAPublicKey]

//
// Base64 encode it, ready for publication=20
//

import sun.misc.BASE64Encoder
new BASE64Encoder().encode( rsaKey.getEncoded )

// In pastebin ( http://pastebin.com/TEpMBJK5 )
// you will see this returns
//
// =
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA45TRs85kTYCdioW2gW4i9sd0G5opTS=
5M
// =
tHdzPBb+wMmzRrJgeJRBSBFCNDk89jSnQpR+Jk0dIqVc9rXpitrNiXuYlvzeWDYAi7vIRjBX9n=
hI
// =
9aMbQbAy5HZc1Uah3X3j/CQjyI6scjMqyRdOC8pOn+lz2Qw8YiYXwM6mm0XAHPupDyR8JuG85B=
mi
// =
UbxGKH97AO3DS1OAZswqKFu5m0IwEpQnaNYZ0mHBtmjshH5WzPYh2LFehg/CEJMXqCYfeviU8E=
kH
// =
A6/zI+iOrUXE9rizRoTYFXW/KnishC/RKq5djuUsmFgIe+PrjIx6DKnH7QXr9BEUXiDWVKcBGN=
WG
// wlMyqQIDAQAB
//

//
// Decode the key, which could have been found in DNSsec
//

import sun.security.util.DerValue
val der =3D new DerValue( rsaKey.getEncoded )
val newKey =3D X509Key.parse(der)

The output from the scala shell is shown in=20
   http://pastebin.com/TEpMBJK5

>=20
>> Currently we are not asking to remove the other options. Just to see =
if this
>> option is possible, and to work out what the advantages and =
disadvantages
>> would be.
>=20
> Well I'm OK with that, as long as it's made optional so implementers =
can
> ignore it at their leisure.  Putting it in a seperate RFC would make =
this even
> easier.

Now I think that the argument that this is so difficult has been shown =
to be wrong, I think we can perhaps push the discussion further on this. =
The reasons for or against this here won't be the same as on the WebID =
XG, but it should be instructive none the less.

>=20
> Peter.

Social Web Architect
http://bblfish.net/

Date: Sun, 20 Feb 2011 00:35:10 -0500
From: Scott Schmit <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [keyassure] dane-04 trust anchors

On Sun, Feb 13, 2011 at 02:58:29PM -0500, Paul Wouters wrote:
> On Fri, 11 Feb 2011, Yaron Sheffer wrote:
> >The client MUST obey any constraints included in the trust anchor,
> >including but not limited to:
> >- Validity period.
> 
> What to do if that period does not match the DNS TTL/RRSIG period?

The DNS TTL should be used to determine when the client MUST forget the
certificate association and refetch the TLSA record if it needs it
again.  I think that's the DANE equivalent to revocation (if the TLSA
record is replaced, the old cert was revoked).

The RRSIG period serves a similar role to the Validity period in X.509,
though it'll be much shorter than we're used to for PKIX. I would think
that the most restrictive value wins. The notAfter field can always be
set to be never to avoid needing to regenerate the certificate.

You could probably argue that what I'm saying to use the TTL for is what
the RRSIG period is for, but in my experience with DNSSEC tools, it's a
lot more obvious to me how I'd control (without affecting the period for
other records) the rate a client rechecks the certificate validity via
the TTL.

-- 
Scott Schmit

From: Yoav Nir <[email-masked]>
To: Scott Schmit <[email-masked]>
Date: Sun, 20 Feb 2011 07:22:37 +0200
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] The SSL Proxy Issue

On Feb 19, 2011, at 11:42 PM, Scott Schmit wrote:

> On Sat, Feb 19, 2011 at 12:36:56PM -0800, Paul Hoffman wrote keyassure:
>> On 2/19/11 10:49 AM, Steingruebl, Andy wrote:
>>>> -----Original Message-----
>>>> From: [email-masked] [mailto:[email-masked]] O=
n
>>>> Behalf Of Paul Hoffman
>>>>=20
>>>> Regardless of the number of use cases, why is it an issue for TLSA?
>>>> Given that they are meant to be invisible to the users, isn't that inv=
isibility the
>>>> same with or without TLSA?
>>>=20
>>> In the current CA/Browser (other code also) model there is not exclusio=
n for trust-anchors.  Any trust anchor can make claims for any name.  With =
the advent of DANE/TLSA records, the situation changes.  Please see the oth=
er mail I just sent...
>>=20
>> I'm not understanding you. TLSA is not looking to replace the
>> current trust anchors by removing them from the browser unless the
>> user (or, in the case in question, the user's administrator) wants
>> to remove them. With an SSL proxy, the user has a universal trust
>> anchor added to their browser, and TLSA doesn't affect that at all,
>> if I understand the issue you are raising.
>=20
> TLSA very much affects that -- reread section 3 of the DANE protocol
> draft. A straightforward implementation of DANE will result in the
> client looking up example.com, getting back a TLSA record saying that
> the it should be expecting a particular cert, which is then checked
> against the cert it gets back when connecting via TLS.
>=20
> Except that with the proxy in the way, the client will receive the
> proxy-manufactured cert. Since the two don't match, the connection
> fails. It doesn't matter if the proxy is a TA in the client, because
> DANE overrides that.
>=20
> In the general case, this is by design and desirable. In the specific
> case of managed environments, there are ways around it:
>=20
> The SSL proxy (or another supporting device) could also proxy DNS by
> stripping out all DNSSEC from responses (and configuring the hosts to
> disable DNSSEC). One hopes that the proxy has DNSSEC enabled and uses it
> (and that the internal network/proxy is secure). This disables DANE on
> the internal network (though the proxy could use DANE when talking
> externally).

I'm not sure that would work. DNS clients tend to cache a lot. So if I acce=
ss mail.google.com a lot, my browser will have a cache of all the DNS respo=
nses, including the DANE response. By the time I try to access gmail from m=
y workplace, I'm not making and DNS queries. Instead, I just begin a TLS ha=
ndshake, and get the wrong certificate.=20

Until now, browser makers did not accommodate the SSL proxies in anyway. It=
 was up to the SSL proxies to work around the browsers. I don't think Micro=
soft, Mozilla, Google and Opera will suddenly have the motivation to play a=
long with what is essentially a man-in-the-middle attack.

Date: Sat, 19 Feb 2011 23:21:33 -0500
From: Scott Schmit <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-04.txt

On Thu, Feb 10, 2011 at 02:45:02PM -0800, [email-masked] wrote:
> 	Title           : Using Secure DNS to Associate Certificates with Domain Names For TLS
> 	Author(s)       : P. Hoffman, J. Schlyter
> 	Filename        : draft-ietf-dane-protocol-04.txt
> 	Pages           : 11
> 	Date            : 2011-02-10

Some of these are nits, some not:

Abstract:
---------

>  TLS and DTLS use certificates for authenticating the server.  Users
>  want their applications to verify that the certificate provided by
>  the TLS server is in fact associated with the domain name they
>  expect.  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.  This document describes how to use secure DNS to
>  associate the TLS server's certificate with the the intended domain
>  name.

I would argue that in DNSSEC, each zone operator is a CA, just not a
PKIX CA.

How does this sound instead?

   TLS and DTLS use certificates for authenticating the server.  Users
   want their applications to verify that the certificate provided by
   the TLS server is in fact associated with the domain name they
   expect. DNSSEC provides a mechanism for a zone operator to sign DNS
   information directly.  This way, bindings of keys to domains are
   asserted not by external entities, but by the entities that operate
   the DNS.  This document describes how to use secure DNS to associate
   the TLS server's certificate with the the intended domain name.

(I used the text from the charter, I figured that's the least
controversial option).

Section 2.2:
------------

I'm not the first to mention this, but I think the overlap between the
certificate type and hash type is a bad idea. It allows nonsensical
combinations to be expressed with all the problems that go with it.

It would make much more sense for the certificate type to only indicate
the kind of certificate that is referenced, and the second field
indicates how that reference is formatted in the RDATA. This would
change the text to something like:

   o  A one-octet value, called "certificate type", specifying the
      provided association that will be used to match the target
      certificate.  This will be an IANA registry in order to make it
      easier to add additional certificate types in the future.  The
      types defined in this document are:
 
         1 -- An end-entity certificate
 
         2 -- A certification authority's certificate
 
   o  A one-octet value, called "reference type", specifying how the
      certificate association is presented.  This value is defined in a
      new IANA registry.  The types defined in this document are:
 
         0 -- Full certificate in DER encoding
 
         1 -- SHA-1 hash of the certificate in DER encoding
 
         2 -- SHA-256 hash of the certificate in DER encoding
 
         3 -- SHA-384 hash of the certificate in DER encoding
 
      Using the same hash algorithm as is used in the signature in the
      certificate will make it more likely that the TLS client will
      understand this TLSA data.

Unless these are all MUSTs, the document needs to indicate which are
required and which are not.

Section 3:
----------

Should "If the application receives zero usable certificate
associations, it processes TLS in the normal fashion." be a MUST?

The last statement in section three should probably be:

"If no match between the usable certificate association(s) and the
server's end entity certificate in TLS is found, the TLS client MUST
abort the handshake with an "unknown_ca" error."

This adds "usable" to make clear the distinction between this and the
"continue as usual" case. Also, I changed access_denied to unknown_ca.
According to RFC 5246:

>  unknown_ca
>     A valid certificate chain or partial chain was received, but the
>     certificate was not accepted because the CA certificate could not
>     be located or couldn't be matched with a known, trusted CA.  This
>     message is always fatal.
>
>  access_denied
>     A valid certificate was received, but when access control was
>     applied, the sender decided not to proceed with negotiation.  This
>     message is always fatal.

To me, unknown_ca looks like the correct error -- DANE is about allowing
DNSSEC to redefine what the trusted CAs are.

Section 4.2/4.3:
----------------

Value 255 is unspecified. Is this a typo, or was that intended to be
reserved as experimental?

We need to specify which algorithms are required, optional, etc.

I don't think the registry policies are sufficiently restrictive to
prevent using up the available space. At minimum it should require
expert review if not IETF Review. Otherwise, the only limitation on
registration is an independent RFC.

Just to demonstrate how quickly the hash type (or whatever it turns
into) could be used up, NIST is currently holding a competition to
decide what algorithm will become SHA-3. They are now on their final
round of competition, and there are no further opportunities for tweaks
to the algorithms. So, all those algorithms are permanent and readily
available.

So how many would that take up? I count 29 (4 BLAKE, 4 Groestl, 4
Keccak, 4 JH, 13 Skein). Throw in SHA-224, SHA-512 (from FIPS-180-3),
SHA-512/224, SHA-512/256 (from FIPS-180-4 once it's finalized), MD5, and
the existing entries from dane-04, and you have 37 entries--about 1/7th
of the available space.

Section 5:
----------

You have two references to just A records and three to A/AAAA records.
That's probably incomplete editing to change them all to the latter.

Also, I don't understand this paragraph:

>  A DNS administrator who goes rogue and changes both the A and TLSA
>  records for a domain name can cause the user to go to an unauthorized
>  server that will appear authorized, unless the client performs
>  certificate validation and rejects the certificate.  That
>  administrator could probably get a certificate issued anyway, so this
>  is not an additional threat.

What certificate validation is the client going to do that would detect
this attack?

The good news about this kind of attack is that it can be detected (by
machine, admittedly) since all the certificates/associations are
published in the DNS (unlike a rogue PKIX CA).

Maybe this is a lack of operational experience, but I'm not sure I
understand why adding or changing TLSA information would be less
protected than for A/AAAA records?

Hope this helps.

-- 
Scott Schmit

From: Peter Gutmann <[email-masked]>
To: [email-masked], [email-masked]
Date: Sun, 20 Feb 2011 16:01:53 +1300
Cc: [email-masked]
Subject: Re: [keyassure] publishing the public key

Henry Story <[email-masked]> writes:

>Is that the same as X509? 

It *is* X.509, just used as a key bag (with optional attributes).

>The code to select the subset is going to be at most a few lines.

How do you get from CertCreateContext() to turn-this-encoded-blob-into-a-
public-key-context?

>Currently we are not asking to remove the other options. Just to see if this
>option is possible, and to work out what the advantages and disadvantages
>would be.

Well I'm OK with that, as long as it's made optional so implementers can
ignore it at their leisure.  Putting it in a seperate RFC would make this even
easier.

Peter.

Date: Sat, 19 Feb 2011 17:16:04 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] The SSL Proxy Issue

On 2/19/11 4:59 PM, Phillip Hallam-Baker wrote:
> It really depends on the browser providers. If they consider this to be
> an essential market requirement then it is going to be supported and I
> would prefer for support to be made explicit rather than be something
> buried in the small print. If they don't consider it to be a market
> requirement it is merely something to note in the security considerations.

For now, we'll put it in the Security Considerations. If the WG wants to 
do something more, we'll need an open issue with one or more proposals 
for how to do it technically.

Date: Sat, 19 Feb 2011 16:59:59 -0800
From: Phillip Hallam-Baker <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] The SSL Proxy Issue

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

On Sat, Feb 19, 2011 at 1:42 PM, Scott Schmit <[email-masked]> wrote:

>
> Or Phillip's idea, that the client plays along and makes an exception to
> the DANE processing rules for the proxy. Of course, if you're going to
> do that, it might just be simpler to turn DANE support off in the client
> altogether, since you aren't actually using it. Though perhaps with
> laptops where the proxy isn't always in the way, it could be useful.
> Anyway, this exception would be a violation of the protocol unless we
> codified it (as the draft is currently written).

To be precise, it was one option.

The other was to decide that this is not going to be supported.

It really depends on the browser providers. If they consider this to be an
essential market requirement then it is going to be supported and I would
prefer for support to be made explicit rather than be something buried in
the small print. If they don't consider it to be a market requirement it is
merely something to note in the security considerations.

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

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

<br><br><div class=3D"gmail_quote">On Sat, Feb 19, 2011 at 1:42 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;">
<br>
Or Phillip&#39;s idea, that the client plays along and makes an exception t=
o<br>
the DANE processing rules for the proxy. Of course, if you&#39;re going to<=
br>
do that, it might just be simpler to turn DANE support off in the client<br=
>
altogether, since you aren&#39;t actually using it. Though perhaps with<br>
laptops where the proxy isn&#39;t always in the way, it could be useful.<br=
>
Anyway, this exception would be a violation of the protocol unless we<br>
codified it (as the draft is currently written).</blockquote><div><br></div=
><div>To be precise, it was one option.</div><div><br></div><div>The other =
was to decide that this is not going to be supported.</div><div><br></div>
<div><br></div><div>It really depends on the browser providers. If they con=
sider this to be an essential market requirement then it is going to be sup=
ported and I would prefer for support to be made explicit rather than be so=
mething buried in the small print. If they don&#39;t consider it to be a ma=
rket requirement it is merely something to note in the security considerati=
ons.</div>
<div>=A0</div></div><br>-- <br>Website: <a href=3D"http://hallambaker.com/"=
>http://hallambaker.com/</a><br><br>

--20cf303349393c8f8a049cac440a--

Date: Sat, 19 Feb 2011 15:51:35 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] The SSL Proxy Issue

On 2/19/11 1:42 PM, Scott Schmit wrote:
> TLSA very much affects that -- reread section 3 of the DANE protocol
> draft. A straightforward implementation of DANE will result in the
> client looking up example.com, getting back a TLSA record saying that
> the it should be expecting a particular cert, which is then checked
> against the cert it gets back when connecting via TLS.
>
> Except that with the proxy in the way, the client will receive the
> proxy-manufactured cert. Since the two don't match, the connection
> fails. It doesn't matter if the proxy is a TA in the client, because
> DANE overrides that.

Thank you, that explains what I was missing. I was assuming that someone 
behind a proxy would be configured not to issue DANE requests for the 
very reason you give, but now I see that this is possibly not under the 
control of the admin who shoves in the universal trust anchor that is 
used by the proxy.

> In the general case, this is by design and desirable. In the specific
> case of managed environments, there are ways around it:
>
> The SSL proxy (or another supporting device) could also proxy DNS by
> stripping out all DNSSEC from responses (and configuring the hosts to
> disable DNSSEC). One hopes that the proxy has DNSSEC enabled and uses it
> (and that the internal network/proxy is secure). This disables DANE on
> the internal network (though the proxy could use DANE when talking
> externally).
>
> The SSL proxy could also proxy DNSSEC by re-signing all responses with a
> single DNSKEY (and configuring the hosts to use the proxy's key as the
> root TA).

Exactly right. Both have the same (ugly) properties of the current proxy.

> Or Phillip's idea, that the client plays along and makes an exception to
> the DANE processing rules for the proxy. Of course, if you're going to
> do that, it might just be simpler to turn DANE support off in the client
> altogether, since you aren't actually using it. Though perhaps with
> laptops where the proxy isn't always in the way, it could be useful.
> Anyway, this exception would be a violation of the protocol unless we
> codified it (as the draft is currently written).

And I will now agree with the others who have said that we don't want to 
put in exceptions like this. It's similar to putting exceptions in PKIX 
that say "or you just might shove in your own TA": there is no good 
reason to say that.

Date: Sat, 19 Feb 2011 16:42:26 -0500
From: Scott Schmit <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [keyassure] The SSL Proxy Issue

On Sat, Feb 19, 2011 at 12:36:56PM -0800, Paul Hoffman wrote keyassure:
> On 2/19/11 10:49 AM, Steingruebl, Andy wrote:
> >>-----Original Message-----
> >>From: [email-masked] [mailto:[email-masked]] On
> >>Behalf Of Paul Hoffman
> >>
> >>Regardless of the number of use cases, why is it an issue for TLSA?
> >>Given that they are meant to be invisible to the users, isn't that invisibility the
> >>same with or without TLSA?
> >
> >In the current CA/Browser (other code also) model there is not exclusion for trust-anchors.  Any trust anchor can make claims for any name.  With the advent of DANE/TLSA records, the situation changes.  Please see the other mail I just sent...
> 
> I'm not understanding you. TLSA is not looking to replace the
> current trust anchors by removing them from the browser unless the
> user (or, in the case in question, the user's administrator) wants
> to remove them. With an SSL proxy, the user has a universal trust
> anchor added to their browser, and TLSA doesn't affect that at all,
> if I understand the issue you are raising.

TLSA very much affects that -- reread section 3 of the DANE protocol
draft. A straightforward implementation of DANE will result in the
client looking up example.com, getting back a TLSA record saying that
the it should be expecting a particular cert, which is then checked
against the cert it gets back when connecting via TLS.

Except that with the proxy in the way, the client will receive the
proxy-manufactured cert. Since the two don't match, the connection
fails. It doesn't matter if the proxy is a TA in the client, because
DANE overrides that.

In the general case, this is by design and desirable. In the specific
case of managed environments, there are ways around it:

The SSL proxy (or another supporting device) could also proxy DNS by
stripping out all DNSSEC from responses (and configuring the hosts to
disable DNSSEC). One hopes that the proxy has DNSSEC enabled and uses it
(and that the internal network/proxy is secure). This disables DANE on
the internal network (though the proxy could use DANE when talking
externally).

The SSL proxy could also proxy DNSSEC by re-signing all responses with a
single DNSKEY (and configuring the hosts to use the proxy's key as the
root TA).

Or Phillip's idea, that the client plays along and makes an exception to
the DANE processing rules for the proxy. Of course, if you're going to
do that, it might just be simpler to turn DANE support off in the client
altogether, since you aren't actually using it. Though perhaps with
laptops where the proxy isn't always in the way, it could be useful.
Anyway, this exception would be a violation of the protocol unless we
codified it (as the draft is currently written).

From: Henry Story <[email-masked]>
Date: Sat, 19 Feb 2011 22:39:26 +0100
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] publishing the public key

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

On 19 Feb 2011, at 21:34, Phillip Hallam-Baker wrote:

> I agree with Peter here.
>=20
> Folk who are bike-shedding this one need to understand that he is the =
person they need to persuade to write the code.
>=20
> At RSA he demonstrated a large number of issues with PKI that largely =
come from it giving more options than people care to know what to do =
with. DNSSEC is already more complex than X.509 was at a similar stage =
of deployment.

Well that is why the idea of using a subset of X509 could hit a sweet =
spot. It requires no new tools, but could also reduce
the complexity even further. The publication of a subset of X509 would =
be simpler than X509 to implement, and so reduce the
problems with it.

> What appears to be a simpler mechanism to implement is only going to =
save time and effort if it REPLACES the existing mechanism completely =
and ELIMINATES the need to code for it.
>=20
>=20
> Comparison to the design choices in FOAF is not very helpful since 1) =
FOAF has something of a traction/deployment problem in itself and 2) use =
in FOAF does not disrupt an existing deployed infrastructure.

There are probably a lot  more foaf files out there now than CA signed =
TLS signed end points now. And I think those are just going to grow.  =
But that was not the point of my bringing foaf into the discussion. It =
was just that naturally a few people we were working with thought of =
using a subset of X509 to solve their problem.=20

>=20
> Predicting the security implications for a design change for a =
security protocol deployed for 16 years is going to be very error prone.

Not if you use a subset of what you are already using. In fact that is =
why I am arguing for it. I don't like complexity. So for me in public =
key cryptography it is the public keys that are key [sic]. The question =
should be:
=20
 - why not serve the minimal information needed
 - what advantage does one get by serving the full X509
 - what (dis)advantage of both
 - why not the public key rather than the signature?
=20
The debate is not a either/or debate here. You already have 4 options in =
section 2.2 of http://tools.ietf.org/html/draft-ietf-dane-protocol-04 If =
it were to be an either/or, it could be between the options of  =
publishing the signature and the option of publishing the public key. It =
seems to me that the public key is a lot more useful.=20

Henry

>=20
>=20
> On Sat, Feb 19, 2011 at 11:46 AM, Peter Gutmann =
<[email-masked]> wrote:
> Henry Story <[email-masked]> writes:
>=20
> >My question is: what do people use now to pass public keys?
>=20
> X.509 key bags.
>=20
> >I know an X509 cert contains the public key, though I don't know if =
it can
> >contain ECC keys.
>=20
> It can contain any kind of key for any algorithm likely to be used =
with TLS.
>=20
> >If it does then there is another simple answer: extract the part of =
that
> >document that contains both the type of the key and the details of =
it, and
> >use that.
>=20
> In that case why not just stick with X.509?  This is bizarre, you have =
a
> universally-agreed-on, universally-supported format, and you're =
proposing to
> extract a subset of that requiring custom coding in each =
implementation to
> support and use that?
>=20
> Another reason to stick with X.509 as key bags is that eventually =
you're going
> to want to put policy in the DNS ("must connect with TLS", "must use =
EV
> certs", "must use a PFS algorithm like DH/ECDH", "cannot use non-FIPS
> algorithms", and so on).  Guess what X.509v3 key bags were =
specifically
> designed for?
>=20
> The end result is that you'll end up reinventing X.509 as a container =
format,
> only it'll be some homebrew parallel format that needs custom code to =
support
> and endless kludging as things get bolted on that'd be automatically =
supported
> in the X.509 key bag format.  It's reinventing the wheel, but making =
it square
> just to be different.
>=20
> Peter.
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>=20
>=20
>=20
> --=20
> Website: http://hallambaker.com/
>=20

Social Web Architect
http://bblfish.net/

--Apple-Mail-56--130696425
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 19 Feb 2011, at 21:34, Phillip Hallam-Baker =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite">I agree with Peter here.<div><br></div><div>Folk who are =
bike-shedding this one need to understand that he is the person they =
need to persuade to write the code.</div><div><br></div><div>At RSA he =
demonstrated a large number of issues with PKI that largely come from it =
giving more options than people care to know what to do with. DNSSEC is =
already more complex than X.509 was at a similar stage of =
deployment.</div></blockquote><div><br></div><div>Well that is why the =
idea of using a subset of X509 could hit a sweet spot. It requires no =
new tools, but could also reduce</div><div>the complexity even further. =
The publication of a subset of X509 would be simpler than X509 to =
implement, and so reduce the</div><div>problems with =
it.</div><br><blockquote type=3D"cite">
<div>What appears to be a simpler mechanism to implement is only going =
to save time and effort if it REPLACES the existing mechanism completely =
and ELIMINATES the need to code for it.</div><div><br></div><div>
<br></div><div>Comparison to the design choices in FOAF is not very =
helpful since 1) FOAF has something of a traction/deployment problem in =
itself and 2) use in FOAF does not disrupt an existing deployed =
infrastructure.</div></blockquote><div><br></div><div>There are probably =
a lot &nbsp;more foaf files out there now than CA signed TLS signed end =
points now. And I think those are just going to grow. &nbsp;But that was =
not the point of my bringing foaf into the discussion. It was just that =
naturally a few people we were working with thought of using a subset of =
X509 to solve their problem.&nbsp;</div><div><br></div><blockquote =
type=3D"cite">
<div><br></div><div>Predicting the security implications for a design =
change for a security protocol deployed for 16 years is going to be very =
error prone.</div></blockquote><div><br></div><div>Not if you use a =
subset of what you are already using. In fact that is why I am arguing =
for it. I don't like complexity. So for me in public key cryptography it =
is the public keys that are key [sic]. The question should =
be:</div><div>&nbsp;</div><div>&nbsp;- why not serve the minimal =
information needed</div><div>&nbsp;- what advantage does one get by =
serving the full X509</div><div>&nbsp;- what (dis)advantage of =
both</div><div>&nbsp;- why not the public key rather than the =
signature?</div><div>&nbsp;</div><div>The debate is not a either/or =
debate here. You already have 4 options in section 2.2 of&nbsp;<a =
href=3D"http://tools.ietf.org/html/draft-ietf-dane-protocol-04">http://too=
ls.ietf.org/html/draft-ietf-dane-protocol-04</a>&nbsp;If it were to be =
an either/or, it could be between the options of &nbsp;publishing the =
signature and the option of publishing the public key. It seems to me =
that the public key is a lot more =
useful.&nbsp;</div><div><br></div><div>Henry</div><br><blockquote =
type=3D"cite"><div><br></div><div><br><div class=3D"gmail_quote">On Sat, =
Feb 19, 2011 at 11:46 AM, Peter Gutmann <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">Henry=
 Story &lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>&gt; =
writes:<br>
<br>
&gt;My question is: what do people use now to pass public keys?<br>
<br>
</div>X.509 key bags.<br>
<div class=3D"im"><br>
&gt;I know an X509 cert contains the public key, though I don't know if =
it can<br>
&gt;contain ECC keys.<br>
<br>
</div>It can contain any kind of key for any algorithm likely to be used =
with TLS.<br>
<div class=3D"im"><br>
&gt;If it does then there is another simple answer: extract the part of =
that<br>
&gt;document that contains both the type of the key and the details of =
it, and<br>
&gt;use that.<br>
<br>
</div>In that case why not just stick with X.509? &nbsp;This is bizarre, =
you have a<br>
universally-agreed-on, universally-supported format, and you're =
proposing to<br>
extract a subset of that requiring custom coding in each implementation =
to<br>
support and use that?<br>
<br>
Another reason to stick with X.509 as key bags is that eventually you're =
going<br>
to want to put policy in the DNS ("must connect with TLS", "must use =
EV<br>
certs", "must use a PFS algorithm like DH/ECDH", "cannot use =
non-FIPS<br>
algorithms", and so on). &nbsp;Guess what X.509v3 key bags were =
specifically<br>
designed for?<br>
<br>
The end result is that you'll end up reinventing X.509 as a container =
format,<br>
only it'll be some homebrew parallel format that needs custom code to =
support<br>
and endless kludging as things get bolted on that'd be automatically =
supported<br>
in the X.509 key bag format. &nbsp;It's reinventing the wheel, but =
making it square<br>
just to be different.<br>
<div><div></div><div class=3D"h5"><br>
Peter.<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"_blank">https://www.ietf.org/mailman/listinfo/keyassure</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>
</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-56--130696425--

From: Henry Story <[email-masked]>
Date: Sat, 19 Feb 2011 22:25:10 +0100
To: Peter Gutmann <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] publishing the public key

On 19 Feb 2011, at 20:46, Peter Gutmann wrote:

> Henry Story <[email-masked]> writes:
>=20
>> My question is: what do people use now to pass public keys?
>=20
> X.509 key bags

Is that the same as X509? If not is there a specification one can look =
that up on?

>=20
>> I know an X509 cert contains the public key, though I don't know if =
it can
>> contain ECC keys.
>=20
> It can contain any kind of key for any algorithm likely to be used =
with TLS.

great! So we at least no longer have the problem of the encoding.

>=20
>> If it does then there is another simple answer: extract the part of =
that
>> document that contains both the type of the key and the details of =
it, and
>> use that.
>=20
> In that case why not just stick with X.509?  This is bizarre, you have =
a
> universally-agreed-on, universally-supported format, and you're =
proposing to
> extract a subset of that requiring custom coding in each =
implementation to
> support and use that?

If the parsers for X509 are already written, then parsers for a subset
of X509 are already written. It's going to be easy to use the same =
tools.
At least I think one should not dismiss that possibility. The code to =
select
the subset is going to be at most a few lines.

> Another reason to stick with X.509 as key bags is that eventually =
you're going
> to want to put policy in the DNS ("must connect with TLS", "must use =
EV
> certs", "must use a PFS algorithm like DH/ECDH", "cannot use non-FIPS
> algorithms", and so on).  Guess what X.509v3 key bags were =
specifically
> designed for?

That is a reason for the argument to allowing the current options that =
enable the DNS to also send full X509 documents. Btw. I have not really =
looked at policy that much, can you point  me to a human readable =
document I can understand this part of X.509 more? (use cases and such)

> The end result is that you'll end up reinventing X.509 as a container =
format,

Not at all, since we are selecting a piece of it.

It would be as if you had a parser for atom <feed> documents [1] which =
contain <entry> elements. The someone comes along and says that they =
have a use case for documents containing <entry> documents only. The =
problem of parsing those documents is not going to be an issue, neither =
is the semantics of entry, at least for anyone who already has a parser =
for <feed>

> only it'll be some homebrew parallel format that needs custom code to =
support
> and endless kludging as things get bolted on that'd be automatically =
supported
> in the X.509 key bag format.  It's reinventing the wheel, but making =
it square
> just to be different.

There is no re-inventing the wheel here at all.=20

The advantage would bet that you are giving a format where you express =
the key (so to speak) information. So that is why initially I was asking =
what the benefits in terms of packets sent on the wire would be between =
just sending the key in this subset of X509 and sending the full X509. =
For sites like Google this could make an important difference. That is =
something that is measurable, and could let us know if there is an =
advantage at all of considering this.=20

Currently we are not asking to remove the other options. Just to see if =
this option is possible, and to work out what the advantages and =
disadvantages would be.

Henry

[1] http://www.ietf.org/rfc/rfc4287.txt

>=20
> Peter.

Social Web Architect
http://bblfish.net/

Date: Sat, 19 Feb 2011 12:52:20 -0800
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] The SSL Proxy Issue

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

I am starting to think that the only way this 'requirement' can be handled
is if the browsers decide that they are going to explicitly support it and
write code appropriately.

That is, it is acceptable for a browser provider to either:

1) Say that SSL proxies are going to break because it is a clueless idea and
they want them to break, die, die die.

or

2) Say that an SSL proxy is only going to work if a root is added to the
browser that is explicitly marked as being an SSL proxy root and having
proxy capabilities.

Note that in either case the ability to perform covert wiretap is lost.
Merely having a root in the browser is not going to be sufficient to perform
the attack, the root has to be marked as being proxy-authorized.

On Sat, Feb 19, 2011 at 12:36 PM, Paul Hoffman <[email-masked]>wrote:

> On 2/19/11 10:49 AM, Steingruebl, Andy wrote:
>
>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]] On
>>> Behalf Of Paul Hoffman
>>>
>>> Regardless of the number of use cases, why is it an issue for TLSA?
>>> Given that they are meant to be invisible to the users, isn't that
>>> invisibility the
>>> same with or without TLSA?
>>>
>>
>> In the current CA/Browser (other code also) model there is not exclusion
>> for trust-anchors.  Any trust anchor can make claims for any name.  With the
>> advent of DANE/TLSA records, the situation changes.  Please see the other
>> mail I just sent...
>>
>
> I'm not understanding you. TLSA is not looking to replace the current trust
> anchors by removing them from the browser unless the user (or, in the case
> in question, the user's administrator) wants to remove them. With an SSL
> proxy, the user has a universal trust anchor added to their browser, and
> TLSA doesn't affect that at all, if I understand the issue you are raising.
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

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

I am starting to think that the only way this &#39;requirement&#39; can be =
handled is if the browsers decide that they are going to explicitly support=
 it and write code appropriately.<div><br></div><div>That is, it is accepta=
ble for a browser provider to either:</div>
<div><br></div><div>1) Say that SSL proxies are going to break because it i=
s a clueless idea and they want them to break, die, die die.</div><div><br>=
</div><div>or</div><div><br></div><div>2) Say that an SSL proxy is only goi=
ng to work if a root is added to the browser that is explicitly marked as b=
eing an SSL proxy root and having proxy capabilities.</div>
<div><br></div><div><br></div><div>Note that in either case the ability to =
perform covert wiretap is lost. Merely having a root in the browser is not =
going to be sufficient to perform the attack, the root has to be marked as =
being proxy-authorized.</div>
<div><br></div><div><br><br><div class=3D"gmail_quote">On Sat, Feb 19, 2011=
 at 12:36 PM, Paul Hoffman <span dir=3D"ltr">&lt;<a href=3D"mailto:paul.hof=
[email-masked]">[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;">
<div class=3D"im">On 2/19/11 10:49 AM, Steingruebl, Andy wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-----Original Message-----<br>
From: <a href=3D"mailto:[email-masked]" target=3D"_blank">keyas=
[email-masked]</a> [mailto:<a href=3D"mailto:keyassure-bounces@ietf.=
org" target=3D"_blank">[email-masked]</a>] On<br>
Behalf Of Paul Hoffman<br>
<br>
Regardless of the number of use cases, why is it an issue for TLSA?<br>
Given that they are meant to be invisible to the users, isn&#39;t that invi=
sibility the<br>
same with or without TLSA?<br>
</blockquote>
<br>
In the current CA/Browser (other code also) model there is not exclusion fo=
r trust-anchors. =A0Any trust anchor can make claims for any name. =A0With =
the advent of DANE/TLSA records, the situation changes. =A0Please see the o=
ther mail I just sent...<br>

</blockquote>
<br></div>
I&#39;m not understanding you. TLSA is not looking to replace the current t=
rust anchors by removing them from the browser unless the user (or, in the =
case in question, the user&#39;s administrator) wants to remove them. With =
an SSL proxy, the user has a universal trust anchor added to their browser,=
 and TLSA doesn&#39;t affect that at all, if I understand the issue you are=
 raising.<div>
<div></div><div class=3D"h5"><br>
_______________________________________________<br>
keyassure 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/keyassure" target=3D"_blan=
k">https://www.ietf.org/mailman/listinfo/keyassure</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>

--20cf30334939875731049ca8ceaf--

Date: Sat, 19 Feb 2011 12:36:56 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] The SSL Proxy Issue

On 2/19/11 10:49 AM, Steingruebl, Andy wrote:
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Paul Hoffman
>>
>> Regardless of the number of use cases, why is it an issue for TLSA?
>> Given that they are meant to be invisible to the users, isn't that invisibility the
>> same with or without TLSA?
>
> In the current CA/Browser (other code also) model there is not exclusion for trust-anchors.  Any trust anchor can make claims for any name.  With the advent of DANE/TLSA records, the situation changes.  Please see the other mail I just sent...

I'm not understanding you. TLSA is not looking to replace the current 
trust anchors by removing them from the browser unless the user (or, in 
the case in question, the user's administrator) wants to remove them. 
With an SSL proxy, the user has a universal trust anchor added to their 
browser, and TLSA doesn't affect that at all, if I understand the issue 
you are raising.

Date: Sat, 19 Feb 2011 12:34:15 -0800
From: Phillip Hallam-Baker <[email-masked]>
To: Peter Gutmann <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] publishing the public key

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

I agree with Peter here.

Folk who are bike-shedding this one need to understand that he is the person
they need to persuade to write the code.

At RSA he demonstrated a large number of issues with PKI that largely come
from it giving more options than people care to know what to do with. DNSSEC
is already more complex than X.509 was at a similar stage of deployment.

What appears to be a simpler mechanism to implement is only going to save
time and effort if it REPLACES the existing mechanism completely and
ELIMINATES the need to code for it.

Comparison to the design choices in FOAF is not very helpful since 1) FOAF
has something of a traction/deployment problem in itself and 2) use in FOAF
does not disrupt an existing deployed infrastructure.

Predicting the security implications for a design change for a security
protocol deployed for 16 years is going to be very error prone.

On Sat, Feb 19, 2011 at 11:46 AM, Peter Gutmann
<[email-masked]>wrote:

> Henry Story <[email-masked]> writes:
>
> >My question is: what do people use now to pass public keys?
>
> X.509 key bags.
>
> >I know an X509 cert contains the public key, though I don't know if it can
> >contain ECC keys.
>
> It can contain any kind of key for any algorithm likely to be used with
> TLS.
>
> >If it does then there is another simple answer: extract the part of that
> >document that contains both the type of the key and the details of it, and
> >use that.
>
> In that case why not just stick with X.509?  This is bizarre, you have a
> universally-agreed-on, universally-supported format, and you're proposing
> to
> extract a subset of that requiring custom coding in each implementation to
> support and use that?
>
> Another reason to stick with X.509 as key bags is that eventually you're
> going
> to want to put policy in the DNS ("must connect with TLS", "must use EV
> certs", "must use a PFS algorithm like DH/ECDH", "cannot use non-FIPS
> algorithms", and so on).  Guess what X.509v3 key bags were specifically
> designed for?
>
> The end result is that you'll end up reinventing X.509 as a container
> format,
> only it'll be some homebrew parallel format that needs custom code to
> support
> and endless kludging as things get bolted on that'd be automatically
> supported
> in the X.509 key bag format.  It's reinventing the wheel, but making it
> square
> just to be different.
>
> Peter.
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

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

I agree with Peter here.<div><br></div><div>Folk who are bike-shedding this=
 one need to understand that he is the person they need to persuade to writ=
e the code.</div><div><br></div><div><br></div><div>At RSA he demonstrated =
a large number of issues with PKI that largely come from it giving more opt=
ions than people care to know what to do with. DNSSEC is already more compl=
ex than X.509 was at a similar stage of deployment.</div>
<div><br></div><div>What appears to be a simpler mechanism to implement is =
only going to save time and effort if it REPLACES the existing mechanism co=
mpletely and ELIMINATES the need to code for it.</div><div><br></div><div>
<br></div><div>Comparison to the design choices in FOAF is not very helpful=
 since 1) FOAF has something of a traction/deployment problem in itself and=
 2) use in FOAF does not disrupt an existing deployed infrastructure.</div>
<div><br></div><div>Predicting the security implications for a design chang=
e for a security protocol deployed for 16 years is going to be very error p=
rone.</div><div><br></div><div><br><div class=3D"gmail_quote">On Sat, Feb 1=
9, 2011 at 11:46 AM, Peter Gutmann <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">Henry Story &lt;<a href=
=3D"mailto:[email-masked]">[email-masked]</a>&gt; writes:=
<br>
<br>
&gt;My question is: what do people use now to pass public keys?<br>
<br>
</div>X.509 key bags.<br>
<div class=3D"im"><br>
&gt;I know an X509 cert contains the public key, though I don&#39;t know if=
 it can<br>
&gt;contain ECC keys.<br>
<br>
</div>It can contain any kind of key for any algorithm likely to be used wi=
th TLS.<br>
<div class=3D"im"><br>
&gt;If it does then there is another simple answer: extract the part of tha=
t<br>
&gt;document that contains both the type of the key and the details of it, =
and<br>
&gt;use that.<br>
<br>
</div>In that case why not just stick with X.509? =A0This is bizarre, you h=
ave a<br>
universally-agreed-on, universally-supported format, and you&#39;re proposi=
ng to<br>
extract a subset of that requiring custom coding in each implementation to<=
br>
support and use that?<br>
<br>
Another reason to stick with X.509 as key bags is that eventually you&#39;r=
e going<br>
to want to put policy in the DNS (&quot;must connect with TLS&quot;, &quot;=
must use EV<br>
certs&quot;, &quot;must use a PFS algorithm like DH/ECDH&quot;, &quot;canno=
t use non-FIPS<br>
algorithms&quot;, and so on). =A0Guess what X.509v3 key bags were specifica=
lly<br>
designed for?<br>
<br>
The end result is that you&#39;ll end up reinventing X.509 as a container f=
ormat,<br>
only it&#39;ll be some homebrew parallel format that needs custom code to s=
upport<br>
and endless kludging as things get bolted on that&#39;d be automatically su=
pported<br>
in the X.509 key bag format. =A0It&#39;s reinventing the wheel, but making =
it square<br>
just to be different.<br>
<div><div></div><div class=3D"h5"><br>
Peter.<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>
</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>

--0016e68f67d8dd363e049ca88d2e--

From: Peter Gutmann <[email-masked]>
To: [email-masked], [email-masked]
Date: Sun, 20 Feb 2011 08:46:08 +1300
Subject: Re: [keyassure] publishing the public key

Henry Story <[email-masked]> writes:

>My question is: what do people use now to pass public keys?

X.509 key bags.

>I know an X509 cert contains the public key, though I don't know if it can
>contain ECC keys.

It can contain any kind of key for any algorithm likely to be used with TLS.

>If it does then there is another simple answer: extract the part of that
>document that contains both the type of the key and the details of it, and
>use that.

In that case why not just stick with X.509?  This is bizarre, you have a
universally-agreed-on, universally-supported format, and you're proposing to
extract a subset of that requiring custom coding in each implementation to
support and use that?

Another reason to stick with X.509 as key bags is that eventually you're going
to want to put policy in the DNS ("must connect with TLS", "must use EV
certs", "must use a PFS algorithm like DH/ECDH", "cannot use non-FIPS
algorithms", and so on).  Guess what X.509v3 key bags were specifically
designed for?

The end result is that you'll end up reinventing X.509 as a container format,
only it'll be some homebrew parallel format that needs custom code to support
and endless kludging as things get bolted on that'd be automatically supported
in the X.509 key bag format.  It's reinventing the wheel, but making it square
just to be different.

Peter.

From: Yoav Nir <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 19 Feb 2011 21:06:14 +0200
Accept-Language: en-US
acceptlanguage: en-US
Cc: Adam Langley <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] The SSL Proxy Issue

On Feb 19, 2011, at 8:16 PM, Phillip Hallam-Baker wrote:

> OK and I assume that this means that this would certainly not be EV compa=
tible (unless the signer is breaching the EV requirements)
>=20
> There are two use cases that I can see would drive this:
>=20
> 1) Enterprises that are required to track internal communications.=20

What do you mean by "are required to"?  Lots of times this comes from eithe=
r a "security officer" or an auditor who says, "there's this tool in the to=
olbox. Why aren't you using it?"
The legitimate use can be that the company has some application firewall th=
at blocks HTTP based attacks. Without an SSL proxy, you can't block the att=
acks if they're over HTTPS.

>=20
> 2) Governments looking to perform covert surveillance.
>=20
>=20
> I only recognize one of these use cases as legitimate. The other is reall=
y an anti-use case (attack).

I agree. An attack is an attack, even if the attacker works for the good gu=
ys. Even if the attacker is doing it for my own good.

> The only difference I can see in these use cases is the 'covert' part. I =
think it is OK to have a hole, provided the users know that there is a hole=
.

Well, it's the employer's computer and the employer's SSL proxy. The trust =
anchor store is controlled by the employer through the operating system's r=
emote management tools. The employee need never know, so I'm not sure if th=
is doesn't fall under 'covert' as well.

From: "Steingruebl, Andy" <[email-masked]>
To: Paul Hoffman <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Sat, 19 Feb 2011 11:49:25 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [keyassure] The SSL Proxy Issue

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Paul Hoffman
>=20
> Regardless of the number of use cases, why is it an issue for TLSA?
> Given that they are meant to be invisible to the users, isn't that invisi=
bility the
> same with or without TLSA?

In the current CA/Browser (other code also) model there is not exclusion fo=
r trust-anchors.  Any trust anchor can make claims for any name.  With the =
advent of DANE/TLSA records, the situation changes.  Please see the other m=
ail I just sent...

- Andy

From: "Steingruebl, Andy" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Sat, 19 Feb 2011 11:48:01 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [keyassure] The SSL Proxy Issue

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Steingruebl, Andy
>=20
> I'm personally in favor of a combination of #2/#3 as a long-term fix beca=
use if
> we don't specify a way to do this use case, people are going to bastardiz=
e the
> existing protocols in insecure ways that make a mess of things, just like=
 has
> happened with the existing transparent proxy architectures in existence i=
n
> many places.  We can't easily get people to get rid of those without prov=
iding
> them a solution, and absent a well-defined solution we're going to get
> overloading of other functionality that will be ugly and insecure.

Apologies for replying to my own post, but I fear my previous note could ha=
ve been read as me advocating or at least not disapproving on inspecting ga=
teways, etc.  Far from it.  I'd like these types of network inspections mad=
e explicit and accounted for in our security models, and users to opt-in if=
 necessary.  There are going to be networks that want to do admission contr=
ol though for a diversity of clients, and their temptation will be to abuse=
/augment existing protocols rather than inventing something new and/or usin=
g a complicated protocol instead of a simpler one that gets them what they =
want, consequences be damned.  We should press back firmly on that, and I t=
hink we need to do so proactively rather than just reactively.

- Andy

Date: Sat, 19 Feb 2011 10:46:16 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] The SSL Proxy Issue

On 2/19/11 10:16 AM, Phillip Hallam-Baker wrote:
> There are two use cases that I can see would drive this:
>
> 1) Enterprises that are required to track internal communications.
>
> 2) Governments looking to perform covert surveillance.

There are actually many more. SSL proxies have become hammers that 
enterprises look at as universal tools.

Regardless of the number of use cases, why is it an issue for TLSA? 
Given that they are meant to be invisible to the users, isn't that 
invisibility the same with or without TLSA?

Date: Sat, 19 Feb 2011 10:41:50 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] publishing the public key

On 2/19/11 9:09 AM, Phillip Hallam-Baker wrote:
> The problem with this approach is that it means that we are going to at
> best be exercising new code paths in existing code. At worst we are
> going to force people to write new code.

Fully agree on both. I have yet to see what I asked for early on, which 
is any text that explains how a TLS client who gets a bare key would use 
it in TLS.

If there is later a standards-track extension to TLS that handles bare 
public keys, that format can be added to TLSA at that time. It would use 
the exact same format so that clients can do exact matching without 
having to process either the key data from TLSA/DNS or the key data from 
the TLS handshake.

I'm still open to hearing *why* adding bare keys would help TLSA, but I 
would also want to see text about how the processing would go so that I 
could weigh the benefit against the cost.

From: "Steingruebl, Andy" <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>, "[email-masked]" <[email-masked]>, Dan Kaminsky <[email-masked]>
Date: Sat, 19 Feb 2011 11:19:39 -0700
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [keyassure] The SSL Proxy Issue

> From: [email-masked] [mailto:[email-masked]] On B=
ehalf Of Phillip Hallam-Baker

>Could someone explain exactly how SSL MITM proxies are=A0

> 1) Being supported in existing browsers?

To the best of my knowledge based on any/all documents I've ever seen, they=
 simply require an enterprise to install a new root-CA to each client machi=
ne, and then they create new certs on the fly for each site a browser tries=
 to connect.  Roughly the same technique that local web security testing to=
ols such as Fiddler, Burp, etc. do it as well.

> 2) Should be supported in DANE?

Because the existing model (Multiple CAs all equally trusted) doesn't have =
exclusion, the existing MITM SSL/TLS architecture can work.  Now that one o=
f the main features on DANE is a single trust root, I see only a few option=
s to making this interception architecture still work, and they are all ugl=
y.

A few ideas on what we should do about it:
=20
1. We should actually specify this use case somewhere, if not in the spec t=
hen in a guidelines document.
2. We should explicitly make it hard to do as we don't think this type of n=
etwork inspection is legitimate.
3. We should work on creating a new technology somewhere lower in the stack=
 that tells clients the rules/properties for a network.  This problem is al=
ready raising its ugly head because of HSTS in the presence of middlebox ar=
chitectures such as those at hotels, coffee shops, etc.

I'm personally in favor of a combination of #2/#3 as a long-term fix becaus=
e if we don't specify a way to do this use case, people are going to bastar=
dize the existing protocols in insecure ways that make a mess of things, ju=
st like has happened with the existing transparent proxy architectures in e=
xistence in many places.  We can't easily get people to get rid of those wi=
thout providing them a solution, and absent a well-defined solution we're g=
oing to get overloading of other functionality that will be ugly and insecu=
re.

- Andy

Date: Sat, 19 Feb 2011 10:16:45 -0800
From: Phillip Hallam-Baker <[email-masked]>
To: Adam Langley <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] The SSL Proxy Issue

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

OK and I assume that this means that this would certainly not be EV
compatible (unless the signer is breaching the EV requirements)

There are two use cases that I can see would drive this:

1) Enterprises that are required to track internal communications.

2) Governments looking to perform covert surveillance.

I only recognize one of these use cases as legitimate. The other is really
an anti-use case (attack).

The only difference I can see in these use cases is the 'covert' part. I
think it is OK to have a hole, provided the users know that there is a hole.
I don't want NSA employees having private conversations from NSA machines
that can't be tracked by the NSA.

On Sat, Feb 19, 2011 at 9:57 AM, Adam Langley <[email-masked]>wrote:

> On Sat, Feb 19, 2011 at 12:14 PM, Phillip Hallam-Baker <[email-masked]>
> wrote:
> > Could someone explain exactly how SSL MITM proxies are
> > 1) Being supported in existing browsers?
>
> There is no explicit support. The proxy's signing certificate is
> configured as a root on the client and the browser sees every site
> signed by that root.
>
>
> AGL
>
> --
> Adam Langley [email-masked] http://www.imperialviolet.org
>

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

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

<div>OK and I assume that this means that this would certainly not be EV co=
mpatible (unless the signer is breaching the EV requirements)</div><div><br=
></div>There are two use cases that I can see would drive this:<div><br>
</div><div>1) Enterprises that are required to track internal communication=
s.=A0</div><div><br></div><div>2) Governments looking to perform covert sur=
veillance.</div><div><br></div><div><br></div><div>I only recognize one of =
these use cases as legitimate. The other is really an anti-use case (attack=
).</div>
<div><br></div><div>The only difference I can see in these use cases is the=
 &#39;covert&#39; part. I think it is OK to have a hole, provided the users=
 know that there is a hole. I don&#39;t want NSA employees having private c=
onversations from NSA machines that can&#39;t be tracked by the NSA.</div>
<div><br></div><div><br><br><div class=3D"gmail_quote">On Sat, Feb 19, 2011=
 at 9:57 AM, Adam Langley <span dir=3D"ltr">&lt;<a href=3D"mailto:agl@imper=
ialviolet.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=
;padding-left:1ex;">
<div class=3D"im">On Sat, Feb 19, 2011 at 12:14 PM, Phillip Hallam-Baker &l=
t;<a href=3D"mailto:[email-masked]">[email-masked]</a>&gt; wrote:<br>
&gt; Could someone explain exactly how SSL MITM proxies are<br>
&gt; 1) Being supported in existing browsers?<br>
<br>
</div>There is no explicit support. The proxy&#39;s signing certificate is<=
br>
configured as a root on the client and the browser sees every site<br>
signed by that root.<br>
<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>
</font></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a href=
=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--20cf30549b53207cec049ca6a215--

Sender: [email-masked]
Date: Sat, 19 Feb 2011 12:57:53 -0500
From: Adam Langley <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked], Dan Kaminsky <[email-masked]>
Subject: Re: [keyassure] The SSL Proxy Issue

On Sat, Feb 19, 2011 at 12:14 PM, Phillip Hallam-Baker <[email-masked]> wrote:
> Could someone explain exactly how SSL MITM proxies are
> 1) Being supported in existing browsers?

There is no explicit support. The proxy's signing certificate is
configured as a root on the client and the browser sees every site
signed by that root.

AGL

-- 
Adam Langley [email-masked] http://www.imperialviolet.org

From: Henry Story <[email-masked]>
Date: Sat, 19 Feb 2011 18:32:15 +0100
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] publishing the public key

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

On 19 Feb 2011, at 18:09, Phillip Hallam-Baker wrote:

> The problem with this approach is that it means that we are going to =
at best be exercising new code paths in existing code. At worst we are =
going to force people to write new code.
>=20
>=20
> It is impossible to run TLS without X.509 code in the stack. =
Everything else is superfluous.
>=20
> This is really bikeshedding. It is not going to simplify =
implementation by an iota and it is going to create yet another special =
case to support.=20
>=20
> I don't think the crypto community wants to support yet another key =
format. Even if that format is 'merely' a subset of an existing format.

 I don't think that is a problem. On the foaf-protocols list we were =
discussing not so long ago using the public key element of X.509 only. =
in DER format.  So that instead of writing

:me cert:publicKey [ rsa:modulus "..."; rsa:exponent "..." ]

people could write

:me cert:publicKey "SDFSDFJSRUSFZJLSDF"^^cert:derEncoded .

People using python, perl, javascript found no problem with the parsing =
of this. The javascript people even went so
far as to write a javascript ASN.1 parsing library.

https://github.com/digitalbazaar/forge/blob/master/js/asn1.js

I am kind of against that more because it is silly to embed an ASN.1 DER =
syntax inside an XML syntax. It just creates
twice the work and no real benefit (only the illusory benefit that you =
have 1 string, whereas in fact you then have to
parse it with some other parse to get the two numbers out of it)=20
But I think that since you believe it has to be X509, then ASN.1 should =
be the road for you. And I think that people working
at the DNS level should have no trouble working with those tools, =
especially the consumers such as browser vendors.

Henry

>=20
> On Sat, Feb 19, 2011 at 1:51 AM, Henry Story <[email-masked]> =
wrote:
> I had received your mails Peter.  Your mail is also available in the =
archives.
>=20
>   http://www.ietf.org/mail-archive/web/keyassure/current/msg01846.html
>=20
> Ilari Liusvaara came up with a format for raw keys in what seems to be =
C
>=20
>   http://www.ietf.org/mail-archive/web/keyassure/current/msg01803.html
>=20
> (though I am not sure that C is progress over ASN.1 for such a =
specification)
>=20
> My question is: what do people use now to pass public keys? I know an =
X509 cert
> contains the public key, though I don't know if it can contain ECC =
keys.
> If it does then there is another simple answer: extract the part of =
that document
> that contains both the type of the key and the details of it, and use =
that.
>=20
> So in the XML world the xmldsig spec defines the KeyInfo element
> http://www.w3.org/TR/xmldsig-core/#sec-KeyInfo
> which specified the following keys
>=20
>   * http://www.w3.org/2000/09/xmldsig#DSAKeyValue
>   * http://www.w3.org/2000/09/xmldsig#RSAKeyValue
>   * http://www.w3.org/2000/09/xmldsig#X509Data
>   * http://www.w3.org/2000/09/xmldsig#PGPData
>   * http://www.w3.org/2000/09/xmldsig#SPKIData
>   * http://www.w3.org/2000/09/xmldsig#MgmtData
>=20
> So there one could just take the KeyInfo Element, and use that as a =
document format to place the
> keys in. Of course one would remove X509, PGP keys, and one would have =
to define an xml structure for
> elliptic curve keys. I am not recomending this option
>=20
> So essentially there has to be a way of having a structure a bit more =
general than the following
> that can encode all the needed keys and that is extensible
>=20
>=20
>  RSAPublicKey ::=3D SEQUENCE {
>    modulus           INTEGER,  -- n
>    publicExponent    INTEGER   -- e
>  }
>=20
>=20
> So there does not seem to be a lack of solutions. The trick I suppose =
is finding the one that is the most likely to be adopted. I suppose some =
ASN.1 DER encoding is the one most tools are ready for.
>=20
> Henry
>=20
> On 19 Feb 2011, at 02:24, Peter Gutmann wrote:
>=20
> > [Several of my posts didn't make it to the list, these are re-posts =
of earlier
> > messages]
> >
> > Paul Wouters <[email-masked]> writes:
> >> On Tue, 15 Feb 2011, Peter Gutmann wrote:
> >>>> The public key's type and raw blob will be obtained from DNSSEC, =
so this is
> >>>> no longer required to be conveyed to the client from the server =
via a PKIX
> >>>> certificate or other ASN.1 structures.
> >>>
> >>> But what format is the "type and raw blob" in?  You need some way =
of encoding
> >>> it, and if it's not the standard ASN.1 format what are you going =
to use?
> >>
> >> I'm not sure I understand your question.
> >
> > A public key contains a number of components and options. For =
example for ECC
> > there are the basic key values p, a, b, G, n, h (or m, f, a, b, G, =
n, h for
> > binary curves), an indication of the underlying field (prime or =
binary), the
> > point format, whether point compression is used, polynomial vs. =
normal basis,
> > whether fixed domain parameters are used, and probably some other =
stuff I've
> > forgotten.  How is all this stuff communicated?
> >
> >> The key would encoded in DNS, likely in a format similar to DNSKEY.
> >
> > DNSKEY (RFC 3757) just specifies an opaque value labelled "public =
key".  If
> > you mean RFC 4034:
> >
> >  RSA/MD5 [RSAMD5]         n      [RFC2537]  NOT RECOMMENDED
> >  Diffie-Hellman [DH]      n      [RFC2539]   -
> >  DSA/SHA-1 [DSA]          y      [RFC2536]  OPTIONAL
> >  Elliptic Curve [ECC]              TBA       -
> >  RSA/SHA-1 [RSASHA1]      y      [RFC3110]  MANDATORY
> >
> > this (a) ain't gonna cut it because it doesn't cover what's required =
by TLS
> > and (b) requires that your TLS implementation speak DNSSEC (or at =
least the
> > DNSKEY part of DNSSEC) just to get a key. I can't see TLS =
implementors being
> > too enthusiastic about this.
> >
> > Peter.
> > _______________________________________________
> > keyassure mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/keyassure
>=20
> Social Web Architect
> http://bblfish.net/
>=20
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>=20
>=20
>=20
> --=20
> Website: http://hallambaker.com/
>=20

Social Web Architect
http://bblfish.net/

--Apple-Mail-54--145528025
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 19 Feb 2011, at 18:09, Phillip Hallam-Baker =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite">The problem with this approach is that it means that we =
are going to at best be exercising new code paths in existing code. At =
worst we are going to force people to write new =
code.<div><br></div><div><br></div><div>It is impossible to run TLS =
without X.509 code in the stack. Everything else is =
superfluous.</div></blockquote><blockquote =
type=3D"cite"><div><br></div><div>This is really bikeshedding. It is not =
going to simplify implementation by an iota and it is going to create =
yet another special case to support.&nbsp;</div><div><br></div><div>I =
don't think the crypto community wants to support yet another key =
format. Even if that format is 'merely' a subset of an existing =
format.<br></div></blockquote><div><br></div><div><div>&nbsp;I don't =
think that is a problem. On the foaf-protocols list we were discussing =
not so long ago&nbsp;using the public key element of X.509 only. in DER =
format. &nbsp;So that instead of writing</div><div><br></div><div>:me =
cert:publicKey [ rsa:modulus "..."; rsa:exponent "..." =
]</div><div><br></div><div>people could =
write</div><div><br></div><div>:me cert:publicKey =
"SDFSDFJSRUSFZJLSDF"^^cert:derEncoded .</div><div><br></div><div>People =
using python, perl, javascript found no problem with the parsing of =
this. The javascript people even went so</div><div>far as to write a =
javascript ASN.1 parsing library.</div><div><br></div><div><a =
href=3D"https://github.com/digitalbazaar/forge/blob/master/js/asn1.js">htt=
ps://github.com/digitalbazaar/forge/blob/master/js/asn1.js</a></div><div><=
br></div><div>I am kind of against that more because it is silly to =
embed an ASN.1 DER syntax inside an XML syntax. It just =
creates</div><div>twice the work and no real benefit (only the illusory =
benefit that you have 1 string, whereas in fact you then have =
to</div><div>parse it with some other parse to get the two numbers out =
of it)&nbsp;</div><div>But I think that since you believe it has to be =
X509, then ASN.1 should be the road&nbsp;for you. And I think that =
people working</div><div>at the DNS level should have no trouble working =
with those tools, especially the consumers such as browser =
vendors.</div><div><br></div><div>Henry</div><div><br></div><div><br></div=
></div><blockquote type=3D"cite"><div><div><br><div =
class=3D"gmail_quote">On Sat, Feb 19, 2011 at 1:51 AM, 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;">
I had received your mails Peter. &nbsp;Your mail is also available in =
the archives.<br>
<br>
 &nbsp; <a =
href=3D"http://www.ietf.org/mail-archive/web/keyassure/current/msg01846.ht=
ml" =
target=3D"_blank">http://www.ietf.org/mail-archive/web/keyassure/current/m=
sg01846.html</a><br>
<br>
Ilari Liusvaara came up with a format for raw keys in what seems to be =
C<br>
<br>
 &nbsp; <a =
href=3D"http://www.ietf.org/mail-archive/web/keyassure/current/msg01803.ht=
ml" =
target=3D"_blank">http://www.ietf.org/mail-archive/web/keyassure/current/m=
sg01803.html</a><br>
<br>
(though I am not sure that C is progress over ASN.1 for such a =
specification)<br>
<br>
My question is: what do people use now to pass public keys? I know an =
X509 cert<br>
contains the public key, though I don't know if it can contain ECC =
keys.<br>
If it does then there is another simple answer: extract the part of that =
document<br>
that contains both the type of the key and the details of it, and use =
that.<br>
<br>
So in the XML world the xmldsig spec defines the KeyInfo element<br>
<a href=3D"http://www.w3.org/TR/xmldsig-core/#sec-KeyInfo" =
target=3D"_blank">http://www.w3.org/TR/xmldsig-core/#sec-KeyInfo</a><br>
which specified the following keys<br>
<br>
 &nbsp; * <a href=3D"http://www.w3.org/2000/09/xmldsig#DSAKeyValue" =
target=3D"_blank">http://www.w3.org/2000/09/xmldsig#DSAKeyValue</a><br>
 &nbsp; * <a href=3D"http://www.w3.org/2000/09/xmldsig#RSAKeyValue" =
target=3D"_blank">http://www.w3.org/2000/09/xmldsig#RSAKeyValue</a><br>
 &nbsp; * <a href=3D"http://www.w3.org/2000/09/xmldsig#X509Data" =
target=3D"_blank">http://www.w3.org/2000/09/xmldsig#X509Data</a><br>
 &nbsp; * <a href=3D"http://www.w3.org/2000/09/xmldsig#PGPData" =
target=3D"_blank">http://www.w3.org/2000/09/xmldsig#PGPData</a><br>
 &nbsp; * <a href=3D"http://www.w3.org/2000/09/xmldsig#SPKIData" =
target=3D"_blank">http://www.w3.org/2000/09/xmldsig#SPKIData</a><br>
 &nbsp; * <a href=3D"http://www.w3.org/2000/09/xmldsig#MgmtData" =
target=3D"_blank">http://www.w3.org/2000/09/xmldsig#MgmtData</a><br>
<br>
So there one could just take the KeyInfo Element, and use that as a =
document format to place the<br>
keys in. Of course one would remove X509, PGP keys, and one would have =
to define an xml structure for<br>
elliptic curve keys. I am not recomending this option<br>
<br>
So essentially there has to be a way of having a structure a bit more =
general than the following<br>
that can encode all the needed keys and that is extensible<br>
<br>
<br>
 &nbsp;RSAPublicKey ::=3D SEQUENCE {<br>
 &nbsp; &nbsp;modulus &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; INTEGER, =
&nbsp;-- n<br>
 &nbsp; &nbsp;publicExponent &nbsp; &nbsp;INTEGER &nbsp; -- e<br>
 &nbsp;}<br>
<br>
<br>
So there does not seem to be a lack of solutions. The trick I suppose is =
finding the one that is the most likely to be adopted. I suppose some =
ASN.1 DER encoding is the one most tools are ready for.<br>
<font color=3D"#888888"><br>
Henry<br>
</font><div><div></div><div class=3D"h5"><br>
On 19 Feb 2011, at 02:24, Peter Gutmann wrote:<br>
<br>
&gt; [Several of my posts didn't make it to the list, these are re-posts =
of earlier<br>
&gt; messages]<br>
&gt;<br>
&gt; Paul Wouters &lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>&gt; =
writes:<br>
&gt;&gt; On Tue, 15 Feb 2011, Peter Gutmann wrote:<br>
&gt;&gt;&gt;&gt; The public key's type and raw blob will be obtained =
from DNSSEC, so this is<br>
&gt;&gt;&gt;&gt; no longer required to be conveyed to the client from =
the server via a PKIX<br>
&gt;&gt;&gt;&gt; certificate or other ASN.1 structures.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; But what format is the "type and raw blob" in? &nbsp;You =
need some way of encoding<br>
&gt;&gt;&gt; it, and if it's not the standard ASN.1 format what are you =
going to use?<br>
&gt;&gt;<br>
&gt;&gt; I'm not sure I understand your question.<br>
&gt;<br>
&gt; A public key contains a number of components and options. For =
example for ECC<br>
&gt; there are the basic key values p, a, b, G, n, h (or m, f, a, b, G, =
n, h for<br>
&gt; binary curves), an indication of the underlying field (prime or =
binary), the<br>
&gt; point format, whether point compression is used, polynomial vs. =
normal basis,<br>
&gt; whether fixed domain parameters are used, and probably some other =
stuff I've<br>
&gt; forgotten. &nbsp;How is all this stuff communicated?<br>
&gt;<br>
&gt;&gt; The key would encoded in DNS, likely in a format similar to =
DNSKEY.<br>
&gt;<br>
&gt; DNSKEY (RFC 3757) just specifies an opaque value labelled "public =
key". &nbsp;If<br>
&gt; you mean RFC 4034:<br>
&gt;<br>
&gt; &nbsp;RSA/MD5 [RSAMD5] &nbsp; &nbsp; &nbsp; &nbsp; n &nbsp; &nbsp; =
&nbsp;[RFC2537] &nbsp;NOT RECOMMENDED<br>
&gt; &nbsp;Diffie-Hellman [DH] &nbsp; &nbsp; &nbsp;n &nbsp; &nbsp; =
&nbsp;[RFC2539] &nbsp; -<br>
&gt; &nbsp;DSA/SHA-1 [DSA] &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;y &nbsp; =
&nbsp; &nbsp;[RFC2536] &nbsp;OPTIONAL<br>
&gt; &nbsp;Elliptic Curve [ECC] &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
&nbsp; &nbsp;TBA &nbsp; &nbsp; &nbsp; -<br>
&gt; &nbsp;RSA/SHA-1 [RSASHA1] &nbsp; &nbsp; &nbsp;y &nbsp; &nbsp; =
&nbsp;[RFC3110] &nbsp;MANDATORY<br>
&gt;<br>
&gt; this (a) ain't gonna cut it because it doesn't cover what's =
required by TLS<br>
&gt; and (b) requires that your TLS implementation speak DNSSEC (or at =
least the<br>
&gt; DNSKEY part of DNSSEC) just to get a key. I can't see TLS =
implementors being<br>
&gt; too enthusiastic about this.<br>
&gt;<br>
&gt; Peter.<br>
&gt; _______________________________________________<br>
&gt; keyassure mailing list<br>
&gt; <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/keyassure" =
target=3D"_blank">https://www.ietf.org/mailman/listinfo/keyassure</a><br>
<br>
</div></div><div class=3D"im">Social Web Architect<br>
<a href=3D"http://bblfish.net/" =
target=3D"_blank">http://bblfish.net/</a><br>
<br>
_______________________________________________<br>
</div><div><div></div><div class=3D"h5">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"_blank">https://www.ietf.org/mailman/listinfo/keyassure</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>
</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-54--145528025--

Date: Sat, 19 Feb 2011 09:14:38 -0800
From: Phillip Hallam-Baker <[email-masked]>
To: [email-masked], Dan Kaminsky <[email-masked]>
Subject: [keyassure] The SSL Proxy Issue

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

Could someone explain exactly how SSL MITM proxies are

1) Being supported in existing browsers?
2) Should be supported in DANE?

Note that I am not interested in answers of the form 'read XYZ spec' unless
it is coming from someone who knows the code matches that spec. I know that
there are descriptions of what the behavior should be, but what I want to
know is what the behavior is.

I really worry that there is another Kaminsky type bug in there. The reason
that bug existed for so long was that the protocol was known to be defective
and there was little interest in determining exactly how defective.

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

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

Could someone explain exactly how SSL MITM proxies are=A0<div><br></div><di=
v>1) Being supported in existing browsers?<div>2) Should be supported in DA=
NE?</div><div><br></div><div>Note that I am not interested in answers of th=
e form &#39;read XYZ spec&#39; unless it is coming from someone who knows t=
he code matches that spec. I know that there are descriptions of what the b=
ehavior should be, but what I want to know is what the behavior is.</div>
<div><br></div><div>I really worry that there is another Kaminsky type bug =
in there. The reason that bug existed for so long was that the protocol was=
 known to be defective and there was little interest in determining exactly=
 how defective.</div>
<div><br></div><div><br>-- <br>Website: <a href=3D"http://hallambaker.com/"=
>http://hallambaker.com/</a><br><br>
</div></div>

--20cf30549b5303690f049ca5c462--

Date: Sat, 19 Feb 2011 09:09:31 -0800
From: Phillip Hallam-Baker <[email-masked]>
To: Henry Story <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] publishing the public key

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

The problem with this approach is that it means that we are going to at best
be exercising new code paths in existing code. At worst we are going to
force people to write new code.

It is impossible to run TLS without X.509 code in the stack. Everything else
is superfluous.

This is really bikeshedding. It is not going to simplify implementation by
an iota and it is going to create yet another special case to support.

I don't think the crypto community wants to support yet another key format.
Even if that format is 'merely' a subset of an existing format.

On Sat, Feb 19, 2011 at 1:51 AM, Henry Story <[email-masked]>wrote:

> I had received your mails Peter.  Your mail is also available in the
> archives.
>
>   http://www.ietf.org/mail-archive/web/keyassure/current/msg01846.html
>
> Ilari Liusvaara came up with a format for raw keys in what seems to be C
>
>   http://www.ietf.org/mail-archive/web/keyassure/current/msg01803.html
>
> (though I am not sure that C is progress over ASN.1 for such a
> specification)
>
> My question is: what do people use now to pass public keys? I know an X509
> cert
> contains the public key, though I don't know if it can contain ECC keys.
> If it does then there is another simple answer: extract the part of that
> document
> that contains both the type of the key and the details of it, and use that.
>
> So in the XML world the xmldsig spec defines the KeyInfo element
> http://www.w3.org/TR/xmldsig-core/#sec-KeyInfo
> which specified the following keys
>
>   * http://www.w3.org/2000/09/xmldsig#DSAKeyValue
>   * http://www.w3.org/2000/09/xmldsig#RSAKeyValue
>   * http://www.w3.org/2000/09/xmldsig#X509Data
>   * http://www.w3.org/2000/09/xmldsig#PGPData
>   * http://www.w3.org/2000/09/xmldsig#SPKIData
>   * http://www.w3.org/2000/09/xmldsig#MgmtData
>
> So there one could just take the KeyInfo Element, and use that as a
> document format to place the
> keys in. Of course one would remove X509, PGP keys, and one would have to
> define an xml structure for
> elliptic curve keys. I am not recomending this option
>
> So essentially there has to be a way of having a structure a bit more
> general than the following
> that can encode all the needed keys and that is extensible
>
>
>  RSAPublicKey ::= SEQUENCE {
>    modulus           INTEGER,  -- n
>    publicExponent    INTEGER   -- e
>  }
>
>
> So there does not seem to be a lack of solutions. The trick I suppose is
> finding the one that is the most likely to be adopted. I suppose some ASN.1
> DER encoding is the one most tools are ready for.
>
> Henry
>
> On 19 Feb 2011, at 02:24, Peter Gutmann wrote:
>
> > [Several of my posts didn't make it to the list, these are re-posts of
> earlier
> > messages]
> >
> > Paul Wouters <[email-masked]> writes:
> >> On Tue, 15 Feb 2011, Peter Gutmann wrote:
> >>>> The public key's type and raw blob will be obtained from DNSSEC, so
> this is
> >>>> no longer required to be conveyed to the client from the server via a
> PKIX
> >>>> certificate or other ASN.1 structures.
> >>>
> >>> But what format is the "type and raw blob" in?  You need some way of
> encoding
> >>> it, and if it's not the standard ASN.1 format what are you going to
> use?
> >>
> >> I'm not sure I understand your question.
> >
> > A public key contains a number of components and options. For example for
> ECC
> > there are the basic key values p, a, b, G, n, h (or m, f, a, b, G, n, h
> for
> > binary curves), an indication of the underlying field (prime or binary),
> the
> > point format, whether point compression is used, polynomial vs. normal
> basis,
> > whether fixed domain parameters are used, and probably some other stuff
> I've
> > forgotten.  How is all this stuff communicated?
> >
> >> The key would encoded in DNS, likely in a format similar to DNSKEY.
> >
> > DNSKEY (RFC 3757) just specifies an opaque value labelled "public key".
>  If
> > you mean RFC 4034:
> >
> >  RSA/MD5 [RSAMD5]         n      [RFC2537]  NOT RECOMMENDED
> >  Diffie-Hellman [DH]      n      [RFC2539]   -
> >  DSA/SHA-1 [DSA]          y      [RFC2536]  OPTIONAL
> >  Elliptic Curve [ECC]              TBA       -
> >  RSA/SHA-1 [RSASHA1]      y      [RFC3110]  MANDATORY
> >
> > this (a) ain't gonna cut it because it doesn't cover what's required by
> TLS
> > and (b) requires that your TLS implementation speak DNSSEC (or at least
> the
> > DNSKEY part of DNSSEC) just to get a key. I can't see TLS implementors
> being
> > too enthusiastic about this.
> >
> > Peter.
> > _______________________________________________
> > keyassure mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/keyassure
>
> Social Web Architect
> http://bblfish.net/
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

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

The problem with this approach is that it means that we are going to at bes=
t be exercising new code paths in existing code. At worst we are going to f=
orce people to write new code.<div><br></div><div><br></div><div>It is impo=
ssible to run TLS without X.509 code in the stack. Everything else is super=
fluous.</div>
<div><br></div><div>This is really bikeshedding. It is not going to simplif=
y implementation by an iota and it is going to create yet another special c=
ase to support.=A0</div><div><br></div><div>I don&#39;t think the crypto co=
mmunity wants to support yet another key format. Even if that format is &#3=
9;merely&#39; a subset of an existing format.<br>
<div><br></div><div><br><br><div class=3D"gmail_quote">On Sat, Feb 19, 2011=
 at 1:51 AM, Henry Story <span dir=3D"ltr">&lt;<a href=3D"mailto:henry.stor=
[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 soli=
d;padding-left:1ex;">
I had received your mails Peter. =A0Your mail is also available in the arch=
ives.<br>
<br>
 =A0 <a href=3D"http://www.ietf.org/mail-archive/web/keyassure/current/msg0=
1846.html" target=3D"_blank">http://www.ietf.org/mail-archive/web/keyassure=
/current/msg01846.html</a><br>
<br>
Ilari Liusvaara came up with a format for raw keys in what seems to be C<br=
>
<br>
 =A0 <a href=3D"http://www.ietf.org/mail-archive/web/keyassure/current/msg0=
1803.html" target=3D"_blank">http://www.ietf.org/mail-archive/web/keyassure=
/current/msg01803.html</a><br>
<br>
(though I am not sure that C is progress over ASN.1 for such a specificatio=
n)<br>
<br>
My question is: what do people use now to pass public keys? I know an X509 =
cert<br>
contains the public key, though I don&#39;t know if it can contain ECC keys=
.<br>
If it does then there is another simple answer: extract the part of that do=
cument<br>
that contains both the type of the key and the details of it, and use that.=
<br>
<br>
So in the XML world the xmldsig spec defines the KeyInfo element<br>
<a href=3D"http://www.w3.org/TR/xmldsig-core/#sec-KeyInfo" target=3D"_blank=
">http://www.w3.org/TR/xmldsig-core/#sec-KeyInfo</a><br>
which specified the following keys<br>
<br>
 =A0 * <a href=3D"http://www.w3.org/2000/09/xmldsig#DSAKeyValue" target=3D"=
_blank">http://www.w3.org/2000/09/xmldsig#DSAKeyValue</a><br>
 =A0 * <a href=3D"http://www.w3.org/2000/09/xmldsig#RSAKeyValue" target=3D"=
_blank">http://www.w3.org/2000/09/xmldsig#RSAKeyValue</a><br>
 =A0 * <a href=3D"http://www.w3.org/2000/09/xmldsig#X509Data" target=3D"_bl=
ank">http://www.w3.org/2000/09/xmldsig#X509Data</a><br>
 =A0 * <a href=3D"http://www.w3.org/2000/09/xmldsig#PGPData" target=3D"_bla=
nk">http://www.w3.org/2000/09/xmldsig#PGPData</a><br>
 =A0 * <a href=3D"http://www.w3.org/2000/09/xmldsig#SPKIData" target=3D"_bl=
ank">http://www.w3.org/2000/09/xmldsig#SPKIData</a><br>
 =A0 * <a href=3D"http://www.w3.org/2000/09/xmldsig#MgmtData" target=3D"_bl=
ank">http://www.w3.org/2000/09/xmldsig#MgmtData</a><br>
<br>
So there one could just take the KeyInfo Element, and use that as a documen=
t format to place the<br>
keys in. Of course one would remove X509, PGP keys, and one would have to d=
efine an xml structure for<br>
elliptic curve keys. I am not recomending this option<br>
<br>
So essentially there has to be a way of having a structure a bit more gener=
al than the following<br>
that can encode all the needed keys and that is extensible<br>
<br>
<br>
 =A0RSAPublicKey ::=3D SEQUENCE {<br>
 =A0 =A0modulus =A0 =A0 =A0 =A0 =A0 INTEGER, =A0-- n<br>
 =A0 =A0publicExponent =A0 =A0INTEGER =A0 -- e<br>
 =A0}<br>
<br>
<br>
So there does not seem to be a lack of solutions. The trick I suppose is fi=
nding the one that is the most likely to be adopted. I suppose some ASN.1 D=
ER encoding is the one most tools are ready for.<br>
<font color=3D"#888888"><br>
Henry<br>
</font><div><div></div><div class=3D"h5"><br>
On 19 Feb 2011, at 02:24, Peter Gutmann wrote:<br>
<br>
&gt; [Several of my posts didn&#39;t make it to the list, these are re-post=
s of earlier<br>
&gt; messages]<br>
&gt;<br>
&gt; Paul Wouters &lt;<a href=3D"mailto:[email-masked]">paul@xelerance.=
com</a>&gt; writes:<br>
&gt;&gt; On Tue, 15 Feb 2011, Peter Gutmann wrote:<br>
&gt;&gt;&gt;&gt; The public key&#39;s type and raw blob will be obtained fr=
om DNSSEC, so this is<br>
&gt;&gt;&gt;&gt; no longer required to be conveyed to the client from the s=
erver via a PKIX<br>
&gt;&gt;&gt;&gt; certificate or other ASN.1 structures.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; But what format is the &quot;type and raw blob&quot; in? =A0Yo=
u need some way of encoding<br>
&gt;&gt;&gt; it, and if it&#39;s not the standard ASN.1 format what are you=
 going to use?<br>
&gt;&gt;<br>
&gt;&gt; I&#39;m not sure I understand your question.<br>
&gt;<br>
&gt; A public key contains a number of components and options. For example =
for ECC<br>
&gt; there are the basic key values p, a, b, G, n, h (or m, f, a, b, G, n, =
h for<br>
&gt; binary curves), an indication of the underlying field (prime or binary=
), the<br>
&gt; point format, whether point compression is used, polynomial vs. normal=
 basis,<br>
&gt; whether fixed domain parameters are used, and probably some other stuf=
f I&#39;ve<br>
&gt; forgotten. =A0How is all this stuff communicated?<br>
&gt;<br>
&gt;&gt; The key would encoded in DNS, likely in a format similar to DNSKEY=
.<br>
&gt;<br>
&gt; DNSKEY (RFC 3757) just specifies an opaque value labelled &quot;public=
 key&quot;. =A0If<br>
&gt; you mean RFC 4034:<br>
&gt;<br>
&gt; =A0RSA/MD5 [RSAMD5] =A0 =A0 =A0 =A0 n =A0 =A0 =A0[RFC2537] =A0NOT RECO=
MMENDED<br>
&gt; =A0Diffie-Hellman [DH] =A0 =A0 =A0n =A0 =A0 =A0[RFC2539] =A0 -<br>
&gt; =A0DSA/SHA-1 [DSA] =A0 =A0 =A0 =A0 =A0y =A0 =A0 =A0[RFC2536] =A0OPTION=
AL<br>
&gt; =A0Elliptic Curve [ECC] =A0 =A0 =A0 =A0 =A0 =A0 =A0TBA =A0 =A0 =A0 -<b=
r>
&gt; =A0RSA/SHA-1 [RSASHA1] =A0 =A0 =A0y =A0 =A0 =A0[RFC3110] =A0MANDATORY<=
br>
&gt;<br>
&gt; this (a) ain&#39;t gonna cut it because it doesn&#39;t cover what&#39;=
s required by TLS<br>
&gt; and (b) requires that your TLS implementation speak DNSSEC (or at leas=
t the<br>
&gt; DNSKEY part of DNSSEC) just to get a key. I can&#39;t see TLS implemen=
tors being<br>
&gt; too enthusiastic about this.<br>
&gt;<br>
&gt; Peter.<br>
&gt; _______________________________________________<br>
&gt; keyassure mailing list<br>
&gt; <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/keyassure" target=3D"=
_blank">https://www.ietf.org/mailman/listinfo/keyassure</a><br>
<br>
</div></div><div class=3D"im">Social Web Architect<br>
<a href=3D"http://bblfish.net/" target=3D"_blank">http://bblfish.net/</a><b=
r>
<br>
_______________________________________________<br>
</div><div><div></div><div class=3D"h5">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>
</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>

--20cf3054ab2bae0ceb049ca5b14e--

From: "dane issue tracker" <[email-masked]>
Auto-Submitted: auto-generated
To: [email-masked]
Date: Sat, 19 Feb 2011 15:21:22 -0000
Cc: [email-masked]
Subject: Re: [keyassure] [dane] protocol #3 (closed): Format of the record.

#3: Format of the record.

Changes (by warren@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Consensus called as:

 We will be using a new RR type.

-- 
--------------------------------+-------------------------------------------
 Reporter:  warren@…            |        Owner:        
     Type:  task                |       Status:  closed
 Priority:  minor               |    Milestone:        
Component:  protocol            |      Version:        
 Severity:  Active WG Document  |   Resolution:  fixed 
 Keywords:                      |  
--------------------------------+-------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/dane/trac/ticket/3#comment:2>
dane <http://tools.ietf.org/dane/>

From: Warren Kumari <[email-masked]>
To: Paul Wouters <[email-masked]>
Date: Sat, 19 Feb 2011 10:16:53 -0500
Cc: [email-masked]
Subject: Re: [keyassure] Issue #3: Format of the record.

Okey dokey -- it seems that we are all happy with using "a new RR type  
(used in draft-ietf-dane-protocol-00)" and so I'm calling it....

W
On Feb 13, 2011, at 2:47 PM, Paul Wouters wrote:

> On Thu, 10 Feb 2011, Warren Kumari wrote:
>
>> We have "Issue #3: Format of the record" with the description:
>>
>> --------------------
>> Format of the record:
>> a subtype of CERT (as was used in early drafts)
>> a new RRtype (used in draft-ietf-dane-protocol-00)
>> a TXT record with _prefix.
>>
>> Hopefully this is just a representation issue and can be worked on  
>> after larger decisions have been made.
>>
>> ----------------------
>>
>> I think that we have settled on using a new RRtype (as shown in  
>> draft-ietf-dane-protocol-00), but I realize that we haven't  
>> explicitly had a consensus call on this, so I am (with all  
>> reverence) donning the bells and ribbons, stepping over the clay  
>> pipes, smacking myself smartly with the stick and beginning the  
>> consensus call...
>
> Yes, a new RRTYPE.
>
> Paul
>

From: Henry Story <[email-masked]>
Date: Sat, 19 Feb 2011 10:51:11 +0100
To: [email-masked]
Subject: Re: [keyassure] publishing the public key

I had received your mails Peter.  Your mail is also available in the =
archives.

   http://www.ietf.org/mail-archive/web/keyassure/current/msg01846.html

Ilari Liusvaara came up with a format for raw keys in what seems to be C
  =20
   http://www.ietf.org/mail-archive/web/keyassure/current/msg01803.html

(though I am not sure that C is progress over ASN.1 for such a =
specification)

My question is: what do people use now to pass public keys? I know an =
X509 cert
contains the public key, though I don't know if it can contain ECC keys.=20=

If it does then there is another simple answer: extract the part of that =
document
that contains both the type of the key and the details of it, and use =
that.

So in the XML world the xmldsig spec defines the KeyInfo element=20
http://www.w3.org/TR/xmldsig-core/#sec-KeyInfo
which specified the following keys

   * http://www.w3.org/2000/09/xmldsig#DSAKeyValue
   * http://www.w3.org/2000/09/xmldsig#RSAKeyValue
   * http://www.w3.org/2000/09/xmldsig#X509Data
   * http://www.w3.org/2000/09/xmldsig#PGPData
   * http://www.w3.org/2000/09/xmldsig#SPKIData
   * http://www.w3.org/2000/09/xmldsig#MgmtData

So there one could just take the KeyInfo Element, and use that as a =
document format to place the
keys in. Of course one would remove X509, PGP keys, and one would have =
to define an xml structure for
elliptic curve keys. I am not recomending this option

So essentially there has to be a way of having a structure a bit more =
general than the following
that can encode all the needed keys and that is extensible

  RSAPublicKey ::=3D SEQUENCE {
    modulus           INTEGER,  -- n
    publicExponent    INTEGER   -- e
  }

So there does not seem to be a lack of solutions. The trick I suppose is =
finding the one that is the most likely to be adopted. I suppose some =
ASN.1 DER encoding is the one most tools are ready for.

Henry

On 19 Feb 2011, at 02:24, Peter Gutmann wrote:

> [Several of my posts didn't make it to the list, these are re-posts of =
earlier
> messages]
>=20
> Paul Wouters <[email-masked]> writes:
>> On Tue, 15 Feb 2011, Peter Gutmann wrote:
>>>> The public key's type and raw blob will be obtained from DNSSEC, so =
this is
>>>> no longer required to be conveyed to the client from the server via =
a PKIX
>>>> certificate or other ASN.1 structures.
>>>=20
>>> But what format is the "type and raw blob" in?  You need some way of =
encoding
>>> it, and if it's not the standard ASN.1 format what are you going to =
use?
>>=20
>> I'm not sure I understand your question.
>=20
> A public key contains a number of components and options. For example =
for ECC
> there are the basic key values p, a, b, G, n, h (or m, f, a, b, G, n, =
h for
> binary curves), an indication of the underlying field (prime or =
binary), the
> point format, whether point compression is used, polynomial vs. normal =
basis,
> whether fixed domain parameters are used, and probably some other =
stuff I've
> forgotten.  How is all this stuff communicated?
>=20
>> The key would encoded in DNS, likely in a format similar to DNSKEY.
>=20
> DNSKEY (RFC 3757) just specifies an opaque value labelled "public =
key".  If
> you mean RFC 4034:
>=20
>  RSA/MD5 [RSAMD5]         n      [RFC2537]  NOT RECOMMENDED
>  Diffie-Hellman [DH]      n      [RFC2539]   -
>  DSA/SHA-1 [DSA]          y      [RFC2536]  OPTIONAL
>  Elliptic Curve [ECC]              TBA       -
>  RSA/SHA-1 [RSASHA1]      y      [RFC3110]  MANDATORY
>=20
> this (a) ain't gonna cut it because it doesn't cover what's required =
by TLS
> and (b) requires that your TLS implementation speak DNSSEC (or at =
least the
> DNSKEY part of DNSSEC) just to get a key. I can't see TLS implementors =
being
> too enthusiastic about this.
>=20
> Peter.
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Social Web Architect
http://bblfish.net/

From: Peter Gutmann <[email-masked]>
To: [email-masked], [email-masked]
Date: Sat, 19 Feb 2011 14:41:47 +1300
Subject: Re: [keyassure] publishing the public key

Paul Hoffman <[email-masked]> writes:

>I disagree that us using bare keys for identifying TLS server certificates is
>impossible.

It's not impossible, but close to it (and for ECC algos it may well be
impossible).  This is a really, really bad way to identify a cert.  For
relatively simple algorithms like RSA "all" you need to do is decode the key
in the cert (assuming your PKI API actually gives you access to it, if it just
treats the cert as a blob used for signing or encryption then you may not be
able to get to it), decode the key in DNS, canonicalise the two in some
manner, and then compare the components (as opposed to storing a hash of the
cert, for which you call memcmp(), thus the "all" in quotes above).  For ECC
keys there are so many ways to store the same key (different parameter
encodings, optional parameters, different ways of identifying the same
parameters and in different formats) that in general there's no really
reliable way to compare them.  Even with the simplest key type, RSA, it was
hard enough, I've got code that mostly works most of the time and that's way
more complicated than it has to be.

If you want to uniquely identify a certificate, use the SHA-1 hash like
everything else does.

Peter.

From: Peter Gutmann <[email-masked]>
To: [email-masked]
Date: Sat, 19 Feb 2011 14:24:35 +1300
Subject: Re: [keyassure] publishing the public key

[Several of my posts didn't make it to the list, these are re-posts of earlier
 messages]

Paul Wouters <[email-masked]> writes:
>On Tue, 15 Feb 2011, Peter Gutmann wrote:
>>> The public key's type and raw blob will be obtained from DNSSEC, so this is
>>> no longer required to be conveyed to the client from the server via a PKIX
>>> certificate or other ASN.1 structures.
>>
>> But what format is the "type and raw blob" in?  You need some way of encoding
>> it, and if it's not the standard ASN.1 format what are you going to use?
>
>I'm not sure I understand your question.

A public key contains a number of components and options. For example for ECC
there are the basic key values p, a, b, G, n, h (or m, f, a, b, G, n, h for
binary curves), an indication of the underlying field (prime or binary), the
point format, whether point compression is used, polynomial vs. normal basis,
whether fixed domain parameters are used, and probably some other stuff I've
forgotten.  How is all this stuff communicated?

>The key would encoded in DNS, likely in a format similar to DNSKEY.

DNSKEY (RFC 3757) just specifies an opaque value labelled "public key".  If
you mean RFC 4034:

  RSA/MD5 [RSAMD5]         n      [RFC2537]  NOT RECOMMENDED
  Diffie-Hellman [DH]      n      [RFC2539]   -
  DSA/SHA-1 [DSA]          y      [RFC2536]  OPTIONAL
  Elliptic Curve [ECC]              TBA       -
  RSA/SHA-1 [RSASHA1]      y      [RFC3110]  MANDATORY

this (a) ain't gonna cut it because it doesn't cover what's required by TLS
and (b) requires that your TLS implementation speak DNSSEC (or at least the
DNSKEY part of DNSSEC) just to get a key. I can't see TLS implementors being
too enthusiastic about this.

Peter.

From: Peter Gutmann <[email-masked]>
To: [email-masked],, [email-masked], [email-masked],
Date: Sat, 19 Feb 2011 14:24:03 +1300
Subject: Re: [keyassure] publishing the public key

[Several of my posts didn't make it to the list, these are re-posts of earlier
 messages]

Henry Story <[email-masked]> writes:

>And I think Browser Vendors will be very keen to implement this, as well as
>DNSSEC of course, given the terrible state of DNS.

Have any browser vendors actually expressed this opinion?  Given their well-
established track record of responding with PKI-me-harder in response to
existing PKI problems, are you sure they're going to rush to embrace this?

(Don't get me wrong, I think it's a really neat idea, I just can't see browser
vendors embracing it, given their current track record).

Peter.

From: Peter Gutmann <[email-masked]>
To: [email-masked],, [email-masked]
Date: Sat, 19 Feb 2011 14:15:35 +1300
Subject: Re: [keyassure] publishing the public key

[Several of my posts didn't make it to the list, these are re-posts of earlier
 messages]

Henry Story <[email-masked]> writes:

>In draft-dane-04 [1] one can currently only publish either a signature or a
>certificate in the DNS. That is the only allowed formats of the resource
>record are as specified in section 2.2
>
>[...]
>
>Why not publish the only piece of the certificate that is important in public
>key cryptography: the public key.

Whatever format gets used, could we restrict things to just a single form, or
at most two forms?  At the moment we've got two types of certs, two hashes of
certs, and a raw public key (or, most likely, two of them).  In practice
there's going to be some de facto standard that everyone uses (e.g. SHA-1
hashes of certs for "fingerprints", which every browser seems to support even
though there isn't even a standard specifying them), and adding a whole pile
of formats is going to reduce interoperability or (more likely) lead to
implementors ignoring all but whatever ends up as the de facto standard.  I'd
use the cert fingerprint (which is already the de facto universal identifier)
as a MUST and leave the rest as options.  TLS already requires that you send
the full cert, TLS implementations already generate a cert fingerprint, so all
that's left to implement besides (shudder) the res_query() lookup is a
memcmp().

Peter.

Date: Thu, 17 Feb 2011 05:56:10 -0800
From: Phillip Hallam-Baker <[email-masked]>
To: Yoav Nir <[email-masked]>
Cc: Adam Langley <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Bootstrapping Dane Adoption

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

On Wed, Feb 16, 2011 at 11:24 AM, Yoav Nir <[email-masked]> wrote:

>
> On Feb 16, 2011, at 6:48 PM, Adam Langley wrote:
>
> > On Wed, Feb 16, 2011 at 11:39 AM, Paul Wouters <[email-masked]>
> wrote:
> >> But it is not the vendors that would need to make that change? It's just
> the
> >> browser people and the entity deploying SSL proxies?
> >
> > Ah, I understand what you are suggesting. Indeed you could do that
> > with just action by the proxy admins. However, I still feel that those
> > people will be very slow in changing.
>
> I disagree. While my company doesn't make SSL proxies, we do make
> firewalls, and it's always up to us to accommodate whatever browsers
> customers are using. 10 years ago it turned out that our firewall was
> blocking Netscape browsers on Mac OS 9.2. We had to change our firewall.
>
> So if some new version of a popular browser starts getting blocked behind
> the SSL proxy, then the proxy vendor will be pressured to fix it. It's a
> competitive market, and you don't get to say, "oh, we don't support Chrome
> 11. Maybe we will next year"

But you do get to say 'we don't support a specific feature of Chrome 11'.

Having run firewalls as an outsourced service, I know that a huge fraction
of the installed base is misconfigured and has obsolete configurations. A
non trivial fraction of firewalls being brought under management turn out to
be configured for pass through of all protocols (The $250,000 ethernet cable
configuration).

I think we need to have a document that sets out what the specific issues
with these proxies are and we need to decide which to support and which to
not support.

SSL is not 'designed' to prevent MITM attacks, the whole PURPOSE of SSL is
to prevent MITM attacks. So I think we need to decide which issues to
support and which not to support.

I strongly suspect that the MITM proxy ssl capabilities are underspecified
to say the least. They were originally a feature that was thrown into
Netscape Navigator for expediency with zero discussion outside the company.

I know that it is the type of feature that IETF types have traditionally
preferred to ignore. I certainly have felt no inclination to look at that
type of feature. It was put in the specs against my protests as a fait
accompli.

But that is a pretty bad situation from a security point of view and there
is a huge risk here of creating a massive hole in SSL of Kaminsky
proportions if people decide that they can simply follow the same approach
because they have a particular view of what CAs do and they can remove
controls that they personally don't think matter.

I think we are going to either have to decide that this scheme is not going
to support SSL proxies at all or it is going to have to have a first class
mechanism designed to support the SSL proxy use case.

Handwaving arguments about security protocols are a recipe for disaster. In
particular the argument that 'its ok we already do this without disaster'
has led to a number of notorious security protocol failures.

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

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

<br><br><div class=3D"gmail_quote">On Wed, Feb 16, 2011 at 11:24 AM, Yoav N=
ir <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">ynir@checkp=
oint.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"><br>
On Feb 16, 2011, at 6:48 PM, Adam Langley wrote:<br>
<br>
&gt; On Wed, Feb 16, 2011 at 11:39 AM, Paul Wouters &lt;<a href=3D"mailto:p=
[email-masked]">[email-masked]</a>&gt; wrote:<br>
&gt;&gt; But it is not the vendors that would need to make that change? It&=
#39;s just the<br>
&gt;&gt; browser people and the entity deploying SSL proxies?<br>
&gt;<br>
&gt; Ah, I understand what you are suggesting. Indeed you could do that<br>
&gt; with just action by the proxy admins. However, I still feel that those=
<br>
&gt; people will be very slow in changing.<br>
<br>
</div>I disagree. While my company doesn&#39;t make SSL proxies, we do make=
 firewalls, and it&#39;s always up to us to accommodate whatever browsers c=
ustomers are using. 10 years ago it turned out that our firewall was blocki=
ng Netscape browsers on Mac OS 9.2. We had to change our firewall.<br>

<br>
So if some new version of a popular browser starts getting blocked behind t=
he SSL proxy, then the proxy vendor will be pressured to fix it. It&#39;s a=
 competitive market, and you don&#39;t get to say, &quot;oh, we don&#39;t s=
upport Chrome 11. Maybe we will next year&quot;</blockquote>
<div><br></div><div>But you do get to say &#39;we don&#39;t support a speci=
fic feature of Chrome 11&#39;.</div><div><br></div><div>Having run firewall=
s as an outsourced service, I know that a huge fraction of the installed ba=
se is misconfigured and has obsolete configurations. A non trivial fraction=
 of firewalls being brought under management turn out to be configured for =
pass through of all protocols (The $250,000 ethernet cable configuration).<=
/div>
<div><br></div><div><br></div><div>I think we need to have a document that =
sets out what the specific issues with these proxies are and we need to dec=
ide which to support and which to not support.</div><div><br></div><div>
SSL is not &#39;designed&#39; to prevent MITM attacks, the whole PURPOSE of=
 SSL is to prevent MITM attacks. So I think we need to decide which issues =
to support and which not to support.</div><div><br></div><div><br></div>
<div>I strongly suspect that the MITM proxy ssl capabilities are underspeci=
fied to say the least. They were originally a feature that was thrown into =
Netscape Navigator for expediency with zero discussion outside the company.=
</div>
<div><br></div><div>I know that it is the type of feature that IETF types h=
ave traditionally preferred to ignore. I certainly have felt no inclination=
 to look at that type of feature. It was put in the specs against my protes=
ts as a fait accompli.</div>
<div><br></div><div>But that is a pretty bad situation from a security poin=
t of view and there is a huge risk here of creating a massive hole in SSL o=
f Kaminsky proportions if people decide that they can simply follow the sam=
e approach because they have a particular view of what CAs do and they can =
remove controls that they personally don&#39;t think matter.</div>
<div><br></div><div>I think we are going to either have to decide that this=
 scheme is not going to support SSL proxies at all or it is going to have t=
o have a first class mechanism designed to support the SSL proxy use case.=
=A0</div>
<div><br></div><div><br></div><div>Handwaving arguments about security prot=
ocols are a recipe for disaster. In particular the argument that &#39;its o=
k we already do this without disaster&#39; has led to a number of notorious=
 security protocol failures.</div>
<div><br></div><div><br></div><div><br></div><div>=A0</div></div>-- <br>Web=
site: <a href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><b=
r>

--90e6ba6e866887386f049c7ac26b--

To: "Richard L. Barnes" <[email-masked]>
From: Mark Andrews <[email-masked]>
Date: Thu, 17 Feb 2011 19:55:36 +1100
Cc: Adam Langley <[email-masked]>, [email-masked]
Subject: Re: [keyassure] Bootstrapping Dane Adoption

In message <[email-masked]>, "Richard L. Barnes" 
writes:
> Actually, I don't think it would be that hard to spoof the root zone, =
> assuming your clients are provisioned with an alternate TA (i.e., the =
> one you hold). =20
> 
> In the worst case, you have to re-sign the root zone, then create keys =
> and signatures down the hierarchy to the record you want to spoof. =20
> 
> My DNSSEC foo is a little hazy on this one, but I wonder if you could =
> even just return signed records as if they came directly out of the =
> root.  I seem to recall a certain root node doing something like this =
> (returning A records, but no DNSSEC) last March or so.
> 
> I'm not saying this is a *good* idea, but technically, it does work.  =
> I'm not that hot on SSL middleboxes either, but they need to be handled =
> properly.
> 
> --Richard

You would have to sign every response and remove all trace of zone
cuts to use normal validators internally.  This assumes that you
want to intercept all communications.  If you just want to intercept
some then you would still need to make those paths appear to be in
the root zone.  You could delegate away the paths you don't care about.

> On Feb 16, 2011, at 6:20 PM, Mark Andrews wrote:
> 
> >=20
> > In message <[email-masked]>, "Richard L. =
> Barnes"=20
> > writes:
> >> Transparent SSL proxies really are a problem from a security =
> perspective.  It
> >> 's always a bad idea to design protocols that accommodate them =
> without client
> >> configuration -- because then you end up accommodating malicious MitM =
> entiti
> >> es as well.
> >>=20
> >> What is worth thinking through is what sort of client configuration =
> changes a
> >> re necessary to accommodate transparent SSL proxies.  In the current, =
> X.509-b
> >> ased environment, the critical change is to add a trust anchor to the =
> client=20
> >> SSL verification system.  This enables the proxy (holding the private =
> key tha
> >> t goes with the TA) to issue certs for sites that clients visit.
> >>=20
> >> The corresponding process for DANE would just change X.509 to DNSSEC: =
> Clients
> >> would have an additional DNSSEC TA (i.e., in addition to the root), =
> so that=20
> >> the proxy could assert trust chains that bind keys under its control =
> to names
> >> that clients are interested in.
> >>=20
> >> I wasn't kidding when I said that proxies would need to MitM the DNS =
> traffic=20
> >> as well :)
> >>=20
> >> --Richard
> >=20
> > Adding a alternate root trust anchor won't work.  The root key only
> > signs the root zone.  99.999% percent of spoofed anwers won't be
> > from the root zone.
> >=20
> > It needs to be a key that is use as a alternative verification
> > source or you need to trust "AD" and not validate yourself.
> >=20
> > Mark
> > --=20
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 17 Feb 2011 00:45:16 -0500
To: Mark Andrews <[email-masked]>
Cc: Adam Langley <[email-masked]>, [email-masked]
Subject: Re: [keyassure] Bootstrapping Dane Adoption

Actually, I don't think it would be that hard to spoof the root zone, =
assuming your clients are provisioned with an alternate TA (i.e., the =
one you hold). =20

In the worst case, you have to re-sign the root zone, then create keys =
and signatures down the hierarchy to the record you want to spoof. =20

My DNSSEC foo is a little hazy on this one, but I wonder if you could =
even just return signed records as if they came directly out of the =
root.  I seem to recall a certain root node doing something like this =
(returning A records, but no DNSSEC) last March or so.

I'm not saying this is a *good* idea, but technically, it does work.  =
I'm not that hot on SSL middleboxes either, but they need to be handled =
properly.

--Richard

On Feb 16, 2011, at 6:20 PM, Mark Andrews wrote:

>=20
> In message <[email-masked]>, "Richard L. =
Barnes"=20
> writes:
>> Transparent SSL proxies really are a problem from a security =
perspective.  It
>> 's always a bad idea to design protocols that accommodate them =
without client
>> configuration -- because then you end up accommodating malicious MitM =
entiti
>> es as well.
>>=20
>> What is worth thinking through is what sort of client configuration =
changes a
>> re necessary to accommodate transparent SSL proxies.  In the current, =
X.509-b
>> ased environment, the critical change is to add a trust anchor to the =
client=20
>> SSL verification system.  This enables the proxy (holding the private =
key tha
>> t goes with the TA) to issue certs for sites that clients visit.
>>=20
>> The corresponding process for DANE would just change X.509 to DNSSEC: =
Clients
>> would have an additional DNSSEC TA (i.e., in addition to the root), =
so that=20
>> the proxy could assert trust chains that bind keys under its control =
to names
>> that clients are interested in.
>>=20
>> I wasn't kidding when I said that proxies would need to MitM the DNS =
traffic=20
>> as well :)
>>=20
>> --Richard
>=20
> Adding a alternate root trust anchor won't work.  The root key only
> signs the root zone.  99.999% percent of spoofed anwers won't be
> from the root zone.
>=20
> It needs to be a key that is use as a alternative verification
> source or you need to trust "AD" and not validate yourself.
>=20
> Mark
> --=20
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

Date: Wed, 16 Feb 2011 19:23:06 -0500
To: "Steingruebl, Andy" <[email-masked]>
From: Stephen Kent <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Using trust anchor language

Sorry for the very tardy reply.

>  > -----Original Message-----
>>  From: Stephen Kent [mailto:[email-masked]]
>>
>>  Sorry for being dense, but can you explain how the SNI extension and IP
>>  exhaustion relate to the issue of extracting a DNS name from a cert vs.
>>  inferring it from the DNS record?
>
>Ordinarily, in order to host multiple TLS-endpoints (web virtual 
>hosting) on a single-IP, you have two choices:
>
>1. A cert with multiple SANs
>2. use SNI so a client can indicate which end-endpoint (hostname) it 
>is trying to reach.
>
>#1 is extremely problematic when virtual-hosting services for 
>different entities, or lots of entities.  For example, CDNs will 
>often try to virtual a number of websites at the same IP, and will 
>have a certificate with SANs that span a multitude of 
>organizations/businesses.
>
>#2 is problematic because SNI isn't supported in Windows-XP.
>
>Currently, #1 or a single-IP per "website/hostname" is required.
>
>With TLSA if we don't have to embed the hostname in the certificate 
>offered during the TLS handshake, we don't care about SNI if a 
>client supports TLSA.  Now, what client will support TLSA and not 
>SNI, well, that's why this isn't really that big a deal I suppose..

Thanks for the clarification of the TLS problem generated by virtual 
hosting, used with older versions of WIndows.

In DANE there is no issuance cost for having a lot of SANs in the 
server cert, or for changing the cert to add or remove SANs, but I 
admit that it could get big if there are a lot of sites hosted on the 
same machine.

If there are no attacks that arise if we ignore the name in a cert, then
we could do so as a way of avoiding this problem, and so I understand 
your motivation.

However, if the goal of DANE is to provide a cert to be used as a TA, 
to verify an EE cert for a web site, this is a problem, as it would 
interfere with cert chaining from the TA to the EE cert. So we do 
have some tradeoffs to consider.

Steve

To: Mark Andrews <[email-masked]>
Comments: In-reply-to Mark Andrews <[email-masked]> message dated "Thu, 17 Feb 2011 10:20:43 +1100."
Date: Wed, 16 Feb 2011 15:36:53 -0800
From: John Gilmore <[email-masked]>
Cc: Adam Langley <[email-masked]>, [email-masked]
Subject: Re: [keyassure] Bootstrapping Dane Adoption

> Transparent SSL proxies really are a problem from a security perspective.

If DANE anchoring of SSL is properly implemented, then anyone who
sticks a MITM (of any sort) in the middle is going to have it detected
and rejected.  No communication.  Even if it's corporate policy to
watch everything in the clear in some great-wall-of-Intel or whatever.

When that little LOCK icon turns on, you'll damn well know that you're
talking to the server of the domain name you typed - and nobody else.

It could only come from IETF...security protocols that actually work,
despite corporate policies against actual security!

	John

To: "Richard L. Barnes" <[email-masked]>
From: Mark Andrews <[email-masked]>
Date: Thu, 17 Feb 2011 10:20:43 +1100
Cc: Adam Langley <[email-masked]>, [email-masked]
Subject: Re: [keyassure] Bootstrapping Dane Adoption

In message <[email-masked]>, "Richard L. Barnes" 
writes:
> Transparent SSL proxies really are a problem from a security perspective.  It
> 's always a bad idea to design protocols that accommodate them without client
>  configuration -- because then you end up accommodating malicious MitM entiti
> es as well.
> 
> What is worth thinking through is what sort of client configuration changes a
> re necessary to accommodate transparent SSL proxies.  In the current, X.509-b
> ased environment, the critical change is to add a trust anchor to the client 
> SSL verification system.  This enables the proxy (holding the private key tha
> t goes with the TA) to issue certs for sites that clients visit.
> 
> The corresponding process for DANE would just change X.509 to DNSSEC: Clients
>  would have an additional DNSSEC TA (i.e., in addition to the root), so that 
> the proxy could assert trust chains that bind keys under its control to names
>  that clients are interested in.
> 
> I wasn't kidding when I said that proxies would need to MitM the DNS traffic 
> as well :)
> 
> --Richard

Adding a alternate root trust anchor won't work.  The root key only
signs the root zone.  99.999% percent of spoofed anwers won't be
from the root zone.

It needs to be a key that is use as a alternative verification
source or you need to trust "AD" and not validate yourself.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

From: Martin Rex <[email-masked]>
To: [email-masked] (Andrew Sullivan)
Date: Wed, 16 Feb 2011 22:01:56 +0100 (MET)
Cc: [email-masked]
Subject: Re: [keyassure] Bootstrapping Dane Adoption
Reply-To: [email-masked]

Andrew Sullivan wrote:
> 
> On Wed, Feb 16, 2011 at 11:50:15AM -0500, Richard L. Barnes wrote:
> > 
> > The corresponding process for DANE would just change X.509 to
> > DNSSEC: Clients would have an additional DNSSEC TA (i.e., in
> > addition to the root), so that the proxy could assert trust chains
> > that bind keys under its control to names that clients are
> > interested in.
> > 
> > I wasn't kidding when I said that proxies would need to MitM the DNS
> > traffic as well :)
> 
> You're suggesting that the client uses an intermediate resolver for
> which it has a TA configured.  The intermediate resolver, when
> responding to {all|some class of} queries, intercepts the answers,
> creates new RRSIGs and DS records and so on, and synthesizes those as
> part of the answer returned to the client?  I guess if you reproduce
> the whole chain of trust all the way down, it could work.  I'd want to
> work through it completely.  But do I have the idea right?

One possible hack for a HTTP CONNECT proxy would be to perform
all DANE-relevant DNSSEC lookups for the given URL and put the responses
in their entire beauty into Mime-Headers of the HTTP CONNECT response...

-Martin

From: Martin Rex <[email-masked]>
To: [email-masked] (Paul Wouters)
Date: Wed, 16 Feb 2011 21:34:52 +0100 (MET)
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] Bootstrapping Dane Adoption
Reply-To: [email-masked]

Paul Wouters wrote:
> > 
> > In order to get off the ground I feel that it's important that clients
> > not be broken so that sites don't feel pressure not to publish DNS
> > cert information.
> 
> You could disable DANE lookups if a proxy for SSL is configured?
> 
> I guess that leaves transparent SSL proxies still as a problem.

Transparent SSL proxies ought not to be a problem, since they do
not affect DNS lookups at all.

But _configured_ SSL proxies may be an indicator that a browser
itself lives in a seperate DNS universe (not that uncommon in
sensibly firewalled company networks), so that no DNS or DNSSEC
records from the internet are accessible for the browser.

There used to be a number of broken clients, though being
HTTP or HTTPS proxy capable, were still trying to resolve hostnames
locally even when connecting through the proxy and failed
badly if the DNS lookup failed.  It appeared to be common
breakage in Java applets a decade ago, but it also affected
the OpenSUSE 11.1 network installer.

A common workaround for such breakage is to add the offending
hostname with a random ip to the local hosts file and retry...

-Martin

Date: Wed, 16 Feb 2011 14:34:43 -0500
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Bootstrapping Dane Adoption

On Wed, Feb 16, 2011 at 11:50:15AM -0500, Richard L. Barnes wrote:
> 
> The corresponding process for DANE would just change X.509 to
> DNSSEC: Clients would have an additional DNSSEC TA (i.e., in
> addition to the root), so that the proxy could assert trust chains
> that bind keys under its control to names that clients are
> interested in.
> 
> I wasn't kidding when I said that proxies would need to MitM the DNS
> traffic as well :)

You're suggesting that the client uses an intermediate resolver for
which it has a TA configured.  The intermediate resolver, when
responding to {all|some class of} queries, intercepts the answers,
creates new RRSIGs and DS records and so on, and synthesizes those as
part of the answer returned to the client?  I guess if you reproduce
the whole chain of trust all the way down, it could work.  I'd want to
work through it completely.  But do I have the idea right?

A

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

From: Yoav Nir <[email-masked]>
To: Adam Langley <[email-masked]>
Date: Wed, 16 Feb 2011 21:24:02 +0200
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Bootstrapping Dane Adoption

On Feb 16, 2011, at 6:48 PM, Adam Langley wrote:

> On Wed, Feb 16, 2011 at 11:39 AM, Paul Wouters <[email-masked]> wrote=
:
>> But it is not the vendors that would need to make that change? It's just=
 the
>> browser people and the entity deploying SSL proxies?
>=20
> Ah, I understand what you are suggesting. Indeed you could do that
> with just action by the proxy admins. However, I still feel that those
> people will be very slow in changing.

I disagree. While my company doesn't make SSL proxies, we do make firewalls=
, and it's always up to us to accommodate whatever browsers customers are u=
sing. 10 years ago it turned out that our firewall was blocking Netscape br=
owsers on Mac OS 9.2. We had to change our firewall.

So if some new version of a popular browser starts getting blocked behind t=
he SSL proxy, then the proxy vendor will be pressured to fix it. It's a com=
petitive market, and you don't get to say, "oh, we don't support Chrome 11.=
 Maybe we will next year"

From: Yoav Nir <[email-masked]>
To: Paul Wouters <[email-masked]>
Date: Wed, 16 Feb 2011 21:19:18 +0200
Accept-Language: en-US
acceptlanguage: en-US
Cc: Adam Langley <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Bootstrapping Dane Adoption

On Feb 16, 2011, at 8:51 PM, Paul Wouters wrote:

> On Wed, 16 Feb 2011, Adam Langley wrote:
>=20
>> I don't believe that it does. What I'm suggesting is this:
>>=20
>> The set of root CAs shipped by default for Firefox and Microsoft is
>> known. We know that these aren't MITM certificates. So, if we get a CA
>> certificate rooted at one of those certs, and information from the DNS
>> which contradicts that, we can reject the certificate. This means that
>> you can't fool a CA into issuing a certificate and attack users.
>>=20
>> However, if a certificate validates, but isn't rooted at a standard
>> root, then it's been signed by a root that has been manually added. In
>> this case, there's a good chance that it's a MITM proxy and we skip
>> the DNS check. Thus the only roots which can override DNS information
>> are those which have been manually added.
>=20
> Ahh I see. I did not realise the browsers kept a difference between manua=
lly
> added and shipped per default. This would work then, except if the MITM
> proxy is signed with public CA shipped with a browser. Do people not do t=
hat?
> I thought perhaps MITM proxies did this to already reduce popups.

No, the commercial CAs don't sell you certificates with Basic Constraints s=
et to true. the MitM proxies have their own CA certificates, and the user (=
or her administrator) have to install the MitM certificate to get it to wor=
k. That way they know that they can be attacked.

It's also news to me that browsers differentiate between TAs that were ship=
ped as opposed to TAs that were added.=

Date: Wed, 16 Feb 2011 13:51:35 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Adam Langley <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Bootstrapping Dane Adoption

On Wed, 16 Feb 2011, Adam Langley wrote:

> I don't believe that it does. What I'm suggesting is this:
>
> The set of root CAs shipped by default for Firefox and Microsoft is
> known. We know that these aren't MITM certificates. So, if we get a CA
> certificate rooted at one of those certs, and information from the DNS
> which contradicts that, we can reject the certificate. This means that
> you can't fool a CA into issuing a certificate and attack users.
>
> However, if a certificate validates, but isn't rooted at a standard
> root, then it's been signed by a root that has been manually added. In
> this case, there's a good chance that it's a MITM proxy and we skip
> the DNS check. Thus the only roots which can override DNS information
> are those which have been manually added.

Ahh I see. I did not realise the browsers kept a difference between manually
added and shipped per default. This would work then, except if the MITM
proxy is signed with public CA shipped with a browser. Do people not do that?
I thought perhaps MITM proxies did this to already reduce popups.

Paul

Sender: [email-masked]
Date: Wed, 16 Feb 2011 13:05:53 -0500
From: Adam Langley <[email-masked]>
To: Paul Wouters <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Bootstrapping Dane Adoption

On Wed, Feb 16, 2011 at 12:31 PM, Paul Wouters <[email-masked]> wrote:
> This reduces DANE back to the case where every CA on the planet can MITM.
> That would not be good. At least make it a config option that can be
> changed, and then we can argue about when is the right time to switch it.

I don't believe that it does. What I'm suggesting is this:

The set of root CAs shipped by default for Firefox and Microsoft is
known. We know that these aren't MITM certificates. So, if we get a CA
certificate rooted at one of those certs, and information from the DNS
which contradicts that, we can reject the certificate. This means that
you can't fool a CA into issuing a certificate and attack users.

However, if a certificate validates, but isn't rooted at a standard
root, then it's been signed by a root that has been manually added. In
this case, there's a good chance that it's a MITM proxy and we skip
the DNS check. Thus the only roots which can override DNS information
are those which have been manually added.

It will fail if there are MITM proxies that use intermediate CA
certificates that root at a standard root. I very much hope, for many
reasons, that such a proxy doesn't exist.

AGL

-- 
Adam Langley [email-masked] http://www.imperialviolet.org

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 16 Feb 2011 10:01:49 -0800
To: Ilari Liusvaara <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] publishing the public key

A much better saving is to use the tls option that allows for fast rekey by m=
eans of a kerberos like ticket stored on the client side.

That approach means the client does one key exchange and that is leveraged o=
ver multiple http sessions.

The cert is only a kb, self signed certs are less and your main saving would=
 be not having the signature. Looking at the tls key exchange, what matters i=
s packets, not really bytes. I dont think you will find certs vs keys saves a=
 packet.

Sent from my iPad

On Feb 14, 2011, at 4:46, Ilari Liusvaara <[email-masked]> wrot=
e:

> On Mon, Feb 14, 2011 at 11:20:33AM +0100, Henry Story wrote:
>> Hi,
>>=20
>> In draft-dane-04 [1] one can currently only publish either a signature
>> or a certificate in the DNS. That is the only allowed formats of the
>> resource record are as specified in section 2.2
>>=20
>>  1 -- Hash of an end-entity certificate
>>  2 -- Full end-entity certificate in DER encoding
>>  3 -- Hash of an certification authority's certificate
>>  4 -- Full certification authority's certificate in DER encoding
>>=20
>> Why not publish the only piece of the certificate that is important in
>> public key cryptography: the public key. ( This is what WebID does
>> currently ) This should be shorter than the certificate, and though it
>> will be longer than the signature, it will be a lot more useful, tying
>> the publisher much less to a particular serialisation format. So you
>> reduce the PGP/X509 disagreements.
>=20
> Unfortunately TLS requires sending the full certificate. Yes, one could
> define a new certificate type that contained just the public key, but
> that would require a IETF consensus (RFC through TLS working
> group[1]).
>=20
> Then one would define new DANE ceritifcate type (3 [2] or 5/6) to
> match that.
>=20
> <snip idea of certificate URLs>
>=20
> I don't think that would be possible to use without new certificate
> type either.
>=20
> As for bandwidth, sure it would save some. One can send well-secured
> key in roughly 80 bytes total (including CertificateType extension).
> Modern X.509 certs are far larger[3], even if restricted to bare
> minimum fields.
>=20
> As for what this would be useful for: If the raw key format would
> be easily parsed, it would save lots of tricky ASN.1 and X.509
> parsing (yes, there are libraries for that)
>=20
>=20
>=20
>=20
> [1] Not entierely accurate, it is RFC approved by IESG (and they'll
> consult TLS WG).
>=20
> [2] Since those 4 types could be collapsed to 2 (2 of those require
> second byte to be zero and 2 require nonzero second byte)
>=20
> [3] There's also subtle performance issue there. Those certificates
> can be so large that TCP windows get overflowed. As consequence,
> either one has to break TCP spec (many sites do this) or suffer
> a latency hit.
>=20
> -Ilari
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Date: Wed, 16 Feb 2011 12:31:50 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Adam Langley <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Bootstrapping Dane Adoption

On Wed, 16 Feb 2011, Adam Langley wrote:

> For transparent proxies I suspect that we'll need to skip them when
> the certificate is correctly signed by a root which has been added to
> the system.

This reduces DANE back to the case where every CA on the planet can MITM.
That would not be good. At least make it a config option that can be
changed, and then we can argue about when is the right time to switch it.

Paul

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 16 Feb 2011 11:51:27 -0500
To: "Richard L. Barnes" <[email-masked]>
Cc: Adam Langley <[email-masked]>, [email-masked]
Subject: Re: [keyassure] Bootstrapping Dane Adoption

Of course, Adam's idea to allow locally-configured X.509 TAs to override =
DANE would work as well.  That's just forcing the client back into the =
old world, which is a good thing in this case.
--Richard

On Feb 16, 2011, at 11:50 AM, Richard L. Barnes wrote:

> Transparent SSL proxies really are a problem from a security =
perspective.  It's always a bad idea to design protocols that =
accommodate them without client configuration -- because then you end up =
accommodating malicious MitM entities as well.
>=20
> What is worth thinking through is what sort of client configuration =
changes are necessary to accommodate transparent SSL proxies.  In the =
current, X.509-based environment, the critical change is to add a trust =
anchor to the client SSL verification system.  This enables the proxy =
(holding the private key that goes with the TA) to issue certs for sites =
that clients visit.
>=20
> The corresponding process for DANE would just change X.509 to DNSSEC: =
Clients would have an additional DNSSEC TA (i.e., in addition to the =
root), so that the proxy could assert trust chains that bind keys under =
its control to names that clients are interested in.
>=20
> I wasn't kidding when I said that proxies would need to MitM the DNS =
traffic as well :)
>=20
> --Richard
>=20
>=20
>=20
> On Feb 16, 2011, at 11:39 AM, Paul Wouters wrote:
>=20
>> On Wed, 16 Feb 2011, Adam Langley wrote:
>>=20
>>> On Wed, Feb 16, 2011 at 11:23 AM, Paul Wouters <[email-masked]> =
wrote:
>>>> Couldn't the MITM SSL proxy register their cert in the DNS entry =
associated
>>>> with their name or reverse ? That way, it becomes a "DANE =
certified" MITM,
>>>> so 1) if the user configured a MITM proxy and 2) the DANE cert =
matches, then
>>>> don't warn the user...
>>>>=20
>>>> Now people with a MITM SSL proxy are protected against other MITM =
entities.
>>>=20
>>> Pressure can be applied to the vendors to make changes but, in my
>>> experience, they move very slowly and customer update firmware even
>>> more slowly.
>>=20
>> But it is not the vendors that would need to make that change? It's =
just the
>> browser people and the entity deploying SSL proxies?
>>=20
>>> In order to get off the ground I feel that it's important that =
clients
>>> not be broken so that sites don't feel pressure not to publish DNS
>>> cert information.
>>=20
>> You could disable DANE lookups if a proxy for SSL is configured?
>>=20
>> I guess that leaves transparent SSL proxies still as a problem.
>>=20
>> Paul
>> _______________________________________________
>> 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

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 16 Feb 2011 11:50:15 -0500
To: Paul Wouters <[email-masked]>
Cc: Adam Langley <[email-masked]>, [email-masked]
Subject: Re: [keyassure] Bootstrapping Dane Adoption

Transparent SSL proxies really are a problem from a security =
perspective.  It's always a bad idea to design protocols that =
accommodate them without client configuration -- because then you end up =
accommodating malicious MitM entities as well.

What is worth thinking through is what sort of client configuration =
changes are necessary to accommodate transparent SSL proxies.  In the =
current, X.509-based environment, the critical change is to add a trust =
anchor to the client SSL verification system.  This enables the proxy =
(holding the private key that goes with the TA) to issue certs for sites =
that clients visit.

The corresponding process for DANE would just change X.509 to DNSSEC: =
Clients would have an additional DNSSEC TA (i.e., in addition to the =
root), so that the proxy could assert trust chains that bind keys under =
its control to names that clients are interested in.

I wasn't kidding when I said that proxies would need to MitM the DNS =
traffic as well :)

--Richard

On Feb 16, 2011, at 11:39 AM, Paul Wouters wrote:

> On Wed, 16 Feb 2011, Adam Langley wrote:
>=20
>> On Wed, Feb 16, 2011 at 11:23 AM, Paul Wouters <[email-masked]> =
wrote:
>>> Couldn't the MITM SSL proxy register their cert in the DNS entry =
associated
>>> with their name or reverse ? That way, it becomes a "DANE certified" =
MITM,
>>> so 1) if the user configured a MITM proxy and 2) the DANE cert =
matches, then
>>> don't warn the user...
>>>=20
>>> Now people with a MITM SSL proxy are protected against other MITM =
entities.
>>=20
>> Pressure can be applied to the vendors to make changes but, in my
>> experience, they move very slowly and customer update firmware even
>> more slowly.
>=20
> But it is not the vendors that would need to make that change? It's =
just the
> browser people and the entity deploying SSL proxies?
>=20
>> In order to get off the ground I feel that it's important that =
clients
>> not be broken so that sites don't feel pressure not to publish DNS
>> cert information.
>=20
> You could disable DANE lookups if a proxy for SSL is configured?
>=20
> I guess that leaves transparent SSL proxies still as a problem.
>=20
> Paul
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Sender: [email-masked]
Date: Wed, 16 Feb 2011 11:48:29 -0500
From: Adam Langley <[email-masked]>
To: Paul Wouters <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Bootstrapping Dane Adoption

On Wed, Feb 16, 2011 at 11:39 AM, Paul Wouters <[email-masked]> wrote:
> But it is not the vendors that would need to make that change? It's just the
> browser people and the entity deploying SSL proxies?

Ah, I understand what you are suggesting. Indeed you could do that
with just action by the proxy admins. However, I still feel that those
people will be very slow in changing.

> You could disable DANE lookups if a proxy for SSL is configured?
>
> I guess that leaves transparent SSL proxies still as a problem.

Skipping additional checks when a proxy is configured is a good idea.
For transparent proxies I suspect that we'll need to skip them when
the certificate is correctly signed by a root which has been added to
the system.

But, in the end, we'll have to try our best and discover what works
via bug reports.

AGL

-- 
Adam Langley [email-masked] http://www.imperialviolet.org

Date: Wed, 16 Feb 2011 11:39:01 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Adam Langley <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Bootstrapping Dane Adoption

On Wed, 16 Feb 2011, Adam Langley wrote:

> On Wed, Feb 16, 2011 at 11:23 AM, Paul Wouters <[email-masked]> wrote:
>> Couldn't the MITM SSL proxy register their cert in the DNS entry associated
>> with their name or reverse ? That way, it becomes a "DANE certified" MITM,
>> so 1) if the user configured a MITM proxy and 2) the DANE cert matches, then
>> don't warn the user...
>>
>> Now people with a MITM SSL proxy are protected against other MITM entities.
>
> Pressure can be applied to the vendors to make changes but, in my
> experience, they move very slowly and customer update firmware even
> more slowly.

But it is not the vendors that would need to make that change? It's just the
browser people and the entity deploying SSL proxies?

> In order to get off the ground I feel that it's important that clients
> not be broken so that sites don't feel pressure not to publish DNS
> cert information.

You could disable DANE lookups if a proxy for SSL is configured?

I guess that leaves transparent SSL proxies still as a problem.

Paul

Sender: [email-masked]
Date: Wed, 16 Feb 2011 11:29:22 -0500
From: Adam Langley <[email-masked]>
To: Paul Wouters <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Bootstrapping Dane Adoption

On Wed, Feb 16, 2011 at 11:23 AM, Paul Wouters <[email-masked]> wrote:
> Couldn't the MITM SSL proxy register their cert in the DNS entry associated
> with their name or reverse ? That way, it becomes a "DANE certified" MITM,
> so 1) if the user configured a MITM proxy and 2) the DANE cert matches, then
> don't warn the user...
>
> Now people with a MITM SSL proxy are protected against other MITM entities.

Pressure can be applied to the vendors to make changes but, in my
experience, they move very slowly and customer update firmware even
more slowly.

In order to get off the ground I feel that it's important that clients
not be broken so that sites don't feel pressure not to publish DNS
cert information.

AGL

-- 
Adam Langley [email-masked] http://www.imperialviolet.org

Date: Wed, 16 Feb 2011 11:23:59 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Adam Langley <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Bootstrapping Dane Adoption

On Wed, 16 Feb 2011, Adam Langley wrote:

> On Wed, Feb 16, 2011 at 4:17 AM, Henry Story <[email-masked]> wrote:
>> With even a few million such entries it would then be very easy to
>> convince browser manufacturers of the use of adding support for DANE.
>
> Nope, because it would break everyone behind a MITM SSL proxy.

Couldn't the MITM SSL proxy register their cert in the DNS entry associated
with their name or reverse ? That way, it becomes a "DANE certified" MITM,
so 1) if the user configured a MITM proxy and 2) the DANE cert matches, then
don't warn the user...

Now people with a MITM SSL proxy are protected against other MITM entities.

Paul

Date: Wed, 16 Feb 2011 10:56:18 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Matt McCutchen <[email-masked]>
Cc: keyassure <[email-masked]>
Subject: Re: [keyassure] Proof-of-concept implementation for NSS

On Wed, 16 Feb 2011, Matt McCutchen wrote:

> Surprise!
>
> I have a proof-of-concept implementation of DANE for NSS working against
> TLSA data on mattmccutchen.net.  Firefox even runs with the modified
> NSS, though it shows unverified certificate details.  Only SHA-1 hashes
> of end-entity certificates are supported, following the format in
> draft-ietf-dane-protocol-04.  The NSS patch, which includes
> documentation, will be maintained at:
>
> https://mattmccutchen.net/cryptid/#nss-dane

This is awesome! I will test these and update my tools to generate TLSA
with prefixes and let you know!

Paul

Sender: [email-masked]
Date: Wed, 16 Feb 2011 10:44:06 -0500
From: Adam Langley <[email-masked]>
To: Henry Story <[email-masked]>
Cc: John Gilmore <[email-masked]>, [email-masked]
Subject: Re: [keyassure] Bootstrapping Dane Adoption

On Wed, Feb 16, 2011 at 10:34 AM, Henry Story <[email-masked]> wro=
te:
> =C2=A0Step 1. is this certificate signed by a trusted CA, or can I build =
a chain to a trusted CA?
> =C2=A0- If yes, it's a good connection. Proceed with browsing experience.

We're solving different problems. You want to enable certificates to
validate without being CA signed. I understand that, although, given
that StartCom gives out free certs I feel that this is mostly a large
organisation problem.

I'm talking about sites which are worried about CAs misissuing
certificates. Either because the CA was fooled (*), or because an
intermediate CA cert was misused.

These sites have CA signed certs but they want to publish information
which excludes other CAs, or other certificates. That leads to the
chicken-and-egg problem that I described.

AGL

--=20
Adam Langley [email-masked] http://www.imperialviolet.org

From: Henry Story <[email-masked]>
Date: Wed, 16 Feb 2011 16:34:20 +0100
To: Adam Langley <[email-masked]>
Cc: John Gilmore <[email-masked]>, [email-masked]
Subject: Re: [keyassure] Bootstrapping Dane Adoption

On 16 Feb 2011, at 15:43, Adam Langley wrote:

> On Wed, Feb 16, 2011 at 8:43 AM, Henry Story <[email-masked]> =
wrote:
>> Yes, sorry. I was not proposing more UI warnings for the browser =
user.
>> Rather I was thinking of having the DNS provider send an email =
suggesting
>> to its clients to add public keys using dane to DNSsec.
>=20
> If DNS information is to be used as an additional source of
> certificate verification then you have a chicken and egg problem:
>  * Sites won't publish the information in DNS because it'll break
> capable clients behind MITM proxies.

Why would publishing a public key in DNS break capable clients behind
MITM proxies?=20

 1- for current browsers it makes no difference, since they don't look
   in DNS for that information
 2- for the yet to be built browsers it will depend on how MITM proxies=20=

   work and how the algorithm for chosen for selecting legitimate =
certificate.=20

 How do MITM proxies work? I am told ( http://bit.ly/g4jt5P ) that =
either
   a. companies simply place the MITM certificate in their employees =
browsers as trusted root certificates
   b. there seems to be something as a "Proxy Certificates" which I have =
not enough
      information for.

  So the case we are looking at for the moment is a situation such as =
2a, and
the trick is to specify an algorithm where browsers work behind good =
proxies, but not
behind evil proxies such as the ones in an internet caf=E9. We also want =
browsers
2a to allow legitimate self signed certificates. It seems to me that =
this is an easy algorithm to write down. The User Agent on receiving a =
certificate follows this procedure

  Step 1. is this certificate signed by a trusted CA, or can I build a =
chain to a trusted CA?=20
  - If yes, it's a good connection. Proceed with browsing experience.
    Note that since legitimate Proxy certificates appear in the trusted =
CA list as explained in a above (and I imagine something similar works =
for what is known as "Proxy Certificates") this deals with legitimate =
proxies. Illegitimate proxies won't be able to be tied to the trusted CA =
roots, and the DNS lookup described in step 2 won't work either, so they =
will fail)
  - else go to 2.
=20
  Step 2. Is this a self signed certificate, or one that it makes sense =
to look up in DNSsec?=20
  - If yes, look it up, and if tests succeeds then it's a good =
connection. Continue with browsing experience.=20
  - else show ugly monster to user so he understand this is dangerous.

>  * MITM proxies won't change until the pressure is overwhelming.

I think there is no need for them to change. Well if I thought about it, =
perhaps I could come up with ways to improve them, but that would be a =
different topic.

>=20
> (`Sites' here means sites that have valid certificate, but are worried
> about mis-issuance by CAs, mistaken or otherwise.)
>=20
> I'm not suggesting that MITM proxies are a good thing but the reality
> is that a) they exist in numbers large enough that we can't ignore
> them b) they're very slow to change.
>=20
>> You mean assume it's a Good MITM box and skip the check? That would =
completely
>> defeat the whole point of TLS. I think you must be thinking of =
something else.
>=20
> Yes that's what I'm suggesting as a way to break the deadlock =
described above.

So how does that not break all of TLS at the same time?

Henry

>=20
>=20
> AGL
>=20
> --=20
> Adam Langley [email-masked] http://www.imperialviolet.org

Social Web Architect
http://bblfish.net/

Sender: [email-masked]
Date: Wed, 16 Feb 2011 09:43:31 -0500
From: Adam Langley <[email-masked]>
To: Henry Story <[email-masked]>
Cc: John Gilmore <[email-masked]>, [email-masked]
Subject: Re: [keyassure] Bootstrapping Dane Adoption

On Wed, Feb 16, 2011 at 8:43 AM, Henry Story <[email-masked]> wrote:
> Yes, sorry. I was not proposing more UI warnings for the browser user.
> Rather I was thinking of having the DNS provider send an email suggesting
> to its clients to add public keys using dane to DNSsec.

If DNS information is to be used as an additional source of
certificate verification then you have a chicken and egg problem:
  * Sites won't publish the information in DNS because it'll break
capable clients behind MITM proxies.
  * MITM proxies won't change until the pressure is overwhelming.

(`Sites' here means sites that have valid certificate, but are worried
about mis-issuance by CAs, mistaken or otherwise.)

I'm not suggesting that MITM proxies are a good thing but the reality
is that a) they exist in numbers large enough that we can't ignore
them b) they're very slow to change.

> You mean assume it's a Good MITM box and skip the check? That would completely
> defeat the whole point of TLS. I think you must be thinking of something else.

Yes that's what I'm suggesting as a way to break the deadlock described above.

AGL

-- 
Adam Langley [email-masked] http://www.imperialviolet.org

From: Matt McCutchen <[email-masked]>
To: [email-masked]
Date: Wed, 16 Feb 2011 09:33:59 -0500
Subject: Re: [keyassure] Bootstrapping Dane Adoption

On Wed, 2011-02-16 at 14:43 +0100, Henry Story wrote:
> On 16 Feb 2011, at 14:03, Adam Langley wrote:
> > Rather I suspect that the answer will be in the form: "If this cert is
> > accepted by the verifier but is rooted at a non-default CA, then
> > assume it's a MITM box and skip the check". That's been on my todo
> > list for a while now in Chrome.
> 
> You mean assume it's a Good MITM box and skip the check? That would completely
> defeat the whole point of TLS. I think you must be thinking of something else.

The proposal is to exempt "non-default" trusted CAs from DANE exclusion,
but I don't think "non-default", whatever it means, is what we want.  We
probably want a separate trust bit.  Let's just hope Mozilla doesn't
start handing it out to public CAs.

-- 
Matt

From: Matt McCutchen <[email-masked]>
To: [email-masked]
Date: Wed, 16 Feb 2011 09:00:22 -0500
Subject: Re: [keyassure] Bootstrapping Dane Adoption

On Wed, 2011-02-16 at 08:39 -0500, Richard L. Barnes wrote:
> Presumably the MITM SSL proxy vendors just need to start MITM-ing the DNS traffic now too?

Yep.  Let them fork the world all the way up to the root zone trust
anchor.

-- 
Matt

From: Henry Story <[email-masked]>
Date: Wed, 16 Feb 2011 14:43:39 +0100
To: Adam Langley <[email-masked]>
Cc: John Gilmore <[email-masked]>, [email-masked]
Subject: Re: [keyassure] Bootstrapping Dane Adoption

On 16 Feb 2011, at 14:03, Adam Langley wrote:

> On Wed, Feb 16, 2011 at 7:52 AM, Henry Story <[email-masked]> =
wrote:
>> Ok. So it could automatically alert the user, and ask him if he would
>> like this to happen by confirming securely his intention.

Oops. Sorry I think I sent my reply above too quickly. I was thinking =
you
were speaking of the DNSsec provider having a MITM problem, and so my =
solution
was geared towards asking the domain admin to verify that.

But in fact you were thinking of this from the =
end-user-behind-his-browser
experience, and the issue you are thinking of is not just any MITM TLS =
proxy,=20
but legitimate ones such as those that are behind HTTPS company =
firewalls.=20
As it happens we just had  a discussion of this on the WebID mailing =
list=20

ISSUE-28: "How does the WebID protocol (foaf+ssl) interact with TLS =
proxies"
           http://www.w3.org/2005/Incubator/webid/track/issues/28

So if I understand correctly from that discussion and thanks to the =
clear=20
contribution by Yngve from Opera ( http://bit.ly/g4jt5P ) companies that
use these proxies would put the proxy root certificate into their =
employees=20
browsers. They would be foolish if they did not, because if they did not
they would be training their users not to take care of security alerts.

What the proposal of allowing people to place self signed certs into =
DNSsec
using Dane is designed to do, is to allow browsers to distinguish =
between
the millions of legitimate self signed certs and the non legitimate =
ones.
As a result browser warnings will be a lot more meaningful.

What you are bringing up is another subset of self signed certificates=20=

usages: those by legitimate TLS proxies. For those it seems there is
the existing solution described above. Yngve also mentioned something
about "Proxy Certificates" though I don't know much about those.=20

>=20
> Adding more UI warnings is a classic trap that smart people fall into.
> Although it suffices for experts, it's worse than useless for 99.9% of
> users.

Yes, sorry. I was not proposing more UI warnings for the browser user.
Rather I was thinking of having the DNS provider send an email =
suggesting=20
to its clients to add public keys using dane to DNSsec.

I was in fact trying to reduce the case of legitimate end user warnings
by allowing the browser to distinguish between legitimate and=20
illegitimate self signed certificates by allowing legitimate web sites
to place keys in DNSsec.

>=20
> Rather I suspect that the solution will have to be more messy than
> this. If we had a list of the Issuer names that MITM boxes used, then
> we could skip the check in those cases. But we don't and finding out
> will be painful for some users.

There seems to be something called "Proxy certificates" according to =
Yngve.
But he did not give further pointers, so I don't know how those work.

> Rather I suspect that the answer will be in the form: "If this cert is
> accepted by the verifier but is rooted at a non-default CA, then
> assume it's a MITM box and skip the check". That's been on my todo
> list for a while now in Chrome.

You mean assume it's a Good MITM box and skip the check? That would =
completely
defeat the whole point of TLS. I think you must be thinking of something =
else.

Henry

>=20
>=20
> AGL
>=20
> --=20
> Adam Langley [email-masked] http://www.imperialviolet.org

Social Web Architect
http://bblfish.net/

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 16 Feb 2011 08:39:55 -0500
To: Adam Langley <[email-masked]>
Cc: John Gilmore <[email-masked]>, [email-masked]
Subject: Re: [keyassure] Bootstrapping Dane Adoption

Presumably the MITM SSL proxy vendors just need to start MITM-ing the =
DNS traffic now too?

Honestly, this seems like a security plus to me -- out-of-band =
verification of keys!

--Richard

On Feb 16, 2011, at 7:21 AM, Adam Langley wrote:

> On Wed, Feb 16, 2011 at 4:17 AM, Henry Story <[email-masked]> =
wrote:
>> With even a few million such entries it would then be very easy to
>> convince browser manufacturers of the use of adding support for DANE.
>=20
> Nope, because it would break everyone behind a MITM SSL proxy.
>=20
>=20
> AGL
>=20
> --=20
> Adam Langley [email-masked] http://www.imperialviolet.org
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Sender: [email-masked]
Date: Wed, 16 Feb 2011 08:03:39 -0500
From: Adam Langley <[email-masked]>
To: Henry Story <[email-masked]>
Cc: John Gilmore <[email-masked]>, [email-masked]
Subject: Re: [keyassure] Bootstrapping Dane Adoption

On Wed, Feb 16, 2011 at 7:52 AM, Henry Story <[email-masked]> wrote:
> Ok. So it could automatically alert the user, and ask him if he would
> like this to happen by confirming securely his intention.

Adding more UI warnings is a classic trap that smart people fall into.
Although it suffices for experts, it's worse than useless for 99.9% of
users.

Rather I suspect that the solution will have to be more messy than
this. If we had a list of the Issuer names that MITM boxes used, then
we could skip the check in those cases. But we don't and finding out
will be painful for some users.

Rather I suspect that the answer will be in the form: "If this cert is
accepted by the verifier but is rooted at a non-default CA, then
assume it's a MITM box and skip the check". That's been on my todo
list for a while now in Chrome.

AGL

-- 
Adam Langley [email-masked] http://www.imperialviolet.org

From: Henry Story <[email-masked]>
Date: Wed, 16 Feb 2011 13:52:51 +0100
To: Adam Langley <[email-masked]>
Cc: John Gilmore <[email-masked]>, [email-masked]
Subject: Re: [keyassure] Bootstrapping Dane Adoption

On 16 Feb 2011, at 13:21, Adam Langley wrote:

> On Wed, Feb 16, 2011 at 4:17 AM, Henry Story <[email-masked]> =
wrote:
>> With even a few million such entries it would then be very easy to
>> convince browser manufacturers of the use of adding support for DANE.
>=20
> Nope, because it would break everyone behind a MITM SSL proxy.

Ok. So it could automatically alert the user, and ask him if he would
like this to happen by confirming securely his intention.=20

Perhaps a link to a browser plugin initially would be useful,
so that people can see where this is leading.

Henry

>=20
>=20
> AGL
>=20
> --=20
> Adam Langley [email-masked] http://www.imperialviolet.org

Social Web Architect
http://bblfish.net/

Sender: [email-masked]
Date: Wed, 16 Feb 2011 07:21:02 -0500
From: Adam Langley <[email-masked]>
To: Henry Story <[email-masked]>
Cc: John Gilmore <[email-masked]>, [email-masked]
Subject: Re: [keyassure] Bootstrapping Dane Adoption

On Wed, Feb 16, 2011 at 4:17 AM, Henry Story <[email-masked]> wrote:
> With even a few million such entries it would then be very easy to
> convince browser manufacturers of the use of adding support for DANE.

Nope, because it would break everyone behind a MITM SSL proxy.

AGL

-- 
Adam Langley [email-masked] http://www.imperialviolet.org

From: Henry Story <[email-masked]>
Date: Wed, 16 Feb 2011 10:17:23 +0100
To: John Gilmore <[email-masked]>
Cc: [email-masked]
Subject: [keyassure] Bootstrapping Dane Adoption

(just pursuing the conversation on a thread that with a name that is =
more=20
 related to the topic, since this has no more that much to do with =
publishing
 bare public keys )

On 15 Feb 2011, at 22:58, John Gilmore wrote in the thread archived at
http://www.ietf.org/mail-archive/web/keyassure/current/msg01810.html

>>   I can't remember if in their presentation they tell us how many =
valid self
>> signed certs they found out there...
>=20
> According to Chris Palmer of EFF, the SSL Observatory found 7 million
> self-signed certs (and 4.3 million with other certs).  But none of the
> self-signed certs were considered "valid self-signed certs" because
> the definition of "valid" was "with a valid signature chain, according
> to at least one browser", and of course browsers consider self-signed
> certs invalid.
>=20
> It appears that securing your web site with crypto is about three
> times as popular as obtaining a certificate from a certifying
> authority.
>=20
> So, providing a simple way in DNS for those 7 million web
> administrators to securely anchor their website's public keys to their
> domain names, without dealing with a certificate authority, would
> provide significant benefits to literally millions of people.

Yes.=20

It occurred to me that DNSsec providers could easily bootstrap the
adoption of Dane by pinging port 443 of their clients hosts, getting the=20=

X509 Cert if it is there, verify it is correct, and if it is self signed
add the cert or public key to the DNSsec entry.

With even a few million such entries it would then be very easy to=20
convince browser manufacturers of the use of adding support for DANE.

Henry

> 	John Gilmore

From: Matt McCutchen <[email-masked]>
To: keyassure <[email-masked]>
Date: Wed, 16 Feb 2011 00:21:05 -0500
Subject: [keyassure] Proof-of-concept implementation for NSS

Surprise!

I have a proof-of-concept implementation of DANE for NSS working against
TLSA data on mattmccutchen.net.  Firefox even runs with the modified
NSS, though it shows unverified certificate details.  Only SHA-1 hashes
of end-entity certificates are supported, following the format in
draft-ietf-dane-protocol-04.  The NSS patch, which includes
documentation, will be maintained at:

https://mattmccutchen.net/cryptid/#nss-dane

Have fun.

-- 
Matt

Date: Tue, 15 Feb 2011 17:31:18 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Yaron Sheffer <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] publishing the public key

On Tue, 15 Feb 2011, Yaron Sheffer wrote:

> Just for the record, IKEv2 does support bare public keys (though I don't 
> think they are often used).
>
> The exact RFC 5996 wording regarding the format is:
>
> "Raw RSA Key" contains a PKCS #1 encoded RSA key, that is, a DER-encoded 
> RSAPublicKey structure (see [RSA 
> <http://tools.ietf.org/html/rfc5996#ref-RSA>] and [PKCS1 
> <http://tools.ietf.org/html/rfc5996#ref-PKCS1>]).
>
>
> Yes, it's ASN.1, but it's well defined. Let's not forget that there have been 
> security vulnerabilities related to the on-the-wire format of pubic keys in 
> the past.

Openswan (IPsec for Linux) supports raw RSA keys for IKEv1 and IKEv2.

Paul

To: Henry Story <[email-masked]>
Comments: In-reply-to Henry Story <[email-masked]> message dated "Mon, 14 Feb 2011 20:07:04 +0100."
Date: Tue, 15 Feb 2011 13:58:15 -0800
From: John Gilmore <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] publishing the public key

>    I can't remember if in their presentation they tell us how many valid self
> signed certs they found out there...

According to Chris Palmer of EFF, the SSL Observatory found 7 million
self-signed certs (and 4.3 million with other certs).  But none of the
self-signed certs were considered "valid self-signed certs" because
the definition of "valid" was "with a valid signature chain, according
to at least one browser", and of course browsers consider self-signed
certs invalid.

It appears that securing your web site with crypto is about three
times as popular as obtaining a certificate from a certifying
authority.

So, providing a simple way in DNS for those 7 million web
administrators to securely anchor their website's public keys to their
domain names, without dealing with a certificate authority, would
provide significant benefits to literally millions of people.

	John Gilmore

Date: Tue, 15 Feb 2011 14:24:54 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol

Sorry to be so late in replying, but travel, vacation, etc.

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

agreed

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

buggy code exists. I don't suggest that we contort extant specs to accommodate
such code, but we also should be mindful of pervasive limitations when
developing new specs.

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

Using an AIA to locate a CA cert is exactly what we intended when that
extension was defined, to compensate for a lack of directory access/data.
i agree that AIA chasing can be evil, but it can be use for good as well :-).

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

One could do that, but it ought not be necessary.

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

agreed.

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

if DANE wants to define such an extension, and if the TLS WG agrees,
then that would be one way to address this issue.

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

agreed.

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

we disagree on the history here, but we should not pursue the discussion
on this list.

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

This is a re-statement of what I suggested in the 1997 MILCOM paper I cited
in a previous message.

Steve

Date: Tue, 15 Feb 2011 21:42:21 +0200
From: Yaron Sheffer <[email-masked]>
To: Ilari Liusvaara <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] publishing the public key

Hi Ilari,

What I had in mind was this padding attack: 
http://www.openssl.org/news/secadv_20030319.txt

Thanks,
     Yaron

On 02/15/2011 09:07 PM, Ilari Liusvaara wrote:
> On Tue, Feb 15, 2011 at 08:18:04PM +0200, Yaron Sheffer wrote:
> >
> > Yes, it's ASN.1, but it's well defined. Let's not forget that there
> > have been security vulnerabilities related to the on-the-wire format
> > of pubic keys in the past.
>
> Letting factors outside the signed blocks interfere with interpretation
> of stuff inside signature? Signed blocks with multiple interpretations?
>
> What else? Got summary of some of the issues (just for reference, quick
> googling doesn't yield anything relvant)?
>
> -Ilari

Date: Tue, 15 Feb 2011 21:07:18 +0200
From: Ilari Liusvaara <[email-masked]>
To: Yaron Sheffer <[email-masked]>
Sender: Ilari Liusvaara <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] publishing the public key

On Tue, Feb 15, 2011 at 08:18:04PM +0200, Yaron Sheffer wrote:
> 
> Yes, it's ASN.1, but it's well defined. Let's not forget that there
> have been security vulnerabilities related to the on-the-wire format
> of pubic keys in the past.

Letting factors outside the signed blocks interfere with interpretation
of stuff inside signature? Signed blocks with multiple interpretations?

What else? Got summary of some of the issues (just for reference, quick
googling doesn't yield anything relvant)?

-Ilari

Date: Tue, 15 Feb 2011 20:18:04 +0200
From: Yaron Sheffer <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] publishing the public key

Just for the record, IKEv2 does support bare public keys (though I don't 
think they are often used).

The exact RFC 5996 wording regarding the format is:

"Raw RSA Key" contains a PKCS #1 encoded RSA key, that is, a DER-encoded RSAPublicKey structure (see [RSA  <http://tools.ietf.org/html/rfc5996#ref-RSA>] and [PKCS1  <http://tools.ietf.org/html/rfc5996#ref-PKCS1>]).

Yes, it's ASN.1, but it's well defined. Let's not forget that there have 
been security vulnerabilities related to the on-the-wire format of pubic 
keys in the past.

Thanks,
     Yaron
> Message: 4
> Date: Mon, 14 Feb 2011 18:35:23 -0800
> From: Paul Hoffman<[email-masked]>
> Subject: Re: [keyassure] Issue #14 - publishing the public key
> To: [email-masked]
> Message-ID:<[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Personally, I don't see much use for bare public keys, but I hear that
> many people do, and I don't see much harm in adding them.
>
> However, if the WG wants to add them, I would want to see some wording
> for how the on-the-wire format would look. That is, you can't just put
> the bits of the public key there: you also have to say what the
> signature algorithm is and, if the algorithm requires parameters, what
> the parameters are.
>
> Any of the folks who seem most in favor of this: please suggest some
> wording here. You need to say what the format is and how the TLS client
> would compare the value gotten from the TLSA RR with the certificate
> they get in the TLS handshake.

Date: Tue, 15 Feb 2011 11:19:22 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] publishing the public key

On Tue, 15 Feb 2011, Paul Hoffman wrote:

>> So please don't call bare public key out of scope yet.
>
> Paul, saying that is ridiculous. In the message that preceded the one you 
> replied to, I actually supported bare keys as long as proponents can propose 
> wording that the WG would support on how they should be included.

Sorry, I should have been more clear. I did not mean you personally with
that statement.  I meant in general for the keyassure list to keep bare
keys under consideration when continuing to work out the DANE protocol.

Paul

Date: Tue, 15 Feb 2011 07:30:55 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] publishing the public key

On 2/14/11 9:12 PM, Paul Wouters wrote:
> On Mon, 14 Feb 2011, Paul Hoffman wrote:
>
>>> Why does TLS service have to send cert/cert chain?
>>
>> Because that is what is required by the TLS standard. We should not be
>> trying to modify the TLS spec in this WG.
>
> I understand, but there IS a relationship here. With DANE, you have an
> alternative to PKIX-TLS. So such a change would affect TLS, but would
> require DANE.

I disagree that us using bare keys for identifying TLS server 
certificates is impossible.

> Similarly, the TLS group could say "we won't add bare
> public key because there is no validation for it" and they'd send me
> back to DANE.

They could say that, but you have not even asked the TLS WG, have you?

> So please don't call bare public key out of scope yet.

Paul, saying that is ridiculous. In the message that preceded the one 
you replied to, I actually supported bare keys as long as proponents can 
propose wording that the WG would support on how they should be included.

Date: Tue, 15 Feb 2011 14:16:21 +0200
From: Ilari Liusvaara <[email-masked]>
To: Paul Wouters <[email-masked]>
Sender: Ilari Liusvaara <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] publishing the public key

On Tue, Feb 15, 2011 at 12:12:08AM -0500, Paul Wouters wrote:
> 
> I understand, but there IS a relationship here. With DANE, you have an
> alternative to PKIX-TLS. So such a change would affect TLS, but would
> require DANE. Similarly, the TLS group could say "we won't add bare
> public key because there is no validation for it" and they'd send me
> back to DANE.
> 
> So please don't call bare public key out of scope yet.

There are actual technical reasons why putting raw TLS keys in DNS
is a bad idea.

- The problems it causes with TLS library APIs.
- The problems it causes with multiple A/AAAA records.
- The problem of not being able to use the sceme for client-to-server.

You need a new TLS certtype anyway. I say it is much better way to
define new raw key TLS certtype and then assure those via DANE.

BTW: Here's one format for raw keys (no ASN.1):

General conventions:
* uint<n> is n-bit (padding by zeroes on most signficant bits of
first octet to be next multiple of an octet) big-endian number.
* poly<L> is an element of GF(2^L) given in polynomial basis
(again padding on most signficant bits of the first octet with zeroes to be
next multiple of an octet).

struct rawkey_certificate {

//TLS HashAlgorithm registry, MUST NOT be 0 (unhashed) nor 1 (MD5). SHOULD
//NOT be 2 (SHA-1).
	uint<8> tls_hash_algorithm; 

//Key type
	uint<16> key_type;

	switch(key_type)
	{
	case 0:
		//RSA
		uint<16> L_rsa_n;
		uint<16> L_rsa_e;
		uint<L_rsa_n> rsa_n;
		uint<L_rsa_e> rsa_e;
	case 1:
		//DSA
		uint<16> L_dsa_p;
		uint<8> L_dsa_q;
		uint<L_dsa_p> dsa_p;
		uint<L_dsa_p> dsa_g;
		uint<L_dsa_p> dsa_y;
		uint<L_dsa_q> dsa_q;
	case 2...20:
		//Prime ECDSA public key (see the table of curves).
		uint<L> ecdsa_Y_x;
		uint<L> ecdsa_Y_y;
	case 21...30:
		//Binary ECDSA public key (see the table of curves).
		poly<L> ecdsa_Y_x;
		poly<L> ecdsa_Y_y;
	//Other key_types to be defined.
	}
}

Constraints for certificate length (L_cert) with different keytypes:

RSA: L_cert >= 7 + ceil(L_rsa_n / 8) + ceil(L_rsa_e / 8)
DSA: L_cert >= 6 + 3 * ceil(L_dsa_p / 8) + ceil(L_dsa_q / 8)
fixed-curve ECDSA: L_cert >= 3 + 2 * ceil(L / 8).

The reason why I did not define arbitrary ECDSA curves is that PKIX forbids
those and defining full elliptic curve format is actually much more
involved than just using a slew of ready-made curves (it could be done, just
allocate a key_type for that).

I didn't do point compression because ECC points are small anyway and
unpacking those if p = 4k + 1 (like NIST P-curves have) is a bit nasty.

Table of curves:

Keytype:	Type:	L:	Curve:
--------	-----	--	------
2		Prime	192	NIST P-192
3		Prime	224	NIST P-224
4		Prime	256	NIST P-256
5		Prime	384	NIST P-384
6		Prime	521	NIST P-521
7		Prime	160	Brainpool P160r1
8		Prime	192	Brainpool P192r1
9		Prime	224	Brainpool P224r1
10		Prime	256	Brainpool P256r1
11		Prime	320	Brainpool P320r1
12		Prime	384	Brainpool P384r1
13		Prime	512	Brainpool P512r1
14		Prime	160	Brainpool P160t1
15		Prime	192	Brainpool P192t1
16		Prime	224	Brainpool P224t1
17		Prime	256	Brainpool P256t1
18		Prime	320	Brainpool P320t1
19		Prime	384	Brainpool P384t1
20		Prime	512	Brainpool P512t1
21		Binary	163	NIST B-163
22		Binary	233	NIST B-233
23		Binary	271	NIST B-271
24		Binary	409	NIST B-409
25		Binary	571	NIST B-571
26		Binary	163	NIST K-163
27		Binary	233	NIST K-233
28		Binary	271	NIST K-271
29		Binary	409	NIST K-409
30		Binary	571	NIST K-571

[1] (EC)DSA has no indication what hash type is used.

-Ilari

From: Henry Story <[email-masked]>
Date: Tue, 15 Feb 2011 12:46:34 +0100
To: Paul Wouters <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] publishing the public key

On 15 Feb 2011, at 02:35, Paul Wouters wrote:

> On Tue, 15 Feb 2011, Peter Gutmann wrote:
>=20
>>> The public key's type and raw blob will be obtained from DNSSEC, so =
this is
>>> no longer required to be conveyed to the client from the server via =
a PKIX
>>> certificate or other ASN.1 structures.
>>=20
>> But what format is the "type and raw blob" in?  You need some way of =
encoding
>> it, and if it's not the standard ASN.1 format what are you going to =
use?
>=20
> I'm not sure I understand your question. The key would encoded in DNS, =
likely in a
> format similar to DNSKEY.

Or you just put the key info in ASN.1 format (Abstract Syntax Notation =
1). ASN.1=20
is just like XML in this respect - both are syntaxes.  Instead of URIs =
for namespaces=20
they use  registered numbers. And  there is part of the X509 tree of =
information
a subtree for describing public keys. Just take that subtree. =20

I don't know where that is defined though, though I think I came across =
it last
year.

Henry

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

Social Web Architect
http://bblfish.net/

From: Henry Story <[email-masked]>
Date: Tue, 15 Feb 2011 12:32:45 +0100
To: Paul Wouters <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] publishing the public key

On 15 Feb 2011, at 03:49, Paul Wouters wrote:

> On Tue, 15 Feb 2011, Peter Gutmann wrote:

( Btw, I could not find the thread of this discussion in context, and =
this
may be reflected in my reply. It would help to point to the web archive=20=

if it's an older post that is being replied to here. )

>=20
>> A public key contains a number of components and options. For example =
for ECC
>> there are the basic key values p, a, b, G, n, h (or m, f, a, b, G, n, =
h for
>> binary curves), an indication of the underlying field (prime or =
binary), the
>> point format, whether point compression is used, polynomial vs. =
normal basis,
>> whether fixed domain parameters are used, and probably some other =
stuff I've
>> forgotten.  How is all this stuff communicated?
>=20
> I see.

At the simplest, can one not just take the  public key part of the ASN.1 =
that comes in an X.509 certificate, and pop that DER encoded in the yet =
to be named value field?=20

Pro: it clearly is defined
Con: there is a bit of remaining ASN.1, but it's a lot less than before =
:-)

At least that shows that there is one easy solution.=20

>=20
>> this (a) ain't gonna cut it because it doesn't cover what's required =
by TLS
>> and (b) requires that your TLS implementation speak DNSSEC (or at =
least the
>> DNSKEY part of DNSSEC) just to get a key. I can't see TLS =
implementors being
>> too enthusiastic about this.
>=20
> Okay.

Assuming this discussion is about publishing a public key in DNSSEC - =
let's not
care about the format - I would reply the following

(a) not sure why this answer was made
(b) Using the public key published in DNSSEC does not require that the =
TLS=20
implementation speak DNSSEC. Current browsers that deal with millions of =
self
signed certificates on the internet will show ugly dialogs as they do =
now.
But future browser that are DNSSEC aware could use keyassure to give a =
better
dialog. They might not get EV certificate dialog, but at least they will =
know that
they have connected to the correct service.

They can do (b) whether the certificate is published in DNSSEC or =
whether the
public key is published there. It does not matter. After all the =
certificate contains
the public key, plus extra information.

Henry

>=20
> I'll have to do some more reading to ensure I understand everything, =
and I'll
> write up something for this for you to check.
>=20
> Thanks!
>=20
> Paul
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Social Web Architect
http://bblfish.net/

Date: Tue, 15 Feb 2011 00:12:08 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] publishing the public key

On Mon, 14 Feb 2011, Paul Hoffman wrote:

>> Why does TLS service have to send cert/cert chain?
>
> Because that is what is required by the TLS standard. We should not be trying 
> to modify the TLS spec in this WG.

I understand, but there IS a relationship here. With DANE, you have an
alternative to PKIX-TLS. So such a change would affect TLS, but would
require DANE. Similarly, the TLS group could say "we won't add bare
public key because there is no validation for it" and they'd send me
back to DANE.

So please don't call bare public key out of scope yet.

Paul

Date: Mon, 14 Feb 2011 19:25:39 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] publishing the public key

On 2/14/11 6:46 PM, Paul Wouters wrote:
> Why does TLS service have to send cert/cert chain?

Because that is what is required by the TLS standard. We should not be 
trying to modify the TLS spec in this WG.

Date: Mon, 14 Feb 2011 21:49:47 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Peter Gutmann <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] publishing the public key

On Tue, 15 Feb 2011, Peter Gutmann wrote:

> A public key contains a number of components and options. For example for ECC
> there are the basic key values p, a, b, G, n, h (or m, f, a, b, G, n, h for
> binary curves), an indication of the underlying field (prime or binary), the
> point format, whether point compression is used, polynomial vs. normal basis,
> whether fixed domain parameters are used, and probably some other stuff I've
> forgotten.  How is all this stuff communicated?

I see.

> this (a) ain't gonna cut it because it doesn't cover what's required by TLS
> and (b) requires that your TLS implementation speak DNSSEC (or at least the
> DNSKEY part of DNSSEC) just to get a key. I can't see TLS implementors being
> too enthusiastic about this.

Okay.

I'll have to do some more reading to ensure I understand everything, and I'll
write up something for this for you to check.

Thanks!

Paul

Date: Mon, 14 Feb 2011 21:46:26 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Scott Schmit <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] publishing the public key

On Mon, 14 Feb 2011, Scott Schmit wrote:

> <snip bandwidth considerations, etc>
>
> People keep saying that, but I don't think it's true. This is always an
> option:
>
> In some order:
> * Client looks up bare key in DNS
> * Client connects to TLS service, TLS service sends cert/cert chain

Why does TLS service have to send cert/cert chain? The client already has
all it needs to know, the bare public key and the DNSSEC validation asserting
the key is validated for use.

> Then, instead of comparing the key/hash of key to the whole cert, the
> client picks out the public key and compares them (or their hashes).  If
> they match, use the cert as before.

the problem is if cert now contains a CN=www.paypal.com. Browser vendors do
not want to ever display information that has no been validated, and for
DANE public keys, none of the certificate is validated. This is why its
better not to drag in these things to begin with.

> There are problems with this approach, but I'd rather the conversation
> not stop with "it's impossible to put bare keys in DNS until TLS
> supports it directly!" Instead, I'd prefer we discuss the problems that
> a bare key approach would need to deal with. I suspect most of them are
> at least related to the question of what cert fields to pay attention
> to.

I'd be in favour of this, though I also understand people don't want to add
types for vapourware.

> Some issues that would need to be understood/resolved:
> * the bare key doesn't tell you anything about the algorithm it's for
> (or how to interpret it, really)

The RRTYPE would need to tell you. Currently, we only have the "hash type"
(section 2.2) though that could perhaps be expanded to also contain the public key type.
Or alternatively, we add another field similar to how DNSKEY describes the
key algorithm (and possibly using the same values)

> * a hacker could potentially alter the certificate in some unexpected
> way (usually only affects EE certs if the TA certs are well-protected)
> from what the service owner expected -- whether this matters depends on
> what you were getting out of the other cert fields.

This is why "bare public key" has no PKIX container.

Paul

Date: Mon, 14 Feb 2011 18:35:23 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Issue #14 - publishing the public key

Personally, I don't see much use for bare public keys, but I hear that 
many people do, and I don't see much harm in adding them.

However, if the WG wants to add them, I would want to see some wording 
for how the on-the-wire format would look. That is, you can't just put 
the bits of the public key there: you also have to say what the 
signature algorithm is and, if the algorithm requires parameters, what 
the parameters are.

Any of the folks who seem most in favor of this: please suggest some 
wording here. You need to say what the format is and how the TLS client 
would compare the value gotten from the TLSA RR with the certificate 
they get in the TLS handshake.

--Paul Hoffman

From: Warren Kumari <[email-masked]>
Date: Mon, 14 Feb 2011 21:26:14 -0500
To: [email-masked]
Subject: Re: [keyassure] Issue #14 - publishing the public key

[ Subject updated to include the issue number - apologies if this makes =
your MUA crazy. ]=20

We have this particular item listed as an issue in the issue tracker so =
I figured that we might as well keep track of the progress we are making =
on this, so let's discuss it an issue and figure out how / what we would =
like to do about it[0]... (Also known as, issue #14 is officially open =
:-))

W

[0]: Yes, I realize that we are already discussing it, but I'm trying =
hard to use the issue tracker to actually work through the open issues, =
track what we are deciding, etc. I have seen it being used very =
effectively, especially to help newcomers understand what has been =
discussed and what has been decided.

On Feb 14, 2011, at 8:35 PM, Paul Wouters wrote:

> On Tue, 15 Feb 2011, Peter Gutmann wrote:
>=20
>>> The public key's type and raw blob will be obtained from DNSSEC, so =
this is
>>> no longer required to be conveyed to the client from the server via =
a PKIX
>>> certificate or other ASN.1 structures.
>>=20
>> But what format is the "type and raw blob" in?  You need some way of =
encoding
>> it, and if it's not the standard ASN.1 format what are you going to =
use?
>=20
> I'm not sure I understand your question. The key would encoded in DNS, =
likely in a
> format similar to DNSKEY.
>=20
> Paul
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>=20

Date: Mon, 14 Feb 2011 21:21:03 -0500
From: Scott Schmit <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [keyassure] publishing the public key

On Mon, Feb 14, 2011 at 02:46:17PM +0200, Ilari Liusvaara wrote keyassure:
> On Mon, Feb 14, 2011 at 11:20:33AM +0100, Henry Story wrote:
> > Hi,
> > 
> > In draft-dane-04 [1] one can currently only publish either a signature
> > or a certificate in the DNS. That is the only allowed formats of the
> > resource record are as specified in section 2.2
> > 
> >   1 -- Hash of an end-entity certificate
> >   2 -- Full end-entity certificate in DER encoding
> >   3 -- Hash of an certification authority's certificate
> >   4 -- Full certification authority's certificate in DER encoding
> > 
> > Why not publish the only piece of the certificate that is important in
> > public key cryptography: the public key. ( This is what WebID does
> > currently ) This should be shorter than the certificate, and though it
> > will be longer than the signature, it will be a lot more useful, tying
> > the publisher much less to a particular serialisation format. So you
> > reduce the PGP/X509 disagreements.
> 
> Unfortunately TLS requires sending the full certificate. Yes, one could
> define a new certificate type that contained just the public key, but
> that would require a IETF consensus (RFC through TLS working
> group[1]).
> 
<snip bandwidth considerations, etc>

People keep saying that, but I don't think it's true. This is always an
option:

In some order:
* Client looks up bare key in DNS
* Client connects to TLS service, TLS service sends cert/cert chain

Then, instead of comparing the key/hash of key to the whole cert, the
client picks out the public key and compares them (or their hashes).  If
they match, use the cert as before.

If later the TLS WG develops a bare key option to TLS, this should
transparently support that (the processing changes, but otherwise, it's
the same).

There are problems with this approach, but I'd rather the conversation
not stop with "it's impossible to put bare keys in DNS until TLS
supports it directly!" Instead, I'd prefer we discuss the problems that
a bare key approach would need to deal with. I suspect most of them are
at least related to the question of what cert fields to pay attention
to.

Some issues that would need to be understood/resolved:
* the bare key doesn't tell you anything about the algorithm it's for
(or how to interpret it, really)
* a hacker could potentially alter the certificate in some unexpected
way (usually only affects EE certs if the TA certs are well-protected)
from what the service owner expected -- whether this matters depends on
what you were getting out of the other cert fields.

Date: Mon, 14 Feb 2011 20:35:16 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Peter Gutmann <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] publishing the public key

On Tue, 15 Feb 2011, Peter Gutmann wrote:

>> The public key's type and raw blob will be obtained from DNSSEC, so this is
>> no longer required to be conveyed to the client from the server via a PKIX
>> certificate or other ASN.1 structures.
>
> But what format is the "type and raw blob" in?  You need some way of encoding
> it, and if it's not the standard ASN.1 format what are you going to use?

I'm not sure I understand your question. The key would encoded in DNS, likely in a
format similar to DNSKEY.

Paul

From: Henry Story <[email-masked]>
Date: Mon, 14 Feb 2011 20:07:04 +0100
To: [email-masked]
Cc: [email-masked]
Subject: Re: [keyassure] publishing the public key

On 14 Feb 2011, at 19:29, Martin Rex wrote:

> Henry Story wrote:
>>=20
>>> The current approach of admins to run a TLS server with a bare =
public
>>> key is to generate themselves a self-signed (X.509v1) Certificate.
>>> That is probably what many folks are doing when protecting Web =
access to
>>> their HomeNAS, Home DSL-router, Home DVB-s receiver, etc.
>>>=20
>>> This works with the installed base, in particular with the installed
>>> base of servers.  Though it doesn't work that well with Web Browsers
>>> as clients.  In particular, many recent browers are pretty badly =
broken
>>> when it comes to a sensible UI for servers using a self-signed cert.
>>=20
>> Indeed, and this is why keyassure is going to be so useful for those =
people.=20
>> They must just be itching to pop their public keys in DNSSEC as soon =
as the=20
>> first browser vendors implement it. So you are guaranteed a large =
community
>> to spread the word and give you feedback. And I think Browser Vendors =
will
>> be very keen to implement this, as well as DNSSEC of course, given =
the
>> terrible state of DNS.

I was thinking of the issue brought up by the EFF SSL Observatory =
project,=20
that they presented at the Choas Communication Congress in Berlin right
after Christmas 2010 in a talk entitled "Is the SSLiverse a safe place?"

    https://events.ccc.de/congress/2010/Fahrplan/events/4121.en.html

And you can get video on youtube. In particular if you look at slide 10 =
(of 56)
=20
    =
http://www.youtube.com/watch?v=3DVUKCDm04AqI&feature=3Dplayer_detailpage#t=
=3D631s

They point out that of the 16.2 Million servers listening to port 443 , =
only 11.3 Million
started an SSL handshake, and only 4.3 Million had a valid cert chain. =
So that means that
there are immediately 7 Million servers which could be helped if getting =
an SSL certificate
could be made a lot easier. And this is not counting how many others =
would start deploying
SSL if it was easier to do.

   I can't remember if in their presentation they tell us how many valid =
self
signed certs they found out there... One couls download the DB you query =
it locally...

> Not at all.  The average Home user (private home DSL subscriber) is
> not a DNS admin, let alone a DNSSEC admin.  So for accessing the =
Web-UIs
> Home devices/equipment/gadgets, DANE will be mostly irrelevant.

Ah you mean for accessing the SSL protected internal servers....

>=20
> But maybe some of the Browser maintainers fix their UIs and start
> to distinguish direct access to local resources on private networks
> (such as 192.169.x.x and 10.x.x.x and hostnames without domains =
attached)
> from access to resources on the internet.  And stop behaving like =
nagware
> for commercial CAs.

I see what you are getting at...

Interesting thought. It's tricky as to how one should do that correctly =
without there
being a danger in large organisations of people putting up evil SSL =
proxies.

Perhaps the following could work. Imagine that these devices come =
shipping with DNSSEC servers that work internally  to resolve those =
addresses, and which use keyassure to publish the public key... Perhaps  =
there is something at the DNSSEC level that can be done there...?=20

Henry

>=20
> -Martin

Social Web Architect
http://bblfish.net/

From: Martin Rex <[email-masked]>
To: [email-masked] (Henry Story)
Date: Mon, 14 Feb 2011 19:29:20 +0100 (MET)
Cc: [email-masked]
Subject: Re: [keyassure] publishing the public key
Reply-To: [email-masked]

Henry Story wrote:
> 
> > The current approach of admins to run a TLS server with a bare public
> > key is to generate themselves a self-signed (X.509v1) Certificate.
> > That is probably what many folks are doing when protecting Web access to
> > their HomeNAS, Home DSL-router, Home DVB-s receiver, etc.
> > 
> > This works with the installed base, in particular with the installed
> > base of servers.  Though it doesn't work that well with Web Browsers
> > as clients.  In particular, many recent browers are pretty badly broken
> > when it comes to a sensible UI for servers using a self-signed cert.
> 
> Indeed, and this is why keyassure is going to be so useful for those people. 
> They must just be itching to pop their public keys in DNSSEC as soon as the 
> first browser vendors implement it. So you are guaranteed a large community
> to spread the word and give you feedback. And I think Browser Vendors will
> be very keen to implement this, as well as DNSSEC of course, given the
> terrible state of DNS.

Not at all.  The average Home user (private home DSL subscriber) is
not a DNS admin, let alone a DNSSEC admin.  So for accessing the Web-UIs
Home devices/equipment/gadgets, DANE will be mostly irrelevant.

But maybe some of the Browser maintainers fix their UIs and start
to distinguish direct access to local resources on private networks
(such as 192.169.x.x and 10.x.x.x and hostnames without domains attached)
from access to resources on the internet.  And stop behaving like nagware
for commercial CAs.

-Martin

From: Henry Story <[email-masked]>
Date: Mon, 14 Feb 2011 18:59:33 +0100
To: [email-masked]
Cc: [email-masked]
Subject: Re: [keyassure] publishing the public key

On 14 Feb 2011, at 18:33, Martin Rex wrote:

> Paul Wouters wrote:
>>=20
>> On Mon, 14 Feb 2011, Henry Story wrote:
>>>=20
>>> Why not publish the only piece of the certificate that is important
>>> in public key cryptography: the public key.
>>=20
>> Yes. This was asked by others including me as well. People thought it =
would
>> be no problem to add this to dane once a bare public key TLS method =
exists.
>>=20
>>>  An important question is of course: how much bandwidth does one =
save?
>>=20
>> Bandwidth does not really matter. What matters is latency
>> (less round trips) and a riddance of ASN.1 parsing.
>=20
> The current approach of admins to run a TLS server with a bare public
> key is to generate themselves a self-signed (X.509v1) Certificate.
> That is probably what many folks are doing when protecting Web access =
to
> their HomeNAS, Home DSL-router, Home DVB-s receiver, etc.
>=20
> This works with the installed base, in particular with the installed
> base of servers.  Though it doesn't work that well with Web Browsers
> as clients.  In particular, many recent browers are pretty badly =
broken
> when it comes to a sensible UI for servers using a self-signed cert.

Indeed, and this is why keyassure is going to be so useful for those =
people.=20
They must just be itching to pop their public keys in DNSSEC as soon as =
the=20
first browser vendors implement it. So you are guaranteed a large =
community
to spread the word and give you feedback. And I think Browser Vendors =
will be
very keen to implement this, as well as DNSSEC of course, given the =
terrible state
of DNS.

=46rom WebID's perspective we love keyassure, because it will make =
deployment of https=20
so much easier, and so make it much easier to create the Secure =
Decentralised=20
Social Web which we want to build.  In fact we have an issue open there =
to follow=20
your work here

 http://www.w3.org/2005/Incubator/webid/track/issues/5

It also permits "Turning every Web Server into a CA"
http://lists.w3.org/Archives/Public/public-xg-webid/2011Feb/0060.html

which is pretty cool I think.

 So all of the above will work as keyassure is written out now, but I do=20=

think that if one can reduce the bandwidth used by DNSSEC as much as =
possible
as well as get the best value for the bits used - which I think the =
public key
does - all the better. That will reduce the talk of DNS as a Denial of =
Serice=20
Attack amplifier.

	Henry

>=20
> -Martin

Social Web Architect
http://bblfish.net/

From: Martin Rex <[email-masked]>
To: [email-masked] (Paul Wouters)
Date: Mon, 14 Feb 2011 18:33:15 +0100 (MET)
Cc: [email-masked]
Subject: Re: [keyassure] publishing the public key
Reply-To: [email-masked]

Paul Wouters wrote:
> 
> On Mon, 14 Feb 2011, Henry Story wrote:
> >
> > Why not publish the only piece of the certificate that is important
> > in public key cryptography: the public key.
>
> Yes. This was asked by others including me as well. People thought it would
> be no problem to add this to dane once a bare public key TLS method exists.
> 
> >   An important question is of course: how much bandwidth does one save?
> 
> Bandwidth does not really matter. What matters is latency
> (less round trips) and a riddance of ASN.1 parsing.

The current approach of admins to run a TLS server with a bare public
key is to generate themselves a self-signed (X.509v1) Certificate.
That is probably what many folks are doing when protecting Web access to
their HomeNAS, Home DSL-router, Home DVB-s receiver, etc.

This works with the installed base, in particular with the installed
base of servers.  Though it doesn't work that well with Web Browsers
as clients.  In particular, many recent browers are pretty badly broken
when it comes to a sensible UI for servers using a self-signed cert.

-Martin

Date: Mon, 14 Feb 2011 11:37:43 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Peter Gutmann <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] publishing the public key

On Tue, 15 Feb 2011, Peter Gutmann wrote:

>> If you want to help writing a bare public key TLS variant, please contact me.
>
> There is no such thing as a "bare public key".  Public keys have complex
> composite structures, and to encode that you need something like ASN.1 (unless
> you want to invent your own format, which is going to make things even
> uglier).  At this point you're duplicating a significant chunk of ASN.1-
> parsing code outside the certificate code that would normally handle it.  This
> does not seem like a good direction to go in.

The public key's type and raw blob will be obtained from DNSSEC, so
this is no longer required to be conveyed to the client from the server
via a PKIX certificate or other ASN.1 structures. No other certificate
information is desired.

Perhaps some other mode is required if the client needs to be
authenticated by the server, but the use we are talking about here is
for unauthenticated clients, eg the currently deployed "https" mode
without user certs/credentials.

Paul

From: "dane issue tracker" <[email-masked]>
Auto-Submitted: auto-generated
To: [email-masked]
Date: Mon, 14 Feb 2011 15:30:20 -0000
Cc: [email-masked]
Subject: Re: [keyassure] [dane] protocol #14 (new): Bare Public Keys

#14: Bare Public Keys

Comment(by henry.story@…):

 There is also a longer thread from Febuary 14th 2011 on the subject
 [http://www.ietf.org/mail-archive/web/keyassure/current/msg01780.html
 publishing the public key]

-- 
--------------------------------+-------------------------------------------
 Reporter:  mlepinsk@…          |       Owner:     
     Type:  defect              |      Status:  new
 Priority:  minor               |   Milestone:     
Component:  protocol            |     Version:     
 Severity:  Active WG Document  |    Keywords:     
--------------------------------+-------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/dane/trac/ticket/14#comment:1>
dane <http://tools.ietf.org/dane/>

Date: Mon, 14 Feb 2011 07:24:23 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] publishing the public key

On 2/14/11 6:54 AM, Henry Story wrote:
> Sorry. I don't have a good picture of the web of specs that dane is tied into.

Please read the TLSA document. It is "tied" to TLS and DTLS only.

Date: Mon, 14 Feb 2011 07:17:55 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] publishing the public key

On 2/14/11 2:20 AM, Henry Story wrote:
> Why not publish the only piece of the certificate that is important
> in public key cryptography: the public key.

There is an open issue for this question. See #14 in 
<http://trac.tools.ietf.org/wg/dane/trac/report/1>. When the chairs want 
to open that for discussion, there will certainly be lots of opinions on it.

From: Henry Story <[email-masked]>
Date: Mon, 14 Feb 2011 15:54:57 +0100
To: [email-masked]
Subject: Re: [keyassure] publishing the public key

On 14 Feb 2011, at 15:19, Paul Wouters wrote:

> On Mon, 14 Feb 2011, Henry Story wrote:
>=20
>> In draft-dane-04 [1] one can currently only publish either a =
signature or a certificate in the DNS. That is the only allowed formats =
of the resource record are as specified in section 2.2
>>=20
>> 1 -- Hash of an end-entity certificate
>> 2 -- Full end-entity certificate in DER encoding
>> 3 -- Hash of an certification authority's certificate
>> 4 -- Full certification authority's certificate in DER encoding
>>=20
>> Why not publish the only piece of the certificate that is important =
in public key cryptography: the public key. ( This is what WebID does =
currently ) This should be shorter than the certificate, and though it =
will be longer than the signature, it will be a lot more useful, tying =
the publisher much less to a particular serialisation format. So you =
reduce the PGP/X509 disagreements.
>=20
> Yes. This was asked by others including me as well. People thought it =
would be no
> problem to add this to dane once a bare public key TLS method exists.
>=20
>>  An important question is of course: how much bandwidth does one =
save?
>=20
> Bandwidth does not really matter. What matters is latency (less round =
trips) and a riddance of ASN.1
> parsing.
>=20
> If you want to help writing a bare public key TLS variant, please =
contact me.

What do you mean by a bare public key TLS variant? You mean start an =
IETF group
to spec out how the client and the server should communicate in a TLS =
variant
that would not require the server to send a certificate? Or is this =
something that
one needs to do to explain how a User Agent can prove authenticity of =
the server from
a public key alone? (That's so simple it's a bit difficult to even see =
how to write it)
Or is it just that one needs to specify text for dane? Or is dane a =
subproject of=20
keyassure, and this is referring to some other project here? Or is do
we just need to specify some text that is going to go into dane?

Sorry. I don't have a good picture of the web of specs that dane is tied =
into.

If its longer project I probably won't have time to do this myself as I =
am already=20
quite tied up with WebID. But if I know what is needed we could write up =
a little=20
note on the W3C WebID Incubator Group ( http://tinyurl.com/webidxg ) for =
our final=20
report on what browser improvements would be helpful, and why. Hopefully =
this will=20
be something that the browser vendors at the W3C could have a closer =
look at. But
it really depends on how long the project is. Perhaps there are people =
on our list who
have more time to participate. Perhaps this won't take so long to do...

	Henry

>=20
> Paul

Social Web Architect
http://bblfish.net/

Date: Mon, 14 Feb 2011 09:19:32 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Henry Story <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] publishing the public key

On Mon, 14 Feb 2011, Henry Story wrote:

>  In draft-dane-04 [1] one can currently only publish either a signature or a certificate in the DNS. That is the only allowed formats of the resource record are as specified in section 2.2
>
>  1 -- Hash of an end-entity certificate
>  2 -- Full end-entity certificate in DER encoding
>  3 -- Hash of an certification authority's certificate
>  4 -- Full certification authority's certificate in DER encoding
>
> Why not publish the only piece of the certificate that is important in public key cryptography: the public key. ( This is what WebID does currently ) This should be shorter than the certificate, and though it will be longer than the signature, it will be a lot more useful, tying the publisher much less to a particular serialisation format. So you reduce the PGP/X509 disagreements.

Yes. This was asked by others including me as well. People thought it would be no
problem to add this to dane once a bare public key TLS method exists.

>   An important question is of course: how much bandwidth does one save?

Bandwidth does not really matter. What matters is latency (less round trips) and a riddance of ASN.1
parsing.

If you want to help writing a bare public key TLS variant, please contact me.

Paul

From: Henry Story <[email-masked]>
Date: Mon, 14 Feb 2011 15:02:18 +0100
To: Ilari Liusvaara <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] publishing the public key

On 14 Feb 2011, at 13:46, Ilari Liusvaara wrote:

> On Mon, Feb 14, 2011 at 11:20:33AM +0100, Henry Story wrote:
>> Hi,
>>=20
>> In draft-dane-04 [1] one can currently only publish either a =
signature
>> or a certificate in the DNS. That is the only allowed formats of the
>> resource record are as specified in section 2.2
>>=20
>>  1 -- Hash of an end-entity certificate
>>  2 -- Full end-entity certificate in DER encoding
>>  3 -- Hash of an certification authority's certificate
>>  4 -- Full certification authority's certificate in DER encoding
>>=20
>> Why not publish the only piece of the certificate that is important =
in
>> public key cryptography: the public key. ( This is what WebID does
>> currently ) This should be shorter than the certificate, and though =
it
>> will be longer than the signature, it will be a lot more useful, =
tying
>> the publisher much less to a particular serialisation format. So you
>> reduce the PGP/X509 disagreements.
>=20
> Unfortunately TLS requires sending the full certificate. Yes, one =
could
> define a new certificate type that contained just the public key, but
> that would require a IETF consensus (RFC through TLS working
> group[1]).

As you certainly know, but as you don't know what I know let me be =
specific,
TLS does not currently make any claims as to what should be published=20
in  DNS. In fact TLS requires(?) that the client will look to see if it =
can=20
build a chain of certificates from the server cert  to a  trusted=20
Certificate Authority (CA), and show that the CA authenticates each =
element
in the chain.
=20
keyassure (or is it dane?) will, as I understand, allow another way for =
trust=20
to be established by tying the identity of the server to DNS, rather =
than=20
(or in addition to) tying it to a CA.=20

So a User Agent (UA) that is keyassure enabled connecting to a TLS =
server =20
should receive as all UAs now do an X509 certificate. What will be =
unusual is
that this certificate could be self-signed.=20

In the TLS negotiation the UA will have proof that the server knows the =
private=20
key of the public key sent in the certificate, following existing TLS =
specs. But=20
since the Certificate will be self signed the UA will not be able to get =
confirmation
from a CA that the service that knows that private key is the service =
that has
global identity alice.example:443 . An evil agent known as Eve could =
have create a=20
public/private key pair and generate a self signed  certificate =
asserting that it=20
is the certificate of service alice.example:443 but place that on the =
server she
likes to think of as eve.example:443 .

So what do we really need? We just need a trusted service to tell us =
that=20
alice.example:443 is indeed the knower of the given private key. DNS is =
of course the=20
perfect place to get that information, especially when the information =
can be trusted.
So what we need is DNS to say the following:

<srv:alice.example:443> knowsPrivateKeyOfPublicKey [ a RSAPublicKey; ... =
] .

Once that is said, all is said.

My point after that is that so much is said there, that the server would =
not even
need to send the certificate anymore (saving yet more bandwidth)

> Then one would define new DANE ceritifcate type (3 [2] or 5/6) to
> match that.

ok, so it is possible to do it.=20
But I think one should investigate a bit more if one cannot get =
consensus that
one does not really needs anything more than the public key. After all =
this is
public key cryptography we are using!

>=20
> <snip idea of certificate URLs>
>=20
> I don't think that would be possible to use without new certificate
> type either.

I think you could just use the ASN.1 public key object, and DER encode
it. I think that is even specified somewhere. But ok, if the certificate=20=

type is important... Note that the object does not even have to be =
signed
(DNSSEC signs things)

> As for bandwidth, sure it would save some. One can send well-secured
> key in roughly 80 bytes total (including CertificateType extension).
> Modern X.509 certs are far larger[3], even if restricted to bare
> minimum fields.

The important calculation would have to be: how many packets does one =
save
when sending:

  - a hash of an entity certificate
  - a public key only
  - a pretty minimal certificate
  - a usual key=20
=20
And here one would need two figures:=20
  a the size of the information
  b the size after the DNSSEC wrappers that have to be added to the =
message.

Where the second size is more important of course

> As for what this would be useful for: If the raw key format would
> be easily parsed, it would save lots of tricky ASN.1 and X.509
> parsing (yes, there are libraries for that)

Indeed. That is partly what my thought experiment was getting at: you=20
could even remove the ASN.1 from the server, by not having it send =
server
certs. Though perhaps to bring this up here is to risk confusing issues.

>=20
> [1] Not entierely accurate, it is RFC approved by IESG (and they'll
> consult TLS WG).
>=20
> [2] Since those 4 types could be collapsed to 2 (2 of those require
> second byte to be zero and 2 require nonzero second byte)
>=20
> [3] There's also subtle performance issue there. Those certificates
> can be so large that TCP windows get overflowed. As consequence,
> either one has to break TCP spec (many sites do this) or suffer
> a latency hit.
>=20
> -Ilari

Social Web Architect
http://bblfish.net/

Date: Mon, 14 Feb 2011 14:46:17 +0200
From: Ilari Liusvaara <[email-masked]>
To: Henry Story <[email-masked]>
Sender: Ilari Liusvaara <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] publishing the public key

On Mon, Feb 14, 2011 at 11:20:33AM +0100, Henry Story wrote:
> Hi,
> 
> In draft-dane-04 [1] one can currently only publish either a signature
> or a certificate in the DNS. That is the only allowed formats of the
> resource record are as specified in section 2.2
> 
>   1 -- Hash of an end-entity certificate
>   2 -- Full end-entity certificate in DER encoding
>   3 -- Hash of an certification authority's certificate
>   4 -- Full certification authority's certificate in DER encoding
> 
> Why not publish the only piece of the certificate that is important in
> public key cryptography: the public key. ( This is what WebID does
> currently ) This should be shorter than the certificate, and though it
> will be longer than the signature, it will be a lot more useful, tying
> the publisher much less to a particular serialisation format. So you
> reduce the PGP/X509 disagreements.

Unfortunately TLS requires sending the full certificate. Yes, one could
define a new certificate type that contained just the public key, but
that would require a IETF consensus (RFC through TLS working
group[1]).

Then one would define new DANE ceritifcate type (3 [2] or 5/6) to
match that.

<snip idea of certificate URLs>

I don't think that would be possible to use without new certificate
type either.

As for bandwidth, sure it would save some. One can send well-secured
key in roughly 80 bytes total (including CertificateType extension).
Modern X.509 certs are far larger[3], even if restricted to bare
minimum fields.

As for what this would be useful for: If the raw key format would
be easily parsed, it would save lots of tricky ASN.1 and X.509
parsing (yes, there are libraries for that)

[1] Not entierely accurate, it is RFC approved by IESG (and they'll
consult TLS WG).

[2] Since those 4 types could be collapsed to 2 (2 of those require
second byte to be zero and 2 require nonzero second byte)

[3] There's also subtle performance issue there. Those certificates
can be so large that TCP windows get overflowed. As consequence,
either one has to break TCP spec (many sites do this) or suffer
a latency hit.

-Ilari

From: Henry Story <[email-masked]>
Date: Mon, 14 Feb 2011 11:20:33 +0100
To: [email-masked]
Subject: [keyassure] publishing the public key

Hi,

  In draft-dane-04 [1] one can currently only publish either a signature =
or a certificate in the DNS. That is the only allowed formats of the =
resource record are as specified in section 2.2

  1 -- Hash of an end-entity certificate
  2 -- Full end-entity certificate in DER encoding
  3 -- Hash of an certification authority's certificate
  4 -- Full certification authority's certificate in DER encoding

Why not publish the only piece of the certificate that is important in =
public key cryptography: the public key. ( This is what WebID does =
currently ) This should be shorter than the certificate, and though it =
will be longer than the signature, it will be a lot more useful, tying =
the publisher much less to a particular serialisation format. So you =
reduce the PGP/X509 disagreements.

There is no need to send a full certificate. Many users will only need =
to tie a name to a public key and to have a guarantee of the integrity =
of the information. But the integrity is itself assured by DNSSEC. The =
tying of the name to the public key is done by the lookup in DNS, as =
with eg: _443._tcp.www.example.com ) So all that is really required is =
to return the public key - the type (RSA, DSA, ...) and the fields. This =
can be done in ASN.1.

  The following use case may help: Imagine a future revision of TLS, =
which permits the server to not send the server certificate, a bit as =
the client_certificate_url extension of TLS 1.2 allows the client to =
send a URL to a location of his certificate, instead of sending his =
certificate in order to save bandwidth. Here the server just tells the =
client to look up his public key in DNSSEC .  This would then save =
bandwidth at both ends: the server would not need to send his =
certificate and DNSSEC would just send the minimal information needed to =
confirm.=20

   The public key by itself would not be able to contain the types of =
restrictions on usage of the key of course: only use for signing, ... =
that are available in X509.=20

   An important question is of course: how much bandwidth does one save?

Henry

[1] http://tools.ietf.org/html/draft-ietf-dane-protocol-04

Social Web Architect
http://bblfish.net/

Date: Sun, 13 Feb 2011 18:53:47 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Matt McCutchen <[email-masked]>
Cc: keyassure <[email-masked]>
Subject: Re: [keyassure] Binding to full TLS encapsulation or STARTTLS

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

That openeth a can of worms.

While it would be nice to be able to simply open a TLS session rather than
start raw and negotiate an upgrade, that is hard to support on the server
side unless the server has separate port assignments for raw and TLS
service.

That works for HTTP, NNTP and a few others. But the IAB and IESG clamped
down on dual port assignments and so that scheme only works in some cases.

HTTPS is not quite the same thing as HTTP with inband upgrade to SSL.

I am not even sure how widely supported the inband upgrade is for HTTP.

Not trying to be difficult here, I have really no good scheme for fixing
this.

On Sun, Feb 13, 2011 at 1:15 PM, Matt McCutchen <[email-masked]>wrote:

> I realized that TLSA as we are currently discussing does not bind keys
> to the use of full TLS encapsulation or STARTTLS.  I'm thinking this is
> OK because it would be pretty ridiculous to multiplex different services
> based on the use of full encapsulation or STARTTLS, and clients
> generally do not ascribe security significance to the use of one or the
> other.  E.g., if I bind a key to _3141._tcp.example.com for a service
> that uses STARTTLS, I can't think of any scenario in which a client
> trying to use full encapsulation would be harmed if a MITM allowed it to
> succeed by performing the STARTTLS part directly with the server.  It
> might be nice to prevent web browsers from talking to STARTTLS services,
> but that would be far from a complete solution to the problem of
> browsers being a loose cannon for arbitrary connections, nor is it our
> responsibility to solve that problem here.
>
> Sanity check?
>
> --
> Matt
>
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

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

That openeth a can of worms.<div><br></div><div>While it would be nice to b=
e able to simply open a TLS session rather than start raw and negotiate an =
upgrade, that is hard to support on the server side unless the server has s=
eparate port assignments for raw and TLS service.</div>
<div><br></div><div>That works for HTTP, NNTP and a few others. But the IAB=
 and IESG clamped down on dual port assignments and so that scheme only wor=
ks in some cases.</div><div><br></div><div><br></div><div>HTTPS is not quit=
e the same thing as HTTP with inband upgrade to SSL.</div>
<div><br></div><div>I am not even sure how widely supported the inband upgr=
ade is for HTTP.</div><div><br></div><div><br></div><div>Not trying to be d=
ifficult here, I have really no good scheme for fixing this.<br><br><div cl=
ass=3D"gmail_quote">
On Sun, Feb 13, 2011 at 1:15 PM, Matt McCutchen <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:[email-masked]">[email-masked]</a>&gt;</span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex;">
I realized that TLSA as we are currently discussing does not bind keys<br>
to the use of full TLS encapsulation or STARTTLS. =A0I&#39;m thinking this =
is<br>
OK because it would be pretty ridiculous to multiplex different services<br=
>
based on the use of full encapsulation or STARTTLS, and clients<br>
generally do not ascribe security significance to the use of one or the<br>
other. =A0E.g., if I bind a key to _3141._<a href=3D"http://tcp.example.com=
" target=3D"_blank">tcp.example.com</a> for a service<br>
that uses STARTTLS, I can&#39;t think of any scenario in which a client<br>
trying to use full encapsulation would be harmed if a MITM allowed it to<br=
>
succeed by performing the STARTTLS part directly with the server. =A0It<br>
might be nice to prevent web browsers from talking to STARTTLS services,<br=
>
but that would be far from a complete solution to the problem of<br>
browsers being a loose cannon for arbitrary connections, nor is it our<br>
responsibility to solve that problem here.<br>
<br>
Sanity check?<br>
<font color=3D"#888888"><br>
--<br>
Matt<br>
<br>
<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>
</font></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a href=
=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--001485f6d1ae6db88c049c32a49e--

Date: Sun, 13 Feb 2011 15:49:43 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] dane-04 trust anchors

On 2/13/11 2:16 PM, Stephen Farrell wrote:
>> From my personal p-o-v, (i.e. no hats) I don't see that DANE's
> handing of additional TA inputs  (compared to the things 5280
> needs) can be driven by 5280 since 5280 is silent on the topic.
> Equally, I don't think the (sometimes not so great) browser
> implementations of TA handling ought drive everything DANE
> does. So DANE should decide what it wants basically. Treat the
> info as a 5280 TA, as a bare key, as some kind of TAMP-like
> thing, whatever meets the use cases, and can be secure enough.

This seems like a good way to dissect the topic, except that there is 
obvious disagreement about what a "5280 TA" is. I would say that 
treating the TLSA info as a bare key is the clearest statement.

Date: Sun, 13 Feb 2011 15:46:51 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] dane-04 trust anchors

On 2/13/11 1:36 PM, Yaron Sheffer wrote:
>> Please re-read section 6.1.1, particularly element (d) there. Your list
>> would fall under (d)(4), which is explicitly listed as optional.
>>
> I believe this characterization is incorrect. 6.1.1.d.4 discusses
> "public key parameters", which are never defined, but seem to refer to
> actual mathematical parameters of the public key, such as algebraic
> groups, generators etc.

As you say, they are not defined, so you could be right. However, that 
doesn't make much sense because I would doubt that needed parameters 
such as those would be optional; this is why I assumed that they were 
parameters such as "how long is this key good for" and "what can this 
key be used for" and so on.

> I agree that RFC 5280 is essentially silent about the semantics of
> anything in the TA, when it is provided as a self-signed cert. I would
> appear that the authors of RFC 2459 (back in Jan. 1999) considered the
> self-signed cert that wraps the public key as extraneous.

I'm glad we agree here.

> However if a
> modern browser were to ignore the validity period on a Verisign
> top-level CA cert, this would be considered a bug.

...by you, but not by the spec.

> I accept that I confused the processing of EE certs with trust anchors.

Good.

> But it would seem that modern practice diverges *a lot* from RFC 5280.

That might be true, but I'm not sure how it is relevant to what we make 
as MUST-level considerations in the TLSA document.

> Moreover, people expect certain behavior from TLS self-signed CA certs
> and we should ensure that such behavior (to the extent it is formally
> specified) is also followed by a conformant DANE RP.

We disagree here: just because people might expect something that is 
wrong, I do not see why institutionalizing it makes it right.

> All the items on my list can appear in intermediate certs, and sometimes
> do (with the possible exception of name constraints). So applications
> should behave sanely when presented with them.

Fully agree. In an intermediate certificate in a chain from a trust 
anchor, the full PKIX non-TA semantics need to be used. That's not what 
we are talking about in this thread, of course.

Date: Sun, 13 Feb 2011 18:09:48 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Jakob Schlyter <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] WebID at W3C and keyassure

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

On Sun, Feb 13, 2011 at 1:49 PM, Jakob Schlyter <[email-masked]> wrote:

> On 12 feb 2011, at 00.20, Phillip Hallam-Baker wrote:
>
> > The RFC published in 2006
> >
> > The idea does not appear to have found much success, I am not aware of
> any application that obtains S/MIME certs in that fashion.
> >
> > I think those facts suggest that the DNS is not a good choice for
> per-user information.
>
> I acknowledge it has not found much success, but I would suspect that is
> also due to the limited email address to DNS domain name mapping used. On
> the other hand, no other email address to certificate services has found
> much success either.
>
> > While that approach may work for small time personal domains, the DNS as
> deployed and administered does not make that approach a practical one for an
> organization of even moderate size.
>
> Given a better method to provide information on how to perform the mapping
> between email address and DNS domain name (e.g. all certs for
> [email-masked] can be found at username._users.kirei.se), I believe
> this is scalable even for large organizations. If we have that, a protocol
> like DANE could be quite useful.
>
>        jakob
>
>
As I said originally:

DNS is an appropriate mechanism to use to discover a service that can
resolve the 'user' portion for 'example.com'

There is already a W3C recommendation that does precisely that - XKMS. It
even has SRV prefixes defined for that exact purpose.

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

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

<br><br><div class=3D"gmail_quote">On Sun, Feb 13, 2011 at 1:49 PM, Jakob S=
chlyter <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">jakob@kirei=
.se</a>&gt;</span> wrote:<br><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">On 12 feb 2011, at 00.20, Phillip Hallam-Baker wrote:<br>
<br>
&gt; The RFC published in 2006<br>
&gt;<br>
&gt; The idea does not appear to have found much success, I am not aware of=
 any application that obtains S/MIME certs in that fashion.<br>
&gt;<br>
&gt; I think those facts suggest that the DNS is not a good choice for per-=
user information.<br>
<br>
</div>I acknowledge it has not found much success, but I would suspect that=
 is also due to the limited email address to DNS domain name mapping used. =
On the other hand, no other email address to certificate services has found=
 much success either.<br>

<div class=3D"im"><br>
&gt; While that approach may work for small time personal domains, the DNS =
as deployed and administered does not make that approach a practical one fo=
r an organization of even moderate size.<br>
<br>
</div>Given a better method to provide information on how to perform the ma=
pping between email address and DNS domain name (e.g. all certs for <a href=
=3D"mailto:[email-masked]">[email-masked]</a> can be found at usernam=
e._<a href=3D"http://users.kirei.se" target=3D"_blank">users.kirei.se</a>),=
 I believe this is scalable even for large organizations. If we have that, =
a protocol like DANE could be quite useful.<br>

<font color=3D"#888888"><br>
 =A0 =A0 =A0 =A0jakob<br>
<br>
</font></blockquote></div><br>As I said originally:<div><br></div><div><met=
a charset=3D"utf-8"><span class=3D"Apple-style-span" style=3D"border-collap=
se: collapse; color: rgb(51, 51, 51); font-family: arial, sans-serif; font-=
size: 13px; ">DNS is an appropriate mechanism to use to discover a service =
that can resolve the &#39;user&#39; portion for &#39;<a href=3D"http://exam=
ple.com/" target=3D"_blank" style=3D"color: rgb(61, 84, 89); ">example.com<=
/a>&#39;</span></div>
<div><font class=3D"Apple-style-span" color=3D"#333333" face=3D"arial, sans=
-serif"><span class=3D"Apple-style-span" style=3D"border-collapse: collapse=
;"><br></span></font></div><div><font class=3D"Apple-style-span" color=3D"#=
333333" face=3D"arial, sans-serif"><span class=3D"Apple-style-span" style=
=3D"border-collapse: collapse;"><br>
</span></font></div><div><font class=3D"Apple-style-span" color=3D"#333333"=
 face=3D"arial, sans-serif"><span class=3D"Apple-style-span" style=3D"borde=
r-collapse: collapse;">There is already a W3C recommendation that does prec=
isely that - XKMS. It even has SRV prefixes defined for that exact purpose.=
</span></font></div>
<div><font class=3D"Apple-style-span" color=3D"#333333" face=3D"arial, sans=
-serif"><span class=3D"Apple-style-span" style=3D"border-collapse: collapse=
;"><br clear=3D"all"></span></font><br>-- <br>Website: <a href=3D"http://ha=
llambaker.com/">http://hallambaker.com/</a><br>
<br>
</div>

--001485f6d1ae2449cf049c32072e--

Date: Sun, 13 Feb 2011 22:16:06 +0000
From: Stephen Farrell <[email-masked]>
To: Yaron Sheffer <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] dane-04 trust anchors

Hiya,

On 13/02/11 21:36, Yaron Sheffer wrote:
> Hi Paul,
> 
> please see my response below.
> 
> Thanks,
>     Yaron
> 
>> Date: Sun, 13 Feb 2011 08:59:49 -0800
>> From: Paul Hoffman<[email-masked]>
>> Subject: Re: [keyassure] dane-04 trust anchors
>> To: [email-masked]
>> Message-ID:<[email-masked]>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> On 2/11/11 12:40 PM, Yaron Sheffer wrote:
>>> Having read and enjoyed numerous posts by Steve Kent, and skimmed (I
>>> don't know who might have actually read) Sec. 6.1 of RFC 5280, I still
>>> don't see your problem with my example list, nor any statement by Kent
>>> that contradicts it.
>>
>> Please re-read section 6.1.1, particularly element (d) there. Your list
>> would fall under (d)(4), which is explicitly listed as optional.
>>
> I believe this characterization is incorrect. 6.1.1.d.4 discusses
> "public key parameters", which are never defined, but seem to refer to
> actual mathematical parameters of the public key, such as algebraic
> groups, generators etc.

Right.

> I agree that RFC 5280 is essentially silent about the semantics of
> anything in the TA, 

Right.

> when it is provided as a self-signed cert. 

Or in any other way. 5280 just says TA info "may" be in an SSC
and that was quite deliberate. (Smartcards for example didn't
use SSC's much - they disliked those extra useless signature
bits as I recall:-)

PKIX did a bunch more on this with TAMP afterwards as well so
there's plenty of mail and RFC text to argue from.

>From my personal p-o-v, (i.e. no hats) I don't see that DANE's
handing of additional TA inputs  (compared to the things 5280
needs) can be driven by 5280 since 5280 is silent on the topic.
Equally, I don't think the (sometimes not so great) browser
implementations of TA handling ought drive everything DANE
does. So DANE should decide what it wants basically. Treat the
info as a 5280 TA, as a bare key, as some kind of TAMP-like
thing, whatever meets the use cases, and can be secure enough.

S.

> I would
> appear that the authors of RFC 2459 (back in Jan. 1999) considered the
> self-signed cert that wraps the public key as extraneous. However if a
> modern browser were to ignore the validity period on a Verisign
> top-level CA cert, this would be considered a bug.
> 
>>> All four items are explicitly mentioned in Sec. 6.1 of the RFC, as well
>>> as even more wondrous beasts. The list is non-normative, serving as an
>>> example of the kind of validation that RFC 5280 mandates.
>>
>> There are two problems here. You said:
>>
>>>>> The client MUST obey any constraints included in the trust anchor,
>>>>> including but not limited to:
>>>>> - Validity period.
>>>>> - Key usage fields.
>>>>> - Path length constraints.
>>>>> - Name constraints.
>>>>> The normal rules of RFC 5280 apply.
>>
>> I don't see now a "MUST obey" can be considered "non-normative".
>>
>> Further, you are simply incorrect that RFC 5280 mandates any of those,
>> given that RFC 5280 says that they are optional.
>>
>> One of the reasons I am pushing hard against this is that the DANE WG
>> should not be propagating myths about PKIX. Another is that some of the
>> things that you are trying to mandate are often done poorly in PKIX
>> certificate-writing implementations.
>>
>> You have still not said what the security advantage of following that
>> these optional parts of trust anchors is. For example, if a
>> certificate-writing application does a typically stupid thing with key
>> usage, what security advantage is there to either the TLS server or
>> client for the client to not be able to communicate with the server
>> securely for that one reason? Note that I am not arguing against
>> following PKIX for normal path processing: we are talking about trust
>> anchors only here. You seem to confuse the parts of the validation
>> algorithm that are for end-entity certificates and intermediate CAs with
>> trust anchors, and that is very bad here.
> 
> I accept that I confused the processing of EE certs with trust anchors.
> But it would seem that modern practice diverges *a lot* from RFC 5280.
> Moreover, people expect certain behavior from TLS self-signed CA certs
> and we should ensure that such behavior (to the extent it is formally
> specified) is also followed by a conformant DANE RP.
> 
> All the items on my list can appear in intermediate certs, and sometimes
> do (with the possible exception of name constraints). So applications
> should behave sanely when presented with them.
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
> 

Date: Sun, 13 Feb 2011 23:44:55 +0200
From: Yaron Sheffer <[email-masked]>
To: Paul Wouters <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] dane-04 trust anchors

Hi Paul,

please see my comments below.

Thanks,
	Yaron

On 02/13/2011 09:58 PM, Paul Wouters wrote:
> On Fri, 11 Feb 2011, Yaron Sheffer wrote:
>
>> My reference scenario is this: I am a phisher. I'd like to trick
>> BigBank's customers, so I acquire bigbang.com (an easy misspelling).
>> Now I can get a certificate that they will use as a trust anchor, and
>> include whatever I want in it, such as the Subject field, "Your
>> trusted BigBank".
>
> This is another reason for a "bare public key" type. This is indeed an
> issue
> that browser vendors have to deal with now.
>
I am all in favor of bare public keys. But if people insist on having a 
self-signed certificate instead, we should specify what its semantics are.

>> Client treatment of any non-key information included in the trust
>> anchor is a matter of local policy. It is noted that this
>> specification does not mandate that such information be inspected or
>> validated by the domain registrar.
>
> Why mention "domain registrar"? Those are not a party at all in anything
> here.
>
Some person/organization signs the TLSA record. I would like to mention 
explicitly that this person/organization does not validate anything that 
is referenced from this record.

>> The client MUST obey any constraints included in the trust anchor,
>> including but not limited to:
>> - Validity period.
>
> What to do if that period does not match the DNS TTL/RRSIG period?
>
I guess the more constrained validity prevails.
>> - Key usage fields.
>> - Path length constraints.
>> - Name constraints.
>> The normal rules of RFC 5280 apply.
>
> I'd rather see something saying everything except the public key should
> be "local
> policy", and no "MUST obey" items are present.

"Local policy" is an OK statement for intra-enterprise deployment. It 
makes little sense in consumer cases. Do we want each browser to have 
its own security policy?
>
> Especially since that reduces the amount of ASN.1 parsing. Remember, now
> we don't
> even have the flawed SSL providers sanity checks on anything.

Again, if the application is given a cert, it should parse it. It cannot 
just ignore it. If we say that bare public keys are the RECOMMENDED 
option, fine with me.
>
> Paul

Date: Sun, 13 Feb 2011 23:36:28 +0200
From: Yaron Sheffer <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] dane-04 trust anchors

Hi Paul,

please see my response below.

Thanks,
	Yaron

> Date: Sun, 13 Feb 2011 08:59:49 -0800
> From: Paul Hoffman<[email-masked]>
> Subject: Re: [keyassure] dane-04 trust anchors
> To: [email-masked]
> Message-ID:<[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 2/11/11 12:40 PM, Yaron Sheffer wrote:
>> Having read and enjoyed numerous posts by Steve Kent, and skimmed (I
>> don't know who might have actually read) Sec. 6.1 of RFC 5280, I still
>> don't see your problem with my example list, nor any statement by Kent
>> that contradicts it.
>
> Please re-read section 6.1.1, particularly element (d) there. Your list
> would fall under (d)(4), which is explicitly listed as optional.
>
I believe this characterization is incorrect. 6.1.1.d.4 discusses 
"public key parameters", which are never defined, but seem to refer to 
actual mathematical parameters of the public key, such as algebraic 
groups, generators etc.

I agree that RFC 5280 is essentially silent about the semantics of 
anything in the TA, when it is provided as a self-signed cert. I would 
appear that the authors of RFC 2459 (back in Jan. 1999) considered the 
self-signed cert that wraps the public key as extraneous. However if a 
modern browser were to ignore the validity period on a Verisign 
top-level CA cert, this would be considered a bug.

>> All four items are explicitly mentioned in Sec. 6.1 of the RFC, as well
>> as even more wondrous beasts. The list is non-normative, serving as an
>> example of the kind of validation that RFC 5280 mandates.
>
> There are two problems here. You said:
>
>>>> The client MUST obey any constraints included in the trust anchor,
>>>> including but not limited to:
>>>> - Validity period.
>>>> - Key usage fields.
>>>> - Path length constraints.
>>>> - Name constraints.
>>>> The normal rules of RFC 5280 apply.
>
> I don't see now a "MUST obey" can be considered "non-normative".
>
> Further, you are simply incorrect that RFC 5280 mandates any of those,
> given that RFC 5280 says that they are optional.
>
> One of the reasons I am pushing hard against this is that the DANE WG
> should not be propagating myths about PKIX. Another is that some of the
> things that you are trying to mandate are often done poorly in PKIX
> certificate-writing implementations.
>
> You have still not said what the security advantage of following that
> these optional parts of trust anchors is. For example, if a
> certificate-writing application does a typically stupid thing with key
> usage, what security advantage is there to either the TLS server or
> client for the client to not be able to communicate with the server
> securely for that one reason? Note that I am not arguing against
> following PKIX for normal path processing: we are talking about trust
> anchors only here. You seem to confuse the parts of the validation
> algorithm that are for end-entity certificates and intermediate CAs with
> trust anchors, and that is very bad here.

I accept that I confused the processing of EE certs with trust anchors. 
But it would seem that modern practice diverges *a lot* from RFC 5280. 
Moreover, people expect certain behavior from TLS self-signed CA certs 
and we should ensure that such behavior (to the extent it is formally 
specified) is also followed by a conformant DANE RP.

All the items on my list can appear in intermediate certs, and sometimes 
do (with the possible exception of name constraints). So applications 
should behave sanely when presented with them.

Date: Sun, 13 Feb 2011 14:58:29 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Yaron Sheffer <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] dane-04 trust anchors

On Fri, 11 Feb 2011, Yaron Sheffer wrote:

> My reference scenario is this: I am a phisher. I'd like to trick BigBank's 
> customers, so I acquire bigbang.com (an easy misspelling). Now I can get a 
> certificate that they will use as a trust anchor, and include whatever I want 
> in it, such as the Subject field, "Your trusted BigBank".

This is another reason for a "bare public key" type. This is indeed an issue
that browser vendors have to deal with now.

> Client treatment of any non-key information included in the trust anchor is a 
> matter of local policy. It is noted that this specification does not mandate 
> that such information be inspected or validated by the domain registrar.

Why mention "domain registrar"? Those are not a party at all in anything here.

> The client MUST obey any constraints included in the trust anchor, including 
> but not limited to:
> - Validity period.

What to do if that period does not match the DNS TTL/RRSIG period?

> - Key usage fields.
> - Path length constraints.
> - Name constraints.
> The normal rules of RFC 5280 apply.

I'd rather see something saying everything except the public key should be "local
policy", and no "MUST obey" items are present.

Especially since that reduces the amount of ASN.1 parsing. Remember, now we don't
even have the flawed SSL providers sanity checks on anything.

Paul

Date: Sun, 13 Feb 2011 14:47:52 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Warren Kumari <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Issue #3: Format of the record.

On Thu, 10 Feb 2011, Warren Kumari wrote:

> We have "Issue #3: Format of the record" with the description:
>
> --------------------
> Format of the record:
> a subtype of CERT (as was used in early drafts)
> a new RRtype (used in draft-ietf-dane-protocol-00)
> a TXT record with _prefix.
>
> Hopefully this is just a representation issue and can be worked on after larger decisions have been made.
>
> ----------------------
>
> I think that we have settled on using a new RRtype (as shown in draft-ietf-dane-protocol-00), but I realize that we haven't explicitly had a consensus call on this, so I am (with all reverence) donning the bells and ribbons, stepping over the clay pipes, smacking myself smartly with the stick and beginning the consensus call...

Yes, a new RRTYPE.

Paul

From: Jakob Schlyter <[email-masked]>
Date: Sun, 13 Feb 2011 19:49:34 +0100
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] WebID at W3C and keyassure

On 12 feb 2011, at 00.20, Phillip Hallam-Baker wrote:

> The RFC published in 2006
>=20
> The idea does not appear to have found much success, I am not aware of =
any application that obtains S/MIME certs in that fashion.
>=20
> I think those facts suggest that the DNS is not a good choice for =
per-user information.

I acknowledge it has not found much success, but I would suspect that is =
also due to the limited email address to DNS domain name mapping used. =
On the other hand, no other email address to certificate services has =
found much success either.

> While that approach may work for small time personal domains, the DNS =
as deployed and administered does not make that approach a practical one =
for an organization of even moderate size.

Given a better method to provide information on how to perform the =
mapping between email address and DNS domain name (e.g. all certs for =
[email-masked] can be found at username._users.kirei.se), I believe =
this is scalable even for large organizations. If we have that, a =
protocol like DANE could be quite useful.

	jakob

From: Matt McCutchen <[email-masked]>
To: keyassure <[email-masked]>
Date: Sun, 13 Feb 2011 13:15:10 -0500
Subject: [keyassure] Binding to full TLS encapsulation or STARTTLS

I realized that TLSA as we are currently discussing does not bind keys
to the use of full TLS encapsulation or STARTTLS.  I'm thinking this is
OK because it would be pretty ridiculous to multiplex different services
based on the use of full encapsulation or STARTTLS, and clients
generally do not ascribe security significance to the use of one or the
other.  E.g., if I bind a key to _3141._tcp.example.com for a service
that uses STARTTLS, I can't think of any scenario in which a client
trying to use full encapsulation would be harmed if a MITM allowed it to
succeed by performing the STARTTLS part directly with the server.  It
might be nice to prevent web browsers from talking to STARTTLS services,
but that would be far from a complete solution to the problem of
browsers being a loose cannon for arbitrary connections, nor is it our
responsibility to solve that problem here.

Sanity check?

-- 
Matt

Date: Sun, 13 Feb 2011 08:59:49 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] dane-04 trust anchors

On 2/11/11 12:40 PM, Yaron Sheffer wrote:
> Having read and enjoyed numerous posts by Steve Kent, and skimmed (I
> don't know who might have actually read) Sec. 6.1 of RFC 5280, I still
> don't see your problem with my example list, nor any statement by Kent
> that contradicts it.

Please re-read section 6.1.1, particularly element (d) there. Your list 
would fall under (d)(4), which is explicitly listed as optional.

> All four items are explicitly mentioned in Sec. 6.1 of the RFC, as well
> as even more wondrous beasts. The list is non-normative, serving as an
> example of the kind of validation that RFC 5280 mandates.

There are two problems here. You said:

>>> The client MUST obey any constraints included in the trust anchor,
>>> including but not limited to:
>>> - Validity period.
>>> - Key usage fields.
>>> - Path length constraints.
>>> - Name constraints.
>>> The normal rules of RFC 5280 apply.

I don't see now a "MUST obey" can be considered "non-normative".

Further, you are simply incorrect that RFC 5280 mandates any of those, 
given that RFC 5280 says that they are optional.

One of the reasons I am pushing hard against this is that the DANE WG 
should not be propagating myths about PKIX. Another is that some of the 
things that you are trying to mandate are often done poorly in PKIX 
certificate-writing implementations.

You have still not said what the security advantage of following that 
these optional parts of trust anchors is. For example, if a 
certificate-writing application does a typically stupid thing with key 
usage, what security advantage is there to either the TLS server or 
client for the client to not be able to communicate with the server 
securely for that one reason? Note that I am not arguing against 
following PKIX for normal path processing: we are talking about trust 
anchors only here. You seem to confuse the parts of the validation 
algorithm that are for end-entity certificates and intermediate CAs with 
trust anchors, and that is very bad here.

From: "Jim Schaad" <[email-masked]>
To: "'Paul Hoffman'" <[email-masked]>, <[email-masked]>
Date: Sat, 12 Feb 2011 13:58:12 -0800
Subject: Re: [keyassure] dane-04 trust anchors

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Paul Hoffman
> Sent: Friday, February 11, 2011 8:44 AM
> To: [email-masked]
> Subject: Re: [keyassure] dane-04 trust anchors
> 
> On 2/10/11 11:26 PM, Yaron Sheffer wrote:
> > the new text is a major improvement over the previous version. But it
> > is still missing some necessary guidance.
> >
> > My reference scenario is this: I am a phisher. I'd like to trick
> > BigBank's customers, so I acquire bigbang.com (an easy misspelling).
> > Now I can get a certificate that they will use as a trust anchor, and
> > include whatever I want in it, such as the Subject field, "Your
> > trusted BigBank".
> 
> Good scenario.
> 
> > Moreover, even if I am the rightful owner, the current text does not
> > allow me to restrict the certificate's use.
> 
> Correct. That is on purpose.
> 
> > So I propose the following text added:
> >
> > Client treatment of any non-key information included in the trust
> > anchor is a matter of local policy. It is noted that this
> > specification does not mandate that such information be inspected or
> > validated by the domain registrar.
> 
> Sounds good to me.
> 
> > The client MUST obey any constraints included in the trust anchor,
> > including but not limited to:
> > - Validity period.
> > - Key usage fields.
> > - Path length constraints.
> > - Name constraints.
> > The normal rules of RFC 5280 apply.
> 
> As Steve Kent pointed out earlier on the list, the normal rules of RFC
> 5280 for trust anchors disagrees with that list you gave. I would prefer
to follow
> the normal rules of RFC 5280 for trust anchors, and not come up with ones
of
> our own.

I think that it is perfectly reasonable to say that the information is to be
extracted from the provided certificate and used as the starting conditions
for the certificate validation process.  This does not change the rules for
5280 trust anchors as the information can come in from an external
configuration.

Many systems already will seed that initial configuration of the other
variables used in the process from the data contained in the trust anchor,
allowing for it to be changed or overridden by either system or trust
administrators.

Jim

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

From: Henry Story <[email-masked]>
Date: Sat, 12 Feb 2011 01:29:26 +0100
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] WebID at W3C and keyassure

--Apple-Mail-6--811697351
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

On 11 Feb 2011, at 22:24, Phillip Hallam-Baker wrote:

> On Fri, Feb 11, 2011 at 10:06 AM, Henry Story =
<[email-masked]> wrote:
>=20
>> Let's start from first principles. As far as internet users are =
concerned, an Internet user identifier is [email-masked]
>=20
> In WebID we consider essentially an http url such as =
http://bblfish.net/#me as it is immediately dereferenceable,
>=20
>=20
>=20
> dereference, desmesherence.
>=20
> What matters to the user is that they have a simple identifier that =
they can give to other people, put on letterhead, business cards, read =
over the telephone.

Yes, and I have no problem with that. They can use e-mail addresses, =
home page urls or other identifiers. No problem.=20

>=20
> Tim didn't intended the URLs to even be visible to the end user. The =
address bar was an ad-hoc invention that appeared in Mosaic. In the =
original NeXTstep browser you had to dig into a menu to find the url.

If you look at the "WebID creation and use in 4 mintues"
http://www.youtube.com/watch?v=3DS4dlMTZhUDc
you will see that the end user need have absolutely no understanding of =
the concept of a URI at all. This is completely in line with Tim Berners =
Lee's vision, and he has in fact sponsored a lot of research on WebID =
such as "RDF Policy-based URI Access Control for Content Authoring on =
the Social Semantic Web" http://dig.csail.mit.edu/2009/presbrey/UAP.pdf =
to just give one example.=20

What people give to their friends is a completely different issue. They =
could give friends e-mail addresses, which could be resolved via Web =
Finger or other protocols =
http://blogs.sun.com/bblfish/entry/web_finger_proposals_overview
to the profile document. Or they could use search engines, etc... Those =
are user interface issues that one should not confuse with issues of =
logic.=20

> If you are proposing infrastructure then make it work for the user =
first and only then think about the hacks you might employ for backwards =
compatibility.

Yes, I do recommend you watch my pretty bad and very clearly amateur =
screen cast "WebID creation and use in 4 mintues"

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

With some help we can do better.

>=20
> Here we have the DNS, there is a discovery mechanism that was =
originally designed to resolve [email-masked], use it the way it was =
designed.
>=20
>=20
> If keys are going to be of the slightest use as end user keys they =
have to bind to SMTP and Jabber addresses in any case.
>=20
> What you have here is a URI scheme itself. You should think in terms =
of the canonical form being:
>=20
> webid:[email-masked]=20
>=20
> The URL you gave might be something that ended up being a mapping =
returned for retrieval/resolution purposes but that is all.

I don't think it wrong to use e-mail URLs to identify users. WebFinger =
does that, and I think they even use DNS to do that - which is better =
than when they use the .well-known file in http.=20

It does not in fact matter how many URIs identify a user. Things can be =
named by different names. There is a town in Germany the Germans call =
M=FCnchen, the French and english call Munich. As Frege pointed out in =
the 19th century Hesperus was known as the Evening Star, Phosphorus as =
the Morning Star, and it was only recently in human history that these =
names were shown to all refer to Venus. I have a few different URIs =
identify me:

http://bblfish.net/#me
http://bblfish.net/people/henry/card/#me
...

So these approaches are all compatible.=20

I was trying to show how at the protocol level that keyassure and webid =
are compatible. This does come to confirm your point that we could place =
as you suggest webid: URLs in the SAN too if we defined a protocol for =
webid: dereferencing. This has been proposed on the WebID mailing list, =
and I am not against it. I just start with the http:// URL example which =
is easier to understand (once you understand that it requires no typing)

Hope that helps.

   But don't forget the issue I raised of placing a public key in the =
DNSSEC.=20

Henry =20

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

Social Web Architect
http://bblfish.net/

--Apple-Mail-6--811697351
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><br><div><div>On 11 Feb 2011, at 22:24, Phillip Hallam-Baker =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite">On Fri, Feb 11, 2011 at 10:06 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:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex;">
<div style=3D"word-wrap:break-word"><div><div =
class=3D"im"><div><br></div><blockquote type=3D"cite"><div>Let's start =
from first principles. As far as internet users are concerned, an =
Internet user identifier is <a href=3D"mailto:[email-masked]" =
target=3D"_blank">[email-masked]</a></div>
</blockquote><div><br></div></div><div>In WebID we consider essentially =
an http url such as <a href=3D"http://bblfish.net/#me" =
target=3D"_blank">http://bblfish.net/#me</a> as it is immediately =
dereferenceable,</div><div class=3D"im">
=
<br></div></div></div></blockquote><div><br></div><div><br></div><div>dere=
ference, desmesherence.</div><div><br></div><div>What matters to the =
user is that they have a simple identifier that they can give to other =
people, put on letterhead, business cards, read over the =
telephone.</div></div></blockquote><div><br></div><div>Yes, and I have =
no problem with that. They can use e-mail addresses, home page urls or =
other&nbsp;identifiers. No problem.&nbsp;</div><br><blockquote =
type=3D"cite"><div class=3D"gmail_quote">
<div><br></div><div>Tim didn't intended the URLs to even be visible to =
the end user. The address bar was an ad-hoc invention that appeared in =
Mosaic. In the original NeXTstep browser you had to dig into a menu to =
find the url.</div></div></blockquote><div><br></div><div><br>If you =
look at the "WebID creation and use in 4 mintues"<br><a =
href=3D"http://www.youtube.com/watch?v=3DS4dlMTZhUDc">http://www.youtube.c=
om/watch?v=3DS4dlMTZhUDc</a><br>you will see that the end user need have =
absolutely no understanding of the concept of a URI at all.&nbsp;This is =
completely in line with Tim Berners Lee's vision, and he has in fact =
sponsored a lot of research&nbsp;on WebID such as "RDF Policy-based URI =
Access Control for Content&nbsp;Authoring on the Social Semantic =
Web"&nbsp;http://dig.csail.mit.edu/2009/presbrey/UAP.pdf&nbsp;to just =
give&nbsp;one example.&nbsp;<br><br>What people give to their friends is =
a completely different issue. They could give friends e-mail addresses, =
which could be resolved via Web Finger or other =
protocols&nbsp;http://blogs.sun.com/bblfish/entry/web_finger_proposals_ove=
rview<br>to the profile document. Or they could use search engines, =
etc... Those are user interface issues that one should not confuse with =
issues of logic.&nbsp;<br></div><div><br></div><br><blockquote =
type=3D"cite"><div class=3D"gmail_quote">
<div>If you are proposing infrastructure then make it work for the user =
first and only then think about the hacks you might employ for backwards =
compatibility.</div></div></blockquote><div><br></div><div><br>Yes, I do =
recommend you watch my pretty bad and very clearly amateur screen =
cast&nbsp;"WebID creation and use in 4 mintues"<br><br><a =
href=3D"http://www.youtube.com/watch?v=3DS4dlMTZhUDc">http://www.youtube.c=
om/watch?v=3DS4dlMTZhUDc</a><br><br>With some help we can do =
better.</div><br><blockquote type=3D"cite"><div =
class=3D"gmail_quote"><div><br></div><div>Here we have the DNS, there is =
a discovery mechanism that was originally designed to resolve <a =
href=3D"mailto:[email-masked]">[email-masked]</a>, use it the way it =
was designed.</div>
<div><br></div><div><br></div><div>If keys are going to be of the =
slightest use as end user keys they have to bind to SMTP and Jabber =
addresses in any case.</div><div><br></div><div>What you have here is a =
URI scheme itself. You should think in terms of the canonical form =
being:</div>
<div><br></div><div><a =
href=3D"mailto:[email-masked]">webid:[email-masked]</a>&nbsp;<=
/div></div><div><br></div><div>The URL you gave might be something that =
ended up being a mapping returned for retrieval/resolution purposes but =
that is all.</div></blockquote><div><br></div><div><br></div><div>I =
don't think it wrong to use e-mail URLs to identify users. WebFinger =
does that, and I think they even&nbsp;use DNS to do that - which is =
better than when they use the .well-known file in =
http.&nbsp;</div><div><br>It does not in fact matter how many URIs =
identify a user. Things can be named by different names.&nbsp;There is a =
town in Germany the Germans call M=FCnchen, the French and english call =
Munich. As Frege&nbsp;pointed out in the 19th century Hesperus was known =
as the Evening Star, Phosphorus as the Morning&nbsp;Star, and it was =
only recently in human history that these names were shown to all refer =
to Venus. I&nbsp;have a few different URIs identify me:<br><br><a =
href=3D"http://bblfish.net/#me">http://bblfish.net/#me</a><br>http://bblfi=
sh.net/people/henry/card/#me<br>...<br><br>So these approaches are all =
compatible.&nbsp;<div><br></div><div>I was trying to show how at =
the&nbsp;protocol level that keyassure and webid are compatible. This =
does come to confirm your point that we could place as you suggest =
webid: URLs in the SAN too if we defined a protocol for webid: =
dereferencing. This has been proposed on the WebID mailing list, and I =
am not against it. I just start with the http:// URL example which is =
easier to understand (once you understand that it requires no =
typing)</div><div><br></div><div>Hope that =
helps.</div><div><br></div><div>&nbsp;&nbsp; But don't forget the issue =
I raised of placing a public key in the =
DNSSEC.&nbsp;</div><div><br></div><div>Henry =
&nbsp;</div></div><br><blockquote type=3D"cite">
<div><br></div><div><br></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"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-6--811697351--

Date: Fri, 11 Feb 2011 18:20:05 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Jakob Schlyter <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] WebID at W3C and keyassure

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

The RFC published in 2006

The idea does not appear to have found much success, I am not aware of any
application that obtains S/MIME certs in that fashion.

I think those facts suggest that the DNS is not a good choice for per-user
information.

While that approach may work for small time personal domains, the DNS as
deployed and administered does not make that approach a practical one for an
organization of even moderate size.

On Fri, Feb 11, 2011 at 6:10 PM, Jakob Schlyter <[email-masked]> wrote:

> On 11 feb 2011, at 15.14, Phillip Hallam-Baker wrote:
>
> > DNS is not an appropriate place to store attributes specific to '
> [email-masked]'.
>
> IMHO, that's a pretty strong statement - RFC 4398 (section 3.2) does not
> agree with you at all.
>
>        jakob
>
>

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

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

<div>The RFC published in 2006</div><div><br></div><div>The idea does not a=
ppear to have found much success, I am not aware of any application that ob=
tains S/MIME certs in that fashion.</div><div><br></div><div>I think those =
facts suggest that the DNS is not a good choice for per-user information.</=
div>
<div><br></div><div><br></div><div>While that approach may work for small t=
ime personal domains, the DNS as deployed and administered does not make th=
at approach a practical one for an organization of even moderate size.</div=
>
<div><br><br><div class=3D"gmail_quote">On Fri, Feb 11, 2011 at 6:10 PM, Ja=
kob Schlyter <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">jakob@=
kirei.se</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 11 feb 2011, at 15.14, Phillip Hallam-Baker wrote:<br>
<br>
</div><div class=3D"im">&gt; DNS is not an appropriate place to store attri=
butes specific to &#39;<a href=3D"mailto:[email-masked]">[email-masked]=
</a>&#39;.<br>
<br>
</div>IMHO, that&#39;s a pretty strong statement - RFC 4398 (section 3.2) d=
oes not agree with you at all.<br>
<font color=3D"#888888"><br>
 =A0 =A0 =A0 =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>

--0016e6441dce30c2f6049c09f09c--

From: Jakob Schlyter <[email-masked]>
Date: Sat, 12 Feb 2011 00:10:27 +0100
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] WebID at W3C and keyassure

On 11 feb 2011, at 15.14, Phillip Hallam-Baker wrote:

> DNS is not an appropriate place to store attributes specific to =
[email-masked]'.

IMHO, that's a pretty strong statement - RFC 4398 (section 3.2) does not =
agree with you at all.

	jakob

Date: Fri, 11 Feb 2011 16:24:57 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Henry Story <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] WebID at W3C and keyassure

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

On Fri, Feb 11, 2011 at 10:06 AM, Henry Story <[email-masked]>wrote:
>
>
> Let's start from first principles. As far as internet users are concerned,
> an Internet user identifier is [email-masked]
>
>
> In WebID we consider essentially an http url such as
> http://bblfish.net/#me as it is immediately dereferenceable,
>
>

dereference, desmesherence.

What matters to the user is that they have a simple identifier that they can
give to other people, put on letterhead, business cards, read over the
telephone.

Tim didn't intended the URLs to even be visible to the end user. The address
bar was an ad-hoc invention that appeared in Mosaic. In the original
NeXTstep browser you had to dig into a menu to find the url.

If you are proposing infrastructure then make it work for the user first and
only then think about the hacks you might employ for backwards
compatibility.

Here we have the DNS, there is a discovery mechanism that was originally
designed to resolve [email-masked], use it the way it was designed.

If keys are going to be of the slightest use as end user keys they have to
bind to SMTP and Jabber addresses in any case.

What you have here is a URI scheme itself. You should think in terms of the
canonical form being:

webid:[email-masked]

The URL you gave might be something that ended up being a mapping returned
for retrieval/resolution purposes but that is all.

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

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

<br><br><div class=3D"gmail_quote">On Fri, Feb 11, 2011 at 10:06 AM, Henry =
Story <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">henr=
[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:1ex;">
<div style=3D"word-wrap:break-word"><div><div class=3D"im"><div><br></div><=
blockquote type=3D"cite"><div>Let&#39;s start from first principles. As far=
 as internet users are concerned, an Internet user identifier is <a href=3D=
"mailto:[email-masked]" target=3D"_blank">[email-masked]</a></div>
</blockquote><div><br></div></div><div>In WebID we consider essentially an =
http url such as <a href=3D"http://bblfish.net/#me" target=3D"_blank">http:=
//bblfish.net/#me</a> as it is immediately dereferenceable,</div><div class=
=3D"im">
<br></div></div></div></blockquote><div><br></div><div><br></div><div>deref=
erence, desmesherence.</div><div><br></div><div>What matters to the user is=
 that they have a simple identifier that they can give to other people, put=
 on letterhead, business cards, read over the telephone.</div>
<div><br></div><div>Tim didn&#39;t intended the URLs to even be visible to =
the end user. The address bar was an ad-hoc invention that appeared in Mosa=
ic. In the original NeXTstep browser you had to dig into a menu to find the=
 url.</div>
<div><br></div><div><br></div><div>If you are proposing infrastructure then=
 make it work for the user first and only then think about the hacks you mi=
ght employ for backwards compatibility.</div><div><br></div><div>Here we ha=
ve the DNS, there is a discovery mechanism that was originally designed to =
resolve <a href=3D"mailto:[email-masked]">[email-masked]</a>, use it th=
e way it was designed.</div>
<div><br></div><div><br></div><div>If keys are going to be of the slightest=
 use as end user keys they have to bind to SMTP and Jabber addresses in any=
 case.</div><div><br></div><div>What you have here is a URI scheme itself. =
You should think in terms of the canonical form being:</div>
<div><br></div><div><a href=3D"mailto:[email-masked]">webid:user@=
example.com</a>=A0</div></div><div><br></div><div>The URL you gave might be=
 something that ended up being a mapping returned for retrieval/resolution =
purposes but that is all.</div>
<div><br></div><div><br></div>-- <br>Website: <a href=3D"http://hallambaker=
.com/">http://hallambaker.com/</a><br><br>

--001636b432477ce002049c0854ab--

Date: Fri, 11 Feb 2011 22:40:55 +0200
From: Yaron Sheffer <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] dane-04 trust anchors

Hi Paul,

Having read and enjoyed numerous posts by Steve Kent, and skimmed (I 
don't know who might have actually read) Sec. 6.1 of RFC 5280, I still 
don't see your problem with my example list, nor any statement by Kent 
that contradicts it.

All four items are explicitly mentioned in Sec. 6.1 of the RFC, as well 
as even more wondrous beasts. The list is non-normative, serving as an 
example of the kind of validation that RFC 5280 mandates.

Thanks,
	Yaron

> ------------------------------
>
> Message: 2
> Date: Fri, 11 Feb 2011 08:44:09 -0800
> From: Paul Hoffman<[email-masked]>
> Subject: Re: [keyassure] dane-04 trust anchors
> To: [email-masked]
> Message-ID:<[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 2/10/11 11:26 PM, Yaron Sheffer wrote:
>> the new text is a major improvement over the previous version. But it is
>> still missing some necessary guidance.
>>
>> My reference scenario is this: I am a phisher. I'd like to trick
>> BigBank's customers, so I acquire bigbang.com (an easy misspelling). Now
>> I can get a certificate that they will use as a trust anchor, and
>> include whatever I want in it, such as the Subject field, "Your trusted
>> BigBank".
>
> Good scenario.
>
>> Moreover, even if I am the rightful owner, the current text does not
>> allow me to restrict the certificate's use.
>
> Correct. That is on purpose.
>
>> So I propose the following text added:
>>
>> Client treatment of any non-key information included in the trust anchor
>> is a matter of local policy. It is noted that this specification does
>> not mandate that such information be inspected or validated by the
>> domain registrar.
>
> Sounds good to me.
>
>> The client MUST obey any constraints included in the trust anchor,
>> including but not limited to:
>> - Validity period.
>> - Key usage fields.
>> - Path length constraints.
>> - Name constraints.
>> The normal rules of RFC 5280 apply.
>
> As Steve Kent pointed out earlier on the list, the normal rules of RFC
> 5280 for trust anchors disagrees with that list you gave. I would prefer
> to follow the normal rules of RFC 5280 for trust anchors, and not come
> up with ones of our own.
>
>
> ------------------------------
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>
>
> End of keyassure Digest, Vol 7, Issue 24
> ****************************************

Date: Fri, 11 Feb 2011 08:44:09 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] dane-04 trust anchors

On 2/10/11 11:26 PM, Yaron Sheffer wrote:
> the new text is a major improvement over the previous version. But it is
> still missing some necessary guidance.
>
> My reference scenario is this: I am a phisher. I'd like to trick
> BigBank's customers, so I acquire bigbang.com (an easy misspelling). Now
> I can get a certificate that they will use as a trust anchor, and
> include whatever I want in it, such as the Subject field, "Your trusted
> BigBank".

Good scenario.

> Moreover, even if I am the rightful owner, the current text does not
> allow me to restrict the certificate's use.

Correct. That is on purpose.

> So I propose the following text added:
>
> Client treatment of any non-key information included in the trust anchor
> is a matter of local policy. It is noted that this specification does
> not mandate that such information be inspected or validated by the
> domain registrar.

Sounds good to me.

> The client MUST obey any constraints included in the trust anchor,
> including but not limited to:
> - Validity period.
> - Key usage fields.
> - Path length constraints.
> - Name constraints.
> The normal rules of RFC 5280 apply.

As Steve Kent pointed out earlier on the list, the normal rules of RFC 
5280 for trust anchors disagrees with that list you gave. I would prefer 
to follow the normal rules of RFC 5280 for trust anchors, and not come 
up with ones of our own.

Date: Fri, 11 Feb 2011 08:38:54 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Special, four issues (#2, #9, #13, #18) for the price of one....

On 2/10/11 10:22 PM, Simon Josefsson wrote:
>>>> A TLS client conforming to this protocol MUST treat the certificate
>>>> for association in a TLSA resource record for a domain name as a
>>>> trust anchor for that domain name at the specific port number and
>>>> transport name that was queried. This trust anchor MUST only be used
>>>> for the domain name of the resource record.
>>>
>>> And port number and transport protocol name.
>>
>> Why should we put on that requirement? That is, if I get a trust
>> anchor for _443._tcp.www.example.com, what is the security issue if I
>> also want to use it for TLS on port 4443? There is no attack that an
>> MITM can mount on 4443 that they cannot also mount on 443.
>
> You may want to run a commercial CA on port 443 to get good interop with
> deployed https clients, but you may want to use a trustworthy CA on port
> 4443 to get good security for some other services.

Absolutely.

> Having the
> commercial CA be able to MITM the connection on 4443 sounds counter to
> what I perceive DANE is aiming to achieve.

Quite right, but that is not what the text in the document says. A 
highly-cautious client would not want to use the 443-trust-anchor for 
any other port, but I do not see the reason to force that policy on 
them, particularly if they want to reduce DNS round trips. It makes 
sense to force them to only use the trust anchor on the domain name 
given, because that sets the administrative boundary to the 
administrator of the domain name service; however, beyond that, it 
should be a client policy option.

Would you be OK if we left this as-is and put in a security 
consideration with the scenario you give?

--Paul Hoffman

Date: Fri, 11 Feb 2011 08:35:00 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] draft-ietf-dane-protocol-03.txt

On 2/10/11 9:49 PM, Steve Schultze wrote:
> Sorry I missed this when you first posted.
>
> I feel that Matt's proposed language for Section 3 is clearer as to
> what is done in different scenarios:
> http://www.ietf.org/mail-archive/web/keyassure/current/msg00923.html

It went into more scenarios, but I didn't see much agreement on the 
scenarios at the time, or since then.

> For example, the current language in Section 3 does not make clear
> what is done in the case of no records or a DNSSEC response of
> "bogus" .  I like the way Matt's language clearly lays out all of the
> possible cases and the results.

Laying out the possible cases is good, as long as we can agree with the 
results. For example, there was disagreement about what to do in the 
case of a bogus result; what he proposed at the time causes a new and 
easy-to-mount denial-of-service attack on TLS.

> The one issue with his language is that it assumes the client is
> doing DNSSEC validation, but our current language permits "a remote
> nameserver to which one has a secured channel of communication."  If
> we are permitting that, we may have to rephrase some of his specific
> references to DNSSEC result status' like "bogus" to be more generic.

There is more than that one issue, I believe.

If someone (you or Matt) want to suggest some wording as a change to the 
current draft, that would be helpful to maybe a new open issue. However, 
please consider splitting the wording into different parts, since the 
earlier wording had disagreement about different parts, and the WG might 
want to adopt some but not all of a proposal.

From: Henry Story <[email-masked]>
Date: Fri, 11 Feb 2011 16:06:26 +0100
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] WebID at W3C and keyassure

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

On 11 Feb 2011, at 15:14, Phillip Hallam-Baker wrote:

> [Before reading this in the context of 'PKI vendor speaks', I would =
like to point out to people on the list that Comodo is now an announced =
provider of DNS services under the brand DNS.com.]
>=20
>=20
> It is not very clear to me what is being proposed here.

I was not proposing anything to start of with, other than to show at =
what level the protocols are similar. That of course cannot be a =
proposal, only a point of interest.=20

Noticing that similarity was useful in helping me understand what =
keyassure is doing.  And understanding that similarity also led me to =
ask why you don't also allow one to publish the plain and simple public =
key  in addition perhaps to the 4 methods listed in section 2.2 of =
draft-4. My point there was that that should be enough to do a lot of =
what you want. See the =3D=3DIDEA=3D=3D section. The supporting evidence =
for this is that this is enough for us at the WebID level.=20

> Let's start from first principles. As far as internet users are =
concerned, an Internet user identifier is [email-masked]

In WebID we consider essentially an http url such as =
http://bblfish.net/#me as it is immediately dereferenceable,

> I know that there are people trying to peddle URIs as user identifiers =
but the success of that approach is evidenced by the fact that OpenID =
support is contracting rather than expanding.

There are many reasons why OpenId is having trouble. The main one being =
that the user has to remember what to type, and has to type it. With =
WebID this is integrated into the SSL layer, so the user only needs to =
point and click. There is a 4 minute video on http://bblfish.net/ (the =
second one) that demonstrates this.=20

There is a whole list of other reasons why TLS works better, many of =
them I have gathered here
=
http://www.w3.org/wiki/Foaf%2Bssl/FAQ#OpenID_failed.2C_do_people_really_wa=
nt_distributed_identity.3F

>=20
> Given [email-masked] as the identifier,=20
>=20
> DNS is an appropriate mechanism to resolve attributes bound to the =
'example.com' portion.

exactly. DNS is the Canonical lookup method for a DNS name :-)

>=20
> DNS is an appropriate mechanism to use to discover a service that can =
resolve the 'user' portion for 'example.com

yes (though if it can be avoided then that can be better) But it gives =
some useful flexibility.

> DNS is not an appropriate place to store attributes specific to =
[email-masked]'.

Completely agree.=20

>=20
>=20
> We already have a Web Service that is designed to serve as a key =
centric distribution mechanism for per-user data and it happens to be a =
W3C recommendation - XKMS.

Thanks for pointing that one out. It looks like one of the SOAPy specs. =
This should be useful.
WebID is working within the linked data architectural space, where you =
put things at their URI location, and you try to restrict yourself to =
the RESTful verbs (GET, PUT, POST, DELETE)

>=20
> I think it would be entirely appropriate to use DNS assured keys to =
validate an XKMS service.=20
> We could also take the XKMS schema and use it within FOAF.

yes, so with WebID we use the DNS assured keys, to power up TLS, so that =
https becomes a way to validate the foaf document returned - that it has =
not been corrupted on the way. So that way we have part of the work of =
what XKMS does, but using simple HTTP. (Need to study XKMS in more =
detail)

> I think that there are many possibilities here. But they are way off =
topic for this group.=20

Yes.

> Would it be possible for people interested in this area to Bar BoF in =
Prague?

(I am in Paris btw. But let me know).

Don't forget the issue that I raised that is relevant to this group, =
namely the idea of putting the public keys in DNS, without all the extra =
stuff.

Henry

>=20
> On Fri, Feb 11, 2011 at 7:19 AM, Henry Story <[email-masked]> =
wrote:
>=20
> On 11 Feb 2011, at 01:48, Paul Hoffman wrote:
>=20
> > On 2/10/11 2:41 PM, Henry Story wrote:
> >> Keyassure will probably use the DNS-ID typed subject alternative =
name
> >> (SAN) or Issuer Alternative Name (IAN) in a *server* X509 =
certifactes
> >> to identify the server as suggested is good practice by
> >> =
http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-14#section=
-2.3
> >
> > In your earlier message, you said:
> >
> >> (I have not seen a draft spec yet, and am going from the group
> >> description).
> >
> > Please do read the draft. What you say here, which predicates the =
rest
> > of your message about similarities with the WebID work, is not at =
all
> > correct.
>=20
> Yes, I just read the draft dane 4
> http://tools.ietf.org/html/draft-ietf-dane-protocol-04
>=20
> I don't think I was far off, but still perhaps too cryptic. In section =
2.2 it states that there are four types of things that can be published =
in the TLSA record
>=20
>  1 -- Hash of an end-entity certificate
>  2 -- Full end-entity certificate in DER encoding
>  3 -- Hash of an certification authority's certificate
>  4 -- Full certification authority's certificate in DER encoding
>=20
> So if in 2 the certificate is a DER encoded X509 cert, then if it is a =
server certificate it should contain according to draft-saintandre the =
Domain Name in the SAN field. There are a few different types of SAN =
fields: DNS-ID, SRV-ID and URI-ID. SRV-ID which is defined by rfc4985 is =
a lot closer to what you are specifying in the RDATA format. (Though it =
looks like that RFC could be improved to allow port numbers to be =
specified, as you do)
>=20
> So if someone came across such a certificate with such a SRV-ID, they =
could after finding the SAN do a lookup in DNSSEC and verify that this =
is indeed the correct/current certificate. In some ways this is similar =
to finding an html page with a
>    <link rel=3D"self" href=3D"http://bblfish.net/"/>
> You could use it to lookup the current version of the page. What you =
have in your hand is a cached copy.
>=20
> Now if you do one more little conceptual jump and you allow that one =
can name things including agents with an http(s) URI then he can put =
that URI in the SAN field. So I have a WebID
>=20
>   http://bblfish.net/people/henry/card#me
>=20
> Doing a lookup using HTTP will get the meaning of that URI - and so a =
description of me. That URI could return a PEM certificate too, just as =
you do in the DNS lookup (we are discussing allowing this in addition to =
RDF/XML, rdfa, or other XML representations)
>=20
>   Good so I think we have two protocols - yours and WebID - that both =
can do the following and that are very similar in those respect:
>=20
>   1. place an identifier in the X.509 SAN field.
>      - for keyassure this is a service identifier (SRV-ID)
>      - for webid this is a URI identifier
>   2. dereference the ID to get the latest version
>      - using DNS lookup for keyassure
>      - using HTTP/HTTPS/ftp... lookup for WebID
>   3. Proving authenticity
>   both protocols use the information retrieved canonically at the =
identifier to prove authenticity.
>      - with WebID the relying party uses the public key published =
there to verify that the agent connecting to it is indeed named by that =
URI. He is if he could prove in the TLS handshake that he knew the =
corresponding private key.
>      - with keyassure by proving that there is the appropriate link =
between the keys/signature published in 1-4 and the certificate sent by =
the TLS server.
>=20
>   Essentially point 3 - proving authenticity - works because of what =
you name a trust anchor. I am just pointing out that this trust anchor =
is tied to a naming system and a canonical lookup procedure in both =
cases.
>=20
>   Ok, so I think that demonstrates quite clearly that there are a lot =
of similarities. So what is the use of knowing that?
>=20
>   Well I think for me that helps confirm my WebID intuitions. When I =
spoke to Dan Kaminsky after his talk "X509 considered harmful" [1] a few =
years ago, the possibility of something like keyassure helped me feel we =
could bypass the most damaging of his critiques against the current PKI =
setup. WebID does not need CAs, and with keyassure web servers won't =
need them either. We are still left with the clumsy ASN.1 format, but =
that can be solved over time with better parsers, or, since TLS allows =
it, to some better defined format such as binary xml perhaps.
>=20
>   Another advantage of having two very similar protocols developing, =
especially as they are not stepping on each others toes, is that we may =
be able to learn a few tricks from one another. So here is one initial =
idea that occurred to me reading your spec today.
>=20
>   =3D=3D IDEA =3D=3D
>=20
>   Currently you are publishing either a signature or a certificate in =
the DNS. Why not publish the only piece of the certificate that is =
important: the public key. This is what WebID does. This should be =
shorter than the certificate, and though it will be longer than the =
signature, it will be a lot more useful, tying you much less to a =
particular serialisation format.
>=20
>  There is no need to send a full certificate. All you need is to tie a =
name to a public key and to guarantee to the end user the integrity of =
the information. But the integrity is itself assured by DNSSEC. The =
tying of the name to the public key is done by the lookup in DNS. So all =
that is really required is to return the public key - the type and the =
fields.
>=20
>  One could then even imagine a TLS improvement where the server would =
not need to send his certificate either. All the TLS server would need =
to do is prove that he can encrypt something with his private key. The =
public key would be fetched from the DNS. So at that point we will have =
gotten rid of ASN.1 or at least just kept the minimum needed. This would =
be the server equivalent of the client_certificate_url extension of TLS =
1.2 where the client can send a URL to a location of his certificate, =
instead of sending his certificate. Here the server would not need to =
send his certificate, and for self signed certificates, the DNS sending =
the public key would be enough anyway.
>=20
>  So I hope this helps clarify the similarities of the two protocols as =
well as the usefulness of our interaction.
>=20
> > This is not to say that what WebID is doing can't work with the DANE =
effort, just that we are doing completely different things. DANE is =
about getting a temporary trust anchor for a particular =
port/transport/domainname triple for a server, whereas WebID is about =
identifying clients through an HTTPS lookup. There has been discussion =
of using DANE to get a temporary trust anchor for S/MIME clients, and =
that might be extended to doing so for TLS clients, but it would be done =
using the DNS protocol.
>=20
> yes, that is where each of us understanding the other could help see =
where some of these things would fit best. S/MIME it seems to me is =
closer to client authentication, and so would better fit in with WebID.
>=20
>        Henry Story
>=20
> [1] http://blogs.sun.com/bblfish/entry/camping_and_hacking_at_har2009
>=20
>=20
>=20
>=20
> --=20
> Website: http://hallambaker.com/
>=20

--Apple-Mail-4--845477204
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 11 Feb 2011, at 15:14, Phillip Hallam-Baker =
wrote:</div><br class=3D"Apple-interchange-newline"><blockquote =
type=3D"cite"><div>[Before reading this in the context of 'PKI vendor =
speaks', I would like to point out to people on the list that Comodo is =
now an announced provider of DNS services under the brand =
DNS.com.]</div><div><br></div>
<div><br></div>It is not very clear to me what is being proposed =
here.</blockquote><div><br></div><div>I was not proposing anything to =
start of with, other than to show at what level the protocols are =
similar.&nbsp;That of course cannot be a proposal, only a point of =
interest.&nbsp;</div><div><br></div><div>Noticing that similarity was =
useful in helping me understand what keyassure is doing. &nbsp;And =
understanding that similarity also led me to ask why&nbsp;you don't also =
allow one to publish the plain and simple public key &nbsp;in addition =
perhaps to the 4 methods listed in section 2.2 of draft-4. My point =
there was that that should be enough to do a lot of what you want. See =
the =3D=3DIDEA=3D=3D section. The supporting evidence for this is that =
this is enough for us at the WebID =
level.&nbsp;</div><div><br></div><div><br></div><br><blockquote =
type=3D"cite"><div>Let's start from first principles. As far as internet =
users are concerned, an Internet user identifier is <a =
href=3D"mailto:[email-masked]">[email-masked]</a></div></blockquote><d=
iv><br></div><div>In WebID we consider essentially an http url such as =
<a href=3D"http://bblfish.net/#me">http://bblfish.net/#me</a> as it is =
immediately dereferenceable,</div><br><blockquote type=3D"cite">
<div>I know that there are people trying to peddle URIs as user =
identifiers but the success of that approach is evidenced by the fact =
that OpenID support is contracting rather than =
expanding.</div></blockquote><div><br></div><div>There are many reasons =
why OpenId is having trouble. The main one being that the user has to =
remember what to type, and has to type it. With WebID this is integrated =
into the SSL layer, so the user only needs to point and click. There is =
a 4 minute video on <a =
href=3D"http://bblfish.net/">http://bblfish.net/</a> (the second one) =
that demonstrates this.&nbsp;</div><div><br></div><div>There is a whole =
list of other reasons why TLS works better, many of them I have gathered =
here</div><div><a =
href=3D"http://www.w3.org/wiki/Foaf+ssl/FAQ#OpenID_failed.2C_do_people_rea=
lly_want_distributed_identity.3F">http://www.w3.org/wiki/Foaf%2Bssl/FAQ#Op=
enID_failed.2C_do_people_really_want_distributed_identity.3F</a></div><div=
><br></div><br><blockquote type=3D"cite"><div><br>
</div><div>Given <a href=3D"mailto:[email-masked]">[email-masked]</a> =
as the identifier,&nbsp;</div><div><br></div><div>DNS is an appropriate =
mechanism to resolve attributes bound to&nbsp;the '<a =
href=3D"http://example.com/">example.com</a>' =
portion.</div></blockquote><div><br></div><div>exactly. DNS is the =
Canonical lookup method for a DNS name :-)</div><br><blockquote =
type=3D"cite">
<div><br></div><div>DNS is an appropriate mechanism to use to discover a =
service that can resolve the 'user' portion for '<a =
href=3D"http://example.com/">example.com</a></div></blockquote><div><br></=
div><div>yes (though if it can be avoided then that can be better) But =
it gives some useful flexibility.</div><br><blockquote =
type=3D"cite"><div>DNS is not an appropriate place to store attributes =
specific to '<a =
href=3D"mailto:[email-masked]">[email-masked]</a>'.</div></blockquote>=
<div><br></div>Completely agree.&nbsp;<br><br><blockquote =
type=3D"cite"><div><br></div><div><br></div><div>We already have a Web =
Service that is designed to serve as a key centric distribution =
mechanism for per-user data and it happens to be a W3C recommendation - =
XKMS.</div></blockquote><div><br></div><div>Thanks for pointing that one =
out. It looks like one of the SOAPy specs. This should be =
useful.</div><div>WebID is working within the linked data architectural =
space, where you put things at their URI location, and you try to =
restrict yourself to the RESTful verbs (GET, PUT, POST, =
DELETE)</div><br><blockquote type=3D"cite">
<div><br></div><div>I think it would be entirely appropriate to use DNS =
assured keys to validate an XKMS service.&nbsp;</div><div>We could also =
take the XKMS schema and use it within =
FOAF.</div></blockquote><div><br></div><div>yes, so with WebID we use =
the DNS assured keys, to power up TLS, so that https becomes a way to =
validate the foaf document returned - that it has not been corrupted on =
the way. So that way we have part of the work of what XKMS does, but =
using simple HTTP. (Need to study XKMS in more =
detail)</div><br><blockquote type=3D"cite"><div>I think that there are =
many possibilities here. But they are way off topic for this =
group.&nbsp;</div></blockquote><div><br></div><div>Yes.</div><div><br></di=
v><br><blockquote type=3D"cite"><div>Would it be possible for people =
interested in this area to Bar BoF in =
Prague?</div></blockquote><div><br></div><div>(I am in Paris btw. But =
let me know).</div><div><br></div><div>Don't forget the issue that I =
raised that is relevant to this group, namely the idea of putting the =
public keys in DNS, without all the extra =
stuff.</div><div><br></div><div>Henry</div><div><br></div><br><blockquote =
type=3D"cite"><div>
<br><div class=3D"gmail_quote">On Fri, Feb 11, 2011 at 7:19 AM, 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-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 class=3D"im"><br>
On 11 Feb 2011, at 01:48, Paul Hoffman wrote:<br>
<br>
&gt; On 2/10/11 2:41 PM, Henry Story wrote:<br>
&gt;&gt; Keyassure will probably use the DNS-ID typed subject =
alternative name<br>
&gt;&gt; (SAN) or Issuer Alternative Name (IAN) in a *server* X509 =
certifactes<br>
&gt;&gt; to identify the server as suggested is good practice by<br>
&gt;&gt; <a =
href=3D"http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-14=
#section-2.3" =
target=3D"_blank">http://tools.ietf.org/html/draft-saintandre-tls-server-i=
d-check-14#section-2.3</a><br>
&gt;<br>
&gt; In your earlier message, you said:<br>
&gt;<br>
&gt;&gt; (I have not seen a draft spec yet, and am going from the =
group<br>
&gt;&gt; description).<br>
&gt;<br>
&gt; Please do read the draft. What you say here, which predicates the =
rest<br>
&gt; of your message about similarities with the WebID work, is not at =
all<br>
&gt; correct.<br>
<br>
</div>Yes, I just read the draft dane 4<br>
<a href=3D"http://tools.ietf.org/html/draft-ietf-dane-protocol-04" =
target=3D"_blank">http://tools.ietf.org/html/draft-ietf-dane-protocol-04</=
a><br>
<br>
I don't think I was far off, but still perhaps too cryptic. In section =
2.2 it states that there are four types of things that can be published =
in the TLSA record<br>
<br>
&nbsp;1 -- Hash of an end-entity certificate<br>
&nbsp;2 -- Full end-entity certificate in DER encoding<br>
&nbsp;3 -- Hash of an certification authority's certificate<br>
&nbsp;4 -- Full certification authority's certificate in DER =
encoding<br>
<br>
So if in 2 the certificate is a DER encoded X509 cert, then if it is a =
server certificate it should contain according to draft-saintandre the =
Domain Name in the SAN field. There are a few different types of SAN =
fields: DNS-ID, SRV-ID and URI-ID. SRV-ID which is defined by rfc4985 is =
a lot closer to what you are specifying in the RDATA format. (Though it =
looks like that RFC could be improved to allow port numbers to be =
specified, as you do)<br>

<br>
So if someone came across such a certificate with such a SRV-ID, they =
could after finding the SAN do a lookup in DNSSEC and verify that this =
is indeed the correct/current certificate. In some ways this is similar =
to finding an html page with a<br>

 &nbsp; &nbsp;&lt;link rel=3D"self" href=3D"<a =
href=3D"http://bblfish.net/" =
target=3D"_blank">http://bblfish.net/</a>"/&gt;<br>
You could use it to lookup the current version of the page. What you =
have in your hand is a cached copy.<br>
<br>
Now if you do one more little conceptual jump and you allow that one can =
name things including agents with an http(s) URI then he can put that =
URI in the SAN field. So I have a WebID<br>
<br>
 &nbsp; <a href=3D"http://bblfish.net/people/henry/card#me" =
target=3D"_blank">http://bblfish.net/people/henry/card#me</a><br>
<br>
Doing a lookup using HTTP will get the meaning of that URI - and so a =
description of me. That URI could return a PEM certificate too, just as =
you do in the DNS lookup (we are discussing allowing this in addition to =
RDF/XML, rdfa, or other XML representations)<br>

<br>
 &nbsp; Good so I think we have two protocols - yours and WebID - that =
both can do the following and that are very similar in those =
respect:<br>
<br>
 &nbsp; 1. place an identifier in the X.509 SAN field.<br>
 &nbsp; &nbsp; &nbsp;- for keyassure this is a service identifier =
(SRV-ID)<br>
 &nbsp; &nbsp; &nbsp;- for webid this is a URI identifier<br>
 &nbsp; 2. dereference the ID to get the latest version<br>
 &nbsp; &nbsp; &nbsp;- using DNS lookup for keyassure<br>
 &nbsp; &nbsp; &nbsp;- using HTTP/HTTPS/ftp... lookup for WebID<br>
 &nbsp; 3. Proving authenticity<br>
 &nbsp; both protocols use the information retrieved canonically at the =
identifier to prove authenticity.<br>
 &nbsp; &nbsp; &nbsp;- with WebID the relying party uses the public key =
published there to verify that the agent connecting to it is indeed =
named by that URI. He is if he could prove in the TLS handshake that he =
knew the corresponding private key.<br>

 &nbsp; &nbsp; &nbsp;- with keyassure by proving that there is the =
appropriate link between the keys/signature published in 1-4 and the =
certificate sent by the TLS server.<br>
<br>
 &nbsp; Essentially point 3 - proving authenticity - works because of =
what you name a trust anchor. I am just pointing out that this trust =
anchor is tied to a naming system and a canonical lookup procedure in =
both cases.<br>
<br>
 &nbsp; Ok, so I think that demonstrates quite clearly that there are a =
lot of similarities. So what is the use of knowing that?<br>
<br>
 &nbsp; Well I think for me that helps confirm my WebID intuitions. When =
I spoke to Dan Kaminsky after his talk "X509 considered harmful" [1] a =
few years ago, the possibility of something like keyassure helped me =
feel we could bypass the most damaging of his critiques against the =
current PKI setup. WebID does not need CAs, and with keyassure web =
servers won't need them either. We are still left with the clumsy ASN.1 =
format, but that can be solved over time with better parsers, or, since =
TLS allows it, to some better defined format such as binary xml =
perhaps.<br>

<br>
 &nbsp; Another advantage of having two very similar protocols =
developing, especially as they are not stepping on each others toes, is =
that we may be able to learn a few tricks from one another. So here is =
one initial idea that occurred to me reading your spec today.<br>

<br>
 &nbsp; =3D=3D IDEA =3D=3D<br>
<br>
 &nbsp; Currently you are publishing either a signature or a certificate =
in the DNS. Why not publish the only piece of the certificate that is =
important: the public key. This is what WebID does. This should be =
shorter than the certificate, and though it will be longer than the =
signature, it will be a lot more useful, tying you much less to a =
particular serialisation format.<br>

<br>
 &nbsp;There is no need to send a full certificate. All you need is to =
tie a name to a public key and to guarantee to the end user the =
integrity of the information. But the integrity is itself assured by =
DNSSEC. The tying of the name to the public key is done by the lookup in =
DNS. So all that is really required is to return the public key - the =
type and the fields.<br>

<br>
 &nbsp;One could then even imagine a TLS improvement where the server =
would not need to send his certificate either. All the TLS server would =
need to do is prove that he can encrypt something with his private key. =
The public key would be fetched from the DNS. So at that point we will =
have gotten rid of ASN.1 or at least just kept the minimum needed. This =
would be the server equivalent of the client_certificate_url extension =
of TLS 1.2 where the client can send a URL to a location of his =
certificate, instead of sending his certificate. Here the server would =
not need to send his certificate, and for self signed certificates, the =
DNS sending the public key would be enough anyway.<br>

<br>
 &nbsp;So I hope this helps clarify the similarities of the two =
protocols as well as the usefulness of our interaction.<br>
<div class=3D"im"><br>
&gt; This is not to say that what WebID is doing can't work with the =
DANE effort, just that we are doing completely different things. DANE is =
about getting a temporary trust anchor for a particular =
port/transport/domainname triple for a server, whereas WebID is about =
identifying clients through an HTTPS lookup. There has been discussion =
of using DANE to get a temporary trust anchor for S/MIME clients, and =
that might be extended to doing so for TLS clients, but it would be done =
using the DNS protocol.<br>

<br>
</div>yes, that is where each of us understanding the other could help =
see where some of these things would fit best. S/MIME it seems to me is =
closer to client authentication, and so would better fit in with =
WebID.<br>
<br>
 &nbsp; &nbsp; &nbsp; &nbsp;Henry Story<br>
<br>
[1] <a =
href=3D"http://blogs.sun.com/bblfish/entry/camping_and_hacking_at_har2009"=
 =
target=3D"_blank">http://blogs.sun.com/bblfish/entry/camping_and_hacking_a=
t_har2009</a><br>
<div><div></div><div class=3D"h5"><font class=3D"Apple-style-span" =
color=3D"#000000"><font class=3D"Apple-style-span" =
color=3D"#144FAE"><br></font></font></div></div></blockquote></div></div><=
/blockquote><blockquote type=3D"cite"><div><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><div class=3D"h5">
</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></body></html>=

--Apple-Mail-4--845477204--

Date: Fri, 11 Feb 2011 09:14:37 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Henry Story <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] WebID at W3C and keyassure

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

[Before reading this in the context of 'PKI vendor speaks', I would like to
point out to people on the list that Comodo is now an announced provider of
DNS services under the brand DNS.com.]

It is not very clear to me what is being proposed here.

Let's start from first principles. As far as internet users are concerned,
an Internet user identifier is [email-masked]

I know that there are people trying to peddle URIs as user identifiers but
the success of that approach is evidenced by the fact that OpenID support is
contracting rather than expanding.

Given [email-masked] as the identifier,

DNS is an appropriate mechanism to resolve attributes bound to the '
example.com' portion.

DNS is an appropriate mechanism to use to discover a service that can
resolve the 'user' portion for 'example.com'

DNS is not an appropriate place to store attributes specific to '
[email-masked]'.

We already have a Web Service that is designed to serve as a key centric
distribution mechanism for per-user data and it happens to be a W3C
recommendation - XKMS.

I think it would be entirely appropriate to use DNS assured keys to validate
an XKMS service.

We could also take the XKMS schema and use it within FOAF.

I think that there are many possibilities here. But they are way off topic
for this group.

Would it be possible for people interested in this area to Bar BoF in
Prague?

On Fri, Feb 11, 2011 at 7:19 AM, Henry Story <[email-masked]>wrote:

>
> On 11 Feb 2011, at 01:48, Paul Hoffman wrote:
>
> > On 2/10/11 2:41 PM, Henry Story wrote:
> >> Keyassure will probably use the DNS-ID typed subject alternative name
> >> (SAN) or Issuer Alternative Name (IAN) in a *server* X509 certifactes
> >> to identify the server as suggested is good practice by
> >>
> http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-14#section-2.3
> >
> > In your earlier message, you said:
> >
> >> (I have not seen a draft spec yet, and am going from the group
> >> description).
> >
> > Please do read the draft. What you say here, which predicates the rest
> > of your message about similarities with the WebID work, is not at all
> > correct.
>
> Yes, I just read the draft dane 4
> http://tools.ietf.org/html/draft-ietf-dane-protocol-04
>
> I don't think I was far off, but still perhaps too cryptic. In section 2.2
> it states that there are four types of things that can be published in the
> TLSA record
>
>  1 -- Hash of an end-entity certificate
>  2 -- Full end-entity certificate in DER encoding
>  3 -- Hash of an certification authority's certificate
>  4 -- Full certification authority's certificate in DER encoding
>
> So if in 2 the certificate is a DER encoded X509 cert, then if it is a
> server certificate it should contain according to draft-saintandre the
> Domain Name in the SAN field. There are a few different types of SAN fields:
> DNS-ID, SRV-ID and URI-ID. SRV-ID which is defined by rfc4985 is a lot
> closer to what you are specifying in the RDATA format. (Though it looks like
> that RFC could be improved to allow port numbers to be specified, as you do)
>
> So if someone came across such a certificate with such a SRV-ID, they could
> after finding the SAN do a lookup in DNSSEC and verify that this is indeed
> the correct/current certificate. In some ways this is similar to finding an
> html page with a
>    <link rel="self" href="http://bblfish.net/"/>
> You could use it to lookup the current version of the page. What you have
> in your hand is a cached copy.
>
> Now if you do one more little conceptual jump and you allow that one can
> name things including agents with an http(s) URI then he can put that URI in
> the SAN field. So I have a WebID
>
>   http://bblfish.net/people/henry/card#me
>
> Doing a lookup using HTTP will get the meaning of that URI - and so a
> description of me. That URI could return a PEM certificate too, just as you
> do in the DNS lookup (we are discussing allowing this in addition to
> RDF/XML, rdfa, or other XML representations)
>
>   Good so I think we have two protocols - yours and WebID - that both can
> do the following and that are very similar in those respect:
>
>   1. place an identifier in the X.509 SAN field.
>      - for keyassure this is a service identifier (SRV-ID)
>      - for webid this is a URI identifier
>   2. dereference the ID to get the latest version
>      - using DNS lookup for keyassure
>      - using HTTP/HTTPS/ftp... lookup for WebID
>   3. Proving authenticity
>   both protocols use the information retrieved canonically at the
> identifier to prove authenticity.
>      - with WebID the relying party uses the public key published there to
> verify that the agent connecting to it is indeed named by that URI. He is if
> he could prove in the TLS handshake that he knew the corresponding private
> key.
>      - with keyassure by proving that there is the appropriate link between
> the keys/signature published in 1-4 and the certificate sent by the TLS
> server.
>
>   Essentially point 3 - proving authenticity - works because of what you
> name a trust anchor. I am just pointing out that this trust anchor is tied
> to a naming system and a canonical lookup procedure in both cases.
>
>   Ok, so I think that demonstrates quite clearly that there are a lot of
> similarities. So what is the use of knowing that?
>
>   Well I think for me that helps confirm my WebID intuitions. When I spoke
> to Dan Kaminsky after his talk "X509 considered harmful" [1] a few years
> ago, the possibility of something like keyassure helped me feel we could
> bypass the most damaging of his critiques against the current PKI setup.
> WebID does not need CAs, and with keyassure web servers won't need them
> either. We are still left with the clumsy ASN.1 format, but that can be
> solved over time with better parsers, or, since TLS allows it, to some
> better defined format such as binary xml perhaps.
>
>   Another advantage of having two very similar protocols developing,
> especially as they are not stepping on each others toes, is that we may be
> able to learn a few tricks from one another. So here is one initial idea
> that occurred to me reading your spec today.
>
>   == IDEA ==
>
>   Currently you are publishing either a signature or a certificate in the
> DNS. Why not publish the only piece of the certificate that is important:
> the public key. This is what WebID does. This should be shorter than the
> certificate, and though it will be longer than the signature, it will be a
> lot more useful, tying you much less to a particular serialisation format.
>
>  There is no need to send a full certificate. All you need is to tie a name
> to a public key and to guarantee to the end user the integrity of the
> information. But the integrity is itself assured by DNSSEC. The tying of the
> name to the public key is done by the lookup in DNS. So all that is really
> required is to return the public key - the type and the fields.
>
>  One could then even imagine a TLS improvement where the server would not
> need to send his certificate either. All the TLS server would need to do is
> prove that he can encrypt something with his private key. The public key
> would be fetched from the DNS. So at that point we will have gotten rid of
> ASN.1 or at least just kept the minimum needed. This would be the server
> equivalent of the client_certificate_url extension of TLS 1.2 where the
> client can send a URL to a location of his certificate, instead of sending
> his certificate. Here the server would not need to send his certificate, and
> for self signed certificates, the DNS sending the public key would be enough
> anyway.
>
>  So I hope this helps clarify the similarities of the two protocols as well
> as the usefulness of our interaction.
>
> > This is not to say that what WebID is doing can't work with the DANE
> effort, just that we are doing completely different things. DANE is about
> getting a temporary trust anchor for a particular port/transport/domainname
> triple for a server, whereas WebID is about identifying clients through an
> HTTPS lookup. There has been discussion of using DANE to get a temporary
> trust anchor for S/MIME clients, and that might be extended to doing so for
> TLS clients, but it would be done using the DNS protocol.
>
> yes, that is where each of us understanding the other could help see where
> some of these things would fit best. S/MIME it seems to me is closer to
> client authentication, and so would better fit in with WebID.
>
>        Henry Story
>
> [1] http://blogs.sun.com/bblfish/entry/camping_and_hacking_at_har2009
>
>
>
>
>
>
>
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

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

<div>[Before reading this in the context of &#39;PKI vendor speaks&#39;, I =
would like to point out to people on the list that Comodo is now an announc=
ed provider of DNS services under the brand DNS.com.]</div><div><br></div>
<div><br></div>It is not very clear to me what is being proposed here.<div>=
<br></div><div>Let&#39;s start from first principles. As far as internet us=
ers are concerned, an Internet user identifier is <a href=3D"mailto:user@ex=
ample.com">[email-masked]</a></div>
<div><br></div><div>I know that there are people trying to peddle URIs as u=
ser identifiers but the success of that approach is evidenced by the fact t=
hat OpenID support is contracting rather than expanding.</div><div><br>
</div><div><br></div><div>Given <a href=3D"mailto:[email-masked]">user@ex=
ample.com</a> as the identifier,=A0</div><div><br></div><div>DNS is an appr=
opriate mechanism to resolve attributes bound to=A0the &#39;<a href=3D"http=
://example.com">example.com</a>&#39; portion.</div>
<div><br></div><div><meta charset=3D"utf-8">DNS is an appropriate mechanism=
 to use to discover a service that can resolve the &#39;user&#39; portion f=
or &#39;<a href=3D"http://example.com">example.com</a>&#39;</div><div><br><=
/div>
<div>DNS is not an appropriate place to store attributes specific to &#39;<=
a href=3D"mailto:[email-masked]">[email-masked]</a>&#39;.</div><div><br=
></div><div><br></div><div>We already have a Web Service that is designed t=
o serve as a key centric distribution mechanism for per-user data and it ha=
ppens to be a W3C recommendation - XKMS.</div>
<div><br></div><div>I think it would be entirely appropriate to use DNS ass=
ured keys to validate an XKMS service.=A0</div><div><br></div><div>We could=
 also take the XKMS schema and use it within FOAF.</div><div><br></div><div=
>
<br></div><div>I think that there are many possibilities here. But they are=
 way off topic for this group.=A0</div><div><br></div><div>Would it be poss=
ible for people interested in this area to Bar BoF in Prague?</div><div><br=
>
<br><div class=3D"gmail_quote">On Fri, Feb 11, 2011 at 7:19 AM, Henry Story=
 <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">henry.sto=
[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 11 Feb 2011, at 01:48, Paul Hoffman wrote:<br>
<br>
&gt; On 2/10/11 2:41 PM, Henry Story wrote:<br>
&gt;&gt; Keyassure will probably use the DNS-ID typed subject alternative n=
ame<br>
&gt;&gt; (SAN) or Issuer Alternative Name (IAN) in a *server* X509 certifac=
tes<br>
&gt;&gt; to identify the server as suggested is good practice by<br>
&gt;&gt; <a href=3D"http://tools.ietf.org/html/draft-saintandre-tls-server-=
id-check-14#section-2.3" target=3D"_blank">http://tools.ietf.org/html/draft=
-saintandre-tls-server-id-check-14#section-2.3</a><br>
&gt;<br>
&gt; In your earlier message, you said:<br>
&gt;<br>
&gt;&gt; (I have not seen a draft spec yet, and am going from the group<br>
&gt;&gt; description).<br>
&gt;<br>
&gt; Please do read the draft. What you say here, which predicates the rest=
<br>
&gt; of your message about similarities with the WebID work, is not at all<=
br>
&gt; correct.<br>
<br>
</div>Yes, I just read the draft dane 4<br>
<a href=3D"http://tools.ietf.org/html/draft-ietf-dane-protocol-04" target=
=3D"_blank">http://tools.ietf.org/html/draft-ietf-dane-protocol-04</a><br>
<br>
I don&#39;t think I was far off, but still perhaps too cryptic. In section =
2.2 it states that there are four types of things that can be published in =
the TLSA record<br>
<br>
=A01 -- Hash of an end-entity certificate<br>
=A02 -- Full end-entity certificate in DER encoding<br>
=A03 -- Hash of an certification authority&#39;s certificate<br>
=A04 -- Full certification authority&#39;s certificate in DER encoding<br>
<br>
So if in 2 the certificate is a DER encoded X509 cert, then if it is a serv=
er certificate it should contain according to draft-saintandre the Domain N=
ame in the SAN field. There are a few different types of SAN fields: DNS-ID=
, SRV-ID and URI-ID. SRV-ID which is defined by rfc4985 is a lot closer to =
what you are specifying in the RDATA format. (Though it looks like that RFC=
 could be improved to allow port numbers to be specified, as you do)<br>

<br>
So if someone came across such a certificate with such a SRV-ID, they could=
 after finding the SAN do a lookup in DNSSEC and verify that this is indeed=
 the correct/current certificate. In some ways this is similar to finding a=
n html page with a<br>

 =A0 =A0&lt;link rel=3D&quot;self&quot; href=3D&quot;<a href=3D"http://bblf=
ish.net/" target=3D"_blank">http://bblfish.net/</a>&quot;/&gt;<br>
You could use it to lookup the current version of the page. What you have i=
n your hand is a cached copy.<br>
<br>
Now if you do one more little conceptual jump and you allow that one can na=
me things including agents with an http(s) URI then he can put that URI in =
the SAN field. So I have a WebID<br>
<br>
 =A0 <a href=3D"http://bblfish.net/people/henry/card#me" target=3D"_blank">=
http://bblfish.net/people/henry/card#me</a><br>
<br>
Doing a lookup using HTTP will get the meaning of that URI - and so a descr=
iption of me. That URI could return a PEM certificate too, just as you do i=
n the DNS lookup (we are discussing allowing this in addition to RDF/XML, r=
dfa, or other XML representations)<br>

<br>
 =A0 Good so I think we have two protocols - yours and WebID - that both ca=
n do the following and that are very similar in those respect:<br>
<br>
 =A0 1. place an identifier in the X.509 SAN field.<br>
 =A0 =A0 =A0- for keyassure this is a service identifier (SRV-ID)<br>
 =A0 =A0 =A0- for webid this is a URI identifier<br>
 =A0 2. dereference the ID to get the latest version<br>
 =A0 =A0 =A0- using DNS lookup for keyassure<br>
 =A0 =A0 =A0- using HTTP/HTTPS/ftp... lookup for WebID<br>
 =A0 3. Proving authenticity<br>
 =A0 both protocols use the information retrieved canonically at the identi=
fier to prove authenticity.<br>
 =A0 =A0 =A0- with WebID the relying party uses the public key published th=
ere to verify that the agent connecting to it is indeed named by that URI. =
He is if he could prove in the TLS handshake that he knew the corresponding=
 private key.<br>

 =A0 =A0 =A0- with keyassure by proving that there is the appropriate link =
between the keys/signature published in 1-4 and the certificate sent by the=
 TLS server.<br>
<br>
 =A0 Essentially point 3 - proving authenticity - works because of what you=
 name a trust anchor. I am just pointing out that this trust anchor is tied=
 to a naming system and a canonical lookup procedure in both cases.<br>
<br>
 =A0 Ok, so I think that demonstrates quite clearly that there are a lot of=
 similarities. So what is the use of knowing that?<br>
<br>
 =A0 Well I think for me that helps confirm my WebID intuitions. When I spo=
ke to Dan Kaminsky after his talk &quot;X509 considered harmful&quot; [1] a=
 few years ago, the possibility of something like keyassure helped me feel =
we could bypass the most damaging of his critiques against the current PKI =
setup. WebID does not need CAs, and with keyassure web servers won&#39;t ne=
ed them either. We are still left with the clumsy ASN.1 format, but that ca=
n be solved over time with better parsers, or, since TLS allows it, to some=
 better defined format such as binary xml perhaps.<br>

<br>
 =A0 Another advantage of having two very similar protocols developing, esp=
ecially as they are not stepping on each others toes, is that we may be abl=
e to learn a few tricks from one another. So here is one initial idea that =
occurred to me reading your spec today.<br>

<br>
 =A0 =3D=3D IDEA =3D=3D<br>
<br>
 =A0 Currently you are publishing either a signature or a certificate in th=
e DNS. Why not publish the only piece of the certificate that is important:=
 the public key. This is what WebID does. This should be shorter than the c=
ertificate, and though it will be longer than the signature, it will be a l=
ot more useful, tying you much less to a particular serialisation format.<b=
r>

<br>
 =A0There is no need to send a full certificate. All you need is to tie a n=
ame to a public key and to guarantee to the end user the integrity of the i=
nformation. But the integrity is itself assured by DNSSEC. The tying of the=
 name to the public key is done by the lookup in DNS. So all that is really=
 required is to return the public key - the type and the fields.<br>

<br>
 =A0One could then even imagine a TLS improvement where the server would no=
t need to send his certificate either. All the TLS server would need to do =
is prove that he can encrypt something with his private key. The public key=
 would be fetched from the DNS. So at that point we will have gotten rid of=
 ASN.1 or at least just kept the minimum needed. This would be the server e=
quivalent of the client_certificate_url extension of TLS 1.2 where the clie=
nt can send a URL to a location of his certificate, instead of sending his =
certificate. Here the server would not need to send his certificate, and fo=
r self signed certificates, the DNS sending the public key would be enough =
anyway.<br>

<br>
 =A0So I hope this helps clarify the similarities of the two protocols as w=
ell as the usefulness of our interaction.<br>
<div class=3D"im"><br>
&gt; This is not to say that what WebID is doing can&#39;t work with the DA=
NE effort, just that we are doing completely different things. DANE is abou=
t getting a temporary trust anchor for a particular port/transport/domainna=
me triple for a server, whereas WebID is about identifying clients through =
an HTTPS lookup. There has been discussion of using DANE to get a temporary=
 trust anchor for S/MIME clients, and that might be extended to doing so fo=
r TLS clients, but it would be done using the DNS protocol.<br>

<br>
</div>yes, that is where each of us understanding the other could help see =
where some of these things would fit best. S/MIME it seems to me is closer =
to client authentication, and so would better fit in with WebID.<br>
<br>
 =A0 =A0 =A0 =A0Henry Story<br>
<br>
[1] <a href=3D"http://blogs.sun.com/bblfish/entry/camping_and_hacking_at_ha=
r2009" target=3D"_blank">http://blogs.sun.com/bblfish/entry/camping_and_hac=
king_at_har2009</a><br>
<div><div></div><div class=3D"h5"><br>
<br>
<br>
<br>
<br>
<br>
<br>
<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>
</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>

--001636b43247785b9a049c0251b0--

Date: Fri, 11 Feb 2011 09:01:39 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Yaron Sheffer <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] dane-04 trust anchors

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

This is an issue, but a fairly easy one to deal with and one that is already
dealt with when dealing with self-signed certs. The browser writers know
this stuff already.

Some of the people who were doing security code in 1995 were clueless. In
fact we all pretty much were (but in different ways). But that has not been
an issue since Netscape hired Taher and the brothers Weinstein.

There is a very simple principle here:

DNS cannot extend any positive claims beyond the DNS name itself

DNS can however extend negative claims and restrictions.

A domain can't say 'trust me I am a bank' but it can say 'take extra
security precautions, in case I am a bank'

On Fri, Feb 11, 2011 at 2:26 AM, Yaron Sheffer <[email-masked]>wrote:

> Hi,
>
> the new text is a major improvement over the previous version. But it is
> still missing some necessary guidance.
>
> My reference scenario is this: I am a phisher. I'd like to trick BigBank's
> customers, so I acquire bigbang.com (an easy misspelling). Now I can get a
> certificate that they will use as a trust anchor, and include whatever I
> want in it, such as the Subject field, "Your trusted BigBank".
>
> Moreover, even if I am the rightful owner, the current text does not allow
> me to restrict the certificate's use.
>
> So I propose the following text added:
>
> Client treatment of any non-key information included in the trust anchor is
> a matter of local policy. It is noted that this specification does not
> mandate that such information be inspected or validated by the domain
> registrar.
>
> The client MUST obey any constraints included in the trust anchor,
> including but not limited to:
> - Validity period.
> - Key usage fields.
> - Path length constraints.
> - Name constraints.
> The normal rules of RFC 5280 apply.
>
> Thanks,
>        Yaron
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

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

This is an issue, but a fairly easy one to deal with and one that is alread=
y dealt with when dealing with self-signed certs. The browser writers know =
this stuff already.<div><br></div><div>Some of the people who were doing se=
curity code in 1995 were clueless. In fact we all pretty much were (but in =
different ways). But that has not been an issue since Netscape hired Taher =
and the brothers Weinstein.</div>
<div><br></div><div><br></div><div>There is a very simple principle here:</=
div><div><br></div><div>DNS cannot extend any positive claims beyond the DN=
S name itself</div><div><br></div><div>DNS can however extend negative clai=
ms and restrictions.</div>
<div><br></div><div>A domain can&#39;t say &#39;trust me I am a bank&#39; b=
ut it can say &#39;take extra security precautions, in case I am a bank&#39=
;</div><div><br></div><div><br></div><div><br><div class=3D"gmail_quote">
On Fri, Feb 11, 2011 at 2:26 AM, Yaron Sheffer <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:[email-masked]">[email-masked]</a>&gt;</span> wro=
te:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex;">
Hi,<br>
<br>
the new text is a major improvement over the previous version. But it is st=
ill missing some necessary guidance.<br>
<br>
My reference scenario is this: I am a phisher. I&#39;d like to trick BigBan=
k&#39;s customers, so I acquire <a href=3D"http://bigbang.com" target=3D"_b=
lank">bigbang.com</a> (an easy misspelling). Now I can get a certificate th=
at they will use as a trust anchor, and include whatever I want in it, such=
 as the Subject field, &quot;Your trusted BigBank&quot;.<br>

<br>
Moreover, even if I am the rightful owner, the current text does not allow =
me to restrict the certificate&#39;s use.<br>
<br>
So I propose the following text added:<br>
<br>
Client treatment of any non-key information included in the trust anchor is=
 a matter of local policy. It is noted that this specification does not man=
date that such information be inspected or validated by the domain registra=
r.<br>

<br>
The client MUST obey any constraints included in the trust anchor, includin=
g but not limited to:<br>
- Validity period.<br>
- Key usage fields.<br>
- Path length constraints.<br>
- Name constraints.<br>
The normal rules of RFC 5280 apply.<br>
<br>
Thanks,<br>
 =A0 =A0 =A0 =A0Yaron<br>
_______________________________________________<br>
keyassure 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/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>
</div>

--0016e64402141bf5c0049c022327--

From: Henry Story <[email-masked]>
Date: Fri, 11 Feb 2011 13:19:43 +0100
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] WebID at W3C and keyassure

On 11 Feb 2011, at 01:48, Paul Hoffman wrote:

> On 2/10/11 2:41 PM, Henry Story wrote:
>> Keyassure will probably use the DNS-ID typed subject alternative name
>> (SAN) or Issuer Alternative Name (IAN) in a *server* X509 certifactes
>> to identify the server as suggested is good practice by
>> =
http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-14#section=
-2.3
>=20
> In your earlier message, you said:
>=20
>> (I have not seen a draft spec yet, and am going from the group
>> description).
>=20
> Please do read the draft. What you say here, which predicates the rest
> of your message about similarities with the WebID work, is not at all
> correct.

Yes, I just read the draft dane 4=20
http://tools.ietf.org/html/draft-ietf-dane-protocol-04

I don't think I was far off, but still perhaps too cryptic. In section =
2.2 it states that there are four types of things that can be published =
in the TLSA record

 1 -- Hash of an end-entity certificate
 2 -- Full end-entity certificate in DER encoding
 3 -- Hash of an certification authority's certificate
 4 -- Full certification authority's certificate in DER encoding

So if in 2 the certificate is a DER encoded X509 cert, then if it is a =
server certificate it should contain according to draft-saintandre the =
Domain Name in the SAN field. There are a few different types of SAN =
fields: DNS-ID, SRV-ID and URI-ID. SRV-ID which is defined by rfc4985 is =
a lot closer to what you are specifying in the RDATA format. (Though it =
looks like that RFC could be improved to allow port numbers to be =
specified, as you do)

So if someone came across such a certificate with such a SRV-ID, they =
could after finding the SAN do a lookup in DNSSEC and verify that this =
is indeed the correct/current certificate. In some ways this is similar =
to finding an html page with a=20
    <link rel=3D"self" href=3D"http://bblfish.net/"/>=20
You could use it to lookup the current version of the page. What you =
have in your hand is a cached copy.

Now if you do one more little conceptual jump and you allow that one can =
name things including agents with an http(s) URI then he can put that =
URI in the SAN field. So I have a WebID=20

   http://bblfish.net/people/henry/card#me

Doing a lookup using HTTP will get the meaning of that URI - and so a =
description of me. That URI could return a PEM certificate too, just as =
you do in the DNS lookup (we are discussing allowing this in addition to =
RDF/XML, rdfa, or other XML representations)

   Good so I think we have two protocols - yours and WebID - that both =
can do the following and that are very similar in those respect:

   1. place an identifier in the X.509 SAN field.=20
      - for keyassure this is a service identifier (SRV-ID)
      - for webid this is a URI identifier
   2. dereference the ID to get the latest version
      - using DNS lookup for keyassure
      - using HTTP/HTTPS/ftp... lookup for WebID
   3. Proving authenticity=20
   both protocols use the information retrieved canonically at the =
identifier to prove authenticity.
      - with WebID the relying party uses the public key published there =
to verify that the agent connecting to it is indeed named by that URI. =
He is if he could prove in the TLS handshake that he knew the =
corresponding private key.
      - with keyassure by proving that there is the appropriate link =
between the keys/signature published in 1-4 and the certificate sent by =
the TLS server.

   Essentially point 3 - proving authenticity - works because of what =
you name a trust anchor. I am just pointing out that this trust anchor =
is tied to a naming system and a canonical lookup procedure in both =
cases.=20

   Ok, so I think that demonstrates quite clearly that there are a lot =
of similarities. So what is the use of knowing that?

   Well I think for me that helps confirm my WebID intuitions. When I =
spoke to Dan Kaminsky after his talk "X509 considered harmful" [1] a few =
years ago, the possibility of something like keyassure helped me feel we =
could bypass the most damaging of his critiques against the current PKI =
setup. WebID does not need CAs, and with keyassure web servers won't =
need them either. We are still left with the clumsy ASN.1 format, but =
that can be solved over time with better parsers, or, since TLS allows =
it, to some better defined format such as binary xml perhaps.

   Another advantage of having two very similar protocols developing, =
especially as they are not stepping on each others toes, is that we may =
be able to learn a few tricks from one another. So here is one initial =
idea that occurred to me reading your spec today.

   =3D=3D IDEA =3D=3D

   Currently you are publishing either a signature or a certificate in =
the DNS. Why not publish the only piece of the certificate that is =
important: the public key. This is what WebID does. This should be =
shorter than the certificate, and though it will be longer than the =
signature, it will be a lot more useful, tying you much less to a =
particular serialisation format.

  There is no need to send a full certificate. All you need is to tie a =
name to a public key and to guarantee to the end user the integrity of =
the information. But the integrity is itself assured by DNSSEC. The =
tying of the name to the public key is done by the lookup in DNS. So all =
that is really required is to return the public key - the type and the =
fields.

  One could then even imagine a TLS improvement where the server would =
not need to send his certificate either. All the TLS server would need =
to do is prove that he can encrypt something with his private key. The =
public key would be fetched from the DNS. So at that point we will have =
gotten rid of ASN.1 or at least just kept the minimum needed. This would =
be the server equivalent of the client_certificate_url extension of TLS =
1.2 where the client can send a URL to a location of his certificate, =
instead of sending his certificate. Here the server would not need to =
send his certificate, and for self signed certificates, the DNS sending =
the public key would be enough anyway.

  So I hope this helps clarify the similarities of the two protocols as =
well as the usefulness of our interaction.

> This is not to say that what WebID is doing can't work with the DANE =
effort, just that we are doing completely different things. DANE is =
about getting a temporary trust anchor for a particular =
port/transport/domainname triple for a server, whereas WebID is about =
identifying clients through an HTTPS lookup. There has been discussion =
of using DANE to get a temporary trust anchor for S/MIME clients, and =
that might be extended to doing so for TLS clients, but it would be done =
using the DNS protocol.

yes, that is where each of us understanding the other could help see =
where some of these things would fit best. S/MIME it seems to me is =
closer to client authentication, and so would better fit in with WebID.

	Henry Story

[1] http://blogs.sun.com/bblfish/entry/camping_and_hacking_at_har2009

Date: Fri, 11 Feb 2011 09:26:33 +0200
From: Yaron Sheffer <[email-masked]>
To: [email-masked]
Subject: [keyassure] dane-04 trust anchors

Hi,

the new text is a major improvement over the previous version. But it is 
still missing some necessary guidance.

My reference scenario is this: I am a phisher. I'd like to trick 
BigBank's customers, so I acquire bigbang.com (an easy misspelling). Now 
I can get a certificate that they will use as a trust anchor, and 
include whatever I want in it, such as the Subject field, "Your trusted 
BigBank".

Moreover, even if I am the rightful owner, the current text does not 
allow me to restrict the certificate's use.

So I propose the following text added:

Client treatment of any non-key information included in the trust anchor 
is a matter of local policy. It is noted that this specification does 
not mandate that such information be inspected or validated by the 
domain registrar.

The client MUST obey any constraints included in the trust anchor, 
including but not limited to:
- Validity period.
- Key usage fields.
- Path length constraints.
- Name constraints.
The normal rules of RFC 5280 apply.

Thanks,
	Yaron

From: Simon Josefsson <[email-masked]>
To: Paul Hoffman <[email-masked]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Fri, 11 Feb 2011 07:22:53 +0100
Cc: [email-masked]
Subject: Re: [keyassure] Special, four issues (#2, #9, #13, #18) for the price of one....

Paul Hoffman <[email-masked]> writes:

> On 2/10/11 7:36 PM, Matt McCutchen wrote:
>> On Thu, 2011-02-10 at 18:59 -0800, Paul Hoffman wrote:
>>> Jakob and I would definitely like to hear more on this. If we need to
>>> say more about what a trust anchor is, we can do that. If people think
>>> we have over-restricted it in -04, that's good input as well.
>>
>> I haven't fully considered the issue, I just have two nits to pick:
>>
>>> The -04
>>> text in question is:
>>>
>>> A TLS client conforming to this protocol MUST treat the certificate
>>> for association in a TLSA resource record for a domain name as a
>>> trust anchor for that domain name at the specific port number and
>>> transport name that was queried. This trust anchor MUST only be used
>>> for the domain name of the resource record.
>>
>> And port number and transport protocol name.
>
> Why should we put on that requirement? That is, if I get a trust
> anchor for _443._tcp.www.example.com, what is the security issue if I
> also want to use it for TLS on port 4443? There is no attack that an
> MITM can mount on 4443 that they cannot also mount on 443.

You may want to run a commercial CA on port 443 to get good interop with
deployed https clients, but you may want to use a trustworthy CA on port
4443 to get good security for some other services.  Having the
commercial CA be able to MITM the connection on 4443 sounds counter to
what I perceive DANE is aiming to achieve.

/Simon

From: Steve Schultze <[email-masked]>
Date: Fri, 11 Feb 2011 00:49:48 -0500
To: [email-masked]
Subject: Re: [keyassure] draft-ietf-dane-protocol-03.txt

Sorry I missed this when you first posted.=20

I feel that Matt's proposed language for Section 3 is clearer as to what =
is done in different scenarios:
http://www.ietf.org/mail-archive/web/keyassure/current/msg00923.html

For example, the current language in Section 3 does not make clear what =
is done in the case of no records or a DNSSEC response of "bogus" .  I =
like the way Matt's language clearly lays out all of the possible cases =
and the results.

The one issue with his language is that it assumes the client is doing =
DNSSEC validation, but our current language permits "a remote nameserver =
to which one has a secured channel of communication."  If we are =
permitting that, we may have to rephrase some of his specific references =
to DNSSEC result status' like "bogus" to be more generic.

On Jan 25, 2011, at 2:59 PM, Paul Hoffman wrote:
> Greetings again. There was not an open issue on how TLSA deals with =
non-key information in PKIX certificates, but Phill had brought up =
strong reservations and Steve Kent responded. There was then a longish =
thread on alternatives, but Jakob and I had never clarified the =
document. Thus, we put out -03 with some proposed wording that should =
make clear that the keys in certificate associations are trust anchors. =
The side effect of making that clear is that we could wipe out all the =
wishy-washy stuff from the old 3.1.
>=20
> The diffs are at =
<http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-dane-protocol-03.txt>.
>=20
> If folks are happy with this clarification, it will close some of the =
open issues that were spurred by the language in 3.1.
>=20
> --Paul Hoffman
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

From: "Steingruebl, Andy" <[email-masked]>
To: Nicholas Weaver <[email-masked]>, Phillip Hallam-Baker <[email-masked]>
Date: Thu, 10 Feb 2011 22:36:18 -0700
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Issue #3: Format of the record.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Nicholas Weaver

> And attempting to use a TXT record instead of a new RR is effectively no
> more reliable in practice from a delivery perspective.

Can you clarify this?  I saw Adam Langley's data on lookups of new random R=
R types and the failure rates.  I hadn't seen data on lookup failures for o=
ther types of records, but I could have just overlooked it.

Thanks

- Andy

Sender: Nicholas Weaver <[email-masked]>
From: Nicholas Weaver <[email-masked]>
Date: Thu, 10 Feb 2011 20:21:06 -0800
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Issue #3: Format of the record.

On Feb 10, 2011, at 8:16 PM, Phillip Hallam-Baker wrote:

> Since there is no value in these records without DNSSEC and since this =
is a standards track effort, I see no reason not to use a new RR.
>=20
> Reuse of an existing RR will make the protocol more complex and harder =
to use.
>=20
> All infrastructure that will pass and handle DNSSEC will support new =
RRs.
>=20
> Attempting to use a prefix to the TXT record will not bypass DNSEXT.

And attempting to use a TXT record instead of a new RR is effectively no =
more reliable in practice from a delivery perspective.

> So it has to be at least one new RR.

Agreed.

Date: Thu, 10 Feb 2011 23:16:23 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Warren Kumari <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Issue #3: Format of the record.

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

Since there is no value in these records without DNSSEC and since this is a
standards track effort, I see no reason not to use a new RR.

Reuse of an existing RR will make the protocol more complex and harder to
use.

All infrastructure that will pass and handle DNSSEC will support new RRs.

Attempting to use a prefix to the TXT record will not bypass DNSEXT.

So it has to be at least one new RR.

On Thu, Feb 10, 2011 at 9:28 PM, Warren Kumari <[email-masked]> wrote:

> Hello all,
>
> We have "Issue #3: Format of the record" with the description:
>
> --------------------
> Format of the record:
> a subtype of CERT (as was used in early drafts)
> a new RRtype (used in draft-ietf-dane-protocol-00)
> a TXT record with _prefix.
>
> Hopefully this is just a representation issue and can be worked on after
> larger decisions have been made.
>
> ----------------------
>
> I think that we have settled on using a new RRtype (as shown in
> draft-ietf-dane-protocol-00), but I realize that we haven't explicitly had a
> consensus call on this, so I am (with all reverence) donning the bells and
> ribbons, stepping over the clay pipes, smacking myself smartly with the
> stick and beginning the consensus call...
>
> W
>
> P.S: I have not consulted my co-chair on this, if I have completely
> misjudged the groups views, the fault is all mine...
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

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

Since there is no value in these records without DNSSEC and since this is a=
 standards track effort, I see no reason not to use a new RR.<div><br></div=
><div>Reuse of an existing RR will make the protocol more complex and harde=
r to use.</div>
<div><br></div><div>All infrastructure that will pass and handle DNSSEC wil=
l support new RRs.</div><div><br></div><div>Attempting to use a prefix to t=
he TXT record will not bypass DNSEXT.</div><div><br></div><div><br></div>
<div>So it has to be at least one new RR.</div><div><br><br><div class=3D"g=
mail_quote">On Thu, Feb 10, 2011 at 9:28 PM, 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;">Hello all,<br>
<br>
We have &quot;Issue #3: Format of the record&quot; with the description:<br=
>
<br>
--------------------<br>
Format of the record:<br>
a subtype of CERT (as was used in early drafts)<br>
a new RRtype (used in draft-ietf-dane-protocol-00)<br>
a TXT record with _prefix.<br>
<br>
Hopefully this is just a representation issue and can be worked on after la=
rger decisions have been made.<br>
<br>
----------------------<br>
<br>
I think that we have settled on using a new RRtype (as shown in draft-ietf-=
dane-protocol-00), but I realize that we haven&#39;t explicitly had a conse=
nsus call on this, so I am (with all reverence) donning the bells and ribbo=
ns, stepping over the clay pipes, smacking myself smartly with the stick an=
d beginning the consensus call...<br>

<br>
W<br>
<br>
P.S: I have not consulted my co-chair on this, if I have completely misjudg=
ed the groups views, the fault is all mine...<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>
</div>

--0016e644021407fd4a049bf9f65f--

Date: Thu, 10 Feb 2011 20:07:53 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Special, four issues (#2, #9, #13, #18) for the price of one....

On 2/10/11 7:36 PM, Matt McCutchen wrote:
> On Thu, 2011-02-10 at 18:59 -0800, Paul Hoffman wrote:
>> Jakob and I would definitely like to hear more on this. If we need to
>> say more about what a trust anchor is, we can do that. If people think
>> we have over-restricted it in -04, that's good input as well.
>
> I haven't fully considered the issue, I just have two nits to pick:
>
>> The -04
>> text in question is:
>>
>> A TLS client conforming to this protocol MUST treat the certificate
>> for association in a TLSA resource record for a domain name as a
>> trust anchor for that domain name at the specific port number and
>> transport name that was queried. This trust anchor MUST only be used
>> for the domain name of the resource record.
>
> And port number and transport protocol name.

Why should we put on that requirement? That is, if I get a trust anchor 
for _443._tcp.www.example.com, what is the security issue if I also want 
to use it for TLS on port 4443? There is no attack that an MITM can 
mount on 4443 that they cannot also mount on 443.

>> The trust anchor MUST NOT
>> be loaded for longer than the TTL on the TSLA record.
>
> I think you want the RRSIG validity.  Requiring that clients limit the
> trust anchor to the TTL would be false security.  However, clients would
> be allowed to do so.

Good call. I'm not sure I agree, but it should definitely be discussed.

--Paul Hoffman

From: Matt McCutchen <[email-masked]>
To: keyassure <[email-masked]>
Date: Thu, 10 Feb 2011 22:36:19 -0500
Subject: Re: [keyassure] Special, four issues (#2, #9, #13, #18) for the price of one....

On Thu, 2011-02-10 at 18:59 -0800, Paul Hoffman wrote:
> Jakob and I would definitely like to hear more on this. If we need to=20
> say more about what a trust anchor is, we can do that. If people think=20
> we have over-restricted it in -04, that's good input as well.

I haven't fully considered the issue, I just have two nits to pick:

> The -04=20
> text in question is:
>=20
> A TLS client conforming to this protocol MUST treat the certificate
> for association in a TLSA resource record for a domain name as a
> trust anchor for that domain name at the specific port number and
> transport name that was queried. This trust anchor MUST only be used
> for the domain name of the resource record.

And port number and transport protocol name.

> The trust anchor MUST NOT
> be loaded for longer than the TTL on the TSLA record.=EF=BB=BF

I think you want the RRSIG validity.  Requiring that clients limit the
trust anchor to the TTL would be false security.  However, clients would
be allowed to do so.

--=20
Matt

From: Matt McCutchen <[email-masked]>
To: keyassure <[email-masked]>
Date: Thu, 10 Feb 2011 22:29:52 -0500
Subject: Re: [keyassure] Issue #3: Format of the record.

On Thu, 2011-02-10 at 21:28 -0500, Warren Kumari wrote:
> We have "Issue #3: Format of the record" with the description:
> 
> --------------------
> Format of the record:
> a subtype of CERT (as was used in early drafts)
> a new RRtype (used in draft-ietf-dane-protocol-00)
> a TXT record with _prefix.
> 
> Hopefully this is just a representation issue and can be worked on after larger decisions have been made.
> 
> ----------------------
> 
> I think that we have settled on using a new RRtype (as shown in
> draft-ietf-dane-protocol-00), but I realize that we haven't explicitly
> had a consensus call on this, so I am (with all reverence) donning the
> bells and ribbons, stepping over the clay pipes, smacking myself
> smartly with the stick and beginning the consensus call...

I prefer the new RRtype.

It would be OK to use a new CERT subtype, but I don't find there to be
much conceptual economy in doing so.  RFC 4398 section 7 suggests that
some clients might use DNSSEC-protected CERT records without traditional
validation, but there is nothing precise; in contrast, TLSA makes a
precise assertion.  Furthermore, TLSA clients aren't interested in the
other CERT subtypes, so it is cleaner not to fetch them and have to sort
through them.

TXT at a prefix would only make sense if the RR content is text.  I
prefer binary for the slightly better performance, unless interop issues
with new RRtypes are shown to still be real.  A key-value format like
DKIM or Kaminsky's KEY1 is extensible via new keys, but we don't care
about that assuming we are going to bite off TLSA and deal separately
with the myriad other hints we might want to give clients.

-- 
Matt

Date: Thu, 10 Feb 2011 18:59:09 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Special, four issues (#2, #9, #13, #18) for the price of one....

On 2/10/11 6:43 PM, Warren Kumari wrote:
> Hello again.
>
> It appears to me that the current wording on trust anchors neatly resolves a bunch of issues namely:
> #2: Relying parties policies (http://trac.tools.ietf.org/wg/dane/trac/ticket/2)
> #9: Self-Signed Certificates (http://trac.tools.ietf.org/wg/dane/trac/ticket/9)
> #13: Hostnames in Certificates (http://trac.tools.ietf.org/wg/dane/trac/ticket/13)
> #18: Certificate Properties and Relationship with PKIX (http://trac.tools.ietf.org/wg/dane/trac/ticket/18)
>
> I would like to hear your views on this -- if you have substantive comments on any of the issues *please* start a new thread so that we can keep the discussions separate and organized.

Jakob and I would definitely like to hear more on this. If we need to 
say more about what a trust anchor is, we can do that. If people think 
we have over-restricted it in -04, that's good input as well. The -04 
text in question is:

A TLS client conforming to this protocol MUST treat the certificate
for association in a TLSA resource record for a domain name as a
trust anchor for that domain name at the specific port number and
transport name that was queried. This trust anchor MUST only be used
for the domain name of the resource record. The trust anchor MUST NOT
be loaded for longer than the TTL on the TSLA record.

--Paul Hoffman

From: Warren Kumari <[email-masked]>
Date: Thu, 10 Feb 2011 21:43:16 -0500
To: [email-masked]
Subject: [keyassure] Special, four issues (#2, #9, #13, #18) for the price of one....

Hello again.

It appears to me that the current wording on trust anchors neatly =
resolves a bunch of issues namely:
#2: Relying parties policies =
(http://trac.tools.ietf.org/wg/dane/trac/ticket/2)
#9: Self-Signed Certificates =
(http://trac.tools.ietf.org/wg/dane/trac/ticket/9)
#13: Hostnames in Certificates =
(http://trac.tools.ietf.org/wg/dane/trac/ticket/13)=20
#18: Certificate Properties and Relationship with PKIX =
(http://trac.tools.ietf.org/wg/dane/trac/ticket/18)

I would like to hear your views on this -- if you have substantive =
comments on any of the issues *please* start a new thread so that we can =
keep the discussions separate and organized.

W
(Not donning the shirt and baldricks as this is not an official =
consensus call or opening of an issue).=

From: Warren Kumari <[email-masked]>
Date: Thu, 10 Feb 2011 21:28:31 -0500
To: [email-masked]
Subject: [keyassure] Issue #3: Format of the record.

Hello all,

We have "Issue #3: Format of the record" with the description:

--------------------
Format of the record:
a subtype of CERT (as was used in early drafts)
a new RRtype (used in draft-ietf-dane-protocol-00)
a TXT record with _prefix.

Hopefully this is just a representation issue and can be worked on after =
larger decisions have been made.

----------------------

I think that we have settled on using a new RRtype (as shown in =
draft-ietf-dane-protocol-00), but I realize that we haven't explicitly =
had a consensus call on this, so I am (with all reverence) donning the =
bells and ribbons, stepping over the clay pipes, smacking myself smartly =
with the stick and beginning the consensus call...

W

P.S: I have not consulted my co-chair on this, if I have completely =
misjudged the groups views, the fault is all mine...=

From: "dane issue tracker" <[email-masked]>
Auto-Submitted: auto-generated
To: [email-masked]
Date: Fri, 11 Feb 2011 02:15:40 -0000
Cc: [email-masked]
Subject: Re: [keyassure] [dane] protocol #17 (closed): Should draft-ietf-dane-protocol support TLS only or be more ambitious?

#17: Should draft-ietf-dane-protocol support TLS only or be more ambitious?

Changes (by warren@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Consensus:

 The initial document (draft-ietf-dane-protocol) will support only TLS /
 DTLS.

-- 
--------------------------------+-------------------------------------------
 Reporter:  warren@…            |        Owner:            
     Type:  defect              |       Status:  closed    
 Priority:  major               |    Milestone:  milestone1
Component:  protocol            |      Version:            
 Severity:  Active WG Document  |   Resolution:  fixed     
 Keywords:                      |  
--------------------------------+-------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/dane/trac/ticket/17#comment:1>
dane <http://tools.ietf.org/dane/>

From: Warren Kumari <[email-masked]>
Date: Thu, 10 Feb 2011 21:14:46 -0500
To: [email-masked]
Subject: Re: [keyassure] Call for consensus on #17

While going through the issue tracker I realized that we hadn't marked =
this issue as closed.

There have been no followups, and so I am officially waving the dead =
chicken and pulling the big lever marked "Consensus Achieved" -- I know =
y'all think I just make this stuff up, but I believe in keeping the old =
traditions alive....

The consensus is, as Ondrej stated:=20
The initial document (draft-ietf-dane-protocol) will support only TLS / =
DTLS.

W

On Jan 28, 2011, at 1:26 PM, Warren Kumari wrote:

>=20
> On Jan 28, 2011, at 1:14 PM, Paul Hoffman wrote:
>=20
>> On 1/28/11 9:24 AM, Simon Josefsson wrote:
>>> Ond=F8ej Sur=FD<[email-masked]>  writes:
>>>=20
>>>> Hi all,
>>>>=20
>>>> upon discussion with my fellow co-chair I hereby call for consensus =
on
>>>> issue #17.
>>>>=20
>>>> The consensus would be that the initial document
>>>> (draft-ietf-dane-protocol) would support only TLS.
>>>=20
>>> Does this exclude DTLS?
>=20
> No... Good catch though!
>=20
> 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.
>=20
> 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/' :-)
>=20
>>> DTLS is not the same protocol as TLS.
>>=20
>> 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.
>=20
> Nope, I believe it is perfectly clear in the doc (clear enough that I =
automatically see the implied DTLS)
>=20
> W
>> _______________________________________________
>> keyassure mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/keyassure
>>=20
>=20
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>=20

Date: Thu, 10 Feb 2011 16:48:42 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] WebID at W3C and keyassure

On 2/10/11 2:41 PM, Henry Story wrote:
> Keyassure will probably use the DNS-ID typed subject alternative name
> (SAN) or Issuer Alternative Name (IAN) in a *server* X509 certifactes
> to identify the server as suggested is good practice by
> http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-14#section-2.3

In
>
your earlier message, you said:

> (I have not seen a draft spec yet, and am going from the group
> description).

Please do read the draft. What you say here, which predicates the rest
of your message about similarities with the WebID work, is not at all
correct.

This is not to say that what WebID is doing can't work with the DANE 
effort, just that we are doing completely different things. DANE is 
about getting a temporary trust anchor for a particular 
port/transport/domainname triple for a server, whereas WebID is about 
identifying clients through an HTTPS lookup. There has been discussion 
of using DANE to get a temporary trust anchor for S/MIME clients, and 
that might be extended to doing so for TLS clients, but it would be done 
using the DNS protocol.

From: Matt McCutchen <[email-masked]>
To: keyassure <[email-masked]>
Date: Thu, 10 Feb 2011 19:20:25 -0500
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

On Fri, 2011-02-11 at 01:31 +0200, Ilari Liusvaara wrote:
> On Thu, Feb 10, 2011 at 05:20:55PM -0500, Matt McCutchen wrote:
> > 
> > I don't know where you got that.  My goal with "null TLSA" is to prevent
> > public CAs from fabricating a TLS service that I do not offer.  E.g., I
> > do not operate a site at https://secure.mattmccutchen.net, but if a
> > public CA spoofed it into existence and invited users to visit it, they
> > would be inclined to assume that I endorse the content. 
> 
> That attack doesn't work too well: Clients will try to resolve A/AAAA
> records for secure.mattmccutchen.net, ending up with authenticated
> NXDOMAIN and then complain about unknown host.

I forgot about that, but see my previous message on the subject:

http://www.ietf.org/mail-archive/web/keyassure/current/msg01679.html

> Now, this attack could actually work between ports (but would require
> MITMing on mass scale).

MITMing is what all of this is about...

-- 
Matt

Date: Fri, 11 Feb 2011 01:31:24 +0200
From: Ilari Liusvaara <[email-masked]>
To: Matt McCutchen <[email-masked]>
Sender: Ilari Liusvaara <[email-masked]>
Cc: keyassure <[email-masked]>
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

On Thu, Feb 10, 2011 at 05:20:55PM -0500, Matt McCutchen wrote:
> 
> I don't know where you got that.  My goal with "null TLSA" is to prevent
> public CAs from fabricating a TLS service that I do not offer.  E.g., I
> do not operate a site at https://secure.mattmccutchen.net, but if a
> public CA spoofed it into existence and invited users to visit it, they
> would be inclined to assume that I endorse the content. 

That attack doesn't work too well: Clients will try to resolve A/AAAA
records for secure.mattmccutchen.net, ending up with authenticated
NXDOMAIN and then complain about unknown host.

Now, this attack could actually work between ports (but would require
MITMing on mass scale).

-Ilari

Date: Thu, 10 Feb 2011 14:49:51 -0800
From: Paul Hoffman <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [keyassure] New -04 issued

Greetings again. Jakob and I updated the draft to reflect the consensus 
on issue #1 and to clarify the trust anchor issue that was added in -03. 
The previous message announces the draft; the diffs are at 
<http://tools.ietf.org/rfcdiff?url2=draft-ietf-dane-protocol-04.txt>.

We look forward to more open issues being discussed and resolved before 
the Prague meeting!

--Paul Hoffman

From: [email-masked]
To: [email-masked]
Date: Thu, 10 Feb 2011 14:45:02 -0800
Cc: [email-masked]
Subject: [keyassure] I-D Action:draft-ietf-dane-protocol-04.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           : Using Secure DNS to Associate Certificates with Domain Names For TLS
	Author(s)       : P. Hoffman, J. Schlyter
	Filename        : draft-ietf-dane-protocol-04.txt
	Pages           : 11
	Date            : 2011-02-10

TLS and DTLS use certificates for authenticating the server.  Users
want their applications to verify that the certificate provided by
the TLS server is in fact associated with the domain name they
expect.  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.  This document describes how to use secure DNS to
associate the TLS server's certificate with the the intended domain
name.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dane-protocol-04.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-protocol-04.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart--

From: Henry Story <[email-masked]>
Date: Thu, 10 Feb 2011 23:41:33 +0100
To: [email-masked]
Subject: Re: [keyassure] WebID at W3C and keyassure

John Gilmore rightly pointed out that I was not clear in my mail to the =
list, so I answered his questions in more detail below.

On 10 Feb 2011, at 21:17, John Gilmore wrote:

>> Where keyassure is attempting to identify a server using uniquely
>> identifying information in the DNS, WebID is identifying an end
>> user (human, robot or agency), via a profile document containing
>> cryptographically uniquely identifying information placed in the
>> web.
>=20
> I understand this.
>=20
>> Keyassure coul probably use the dns typed subject
>> alternative name to identify the verify X509 certifactes, WebID
>> uses the SAN (and IAN) with https IDs to identify the agent. We
>> are both using canonical referential lookups to get the meaning
>> of a name (Domain Name with keyassure, HTTP+TLS with WebID) which
>> we can then use to prove referential integrity (authentication).
>=20
> This is so much gobbledygook to me.  Can you explain in English?

Ok, sorry I did type that a bit too quickly yesterday, and it would have =
done with a  bit more editing before pressing the send button. Let me =
just rewrite this with spelling mistakes fixed and in less terse style.

Also here is a quick UML Sequence diagram for how this works
     http://www.w3.org/wiki/Foaf%2Bssl#How_does_it_work.3F

So let me try again:

Keyassure will probably use the DNS-ID typed subject alternative name =
(SAN) or Issuer Alternative Name (IAN) in a *server* X509 certifactes to =
identify the server as suggested is good practice by=20
=
http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-14#section=
-2.3

WebID uses the SAN (and IAN) with https IDs to identify the agent of a =
*client* certificate.

We are both using canonical referential lookups to get the meaning of a =
name. In the  case of keyassure the name is a domain name. The canonical =
way to look up the meaning of a domain name is to look in the DNS. The =
canoncial way to look up the meaning of an ftp:// URL (think of a URL as =
a name) is to use the ftp protocol. So the canoncial way to look up an =
http or https URL is to use HTTP+TLS, which is what WebID does.

So if I understand correctly, in the future a browser will be able to =
verify from DNSSEC that a self signed server certificate is indeed able =
to authenticate the server.

>=20
> I see zero point in working on this WebID thing if the actual goal is
> to actually identify me on the web.

You should of course have a choice to authenticate or be anonymous. Web =
Browsers should show you with what identity you have authenticated and =
allow you to logout in one click. If we can get together on issues like =
this to put some pressure on browser vendors, I'd be happy to help. I =
know of a few security holes that really need some external pressure.

>  I don't want the vast majority of web sites to be able to identify me =
on the web -- and I think this goal is shared by a large, possibly =
majority, fraction of web users.

Yes, you should be anonymous by default.=20

> To the extent that "WebID" becomes standard, if it makes it easier for
> websites to demand that people "identify themselves" before
> "publishing" information (publishing =3D distributing "to the public",
> not to individual identified people), then it will be destructive of
> the kind of Web that I want to continue to exist.  I want ordinary
> un-identified people and browsers to continue to have broad access to
> everything published on the web.  I refuse to use sites like the New
> York Times that demand that I login "to a free account" merely so they
> can track what I'm reading.

It is going to be very easy to create a WebID: one click of a button. =
And you can have as many as you want, on as many sites as you want. It =
should be easy to create throw away webids too. There is no need to go =
to any government agency, no need to prove anything. WebIDs are built to =
enable a web of trust. But you don't need to participate in a web of =
trust, and if you do, you don't need to reveal it to anyone else than =
those you trust.

> To the extent that "WebID" makes it harder for people to use a
> different pseudonym with each current website that "demands"
> identifying information, it will be destructive.

WebID allows you to authenticate on sites in a very decentralised way. =
You can have any number of IDs and place them wherever you want. So it =
is not restrictive.=20

> To the extent that "WebID" makes it impossible for sites like
> bugmenot.com or mailinator.com to exist and function well, it will be
> destructive.

They could provide temporal WebIDs as an additional service, without =
problem.

>=20
> To the extent that "WebID" works like "OpenID", it will never catch on
> anyway.

The extent to which it is different to OpenID is detailed here
=
http://www.w3.org/wiki/Foaf%2Bssl/FAQ#OpenID_failed.2C_do_people_really_wa=
nt_distributed_identity.3F

=46rom the user perspective it is a lot easier to use.

>  I use OpenID with exactly one site, because they demand it and
> offer no alternative.  And it's incredibly cumbersome, harder than =
just
> logging in like other sites require.

Yes, WebID is point and click. No typing. See the short video I put =
together here
http://bblfish.net/

>=20
> Now if somebody at W3C actually automated bugmenot.com in a new
> protocol, so that ordinary people could just set their web browser to
> pretend to be randomly generated other people on sites that demand
> their identities, I'd be much more interested in it. =20

It would be very easy to do. You can get yourself a WebID at=20
http://foaf.me/ in a few clicks. The UI should definitively be improved.=20=

> But after
> a brief look at:
>=20
>  http://www.w3.org/2005/Incubator/webid/spec/
>=20
> that doesn't seem at all to be what's happening.  Instead it's more
> totalitarian bullshit wrapped in X.509 encoding.

It's certainly not. (Perhaps it's a good thing that it looks like that, =
...)

Anyway, what in particular makes you think that in the wording or =
presentation? We are working on the spec.=20

Btw. has this group got a draft spec I could look at?

Henry Story

>=20
> 	John Gilmore

Social Web Architect
http://bblfish.net/

From: Matt McCutchen <[email-masked]>
To: keyassure <[email-masked]>
Date: Thu, 10 Feb 2011 17:37:20 -0500
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

On Thu, 2011-02-10 at 14:54 -0500, Phillip Hallam-Baker wrote:
> 
> 
> On Thu, Feb 10, 2011 at 12:45 PM, Ilari Liusvaara
> <[email-masked]> wrote:
>         On Thu, Feb 10, 2011 at 10:46:49AM -0500, Phillip Hallam-Baker
>         wrote:
>         >
>         > I believe I can support the following criteria with no
>         compromise to any of
>         > them.
>         
>         
>         <snip long list>
>         
>         Based on this list, it looks like scheme that satisifes all of
>         these would
>         be godawfully complicated (interoperability problems) and
>         require loads
>         of code to implement (bugs, or in worst case, security bugs)
> 
> 
> Let us judge the complexity of the actual proposals rather than the
> presumed complexity of the requirements.
> 
> 
> SAML is based on a design that supports the whole of PKIX in less than
> 20 pages.
> 
> 
> I have pretty good metrics for the relative complexity of my scheme vs
> others based on the number of states and transitions.

I will believe it when I see it.  And if it means being exposed to
Etisalat for an extra six months while we haggle over the design, I'm
not interested.  (Of course, the WG chairs make the decision, not me.)

-- 
Matt

From: Matt McCutchen <[email-masked]>
To: keyassure <[email-masked]>
Date: Thu, 10 Feb 2011 17:20:55 -0500
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

On Wed, 2011-02-09 at 22:11 -0500, Paul Wouters wrote:
> On Wed, 9 Feb 2011, Andrew Sullivan wrote:
> 
> > Ah, I get what you're arguing.  Hrm.
> >
> > So what you want, I think, is a three-value state:
> >
> >    - zone positively has record
> >        This amounts to an affirmation by the zone admin that it
> >        supports the feature.
> 
> Yes.
> 
> >    - zone asserts it does not have record
> >        This is an indeterminate state with respect to the new
> >        feature, because the the signed absence of a record is not a
> >        meaningful assertion.
> 
> Well, the absense tells you no DANE based TLS is there. There could still be
> TLS backed by PKIX.

Correct.

> >    - zone has record asserting no support
> >        This is the zone admin asserting that it does _not_ support
> >        the feature.
> 
> This would be the "null TLSA" record? I find that record unneccessary.

The record asserts that there is no TLS service at the name, in
particular not a PKIX-authenticated service.

> We
> also don't have a "null PKIX" record. Is there a desire to create one
> for those as well?

Not sure what you mean.  PKIX-based TLS authentication by its nature
does not support exclusion.

> Frankly, adding infrastructure to better support insecure protocols makes
> no sense to me. Especailly because we are hard on our way on killing
> port 80, and the last group of clients on port 80 will be those not
> supporting any new RRTYPE anyway.

I don't know where you got that.  My goal with "null TLSA" is to prevent
public CAs from fabricating a TLS service that I do not offer.  E.g., I
do not operate a site at https://secure.mattmccutchen.net, but if a
public CA spoofed it into existence and invited users to visit it, they
would be inclined to assume that I endorse the content.  (And browsers
would be inclined to let it set cookies for .mattmccutchen.net and
confuse my web apps.  This issue deserves a proper solution, but for now
I am avoiding it by not handing out subdomains.)  Null TLSA might help
some clients find a plaintext service more quickly, but that is not the
point.

-- 
Matt

From: Matt McCutchen <[email-masked]>
To: keyassure <[email-masked]>
Date: Thu, 10 Feb 2011 16:53:52 -0500
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

On Wed, 2011-02-09 at 17:39 +0100, Martin Rex wrote:
> I should have been more explicit on this:
> 
> There is a client with a desire to communicate, and a preference/intend
> for TLS-protection.  But with most protocols, there is a fallback
> strategy to communicate without TLS.  It could be that the initial
> reference does not even imply TLS, and its only the client who is
> looking for clues in DNS whether TLS is available.
> 
> So I'm still wondering: what message should an empty list convey?

Just what I said: there is no TLS service associated with the
host/transport/port.

> A pre-DANE client might fallback to non-TLS if TLS doesn't work,
> or it might not try TLS at all.
> 
> What should a DANE-aware client, that is wildly determined to communicate
> do when finding an empty TLSA record?  Go straight for the unprotected
> communication (which is what such a record would imply), or bother
> the user with an annoying popup before doing the fallback on unprotected
> communication.
> 
> I doubt that "not communicating at all" is a workable solution for such
> clients, because it is likely to be perceived as a usability problem
> by a non-marginal fraction of the user base.
> 
> 
> Most "Web users" think that "the Web" == "the Internet" and are so completely
> accustomed to trust everyone with everything over completely insecure
> communication channels (commonly described with "http://")
> that it is going to be hard to turn back time on this.

Any fallback that clients may perform is a separate issue, and we will
need separate mechanisms to control it.  Even considering my proposal in
isolation, I don't see how asserting the absence of a TLS service leaves
clients with fallback worse off.  The only difference it makes is that
they fall back in cases in which they would otherwise make a TLS
connection to an impostor.  At least they know they are not getting a
secure connection if anyone cares to check.

> > > DANE-unaware clients will continue trying to use TLS.
> > > What is your rationale for making DANE-aware clients exhibit
> > > a different behaviour and entirely stop trying to use TLS?
> > 
> > I assert that I do not offer the TLS service, so there is no point in
> > DANE clients trying to connect to it.  In particular, I do not want them
> > to connect to some fake service with a certificate from a public CA.
> > There is nothing I can do about the DANE-unaware clients.
> 
> While there are a few clients of the type "TLS or refuse to connect",
> the vast majority of clients will happily connect without TLS instead,
> and end users have been conditioned over more than a decade that
> fallbacks are OK.

That may be true at a high level, considering how users react to various
situations.  At the level of individual transactions, all of the major
HTTP clients follow "TLS or refuse to connect" for https URLs, and all
of the major mail clients have a checkbox to enable this behavior.  This
is the level I am focused on securing now.

-- 
Matt

Date: Thu, 10 Feb 2011 14:54:42 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Ilari Liusvaara <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

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

On Thu, Feb 10, 2011 at 12:45 PM, Ilari Liusvaara <
[email-masked]> wrote:

> On Thu, Feb 10, 2011 at 10:46:49AM -0500, Phillip Hallam-Baker wrote:
> >
> > I believe I can support the following criteria with no compromise to any
> of
> > them.
>
> <snip long list>
>
> Based on this list, it looks like scheme that satisifes all of these would
> be godawfully complicated (interoperability problems) and require loads
> of code to implement (bugs, or in worst case, security bugs)
>

Let us judge the complexity of the actual proposals rather than the presumed
complexity of the requirements.

SAML is based on a design that supports the whole of PKIX in less than 20
pages.

I have pretty good metrics for the relative complexity of my scheme vs
others based on the number of states and transitions.

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

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

<br><div><br><div class=3D"gmail_quote">On Thu, Feb 10, 2011 at 12:45 PM, I=
lari Liusvaara <span dir=3D"ltr">&lt;<a href=3D"mailto:ilari.liusvaara@elis=
anet.fi">[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;">
<div class=3D"im">On Thu, Feb 10, 2011 at 10:46:49AM -0500, Phillip Hallam-=
Baker wrote:<br>
&gt;<br>
&gt; I believe I can support the following criteria with no compromise to a=
ny of<br>
&gt; them.<br>
<br>
</div>&lt;snip long list&gt;<br>
<br>
Based on this list, it looks like scheme that satisifes all of these would<=
br>
be godawfully complicated (interoperability problems) and require loads<br>
of code to implement (bugs, or in worst case, security bugs)<br></blockquot=
e><div><br></div><div>Let us judge the complexity of the actual proposals r=
ather than the presumed complexity of the requirements.</div><div><br>
</div><div>SAML is based on a design that supports the whole of PKIX in les=
s than 20 pages.</div><div><br></div><div>I have pretty good metrics for th=
e relative complexity of my scheme vs others based on the number of states =
and transitions.</div>
<div>=A0</div></div>-- <br>Website: <a href=3D"http://hallambaker.com/">htt=
p://hallambaker.com/</a><br><br>
</div>

--0016e6441dceda1ed7049bf2f386--

Date: Thu, 10 Feb 2011 19:45:07 +0200
From: Ilari Liusvaara <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Sender: Ilari Liusvaara <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

On Thu, Feb 10, 2011 at 10:46:49AM -0500, Phillip Hallam-Baker wrote:
> 
> I believe I can support the following criteria with no compromise to any of
> them.

<snip long list>

Based on this list, it looks like scheme that satisifes all of these would
be godawfully complicated (interoperability problems) and require loads
of code to implement (bugs, or in worst case, security bugs)

Remember, this isn't enterprise-only stuff. This needs to be usable
by small scale software and services.

-Ilari

Date: Thu, 10 Feb 2011 10:46:49 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Wouters <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

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

Yes, I am working on the draft right now. As you might expect it is an
extension of the concepts in CAA and ESRV using the extension mechanism
anticipated in CAA.

I believe I can support the following criteria with no compromise to any of
them.

1) Correct and predictable interaction with CNAME and wildcards

2) Support for publication of attributes that are specific to a particular
protocol or apply to a whole domain.

3) Ability to prevent downgrade attack by specifying that protocols are
always offered or must be used.

4) Ability to prevent trust substitution attacks such as unauthorized issue
of certificates by CA or use of unauthorized certificates in an application.

5) Ability to advertise end entity keys specific to a domain name or domain
name and protocol

6) Ability to advertise local trust anchors specific to a domain name

7) Support but not require use of service discovery schemes such as SRV,
NAPTR, URI and future schemes as they are developed.

8) Allow for compact implementation. Service discovery must be performed by
every device on the network, including devices whose performance does not
even support a full IP stack. Code complexity must be kept to a minimum.

9) Enable simplified administration by allowing administrative tasks to be
automated.

The above can all be supported in a manner that is completely protocol
neutral with no special cases called out in the mechanism. (i.e. not
specific to PKIX, TLS, application protocol).

However in order to use the mechanism with a particular protocol it is
likely going to be necessary to write up a separate draft for that
particular binding (like we did in SAML). so while I would design the
mechanism to be completely neutral wrt the PKI and security protocol, I
would only consider writing security bindings for PKIX and TLS and
application bindings for HTTP, SMTP, IMAP, POP3 and Jabber.

There is one specific protocol that I think we are going to need to special
case and that is HTTP for Web browsing where the latency issues have a
critical impact on the user experience.

The design constraint here being that use of prefix records will inevitably
degrade latency performance even if an attempt is made to pre-fetch records
before the canonical name of the service is known.

10) Support discovery for attributes relating to interactive HTTP in a
single round trip.

If people like the above set of requirements, I can provide a design that
meets them all with a minimum of mechanism.

If there are other requirements, I may be able to support those in addition.

On Wed, Feb 9, 2011 at 10:12 PM, Paul Wouters <[email-masked]> wrote:

> On Wed, 9 Feb 2011, Paul Wouters wrote:
>
>  So can you suggest a format for a new "unified" TLSA/HASTLS record?
>>
>
> Just to make it clear. I would be happy with such a unified record.
> However,
> I'd rather not spend another 9 months on that discussion again, because I
> fear it would dig up the whole PKIX vs DANE again.
>
>
> Paul
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

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

Yes, I am working on the draft right now. As you might expect it is an exte=
nsion of the concepts in CAA and ESRV using the extension mechanism anticip=
ated in CAA.<div><br></div><div>I believe I can support the following crite=
ria with no compromise to any of them.</div>
<div><br></div><div>1) Correct and predictable interaction with CNAME and w=
ildcards</div><div><br></div><div>2) Support for publication of attributes =
that are specific to a particular protocol or apply to a whole domain.</div=
>
<div><br></div><div>3) Ability to prevent downgrade attack by specifying th=
at protocols are always offered or must be used.</div><div><br></div><div>4=
) Ability to prevent trust substitution attacks such as unauthorized issue =
of certificates by CA or use of unauthorized certificates in an application=
.</div>
<div><br></div><div>5) Ability to advertise end entity keys specific to a d=
omain name or domain name and protocol</div><div><br></div><div>6) Ability =
to advertise local trust anchors specific to a domain name<br><div><br>
</div><div>7) Support but not require use of service discovery schemes such=
 as SRV, NAPTR, URI and future schemes as they are developed.</div><div><br=
></div><div>8) Allow for compact implementation. Service discovery must be =
performed by every device on the network, including devices whose performan=
ce does not even support a full IP stack. Code complexity must be kept to a=
 minimum.</div>
<div><br></div><div>9) Enable simplified administration by allowing adminis=
trative tasks to be automated.</div><div><br></div><div><br></div><div>The =
above can all be supported in a manner that is completely protocol neutral =
with no special cases called out in the mechanism. (i.e. not specific to PK=
IX, TLS, application protocol).</div>
<div><br></div><div>However in order to use the mechanism with a particular=
 protocol it is likely going to be necessary to write up a separate draft f=
or that particular binding (like we did in SAML). so while I would design t=
he mechanism to be completely neutral wrt the PKI and security protocol, I =
would only consider writing security bindings for PKIX and TLS and applicat=
ion bindings for HTTP, SMTP, IMAP, POP3 and Jabber.</div>
<div><br></div><div><br></div><div>There is one specific protocol that I th=
ink we are going to need to special case and that is HTTP for Web browsing =
where the latency issues have a critical impact on the user experience.</di=
v>
<div><br></div><div>The design constraint here being that use of prefix rec=
ords will inevitably degrade latency performance even if an attempt is made=
 to pre-fetch records before the canonical name of the service is known.</d=
iv>
<div><br></div><div>10) Support discovery for attributes relating to intera=
ctive HTTP in a single round trip.</div><div><br><br></div><div>If people l=
ike the above set of requirements, I can provide a design that meets them a=
ll with a minimum of mechanism.</div>
<div><br></div><div>If there are other requirements, I may be able to suppo=
rt those in addition.</div><div><br></div><div><br></div><div><br><div clas=
s=3D"gmail_quote">On Wed, Feb 9, 2011 at 10:12 PM, Paul Wouters <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:1p=
x #ccc solid;padding-left:1ex;"><div class=3D"im">On Wed, 9 Feb 2011, Paul =
Wouters wrote:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
So can you suggest a format for a new &quot;unified&quot; TLSA/HASTLS recor=
d?<br>
</blockquote>
<br></div>
Just to make it clear. I would be happy with such a unified record. However=
,<br>
I&#39;d rather not spend another 9 months on that discussion again, because=
 I<br>
fear it would dig up the whole PKIX vs DANE again.<div><div></div><div clas=
s=3D"h5"><br>
<br>
Paul<br>
_______________________________________________<br>
keyassure 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/keyassure" target=3D"_blan=
k">https://www.ietf.org/mailman/listinfo/keyassure</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>

--001636ed72565861e5049bef7d23--

Date: Wed, 9 Feb 2011 22:12:31 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

On Wed, 9 Feb 2011, Paul Wouters wrote:

> So can you suggest a format for a new "unified" TLSA/HASTLS record?

Just to make it clear. I would be happy with such a unified record. However,
I'd rather not spend another 9 months on that discussion again, because I
fear it would dig up the whole PKIX vs DANE again.

Paul

Date: Wed, 9 Feb 2011 22:11:02 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Andrew Sullivan <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

On Wed, 9 Feb 2011, Andrew Sullivan wrote:

> Ah, I get what you're arguing.  Hrm.
>
> So what you want, I think, is a three-value state:
>
>    - zone positively has record
>        This amounts to an affirmation by the zone admin that it
>        supports the feature.

Yes.

>    - zone asserts it does not have record
>        This is an indeterminate state with respect to the new
>        feature, because the the signed absence of a record is not a
>        meaningful assertion.

Well, the absense tells you no DANE based TLS is there. There could still be
TLS backed by PKIX.

>    - zone has record asserting no support
>        This is the zone admin asserting that it does _not_ support
>        the feature.

This would be the "null TLSA" record? I find that record unneccessary. We
also don't have a "null PKIX" record. Is there a desire to create one
for those as well?

Frankly, adding infrastructure to better support insecure protocols makes
no sense to me. Especailly because we are hard on our way on killing
port 80, and the last group of clients on port 80 will be those not
supporting any new RRTYPE anyway.

Paul

Date: Wed, 9 Feb 2011 22:05:31 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

On Wed, 9 Feb 2011, Phillip Hallam-Baker wrote:

> So what we are going to end up with here by splitting TLSA and HASTLS is a scheme that requires two separate records and discovery
> patterns and is considerably less efficient than a scheme that was designed to support both from the start.

So can you suggest a format for a new "unified" TLSA/HASTLS record?

> In my view the requirement for 'must use TLS' has far deeper support amongst the client vendors than the requirements DANE is apparently
> trying to meet.

Unfortunately, whenever I suggest a "must use TLS" bit, I'm told  you can't dictate policy in DNS.

> Thus if DANE does not think about how to work well with HASTLS it is likely to be irrelevant.

I'd be interested in seeing your suggestion for a unified record.

Paul

Date: Wed, 9 Feb 2011 17:23:29 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Wouters <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

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

On Wed, Feb 9, 2011 at 12:34 PM, Paul Wouters <[email-masked]> wrote:
>
> What's wrong with an NSEC record for the TLSA/HASTLS record saying that?

What is wrong is that we are designing two separate mechanisms here when we
should really have one.

This would not matter so much if not for the fact that the design of key
assure is being constrained by attempts to support performance requirements.

So what we are going to end up with here by splitting TLSA and HASTLS is a
scheme that requires two separate records and discovery patterns and is
considerably less efficient than a scheme that was designed to support both
from the start.

In my view the requirement for 'must use TLS' has far deeper support amongst
the client vendors than the requirements DANE is apparently trying to meet.

Thus if DANE does not think about how to work well with HASTLS it is likely
to be irrelevant. It is very easy to glom a key publication scheme onto a
policy record. Working the other way is rather harder.

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

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

<div>On Wed, Feb 9, 2011 at 12:34 PM, Paul Wouters=A0<span dir=3D"ltr">&lt;=
<a href=3D"mailto:[email-masked]">[email-masked]</a>&gt;</span>=A0w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin-top: 0px; margin-rig=
ht: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; bo=
rder-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left=
: 1ex; ">
What&#39;s wrong with an NSEC record for the TLSA/HASTLS record saying that=
?</blockquote></div><div><br></div><div><br></div><div><br></div>What is wr=
ong is that we are designing two separate mechanisms here when we should re=
ally have one.<div>
<br></div><div>This would not matter so much if not for the fact that the d=
esign of key assure is being constrained by attempts to support performance=
 requirements.</div><div><br></div><div><br></div><div>So what we are going=
 to end up with here by splitting TLSA and HASTLS is a scheme that requires=
 two separate records and discovery patterns and is considerably less effic=
ient than a scheme that was designed to support both from the start.</div>
<div><br></div><div>In my view the requirement for &#39;must use TLS&#39; h=
as far deeper support amongst the client vendors than the requirements DANE=
 is apparently trying to meet.</div><div><br></div><div>Thus if DANE does n=
ot think about how to work well with HASTLS it is likely to be irrelevant. =
It is very easy to glom a key publication scheme onto a policy record. Work=
ing the other way is rather harder.</div>
<div><br>-- <br>Website: <a href=3D"http://hallambaker.com/">http://hallamb=
aker.com/</a><br><br>
</div>

--0016e645ab5617ea9d049be0eaa7--

Sender: [email-masked]
Date: Wed, 9 Feb 2011 14:09:27 -0800
From: Zack Weinberg <[email-masked]>
To: Andrew Sullivan <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

On Wed, Feb 9, 2011 at 1:44 PM, Andrew Sullivan <[email-masked]> wrote:
> Ah, I get what you're arguing. =C2=A0Hrm.
>
> So what you want, I think, is a three-value state:
>
> =C2=A0 =C2=A0- zone positively has record
> =C2=A0 =C2=A0 =C2=A0 =C2=A0This amounts to an affirmation by the zone adm=
in that it
> =C2=A0 =C2=A0 =C2=A0 =C2=A0supports the feature.
>
> =C2=A0 =C2=A0- zone asserts it does not have record
> =C2=A0 =C2=A0 =C2=A0 =C2=A0This is an indeterminate state with respect to=
 the new
> =C2=A0 =C2=A0 =C2=A0 =C2=A0feature, because the the signed absence of a r=
ecord is not a
> =C2=A0 =C2=A0 =C2=A0 =C2=A0meaningful assertion.
>
> =C2=A0 =C2=A0- zone has record asserting no support
> =C2=A0 =C2=A0 =C2=A0 =C2=A0This is the zone admin asserting that it does =
_not_ support
> =C2=A0 =C2=A0 =C2=A0 =C2=A0the feature.

Yeah.

> Is that right? =C2=A0If it's what you're arguing for, it's a little odd,
> because we don't normally require this for other protocols. =C2=A0That is=
,
> if I'm adding (say) an SMTP extension, your rejection of the extension
> says nothing about your awareness of the extension. =C2=A0Now, you seem t=
o
> be arguing in this case that provable non-existence of the record is
> not the same as saying you positively don't support the feature, but
> I'm not sure I see the additional value in the distinction. =C2=A0(As a f=
an
> of intuitionistic logic, however, I confess that the three-value
> approach has appeal to me personally.)

I am personally only arguing for a weaker position: _if_ "saying that
you positively don't support a feature" is considered to be a use case
worth including in the specification, _then_ that statement must not
be expressed via "zone asserts it does not have record".

Concretely, I'd be okay with TLSA not having a way to say "this domain
positively does not provide any TLS-secured services".  That was Matt
McCutchen's feature request; I can see the use but if it's not
considered valuable enough to include I'd be fine with that.  What I'm
not fine with is being forced to add TLSA records for all secured
services in a zone just so I can start signing it.

zw

Date: Wed, 9 Feb 2011 16:44:40 -0500
From: Andrew Sullivan <[email-masked]>
To: Zack Weinberg <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

On Wed, Feb 09, 2011 at 12:27:27PM -0800, Zack Weinberg wrote:
> Basically what I am saying is we cannot treat a zone as having
> affirmatively opted in to any new application/transport layer
> semantics just because their zone is signed.  We have to have a
> successful secure lookup of at least one new record.

Ah, I get what you're arguing.  Hrm.  

So what you want, I think, is a three-value state:

    - zone positively has record
        This amounts to an affirmation by the zone admin that it
        supports the feature.

    - zone asserts it does not have record
        This is an indeterminate state with respect to the new
        feature, because the the signed absence of a record is not a
        meaningful assertion.

    - zone has record asserting no support
        This is the zone admin asserting that it does _not_ support
        the feature.

Is that right?  If it's what you're arguing for, it's a little odd,
because we don't normally require this for other protocols.  That is,
if I'm adding (say) an SMTP extension, your rejection of the extension
says nothing about your awareness of the extension.  Now, you seem to
be arguing in this case that provable non-existence of the record is
not the same as saying you positively don't support the feature, but
I'm not sure I see the additional value in the distinction.  (As a fan
of intuitionistic logic, however, I confess that the three-value
approach has appeal to me personally.)

A

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

Sender: [email-masked]
Date: Wed, 9 Feb 2011 12:27:27 -0800
From: Zack Weinberg <[email-masked]>
To: Andrew Sullivan <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

On Wed, Feb 9, 2011 at 12:03 PM, Andrew Sullivan <[email-masked]> wrote:
> On Wed, Feb 09, 2011 at 11:39:33AM -0800, Zack Weinberg wrote:
>
>> NSEC for any new DNS record MUST mean "behave as you would have prior
>> to the invention of the new DNS record". =C2=A0To do otherwise would
>> require a flag day for the entire Internet and therefore jeopardize
>> not only the transition to whatever new DNS record is suggested, but
>> the transition to DNSSEC itself.
>
> I don't understand what that means.
>
> An NSEC record with a negative response to a query is a cryptographic
> proof that the record doesn't exist. =C2=A0So in this sense, an NSEC reco=
rd
> for the new DNS RRTYPE works exactly the same way as any other RRTYPE.

Right.

> But obviously, the _semantics_ of such provable non-existence is
> altogether a different matter, for the very same reason that the
> semantics of a new RRTYPE could be different for each such type. =C2=A0No=
?

No. Individual zone administrators should be able to sign their zone
_without making any other changes_ and have everything continue to
work as before.  That means the semantics of provable non-existence
needs to be identical to the semantics of "insecure/indeterminate" (in
the RFC 4033 sense) non-existence in all cases, and that in turn has
to be legacy compatibility behavior.

Basically what I am saying is we cannot treat a zone as having
affirmatively opted in to any new application/transport layer
semantics just because their zone is signed.  We have to have a
successful secure lookup of at least one new record.

zw

Date: Wed, 9 Feb 2011 15:03:06 -0500
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

On Wed, Feb 09, 2011 at 11:39:33AM -0800, Zack Weinberg wrote:

> NSEC for any new DNS record MUST mean "behave as you would have prior
> to the invention of the new DNS record".  To do otherwise would
> require a flag day for the entire Internet and therefore jeopardize
> not only the transition to whatever new DNS record is suggested, but
> the transition to DNSSEC itself.

I don't understand what that means.

An NSEC record with a negative response to a query is a cryptographic
proof that the record doesn't exist.  So in this sense, an NSEC record
for the new DNS RRTYPE works exactly the same way as any other RRTYPE.

But obviously, the _semantics_ of such provable non-existence is
altogether a different matter, for the very same reason that the
semantics of a new RRTYPE could be different for each such type.  No?

> (However, a "bogus" DNSSEC validation state for any lookup at all can
> and should be treated as a MUST-refuse-to-proceed condition.)

That is in fact what it's supposed to mean in the DNS, yes.

A

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

Sender: [email-masked]
Date: Wed, 9 Feb 2011 11:39:33 -0800
From: Zack Weinberg <[email-masked]>
To: Paul Wouters <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

On Wed, Feb 9, 2011 at 9:34 AM, Paul Wouters <[email-masked]> wrote:
> On Wed, 9 Feb 2011, Martin Rex wrote:
>
>>>>> I agree with this, but the question is how do you present an empty
>>>>> list.
>>>>
>>>> What exactly would you want to convey with an empty list?
>>>>
>>>> =C2=A0"I won't respond to TLS, so don't even bother trying"
>>>
>>> More precisely, "there is no TLS service associated with this DNS
>>> name/transport/port". =C2=A0Therefore, general-purpose clients that ref=
er to
>>> TLS services by DNS name/transport/port will not be able to make a
>>> connection.
>
> What's wrong with an NSEC record for the TLSA/HASTLS record saying that?

NSEC for any new DNS record MUST mean "behave as you would have prior
to the invention of the new DNS record".  To do otherwise would
require a flag day for the entire Internet and therefore jeopardize
not only the transition to whatever new DNS record is suggested, but
the transition to DNSSEC itself.

(However, a "bogus" DNSSEC validation state for any lookup at all can
and should be treated as a MUST-refuse-to-proceed condition.)

zw

From: Henry Story <[email-masked]>
Date: Wed, 9 Feb 2011 18:37:52 +0100
To: [email-masked]
Subject: [keyassure] WebID at W3C and keyassure

Hi,

	The W3C has started the WebID incubator group =
http://tinyurl.com/webidxg which is continuing work previously known as =
foaf+ssl in a more formal setting. I bring this to your attention =
because the foaf+ssl protocol [1], is conceptually very similar to what =
I believe keyassure is setting out to do. (I have not seen a draft spec =
yet, and am going from the group description).

   Where keyassure is attempting to identify a server using uniquely =
identifying information in the DNS, WebID is identifying an end user =
(human, robot or agency), via a profile document containing =
cryptographically uniquely identifying information placed in the web. =
Keyassure coul probably use the dns typed subject alternative name to =
identify the verify X509 certifactes, WebID uses the SAN (and IAN) with =
https IDs to identify the agent. We are both using canonical referential =
lookups to get the meaning of a name (Domain Name with keyassure, =
HTTP+TLS with WebID) which we can then use to prove referential =
integrity (authentication).

   So this parallel would by itself be enough to bring this to your =
attention. But it turns out that WebID could become all the easier to =
deploy and use if keyassure works, since TLS on the server will become =
much easier to deploy. Furthermore it makes some very interesting things =
possible, as discussed for example in "Turning every Web Server into a =
CA",=20

http://lists.w3.org/Archives/Public/public-xg-webid/2011Feb/0060.html

For this use case, I think it would help there if the full public key =
were in the DNS.=20

WebID is really about enabling a distributed secure social web. [3]

In any case I think it would be very useful to make sure we track each =
other's work. I am subscribed to this mailing list now, and our =
conversations are fully public too. Joining the mailing list is easy =
http://lists.w3.org/Archives/Public/public-xg-webid/=20
and we welcome contributions. It is quite easy to join the XG also, if =
you feel a desire to participate more actively. :-)

Henry Story

[1]   in development here
    http://www.w3.org/2005/Incubator/webid/spec/
[2] "How does Secure Authentication Work in FOAF+SSL" has an =
illustration that helps see the parallel. =
http://www.w3.org/wiki/Foaf%2Bssl/FAQ#How_does_Secure_Authentication_Work_=
with_FOAF.2BSSL.3F
[3] see the videos posted on my home page:

Social Web Architect
http://bblfish.net/

Date: Wed, 9 Feb 2011 12:34:51 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Martin Rex <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

On Wed, 9 Feb 2011, Martin Rex wrote:

>>>> I agree with this, but the question is how do you present an empty list.
>>>
>>> What exactly would you want to convey with an empty list?
>>>
>>>  "I won't respond to TLS, so don't even bother trying"
>>
>> More precisely, "there is no TLS service associated with this DNS
>> name/transport/port".  Therefore, general-purpose clients that refer to
>> TLS services by DNS name/transport/port will not be able to make a
>> connection.

What's wrong with an NSEC record for the TLSA/HASTLS record saying that?

> I should have been more explicit on this:
>
> There is a client with a desire to communicate, and a preference/intend
> for TLS-protection.  But with most protocols, there is a fallback
> strategy to communicate without TLS.  It could be that the initial
> reference does not even imply TLS, and its only the client who is
> looking for clues in DNS whether TLS is available.

This is why in HASTLS, you can state whether or not there is a fallback you
may use.

> So I'm still wondering: what message should an empty list convey?
>
> A pre-DANE client might fallback to non-TLS if TLS doesn't work,
> or it might not try TLS at all.
>
> What should a DANE-aware client, that is wildly determined to communicate
> do when finding an empty TLSA record?  Go straight for the unprotected
> communication (which is what such a record would imply), or bother
> the user with an annoying popup before doing the fallback on unprotected
> communication.

An empty TLSA record offers nothing more over an NSEC record.

> I doubt that "not communicating at all" is a workable solution for such
> clients, because it is likely to be perceived as a usability problem
> by a non-marginal fraction of the user base.

Yet, that is what security will require. If a TLSA record states there is
TLS, or a DNSSEC error occurs trying to get a TLS related record, you
SHOULD NOT fallback to plaintext.

The usability issue is in running legacy port 80..... Fix that and your problem
will go away. Then at most the user will see a bad/hacked cert with a popup,
hopefully preventing the user from connecting.

> Most "Web users" think that "the Web" == "the Internet" and are so completely
> accustomed to trust everyone with everything over completely insecure
> communication channels (commonly described with "http://")
> that it is going to be hard to turn back time on this.

HASTLS and STS are bascially the start of the end of port 80.

> I'm currently quite annoyed of my EMail provider, because their Web-Mail
> interface completely refuses to serve a login page via HTTPS:
> They do "POST" to a HTTPS url on their Login-Page, but that page itself
> is accessible only through HTTP (on a host that does not listen on 443).

Tell them that is unacceptable.

Paul

From: Martin Rex <[email-masked]>
To: [email-masked] (Matt McCutchen)
Date: Wed, 9 Feb 2011 17:39:32 +0100 (MET)
Cc: [email-masked]
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain
Reply-To: [email-masked]

Matt McCutchen wrote:
> 
> On Tue, 2011-02-01 at 23:42 +0100, Martin Rex wrote:
> > Zack Weinberg wrote:
> > > 
> > > > If there is a DANE record, then any wise client should interpret that
> > > > as an exclusive list of allowed TLS certificates
> > > 
> > > I agree with this, but the question is how do you present an empty list.
> > 
> > What exactly would you want to convey with an empty list?
> > 
> >  "I won't respond to TLS, so don't even bother trying"
> 
> More precisely, "there is no TLS service associated with this DNS
> name/transport/port".  Therefore, general-purpose clients that refer to
> TLS services by DNS name/transport/port will not be able to make a
> connection.  This does not preclude the admin to run a TLS server for
> some special purpose, to accept connections only from specially
> configured clients, but in most cases it will make sense to use DANE.
> 
> >
> > The only time when such an information becomes interesting is when
> > you have a client with a strong desire to communicate with a target
> > and intent/preference for using TLS-protection on that communication.

I should have been more explicit on this:

There is a client with a desire to communicate, and a preference/intend
for TLS-protection.  But with most protocols, there is a fallback
strategy to communicate without TLS.  It could be that the initial
reference does not even imply TLS, and its only the client who is
looking for clues in DNS whether TLS is available.

So I'm still wondering: what message should an empty list convey?

A pre-DANE client might fallback to non-TLS if TLS doesn't work,
or it might not try TLS at all.

What should a DANE-aware client, that is wildly determined to communicate
do when finding an empty TLSA record?  Go straight for the unprotected
communication (which is what such a record would imply), or bother
the user with an annoying popup before doing the fallback on unprotected
communication.

I doubt that "not communicating at all" is a workable solution for such
clients, because it is likely to be perceived as a usability problem
by a non-marginal fraction of the user base.

Most "Web users" think that "the Web" == "the Internet" and are so completely
accustomed to trust everyone with everything over completely insecure
communication channels (commonly described with "http://")
that it is going to be hard to turn back time on this.

I'm currently quite annoyed of my EMail provider, because their Web-Mail
interface completely refuses to serve a login page via HTTPS:
They do "POST" to a HTTPS url on their Login-Page, but that page itself
is accessible only through HTTP (on a host that does not listen on 443).

>
> > DANE-unaware clients will continue trying to use TLS.
> > What is your rationale for making DANE-aware clients exhibit
> > a different behaviour and entirely stop trying to use TLS?
> 
> I assert that I do not offer the TLS service, so there is no point in
> DANE clients trying to connect to it.  In particular, I do not want them
> to connect to some fake service with a certificate from a public CA.
> There is nothing I can do about the DANE-unaware clients.

While there are a few clients of the type "TLS or refuse to connect",
the vast majority of clients will happily connect without TLS instead,
and end users have been conditioned over more than a decade that
fallbacks are OK.

-Martin

From: Warren Kumari <[email-masked]>
Date: Tue, 8 Feb 2011 14:46:23 -0500
To: [email-masked]
Subject: Re: [keyassure] Call for consensus on #1

Ok, we are calling consensus on #1 -- We will be using a name with a =
prefix....

I have just opened a new issue (Issue #19 - =
http://trac.tools.ietf.org/wg/dane/trac/ticket/19 ) to finalize the =
format of the prefix.

I realize that we have already had a fair bit of discussion on what =
Issue #19 discusses, and I don't want us to forget the progress that we =
have made on it.=20
Closing #1 and opening #19 is partly an administrative move, but also =
allows us to focus our discussions and all understand where on the page =
we are...

I'd like to once again thank folk for all of their hard work and ongoing =
discussions.

W

On Feb 1, 2011, at 9:15 AM, Ond=C5=99ej Sur=C3=BD wrote:

> Hi,
>=20
> I would like to call for consensus on issue #1.
>=20
> The consensus would be that the draft-dane-protocol would define =
lookup on TLSA records as query for a name prefixed with a port or port =
and proto.
>=20
> Possible examples (no preference here for issue #1):
> _443.www.example.com
> _443._tcp.example.com
> _tcp_443.example.com.
>=20
> I will open separate issue# for the particular solution for querying =
(proto or not, fallback or not, etc.), since I don't think we have =
consensus on that yet.  (And I think we should step forward constantly =
even in small steps.)
>=20
> Ondrej
> --=20
> Ond=C5=99ej Sur=C3=BD
> vedouc=C3=AD v=C3=BDzkumu/Head of R&D department
> -------------------------------------------
> CZ.NIC, z.s.p.o.    --    Laborato=C5=99e CZ.NIC
> Americka 23, 120 00 Praha 2, Czech Republic
> mailto:[email-masked]    http://nic.cz/
> tel:+420.222745110       fax:+420.222745112
> -------------------------------------------
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

From: Matt McCutchen <[email-masked]>
To: keyassure <[email-masked]>
Date: Sat, 05 Feb 2011 15:48:41 -0500
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

On Sat, 2011-02-05 at 12:53 -0500, Phillip Hallam-Baker wrote:

> I think this solution can be made to work, but it is not the best
> solution that we can achieve.
> 
> In addition to the IPv4 exhaustion issue, the IETF has been facing a
> port exhaustion issue as well for some time. And so there has been a
> push to move to use DNS protocol prefixes to fix that problem. [...]

> As far as mechanism goes, I see two distinct conditions to support
> 
> 1) Where the connection is established by the DNS name directly
> 
> 2) Where a prefixed discovery mechanism is involved.
> 
> The scheme I propose has essentially the same performance
> characteristics as Matt's, I just have slightly different semantics,
> instead of always looking for the prefix record, I always look for a
> record at the unprefixed domain that may tell me that advanced
> discovery (SRV, NAPTR, URI) is in use and that there is more detailed
> data available or may tell me that there is no additional data to be
> found.
> 
> It is of course still possible to perform optimistic pre-fetching of
> the prefixed records at the start of discovery under my scheme as
> well.
> 
> I don't see this as a 'grand design', I just see it as fitting in with
> the existing DNS discovery architecture rather than complicating it. I
> give the administrator a straightforward binary choice, either do not
> differentiate between trust criteria for services at all, or
> alternatively employ advanced discovery to do so.

I agree that there are problems to be solved with discovery.  What I
don't understand is what you hope to gain by entangling discovery with
DANE.

In my view, binding credentials to the hostname+transport+port tuple to
which the client connects is ideal because:

1. All clients we care about, including generic tools like stunnel and
openssl s_client, go through this stage.  It will be straightforward to
modify them to pass the information to the TLS library.  The library
could even have a single API call "dane_tls_connect(hostname, port)"
that both connects the socket and saves the endpoint info for later
checking, giving us the "secure TCP" primitive we never had (likewise
for other transports), but I suspect there must be reasons why this
approach is not already taken with the hostname.

2. With current SNI, this tuple is exactly what is available to the
server when it chooses a credential to present.  Thus, in the absence of
active attacks, the set of credentials that clients might see when
making a connection is a function only of this tuple.  Finer
distinctions cannot meaningfully be made in DANE.  If people want to
virtual-host multiple service types for the same hostname on the same
port and demultiplex them at the TLS level, that would require support
for service types in both SNI and DANE, but I highly doubt that will
become important.

Can you point to any concrete use cases that would benefit from your
proposal?

> The clients that are going to make use of these keys are going to have
> to have custom code anyway.

Not really.  All one would have to do, using NSS as an example, is
modify SSL_SetURL (a misnomer; it takes only the hostname) to also take
the transport and port and modify the applications to pass that
information.

> One issue I do see with the port prefix approach is that it does not
> make much sense with the existing scheme employed to support
> multi-homing of Web hosts - multiple A records. For example, if
> example.com has four hosts, it will have something like:
> 
> $origin example.com
> www  CNAME example.com
> .    A 10.0.0.1
> .    A 10.0.0.2
> .    A 10.0.0.3
> .    A 10.0.0.4
> 
> So now we add a record
> 
> _80._http  TLSA  (whatever)
> 
> Which binds to a specific port on a non specific IP address. That does
> not make much sense to me.

Agreed, that is a little goofy.  But it's not a reason to prefer your
combined DANE + discovery proposal because SRV in combination with DANE
as I propose will solve the problem equally well.  And I don't think
it's worth bending over backwards to solve this in DANE if the
application is not prepared to adopt a discovery mechanism.

-- 
Matt

Date: Sat, 5 Feb 2011 12:53:39 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: James Cloos <[email-masked]>
Cc: keyassure <[email-masked]>
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

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

On Fri, Feb 4, 2011 at 7:38 PM, James Cloos <[email-masked]> wrote:

> >>>>> "MM" == Matt McCutchen <[email-masked]> writes:
>
> >> Those are not awful.  They probably make prefixes usable.
> >>
> >> (And perhaps should be used for existing SRV usages, too.)
>
> MM> That's what I was hoping to achieve.  I appreciate the vote
> MM> of confidence.  :)
>
> I wanted to think about it some more, but I do agree that what you
> propose is the right solution.

I think this solution can be made to work, but it is not the best solution
that we can achieve.

In addition to the IPv4 exhaustion issue, the IETF has been facing a port
exhaustion issue as well for some time. And so there has been a push to move
to use DNS protocol prefixes to fix that problem.

I see two very distinct sets of requirements by application protocol:

1) How to deal with widely deployed legacy protocols requiring low latency
connection establishment.

2)  How to deal with new protocols and protocols that do not require
optimization

The first is essentially use of HTTP for Web browsing. There are other
protocols in use, but none where the impact of DNS connection establishment
is anywhere near a dominant impact on performance.

So it really is quite appropriate to treat HTTP as a special case, indeed
HTTP specifically for use in Web Browsing as opposed to using it as a Web
Services transport, firewall bypass protocol or whatever.

As far as mechanism goes, I see two distinct conditions to support

1) Where the connection is established by the DNS name directly

2) Where a prefixed discovery mechanism is involved.

The scheme I propose has essentially the same performance characteristics as
Matt's, I just have slightly different semantics, instead of always looking
for the prefix record, I always look for a record at the unprefixed domain
that may tell me that advanced discovery (SRV, NAPTR, URI) is in use and
that there is more detailed data available or may tell me that there is no
additional data to be found.

It is of course still possible to perform optimistic pre-fetching of the
prefixed records at the start of discovery under my scheme as well.

I don't see this as a 'grand design', I just see it as fitting in with the
existing DNS discovery architecture rather than complicating it. I give the
administrator a straightforward binary choice, either do not differentiate
between trust criteria for services at all, or alternatively employ advanced
discovery to do so.

The clients that are going to make use of these keys are going to have to
have custom code anyway.

One issue I do see with the port prefix approach is that it does not make
much sense with the existing scheme employed to support multi-homing of Web
hosts - multiple A records. For example, if example.com has four hosts, it
will have something like:

$origin example.com
www  CNAME example.com
.    A 10.0.0.1
.    A 10.0.0.2
.    A 10.0.0.3
.    A 10.0.0.4

So now we add a record

_80._http  TLSA  (whatever)

Which binds to a specific port on a non specific IP address. That does not
make much sense to me.

Of course we are trying to get away from using round robin discovery, it is
not a very good approach for load balancing. But the port prefix approach is
not playing nice with the existing proposed alternatives.

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

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

<br><br><div class=3D"gmail_quote">On Fri, Feb 4, 2011 at 7:38 PM, James Cl=
oos <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">cloos@jhcloo=
s.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">&gt;&gt;&gt;&gt;&gt; &quot;MM&quot; =3D=3D Matt McCutchen=
 &lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>&g=
t; writes:<br>
<br>
</div><div class=3D"im">&gt;&gt; Those are not awful. =A0They probably make=
 prefixes usable.<br>
&gt;&gt;<br>
&gt;&gt; (And perhaps should be used for existing SRV usages, too.)<br>
<br>
</div>MM&gt; That&#39;s what I was hoping to achieve. =A0I appreciate the v=
ote<br>
MM&gt; of confidence. =A0:)<br>
<br>
I wanted to think about it some more, but I do agree that what you<br>
propose is the right solution.</blockquote><div><br></div><div><br></div><d=
iv>I think this solution can be made to work, but it is not the best soluti=
on that we can achieve.</div><div><br></div><div>In addition to the IPv4 ex=
haustion issue, the IETF has been facing a port exhaustion issue as well fo=
r some time. And so there has been a push to move to use DNS protocol prefi=
xes to fix that problem.</div>
<div><br></div><div>I see two very distinct sets of requirements by applica=
tion protocol:</div><div><br></div><div><br></div><div>1) How to deal with =
widely deployed legacy protocols requiring low latency connection establish=
ment.</div>
<div><br></div><div>2) =A0How to deal with new protocols and protocols that=
 do not require optimization=A0</div><div>=A0</div><div><br></div><div>The =
first is essentially use of HTTP for Web browsing. There are other protocol=
s in use, but none where the impact of DNS connection establishment is anyw=
here near a dominant impact on performance.</div>
<div><br></div><div>So it really is quite appropriate to treat HTTP as a sp=
ecial case, indeed HTTP specifically for use in Web Browsing as opposed to =
using it as a Web Services transport, firewall bypass protocol or whatever.=
</div>
<div><br></div><div><br></div><div>As far as mechanism goes, I see two dist=
inct conditions to support</div><div><br></div><div>1) Where the connection=
 is established by the DNS name directly</div><div><br></div><div>2) Where =
a prefixed discovery mechanism is involved.</div>
<div><br></div><div><br></div><div>The scheme I propose has essentially the=
 same performance characteristics as Matt&#39;s, I just have slightly diffe=
rent semantics, instead of always looking for the prefix record, I always l=
ook for a record at the unprefixed domain that may tell me that advanced di=
scovery (SRV, NAPTR, URI) is in use and that there is more detailed data av=
ailable or may tell me that there is no additional data to be found.</div>
<div><br></div><div>It is of course still possible to perform optimistic pr=
e-fetching of the prefixed records at the start of discovery under my schem=
e as well.</div><div><br></div><div><br></div><div>I don&#39;t see this as =
a &#39;grand design&#39;, I just see it as fitting in with the existing DNS=
 discovery architecture rather than complicating it. I give the administrat=
or a straightforward binary choice, either do not differentiate between tru=
st criteria for services at all, or alternatively employ advanced discovery=
 to do so.</div>
<div><br></div><div>The clients that are going to make use of these keys ar=
e going to have to have custom code anyway.</div><div><br></div><div><br></=
div><div>One issue I do see with the port prefix approach is that it does n=
ot make much sense with the existing scheme employed to support multi-homin=
g of Web hosts - multiple A records. For example, if <a href=3D"http://exam=
ple.com">example.com</a> has four hosts, it will have something like:</div>
<div><br></div><div>$origin <a href=3D"http://example.com">example.com</a><=
/div><div>www =A0CNAME <a href=3D"http://example.com">example.com</a></div>=
<div>. =A0 =A0A 10.0.0.1</div><div><meta charset=3D"utf-8">. =A0 =A0A 10.0.=
0.2</div><div>
<meta charset=3D"utf-8">. =A0 =A0A 10.0.0.3</div><div><meta charset=3D"utf-=
8">. =A0 =A0A 10.0.0.4</div></div><div><br></div><div>So now we add a recor=
d</div><div><br></div><div>_80._http =A0TLSA =A0(whatever)</div><div><br></=
div><div>Which binds to a specific port on a non specific IP address. That =
does not make much sense to me.</div>
<div><br></div><div>Of course we are trying to get away from using round ro=
bin discovery, it is not a very good approach for load balancing. But the p=
ort prefix approach is not playing nice with the existing proposed alternat=
ives.</div>
<div><br></div><br>-- <br>Website: <a href=3D"http://hallambaker.com/">http=
://hallambaker.com/</a><br><br>

--0016e642d3bab8aa34049b8cadef--

From: Matt McCutchen <[email-masked]>
To: keyassure <[email-masked]>
Date: Fri, 04 Feb 2011 22:43:44 -0500
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services

On Fri, 2011-02-04 at 21:06 +0100, Martin Rex wrote: 
> Matt McCutchen wrote:
> > 
> > On Thu, 2011-02-03 at 20:16 -0500, Matt McCutchen wrote:
> > > using the same certificate for multiple services at the
> > > same name exposes you to cross-protocol attacks.
> > 
> > To clarify: even if the services are at the same security level, the
> > case in which a MITM diverts the connection to a service other than the
> > one the client wanted should be caught at the TLS level.
> > 
> > TLS is designed to be capable of providing a strong guarantee: if your
> > connection goes through, you are talking to the service you wanted.
> > Let's not weaken this by being sloppy with the naming.
> 
> You're confusing two things here: [...]

I did not intend to do so.  I understand that naming and certificate
acceptance criteria are outside the scope of TLS per se.  By the "TLS
level", I meant the facility that provides TLS connections with server
authentication to applications.

> TLSA records of the form
> 
>    _443._tcp.www.example.com   TLSA   (server-cert|server-cert-hash)
> 
> would allow to distinguish server endpoints at the granularity
> (port+protocol+hostname).  With this scheme it is possible
> to prevent "cross-protocol attacks" by assigning distinct
> credentials to distinct protocols.  (There is no protection
> if the services share a single credential, though).

Right.  If SNI would include the transport+port, having the server check
that information would be another way to prevent the attacks.  However,
I'm thinking it may be better design for each service to have a
credential valid only for the name+transport+port combinations it is
capable of serving.  This will hopefully be less of a PITA to arrange
with DANE than under the traditional public CA system.

-- 
Matt

From: James Cloos <[email-masked]>
To: Matt McCutchen <[email-masked]>
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABHNCSVQICAgIfAhkiAAAAI1J REFUOE+lU9ESgCAIg64P1y+ngUdxhl5H8wFbbM0OmUiEhKkCYaZThXCo6KE5sCbA1DDX3genvO4d eBQgEMaM5qy6uWk4SfBYfdu9jvBN9nSVDOKRtwb+I3epboOsOX5pZbJNsBJFvmQQ05YMfieIBnYX FK2N6dOawd97r/e8RjkTLzmMsiVgrAoEugtviCM3v2WzjgAAAABJRU5ErkJggg==
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, 04 Feb 2011 19:38:41 -0500
Lines: 15
Cc: keyassure <[email-masked]>
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

>>>>> "MM" == Matt McCutchen <[email-masked]> writes:

>> Those are not awful.  They probably make prefixes usable.
>> 
>> (And perhaps should be used for existing SRV usages, too.)

MM> That's what I was hoping to achieve.  I appreciate the vote
MM> of confidence.  :)

I wanted to think about it some more, but I do agree that what you
propose is the right solution.

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

Date: Fri, 4 Feb 2011 18:52:56 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Mark Andrews <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

On Sat, 5 Feb 2011, Mark Andrews wrote:

> 	SOA/NS not answered by GLB's.

Cisco should fix that :)

Paul

From: James Cloos <[email-masked]>
To: =?utf-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABHNCSVQICAgIfAhkiAAAAI1J REFUOE+lU9ESgCAIg64P1y+ngUdxhl5H8wFbbM0OmUiEhKkCYaZThXCo6KE5sCbA1DDX3genvO4d eBQgEMaM5qy6uWk4SfBYfdu9jvBN9nSVDOKRtwb+I3epboOsOX5pZbJNsBJFvmQQ05YMfieIBnYX FK2N6dOawd97r/e8RjkTLzmMsiVgrAoEugtviCM3v2WzjgAAAABJRU5ErkJggg==
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, 04 Feb 2011 14:36:21 -0500
Lines: 10
Cc: [email-masked]
Subject: Re: [keyassure] Call for consensus on #1

After further thought, provided that Matt's proposal to deal with CNAME
and wildcard issues is used, I agree that prefixed lookups are best.

All of the arguments for prefixes are good, and his proposal deals well
with the prefix vs ( CNAME | wildcard ) issues which would otherwise
contraindicate prefixes.

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

Date: Fri, 4 Feb 2011 16:15:40 -0500
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

On Sat, Feb 05, 2011 at 07:53:30AM +1100, Mark Andrews wrote:
> 
> 	DS don't exist with islands of trust.

Right, but in that case you have a DNSKEY with no DS at the parent.

> 	DNSKEY doesn't exist with non-signed zones.

Non-signed zones aren't a consideration here, because they're never
going to be candidates for any of the DANE output.  Normally, it's a
problem, but not in this case.

> 	SOA/NS not answered by GLB's.

Yes.  But we don't care, because the DS/DNSKEY point is the one we
need.  Either you have a DS through which you can build a chain, or
you have a TA matching the DNSKEY, or you don't use the data from this
zone (for these purposes).

A

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

To: Andrew Sullivan <[email-masked]>
From: Mark Andrews <[email-masked]>
Date: Sat, 05 Feb 2011 07:53:30 +1100
Cc: [email-masked]
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

In message <[email-masked]>, Andrew Sullivan writes:
> On Thu, Feb 03, 2011 at 11:15:34PM -0500, Matt McCutchen wrote:
> > 
> > Not any more than the DNSKEY RRset does.  Either RRset will be cached by
> > the ISP as soon as one client cares about it.
> 
> I think you mean the DS, since the DNSKEY isn't at the parent.  But
> that's not the only case anyway.  As I understand it, the idea here is
> that you're going to crawl up and look to see whether the parent
> includes a record "covering" the policy in the child.  TLDs won't have
> such a record, which will mean that they'll get a lot of queries for
> things they don't have.  Negative caches don't last long.
> 
> This is why I claim that the only sensible way to look for the zone
> cut, if that's what we're going to do, is to use the DS record itself,
> because you're guaranteed to need it or a configured trust anchor for
> this scheme to work.

Give the amount of broken DNS implementations out there you can't do
this reliably with any query.  SOA and NS should be in every zone but
they are not.

	DS don't exist with islands of trust.
	DNSKEY doesn't exist with non-signed zones.
	SOA/NS not answered by GLB's.
 
Mark

> A
> 
> -- 
> Andrew Sullivan
> [email-masked]
> Shinkuro, Inc.
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

From: Martin Rex <[email-masked]>
To: [email-masked] (Matt McCutchen)
Date: Fri, 4 Feb 2011 21:06:11 +0100 (MET)
Cc: [email-masked]
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services
Reply-To: [email-masked]

Matt McCutchen wrote:
> 
> On Thu, 2011-02-03 at 20:16 -0500, Matt McCutchen wrote:
> > using the same certificate for multiple services at the
> > same name exposes you to cross-protocol attacks.
> 
> To clarify: even if the services are at the same security level, the
> case in which a MITM diverts the connection to a service other than the
> one the client wanted should be caught at the TLS level.
> 
> TLS is designed to be capable of providing a strong guarantee: if your
> connection goes through, you are talking to the service you wanted.
> Let's not weaken this by being sloppy with the naming.

You're confusing two things here:

Per section 1. Introduction, last sentence of all existing TLS specs,
the TLS protocol is completely agnositc about naming, and technically,
completely agnostic about PKIX, X.509 certs and certificate paths.

Many implementations of TLS go far beyond the TLS protocol spec and
provide complimentary code to applications that performs server
endpoint identification as described in rfc-2818 and performs
PKIX cert path validation per default, offering application
callers possibilities to obtain details and override negative
results from PKIX processing.

If there is a possibility for cross-protocol attacks, then this
is not a result of a failure within TLS, but a failure of the
apps in correctly identifying and distinguishing TLS server endpoints.

In the traditional approach of server endpoint identification
described in rfc-2818, endpoints are distinguished and identified
at the granularity of "hostname".  TLSA records of the form

   _443._tcp.www.example.com   TLSA   (server-cert|server-cert-hash)

would allow to distinguish server endpoints at the granularity
(port+protocol+hostname).  With this scheme it is possible
to prevent "cross-protocol attacks" by assigning distinct
credentials to distinct protocols.  (There is no protection
if the services share a single credential, though).

The big advantage of doing this in DNS rather than within the
server/service certificate is that it is easier on the
admin side--you don't have to rekey the service when you want
to run it on a different port.  TCP ports are a very limited
resource that is assigned on a first-come-first-served basis,
and it is not uncommon to have multiple distinct instances
of a particular service/protocol listening on distinct ports
of a single host(name).

-Martin

Date: Fri, 4 Feb 2011 08:12:59 -0500
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

On Thu, Feb 03, 2011 at 11:15:34PM -0500, Matt McCutchen wrote:
> 
> Not any more than the DNSKEY RRset does.  Either RRset will be cached by
> the ISP as soon as one client cares about it.

I think you mean the DS, since the DNSKEY isn't at the parent.  But
that's not the only case anyway.  As I understand it, the idea here is
that you're going to crawl up and look to see whether the parent
includes a record "covering" the policy in the child.  TLDs won't have
such a record, which will mean that they'll get a lot of queries for
things they don't have.  Negative caches don't last long.

This is why I claim that the only sensible way to look for the zone
cut, if that's what we're going to do, is to use the DS record itself,
because you're guaranteed to need it or a configured trust anchor for
this scheme to work.

A

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

From: Matt McCutchen <[email-masked]>
To: [email-masked]
Date: Fri, 04 Feb 2011 01:00:47 -0500
Subject: Re: [keyassure] Call for consensus on #1

On Wed, 2011-02-02 at 15:30 -0500, James Cloos wrote:
> Or it would need to specify the zone's own root CA (by IRI and hash)
> which can then specify how much trust whatever it signs should have.
> The only restriction we should specify in that case is that our RR only
> implies that said CA can be trusted for names which are the same

"zone"?

> as the
> one where the CA pointer was found.  (For this purpose, a name such as
> foo.bar.example.net. should be considered (in) a sub-zone of
> example.net. only iff there is a DS RR in the trust path.  In other
> words, the '.'s don't make the boundries, only DS RRs do.  We should
> point that out explictly, no matter what else we do.)

You are right, an organization with an existing internal CA will
typically want to designate it for the entire zone, just like I want to
assert DANE exclusivity for my entire zone.  (Though they should also be
able to designate it just for the example.com host if they want.)  We
can use the same design for both kinds of zone-wide assertion.

> I just thought of another possbile wording.  We could just say that our
> lookup should be for whatever the (DNS) client is already going to look
> up.  If it is about to do an AorAAAA lookup on 'example.com.', then it
> should also do a DANE lookup on 'example.com.'.  And if it is about to
> do a SRV lookup on '_sip._tcp.example.org.' then its DANE lookup should
> also be on '_sip._tcp.example.org.'. 

I prefer the design in which the DANE lookup is always on the host/port
the client will connect to and any SRV discovery is done first.  This
way, there is only one kind of DANE lookup, stunnel can do it, and if
you do load balancing with SRV, you can designate a different key for
each target server rather than pile them all at the source name.  The
one thing to watch out for is that the SRV becomes security-critical,
but I'd find it hard to argue that the current practice of issuing a
cert with the source name to the target machine is any more secure.

-- 
Matt

From: Matt McCutchen <[email-masked]>
To: =?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?= <[email-masked]>
Date: Fri, 04 Feb 2011 00:24:26 -0500
Cc: [email-masked]
Subject: Re: [keyassure] Call for consensus on #1

On Wed, 2011-02-02 at 09:58 +0100, Ond=C5=99ej Sur=C3=BD wrote:
> On 1.2.2011 16:48, Matt McCutchen wrote:
> > I don't feel strongly about the syntax, but I like the consistency of
> > _443._tcp.example.com with SRV.
>=20
> So you agree with the proposal to use prefix labels?

Yes.  (I didn't realize you meant to solicit consensus, not just declare
it.  Maybe that helps explain my previous message.)

--=20
Matt

Sender: [email-masked]
Date: Thu, 3 Feb 2011 21:21:51 -0800
From: Zack Weinberg <[email-masked]>
To: Matt McCutchen <[email-masked]>
Cc: keyassure <[email-masked]>
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

On Thu, Feb 3, 2011 at 8:38 PM, Matt McCutchen <[email-masked]> wro=
te:
>>
>> to indicate that 'www.example.com' provides HTTPS service with a
>> particular key, but does not provide any other secured service.
>
> So a single TLSA RR with this sentinel value represents an exclusive
> empty set? =C2=A0Sounds good to me.

Yah.

> If we support nonexclusive TLSA for individual services, we'll probably
> want to refactor this to have RRs that just make positive endorsements
> of certificates and a special RR that indicates exclusivity. =C2=A0Then, =
no
> TLSA RRs at all would mean no endorsements and no exclusivity.

I'd rather keep that argument out of this thread, but at present I
don't see a use case for nonexclusive.

zw

From: Matt McCutchen <[email-masked]>
To: [email-masked]
Date: Fri, 04 Feb 2011 00:09:18 -0500
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

On Tue, 2011-02-01 at 23:42 +0100, Martin Rex wrote:
> Zack Weinberg wrote:
> > 
> > > If there is a DANE record, then any wise client should interpret that
> > > as an exclusive list of allowed TLS certificates
> > 
> > I agree with this, but the question is how do you present an empty list.
> 
> What exactly would you want to convey with an empty list?
> 
>  "I won't respond to TLS, so don't even bother trying"

More precisely, "there is no TLS service associated with this DNS
name/transport/port".  Therefore, general-purpose clients that refer to
TLS services by DNS name/transport/port will not be able to make a
connection.  This does not preclude the admin to run a TLS server for
some special purpose, to accept connections only from specially
configured clients, but in most cases it will make sense to use DANE.

> The only time when such an information becomes interesting is when
> you have a client with a strong desire to communicate with a target
> and intent/preference for using TLS-protection on that communication.
> 
> DANE-unaware clients will continue trying to use TLS.
> What is your rationale for making DANE-aware clients exhibit
> a different behaviour and entirely stop trying to use TLS?

I assert that I do not offer the TLS service, so there is no point in
DANE clients trying to connect to it.  In particular, I do not want them
to connect to some fake service with a certificate from a public CA.
There is nothing I can do about the DANE-unaware clients.

-- 
Matt

From: Matt McCutchen <[email-masked]>
To: keyassure <[email-masked]>
Date: Thu, 03 Feb 2011 23:38:07 -0500
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

On Tue, 2011-02-01 at 08:21 -0800, Zack Weinberg wrote:
> It occurs to me that there is currently no such thing as a DANE record
> that expresses "there are no TLS-secured services provided by this
> domain name" (or "...by this port").  Maybe there should be one?  I
> suggest that the record with hash type 0, cert type 0, and zero bytes
> of certificate data could have this meaning.  Under the _nnn._tcp.host
> proposal being discussed in the other thread, you could then have
> 
> $ORIGIN example.com.
> 
> www                 A  w.x.y.z
> _443._tcp.www  TLSA ( 1 2 ...hash... )
> *.www               TLSA ( 0 0 )
> 
> to indicate that 'www.example.com' provides HTTPS service with a
> particular key, but does not provide any other secured service.

So a single TLSA RR with this sentinel value represents an exclusive
empty set?  Sounds good to me.

If we support nonexclusive TLSA for individual services, we'll probably
want to refactor this to have RRs that just make positive endorsements
of certificates and a special RR that indicates exclusivity.  Then, no
TLSA RRs at all would mean no endorsements and no exclusivity.

-- 
Matt

From: Matt McCutchen <[email-masked]>
To: keyassure <[email-masked]>
Date: Thu, 03 Feb 2011 23:23:59 -0500
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

On Wed, 2011-02-02 at 08:31 +0100, Jakob Schlyter wrote: 
> On 1 feb 2011, at 16.49, Matt McCutchen wrote:
> 
> > I would like to assert DANE exclusivity for the entire domain
> > mattmccutchen.net so that, with respect to clients that check DANE first
> > and fall back to a mainstream public CA list, a shady CA cannot
> > impersonate my existing TLS services /or/ fabricate TLS services I do
> > not offer.
> 
> This sounds like the opposite of STS (Strict Transport Security),

I don't follow.

> i.e. policy and not key association distribution.

Gah...

Asserting TLSA exclusivity for an entire domain is not fundamentally
different from asserting it for a single _port._transport.host, just
grander in scale.  It's equivalent to a thicket of wildcard exclusive
TLSA records with empty certificate sets.

Ultimately, any of these directives can be viewed as an assertion or a
suggested policy.  Of course clients can do as they wish; the idea is
that the admin disclaims responsibility for anything bad that might
happen to the client as a result of it not following the policy.

-- 
Matt

From: Matt McCutchen <[email-masked]>
To: keyassure <[email-masked]>
Date: Thu, 03 Feb 2011 23:15:34 -0500
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

On Thu, 2011-02-03 at 12:02 -0500, Andrew Sullivan wrote:
> there's also the fact
> that it imposes load on a parent who ought not to need to participate
> in most of this.

Not any more than the DNSKEY RRset does.  Either RRset will be cached by
the ISP as soon as one client cares about it.

-- 
Matt

From: Matt McCutchen <[email-masked]>
To: James Cloos <[email-masked]>
Date: Thu, 03 Feb 2011 23:11:14 -0500
Cc: keyassure <[email-masked]>
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

On Wed, 2011-02-02 at 15:56 -0500, James Cloos wrote:
> >>>>> "MM" == Matt McCutchen <[email-masked]> writes:
> 
> MM> I would just propose that the client check for CNAME at www.example.com
> MM> or TLSA at _443._tcp.www.example.com in unspecified order (they should
> MM> not both exist), and if a CNAME at www.example.com is found, query
> MM> the prefixed version of the target name.  The client would not honor
> MM> a CNAME at _443._tcp.www.example.com.  DNS admins who want to apply
> MM> TLSA to a wildcard set of host names can use a wildcard CNAME first
> MM> and then put the TLSA at the target name.
> 
> Those are not awful.  They probably make prefixes usable.
> 
> (And perhaps should be used for existing SRV usages, too.)

That's what I was hoping to achieve.  I appreciate the vote of
confidence.  :)

-- 
Matt

From: Matt McCutchen <[email-masked]>
To: Paul Wouters <[email-masked]>
Date: Thu, 03 Feb 2011 20:30:30 -0500
Cc: keyassure <[email-masked]>
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

On Thu, 2011-02-03 at 20:16 -0500, Matt McCutchen wrote:
> using the same certificate for multiple services at the
> same name exposes you to cross-protocol attacks.

To clarify: even if the services are at the same security level, the
case in which a MITM diverts the connection to a service other than the
one the client wanted should be caught at the TLS level.

TLS is designed to be capable of providing a strong guarantee: if your
connection goes through, you are talking to the service you wanted.
Let's not weaken this by being sloppy with the naming.

-- 
Matt

From: Matt McCutchen <[email-masked]>
To: Paul Wouters <[email-masked]>
Date: Thu, 03 Feb 2011 20:16:22 -0500
Cc: keyassure <[email-masked]>
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

On Tue, 2011-02-01 at 13:54 -0500, Paul Wouters wrote:
> On Tue, 1 Feb 2011, Matt McCutchen wrote:
> 
> > I am unhappy with 1a.  I wouldn't like to build the assumption that
> > ports at the same host name are at the same security level into DANE,
> 
> insecure.example.com. IN A 1.2.3.4
> secure.example.com. IN A 1.2.3.4
> insecure.example.com. IN TLSA x snakeoilcert
> secure.example.com. IN TLSA x securecert
> 
> Now you have different security levels to the same host on 1.2.3.4,
> without the added parsing/complexity/uglyness of _modifiers.

- There is no parsing, only construction.  The client gets a TLSA record
back by virtue of constructing the _port._transport.host string the same
way the DNS admin did when publishing the data.

- I do not see what is complex or ugly about stating the transport
protocol and port number your service listens on.  This way, TLSA layers
neatly onto our transport protocols to provide the abstraction of an
authenticated (D)TLS connection over Foo Transport Protocol to an
arbitrary (DNS name, port) pair; generic TLS tools such as stunnel can
take advantage of this.  In contrast, using subdomain names that are not
standardized anywhere and thus liable to be chosen differently for the
same service type (smtp.foo.com, mail.bar.com, ...) has the potential to
be ugly, and using the same certificate for multiple services at the
same name exposes you to cross-protocol attacks.

If the admin does not want to type out the _port._transport.host format,
surely there will be GUIs like the ones for port forwarding on home
routers today that let him pick the transport protocol and service type
(assuming the default port) from a menu.  But I really don't think this
is an imposition.

-- 
Matt

Date: Thu, 3 Feb 2011 13:20:59 -0500
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

On Thu, Feb 03, 2011 at 01:08:00PM -0500, Phillip Hallam-Baker wrote:
> There is a very strong probability that where there is a separation of
> control, there will be a zone cut and a DS record.

Well, yes and no.  University environments are a good example here:
some just do not delegate zones, period; but they do not assert tight
administrative control over departments.  The effect is that you have
separation of control of hosts within department boundaries without
zone cuts.  That seems to me to be an important use case.

The same can be true in some corporate environments, where zone cuts
do not correspond very well with administrative control differences.

I know some will regard these as artificial examples, but having
worked under each I contend that they're real and ought to be
considered.

> The problem comes the other way, the fact that a DS record is encountered is
> a much less reliable indicator of a separation of control.

Also yes and no.  In some ways, it's _necessarily_ a separation of
control: the two sides of a zone cut are as a matter of protocol just
independent.  The protocol relies on the operators to make them agree.
And anyway, a system that uses zone cuts as an indicator of control
boundaries need not be a problem: the single operator of both sides
already knows how to co-ordinate changes across the cut, so I don't
see what the problem there could be.  I think this is a red herring.

> If something is going to be an administrative convenience rather than an
> inconvenience, it has to work almost very close to 100% of the time and in
> particular it must not introduce side effects to existing administration
> procedures.

I fully disagree with the latter claim.  _By definition_ a new feature
might introduce side effects to existing administration procedures.
This is a matter of trade-off, and not one of necessity universally
quantified.

A

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

Date: Thu, 3 Feb 2011 13:08:28 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Nicholas Weaver <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

On Thu, 3 Feb 2011, Nicholas Weaver wrote:

>> I browser should just be able to lookup a TLSA record from the validating
>> localhost dns server, without any further knowledge of dnssec or DS records.
>
> I disagree, strongly.
>
> a)  What APIs currently exist that would allow a TLSA record to be looked up rather than an A record.  So new APIs are probably required anyway.
>
> b)  It is the APPLICATION, not the resolver, that needs to know what to do if the DNSSEC portion of the TLSA record fails.
>
> Doing meaningful DNSSEC-using applications without getting the reason FOR a DNSSEC failure is asking for trouble.

That should only be needed for error handling, not for regular succeeding lookups that
return either the TLSA record or an NSEC*.

Yes, the application will have to deal with various kind of ServFails, but in its regular
operation it should just do a lookup, either get a TLSA record or not, and move on. This
case surely should not depend on the application knowing about zone cuts or DS records.

Paul

Date: Thu, 3 Feb 2011 13:08:00 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Andrew Sullivan <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

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

There is a very strong probability that where there is a separation of
control, there will be a zone cut and a DS record.

The problem comes the other way, the fact that a DS record is encountered is
a much less reliable indicator of a separation of control.

If something is going to be an administrative convenience rather than an
inconvenience, it has to work almost very close to 100% of the time and in
particular it must not introduce side effects to existing administration
procedures.

On Thu, Feb 3, 2011 at 12:56 PM, Andrew Sullivan <[email-masked]> wrote:

> On Thu, Feb 03, 2011 at 12:11:55PM -0500, Phillip Hallam-Baker wrote:
> > One of the discoveries we made in DKIM was that ephemera such as zone
> cuts
> > that are visible at the resolver level cannot be relied on to be visible
> at
> > the client level.
>
> My memory of that discussion was rather that the DNS geeks kept saying
> that zone cuts were a lousy thing to rely on, and you shouldn't do it.
> But let's not fight that battle over again.
>
> > WG consensus that the group would rather prefer performance or certain
> forms
> > of administrative convenience than meeting these requirements is unlikely
> to
> > reflect IETF consensus.
>
> Agreed.  But we actually _do_ have a reliable mechanism to detect zone
> cuts here, because we _have to_ have one, because without DNSSEC this
> entire scheme is a waste of time.  The DS record establishes it.  I am
> not arguing that the zone cut is going to be visible to general
> purpose clients, but surely a client that is doing the kind of work
> we're talking about can be expected to be more sophisticated than
> getaddrinfo().
>
> > Crawling the root has been long established as a bad idea.
>
> Fully agree.
>
> A
>
> --
> Andrew Sullivan
> [email-masked]
> Shinkuro, Inc.
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

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

There is a very strong probability that where there is a separation of cont=
rol, there will be a zone cut and a DS record.<div><br></div><div>The probl=
em comes the other way, the fact that a DS record is encountered is a much =
less reliable indicator of a separation of control.<br>
<br></div><div><br></div><div>If something is going to be an administrative=
 convenience rather than an inconvenience, it has to work almost very close=
 to 100% of the time and in particular it must not introduce side effects t=
o existing administration procedures.</div>
<div><br></div><div><br><div class=3D"gmail_quote">On Thu, Feb 3, 2011 at 1=
2:56 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 Thu, Feb 03, 2011 at 12:11:55PM -0500, Phillip Hallam-=
Baker wrote:<br>
&gt; One of the discoveries we made in DKIM was that ephemera such as zone =
cuts<br>
&gt; that are visible at the resolver level cannot be relied on to be visib=
le at<br>
&gt; the client level.<br>
<br>
</div>My memory of that discussion was rather that the DNS geeks kept sayin=
g<br>
that zone cuts were a lousy thing to rely on, and you shouldn&#39;t do it.<=
br>
But let&#39;s not fight that battle over again.<br>
<div class=3D"im"><br>
&gt; WG consensus that the group would rather prefer performance or certain=
 forms<br>
&gt; of administrative convenience than meeting these requirements is unlik=
ely to<br>
&gt; reflect IETF consensus.<br>
<br>
</div>Agreed. =A0But we actually _do_ have a reliable mechanism to detect z=
one<br>
cuts here, because we _have to_ have one, because without DNSSEC this<br>
entire scheme is a waste of time. =A0The DS record establishes it. =A0I am<=
br>
not arguing that the zone cut is going to be visible to general<br>
purpose clients, but surely a client that is doing the kind of work<br>
we&#39;re talking about can be expected to be more sophisticated than<br>
getaddrinfo().<br>
<div class=3D"im"><br>
&gt; Crawling the root has been long established as a bad idea.<br>
<br>
</div>Fully agree.<br>
<br>
A<br>
<font color=3D"#888888"><br>
--<br>
</font><div class=3D"im">Andrew Sullivan<br>
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
</div><div><div></div><div class=3D"h5">Shinkuro, Inc.<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>
</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>

--0016e644c630627150049b64a51f--

Date: Thu, 3 Feb 2011 13:05:33 -0500
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

On Thu, Feb 03, 2011 at 01:04:43PM -0500, Andrew Sullivan wrote:
> The "zone cut" is not the criterion you want, and I assert that it is

s/The/Then/.  Sorry.

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

Date: Thu, 3 Feb 2011 13:04:43 -0500
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

On Thu, Feb 03, 2011 at 12:34:42PM -0500, Paul Wouters wrote:
> I browser should just be able to lookup a TLSA record from the validating
> localhost dns server, without any further knowledge of dnssec or DS records.

The "zone cut" is not the criterion you want, and I assert that it is
not possible to do anything interesting with the notion of zones for
security.  We've seen this over and over again.  Either the zone cut
is important, and you are willing to do the work to detect it
reliably, or else inheritance in the DNS itself is not allowed for
these security policies.

I have repeatedly in the past suggested a sort of meta-info service
about the DNS, where zones have the (signed) ability to return a
location for policy informaiton.  For instance, in this case, one
would have SRV-or-whatever pointers off to the policy for a zone that
says, "I assert policy for the following zones".  The policy document
is actually delivered via https or something like that.  If and only
if the asserted-for zone contains a (validatable) pointer to the same
policy, then a client can accept that policy.  This gets us out of the
mess resulting from trying to infer anything from zone cuts.  (The
reason this is so general purpose is because it can have other uses
too.  Think of solving the cookies-in-a-domain problem and the
IDNA2008 language-tables policy problems using the same mechanism, for
starters.)

Unfortunately, every time I have floated this idea, I have been told
by application people that they won't use it because they don't have
an interface, or because it's too many lookups and will take too long.
This out of hand rejection has caused me never to bother to write the
needed I-D.  On the other hand, it has the conspicuous advantage that
it would work where detecting zone cuts won't, which is why I continue
to nurture it.  If anyone thinks this is not-obviously-stupid now, I
will write it up properly.

A

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

Date: Thu, 3 Feb 2011 13:00:56 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Nicholas Weaver <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

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

On Thu, Feb 3, 2011 at 12:39 PM, Nicholas Weaver
<[email-masked]>wrote:

>
> On Feb 3, 2011, at 9:34 AM, Paul Wouters wrote:
>
> > On Thu, 3 Feb 2011, Andrew Sullivan wrote:
> >
> >> On Wed, Feb 02, 2011 at 06:18:36PM -0500, Matt McCutchen wrote:
> >>> Right... but do DNSSEC client libraries make it easy to access this
> >>> information without doing a separate query for the DS record?
> >>
> >> Client libraries are going to have to learn this if they're going to
> >> do meaningful DNSSEC work.
> >
> > I browser should just be able to lookup a TLSA record from the validating
> > localhost dns server, without any further knowledge of dnssec or DS
> records.
>
> I disagree, strongly.
>
> a)  What APIs currently exist that would allow a TLSA record to be looked
> up rather than an A record.  So new APIs are probably required anyway.
>
> b)  It is the APPLICATION, not the resolver, that needs to know what to do
> if the DNSSEC portion of the TLSA record fails.
>
> Doing meaningful DNSSEC-using applications without getting the reason FOR a
> DNSSEC failure is asking for trouble.

I think it is necessary to phrase the question in a different way. Instead
of assuming that the existing API support is automatically going to improve
to support DANE and like proposals, consider instead what applications are
going to have to do to circumvent local DNS mechanisms and in what
circumstances they should be able to do so.

There are two cases of interest to me:

1) An enterprise user using a home machine

2) A home user attempting to gain unrestricted access to the world media
regardless of government imposed censorship.

In the first case the machine is owned by the enterprise and the enterprise
has the right to decide that it does not want it to be connecting to random
Internet sites that may be attempting to install malware or negatively
impact productivity. Many enterprises do just that by deploying operating
systems that allow them to impose configuration restrictions on
applications.

While certain regimes have attempted this approach to enforce political
censorship, it is rather harder to impose. For example, the Iranian
government operates what is essentially a warez site from which citizens can
download software of their choice - together with government installed
backdoors.

In practice, it is rather hard to impose that degree of control on a machine
that the consumer has acquired independently. Certainly the user is going to
be very aware that the controls are being imposed.

My view is that if we want to get clean access to the Internet DNS,
applications are going to have to be prepared to use libraries that are
designed to route around port 53 restrictions if that is what it takes.

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

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

<br><br><div class=3D"gmail_quote">On Thu, Feb 3, 2011 at 12:39 PM, Nichola=
s Weaver <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]"=
>[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex;">
<div class=3D"im"><br>
On Feb 3, 2011, at 9:34 AM, Paul Wouters wrote:<br>
<br>
&gt; On Thu, 3 Feb 2011, Andrew Sullivan wrote:<br>
&gt;<br>
&gt;&gt; On Wed, Feb 02, 2011 at 06:18:36PM -0500, Matt McCutchen wrote:<br=
>
&gt;&gt;&gt; Right... but do DNSSEC client libraries make it easy to access=
 this<br>
&gt;&gt;&gt; information without doing a separate query for the DS record?<=
br>
&gt;&gt;<br>
&gt;&gt; Client libraries are going to have to learn this if they&#39;re go=
ing to<br>
&gt;&gt; do meaningful DNSSEC work.<br>
&gt;<br>
&gt; I browser should just be able to lookup a TLSA record from the validat=
ing<br>
&gt; localhost dns server, without any further knowledge of dnssec or DS re=
cords.<br>
<br>
</div>I disagree, strongly.<br>
<br>
a) =A0What APIs currently exist that would allow a TLSA record to be looked=
 up rather than an A record. =A0So new APIs are probably required anyway.<b=
r>
<br>
b) =A0It is the APPLICATION, not the resolver, that needs to know what to d=
o if the DNSSEC portion of the TLSA record fails.<br>
<br>
Doing meaningful DNSSEC-using applications without getting the reason FOR a=
 DNSSEC failure is asking for trouble.</blockquote><div><br></div><div>I th=
ink it is necessary to phrase the question in a different way. Instead of a=
ssuming that the existing API support is automatically going to improve to =
support DANE and like proposals, consider instead what applications are goi=
ng to have to do to circumvent local DNS mechanisms and in what circumstanc=
es they should be able to do so.</div>
<div><br></div><div>There are two cases of interest to me:</div><div><br></=
div><div>1) An enterprise user using a home machine</div><div><br></div><di=
v>2) A home user attempting to gain unrestricted access to the world media =
regardless of government imposed censorship.</div>
<div><br></div><div><br></div><div>In the first case the machine is owned b=
y the enterprise and the enterprise has the right to decide that it does no=
t want it to be connecting to random Internet sites that may be attempting =
to install malware or negatively impact productivity. Many enterprises do j=
ust that by deploying operating systems that allow them to impose configura=
tion restrictions on applications.</div>
<div><br></div><div>While certain regimes have attempted this approach to e=
nforce political censorship, it is rather harder to impose. For example, th=
e Iranian government operates what is essentially a warez site from which c=
itizens can download software of their choice - together with government in=
stalled backdoors.</div>
<div><br></div><div>In practice, it is rather hard to impose that degree of=
 control on a machine that the consumer has acquired independently. Certain=
ly the user is going to be very aware that the controls are being imposed.<=
/div>
<div><br></div><div>=A0</div><div>My view is that if we want to get clean a=
ccess to the Internet DNS, applications are going to have to be prepared to=
 use libraries that are designed to route around port 53 restrictions if th=
at is what it takes.</div>
<div><br></div><div><br></div><div><br></div></div><br>-- <br>Website: <a h=
ref=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>

--0016e644c70821bdd2049b648c0c--

Date: Thu, 3 Feb 2011 12:56:55 -0500
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

On Thu, Feb 03, 2011 at 12:11:55PM -0500, Phillip Hallam-Baker wrote:
> One of the discoveries we made in DKIM was that ephemera such as zone cuts
> that are visible at the resolver level cannot be relied on to be visible at
> the client level.

My memory of that discussion was rather that the DNS geeks kept saying
that zone cuts were a lousy thing to rely on, and you shouldn't do it.
But let's not fight that battle over again.

> WG consensus that the group would rather prefer performance or certain forms
> of administrative convenience than meeting these requirements is unlikely to
> reflect IETF consensus.

Agreed.  But we actually _do_ have a reliable mechanism to detect zone
cuts here, because we _have to_ have one, because without DNSSEC this
entire scheme is a waste of time.  The DS record establishes it.  I am
not arguing that the zone cut is going to be visible to general
purpose clients, but surely a client that is doing the kind of work
we're talking about can be expected to be more sophisticated than
getaddrinfo().

> Crawling the root has been long established as a bad idea.

Fully agree.

A

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

From: Nicholas Weaver <[email-masked]>
Date: Thu, 3 Feb 2011 09:39:20 -0800
To: Paul Wouters <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

On Feb 3, 2011, at 9:34 AM, Paul Wouters wrote:

> On Thu, 3 Feb 2011, Andrew Sullivan wrote:
>=20
>> On Wed, Feb 02, 2011 at 06:18:36PM -0500, Matt McCutchen wrote:
>>> Right... but do DNSSEC client libraries make it easy to access this
>>> information without doing a separate query for the DS record?
>>=20
>> Client libraries are going to have to learn this if they're going to
>> do meaningful DNSSEC work.
>=20
> I browser should just be able to lookup a TLSA record from the =
validating
> localhost dns server, without any further knowledge of dnssec or DS =
records.

I disagree, strongly.

a)  What APIs currently exist that would allow a TLSA record to be =
looked up rather than an A record.  So new APIs are probably required =
anyway.

b)  It is the APPLICATION, not the resolver, that needs to know what to =
do if the DNSSEC portion of the TLSA record fails.

Doing meaningful DNSSEC-using applications without getting the reason =
FOR a DNSSEC failure is asking for trouble.

Date: Thu, 3 Feb 2011 12:34:42 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Andrew Sullivan <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

On Thu, 3 Feb 2011, Andrew Sullivan wrote:

> On Wed, Feb 02, 2011 at 06:18:36PM -0500, Matt McCutchen wrote:
>> Right... but do DNSSEC client libraries make it easy to access this
>> information without doing a separate query for the DS record?
>
> Client libraries are going to have to learn this if they're going to
> do meaningful DNSSEC work.

I browser should just be able to lookup a TLSA record from the validating
localhost dns server, without any further knowledge of dnssec or DS records.

Paul

Date: Thu, 3 Feb 2011 12:11:55 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Andrew Sullivan <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

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

On Thu, Feb 3, 2011 at 12:02 PM, Andrew Sullivan <[email-masked]> wrote:

> On Wed, Feb 02, 2011 at 09:36:31AM +0100, Ond=C5=99ej Sur=C3=BD wrote:
>
> > The crawling up to the root is a call for serious problems.
>
> Apart from all the good reasons Ond=C5=99ej mentions, there's also the fa=
ct
> that it imposes load on a parent who ought not to need to participate
> in most of this.
>

One of the discoveries we made in DKIM was that ephemera such as zone cuts
that are visible at the resolver level cannot be relied on to be visible at
the client level.

As a general architectural principle, there has to be orthogonality in the
design of a key distribution mechanism. In particular

* Deployment in a sub zone must not affect the parent

* Deployment in a parent must not affect a sub zone unless this is
explicitly desired.

* Deployment for protocol X must not cause applications to reject valid key=
s
for protocol Y unless this is explicitly desired.

* Deployment for protocol X must not create a key that applications will
accept for protocol Y unless this is explicitly desired.

These are exactly the type of architectural principles that people look
towards the IESG and IAB to enforce.

WG consensus that the group would rather prefer performance or certain form=
s
of administrative convenience than meeting these requirements is unlikely t=
o
reflect IETF consensus.

Crawling the root has been long established as a bad idea.

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

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

<br><br><div class=3D"gmail_quote">On Thu, Feb 3, 2011 at 12:02 PM, Andrew =
Sullivan <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">ajs@shin=
kuro.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 Wed, Feb 02, 2011 at 09:36:31AM +0100, Ond=C5=99ej Sur=
=C3=BD wrote:<br>
<br>
&gt; The crawling up to the root is a call for serious problems.<br>
<br>
</div>Apart from all the good reasons Ond=C5=99ej mentions, there&#39;s als=
o the fact<br>
that it imposes load on a parent who ought not to need to participate<br>
in most of this.<br></blockquote><div><br></div><div>One of the discoveries=
 we made in DKIM was that ephemera such as zone cuts that are visible at th=
e resolver level cannot be relied on to be visible at the client level.</di=
v>
<div><br></div><div><br></div><div>As a general architectural principle, th=
ere has to be orthogonality in the design of a key distribution mechanism. =
In particular</div><div><br></div><div>* Deployment in a sub zone must not =
affect the parent</div>
<div><br></div><div>* Deployment in a parent must not affect a sub zone unl=
ess this is explicitly desired.</div><div><br></div><div>* Deployment for p=
rotocol X must not cause applications to reject valid keys for protocol Y u=
nless this is explicitly desired.</div>
<div><br></div><div>* Deployment for protocol X must not create a key that =
applications will accept for protocol Y unless this is explicitly desired.<=
/div><div><br></div><div><br></div><div>These are exactly the type of archi=
tectural principles that people look towards the IESG and IAB to enforce.</=
div>
<div><br></div><div>WG consensus that the group would rather prefer perform=
ance or certain forms of administrative convenience than meeting these requ=
irements is unlikely to reflect IETF consensus.</div></div><div><br></div>
<div><br></div><div>Crawling the root has been long established as a bad id=
ea.</div><br>-- <br>Website: <a href=3D"http://hallambaker.com/">http://hal=
lambaker.com/</a><br><br>

--0016e644c708c959bf049b63dc00--

Date: Thu, 3 Feb 2011 12:04:37 -0500
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

On Wed, Feb 02, 2011 at 06:18:36PM -0500, Matt McCutchen wrote:
> Right... but do DNSSEC client libraries make it easy to access this
> information without doing a separate query for the DS record?

Client libraries are going to have to learn this if they're going to
do meaningful DNSSEC work.  I understand and sympathize with the
desire to make the DNS a perfect black box, but if applications want
to do interesting things with DNS data, they're going to have to
become something less than agnostic about what that data is.

A

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

Date: Thu, 3 Feb 2011 12:02:45 -0500
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

On Wed, Feb 02, 2011 at 09:36:31AM +0100, Ondřej Surý wrote:

> The crawling up to the root is a call for serious problems.

Apart from all the good reasons Ondřej mentions, there's also the fact
that it imposes load on a parent who ought not to need to participate
in most of this.

A

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

From: James Cloos <[email-masked]>
To: Matt McCutchen <[email-masked]>
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABHNCSVQICAgIfAhkiAAAAI1J REFUOE+lU9ESgCAIg64P1y+ngUdxhl5H8wFbbM0OmUiEhKkCYaZThXCo6KE5sCbA1DDX3genvO4d eBQgEMaM5qy6uWk4SfBYfdu9jvBN9nSVDOKRtwb+I3epboOsOX5pZbJNsBJFvmQQ05YMfieIBnYX FK2N6dOawd97r/e8RjkTLzmMsiVgrAoEugtviCM3v2WzjgAAAABJRU5ErkJggg==
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, 03 Feb 2011 11:45:05 -0500
Lines: 18
Cc: keyassure <[email-masked]>
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

>>>>> "MM" == Matt McCutchen <[email-masked]> writes:

>> Since we rely on DNSSEC anyway, DS records are the ideal way to
>> determine zone cut points.  They are grabbed anyway as a matter
>> of course and provide all the clue required.

MM> Right... but do DNSSEC client libraries make it easy to access this
MM> information without doing a separate query for the DS record?

Even if they do not, the resolver had to grab the DS as part of the
validation, so the round trip for an extra DS lookup by the end client
is by definition local, often even same-process.

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

Date: Thu, 3 Feb 2011 16:10:00 +0100
From: Antoin Verschuren <[email-masked]>
To: <[email-masked]>
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

On 03-02-11 15:28, Paul Hoffman wrote:

> Just to be clear: are you proposing that TLSA records can *only* be
> returned in SRV requests, and that they can't be requested on their own
> using "_port._protocol.host.tld TLSA"?

I was only comparing the "_port._protocol.host.tld" vs the "hostname per
service offered" as solution for the question Ondřej originally asked
about which QNAME to use.

Which RRTYPE to use is the next question Ondřej is going to pose I believe:

"I was planning to open separate issue# on what to include into DNS name
after we get consensus on that we want to have solution based on
prefix+hostname in QNAME. As opposed to just having hostname in QNAME,
or some interaction with SRV record. I felt that if we slowly narrow the
topic it will not divert that much in the mailing list."

- -- 
Antoin Verschuren

Technical Policy Advisor SIDN
Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  F: +31 26 3525505  M: +31 6 23368970
mailto:[email-masked]  xmpp:[email-masked]
http://www.sidn.nl/

Date: Thu, 03 Feb 2011 06:28:51 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

On 2/3/11 4:51 AM, Antoin Verschuren wrote:
> Thinking over it, and hearing the answers, I think I'd vote for the
>
> _port._protocol.host.tld SRV
>
> solution.
> My rationale:
> Everything can be configured both for single hostnames and multiple
> ones, but it takes less records in a zone for this sulution compared to
> the TLSA solution.
>
> "good looks", "ugliness" or "readability" are no criteria for me.
> Smaller size of the zone is.
>
> For the SRV solution, I only need 1 A and 2 SRV records makes 3.
> For the TLSA sollution, I need 2 A and 2 TLSA records makes 4.

Just to be clear: are you proposing that TLSA records can *only* be 
returned in SRV requests, and that they can't be requested on their own 
using "_port._protocol.host.tld TLSA"?

Date: Thu, 3 Feb 2011 13:51:47 +0100
From: Antoin Verschuren <[email-masked]>
To: <[email-masked]>
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

On 01-02-11 19:54, Paul Wouters wrote:
> On Tue, 1 Feb 2011, Matt McCutchen wrote:
> 
>> I am unhappy with 1a.  I wouldn't like to build the assumption that
>> ports at the same host name are at the same security level into DANE,
> 
> insecure.example.com. IN A 1.2.3.4
> secure.example.com. IN A 1.2.3.4
> insecure.example.com. IN TLSA x snakeoilcert
> secure.example.com. IN TLSA x securecert
> 
> Now you have different security levels to the same host on 1.2.3.4,
> without the added parsing/complexity/uglyness of _modifiers.

Hmm, and what's the canonical hostname for 1.2.3.4 in this case ?
Thinking over it, and hearing the answers, I think I'd vote for the

_port._protocol.host.tld SRV

solution.
My rationale:
Everything can be configured both for single hostnames and multiple
ones, but it takes less records in a zone for this sulution compared to
the TLSA solution.

"good looks", "ugliness" or "readability" are no criteria for me.
Smaller size of the zone is.

For the SRV solution, I only need 1 A and 2 SRV records makes 3.
For the TLSA sollution, I need 2 A and 2 TLSA records makes 4.

- -- 
Antoin Verschuren

Technical Policy Advisor SIDN
Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  F: +31 26 3525505  M: +31 6 23368970
mailto:[email-masked]  xmpp:[email-masked]
http://www.sidn.nl/

From: Matt McCutchen <[email-masked]>
To: keyassure <[email-masked]>
Date: Wed, 02 Feb 2011 18:28:09 -0500
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

On Tue, 2011-02-01 at 11:10 -0500, Phillip Hallam-Baker wrote:
> Let us assume that you are signing your domain with DNSSEC.
> 
> It follows that clients will be able to determine with certainty that
> a specific subdomain does not exist. 
> 
> Thus it will be impossible for a client to obtain a valid A record or
> SRV record or any other record that would enable a connection to be
> made.

Excellent point, but I can think of two cases in which this assumption
fails:

- Using an HTTP proxy
- In XMPP server-to-server communication, authenticating the client of
the connection

More broadly, people have developed the mindset and expectation that no
matter how they make a connection, authenticated TLS will cover their
backs.  So I think the assumption you propose is fragile; I don't wish
to make it.  It doesn't buy much in terms of reducing the number of
wildcard records needed, either.

-- 
Matt

From: Matt McCutchen <[email-masked]>
To: keyassure <[email-masked]>
Date: Wed, 02 Feb 2011 18:18:36 -0500
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

On Wed, 2011-02-02 at 15:58 -0500, James Cloos wrote:
> >>>>> "MM" == Matt McCutchen <[email-masked]> writes:
> 
> MM> If there is an easy way to stop at a zone cut (e.g., by detecting
> MM> the SOA record), that would be fine.
> 
> Since we rely on DNSSEC anyway, DS records are the ideal way to
> determine zone cut points.  They are grabbed anyway as a matter
> of course and provide all the clue required.

Right... but do DNSSEC client libraries make it easy to access this
information without doing a separate query for the DS record?

-- 
Matt

From: James Cloos <[email-masked]>
To: Matt McCutchen <[email-masked]>
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABHNCSVQICAgIfAhkiAAAAI1J REFUOE+lU9ESgCAIg64P1y+ngUdxhl5H8wFbbM0OmUiEhKkCYaZThXCo6KE5sCbA1DDX3genvO4d eBQgEMaM5qy6uWk4SfBYfdu9jvBN9nSVDOKRtwb+I3epboOsOX5pZbJNsBJFvmQQ05YMfieIBnYX FK2N6dOawd97r/e8RjkTLzmMsiVgrAoEugtviCM3v2WzjgAAAABJRU5ErkJggg==
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, 02 Feb 2011 15:58:24 -0500
Lines: 12
Cc: [email-masked]
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

>>>>> "MM" == Matt McCutchen <[email-masked]> writes:

MM> If there is an easy way to stop at a zone cut (e.g., by detecting
MM> the SOA record), that would be fine.

Since we rely on DNSSEC anyway, DS records are the ideal way to
determine zone cut points.  They are grabbed anyway as a matter
of course and provide all the clue required.

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

From: James Cloos <[email-masked]>
To: Matt McCutchen <[email-masked]>
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABHNCSVQICAgIfAhkiAAAAI1J REFUOE+lU9ESgCAIg64P1y+ngUdxhl5H8wFbbM0OmUiEhKkCYaZThXCo6KE5sCbA1DDX3genvO4d eBQgEMaM5qy6uWk4SfBYfdu9jvBN9nSVDOKRtwb+I3epboOsOX5pZbJNsBJFvmQQ05YMfieIBnYX FK2N6dOawd97r/e8RjkTLzmMsiVgrAoEugtviCM3v2WzjgAAAABJRU5ErkJggg==
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, 02 Feb 2011 15:56:29 -0500
Lines: 17
Cc: keyassure <[email-masked]>
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

>>>>> "MM" == Matt McCutchen <[email-masked]> writes:

MM> I would just propose that the client check for CNAME at www.example.com
MM> or TLSA at _443._tcp.www.example.com in unspecified order (they should
MM> not both exist), and if a CNAME at www.example.com is found, query
MM> the prefixed version of the target name.  The client would not honor
MM> a CNAME at _443._tcp.www.example.com.  DNS admins who want to apply
MM> TLSA to a wildcard set of host names can use a wildcard CNAME first
MM> and then put the TLSA at the target name.

Those are not awful.  They probably make prefixes usable.

(And perhaps should be used for existing SRV usages, too.)

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

From: James Cloos <[email-masked]>
To: =?utf-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABHNCSVQICAgIfAhkiAAAAI1J REFUOE+lU9ESgCAIg64P1y+ngUdxhl5H8wFbbM0OmUiEhKkCYaZThXCo6KE5sCbA1DDX3genvO4d eBQgEMaM5qy6uWk4SfBYfdu9jvBN9nSVDOKRtwb+I3epboOsOX5pZbJNsBJFvmQQ05YMfieIBnYX FK2N6dOawd97r/e8RjkTLzmMsiVgrAoEugtviCM3v2WzjgAAAABJRU5ErkJggg==
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, 02 Feb 2011 15:30:26 -0500
Lines: 59
Cc: [email-masked]
Subject: Re: [keyassure] Call for consensus on #1

>>>>> "OS" == Ondřej Surý <[email-masked]> writes:

OS> The consensus would be that the draft-dane-protocol would define
OS> lookup on TLSA records as query for a name prefixed with a port or
OS> port and proto.

I've read through this entire thread and remain undecided on your (narrow)
question.

As Phillip pointed out again, using prefixes precludes CNAME and
wildcard RRs.  That strongly suggests avoiding prefixes.

But differentialtion is also necessary.

What it comes down to is the need for a discovery mechanism.  My
suggesting to use NAPTR lookups returned only negative replies.
Unfortunate, since that is the optimal solution to all of the discovery
needs discussed on this list.

That leaves two options that I can see.  The DANE RR would need to
encode the details for all possible uses at that name.

A lookup for example.com. could return an RR which says:

  *  Use cert A for traffic on tcp/sctp port 80
  *  Use cert B for traffic on tcp port 443
  *  Use cert C for traffic on tcp port 25
  *  Use cert C for traffic on tcp port 143
  *  Use cert D for traffic on tcp/sctp/udp port 5060

Or it would need to specify the zone's own root CA (by IRI and hash)
which can then specify how much trust whatever it signs should have.
The only restriction we should specify in that case is that our RR only
implies that said CA can be trusted for names which are the same as the
one where the CA pointer was found.  (For this purpose, a name such as
foo.bar.example.net. should be considered (in) a sub-zone of
example.net. only iff there is a DS RR in the trust path.  In other
words, the '.'s don't make the boundries, only DS RRs do.  We should
point that out explictly, no matter what else we do.)

If the RR we create supports either option above, then non-prefixed is
the way forward.

If, however, the consensus is against such detail, the need for both
differentiating details and also for CNAME and wildcard RRs makes it a
wash.

I just thought of another possbile wording.  We could just say that our
lookup should be for whatever the (DNS) client is already going to look
up.  If it is about to do an AorAAAA lookup on 'example.com.', then it
should also do a DANE lookup on 'example.com.'.  And if it is about to
do a SRV lookup on '_sip._tcp.example.org.' then its DANE lookup should
also be on '_sip._tcp.example.org.'. 

This got longer than I expected; I hope that all is clear....

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

Date: Wed, 2 Feb 2011 15:14:07 -0500
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Call for consensus on #1

On Wed, Feb 02, 2011 at 02:35:32PM -0500, Paul Wouters wrote:
> Corner cases where one can run weird stuff on weird ports through a corporate
> firewall, allowing a TLSA record but not an A record, seems well, weird :)

The problem with doing work on the INTERnet is that it has to
interoperate in all cases, not just the tidy ones.  We have a
collective history of ignoring things like NATs that need all manner
of tricks, and then later we find ourselves living with much worse
designs that happen to work well for one case.  I think we should aim
to be as broad as feasible, even at the cost of some simplicity.

> I am not against any port or transport modifiers, provided we're not
> dropping the simple case that will be good enough for the large majority.

Surely you're not arguing for _two_ ways to do the same thing?  That
to me would be extremely objectionable, and actually I'd expect the
IESG to complain too.

A

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

Date: Wed, 2 Feb 2011 14:35:32 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Andrew Sullivan <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Call for consensus on #1

On Wed, 2 Feb 2011, Andrew Sullivan wrote:

> On Wed, Feb 02, 2011 at 12:22:55PM -0500, Paul Wouters wrote:
>>
>> If they are different services, use a different FQDN.
>
> This seems to require that the person in charge of the services is
> also in charge of the naming.  In large organizations, that may not be
> so.

I'd expect you would be asking the same people for a hostname that you
are going to inform to add a TLSA record? eg [email-masked].

Corner cases where one can run weird stuff on weird ports through a corporate
firewall, allowing a TLSA record but not an A record, seems well, weird :)

> Also, it seems to me that this reasoning is not in line with other
> patterns of use of the DNS for this sort of information.  Consistency
> is a good thing.

So is simplicity :)

I am not against any port or transport modifiers, provided we're not
dropping the simple case that will be good enough for the large majority.

Since people feel that queries should be send in parallel anyway, that
should not cause too much overhead.

So for Ond�ej, I would prefer no modifiers, but could live with any of
the modifier schemes, provided we also support the non-modifier case.

Paul

Date: Wed, 2 Feb 2011 13:24:05 -0500
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Call for consensus on #1

On Wed, Feb 02, 2011 at 12:22:55PM -0500, Paul Wouters wrote:
>
> If they are different services, use a different FQDN.

This seems to require that the person in charge of the services is
also in charge of the naming.  In large organizations, that may not be
so.

For instance, I worked at a university where one could get a network
connection with full, unfettered access to the world.  So I could run
anything I wanted on the machine.  But there was a one-hostname:1
net[4&6]address policy.  I don't know why.  

Also, it seems to me that this reasoning is not in line with other
patterns of use of the DNS for this sort of information.  Consistency
is a good thing.

I don't feel real strongly about this, however.

A

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

From: Matt McCutchen <[email-masked]>
To: [email-masked]
Date: Wed, 02 Feb 2011 09:31:19 -0500
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

On Wed, 2011-02-02 at 09:36 +0100, Ond=C5=99ej Sur=C3=BD wrote:
> On 1.2.2011 16:49, Matt McCutchen wrote:
> > One solution would be to have the client, when no TLSA exists at the
> > desired host/transport/port after following CNAMEs, search from the h=
ost
> > name up for a "DANE options" record with an exclusivity flag (which
> > could be on or off).  If no such record is found all the way up to th=
e
> > root zone, the default is "off".  Do people think this would be worth
> > the implementation effort and the extra queries?
>=20
> The crawling up to the root is a call for serious problems.  You don't=20
> want the _parent_ zone (at the zone cuts) to decide what's the _child_=20
> zone security policy.

If there is an easy way to stop at a zone cut (e.g., by detecting the
SOA record), that would be fine.  I thought it might be more trouble
than it is worth.  The case in which this makes a difference is when one
zone asserts DANE exclusivity, but its subzones make no statement.
Should we assume they use DANE exclusively too or give them the default
of no exclusivity?  The latter approach has the potential to fail open
if an organization splits off some of its DNS space into another zone
and forgets to put another exclusive-DANE flag in that zone.

> Moreover that are lot of security problems with this type of crawling=20
> (f.e. WPAD vulnerability).

The problem with WPAD is that it uses a name that can be registered by
untrusted parties.  That is not the case with this proposal, which would
put the record at the ancestor name.

--=20
Matt

Date: Wed, 2 Feb 2011 12:22:55 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Antoin Verschuren <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Call for consensus on #1

On Wed, 2 Feb 2011, Antoin Verschuren wrote:

> Hmm, haven't read the complete thread, but what happens if I want to run
> my webserver on a different port than 443, and still want to use a
> certificate for encryption ?

foo.example.com. IN TLSA x keyblobA
bar.example.com. IN TLSA y keyblobB
foo.example.com IN A 1.2.3.4
bar.example.com IN A 1.2.3.4

clean and simple. use "bar" for the service on port 443, use "foo" for the service
on the other port.

> what do I use then, including the fact that I may be running a different
> website on port 443 that I also want to publish a different certificate
> for ?

If they are different services, use a different FQDN.

Paul

From: Jakob Schlyter <[email-masked]>
Date: Wed, 2 Feb 2011 13:15:04 +0100
To: Antoin Verschuren <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Call for consensus on #1

On 2 feb 2011, at 13.01, Antoin Verschuren wrote:

> Hmm, haven't read the complete thread, but what happens if I want to =
run
> my webserver on a different port than 443, and still want to use a
> certificate for encryption ?
> what do I use then, including the fact that I may be running a =
different
> website on port 443 that I also want to publish a different =
certificate
> for ?

You look up TLSA for _1234.tcp.www.example.com, and use the resulting =
association for your TLS connection. TLS itself does not care what =
protocol you are going to use over the resulting connection. Your client =
does care of course, but not for the TLSA lookup.

	jakob

--=20
Jakob Schlyter
Kirei AB - http://www.kirei.se/

Date: Wed, 2 Feb 2011 13:01:13 +0100
From: Antoin Verschuren <[email-masked]>
To: <[email-masked]>
Subject: Re: [keyassure] Call for consensus on #1

On 01-02-11 20:03, Jakob Schlyter wrote:
> On 1 feb 2011, at 17.31, Phillip Hallam-Baker wrote:
> 
>> The protocol prefixes can have an unknown number of segments. The port is a single datum. Therefore it makes sense to prefix the port number first before the protocol prefix.
> 
> As the port is a property of the protocol (TCP, UDP and SCTP all have ports, but that may not be true for future protocols), I'd say the protocol (if any) comes first, then any protocol specific identifier.

Hmm, haven't read the complete thread, but what happens if I want to run
my webserver on a different port than 443, and still want to use a
certificate for encryption ?
what do I use then, including the fact that I may be running a different
website on port 443 that I also want to publish a different certificate
for ?

- -- 
Antoin Verschuren

Technical Policy Advisor SIDN
Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  F: +31 26 3525505  M: +31 6 23368970
mailto:[email-masked]  xmpp:[email-masked]
http://www.sidn.nl/

From: Simon Josefsson <[email-masked]>
To: [email-masked]
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 02 Feb 2011 11:10:01 +0100
Subject: Re: [keyassure] Call for consensus on #1

I prefer the _portnum._transport.hostname variant.

(My earlier answer on this was written before the decision to support
both DTLS and TLS were made, so I wanted to clarify my position.)

/Simon

Date: Wed, 02 Feb 2011 09:58:06 +0100
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Call for consensus on #1

On 1.2.2011 16:48, Matt McCutchen wrote:
> On Tue, 2011-02-01 at 15:15 +0100, Ondřej Surý wrote:
>> I would like to call for consensus on issue #1.
>>
>> The consensus would be that the draft-dane-protocol would define lookup
>> on TLSA records as query for a name prefixed with a port or port and proto.
>>
>> Possible examples (no preference here for issue #1):
>>    _443.www.example.com
>>    _443._tcp.example.com
>>    _tcp_443.example.com.
>>
>> I will open separate issue# for the particular solution for querying
>> (proto or not, fallback or not, etc.), since I don't think we have
>> consensus on that yet.  (And I think we should step forward constantly
>> even in small steps.)
>
> Are we going to talk about the specifics next?

Yes, as soon as we decide that we have consensus on that sublabeling is 
the way forward.

> I would vote for always including the transport protocol.  The client
> and DNS admin both know what protocol they are using, so there is no
> reason not to include it; having a fallback without the protocol is just
> extra complexity.  The possibility of having two different services
> using different transport protocols with the same port number seems
> remote now, but we don't know what the future might hold for transport
> protocols so I think we might as well do this right.
>
> I don't feel strongly about the syntax, but I like the consistency of
> _443._tcp.example.com with SRV.

So you agree with the proposal to use prefix labels?

Ondřej
-- 
  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
  -------------------------------------------

Date: Wed, 02 Feb 2011 09:48:25 +0100
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Call for consensus on #1

On 1.2.2011 17:31, Phillip Hallam-Baker wrote:
>
>
> On Tue, Feb 1, 2011 at 9:22 AM, Andrew Sullivan <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     On Tue, Feb 01, 2011 at 03:15:18PM +0100, Ondřej Surý wrote:
>      > The consensus would be that the draft-dane-protocol would define
>     lookup
>      > on TLSA records as query for a name prefixed with a port or port and
>      > proto.
>      >
>      > Possible examples (no preference here for issue #1):
>      >  _443.www.example.com <http://443.www.example.com>
>      >  _443._tcp.example.com <http://tcp.example.com>
>      >  _tcp_443.example.com <http://tcp_443.example.com>.
>      >
>      > I will open separate issue# for the particular solution for querying
>      > (proto or not, fallback or not, etc.), since I don't think we have
>      > consensus on that yet.  (And I think we should step forward
>     constantly
>      > even in small steps.)
>
>     I'm not actually sure that these issues can be separated, since two of
>     the examples include the proto and one does not.  I prefer the 2d
>     arrangement, personally, because it's cleaner from the DNS point of
>     view.
>
>
>
> I think that it is necessary to decide on the discovery strategy first
> before deciding how to prefix labels.

[The following paragraph applies to everybody.]
The question was if we want to use prefix labels or not.  Could you 
please say simple 'yes', 'no' or 'undecided'?  We will decide what to 
put into the prefix label in separate ticket.

Ondřej
-- 
  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
  -------------------------------------------

Date: Wed, 02 Feb 2011 09:43:18 +0100
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

On 1.2.2011 19:51, Paul Wouters wrote:
> On Tue, 1 Feb 2011, Ilari Liusvaara wrote:
>
>> If you have say 2 HTTPSs and 2 POP3Ss, you could stuff them to say,
>> ports 80 (HTTP vs. TLS can be sniffed), 443 for HTTPS and
>> 995 and 996 for POP3S.
>>
>> That would give four ports, 80, 443, 995 and 996 with no conflicts
>> that would need service labels.
>>
>> So I don't see any need for service labels unless supporting seriously
>> obsolete stuff like tcpmux. Port labels are enough.
>
> And those can also be avoided by using a separate FQDN for seperate
> security level services pointing to the same A record.

Yes, they can be avoided, but I don't think we want to push specific 
work with DNS to the DANE users.

> I have not been convinced by the artificially created examples we need
> any sub-labelling.

I know that you're not.  Hence the call for consensus, so we know the 
opinion of the working group, and we can move forward.

Ondřej
-- 
  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
  -------------------------------------------

Date: Wed, 02 Feb 2011 09:36:31 +0100
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

On 1.2.2011 16:49, Matt McCutchen wrote:
> One solution would be to have the client, when no TLSA exists at the
> desired host/transport/port after following CNAMEs, search from the host
> name up for a "DANE options" record with an exclusivity flag (which
> could be on or off).  If no such record is found all the way up to the
> root zone, the default is "off".  Do people think this would be worth
> the implementation effort and the extra queries?

The crawling up to the root is a call for serious problems.  You don't 
want the _parent_ zone (at the zone cuts) to decide what's the _child_ 
zone security policy.

Moreover that are lot of security problems with this type of crawling 
(f.e. WPAD vulnerability).

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: Jakob Schlyter <[email-masked]>
Date: Wed, 2 Feb 2011 08:31:45 +0100
To: Matt McCutchen <[email-masked]>
Cc: keyassure <[email-masked]>
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

On 1 feb 2011, at 16.49, Matt McCutchen wrote:

> I would like to assert DANE exclusivity for the entire domain
> mattmccutchen.net so that, with respect to clients that check DANE =
first
> and fall back to a mainstream public CA list, a shady CA cannot
> impersonate my existing TLS services /or/ fabricate TLS services I do
> not offer.

This sounds like the opposite of STS (Strict Transport Security), i.e. =
policy and not key association distribution.

	jakob

Sender: [email-masked]
Date: Tue, 1 Feb 2011 14:46:14 -0800
From: Zack Weinberg <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

On Tue, Feb 1, 2011 at 2:42 PM, Martin Rex <[email-masked]> wrote:
> Zack Weinberg wrote:
>>
>> > If there is a DANE record, then any wise client should interpret that
>> > as an exclusive list of allowed TLS certificates
>>
>> I agree with this, but the question is how do you present an empty list.
>
> What exactly would you want to convey with an empty list?
> =C2=A0"I won't respond to TLS, so don't even bother trying"

Well, this was originally Matt's requirement, not mine.  I just
suggested how it might be represented in the DNS.  Matt, can you
expand on why this would be useful to you?

zw

From: Martin Rex <[email-masked]>
To: [email-masked] (Zack Weinberg)
Date: Tue, 1 Feb 2011 23:42:27 +0100 (MET)
Cc: [email-masked]
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain
Reply-To: [email-masked]

Zack Weinberg wrote:
> 
> > If there is a DANE record, then any wise client should interpret that
> > as an exclusive list of allowed TLS certificates
> 
> I agree with this, but the question is how do you present an empty list.

What exactly would you want to convey with an empty list?

 "I won't respond to TLS, so don't even bother trying"

The only time when such an information becomes interesting is when
you have a client with a strong desire to communicate with a target
and intent/preference for using TLS-protection on that communication.

DANE-unaware clients will continue trying to use TLS.
What is your rationale for making DANE-aware clients exhibit
a different behaviour and entirely stop trying to use TLS?  

-Martin

Sender: [email-masked]
Date: Tue, 1 Feb 2011 13:32:14 -0800
From: Zack Weinberg <[email-masked]>
To: Paul Wouters <[email-masked]>
Cc: keyassure <[email-masked]>
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

On Tue, Feb 1, 2011 at 11:03 AM, Paul Wouters <[email-masked]> wrote:
> On Tue, 1 Feb 2011, Zack Weinberg wrote:
>
>> It occurs to me that there is currently no such thing as a DANE record
>> that expresses "there are no TLS-secured services provided by this
>> domain name"
>
> Not having them in a signed zone? And the same for CA based certs.

The *absence* of a DANE record in a signed zone has to mean fall back
to legacy behavior, otherwise we force people to adopt DANE just so
they can sign their zones.  So that won't work.

> If there is a DANE record, then any wise client should interpret that
> as an exclusive list of allowed TLS certificates

I agree with this, but the question is how do you present an empty list.

zw

Date: Tue, 01 Feb 2011 11:55:25 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Call for consensus on #1

Having seen the discussion so far, I am swayed by the argument that 
proposal #1 (send all records with differentiators for ports) is 
inferior to #2 (ask for the specific record wanted) because #1 will take 
up unnecessary bandwidth. I now support #2 more than #1, and prefer 
either _portnum._transport.hostname or _portnum.hostname over 
_portnum_transport.hostname. I don't see a strong need for giving the 
transport, but it seems trivial to do and may prevent some weird problem 
in the future.

Date: Tue, 1 Feb 2011 14:03:23 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Zack Weinberg <[email-masked]>
Cc: keyassure <[email-masked]>
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

On Tue, 1 Feb 2011, Zack Weinberg wrote:

> It occurs to me that there is currently no such thing as a DANE record
> that expresses "there are no TLS-secured services provided by this
> domain name"

Not having them in a signed zone? And the same for CA based certs.

If there is a DANE record, then any wise client should interpret that
as an exclusive list of allowed TLS certificates, and any certs presented
to the browser by SomeCA which is not in DNSSEC should be rejected as false.

If you don't do this, DANE becomes as weak as the weakest CA. And that's
not very strong.

Paul

From: Jakob Schlyter <[email-masked]>
Date: Tue, 1 Feb 2011 20:03:08 +0100
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Call for consensus on #1

On 1 feb 2011, at 17.31, Phillip Hallam-Baker wrote:

> The protocol prefixes can have an unknown number of segments. The port =
is a single datum. Therefore it makes sense to prefix the port number =
first before the protocol prefix.

As the port is a property of the protocol (TCP, UDP and SCTP all have =
ports, but that may not be true for future protocols), I'd say the =
protocol (if any) comes first, then any protocol specific identifier.

	jakob

Date: Tue, 1 Feb 2011 13:56:08 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Administrivia: Rename the mailing list to [email-masked]

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

The only example I was previously aware of was the namedroppers list which
was recently required to change to dnsext despite considerable feeling in
the WG against it.

>From an administrative point of view it is much easier for the secretariat
if the names of the lists are the same as the names of the WGs.

I don't think this is a choice in the long term, I would prefer to make a
change as soon as possible.

On Tue, Feb 1, 2011 at 12:34 PM, Paul Hoffman <[email-masked]> wrote=
:

> On 2/1/11 6:18 AM, Ond=C5=99ej Sur=C3=BD wrote:
>
>> Hi,
>>
>> I would like to ask the listmaster to rename the mailing list to
>> [email-masked] to keep it with sync with the WG name.
>>
>> Any objections?
>>
>> I'll keep you posted on the dates, etc. when I know more details.
>>
>
> FWIW, other WGs have the list name be different than the WG name due to t=
he
> same reasons we do. This neatening-up is probably not needed.
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

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

The only example I was previously aware of was the namedroppers list which =
was recently required to change to dnsext despite considerable feeling in t=
he WG against it.=C2=A0<div><br></div><div>From an administrative point of =
view it is much easier for the secretariat if the names of the lists are th=
e same as the names of the WGs.</div>
<div><br></div><div>I don&#39;t think this is a choice in the long term, I =
would prefer to make a change as soon as possible.</div><div><br><br><div c=
lass=3D"gmail_quote">On Tue, Feb 1, 2011 at 12:34 PM, Paul Hoffman <span di=
r=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">[email-masked]=
g</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 2/1/11 6:18 AM, Ond=C5=
=99ej Sur=C3=BD wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Hi,<br>
<br>
I would like to ask the listmaster to rename the mailing list to<br>
<a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a> to kee=
p it with sync with the WG name.<br>
<br>
Any objections?<br>
<br>
I&#39;ll keep you posted on the dates, etc. when I know more details.<br>
</blockquote>
<br></div>
FWIW, other WGs have the list name be different than the WG name due to the=
 same reasons we do. This neatening-up is probably not needed.<div><div></d=
iv><div class=3D"h5"><br>
_______________________________________________<br>
keyassure 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/keyassure" target=3D"_blan=
k">https://www.ietf.org/mailman/listinfo/keyassure</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>

--0016e642d3badad8a2049b3d150f--

Date: Tue, 1 Feb 2011 13:54:51 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Matt McCutchen <[email-masked]>
Cc: keyassure <[email-masked]>
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

On Tue, 1 Feb 2011, Matt McCutchen wrote:

> I am unhappy with 1a.  I wouldn't like to build the assumption that
> ports at the same host name are at the same security level into DANE,

insecure.example.com. IN A 1.2.3.4
secure.example.com. IN A 1.2.3.4
insecure.example.com. IN TLSA x snakeoilcert
secure.example.com. IN TLSA x securecert

Now you have different security levels to the same host on 1.2.3.4,
without the added parsing/complexity/uglyness of _modifiers.

Paul

Date: Tue, 1 Feb 2011 13:51:15 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Ilari Liusvaara <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

On Tue, 1 Feb 2011, Ilari Liusvaara wrote:

> If you have say 2 HTTPSs and 2 POP3Ss, you could stuff them to say,
> ports 80 (HTTP vs. TLS can be sniffed), 443 for HTTPS and
> 995 and 996 for POP3S.
>
> That would give four ports, 80, 443, 995 and 996 with no conflicts
> that would need service labels.
>
> So I don't see any need for service labels unless supporting seriously
> obsolete stuff like tcpmux. Port labels are enough.

And those can also be avoided by using a separate FQDN for seperate
security level services pointing to the same A record.

I have not been convinced by the artificially created examples we need
any sub-labelling.

Paul

Date: Tue, 01 Feb 2011 09:34:27 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Administrivia: Rename the mailing list to [email-masked]

On 2/1/11 6:18 AM, Ondřej Surý wrote:
> Hi,
>
> I would like to ask the listmaster to rename the mailing list to
> [email-masked] to keep it with sync with the WG name.
>
> Any objections?
>
> I'll keep you posted on the dates, etc. when I know more details.

FWIW, other WGs have the list name be different than the WG name due to 
the same reasons we do. This neatening-up is probably not needed.

Sender: [email-masked]
Date: Tue, 1 Feb 2011 09:19:40 -0800
From: Zack Weinberg <[email-masked]>
To: Nicholas Weaver <[email-masked]>
Cc: keyassure <[email-masked]>, Phillip Hallam-Baker <[email-masked]>
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

On Tue, Feb 1, 2011 at 8:25 AM, Nicholas Weaver
<[email-masked]> wrote:
> On Feb 1, 2011, at 8:21 AM, Zack Weinberg wrote:
>> It occurs to me that there is currently no such thing as a DANE record
>> that expresses "there are no TLS-secured services provided by this
>> domain name" (or "...by this port"). =C2=A0Maybe there should be one?
[...]
>
> Stupid question: =C2=A0Couldn't this be done with NSEC/NSEC3 records?

I don't think so, because the "secured" (RFC4033-sense) absence of a
TLSA record has to mean "fall back to pre-DANE behavior" for
compatibility's sake.  We don't want to force people to adopt DANE
just so they can adopt DNSSEC.

zw

Date: Tue, 1 Feb 2011 11:46:23 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Call for consensus on #1

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

On Tue, Feb 1, 2011 at 10:42 AM, Ond=C5=99ej Sur=C3=BD <[email-masked]>=
 wrote:

> On 1.2.2011 16:31, Lawrence Conroy wrote:
>
>> Hi There Ond=C5=99ej, folks,
>>  did you mean example 3 to have no dot between the _tcp and _443 (i.e. t=
o
>> be one label, rather than two)?
>>
>
> Yes.
>
>
>  I have no problem with example 2 (or example 1), but example 3 is
>> confusing and/or less pleasing.
>>
>
> I new I shouldn't add examples there :).
>
>
> On 1.2.2011 16:31, Martin Rex wrote:
> > I'm confused; shouldn't this read
> >
> > a   _443.www.example.com
> > b   _443._tcp.www.example.com
> > c   _tcp_443.www.example.com
>
> Yes, it should.
>
>
> > What would be easier on the DNS administration (software, handling
> > and understanding): (b) or (c) ?
>
> I knew I shouldn't add the examples to my call for consensus :-).  This
> call was only about if:
>
> a) we want to go the DNS prefix way (_prefix._hostname)
> b) something else (just _hostname, SRV, etc.)
>
> My understanding from reading the thread was that the general opinion
> (except Paul W.) was to go the DNS prefix way.

DNS Prefixes do not in general work unless the prefix is attached to a
canonical name.

If the proposal here is that the initial lookup be for a prefixed record,
there will be consequences. E.g. if the initial lookup for a key to connect
to www.example.com at port 80 is

_prefixtbs80.www.example.com

That will have the following consequences:

1) It will fail if www.example.com has a CNAME record unless there is also =
a
CNAME for the prefix record or the prefix is duplicated (thus losing the
point of having a CNAME.

In particular, it is no longer possible to use CNAME to direct across
administrative zones. So if we have a company that is outsourcing their mai=
l
to mailservice.com, they cannot so so by simply adding a CNAME to their own
domain. They have to constantly monitor the destination domain to see if
there might have been key records added and create the corresponding CNAME
records.

2) DNS Wildcards do not work

If there is a wildcard record for *.example.com, there will inevitably be
cases where the resolution either cannot provide the appropriate record or
there will be ambiguity in the record delivered.

There is no DNS wildcard construct for _prefix.*.example.com.

Use of DNAME in place of CNAME does not give the desired semantics either.

One way round this problem is to require a two stage discovery process. In
the first phase the client requests the A record and the prefix record in
parallel.

Should the A record return a result telling the client that the name is not
canonical, a second query is made for the prefix at the canonical name.

If you are going to get into multi-step discovery processes, you might as
well do the job right as I propose in the other thread.

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

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

<br><br><div class=3D"gmail_quote">On Tue, Feb 1, 2011 at 10:42 AM, 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 class=3D"im">On 1.2.2011 16:31, Lawrence Conroy 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 Ond=C5=99ej, folks,<br>
 =C2=A0did you mean example 3 to have no dot between the _tcp and _443 (i.e=
. to be one label, rather than two)?<br>
</blockquote>
<br></div>
Yes.<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">
I have no problem with example 2 (or example 1), but example 3 is confusing=
 and/or less pleasing.<br>
</blockquote>
<br></div>
I new I shouldn&#39;t add examples there :).<div class=3D"im"><br>
<br>
On 1.2.2011 16:31, Martin Rex wrote:<br>
&gt; I&#39;m confused; shouldn&#39;t this read<br>
&gt;<br>
&gt; a =C2=A0 _<a href=3D"http://443.www.example.com" target=3D"_blank">443=
.www.example.com</a><br>
&gt; b =C2=A0 _443._<a href=3D"http://tcp.www.example.com" target=3D"_blank=
">tcp.www.example.com</a><br>
&gt; c =C2=A0 _<a href=3D"http://tcp_443.www.example.com" target=3D"_blank"=
>tcp_443.www.example.com</a><br>
<br></div>
Yes, it should.<div class=3D"im"><br>
<br>
&gt; What would be easier on the DNS administration (software, handling<br>
&gt; and understanding): (b) or (c) ?<br>
<br></div>
I knew I shouldn&#39;t add the examples to my call for consensus :-). =C2=
=A0This call was only about if:<br>
<br>
a) we want to go the DNS prefix way (_prefix._hostname)<br>
b) something else (just _hostname, SRV, etc.)<br>
<br>
My understanding from reading the thread was that the general opinion (exce=
pt Paul W.) was to go the DNS prefix way.</blockquote><div><br></div><div>D=
NS Prefixes do not in general work unless the prefix is attached to a canon=
ical name.</div>
<div><br></div><div>If the proposal here is that the initial lookup be for =
a prefixed record, there will be consequences. E.g. if the initial lookup f=
or a key to connect to <a href=3D"http://www.example.com">www.example.com</=
a> at port 80 is=C2=A0</div>
<div><br></div><div>_<a href=3D"http://prefixtbs80.www.example.com">prefixt=
bs80.www.example.com</a></div><div><br></div><div>That will have the follow=
ing consequences:</div><div><br></div><div>1) It will fail if <a href=3D"ht=
tp://www.example.com">www.example.com</a> has a CNAME record unless there i=
s also a CNAME for the prefix record or the prefix is duplicated (thus losi=
ng the point of having a CNAME.</div>
<div><br></div><div>In particular, it is no longer possible to use CNAME to=
 direct across administrative zones. So if we have a company that is outsou=
rcing their mail to <a href=3D"http://mailservice.com">mailservice.com</a>,=
 they cannot so so by simply adding a CNAME to their own domain. They have =
to constantly monitor the destination domain to see if there might have bee=
n key records added and create the corresponding CNAME records.</div>
<div><br></div><div><br></div><div>2) DNS Wildcards do not work</div><div><=
br></div><div>If there is a wildcard record for *.<a href=3D"http://example=
.com">example.com</a>, there will inevitably be cases where the resolution =
either cannot provide the appropriate record or there will be ambiguity in =
the record delivered.</div>
<div><br></div><div><br></div><div>There is no DNS wildcard construct for _=
prefix.*.<a href=3D"http://example.com">example.com</a>.</div><div><br></di=
v><div>Use of DNAME in place of CNAME does not give the desired semantics e=
ither.</div>
<div><br></div><div><br></div><div>One way round this problem is to require=
 a two stage discovery process. In the first phase the client requests the =
A record and the prefix record in parallel.</div><div><br></div><div>Should=
 the A record return a result telling the client that the name is not canon=
ical, a second query is made for the prefix at the canonical name.</div>
<div><br></div><div>If you are going to get into multi-step discovery proce=
sses, you might as well do the job right as I propose in the other thread.<=
/div><div><br></div></div><br>-- <br>Website: <a href=3D"http://hallambaker=
.com/">http://hallambaker.com/</a><br>
<br>

--0016e644c708d69c64049b3b45ea--

Date: Tue, 1 Feb 2011 11:31:58 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Andrew Sullivan <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Call for consensus on #1

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

On Tue, Feb 1, 2011 at 9:22 AM, Andrew Sullivan <[email-masked]> wrote:

> On Tue, Feb 01, 2011 at 03:15:18PM +0100, Ond=C5=99ej Sur=C3=BD wrote:
> > The consensus would be that the draft-dane-protocol would define lookup
> > on TLSA records as query for a name prefixed with a port or port and
> > proto.
> >
> > Possible examples (no preference here for issue #1):
> >  _443.www.example.com
> >  _443._tcp.example.com
> >  _tcp_443.example.com.
> >
> > I will open separate issue# for the particular solution for querying
> > (proto or not, fallback or not, etc.), since I don't think we have
> > consensus on that yet.  (And I think we should step forward constantly
> > even in small steps.)
>
> I'm not actually sure that these issues can be separated, since two of
> the examples include the proto and one does not.  I prefer the 2d
> arrangement, personally, because it's cleaner from the DNS point of
> view.

I think that it is necessary to decide on the discovery strategy first
before deciding how to prefix labels.

There are two separate concerns here

1) How to avoid records intended only for service A being used to access
service B

2) How to discover the specific records intended for a specific instance of
service of type X on host Y on port Z.

The first is a security concern. If I have a key being advertised for a low
risk protocol (e.g. SMTP for STARTTLS), I do not want a client to accept
that for use with a high risk protocol (e.g. interbank transaction
settlements).

I think that the way to address the first concern is to use SRV prefixes bu=
t
to express them inside the certificate as use restrictions according to RFC
4985.

The second only affects some sites. Use of DNS prefix records involves
certain performance issues. Thus it is reasonable to make this an option fo=
r
those sites that require such certificates to be distinguished.

Given the limited scope of use and given that any site that has a hundred
services at the same domain label is almost certainly going to require use
of SRV or similar to make it practical, I believe that any extended
discovery mechanism for keys should map onto the prefixes used in SRV and
similar mechanisms.

There would thus be three separate phases of resolution, the first two
having the potential to trigger an additional round of resolution should it
be required.

1) Generic - all protocols and ports
   www.example.com

2) Canonical name of service prefixed by protocol
   _http._tcp.example.com

3) Canonical name of host prefixed by protocol+port
   _http._tcp._80.host1.example.com

The protocol prefixes can have an unknown number of segments. The port is a
single datum. Therefore it makes sense to prefix the port number first
before the protocol prefix.

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

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

<br><br><div class=3D"gmail_quote">On Tue, Feb 1, 2011 at 9:22 AM, 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, Feb 01, 2011 at 03:15:18PM +0100, Ond=C5=99ej Sur=
=C3=BD wrote:<br>
&gt; The consensus would be that the draft-dane-protocol would define looku=
p<br>
&gt; on TLSA records as query for a name prefixed with a port or port and<b=
r>
&gt; proto.<br>
&gt;<br>
&gt; Possible examples (no preference here for issue #1):<br>
&gt; =C2=A0_<a href=3D"http://443.www.example.com" target=3D"_blank">443.ww=
w.example.com</a><br>
&gt; =C2=A0_443._<a href=3D"http://tcp.example.com" target=3D"_blank">tcp.e=
xample.com</a><br>
&gt; =C2=A0_<a href=3D"http://tcp_443.example.com" target=3D"_blank">tcp_44=
3.example.com</a>.<br>
&gt;<br>
&gt; I will open separate issue# for the particular solution for querying<b=
r>
&gt; (proto or not, fallback or not, etc.), since I don&#39;t think we have=
<br>
&gt; consensus on that yet. =C2=A0(And I think we should step forward const=
antly<br>
&gt; even in small steps.)<br>
<br>
</div>I&#39;m not actually sure that these issues can be separated, since t=
wo of<br>
the examples include the proto and one does not. =C2=A0I prefer the 2d<br>
arrangement, personally, because it&#39;s cleaner from the DNS point of<br>
view.</blockquote><div><br></div><div><br></div><div>I think that it is nec=
essary to decide on the discovery strategy first before deciding how to pre=
fix labels.</div><div><br></div><div>There are two separate concerns here</=
div>
<div><br></div><div>1) How to avoid records intended only for service A bei=
ng used to access service B</div><div><br></div><div>2) How to discover the=
 specific records intended for a specific instance of service of type X on =
host Y on port Z.</div>
<div><br></div><div><br></div><div>The first is a security concern. If I ha=
ve a key being advertised for a low risk protocol (e.g. SMTP for STARTTLS),=
 I do not want a client to accept that for use with a high risk protocol (e=
.g. interbank transaction settlements).</div>
<div><br></div><div>I think that the way to address the first concern is to=
 use SRV prefixes but to express them inside the certificate as use restric=
tions according to RFC 4985.=C2=A0</div><div><br></div><div><br></div><div>=
The second only affects some sites. Use of DNS prefix records involves cert=
ain performance issues. Thus it is reasonable to make this an option for th=
ose sites that require such certificates to be distinguished.</div>
<div><br></div><div>Given the limited scope of use and given that any site =
that has a hundred services at the same domain label is almost certainly go=
ing to require use of SRV or similar to make it practical, I believe that a=
ny extended discovery mechanism for keys should map onto the prefixes used =
in SRV and similar mechanisms.</div>
<div><br></div><div>There would thus be three separate phases of resolution=
, the first two having the potential to trigger an additional round of reso=
lution should it be required.</div><div><br></div><div>1) Generic - all pro=
tocols and ports</div>
<div>=C2=A0=C2=A0 <a href=3D"http://www.example.com">www.example.com</a></d=
iv><div><br></div><div>2) Canonical name of service prefixed by protocol</d=
iv><div>=C2=A0=C2=A0 _http._<a href=3D"http://tcp.example.com">tcp.example.=
com</a></div><div><br>
</div><div>3) Canonical name of host prefixed by protocol+port</div><div>=
=C2=A0=C2=A0 _http._tcp._<a href=3D"http://80.host1.example.com">80.host1.e=
xample.com</a></div><div><br></div><div>=C2=A0</div><div>The protocol prefi=
xes can have an unknown number of segments. The port is a single datum. The=
refore it makes sense to prefix the port number first before the protocol p=
refix.</div>
<div><br></div></div>-- <br>Website: <a href=3D"http://hallambaker.com/">ht=
tp://hallambaker.com/</a><br><br>

--0016e646526c3e76a9049b3b1221--

From: Nicholas Weaver <[email-masked]>
Date: Tue, 1 Feb 2011 08:25:02 -0800
To: Zack Weinberg <[email-masked]>
Cc: Phillip Hallam-Baker <[email-masked]>, keyassure <[email-masked]>
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

On Feb 1, 2011, at 8:21 AM, Zack Weinberg wrote:

> On Tue, Feb 1, 2011 at 8:10 AM, Phillip Hallam-Baker =
<[email-masked]> wrote:
>> Let us assume that you are signing your domain with DNSSEC.
>> It follows that clients will be able to determine with certainty that =
a
>> specific subdomain does not exist.
>>=20
>> Thus it will be impossible for a client to obtain a valid A record or =
SRV
>> record or any other record that would enable a connection to be made.
>> It follows that this is not an issue for subdomains that do not =
exist.
>> For domains that do exist, the administrator can add a CAA or DANE =
record to
>> express the desired semantics.
>=20
> It occurs to me that there is currently no such thing as a DANE record
> that expresses "there are no TLS-secured services provided by this
> domain name" (or "...by this port").  Maybe there should be one?  I
> suggest that the record with hash type 0, cert type 0, and zero bytes
> of certificate data could have this meaning.  Under the _nnn._tcp.host
> proposal being discussed in the other thread, you could then have
>=20
> $ORIGIN example.com.
>=20
> www                 A  w.x.y.z
> _443._tcp.www  TLSA ( 1 2 ...hash... )
> *.www               TLSA ( 0 0 )
>=20
> to indicate that 'www.example.com' provides HTTPS service with a
> particular key, but does not provide any other secured service.

Stupid question:  Couldn't this be done with NSEC/NSEC3 records?

Sender: [email-masked]
Date: Tue, 1 Feb 2011 08:21:36 -0800
From: Zack Weinberg <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: keyassure <[email-masked]>
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

On Tue, Feb 1, 2011 at 8:10 AM, Phillip Hallam-Baker <[email-masked]> wrote:
> Let us assume that you are signing your domain with DNSSEC.
> It follows that clients will be able to determine with certainty that a
> specific subdomain does not exist.
>
> Thus it will be impossible for a client to obtain a valid A record or SRV
> record or any other record that would enable a connection to be made.
> It follows that this is not an issue for subdomains that do not exist.
> For domains that do exist, the administrator can add a CAA or DANE record to
> express the desired semantics.

It occurs to me that there is currently no such thing as a DANE record
that expresses "there are no TLS-secured services provided by this
domain name" (or "...by this port").  Maybe there should be one?  I
suggest that the record with hash type 0, cert type 0, and zero bytes
of certificate data could have this meaning.  Under the _nnn._tcp.host
proposal being discussed in the other thread, you could then have

$ORIGIN example.com.

www                 A  w.x.y.z
_443._tcp.www  TLSA ( 1 2 ...hash... )
*.www               TLSA ( 0 0 )

to indicate that 'www.example.com' provides HTTPS service with a
particular key, but does not provide any other secured service.

zw

Date: Tue, 1 Feb 2011 11:10:59 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Matt McCutchen <[email-masked]>
Cc: keyassure <[email-masked]>
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

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

Let us assume that you are signing your domain with DNSSEC.

It follows that clients will be able to determine with certainty that a
specific subdomain does not exist.

Thus it will be impossible for a client to obtain a valid A record or SRV
record or any other record that would enable a connection to be made.

It follows that this is not an issue for subdomains that do not exist.

For domains that do exist, the administrator can add a CAA or DANE record to
express the desired semantics.

This is certainly an issue for CAA which deals with issue since it is
entirely valid for a domain name holder to request a certificate for a
subdomain before the subdomain is created. And so the rules for issuer
processing of CAA records require a check at the public delegation point
should the check at the domain fail.

The cost of implementation in a client is rather higher since it has to
maintain a list of public delegation points and has to perform verification
in at least two places.

Maintaining a list of public delegation points in a client is non trivial.
In addition to the non trivial problem of adding/deleting points from the
list it is necessary to have a means of distribution.

On Tue, Feb 1, 2011 at 10:49 AM, Matt McCutchen <[email-masked]>wrote:

> I would like to assert DANE exclusivity for the entire domain
> mattmccutchen.net so that, with respect to clients that check DANE first
> and fall back to a mainstream public CA list, a shady CA cannot
> impersonate my existing TLS services /or/ fabricate TLS services I do
> not offer.  I know I can achieve that by adding enough wildcard dummy
> TLSA records to cover the entire namespace as an automated
> postprocessing step, but that is a little ugly.
>
> One solution would be to have the client, when no TLSA exists at the
> desired host/transport/port after following CNAMEs, search from the host
> name up for a "DANE options" record with an exclusivity flag (which
> could be on or off).  If no such record is found all the way up to the
> root zone, the default is "off".  Do people think this would be worth
> the implementation effort and the extra queries?
>
> --
> Matt
>
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

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

Let us assume that you are signing your domain with DNSSEC.<div><br></div><=
div>It follows that clients will be able to determine with certainty that a=
 specific subdomain does not exist.=A0<br><br></div><div>Thus it will be im=
possible for a client to obtain a valid A record or SRV record or any other=
 record that would enable a connection to be made.</div>
<div><br></div><div>It follows that this is not an issue for subdomains tha=
t do not exist.</div><div><br></div><div>For domains that do exist, the adm=
inistrator can add a CAA or DANE record to express the desired semantics.</=
div>
<div><br></div><div><br></div><div>This is certainly an issue for CAA which=
 deals with issue since it is entirely valid for a domain name holder to re=
quest a certificate for a subdomain before the subdomain is created. And so=
 the rules for issuer processing of CAA records require a check at the publ=
ic delegation point should the check at the domain fail.</div>
<div><br></div><div><br></div><div>The cost of implementation in a client i=
s rather higher since it has to maintain a list of public delegation points=
 and has to perform verification in at least two places.</div><div><br>
</div><div>Maintaining a list of public delegation points in a client is no=
n trivial. In addition to the non trivial problem of adding/deleting points=
 from the list it is necessary to have a means of distribution.</div><div>
<br></div><div><br></div><div><br></div><div><br><div class=3D"gmail_quote"=
>On Tue, Feb 1, 2011 at 10:49 AM, Matt McCutchen <span dir=3D"ltr">&lt;<a h=
ref=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;">I would like to assert DANE exclusivity for=
 the entire domain<br>
<a href=3D"http://mattmccutchen.net" target=3D"_blank">mattmccutchen.net</a=
> so that, with respect to clients that check DANE first<br>
and fall back to a mainstream public CA list, a shady CA cannot<br>
impersonate my existing TLS services /or/ fabricate TLS services I do<br>
not offer. =A0I know I can achieve that by adding enough wildcard dummy<br>
TLSA records to cover the entire namespace as an automated<br>
postprocessing step, but that is a little ugly.<br>
<br>
One solution would be to have the client, when no TLSA exists at the<br>
desired host/transport/port after following CNAMEs, search from the host<br=
>
name up for a &quot;DANE options&quot; record with an exclusivity flag (whi=
ch<br>
could be on or off). =A0If no such record is found all the way up to the<br=
>
root zone, the default is &quot;off&quot;. =A0Do people think this would be=
 worth<br>
the implementation effort and the extra queries?<br>
<font color=3D"#888888"><br>
--<br>
Matt<br>
<br>
<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>
</font></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a href=
=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--0016e646526c3334e0049b3ac756--

Date: Tue, 01 Feb 2011 17:08:14 +0100
From: Pieter Lange <[email-masked]>
To: Ben Laurie <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Firefox 4 (beta) add-on for certificate validations using DNSSEC

I'm sorry, we didn't put up a link too clearly on the page. It's also
added at the "For developers" section now.

You can find our repository at https://os3sec.org/svn/

On 02/01/2011 05:00 PM, Ben Laurie wrote:
> You invite people to submit patches, but where's the source? Did I miss a
> link somewhere?
> 
> On 1 February 2011 10:19, Pieter Lange <[email-masked]> wrote:
> 
>> We're students from the System and Network Engineering master at the
>> University of Amsterdam and have almost completed our one month project
>> under supervision of NLnet.
>> The topic was related to issue #8 (securing last hop) and other subjects
>> you're discussing here, so we think you might be interested.
>>
>> During last month we've been following the list, reading your draft for
>> securing TLS certificate associations and have implemented an add-on for
>> the new Firefox 4 beta. This add-on is inspired[1] on the DNSSEC
>> validator by NIC.CZ, but does much more.
>>
>> Actual DNSSEC trust chain validation is performed by implementing
>> libunbound[2], unlike the original add-on -- that just checked if the
>> 'ad' flag was set and by no means informed users that the 'ad' can be
>> faked.
>>
>> Additionally, the add-on requests TXT and TLSA records for the same
>> label. The TXT implementation is based on Dan Kaminsky's spec[3] as it
>> is a nice showcase for what's possible. Note that we will remove support
>> for TXT record lookup when dane is nearing consensus on all issues.
>>
>> The add-on currently only supports doing sha1 validation for both TXT
>> and TLSA records; full certificates (cert type 2) or 'parent' (cert type
>> 3/4) certificates are not supported. And there must be a thousand and
>> one more things wrong with it; we are not by any means saying this is a
>> proper way to verify certificates yet. Nor do we properly support the
>> 'sts' flag in Kaminsky's specification because of a conflicting rule in
>> the STS[4] draft specification (doesn't allow self signed certificates).
>>
>> We are very much aware that you focus on more than just HTTP, but still
>> this add-on might prove to be a useful tool to evaluate the current drafts.
>>
>> Bug reports are very welcome but we haven't yet set up our bugtracker.
>> Please have patience and if you have any immediate concerns contact us
>> via email.
>>
>> You can find our add-on at https://os3sec.org, the website of our
>> education can be found at https://www.os3.nl
>>
>> Regards,
>> Danny Groenewegen & Pieter Lange
>>
>> [1] http://www.dnssec-validator.cz
>> [2] http://www.unbound.net
>> [3] http://dankaminsky.com/2010/12/19/dnssec-ch1/
>> [4] http://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec-00
>> _______________________________________________
>> keyassure mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/keyassure
>>
> 

From: Jakob Schlyter <[email-masked]>
Date: Tue, 1 Feb 2011 17:05:51 +0100
To: Matt McCutchen <[email-masked]>
Cc: keyassure <[email-masked]>
Subject: Re: [keyassure] Call for consensus on #1

On 1 feb 2011, at 16.48, Matt McCutchen wrote:

> I don't feel strongly about the syntax, but I like the consistency of
> _443._tcp.example.com with SRV.

+1

	jakob

Date: Tue, 1 Feb 2011 11:00:35 -0500
From: Ben Laurie <[email-masked]>
To: Pieter Lange <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Firefox 4 (beta) add-on for certificate validations using DNSSEC

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

You invite people to submit patches, but where's the source? Did I miss a
link somewhere?

On 1 February 2011 10:19, Pieter Lange <[email-masked]> wrote:

> We're students from the System and Network Engineering master at the
> University of Amsterdam and have almost completed our one month project
> under supervision of NLnet.
> The topic was related to issue #8 (securing last hop) and other subjects
> you're discussing here, so we think you might be interested.
>
> During last month we've been following the list, reading your draft for
> securing TLS certificate associations and have implemented an add-on for
> the new Firefox 4 beta. This add-on is inspired[1] on the DNSSEC
> validator by NIC.CZ, but does much more.
>
> Actual DNSSEC trust chain validation is performed by implementing
> libunbound[2], unlike the original add-on -- that just checked if the
> 'ad' flag was set and by no means informed users that the 'ad' can be
> faked.
>
> Additionally, the add-on requests TXT and TLSA records for the same
> label. The TXT implementation is based on Dan Kaminsky's spec[3] as it
> is a nice showcase for what's possible. Note that we will remove support
> for TXT record lookup when dane is nearing consensus on all issues.
>
> The add-on currently only supports doing sha1 validation for both TXT
> and TLSA records; full certificates (cert type 2) or 'parent' (cert type
> 3/4) certificates are not supported. And there must be a thousand and
> one more things wrong with it; we are not by any means saying this is a
> proper way to verify certificates yet. Nor do we properly support the
> 'sts' flag in Kaminsky's specification because of a conflicting rule in
> the STS[4] draft specification (doesn't allow self signed certificates).
>
> We are very much aware that you focus on more than just HTTP, but still
> this add-on might prove to be a useful tool to evaluate the current drafts.
>
> Bug reports are very welcome but we haven't yet set up our bugtracker.
> Please have patience and if you have any immediate concerns contact us
> via email.
>
> You can find our add-on at https://os3sec.org, the website of our
> education can be found at https://www.os3.nl
>
> Regards,
> Danny Groenewegen & Pieter Lange
>
> [1] http://www.dnssec-validator.cz
> [2] http://www.unbound.net
> [3] http://dankaminsky.com/2010/12/19/dnssec-ch1/
> [4] http://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec-00
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

You invite people to submit patches, but where&#39;s the source? Did I miss=
 a link somewhere?<br><br><div class=3D"gmail_quote">On 1 February 2011 10:=
19, Pieter Lange <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]=
l">[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;">We&#39;re students from the System and Netw=
ork Engineering master at the<br>
University of Amsterdam and have almost completed our one month project<br>
under supervision of NLnet.<br>
The topic was related to issue #8 (securing last hop) and other subjects<br=
>
you&#39;re discussing here, so we think you might be interested.<br>
<br>
During last month we&#39;ve been following the list, reading your draft for=
<br>
securing TLS certificate associations and have implemented an add-on for<br=
>
the new Firefox 4 beta. This add-on is inspired[1] on the DNSSEC<br>
validator by <a href=3D"http://NIC.CZ" target=3D"_blank">NIC.CZ</a>, but do=
es much more.<br>
<br>
Actual DNSSEC trust chain validation is performed by implementing<br>
libunbound[2], unlike the original add-on -- that just checked if the<br>
&#39;ad&#39; flag was set and by no means informed users that the &#39;ad&#=
39; can be faked.<br>
<br>
Additionally, the add-on requests TXT and TLSA records for the same<br>
label. The TXT implementation is based on Dan Kaminsky&#39;s spec[3] as it<=
br>
is a nice showcase for what&#39;s possible. Note that we will remove suppor=
t<br>
for TXT record lookup when dane is nearing consensus on all issues.<br>
<br>
The add-on currently only supports doing sha1 validation for both TXT<br>
and TLSA records; full certificates (cert type 2) or &#39;parent&#39; (cert=
 type<br>
3/4) certificates are not supported. And there must be a thousand and<br>
one more things wrong with it; we are not by any means saying this is a<br>
proper way to verify certificates yet. Nor do we properly support the<br>
&#39;sts&#39; flag in Kaminsky&#39;s specification because of a conflicting=
 rule in<br>
the STS[4] draft specification (doesn&#39;t allow self signed certificates)=
.<br>
<br>
We are very much aware that you focus on more than just HTTP, but still<br>
this add-on might prove to be a useful tool to evaluate the current drafts.=
<br>
<br>
Bug reports are very welcome but we haven&#39;t yet set up our bugtracker.<=
br>
Please have patience and if you have any immediate concerns contact us<br>
via email.<br>
<br>
You can find our add-on at <a href=3D"https://os3sec.org" target=3D"_blank"=
>https://os3sec.org</a>, the website of our<br>
education can be found at <a href=3D"https://www.os3.nl" target=3D"_blank">=
https://www.os3.nl</a><br>
<br>
Regards,<br>
Danny Groenewegen &amp; Pieter Lange<br>
<br>
[1] <a href=3D"http://www.dnssec-validator.cz" target=3D"_blank">http://www=
.dnssec-validator.cz</a><br>
[2] <a href=3D"http://www.unbound.net" target=3D"_blank">http://www.unbound=
.net</a><br>
[3] <a href=3D"http://dankaminsky.com/2010/12/19/dnssec-ch1/" target=3D"_bl=
ank">http://dankaminsky.com/2010/12/19/dnssec-ch1/</a><br>
[4] <a href=3D"http://tools.ietf.org/html/draft-ietf-websec-strict-transpor=
t-sec-00" target=3D"_blank">http://tools.ietf.org/html/draft-ietf-websec-st=
rict-transport-sec-00</a><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>

--0015175ce032002c5d049b3aa23c--

From: Matt McCutchen <[email-masked]>
To: [email-masked]
Date: Tue, 01 Feb 2011 10:49:16 -0500
Subject: Re: [keyassure] Administrivia: Rename the mailing list to [email-masked]

On Tue, 2011-02-01 at 15:18 +0100, Ond=C5=99ej Sur=C3=BD wrote:=20
> I would like to ask the listmaster to rename the mailing list to=20
> [email-masked] to keep it with sync with the WG name.
>=20
> Any objections?

Not from me.  Just please make sure that the old archive redirects to
the new so that the links in our mails from the past few months do not
all break.  Hopefully that is standard practice.

--=20
Matt

From: Matt McCutchen <[email-masked]>
To: keyassure <[email-masked]>
Date: Tue, 01 Feb 2011 10:49:00 -0500
Subject: [keyassure] Asserting DANE exclusivity for an entire domain

I would like to assert DANE exclusivity for the entire domain
mattmccutchen.net so that, with respect to clients that check DANE first
and fall back to a mainstream public CA list, a shady CA cannot
impersonate my existing TLS services /or/ fabricate TLS services I do
not offer.  I know I can achieve that by adding enough wildcard dummy
TLSA records to cover the entire namespace as an automated
postprocessing step, but that is a little ugly.

One solution would be to have the client, when no TLSA exists at the
desired host/transport/port after following CNAMEs, search from the host
name up for a "DANE options" record with an exclusivity flag (which
could be on or off).  If no such record is found all the way up to the
root zone, the default is "off".  Do people think this would be worth
the implementation effort and the extra queries?

-- 
Matt

From: Matt McCutchen <[email-masked]>
To: keyassure <[email-masked]>
Date: Tue, 01 Feb 2011 10:48:49 -0500
Subject: Re: [keyassure] Call for consensus on #1

On Tue, 2011-02-01 at 15:15 +0100, Ond=C5=99ej Sur=C3=BD wrote:=20
> I would like to call for consensus on issue #1.
>=20
> The consensus would be that the draft-dane-protocol would define lookup=
=20
> on TLSA records as query for a name prefixed with a port or port and pr=
oto.
>=20
> Possible examples (no preference here for issue #1):
>   _443.www.example.com
>   _443._tcp.example.com
>   _tcp_443.example.com.
>=20
> I will open separate issue# for the particular solution for querying=20
> (proto or not, fallback or not, etc.), since I don't think we have=20
> consensus on that yet.  (And I think we should step forward constantly=20
> even in small steps.)

Are we going to talk about the specifics next?

I would vote for always including the transport protocol.  The client
and DNS admin both know what protocol they are using, so there is no
reason not to include it; having a fallback without the protocol is just
extra complexity.  The possibility of having two different services
using different transport protocols with the same port number seems
remote now, but we don't know what the future might hold for transport
protocols so I think we might as well do this right.

I don't feel strongly about the syntax, but I like the consistency of
_443._tcp.example.com with SRV.

--=20
Matt

Date: Tue, 01 Feb 2011 16:42:26 +0100
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Call for consensus on #1

On 1.2.2011 16:31, Lawrence Conroy wrote:
> Hi There Ondřej, folks,
>   did you mean example 3 to have no dot between the _tcp and _443 (i.e. to be one label, rather than two)?

Yes.

> I have no problem with example 2 (or example 1), but example 3 is confusing and/or less pleasing.

I new I shouldn't add examples there :).

On 1.2.2011 16:31, Martin Rex wrote:
 > I'm confused; shouldn't this read
 >
 > a   _443.www.example.com
 > b   _443._tcp.www.example.com
 > c   _tcp_443.www.example.com

Yes, it should.

 > What would be easier on the DNS administration (software, handling
 > and understanding): (b) or (c) ?

I knew I shouldn't add the examples to my call for consensus :-).  This 
call was only about if:

a) we want to go the DNS prefix way (_prefix._hostname)
b) something else (just _hostname, SRV, etc.)

My understanding from reading the thread was that the general opinion 
(except Paul W.) was to go the DNS prefix way.

O.

> On 1 Feb 2011, at 14:15, Ondřej Surý wrote:
>> Hi,
>>
>> I would like to call for consensus on issue #1.
>>
>> The consensus would be that the draft-dane-protocol would define lookup on TLSA records as query for a name prefixed with a port or port and proto.
>>
>> Possible examples (no preference here for issue #1):
>> _443.www.example.com
>> _443._tcp.example.com
>> _tcp_443.example.com.
>>
>> I will open separate issue# for the particular solution for querying (proto or not, fallback or not, etc.), since I don't think we have consensus on that yet.  (And I think we should step forward constantly even in small steps.)
>>
>> 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
>> -------------------------------------------
>> _______________________________________________
>> keyassure mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/keyassure
>

-- 
  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: Lawrence Conroy <[email-masked]>
Date: Tue, 1 Feb 2011 15:31:24 +0000
To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Call for consensus on #1

Hi There Ond=C5=99ej, folks,
 did you mean example 3 to have no dot between the _tcp and _443 (i.e. =
to be one label, rather than two)?

I have no problem with example 2 (or example 1), but example 3 is =
confusing and/or less pleasing.

all the best,
  Lawrence

On 1 Feb 2011, at 14:15, Ond=C5=99ej Sur=C3=BD wrote:
> Hi,
>=20
> I would like to call for consensus on issue #1.
>=20
> The consensus would be that the draft-dane-protocol would define =
lookup on TLSA records as query for a name prefixed with a port or port =
and proto.
>=20
> Possible examples (no preference here for issue #1):
> _443.www.example.com
> _443._tcp.example.com
> _tcp_443.example.com.
>=20
> I will open separate issue# for the particular solution for querying =
(proto or not, fallback or not, etc.), since I don't think we have =
consensus on that yet.  (And I think we should step forward constantly =
even in small steps.)
>=20
> Ondrej
> --=20
> Ond=C5=99ej Sur=C3=BD
> vedouc=C3=AD v=C3=BDzkumu/Head of R&D department
> -------------------------------------------
> CZ.NIC, z.s.p.o.    --    Laborato=C5=99e CZ.NIC
> Americka 23, 120 00 Praha 2, Czech Republic
> mailto:[email-masked]    http://nic.cz/
> tel:+420.222745110       fax:+420.222745112
> -------------------------------------------
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

From: Martin Rex <[email-masked]>
To: [email-masked] (=?UTF-8?B?T25kxZllaiBTdXLDvQ==?=)
Date: Tue, 1 Feb 2011 16:31:12 +0100 (MET)
Cc: [email-masked]
Subject: Re: [keyassure] Call for consensus on #1
Reply-To: [email-masked]

=?UTF-8?B?T25kxZllaiBTdXLDvQ==?= wrote:
> 
> The consensus would be that the draft-dane-protocol would define lookup 
> on TLSA records as query for a name prefixed with a port or port and proto.
> 
> Possible examples (no preference here for issue #1):
>   _443.www.example.com
>   _443._tcp.example.com
>   _tcp_443.example.com.

I'm confused; shouldn't this read

a   _443.www.example.com
b   _443._tcp.www.example.com
c   _tcp_443.www.example.com

What would be easier on the DNS administration (software, handling
and understanding): (b) or (c) ?

-Martin 

Date: Tue, 01 Feb 2011 16:19:09 +0100
From: Pieter Lange <[email-masked]>
To: [email-masked], Danny Groenewegen <[email-masked]>
Subject: [keyassure] Firefox 4 (beta) add-on for certificate validations using DNSSEC

We're students from the System and Network Engineering master at the
University of Amsterdam and have almost completed our one month project
under supervision of NLnet.
The topic was related to issue #8 (securing last hop) and other subjects
you're discussing here, so we think you might be interested.

During last month we've been following the list, reading your draft for
securing TLS certificate associations and have implemented an add-on for
the new Firefox 4 beta. This add-on is inspired[1] on the DNSSEC
validator by NIC.CZ, but does much more.

Actual DNSSEC trust chain validation is performed by implementing
libunbound[2], unlike the original add-on -- that just checked if the
'ad' flag was set and by no means informed users that the 'ad' can be faked.

Additionally, the add-on requests TXT and TLSA records for the same
label. The TXT implementation is based on Dan Kaminsky's spec[3] as it
is a nice showcase for what's possible. Note that we will remove support
for TXT record lookup when dane is nearing consensus on all issues.

The add-on currently only supports doing sha1 validation for both TXT
and TLSA records; full certificates (cert type 2) or 'parent' (cert type
3/4) certificates are not supported. And there must be a thousand and
one more things wrong with it; we are not by any means saying this is a
proper way to verify certificates yet. Nor do we properly support the
'sts' flag in Kaminsky's specification because of a conflicting rule in
the STS[4] draft specification (doesn't allow self signed certificates).

We are very much aware that you focus on more than just HTTP, but still
this add-on might prove to be a useful tool to evaluate the current drafts.

Bug reports are very welcome but we haven't yet set up our bugtracker.
Please have patience and if you have any immediate concerns contact us
via email.

You can find our add-on at https://os3sec.org, the website of our
education can be found at https://www.os3.nl

Regards,
Danny Groenewegen & Pieter Lange

[1] http://www.dnssec-validator.cz
[2] http://www.unbound.net
[3] http://dankaminsky.com/2010/12/19/dnssec-ch1/
[4] http://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec-00

Date: Tue, 1 Feb 2011 10:11:24 -0500
From: Andrew Sullivan <[email-masked]>
To: =?utf-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Call for consensus on #1

On Tue, Feb 01, 2011 at 03:44:22PM +0100, Ondřej Surý wrote:
> But I am fine with withdrawing the call if there is not enough support  
> to go in those smaller steps.

No, I have no complaint about the call, and I think it's wise to try
to separate these things for clarity.  I just meant that I don't know
they're quite as separable in fact as in principle.

A

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

Date: Tue, 01 Feb 2011 15:44:22 +0100
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Call for consensus on #1

On 1.2.2011 15:22, Andrew Sullivan wrote:
> On Tue, Feb 01, 2011 at 03:15:18PM +0100, Ondřej Surý wrote:
>> The consensus would be that the draft-dane-protocol would define lookup
>> on TLSA records as query for a name prefixed with a port or port and
>> proto.
>>
>> Possible examples (no preference here for issue #1):
>>   _443.www.example.com
>>   _443._tcp.example.com
>>   _tcp_443.example.com.
>>
>> I will open separate issue# for the particular solution for querying
>> (proto or not, fallback or not, etc.), since I don't think we have
>> consensus on that yet.  (And I think we should step forward constantly
>> even in small steps.)
>
> I'm not actually sure that these issues can be separated, since two of
> the examples include the proto and one does not.  I prefer the 2d
> arrangement, personally, because it's cleaner from the DNS point of
> view.

I was planning to open separate issue# on what to include into DNS name 
after we get consensus on that we want to have solution based on 
prefix+hostname in QNAME.  As opposed to just having hostname in QNAME, 
or some interaction with SRV record.  I felt that if we slowly narrow 
the topic it will not divert that much in the mailing list.

But I am fine with withdrawing the call if there is not enough support 
to go in those smaller steps.

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

Date: Tue, 1 Feb 2011 09:22:39 -0500
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Call for consensus on #1

On Tue, Feb 01, 2011 at 03:15:18PM +0100, Ondřej Surý wrote:
> The consensus would be that the draft-dane-protocol would define lookup  
> on TLSA records as query for a name prefixed with a port or port and 
> proto.
>
> Possible examples (no preference here for issue #1):
>  _443.www.example.com
>  _443._tcp.example.com
>  _tcp_443.example.com.
>
> I will open separate issue# for the particular solution for querying  
> (proto or not, fallback or not, etc.), since I don't think we have  
> consensus on that yet.  (And I think we should step forward constantly  
> even in small steps.)

I'm not actually sure that these issues can be separated, since two of
the examples include the proto and one does not.  I prefer the 2d
arrangement, personally, because it's cleaner from the DNS point of
view.

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

Date: Tue, 01 Feb 2011 15:18:41 +0100
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
To: [email-masked]
Subject: [keyassure] Administrivia: Rename the mailing list to [email-masked]

Hi,

I would like to ask the listmaster to rename the mailing list to 
[email-masked] to keep it with sync with the WG name.

Any objections?

I'll keep you posted on the dates, etc. when I know more details.

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

Date: Tue, 01 Feb 2011 15:15:18 +0100
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
To: [email-masked]
Subject: [keyassure] Call for consensus on #1

Hi,

I would like to call for consensus on issue #1.

The consensus would be that the draft-dane-protocol would define lookup 
on TLSA records as query for a name prefixed with a port or port and proto.

Possible examples (no preference here for issue #1):
  _443.www.example.com
  _443._tcp.example.com
  _tcp_443.example.com.

I will open separate issue# for the particular solution for querying 
(proto or not, fallback or not, etc.), since I don't think we have 
consensus on that yet.  (And I think we should step forward constantly 
even in small steps.)

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: Matt McCutchen <[email-masked]>
To: keyassure <[email-masked]>
Date: Tue, 01 Feb 2011 09:01:23 -0500
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

On Thu, 2011-01-27 at 12:14 -0500, Warren Kumari wrote: 
> Ondrej and I would like to call #1 (and #17) soon, but would like to  
> get a little clarification / restatement of folks views...
> 
> When looking up TLSA records, would folk prefer querying for:
> 
> 1: Just a hostname (mail.example.com) and pick from the returned  
> records.

Let's subdivide:
1a: Each record is acceptable for any port.
1b: Each record says which port it is for. 

> 2: Looking up a name prefixed with a port (_443.www.example.com) or  
> port and proto (_443._tcp.www.example.com).
> An application could optimize beyond this, but this defines what is  
> required to look up.

Philosophically, I prefer 2 including the transport protocol (to spell
everything out) because the client asks for precisely the information it
needs.  Compared to 1b, the different owner names might make it easier
for the various services to automatically administer their own TLSA
records (as Phill envisioned) without stepping on each other.

The only problem is making 2 work with CNAMEs and wildcards, the same
problem faced by SRV.  (IMO, it's a pity this interaction wasn't
specified the way we want originally, but there might be other
considerations I'm not aware of.)  Phill described some grand plans.  I
would just propose that the client check for CNAME at www.example.com or
TLSA at _443._tcp.www.example.com in unspecified order (they should not
both exist), and if a CNAME at www.example.com is found, query the
prefixed version of the target name.  The client would not honor a CNAME
at _443._tcp.www.example.com.  DNS admins who want to apply TLSA to a
wildcard set of host names can use a wildcard CNAME first and then put
the TLSA at the target name.

I am unhappy with 1a.  I wouldn't like to build the assumption that
ports at the same host name are at the same security level into DANE,
and I really don't see what's so hard about specifying the port on which
you are going to use the certificate.  And quite apart from security
levels, binding a different certificate to each port is the only way to
prevent connection diversion among ports at the TLS level (where it
should be prevented) since SNI currently does not do ports.

-- 
Matt

Date: Tue, 1 Feb 2011 13:22:59 +0200
From: Ilari Liusvaara <[email-masked]>
To: =?utf-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
Sender: Ilari Liusvaara <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

On Tue, Feb 01, 2011 at 11:14:57AM +0100, Ond=C5=99ej Sur=C3=BD wrote:
> On 31.1.2011 17:29, Simon Josefsson wrote:
> >Ond=C5=99ej Sur=C3=BD<[email-masked]>  writes:
> >
> >>Combination of 1. and 2.:
> >>5. Prefacing the host name with a service name and a port number:
> >>(_110._pop.mail.example.com).
> >>
> >>6. Same as 5, but with a protocol selector:
> >>(f.e. tcp_110._pop.mail.example.com)
> >
> >I dislike any solution that uses service names (the "_pop"), because I
> >haven't seen any explanation what purpose it would serve.  Is there a
> >use case for it?
>=20
> You can have multiple https and multiple pop3s running on the same
> machine?  But you're probably right.

To be useful that would require multiple services with distinct keys
sharing the same port(!). Without explicit muxing like tcpmux (tcp/1;
who uses that anymore???) it would be seriously fragile (or downright
impossible) with many service pairs (server goes first services,
services that can't be reliably be sniffed).

If you have say 2 HTTPSs and 2 POP3Ss, you could stuff them to say,
ports 80 (HTTP vs. TLS can be sniffed), 443 for HTTPS and
995 and 996 for POP3S.

That would give four ports, 80, 443, 995 and 996 with no conflicts
that would need service labels.

So I don't see any need for service labels unless supporting seriously
obsolete stuff like tcpmux. Port labels are enough.

-Ilari

Date: Tue, 01 Feb 2011 11:14:57 +0100
From: =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

On 31.1.2011 17:29, Simon Josefsson wrote:
> Ond�ej Sur�<[email-masked]>  writes:
>
>> Combination of 1. and 2.:
>> 5. Prefacing the host name with a service name and a port number:
>> (_110._pop.mail.example.com).
>>
>> 6. Same as 5, but with a protocol selector:
>> (f.e. tcp_110._pop.mail.example.com)
>
> I dislike any solution that uses service names (the "_pop"), because I
> haven't seen any explanation what purpose it would serve.  Is there a
> use case for it?

You can have multiple https and multiple pop3s running on the same 
machine?  But you're probably right.

>> And this is an idea I got while reading the archive:
>> 7. Prefacing the host name with a service name and a port number with
>> fallback on every level, ie. all those are valid and looked up and
>> used in this order:
>>   _110._pop.mail.example.com IN TLSA
>>   _pop.mail.example.com IN TLSA
>>   mail.example.com IN TLSA
>>
>> That way we can have quite good flexibility while not making things
>> too complicated (ie. I am able to specify separate certificate for
>> important service running on _443.http.www.example.com and having
>> www.example.com IN TLSA<snake_oil_cert>  for all other certificates at
>> the host name).
>
> This adds roundtrips unless implementations do queries in parallel, and
> the latter creates some extra network packets.  Network traffic is
> cheap, so I kind of like it.

/me too :)

> However I fear some implementations will
> skip the (_443.www.example.com,IN,TLS) query and go directly for the
> (www.example.com,IN,TLS) which kind of destroys the flexibility.

The bad thing is that it doesn't only destroy flexibility, but it also 
destroys the security (the _443.www would be authenticated by www TLSA 
record).  Is this fear of bad implementation shared among other members 
of the DANE?  Isn't that more of issue a security warning, a CVE number 
and force the vendor to fix it?

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

Date: Tue, 01 Feb 2011 11:10:46 +0100
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Don't modify DNS server algorithms

On 31.1.2011 21:05, John Gilmore wrote:
> Anyone who designs a simple new protocol on the theory that we'll have
> to modify the algorithms in all the DNS servers is pushing their luck.

I don't think that anybody said that the modification of the DNS 
server-side algorithm is a requirement for DANE work.  It could be 
viewed as a nice-to-have optimization (which is same for A+AAAA or any 
other attempts which didn't go through the dnsext), but that's really an 
DNSEXT work and we should not even slightly assume that this will ever 
happen.  (But yes, EDNSx which would allow multiple queries (f.e. just 
in-the-bailiwick) would be nice to have, but it also would have to be 
very carefully designed.)

Anyway everybody please let's stick to the topic which is Issue#1, thanks.

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: "dane issue tracker" <[email-masked]>
Auto-Submitted: auto-generated
To: [email-masked]
Date: Sun, 27 Feb 2011 16:41:35 -0000
Cc: [email-masked]
Subject: Re: [keyassure] [dane] #19: Format for TLSA DNS lookup.

#19: Format for TLSA DNS lookup.

Changes (by warren@…):

  * status:  new => closed
  * resolution:  => fixed

-- 
-------------------------------+--------------------------------------------
 Reporter:  warren@…           |        Owner:        
     Type:  enhancement        |       Status:  closed
 Priority:  major              |    Milestone:        
Component:  protocol           |      Version:        
 Severity:  -                  |   Resolution:  fixed 
 Keywords:                     |  
-------------------------------+--------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/dane/trac/ticket/19#comment:2>
dane <http://tools.ietf.org/dane/>