Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services
From: Martin Rex <[email-masked]>
To: [email-masked]
Date: Tue, 1 Feb 2011 01:45:26 +0100 (MET)
List-Id: Key Assurance With DNSSEC <keyassure.ietf.org>

Stephen Farrell wrote:
>
> I think I'd go for some form of #2, done in any reasonable way.

I also find some form of #2 the most appealing.

-Martin

Date: Mon, 31 Jan 2011 15:30:17 -0500
From: Andrew Sullivan <[email-masked]>
To: Paul Wouters <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services	under one domain name.

On Mon, Jan 31, 2011 at 02:25:38PM -0500, Paul Wouters wrote:
> There are those who believe some method of obtaining cryptographicly
> relevant material along with the A/AAAA record, meta-RR or EDNS) is
> extremely useful.

I agree that it is extremely useful.  Unfortunately, previous efforts
to cause automatic combinations to come out of the DNS have not proven
successful.  In particular,

> I'd be interested in knowing more about these old attempts. Do you have
> a good set of google keywords for me?

the most obvious example has been the repeated attempts to get A and
AAAA records in a single query.  Rather vexingly, I can't point you to
archives any more because the person who controls the old namedroppers
archives has apparently taken them offline (or at least, had last time
I checked).

>
>> (It is a conceivably different requirement to get the A and AAAA to
>> come along with a new kind of record, but it's certainly not
>> assignment by espert review.)
>
> This did not entirely parse, but I guess I would not object to getting

Sorry.  The expert review process for RRTYPE assignment explictly
excludes any special server-side processing from scope.  That will
emphatically be required any time returning one RR automatically
entails returning some other RR.

Something that is important to remember here is the effect of caches.
If you have some record (say, an A record) that could be in cache, and
then you are asked for a different RRTYPE that would entail returning
the A record at the same time, what do you do with the TTLs?  What
happens at the cache if you have the existing cached A and have to go
get something else?  

A

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

To: Simon Josefsson <[email-masked]>
Comments: In-reply-to Simon Josefsson <[email-masked]> message dated "Mon, 31 Jan 2011 17:38:19 +0100."
Date: Mon, 31 Jan 2011 12:05:15 -0800
From: John Gilmore <[email-masked]>
Cc: [email-masked]
Subject: [keyassure]  Don't modify DNS server algorithms

> > People seem to forget that at some not too far distant point in the
> > future, we want these records to come along with our A record lookup.
> > Having them not at the same RRlabel is going to make that next to
> > impossible.
> 
> Why?
> 
> Compare how DNSSEC modified DNS to ship other records along with A
> record lookups, and those records aren't always on the same RRlabel as
> the query.  So I don't immediately see why it would be next to
> impossible to do something similar.

DNSSEC was a revision of the DNS protocols themselves.  DANE is a
revision of other protocols (like TLS or IPSEC) to use information
pulled from the DNS.

Don't forget that the DNS is the glue that binds the Internet to
humans.  Armchair protocol designers can make DNS implementations
arbitrary complicated and buggy (and there was too much of that in
DNSSEC, which is why it took a decade).  It's quite amazing that it
scaled up to still work in 2011.  Its 1983 design (RFC 881-883) by
Paul Mockapetris and Jon Postel handled hundreds -- hundreds! -- of
hostnames, replacing a flat file (the "hosts table") that was updated
weekly and distributed to every machine on the ARPAnet via FTP.  They
note:

      In the long run the Internet will become too complex and change
      too fast to keep a master table of all the hosts.  At some point
      the master table will be reduced to simply the entries for the
      domain servers for the top level domains.  By this time all normal
      translation of host names into addresses should take place by
      consulting domain servers.

DNS has managed to survive for almost 30 years, coping with the gentle
administration of SRI, the cluelessness of Network Solutions, the
avarice of SAIC, the nepotism of ICANN, and the sewage of domain
speculators.  DNSSEC severely challenged it, and we still don't know
if DNSSEC will scale up to full-Internet size while providing the high
performance and high reliability that the world is used to.  Adding
more complications risks the whole house of cards.  What DNS really
needs is a multi-decade complete redesign from the ground up.  When it
was designed, distributed databases did not exist -- because there
were no networks to distribute them on.  A new design on database
principles, without centralized control, like the routing system or
the USENET, could eliminate a bunch of parasites and power-seekers and
permit the DNS to survive for the next hundred years.

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.
(And vastly delaying the widespread implementation of their protocol.)
If that's what's going down in this committee, be very prepared to
justify exactly why you can't do what you need to do by just defining
a record type or two, like everybody else does.  And make sure that
the "improvement" you think you're making to the DNS is sufficiently
general that it will improve the next dozen protocols, rather than
just your own.

	John Gilmore
	(who implemented the original KEY and SIG records in BIND)

Date: Mon, 31 Jan 2011 14:25:38 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Andrew Sullivan <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

On Mon, 31 Jan 2011, Andrew Sullivan wrote:

> On Mon, Jan 31, 2011 at 11:22:37AM -0500, Paul Wouters wrote:
>> People seem to forget that at some not too far distant point in the future,
>> we want these records to come along with our A record lookup.
>
> I apologise for being a little (!) disengaged, but was there a plan
> for getting records to "come along" with an A record lookup that did
> not involve special server side processing?

Sorry, I should not have used "we" here.

There are those who believe some method of obtaining cryptographicly
relevant material along with the A/AAAA record, meta-RR or EDNS) is
extremely useful. This includes anonymized circuits, such as "tor"
that have a very latent setup cost.

> Because getting things to
> "come along" with A record lookups involves reformatting the Internet,
> or at least the DNS, and previous efforts in that rut have not been
> notable for their success.

I'd be interested in knowing more about these old attempts. Do you have
a good set of google keywords for me?

> (It is a conceivably different requirement to get the A and AAAA to
> come along with a new kind of record, but it's certainly not
> assignment by espert review.)

This did not entirely parse, but I guess I would not object to getting
an A/AAAA record along with TLSA, though then we also have to look at
HASTLS, and what to do when the A/AAAA does not exist. But I guess this
is getting of-topic for the discussion of "under one domain name or not",
apart from the "it's a good and simple design that works for (AFAIK) all
cases, and will make any future changes easier".

Paul

From: "George Barwood" <[email-masked]>
To: "Paul Wouters" <[email-masked]>, =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
Date: Mon, 31 Jan 2011 17:14:49 -0000
Cc: [email-masked]
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

Date: Mon, 31 Jan 2011 11:38:46 -0500
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services	under one domain name.

On Mon, Jan 31, 2011 at 11:22:37AM -0500, Paul Wouters wrote:
> People seem to forget that at some not too far distant point in the future,
> we want these records to come along with our A record lookup. 

I apologise for being a little (!) disengaged, but was there a plan
for getting records to "come along" with an A record lookup that did
not involve special server side processing?  Because getting things to
"come along" with A record lookups involves reformatting the Internet,
or at least the DNS, and previous efforts in that rut have not been
notable for their success.

(It is a conceivably different requirement to get the A and AAAA to
come along with a new kind of record, but it's certainly not
assignment by espert review.)

A

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

From: Simon Josefsson <[email-masked]>
To: Paul Wouters <[email-masked]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Mon, 31 Jan 2011 17:38:19 +0100
Cc: [email-masked]
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

Paul Wouters <[email-masked]> writes:

> People seem to forget that at some not too far distant point in the
> future, we want these records to come along with our A record lookup.
> Having them not at the same RRlabel is going to make that next to
> impossible.

Why?

Compare how DNSSEC modified DNS to ship other records along with A
record lookups, and those records aren't always on the same RRlabel as
the query.  So I don't immediately see why it would be next to
impossible to do something similar.

/Simon

From: Simon Josefsson <[email-masked]>
To: =?iso-8859-2?Q?Ond=F8ej_Sur=FD?= <[email-masked]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Mon, 31 Jan 2011 17:29:46 +0100
Cc: [email-masked]
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

Ond=F8ej Sur=FD <[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?

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

/Simon

Date: Mon, 31 Jan 2011 11:22:37 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

On Mon, 31 Jan 2011, OndÅ™ej SurÃ½ wrote:

> So to summary new suggestions which popped up on the list.
>
> 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)
>
> 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).

People seem to forget that at some not too far distant point in the future,
we want these records to come along with our A record lookup. Having them
not at the same RRlabel is going to make that next to impossible. The
*.foo.www.xelerance.com constructs all could signify a zone cut, so they
would all get dropped as out-of-bailiwick. Adding NSEC/NSEC3 for those
would really just move the problem of locating the right TLSA for the
right port to the issue of locating the right NSEC/NSEC3 for the lack of
a certain *._*.www.example.com record.

If you have two widely different security requirements, why are they on
the same FQDN? They can be on the same host with different FQDNs.

As previously listed examples of super secure website and snakeoil cert
for monitoring, you can simple add "monitoring.www.example.com" FQDN,
put its TLSA cert there and avoid this issue completely.

I still strongly believe in the simple TLSA case without port or protocol
specifiers and SRV like sub zones.

Paul

Date: Mon, 31 Jan 2011 16:53:14 +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 17.1.2011 21:46, Warren Kumari wrote:
> I was hoping that would be able to stick to one open item at a time but
> the discussions on #17 (Should the first doc be TLS only or try be
> everything to everyone?) has wrapped directly to this issue, so:
>
> I'm opening up Issue #1 (Deal with multiple TLS-based services under one
> domain name (http://trac.tools.ietf.org/wg/dane/trac/ticket/1))
> [ Dons frock, flaps hands, twirls the incense burner three times to the
> left, presses button to make water squirt out of daisy add releases the
> 12 doves -- now it is official ]
> -----
> Description:
> How to deal with multiple TLS-based services running under one domain
> name, such as a POP, IMAP, and SMTP server all running on mail.example.com.
>
> Suggestions so far include:
> 1. Prefacing the host name with a service name (_pop.mail.example.com)
> 2. Prefacing the host name with a port number (_110.mail.example.com)
> 3. Returning a set of records that contain port numbers in the response.
> 4. SRV / ESRV

So to summary new suggestions which popped up on the list.

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)

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

8. Same as 7. but with a protocol selector

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

Sender: [email-masked]
Date: Sun, 30 Jan 2011 14:57:25 -0800
From: Zack Weinberg <[email-masked]>
To: Paul Wouters <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

On Sun, Jan 30, 2011 at 1:22 PM, Paul Wouters <[email-masked]> wrote:
> On Sun, 30 Jan 2011, Simon Josefsson wrote:
>
>> Good example. =C2=A0This is even more common than my earlier examples, s=
o I
>> even more strongly believe that any solution that doesn't permit
>> different certs on different ports/protocols won't fly.
>
> Note that option 1 DOES permit different certs on different ports and
> protocols. It is only the lookup that is different, and option 2 only
> protects again a compromised server exchanging different security zone
> certificates on the same server onto different services. I don't think
> this really buys you anything on a compromised server.

Yes.  I advocate option 2 not for security reasons, but because it
will make life easier for the client (which does not have to sort
through many certs, it just has to say which one it needs) and cut
down on response size.

zw

Date: Sun, 30 Jan 2011 13:55:16 -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 1/30/11 1:29 PM, Simon Josefsson wrote:
> Paul Wouters<[email-masked]>  writes:
>
>> On Sun, 30 Jan 2011, Simon Josefsson wrote:
>>
>>> Good example.  This is even more common than my earlier examples, so I
>>> even more strongly believe that any solution that doesn't permit
>>> different certs on different ports/protocols won't fly.
>>
>> Note that option 1 DOES permit different certs on different ports and
>> protocols. It is only the lookup that is different, and option 2 only
>> protects again a compromised server exchanging different security zone
>> certificates on the same server onto different services. I don't think
>> this really buys you anything on a compromised server.
>
> If you don't see the problem, think about this scenario -- if I have one
> important service running on port 443 on, say, www.cacert.org, with the
> private key safely stored on a HSM, and I also have one weak and
> important web interface running on port 4711 for some monitoring
> purpose, with a snake oil cert, and I create TLSA records to cover both
> certificates and put them in the DNS, it means that anyone stealing the
> snake oil private key can masquerade as www.cacert.org if clients only
> validate the TLSA records.

Warren did a bad job of stating #1. It is not "all records are the 
same", but instead "each record says what port it is for". There is no 
difference in security properties between #1 and #2: it is all about 
preference for how the record is requested and its format. #1 has a 
simpler request (no port number) but an additional part of the response 
(includes the port number); #1 has an additional part of the request 
(includes the port number) but a simpler response (no port number). 
That's all.

From: Simon Josefsson <[email-masked]>
To: Paul Wouters <[email-masked]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Sun, 30 Jan 2011 22:32:09 +0100
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

Simon Josefsson <[email-masked]> writes:

> Paul Wouters <[email-masked]> writes:
>
>> On Sun, 30 Jan 2011, Simon Josefsson wrote:
>>
>>> Good example.  This is even more common than my earlier examples, so I
>>> even more strongly believe that any solution that doesn't permit
>>> different certs on different ports/protocols won't fly.
>>
>> Note that option 1 DOES permit different certs on different ports and
>> protocols. It is only the lookup that is different, and option 2 only
>> protects again a compromised server exchanging different security zone
>> certificates on the same server onto different services. I don't think
>> this really buys you anything on a compromised server.
>
> If you don't see the problem, think about this scenario -- if I have one
> important service running on port 443 on, say, www.cacert.org, with the
> private key safely stored on a HSM, and I also have one weak and
> important web interface running on port 4711 for some monitoring
  ^^

That should be 'UNimportant', of course...

/Simon

> purpose, with a snake oil cert, and I create TLSA records to cover both
> certificates and put them in the DNS, it means that anyone stealing the
> snake oil private key can masquerade as www.cacert.org if clients only
> validate the TLSA records.
>
> /Simon
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

From: Simon Josefsson <[email-masked]>
To: Paul Wouters <[email-masked]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Sun, 30 Jan 2011 22:29:20 +0100
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

Paul Wouters <[email-masked]> writes:

> On Sun, 30 Jan 2011, Simon Josefsson wrote:
>
>> Good example.  This is even more common than my earlier examples, so I
>> even more strongly believe that any solution that doesn't permit
>> different certs on different ports/protocols won't fly.
>
> Note that option 1 DOES permit different certs on different ports and
> protocols. It is only the lookup that is different, and option 2 only
> protects again a compromised server exchanging different security zone
> certificates on the same server onto different services. I don't think
> this really buys you anything on a compromised server.

If you don't see the problem, think about this scenario -- if I have one
important service running on port 443 on, say, www.cacert.org, with the
private key safely stored on a HSM, and I also have one weak and
important web interface running on port 4711 for some monitoring
purpose, with a snake oil cert, and I create TLSA records to cover both
certificates and put them in the DNS, it means that anyone stealing the
snake oil private key can masquerade as www.cacert.org if clients only
validate the TLSA records.

/Simon

Date: Sun, 30 Jan 2011 16:22:56 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

On Sun, 30 Jan 2011, Simon Josefsson wrote:

> Good example.  This is even more common than my earlier examples, so I
> even more strongly believe that any solution that doesn't permit
> different certs on different ports/protocols won't fly.

Note that option 1 DOES permit different certs on different ports and
protocols. It is only the lookup that is different, and option 2 only
protects again a compromised server exchanging different security zone
certificates on the same server onto different services. I don't think
this really buys you anything on a compromised server.

Another case could be where an IP/hostname is presenting different
certs for different ports, where the ports are forwarded to separate hosts.
But again, if the portforwarded host or one of the port forwarded hosts is
compromised, I doubt this protection will buy you much. (If it would, the
attacker would block it and their own bogus cert and hope for foolush users)

Paul

From: Simon Josefsson <[email-masked]>
To: Zack Weinberg <[email-masked]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Sun, 30 Jan 2011 22:08:31 +0100
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

Zack Weinberg <[email-masked]> writes:

> I like the idea of a port-selection prefix on the domain name.  I can
> speak only to the Web perspective, but it is fairly common to run two
> separate HTTP(S) servers on different ports; when this is done, the
> browser treats them as disjoint security principals for most purposes,
> so administrators may want to use separate certificates for them.
> Thus, some means of associating two or more certs with the same domain
> is desirable even if the machine is exclusively "a web server".

Good example.  This is even more common than my earlier examples, so I
even more strongly believe that any solution that doesn't permit
different certs on different ports/protocols won't fly.

> I am _opposed_ to any scheme that ties deployment of TLSA to
> deployment of service-discovery records; I like service discovery in
> principle, but I don't want to add to the administrative burden of
> deploying TLSA, especially for protocols that currently work without
> service discovery, like HTTP.

+1

I think tying TLSA to SRV is a good way to never see TLSA used in the
real world.

/Simon

Date: Sun, 30 Jan 2011 15:40:31 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Zack Weinberg <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

On Sun, 30 Jan 2011, Zack Weinberg wrote:

> I prefer a port-selection prefix to returning multiple TLSA records
> for a lookup on the bare domain name because that keeps DNS response
> sizes down and means the client doesn't have to sort out which one it
> needs.

the client needs to understand that anyway, in case you are rolling a
cert, and you briefly have to have two TLSA records.

Paul

Sender: [email-masked]
Date: Sun, 30 Jan 2011 11:30:49 -0800
From: Zack Weinberg <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

On Sun, Jan 30, 2011 at 1:54 AM, Jakob Schlyter <[email-masked]> wrote:
> 28 jan 2011 kl. 18:22 skrev Simon Josefsson <[email-masked]>:
>
>> Paul asked me to clarify my preference and if TLS is the only supported
>> protocol I prefer this approach:
>>
>> _110.mail.example.com
>>
>> where _110 is the port number.
>
> If we're going to do a port selector, I'd prefer the scheme above and I believe
> we can omit the protocol selector and safely assume that the same key
> association is used for all protocols listening on a single port.

(This is not a response to Jakob specifically.)

I like the idea of a port-selection prefix on the domain name.  I can
speak only to the Web perspective, but it is fairly common to run two
separate HTTP(S) servers on different ports; when this is done, the
browser treats them as disjoint security principals for most purposes,
so administrators may want to use separate certificates for them.
Thus, some means of associating two or more certs with the same domain
is desirable even if the machine is exclusively "a web server".

I prefer a port-selection prefix to returning multiple TLSA records
for a lookup on the bare domain name because that keeps DNS response
sizes down and means the client doesn't have to sort out which one it
needs.

I do not think it is useful to include the protocol in the prefix as
well as the port.  I have no opinion as to whether it is useful to
include the transport name (TCP, UDP, SCTP, etc).

I am _opposed_ to any scheme that ties deployment of TLSA to
deployment of service-discovery records; I like service discovery in
principle, but I don't want to add to the administrative burden of
deploying TLSA, especially for protocols that currently work without
service discovery, like HTTP.  (For protocols that already do use SRV
or MX or whatever, like SMTP, it is of course desirable for TLSA to
play well with those schemes, but I don't think I'm qualified to
figure out how that needs to work.)

zw

From: Jakob Schlyter <[email-masked]>
Date: Sun, 30 Jan 2011 10:54:16 +0100
To: Simon Josefsson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

28 jan 2011 kl. 18:22 skrev Simon Josefsson <[email-masked]>:

> Paul asked me to clarify my preference and if TLS is the only supported
> protocol I prefer this approach:
>=20
> _110.mail.example.com
>=20
> where _110 is the port number.

If we're going to do a port selector, I'd prefer the scheme above and I beli=
eve we can omit the protocol selector and safely assume that the same key as=
sociation is used for all protocols listening on a single port.=20

  Jakob

Date: Sun, 30 Jan 2011 11:34:57 +0200
From: Ilari Liusvaara <[email-masked]>
To: Simon Josefsson <[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 Fri, Jan 28, 2011 at 06:22:05PM +0100, Simon Josefsson wrote:
> 
> Paul asked me to clarify my preference and if TLS is the only supported
> protocol I prefer this approach:
> 
> _110.mail.example.com
> 
> where _110 is the port number.
> 
> If DTLS and TLS are the only supported protocols I would prefer this
> approach:
> 
> tcp_110.mail.example.com (TLS)
> udp_110.mail.example.com (DTLS)

Note that TLS can be carried over SCTP as well as TCP (there's even an
Standards Track RFC about that).

Now, SCTP is not commonly used (oft-cited reason is PAT, which will
hopefully go away with IPv6).

-Ilari

Date: Sat, 29 Jan 2011 18:20:07 +0000
From: Stephen Farrell <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

I think I'd go for some form of #2, done in any reasonable way.

One additional reason for that is that there could be multiple,
differently trusted, services on the same host (e.g. a web service
doing foo on port 80, with a foo-admin service on port 81 or
something). Not including the service info in the DANE protocol
somewhere could allow for foo to spoof as foo-admin in some cases.
I've no idea if there are things actually deployed like that now
but I do recall systems like that some years ago.

S.

Date: Sat, 29 Jan 2011 11:51:48 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

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

Is NAPTR really poorly understood, or just poorly designed?

Putting REs into the DNS makes me feel really uncomfortable. Might as well
have javascript in there.

Human administrators can manage NAPTR records if they understand what they
are doing. Managing them automatically looks likely to me to be impossible.

So NAPTR can possibly be made to work as a means of achieving the original
goal of enabling resolution of URNs. It is not what I would want to use for
service discovery.

SRV and URI appear to me to be much closer to what we need here.

On Sat, Jan 29, 2011 at 10:24 AM, Paul Hoffman <[email-masked]>wrote:

> On 1/29/11 4:03 AM, Lawrence Conroy wrote:
>
>> On 28 Jan 2011, at 18:22, James Cloos wrote:
>>
>>> "WK" == Warren Kumari<[email-masked]>  writes:
>>>>>>>>
>>>>>>>
>>> WK>  Ondrej and I would like to call #1 (and #17) soon, but would like to
>>> WK>  get a little clarification / restatement of folks views...
>>>
>>> WK>  When looking up TLSA records, would folk prefer querying for:
>>>
>>> WK>  1: Just a hostname (mail.example.com) and pick from the returned
>>> WK>  records.
>>>
>>> We should recommend doing an NAPTR lookup on the hostname and using its
>>> results to choose what A,AAAA,SRV,TLSA,etc RRs to look for.
>>>
>>> -JimC
>>>
>>
>> To which I reply:
>>   If you're going to recommend NAPTR, then WHAT kind of NAPTR?
>> unaptr [RFC4848], snaptr [RFC3958], a new DDDS Application, ...
>> If you're going to hunt A/AAAA as well as SRV and others I *guess* UNAPTR.
>> I'm really not sure using UNAPTR is doing anyone a favour, but if you
>> must, you need to spell it out.
>> all the best,
>>
>
> ...or don't do this at all. If we want to make certificate associations
> widely deployed, requiring that it be tied to a protocol that is poorly
> understood and barely deployed seems like a bad idea.
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

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

Is NAPTR really poorly understood, or just poorly designed?<div><br></div><=
div>Putting REs into the DNS makes me feel really uncomfortable. Might as w=
ell have javascript in there.</div><div><br></div><div>Human administrators=
 can manage NAPTR records if they understand what they are doing. Managing =
them automatically looks likely to me to be impossible.</div>
<div><br></div><div>So NAPTR can possibly be made to work as a means of ach=
ieving the original goal of enabling resolution of URNs. It is not what I w=
ould want to use for service discovery.</div><div><br></div><div><br></div>
<div>SRV and URI appear to me to be much closer to what we need here.</div>=
<div><br></div><div><div><br><div class=3D"gmail_quote">On Sat, Jan 29, 201=
1 at 10:24 AM, Paul Hoffman <span dir=3D"ltr">&lt;<a href=3D"mailto:paul.ho=
[email-masked]">[email-masked]</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;"><div class=3D"im">On 1/29/11 4:03 AM, Lawre=
nce Conroy wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On 28 Jan 2011, at 18:22, James Cloos wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">
<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"><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">

&quot;WK&quot; =3D=3D Warren Kumari&lt;<a href=3D"mailto:[email-masked]"=
 target=3D"_blank">[email-masked]</a>&gt; =A0writes:<br>
</blockquote></blockquote></blockquote></blockquote></blockquote>
<br>
WK&gt; =A0Ondrej and I would like to call #1 (and #17) soon, but would like=
 to<br>
WK&gt; =A0get a little clarification / restatement of folks views...<br>
<br>
WK&gt; =A0When looking up TLSA records, would folk prefer querying for:<br>
<br>
WK&gt; =A01: Just a hostname (<a href=3D"http://mail.example.com" target=3D=
"_blank">mail.example.com</a>) and pick from the returned<br>
WK&gt; =A0records.<br>
<br>
We should recommend doing an NAPTR lookup on the hostname and using its<br>
results to choose what A,AAAA,SRV,TLSA,etc RRs to look for.<br>
<br>
-JimC<br>
</blockquote>
<br>
To which I reply:<br>
 =A0 If you&#39;re going to recommend NAPTR, then WHAT kind of NAPTR?<br>
unaptr [RFC4848], snaptr [RFC3958], a new DDDS Application, ...<br>
If you&#39;re going to hunt A/AAAA as well as SRV and others I *guess* UNAP=
TR.<br>
I&#39;m really not sure using UNAPTR is doing anyone a favour, but if you m=
ust, you need to spell it out.<br>
all the best,<br>
</blockquote>
<br></div>
...or don&#39;t do this at all. If we want to make certificate associations=
 widely deployed, requiring that it be tied to a protocol that is poorly un=
derstood and barely deployed seems like a bad idea.<div><div></div><div cla=
ss=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></div>

--0016e6434658a73116049afeff1c--

Date: Sat, 29 Jan 2011 07:24:00 -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 1/29/11 4:03 AM, Lawrence Conroy wrote:
> On 28 Jan 2011, at 18:22, James Cloos wrote:
>>>>>>> "WK" == Warren Kumari<[email-masked]>  writes:
>>
>> WK>  Ondrej and I would like to call #1 (and #17) soon, but would like to
>> WK>  get a little clarification / restatement of folks views...
>>
>> WK>  When looking up TLSA records, would folk prefer querying for:
>>
>> WK>  1: Just a hostname (mail.example.com) and pick from the returned
>> WK>  records.
>>
>> We should recommend doing an NAPTR lookup on the hostname and using its
>> results to choose what A,AAAA,SRV,TLSA,etc RRs to look for.
>>
>> -JimC
>
> To which I reply:
>    If you're going to recommend NAPTR, then WHAT kind of NAPTR?
> unaptr [RFC4848], snaptr [RFC3958], a new DDDS Application, ...
> If you're going to hunt A/AAAA as well as SRV and others I *guess* UNAPTR.
> I'm really not sure using UNAPTR is doing anyone a favour, but if you must, you need to spell it out.
> all the best,

...or don't do this at all. If we want to make certificate associations 
widely deployed, requiring that it be tied to a protocol that is poorly 
understood and barely deployed seems like a bad idea.

From: Lawrence Conroy <[email-masked]>
Date: Sat, 29 Jan 2011 12:03:52 +0000
To: James Cloos <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

On 28 Jan 2011, at 18:22, James Cloos wrote:
>>>>>> "WK" =3D=3D Warren Kumari <[email-masked]> writes:
>=20
> WK> Ondrej and I would like to call #1 (and #17) soon, but would like =
to
> WK> get a little clarification / restatement of folks views...
>=20
> WK> When looking up TLSA records, would folk prefer querying for:
>=20
> WK> 1: Just a hostname (mail.example.com) and pick from the returned
> WK> records.
>=20
> We should recommend doing an NAPTR lookup on the hostname and using =
its
> results to choose what A,AAAA,SRV,TLSA,etc RRs to look for.
>=20
> -JimC

To which I reply:
  If you're going to recommend NAPTR, then WHAT kind of NAPTR?
unaptr [RFC4848], snaptr [RFC3958], a new DDDS Application, ...
If you're going to hunt A/AAAA as well as SRV and others I *guess* =
UNAPTR.
I'm really not sure using UNAPTR is doing anyone a favour, but if you =
must, you need to spell it out.
all the best,
  Lawrence=

From: Simon Josefsson <[email-masked]>
To: Warren Kumari <[email-masked]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Fri, 28 Jan 2011 19:57:01 +0100
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] Call for consensus on #17

Warren Kumari <[email-masked]> writes:

> On Jan 28, 2011, at 1:14 PM, Paul Hoffman wrote:
>
>> On 1/28/11 9:24 AM, Simon Josefsson wrote:
>>> Ond=F8ej Sur=FD<[email-masked]>  writes:
>>>
>>>> Hi all,
>>>>
>>>> upon discussion with my fellow co-chair I hereby call for
>>>> consensus on
>>>> issue #17.
>>>>
>>>> The consensus would be that the initial document
>>>> (draft-ietf-dane-protocol) would support only TLS.
>>>
>>> Does this exclude DTLS?
>
> No... Good catch though!
>
> Apologies for not being clearer -- the document uses the term TLS to
> refer to both TLS and DTLS, and we have fallen into doing the same
> thing.

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

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

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

/Simon

From: James Cloos <[email-masked]>
To: [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, 28 Jan 2011 13:22:48 -0500
Lines: 16
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

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

WK> Ondrej and I would like to call #1 (and #17) soon, but would like to
WK> get a little clarification / restatement of folks views...

WK> When looking up TLSA records, would folk prefer querying for:

WK> 1: Just a hostname (mail.example.com) and pick from the returned
WK> records.

We should recommend doing an NAPTR lookup on the hostname and using its
results to choose what A,AAAA,SRV,TLSA,etc RRs to look for.

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

From: Warren Kumari <[email-masked]>
To: Paul Hoffman <[email-masked]>
Date: Fri, 28 Jan 2011 13:26:34 -0500
Cc: [email-masked]
Subject: Re: [keyassure] Call for consensus on #17

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

> On 1/28/11 9:24 AM, Simon Josefsson wrote:
>> Ond=F8ej Sur=FD<[email-masked]>  writes:
>>
>>> Hi all,
>>>
>>> upon discussion with my fellow co-chair I hereby call for =20
>>> consensus on
>>> issue #17.
>>>
>>> The consensus would be that the initial document
>>> (draft-ietf-dane-protocol) would support only TLS.
>>
>> Does this exclude DTLS?

No... Good catch though!

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

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

>>  DTLS is not the same protocol as TLS.
>
> DTLS is clearly and completely covered in every WG draft so far. If =20=

> it is not clear, let the authors know; that would be an error on our =20=

> part.

Nope, I believe it is perfectly clear in the doc (clear enough that I =20=

automatically see the implied DTLS)

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

Date: Fri, 28 Jan 2011 10:14:50 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Call for consensus on #17

On 1/28/11 9:24 AM, Simon Josefsson wrote:
> Ondøej Surý<[email-masked]>  writes:
>
>> Hi all,
>>
>> upon discussion with my fellow co-chair I hereby call for consensus on
>> issue #17.
>>
>> The consensus would be that the initial document
>> (draft-ietf-dane-protocol) would support only TLS.
>
> Does this exclude DTLS?  DTLS is not the same protocol as TLS.

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

Date: Fri, 28 Jan 2011 09:30:57 -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 1/27/11 9:14 AM, 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.
>
> 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.

I prefer #1, but think #2 is OK. If we go with #2, I prefer that we keep 
the semantics close to SRV, and not combine port and transport type into 
a single label.

From: Simon Josefsson <[email-masked]>
To: =?iso-8859-2?Q?Ond=F8ej_Sur=FD?= <[email-masked]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Fri, 28 Jan 2011 18:24:24 +0100
Cc: [email-masked]
Subject: Re: [keyassure] Call for consensus on #17

Ond=F8ej Sur=FD <[email-masked]> writes:

> Hi all,
>
> upon discussion with my fellow co-chair I hereby call for consensus on
> issue #17.
>
> The consensus would be that the initial document
> (draft-ietf-dane-protocol) would support only TLS.

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

/Simon

From: Simon Josefsson <[email-masked]>
To: Warren Kumari <[email-masked]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Fri, 28 Jan 2011 18:22:05 +0100
Cc: [email-masked]
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

Warren Kumari <[email-masked]> writes:

> I was hoping that would be able to stick to one open item at a time
> but the discussions on #17 (Should the first doc be TLS only or try be
> everything to everyone?) has wrapped directly to this issue, so:
>
> I'm opening up Issue #1 (Deal with multiple TLS-based services under
> one domain name (http://trac.tools.ietf.org/wg/dane/trac/ticket/1))
> [ Dons frock, flaps hands, twirls the incense burner three times to
> the left,  presses button to make water squirt out of daisy add
> releases the 12 doves -- now it is official ]
> -----
> Description:
> How to deal with multiple TLS-based services running under one domain
> name, such as a POP, IMAP, and SMTP server all running on
> mail.example.com.
>
> Suggestions so far include:
> Prefacing the host name with a service name (_pop.mail.example.com)
> Prefacing the host name with a port number (_110.mail.example.com)
> Returning a set of records that contain port numbers in the response.
> SRV / ESRV
>
> -----

Paul asked me to clarify my preference and if TLS is the only supported
protocol I prefer this approach:

_110.mail.example.com

where _110 is the port number.

If DTLS and TLS are the only supported protocols I would prefer this
approach:

tcp_110.mail.example.com (TLS)
udp_110.mail.example.com (DTLS)

/Simon

Date: Fri, 28 Jan 2011 17:32:05 +0100
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
To: [email-masked]
Subject: [keyassure] Call for consensus on #17 (Was: Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious?)

Hi all,

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

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

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

Regards,
Ondrej

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

On 16.1.2011 04:15, Warren Kumari wrote:
> Buoyed by actual progress on getting the first issue resolved, I'm
> proposing that we jump right into... the 17th issue.
>
> Issue #17: Should draft-ietf-dane-protocol support TLS only or be
> more ambitious? (http://trac.tools.ietf.org/wg/dane/trac/ticket/17):
>
> Description: ------- Please note: This is not the "what all protocols
> can / do we want to support" issue. That will be a separate (and
> probably lively!) discussion.
>
> The current version of draft-ietf-dane-protocol is titled "Using
> Secure DNS to Associate Certificates with Domain Names For TLS" and
> first goal / milestone is "First WG draft of standards-track protocol
> for using DNS to associate hosts with keys for TLS and DTLS".
>
> What I would like us to discuss is: Should *this* document simply
> specify how to support TLS and future protocols can be supported by
> saying "TLSA, but interpret field Foo to contain Bar" (or "Similar to
> TLSA, but this different RR, formatted like Baz"). Note that some
> other protocols already have similar RRtypes; for example SSH already
> has SSHFP.
>
> The other alternative would be to make *this* document be much more
> generic and able to support arbitrary key bindings. ------
>
> Getting consensus on this issue soon would be good, as it affects how
> the document is written...

-- 
  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: Simon Josefsson <[email-masked]>
To: =?iso-8859-2?Q?Ond=F8ej_Sur=FD?= <[email-masked]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Fri, 28 Jan 2011 15:34:38 +0100
Cc: [email-masked]
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

Ond=F8ej Sur=FD <[email-masked]> writes:

> On 28.1.2011 09:01, Simon Josefsson wrote:
>> Paul Wouters<[email-masked]>  writes:
>>
>>> On Thu, 27 Jan 2011, 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 recor=
ds.
>>>>
>>>> 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.
>>>
>>> I prefer 1, because in the majority of cases there is just one certifia=
te,
>>> as people tend to use different hostnames for different services
>>> (mail.example.com, www.example.com)
>>
>> I disagree, it is common to have multiple services with different
>> certificates/key on one host -- many people access their mail server
>> through SMTP (port 25), submission (port 587), webmail (https) and
>> possibly other ways (I access e-mail over SSH which can use certificates
>> as well).
>
> Simon,
>
> would honoring SRVNames attribute in cert (for Type 1/2) fix that?
> Ie. have multiple records for mail.example.net, but each with
> different SRVNames attribute inside the cert?

Yes, although it some disadvantages.

Consider this (just an illustration, replace DANE with whatever RR name
we end up with and the hash with whatever data is needed to confirm the
certificate data, and imagine the DNSSEC records around the RRset):

mail.example.net. IN DANE 0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33
mail.example.net. IN DANE 62cdb7020ff920e5aa642c3d4066950dd1f01f4d
mail.example.net. IN DANE aef3a7835277a28da831005c2ae3b919e2076a62
mail.example.net. IN DANE 088e16a1019277b15d58faf0541e11910eb756f6

A client that wants to contact port 443 would need to establish the TLS
session and extract the peer's certificate and hash it and compare it to
all the hashes in the RR.  Only the one succeeding should be further
validated for the SubjectAltName attribute.

Compare instead the following records:

tcp_443.mail.example.net. IN DANE 0beec7b5ea3f0fdbc95d0dd47f3c5bc275da8a33
tcp_25.mail.example.net. IN DANE 62cdb7020ff920e5aa642c3d4066950dd1f01f4d
tcp_587.mail.example.net. IN DANE aef3a7835277a28da831005c2ae3b919e2076a62
tcp_143.mail.example.net. IN DANE 088e16a1019277b15d58faf0541e11910eb756f6

The client connecting to mail.example.net on port 25 could look up
tcp_25.mail.example.net and directly compare that hash with the server
certificate.

Another disadvantage is that this approach requires validation of SAN's
which in turns require ASN.1 and X.509 processing.  With the my
preferred approach, to get trust in a server's certificate, all that is
needed is to hash the certificate and compare with what's in the DNS RR.

> That of course doesn't work for Type 3/4 (CA cert) and for bare keys.

Right.

/Simon

Date: Fri, 28 Jan 2011 15:22:21 +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 28.1.2011 09:01, Simon Josefsson wrote:
> Paul Wouters<[email-masked]>  writes:
>
>> On Thu, 27 Jan 2011, 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.
>>>
>>> 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.
>>
>> I prefer 1, because in the majority of cases there is just one certifiate,
>> as people tend to use different hostnames for different services
>> (mail.example.com, www.example.com)
>
> I disagree, it is common to have multiple services with different
> certificates/key on one host -- many people access their mail server
> through SMTP (port 25), submission (port 587), webmail (https) and
> possibly other ways (I access e-mail over SSH which can use certificates
> as well).

Simon,

would honoring SRVNames attribute in cert (for Type 1/2) fix that?  Ie. 
have multiple records for mail.example.net, but each with different 
SRVNames attribute inside the cert?

That of course doesn't work for Type 3/4 (CA cert) and for bare keys.

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: Fri, 28 Jan 2011 08:27:56 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Warren Kumari <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

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

It is not a question of prefer, it is a question of what you can get the DNS
infrastructure to do if you are not going to attempt to change the rules or
change DNSSEC.

DNS has wildcards and alias records (CNAME, DNAME) and they make a
difference. The short version of the story is that if you are going to
respect those constraints:

1) A prefix can only be applied to a canonical name stem

2) It has to be possible to distinguish prefixed names from wildcarded
records.

The other constraint is that early adopters of DNS keying are almost
certainly going to be completely new applications (Web Services, other new
protocols) rather than Web sites. And those new applications are likely to
specify use of an extended discovery mechanism (SRV, URI, NAPTR, etc) so
that they get fault tolerance.

If DANE wants to be relevant to early adopters that can form a critical
mass, it is probably going to have to work with the discovery mechanism used
by those Web services.

The scheme I describe in ESRV mk II combines extended discovery with
discovery of attributes relative to extended discovery (e.g. keys).

*Phase 1:*

At the start of the discovery process the query domain name is not
canonical, therefore an unprefixed query is made. So if we are looking for
the _http._tcp service, the query would be

example.com ? GSRV

As aliases must map to canonical names (no chains of aliases are allowed)
the result of this initial query will be either a canonical name or name not
found.

If you are going to make an unprefixed query in the initial case to obtain
the canonical name, you might as well put that query to work.

In many cases a site is not going to require the ability to specify service
attributes at any level of detail finer than the domain. If that is the
case, you might as well specify the information in the first phase.

In some cases a one size all solution is not going to be acceptable and the
general record will advise that additional information is available for
specific protocols (if manageably small) or should be requested in all
cases.

*Phase Two:*

In phase two we have a canonical name to query on and can use prefixes. At
this point we only have a service prefix, we do not have a host or port.

If the domain contains a wildcard record for GSRV, there is going to be a
risk of crosstalk. To avoid this we either have to be able to flag wildcard
results somehow, or we should use a different RR for prefixed results.

_http._srv.canonical.example.com ? ESRV

Again we may be able to give the data required in this instance, or phase
one may have told us to use an extended discovery mechanism such as SRV and
we may want to specify additional data that is specific to the host.

So the phase two response MAY indicate that discovery should continue to
obtain host/port specific data .

*Phase Three*

We can now obtain host specific data:

_http._srv._80.canonical.example.com ? ESRV

This design may appear somewhat heavy for web browsing. But the main
objective in the design is to support Web Services. And in Web Services we
generally care more about fault tolerance than shaving a few ms of
connection times.

To use this approach in a Web Browsing context we would want to hand the
task of performing the iterative descent to the recursive resolver so that
the results can be cached and reused.

On Thu, Jan 27, 2011 at 12:14 PM, Warren Kumari <[email-masked]> 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.
>
> 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.
>
> W
>
>
>
>
> On Jan 25, 2011, at 2:26 PM, Warren Kumari wrote:
>
>  [ Apologies to those who who may already have seen this data.]
>>
>> Adam Langley (who works on Chrome) has some numbers on actual DNS latency
>> as seen by users of Chrome.
>>
>> -----
>> An experiment was conducted to help understand real world DNS latency and
>> how it would affect things like TLSA....
>>
>> A DNS lookup was made for RR type 13172 (taken from /dev/urandom).
>>
>> This data was collected from some Chrome users who opted into statistics
>> gathering.
>> The experiment was only enabled for Linux users and only in development
>> versions of Chrome. Therefore, keep in mind that Linux users tend to have
>> better network connections in general and the types of users who install
>> development versions also tend to have better networks.
>>
>> 15,216 lookups were measured by 64-bit users and 9,516 by 32-bit users.
>> For the 64-bit users:
>>
>> 51.3% of lookups finished in 0ms (i.e. a local cache, either the one
>> within Chrome or a cache on the same LAN.) Afterwards, the curve trails off
>> very slowly:
>>
>> 67.3% < 10ms
>> 72.8% < 20ms
>> 82% < 50ms
>> 86.5 < 100ms
>> 93% < 200ms
>> 96.5 < 500ms
>> 97.5 < 1000ms
>>
>> 0.56% of lookups didn't complete within 10 seconds (we don't have
>> histogram buckets over 10 seconds).
>>
>> For the 32-bit users the curve is similar, but shifted to the right:
>>
>> 68.5% < 50ms
>> 79% < 100ms
>> 94% < 500ms
>>
>> 1.4% >= 10 seconds.
>>
>> ------
>>
>> I think that these number are really interesting, and should be kept in
>> mind when we are discussing the solutions that involve multiple DNS round
>> trips...
>>
>> W
>>
>>
>> On Jan 17, 2011, at 3:46 PM, Warren Kumari wrote:
>>
>>  I was hoping that would be able to stick to one open item at a time but
>>> the discussions on #17 (Should the first doc be TLS only or try be
>>> everything to everyone?) has wrapped directly to this issue, so:
>>>
>>> I'm opening up Issue #1 (Deal with multiple TLS-based services under one
>>> domain name (http://trac.tools.ietf.org/wg/dane/trac/ticket/1))
>>> [ Dons frock, flaps hands, twirls the incense burner three times to the
>>> left,  presses button to make water squirt out of daisy add releases the 12
>>> doves -- now it is official ]
>>> -----
>>> Description:
>>> How to deal with multiple TLS-based services running under one domain
>>> name, such as a POP, IMAP, and SMTP server all running on
>>> mail.example.com.
>>>
>>> Suggestions so far include:
>>> Prefacing the host name with a service name (_pop.mail.example.com)
>>> Prefacing the host name with a port number (_110.mail.example.com)
>>> Returning a set of records that contain port numbers in the response.
>>> SRV / ESRV
>>>
>>> -----
>>>
>>>
>>>
>>> W
>>> _______________________________________________
>>> keyassure mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/keyassure
>>>
>>
>>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

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

It is not a question of prefer, it is a question of what you can get the DN=
S infrastructure to do if you are not going to attempt to change the rules =
or change DNSSEC.<div><br></div><div><br></div><div>DNS has wildcards and a=
lias records (CNAME, DNAME) and they make a difference. The short version o=
f the story is that if you are going to respect those constraints:</div>
<div><br></div><div>1) A prefix can only be applied to a canonical name ste=
m=A0</div><div><br></div><div>2) It has to be possible to distinguish prefi=
xed names from wildcarded records.<br><div><br>The other constraint is that=
 early adopters of DNS keying are almost certainly going to be completely n=
ew applications (Web Services, other new protocols) rather than Web sites. =
And those new applications are likely to specify use of an extended discove=
ry mechanism (SRV, URI, NAPTR, etc) so that they get fault tolerance.</div>
<div><br></div><div>If DANE wants to be relevant to early adopters that can=
 form a critical mass, it is probably going to have to work with the discov=
ery mechanism used by those Web services.</div><div><br></div><div><br>
</div><div>The scheme I describe in ESRV mk II combines extended discovery =
with discovery of attributes relative to extended discovery (e.g. keys).</d=
iv><div><br></div><div><b>Phase 1:</b></div><div><br></div><div>At the star=
t of the discovery process the query domain name is not canonical, therefor=
e an unprefixed query is made. So if we are looking for the _http._tcp serv=
ice, the query would be</div>
<div><br></div><div><a href=3D"http://example.com">example.com</a> ? GSRV</=
div><div><br></div><div>As aliases must map to canonical names (no chains o=
f aliases are allowed) the result of this initial query will be either a ca=
nonical name or name not found.</div>
<div><br></div><div>If you are going to make an unprefixed query in the ini=
tial case to obtain the canonical name, you might as well put that query to=
 work.</div><div><br></div><div>In many cases a site is not going to requir=
e the ability to specify service attributes at any level of detail finer th=
an the domain. If that is the case, you might as well specify the informati=
on in the first phase.</div>
<div><br></div><div>In some cases a one size all solution is not going to b=
e acceptable and the general record will advise that additional information=
 is available for specific protocols (if manageably small) or should be req=
uested in all cases.</div>
<div><br></div><div><br></div><div><b>Phase Two:</b></div><div><br></div><d=
iv>In phase two we have a canonical name to query on and can use prefixes. =
At this point we only have a service prefix, we do not have a host or port.=
</div>
<div><br></div><div>If the domain contains a wildcard record for GSRV, ther=
e is going to be a risk of crosstalk. To avoid this we either have to be ab=
le to flag wildcard results somehow, or we should use a different RR for pr=
efixed results.</div>
<div><br></div><div>_http._<a href=3D"http://srv.canonical.example.com">srv=
.canonical.example.com</a> ? ESRV</div><div><br></div><div>Again we may be =
able to give the data required in this instance, or phase one may have told=
 us to use an extended discovery mechanism such as SRV and we may want to s=
pecify additional data that is specific to the host.</div>
<div><br></div><div>So the phase two response MAY indicate that discovery s=
hould continue to obtain host/port specific data .</div><div><br></div><div=
><b>Phase Three</b></div><div><br></div><div>We can now obtain host specifi=
c data:</div>
<div><br></div><div>_http._srv._<a href=3D"http://80.canonical.example.com"=
>80.canonical.example.com</a> ? ESRV</div><div><br></div><div><br></div><di=
v><br></div><div>This design may appear somewhat heavy for web browsing. Bu=
t the main objective in the design is to support Web Services. And in Web S=
ervices we generally care more about fault tolerance than shaving a few ms =
of connection times.</div>
<div><br></div><div>To use this approach in a Web Browsing context we would=
 want to hand the task of performing the iterative descent to the recursive=
 resolver so that the results can be cached and reused.</div><div><br></div=
>
<div><br></div><div><br><div class=3D"gmail_quote">On Thu, Jan 27, 2011 at =
12:14 PM, Warren Kumari <span dir=3D"ltr">&lt;<a href=3D"mailto:warren@kuma=
ri.net">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex;">
Ondrej and I would like to call #1 (and #17) soon, but would like to get a =
little clarification / restatement of folks views...<br>
<br>
When looking up TLSA records, would folk prefer querying for:<br>
<br>
1: Just a hostname (<a href=3D"http://mail.example.com" target=3D"_blank">m=
ail.example.com</a>) and pick from the returned records.<br>
<br>
2: Looking up a name prefixed with a port (_<a href=3D"http://443.www.examp=
le.com" target=3D"_blank">443.www.example.com</a>) or port and proto (_443.=
_<a href=3D"http://tcp.www.example.com" target=3D"_blank">tcp.www.example.c=
om</a>).<br>

An application could optimize beyond this, but this defines what is require=
d to look up.<br><font color=3D"#888888">
<br>
W</font><div><div></div><div class=3D"h5"><br>
<br>
<br>
<br>
On Jan 25, 2011, at 2:26 PM, Warren Kumari wrote:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
[ Apologies to those who who may already have seen this data.]<br>
<br>
Adam Langley (who works on Chrome) has some numbers on actual DNS latency a=
s seen by users of Chrome.<br>
<br>
-----<br>
An experiment was conducted to help understand real world DNS latency and h=
ow it would affect things like TLSA....<br>
<br>
A DNS lookup was made for RR type 13172 (taken from /dev/urandom).<br>
<br>
This data was collected from some Chrome users who opted into statistics ga=
thering.<br>
The experiment was only enabled for Linux users and only in development ver=
sions of Chrome. Therefore, keep in mind that Linux users tend to have bett=
er network connections in general and the types of users who install develo=
pment versions also tend to have better networks.<br>

<br>
15,216 lookups were measured by 64-bit users and 9,516 by 32-bit users. For=
 the 64-bit users:<br>
<br>
51.3% of lookups finished in 0ms (i.e. a local cache, either the one within=
 Chrome or a cache on the same LAN.) Afterwards, the curve trails off very =
slowly:<br>
<br>
67.3% &lt; 10ms<br>
72.8% &lt; 20ms<br>
82% &lt; 50ms<br>
86.5 &lt; 100ms<br>
93% &lt; 200ms<br>
96.5 &lt; 500ms<br>
97.5 &lt; 1000ms<br>
<br>
0.56% of lookups didn&#39;t complete within 10 seconds (we don&#39;t have h=
istogram buckets over 10 seconds).<br>
<br>
For the 32-bit users the curve is similar, but shifted to the right:<br>
<br>
68.5% &lt; 50ms<br>
79% &lt; 100ms<br>
94% &lt; 500ms<br>
<br>
1.4% &gt;=3D 10 seconds.<br>
<br>
------<br>
<br>
I think that these number are really interesting, and should be kept in min=
d when we are discussing the solutions that involve multiple DNS round trip=
s...<br>
<br>
W<br>
<br>
<br>
On Jan 17, 2011, at 3:46 PM, Warren Kumari wrote:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I was hoping that would be able to stick to one open item at a time but the=
 discussions on #17 (Should the first doc be TLS only or try be everything =
to everyone?) has wrapped directly to this issue, so:<br>
<br>
I&#39;m opening up Issue #1 (Deal with multiple TLS-based services under on=
e domain name (<a href=3D"http://trac.tools.ietf.org/wg/dane/trac/ticket/1"=
 target=3D"_blank">http://trac.tools.ietf.org/wg/dane/trac/ticket/1</a>))<b=
r>

[ Dons frock, flaps hands, twirls the incense burner three times to the lef=
t, =A0presses button to make water squirt out of daisy add releases the 12 =
doves -- now it is official ]<br>
-----<br>
Description:<br>
How to deal with multiple TLS-based services running under one domain name,=
 such as a POP, IMAP, and SMTP server all running on <a href=3D"http://mail=
.example.com" target=3D"_blank">mail.example.com</a>.<br>
<br>
Suggestions so far include:<br>
Prefacing the host name with a service name (_<a href=3D"http://pop.mail.ex=
ample.com" target=3D"_blank">pop.mail.example.com</a>)<br>
Prefacing the host name with a port number (_<a href=3D"http://110.mail.exa=
mple.com" target=3D"_blank">110.mail.example.com</a>)<br>
Returning a set of records that contain port numbers in the response.<br>
SRV / ESRV<br>
<br>
-----<br>
<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>
<br>
</blockquote>
<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>

--0016e6434658ba6c70049ae808d2--

Date: Fri, 28 Jan 2011 10:15:27 +0200
From: Yaron Sheffer <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [keyassure] Using trust anchor language

Hi Martin,

I completely agree. Just a note on terminology: I am confused by the 
terms "context sensitive" and "context free" in this setting; I think a 
better distinction would be between "informative" versus "restrictive" 
attributes. But we probably just need to spell out the individual 
properties, as you did in your mail.

Thanks,
	Yaron

On 01/28/2011 03:05 AM, Martin Rex wrote:
> Yaron Sheffer wrote:
>>
>> I am fine with the idea of a limited trust anchor, relevant only for
>> that specific host name.
>
> I think that notion of "valid for only the specific hostname"
> that was used for retrieving this cert or cert hash through TLSA
> under DNSSEC protection has always been silently assumed -- and
> needs to / is going to be spelled out.
>
>>
>> I am very suspicious of the "code reuse" argument.
>
> Me2.   :)
>
>> I agree with you that a set of rules is needed (I assume you mean
>> RP-side rules), so that the RP is not fooled into trusting unverified
>> pieces of the cert. But that would only add complexity to the already
>> complex cert processing code, and might end up undermining its security.
>> This would not be a good thing.
>
> Personally, I think there is actually _nothing_ besides the public key
> that can be trusted in a cert purely identified by DANE (TLSA) and
> authenticated through DNSSEC.
>
> What should be described is which particular usage restrictions contained
> in the cert should be honoured, that are _not_ sensitive to a
> particular context.  Any name-related attributes in a certificate
> are highly context sensitive and need to be entirely ignored.
>
> (Mostly) context-free attributes would be
>    - KeyUsage
>    - Validity
> and _maybe_ "ExtendedKeyUsage"
>
> -Martin

From: Simon Josefsson <[email-masked]>
To: Paul Wouters <[email-masked]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Fri, 28 Jan 2011 09:01:58 +0100
Cc: [email-masked]
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

Paul Wouters <[email-masked]> writes:

> On Thu, 27 Jan 2011, 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.
>>
>> 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.
>
> I prefer 1, because in the majority of cases there is just one certifiate,
> as people tend to use different hostnames for different services
> (mail.example.com, www.example.com)

I disagree, it is common to have multiple services with different
certificates/key on one host -- many people access their mail server
through SMTP (port 25), submission (port 587), webmail (https) and
possibly other ways (I access e-mail over SSH which can use certificates
as well).  See my earlier post about this with real-world examples:

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

> The approach without the port and transport service modifiers are simpler and
> less prone to errors.

It is a good way to create a lot of frustration with sysadmins.

/Simon

Date: Fri, 28 Jan 2011 00:14:51 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Warren Kumari <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

On Thu, 27 Jan 2011, 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.
>
> 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.

I prefer 1, because in the majority of cases there is just one certifiate,
as people tend to use different hostnames for different services
(mail.example.com, www.example.com)

In the cases people use the apex for all services, it would still likely
not exceed two TLSA records (mail/smtp/pop/imap and https)

Where people have very different security expectations per service,
they will likely even use separate physical servers neccessitating
different FQDNs.

The approach without the port and transport service modifiers are simpler and
less prone to errors.

Paul

Content-class: urn:content-classes:message
Date: Thu, 27 Jan 2011 23:16:15 -0500
From: "Carl Wallace" <[email-masked]>
To: "Paul Wouters" <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Using trust anchor language

> You might not want to do that though, and rely on DNSSEC to provide
the
> name, and possibly re-use the same cert for multiple domains without
> needing to use wildcards or a long list of subjectAltnames.
>=20
> Paul

Is there no concern for backwards compatibility at all?  Should folks
who do not use the DANE validation approach have no means to determine
if a certificate is valid and appropriate for a given site?  Should
folks have to learn to accept any name in a certificate validated via
DANE while checking for proper names when DANE is not used? =20

From: Warren Kumari <[email-masked]>
To: Warren Kumari <[email-masked]>
Date: Thu, 27 Jan 2011 12:14:02 -0500
Cc: [email-masked]
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

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.

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.

W

On Jan 25, 2011, at 2:26 PM, Warren Kumari wrote:

> [ Apologies to those who who may already have seen this data.]
>
> Adam Langley (who works on Chrome) has some numbers on actual DNS  
> latency as seen by users of Chrome.
>
> -----
> An experiment was conducted to help understand real world DNS  
> latency and how it would affect things like TLSA....
>
> A DNS lookup was made for RR type 13172 (taken from /dev/urandom).
>
> This data was collected from some Chrome users who opted into  
> statistics gathering.
> The experiment was only enabled for Linux users and only in  
> development versions of Chrome. Therefore, keep in mind that Linux  
> users tend to have better network connections in general and the  
> types of users who install development versions also tend to have  
> better networks.
>
> 15,216 lookups were measured by 64-bit users and 9,516 by 32-bit  
> users. For the 64-bit users:
>
> 51.3% of lookups finished in 0ms (i.e. a local cache, either the one  
> within Chrome or a cache on the same LAN.) Afterwards, the curve  
> trails off very slowly:
>
> 67.3% < 10ms
> 72.8% < 20ms
> 82% < 50ms
> 86.5 < 100ms
> 93% < 200ms
> 96.5 < 500ms
> 97.5 < 1000ms
>
> 0.56% of lookups didn't complete within 10 seconds (we don't have  
> histogram buckets over 10 seconds).
>
> For the 32-bit users the curve is similar, but shifted to the right:
>
> 68.5% < 50ms
> 79% < 100ms
> 94% < 500ms
>
> 1.4% >= 10 seconds.
>
> ------
>
> I think that these number are really interesting, and should be kept  
> in mind when we are discussing the solutions that involve multiple  
> DNS round trips...
>
> W
>
>
> On Jan 17, 2011, at 3:46 PM, Warren Kumari wrote:
>
>> I was hoping that would be able to stick to one open item at a time  
>> but the discussions on #17 (Should the first doc be TLS only or try  
>> be everything to everyone?) has wrapped directly to this issue, so:
>>
>> I'm opening up Issue #1 (Deal with multiple TLS-based services  
>> under one domain name (http://trac.tools.ietf.org/wg/dane/trac/ticket/1) 
>> )
>> [ Dons frock, flaps hands, twirls the incense burner three times to  
>> the left,  presses button to make water squirt out of daisy add  
>> releases the 12 doves -- now it is official ]
>> -----
>> Description:
>> How to deal with multiple TLS-based services running under one  
>> domain name, such as a POP, IMAP, and SMTP server all running on  
>> mail.example.com.
>>
>> Suggestions so far include:
>> Prefacing the host name with a service name (_pop.mail.example.com)
>> Prefacing the host name with a port number (_110.mail.example.com)
>> Returning a set of records that contain port numbers in the response.
>> SRV / ESRV
>>
>> -----
>>
>>
>>
>> W
>> _______________________________________________
>> keyassure mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/keyassure
>

From: Warren Kumari <[email-masked]>
To: Warren Kumari <[email-masked]>
Date: Thu, 27 Jan 2011 16:18:14 -0500
Cc: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol

Hi all,

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

Apologies,
   W

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

> While this is an interesting thread (and demonstrates the need for  
> this), I was wondering if we could try and return to the original  
> question....
>
> For a while it looked like we were getting somewhere on that, but I  
> think that we have drifted sufficiently off course that a gentle  
> nudge is in order...
>
> So, <nudge>.
>
> W
>
> On Jan 24, 2011, at 5:44 PM, Martin Rex wrote:
>
>> Stephen Kent wrote:
>>>
>>>> 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.
>>>
>>> I don't think I agree with your characterization of the "original
>>> design" rationale. Long ago there were many fewer TAs in browsers,
>>> and the power shifted between CAs and browser vendors over time.  I
>>> served as CTO for a major CA in the mid-90's, so I recall what  
>>> things
>>> were like then.
>>
>> Netscape 3.01 (~1996) already had 16 independent rootCA certs.
>> (just looked at it -- yup, I still got one of those around).
>>
>> I remember that around year 2000,
>>
>> Thawte sold regular server certs a USD 100 and wildcard certs at  
>> USD 400,
>> and if you paid for 2 years in advance, you could get a server cert
>> with 2 years lifetime.
>>
>> while VeriSign wanted USD 700 for a regular server cert and didn't
>> offer any wildcard certs at all.
>>
>>
>> So both, the multiple independent rootCA certs and the widely varying
>> prices are really pretty old stuff.
>>
>> -Martin
>> _______________________________________________
>> keyassure mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/keyassure
>
> --
> The plural of anecdote is not evidence.
>        -- Bill Lockyer, California Attorney General
>
>
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

From: Martin Rex <[email-masked]>
To: [email-masked] (Yaron Sheffer)
Date: Fri, 28 Jan 2011 02:05:37 +0100 (MET)
Cc: [email-masked]
Subject: Re: [keyassure] Using trust anchor language
Reply-To: [email-masked]

Yaron Sheffer wrote:
> 
> I am fine with the idea of a limited trust anchor, relevant only for 
> that specific host name.

I think that notion of "valid for only the specific hostname"
that was used for retrieving this cert or cert hash through TLSA
under DNSSEC protection has always been silently assumed -- and
needs to / is going to be spelled out.
 
> 
> I am very suspicious of the "code reuse" argument.

Me2.   :)

> I agree with you that a set of rules is needed (I assume you mean
> RP-side rules), so that the RP is not fooled into trusting unverified
> pieces of the cert. But that would only add complexity to the already
> complex cert processing code, and might end up undermining its security.
> This would not be a good thing.

Personally, I think there is actually _nothing_ besides the public key
that can be trusted in a cert purely identified by DANE (TLSA) and
authenticated through DNSSEC.

What should be described is which particular usage restrictions contained
in the cert should be honoured, that are _not_ sensitive to a
particular context.  Any name-related attributes in a certificate
are highly context sensitive and need to be entirely ignored.

(Mostly) context-free attributes would be
  - KeyUsage
  - Validity
and _maybe_ "ExtendedKeyUsage"

-Martin

Date: Fri, 28 Jan 2011 01:31:08 +0200
From: Yaron Sheffer <[email-masked]>
To: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Using trust anchor language

Hi Steve,

I am fine with the idea of a limited trust anchor, relevant only for 
that specific host name.

I am very suspicious of the "code reuse" argument. I agree with you that 
a set of rules is needed (I assume you mean RP-side rules), so that the 
RP is not fooled into trusting unverified pieces of the cert. But that 
would only add complexity to the already complex cert processing code, 
and might end up undermining its security. This would not be a good thing.

Can you please explain (informally) what stuff in the cert can be 
trusted by the RP, other than the public key? For example, if the cert 
contains some future X.509 extension ("the Subject's eyes are blue") - 
should it be trusted by the RP as applying to the TLS endpoint?

And lastly, referring to your other email, can you please be more 
specific about the domain name constraints, i.e. what exact part of the 
SIDR spec you propose that we adopt here?

Thanks,
	Yaron

On 01/27/2011 05:56 PM, Stephen Kent wrote:
> At 8:40 AM +0200 1/27/11, Yaron Sheffer wrote:
>> Hi Paul,
>>
>> if earlier I was confused, now I am extremely worried. It seems to me
>> than with the goal of simplifying the protocol, you are removing all
>> remnants of operational security.
>>
>> If the DNS registrar signs anything more than the public key, in
>> particular if it signs the Subject or Subject Alt Name on a
>> certificate, and if we specify explicitly that this cert is to be used
>> as a trust anchor, then the registrar acts as a CA. So, like it or
>> not, it needs to play by CA rules.
>>
>> If all you sign is the public key, and if you mandate that the cert
>> MUST only be associated with a particular FQDN and the RP MUST ignore
>> non-key material, then we can relax these rules. I think this is the
>> path we should follow if we are to provide a credible, yet secure,
>> alternative to PKI.
>>
>> I am well aware of the failings of commercial PKI. But trying to
>> replace them by a scheme that offers even less security doesn't make
>> sense to me.
>>
>> More below.
>>
>> Yaron
>
> Yaron,
>
> I agree that we have to be careful in the design that DANE adopts, to avoid
> undermining the current level of security offered for TLS. I think this
> can be done safely with either a "bare" key or a cert as the contents of
> the signed record. An advantage of using a cert is that it might be
> easier to make use of the rest of the TLS cert processing software,
> i.e., minimize the impact of using DNS. For example, we could require
> that the cert contain a SAN of the form DNSname, and mandate checks to
> ensure that the SAN is consistent with the
> DNS context from which it was acquired (he said, imprecisely).
>
> I disagree that the client (RP) needs to ignore everything in a cert
> acquired
> in this fashion. If we impose appropriate rules, we can make this safe.
> I view the rules as a form of pre-processing applied to the cert before
> accepting it for use, e.g., as a TA.
>
> Steve

From: Martin Rex <[email-masked]>
To: [email-masked] (Steingruebl Andy)
Date: Thu, 27 Jan 2011 22:16:32 +0100 (MET)
Cc: [email-masked]
Subject: Re: [keyassure] Using trust anchor language
Reply-To: [email-masked]

Steingruebl, Andy wrote:
> 
> > 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..

Conceptually, there _is_ a significant difference. (see last sentence
of section 1 of every TLS spec in existence).

Support for DANE/TLSA could be added entirely at the app layer without
a single change to the underlying TLS implementation.  The use of SNI,
on the other hand, has the inevitable prerequisite that the underlying
TLS implementation itself must support it.

So for implementations running on top of Windows SChannel, supporting
DANE/TLSA is conceivable even for Windows XP and completely independent
of what Microsoft does.  This applies to _all_ environments with currently
extrension-free TLS implementations (WinXP is probably the single largest
example, but there are _many_ more such environments&devices).

In some environments, there may be dozens or even hundreds of
virtual hosts on the same IPv4-address, and having to re-issue
a cert everytime a virtual host is added or removed would be
a real problem without SNI.  Having a self-signed server cert
change every few weeks sounds like a very bad idea, because
it precludes clients from sensible "pinning" of server certs
as a means to improve trust through memorizing prior experience.

-Martin

From: "Steingruebl, Andy" <[email-masked]>
To: Stephen Kent <[email-masked]>
Date: Thu, 27 Jan 2011 11:13:57 -0700
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Using trust anchor language

> -----Original Message-----
> From: Stephen Kent [mailto:[email-masked]]
>=20
> 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) o=
n 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 try=
ing to reach.

#1 is extremely problematic when virtual-hosting services for different ent=
ities, 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 th=
at 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 TLS=
A.  Now, what client will support TLSA and not SNI, well, that's why this i=
sn't really that big a deal I suppose..

- Andy

Date: Thu, 27 Jan 2011 12:47:30 -0500
To: "Steingruebl, Andy" <[email-masked]>
From: Stephen Kent <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Using trust anchor language

At 10:28 AM -0700 1/27/11, Steingruebl, Andy wrote:
>  > -----Original Message-----
>>  From: [email-masked] [mailto:[email-masked]] On
>>  Behalf Of Stephen Kent
>>
>>  Paul,
>>
>>  My understanding has been that the primary motivation for wild cards in web
>>  site certs was to avoid the need to pay for multiple certs.  Since we are
>>  avoiding that concern here, and since one could even choose to put the
>>  same key in multiple certs, each with a different name, what is the major
>>  concern over putting a DNS name in a cert? It's not hard to 
>>generate multiple
>>  certs, e.g., one per site.
>
>A model that doesn't require a name embedded in the cert allows us 
>to get wider TLS deployment without IP exhaustion without requiring 
>SNI.  For what that is worth.
>
>- Andy

Andy,

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?

Steve

From: "Steingruebl, Andy" <[email-masked]>
To: Stephen Kent <[email-masked]>, Paul Wouters <[email-masked]>
Date: Thu, 27 Jan 2011 10:28:22 -0700
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Using trust anchor language

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Stephen Kent
>=20
> Paul,
>=20
> My understanding has been that the primary motivation for wild cards in w=
eb
> site certs was to avoid the need to pay for multiple certs.  Since we are
> avoiding that concern here, and since one could even choose to put the
> same key in multiple certs, each with a different name, what is the major
> concern over putting a DNS name in a cert? It's not hard to generate mult=
iple
> certs, e.g., one per site.

A model that doesn't require a name embedded in the cert allows us to get w=
ider TLS deployment without IP exhaustion without requiring SNI.  For what =
that is worth.

- Andy

Date: Thu, 27 Jan 2011 12:01:11 -0500
To: Paul Wouters <[email-masked]>
From: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Using trust anchor language

At 11:13 AM -0500 1/27/11, Paul Wouters wrote:
>On Thu, 27 Jan 2011, Stephen Kent wrote:
>
>>>Arrrgh. I apologize for assuming that folks understand the use of 
>>>limited trust anchors, given that most of us are used to trust 
>>>anchors with unlimited power. This is a trust anchor *only* for 
>>>this host name. Words to that effect needs to be added, and needs 
>>>to be a MUST.
>>
>>You might note how to effect this, in a PKI-compliant fashion,. e.g., by
>>associating name constraints for the FQDN with the cert.  Carl 
>>Wallace's I-D on TA constraints provides one example of how to do 
>>this, as does the local TA management I-D now in SIDR (only a tiny 
>>part of that functionality would be needed here).
>
>You might not want to do that though, and rely on DNSSEC to provide the name,
>and possibly re-use the same cert for multiple domains without needing to
>use wildcards or a long list of subjectAltnames.
>
>Paul

Paul,

My understanding has been that the primary motivation for wild cards in
web site certs was to avoid the need to pay for multiple certs.  Since we
are avoiding that concern here, and since one could even choose to put the same
key in multiple certs, each with a different name, what is the major
concern over putting a DNS name in a cert? It's not hard to generate multiple
certs, e.g., one per site.

Steve

Date: Thu, 27 Jan 2011 11:13:12 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Using trust anchor language

On Thu, 27 Jan 2011, Stephen Kent wrote:

>> Arrrgh. I apologize for assuming that folks understand the use of limited 
>> trust anchors, given that most of us are used to trust anchors with 
>> unlimited power. This is a trust anchor *only* for this host name. Words to 
>> that effect needs to be added, and needs to be a MUST.
>
> You might note how to effect this, in a PKI-compliant fashion,. e.g., by
> associating name constraints for the FQDN with the cert.  Carl Wallace's I-D 
> on TA constraints provides one example of how to do this, as does the local 
> TA management I-D now in SIDR (only a tiny part of that functionality would 
> be needed here).

You might not want to do that though, and rely on DNSSEC to provide the name,
and possibly re-use the same cert for multiple domains without needing to
use wildcards or a long list of subjectAltnames.

Paul

Date: Thu, 27 Jan 2011 10:56:17 -0500
To: Yaron Sheffer <[email-masked]>
From: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Using trust anchor language

At 8:40 AM +0200 1/27/11, Yaron Sheffer wrote:
>Hi Paul,
>
>if earlier I was confused, now I am extremely worried. It seems to 
>me than with the goal of simplifying the protocol, you are removing 
>all remnants of operational security.
>
>If the DNS registrar signs anything more than the public key, in 
>particular if it signs the Subject or Subject Alt Name on a 
>certificate, and if we specify explicitly that this cert is to be 
>used as a trust anchor, then the registrar acts as a CA. So, like it 
>or not, it needs to play by CA rules.
>
>If all you sign is the public key, and if you mandate that the cert 
>MUST only be associated with a particular FQDN and the RP MUST 
>ignore non-key material, then we can relax these rules. I think this 
>is the path we should follow if we are to provide a credible, yet 
>secure, alternative to PKI.
>
>I am well aware of the failings of commercial PKI. But trying to 
>replace them by a scheme that offers even less security doesn't make 
>sense to me.
>
>More below.
>
>	Yaron

Yaron,

I agree that we have to be careful in the design that DANE adopts, to avoid
undermining the current level of security offered for TLS. I think 
this can be done safely with either a "bare" key or a cert as the 
contents of the signed record. An advantage of using a cert is that 
it might be easier to make use of the rest of the TLS cert processing 
software, i.e., minimize the impact of using DNS. For example, we 
could require that the cert contain a SAN of the form DNSname, and 
mandate checks to ensure that the SAN is consistent with the
DNS context from which it was acquired (he said, imprecisely).

I disagree that the client (RP) needs to ignore everything in a cert acquired
in this fashion. If we impose appropriate rules, we can make this 
safe. I view the rules as a form of pre-processing applied to the 
cert before accepting it for use, e.g., as a TA.

Steve

Date: Thu, 27 Jan 2011 10:04:22 -0500
To: Paul Hoffman <[email-masked]>
From: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Using trust anchor language

At 6:36 AM -0800 1/27/11, Paul Hoffman wrote:
>On 1/26/11 9:12 AM, Zack Weinberg wrote:
>>On Wed, Jan 26, 2011 at 8:58 AM, Paul Hoffman<[email-masked]>  wrote:
>>...
>>>Every TLS client has its own rules for what to do with each individual trust
>>>anchor. Most TLS clients have the policy that "anything that chains to any
>>>trust anchor I have is allowed", but that policy is not mandated anywhere.
>>>More careful TLS clients will have more careful policies. Our protocol
>>>should not force a careless policy on anyone.
>>...
>>>The policy for these four types is "treat them as a trust anchor". I'm not
>>>sure how to make that any clearer.
>>
>>Precisely because of what you say in the first paragraph I've quoted,
>>I think DANE needs to be more specific about appropriate client policy
>>than "treat [a certificate with a valid TLSA record] as a trust
>>anchor".
>>
>>At the very least, I think we need language to the effect that a
>>certificate with a TLSA record SHOULD NOT be promoted to trust anchor
>>for any certificate chain other than the one received from the server
>>at the domain name where the TLSA record appears.  (Possibly even MUST
>>NOT.)  (I may have my PKIX/TLS terminology all wrong, but I hope my
>>meaning is clear.)
>
>Arrrgh. I apologize for assuming that folks understand the use of 
>limited trust anchors, given that most of us are used to trust 
>anchors with unlimited power. This is a trust anchor *only* for this 
>host name. Words to that effect needs to be added, and needs to be a 
>MUST.

You might note how to effect this, in a PKI-compliant fashion,. e.g., by
associating name constraints for the FQDN with the cert.  Carl 
Wallace's I-D on TA constraints provides one example of how to do 
this, as does the local TA management I-D now in SIDR (only a tiny 
part of that functionality would be needed here).

Steve

Date: Thu, 27 Jan 2011 06:36:22 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Using trust anchor language

On 1/26/11 9:12 AM, Zack Weinberg wrote:
> On Wed, Jan 26, 2011 at 8:58 AM, Paul Hoffman<[email-masked]>  wrote:
> ...
>> Every TLS client has its own rules for what to do with each individual trust
>> anchor. Most TLS clients have the policy that "anything that chains to any
>> trust anchor I have is allowed", but that policy is not mandated anywhere.
>> More careful TLS clients will have more careful policies. Our protocol
>> should not force a careless policy on anyone.
> ...
>> The policy for these four types is "treat them as a trust anchor". I'm not
>> sure how to make that any clearer.
>
> Precisely because of what you say in the first paragraph I've quoted,
> I think DANE needs to be more specific about appropriate client policy
> than "treat [a certificate with a valid TLSA record] as a trust
> anchor".
>
> At the very least, I think we need language to the effect that a
> certificate with a TLSA record SHOULD NOT be promoted to trust anchor
> for any certificate chain other than the one received from the server
> at the domain name where the TLSA record appears.  (Possibly even MUST
> NOT.)  (I may have my PKIX/TLS terminology all wrong, but I hope my
> meaning is clear.)

Arrrgh. I apologize for assuming that folks understand the use of 
limited trust anchors, given that most of us are used to trust anchors 
with unlimited power. This is a trust anchor *only* for this host name. 
Words to that effect needs to be added, and needs to be a MUST.

From: Jakob Schlyter <[email-masked]>
Date: Thu, 27 Jan 2011 13:51:59 +0100
To: Yaron Sheffer <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Using trust anchor language

On 27 jan 2011, at 07.40, Yaron Sheffer wrote:

> If the DNS registrar signs anything more than the public key, in =
particular if it signs the Subject or Subject Alt Name on a certificate, =
and if we specify explicitly that this cert is to be used as a trust =
anchor, then the registrar acts as a CA. So, like it or not, it needs to =
play by CA rules.

With "DNS registrar" I assume you mean the person responsible for =
editing the DNS information. In the DNS world, the registrar is actually =
the organization registering new domains names in a DNS registry on =
behalf of the registrant - e.g., Godaddy is a registrar. I suggest we =
use the term "DNS administrator" instead.

> If all you sign is the public key, and if you mandate that the cert =
MUST only be associated with a particular FQDN and the RP MUST ignore =
non-key material, then we can relax these rules. I think this is the =
path we should follow if we are to provide a credible, yet secure, =
alternative to PKI.

The DNS administrator will sign the whole TLSA resource record (RR) - a =
cert or just a hash of a cert. Even though the whole RR is signed, the =
DANE specification can still mandate that the client should ignore the =
hostname part of the cert. Given this, I can generate a self-signed =
certificate with CN=3Dwww.paypal.com and publishing it as a TLSA RR as =
www.kirei.se. My DNS administrator doesn't need to understand what's in =
the TLSA RR - he/she just has to publish whatever I submit. The =
selective ignore part is all on the RP side.

	jakob

Date: Thu, 27 Jan 2011 08:40:34 +0200
From: Yaron Sheffer <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Using trust anchor language

Hi Paul,

if earlier I was confused, now I am extremely worried. It seems to me 
than with the goal of simplifying the protocol, you are removing all 
remnants of operational security.

If the DNS registrar signs anything more than the public key, in 
particular if it signs the Subject or Subject Alt Name on a certificate, 
and if we specify explicitly that this cert is to be used as a trust 
anchor, then the registrar acts as a CA. So, like it or not, it needs to 
play by CA rules.

If all you sign is the public key, and if you mandate that the cert MUST 
only be associated with a particular FQDN and the RP MUST ignore non-key 
material, then we can relax these rules. I think this is the path we 
should follow if we are to provide a credible, yet secure, alternative 
to PKI.

I am well aware of the failings of commercial PKI. But trying to replace 
them by a scheme that offers even less security doesn't make sense to me.

More below.

	Yaron

> Date: Wed, 26 Jan 2011 08:58:48 -0800
> From: Paul Hoffman<[email-masked]>
> Subject: Re: [keyassure] Using trust anchor language
> To: [email-masked]
> Message-ID:<[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 1/26/11 8:27 AM, Yaron Sheffer wrote:
>> Hi Paul,
>>
>> I am extremely confused by the wording of the new draft, and my
>> confusion is even more exacerbated by your clarification below :-)
>> Please help me!
>>
>> Quoting the new text in full:
>>
>> Items received in TLSA resource records can be treated like trust
>> anchors by the TLS client. The trust anchor MUST NOT be loaded for
>> longer than the TTL on the TSLA record.
>>
>> I have three issues with this text:
>>
>> First, the text is imprecise. In some of the cases there are no
>> "items received". The RP received a hash of a cert, and that cert is
>> in fact what we want treated as a trust anchor.
>
> Now I'm the one confused. If the TLS client received a hash of a cert
> (either type 1 or type 3), then they received an item.
>
Yes, but the object that asserts a claim ("I am THIS subject, and I am 
the holder of THIS public key") is the cert itself, not its hash.

>> Second, we use a lower-case "can" for a critical process. A compliant
>>   Relying Party SHOULD/MUST use these RRs as trust anchors.
>
> Not at all. RFC 2119 has specific uses, and none of them apply here
> (unless the WG wants to make such an assertion). Your proposal would
> force a security policy on someone who, for example, just wanted to know
> whether or not a site had a TLSA record.
>
This is plain nonsense. Of course someone can be playing games. We are 
talking of someone using TLSA for the purpose for which TLSA was 
established, i.e. to set up a secure TLS connection.

And you ARE defining a security policy by saying these certs are to be 
used as trust anchors.

>> And third, the way I understand "trust anchor" is you should trust it
>>   blindly, like you trust all those 60 certs in your browser. (I am
>> not talking of enterprise/government cases, but of the other 99.9% of
>> the world).
>
> Every TLS client has its own rules for what to do with each individual
> trust anchor. Most TLS clients have the policy that "anything that
> chains to any trust anchor I have is allowed", but that policy is not
> mandated anywhere. More careful TLS clients will have more careful
> policies. Our protocol should not force a careless policy on anyone.
>
So we are in complete agreement. I would like to focus on the 99.9% of 
the world who do not have fancy policies and will take you at your 
world: use these certs as trust anchors. We need to specify a 
*reasonable* secure policy for such clients. What we have now is not 
reasonable.

>> Does this mean the RP should not even try to validate the cert?
>
> Correct: that is the definition of a trust anchor.
>
No wonder. I consulted RFC 4949 before posting :-)

>> If this is so, we should make the certificate trustworthy. Here's a
>> set of tentative rules:
>>
>> - The DNS registrar MUST have access to the certificate at the time it
>> generate the TLSA record.
>
> There is no such thing as a "DNS registrar". Please choose a phrase that
> exists. Also, what does "have access" mean?
>
Please don't nitpick, Wikipedia seems to understand what I mean: 
http://en.wikipedia.org/wiki/Domain_name_registrar). "Have access" 
means: "can read and validate it".

>> - The registrar MUST ensure that the certificate is valid, and/or must
>> validate any non-key information included in the certificate.
>
> This makes no sense for a self-signed end-entity certificate. How can
> one validate such a certificate?
>
True. For self-signed certs, the Registrar needs to verify that the 
non-key information is correct. Like, call you on the phone to make sure 
you exist. Yes, just like a traditional CA.

>> - In particular the registrar MUST ensure that the certificate does not
>> refer to any DNS address outside of that registrar's scope of authority.
>
> By "DNS address" I assume you mean "host name". What is the problem with
> any of the four types defined so far referring to a host name outside
> the "scope of authority" (whatever that is)? These are being used ad
> trust anchors.
>
You are telling the RP to add the cert as a trust anchor. Then you are 
saying I can have my certs include DNS:vpnc.org as a Subject Alt Name, 
and any RP will happily accept them.

>> - The registrar MUST establish a Certificate Practice Statement (CPS)
>> and make it publicly available.
>
> Why would an entity that does not issue certificates need a CPS?
>
It doesn't generate the cert. But it effectively signs it. So yes, it 
"issues" a certificate.

>> I have a feeling this is NOT what you meant. But I fail to understand
>>   exactly what security policy we now assume.
>
> The policy for these four types is "treat them as a trust anchor". I'm
> not sure how to make that any clearer.
>
>
It is only too clear now.

Sender: [email-masked]
Date: Wed, 26 Jan 2011 09:12:48 -0800
From: Zack Weinberg <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Using trust anchor language

On Wed, Jan 26, 2011 at 8:58 AM, Paul Hoffman <[email-masked]> wrote:
...
> Every TLS client has its own rules for what to do with each individual trust
> anchor. Most TLS clients have the policy that "anything that chains to any
> trust anchor I have is allowed", but that policy is not mandated anywhere.
> More careful TLS clients will have more careful policies. Our protocol
> should not force a careless policy on anyone.
...
> The policy for these four types is "treat them as a trust anchor". I'm not
> sure how to make that any clearer.

Precisely because of what you say in the first paragraph I've quoted,
I think DANE needs to be more specific about appropriate client policy
than "treat [a certificate with a valid TLSA record] as a trust
anchor".

At the very least, I think we need language to the effect that a
certificate with a TLSA record SHOULD NOT be promoted to trust anchor
for any certificate chain other than the one received from the server
at the domain name where the TLSA record appears.  (Possibly even MUST
NOT.)  (I may have my PKIX/TLS terminology all wrong, but I hope my
meaning is clear.)

zw

Date: Wed, 26 Jan 2011 08:58:48 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Using trust anchor language

On 1/26/11 8:27 AM, Yaron Sheffer wrote:
> Hi Paul,
>
> I am extremely confused by the wording of the new draft, and my
> confusion is even more exacerbated by your clarification below :-)
> Please help me!
>
> Quoting the new text in full:
>
> Items received in TLSA resource records can be treated like trust
> anchors by the TLS client. The trust anchor MUST NOT be loaded for
> longer than the TTL on the TSLA record.
>
> I have three issues with this text:
>
> First, the text is imprecise. In some of the cases there are no
> "items received". The RP received a hash of a cert, and that cert is
> in fact what we want treated as a trust anchor.

Now I'm the one confused. If the TLS client received a hash of a cert 
(either type 1 or type 3), then they received an item.

> Second, we use a lower-case "can" for a critical process. A compliant
>  Relying Party SHOULD/MUST use these RRs as trust anchors.

Not at all. RFC 2119 has specific uses, and none of them apply here 
(unless the WG wants to make such an assertion). Your proposal would 
force a security policy on someone who, for example, just wanted to know 
whether or not a site had a TLSA record.

> And third, the way I understand "trust anchor" is you should trust it
>  blindly, like you trust all those 60 certs in your browser. (I am
> not talking of enterprise/government cases, but of the other 99.9% of
> the world).

Every TLS client has its own rules for what to do with each individual 
trust anchor. Most TLS clients have the policy that "anything that 
chains to any trust anchor I have is allowed", but that policy is not 
mandated anywhere. More careful TLS clients will have more careful 
policies. Our protocol should not force a careless policy on anyone.

> Does this mean the RP should not even try to validate the cert?

Correct: that is the definition of a trust anchor.

> If this is so, we should make the certificate trustworthy. Here's a
> set of tentative rules:
>
> - The DNS registrar MUST have access to the certificate at the time it
> generate the TLSA record.

There is no such thing as a "DNS registrar". Please choose a phrase that 
exists. Also, what does "have access" mean?

> - The registrar MUST ensure that the certificate is valid, and/or must
> validate any non-key information included in the certificate.

This makes no sense for a self-signed end-entity certificate. How can 
one validate such a certificate?

> - In particular the registrar MUST ensure that the certificate does not
> refer to any DNS address outside of that registrar's scope of authority.

By "DNS address" I assume you mean "host name". What is the problem with 
any of the four types defined so far referring to a host name outside 
the "scope of authority" (whatever that is)? These are being used ad 
trust anchors.

> - The registrar MUST establish a Certificate Practice Statement (CPS)
> and make it publicly available.

Why would an entity that does not issue certificates need a CPS?

> I have a feeling this is NOT what you meant. But I fail to understand
>  exactly what security policy we now assume.

The policy for these four types is "treat them as a trust anchor". I'm 
not sure how to make that any clearer.

Date: Wed, 26 Jan 2011 18:27:34 +0200
From: Yaron Sheffer <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Using trust anchor language

Hi Paul,

I am extremely confused by the wording of the new draft, and my 
confusion is even more exacerbated by your clarification below :-) 
Please help me!

Quoting the new text in full:

Items received in TLSA resource records can be treated like trust 
anchors by the TLS client.  The trust anchor MUST NOT be loaded for 
longer than the TTL on the TSLA record.

I have three issues with this text:

First, the text is imprecise. In some of the cases there are no "items 
received". The RP received a hash of a cert, and that cert is in fact 
what we want treated as a trust anchor.

Second, we use a lower-case "can" for a critical process. A compliant 
Relying Party SHOULD/MUST use these RRs as trust anchors.

And third, the way I understand "trust anchor" is you should trust it 
blindly, like you trust all those 60 certs in your browser. (I am not 
talking of enterprise/government cases, but of the other 99.9% of the 
world).

Does this mean the RP should not even try to validate the cert?

If this is so, we should make the certificate trustworthy. Here's a set 
of tentative rules:

- The DNS registrar MUST have access to the certificate at the time it 
generate the TLSA record.
- The registrar MUST ensure that the certificate is valid, and/or must 
validate any non-key information included in the certificate.
- In particular the registrar MUST ensure that the certificate does not 
refer to any DNS address outside of that registrar's scope of authority.
- The registrar MUST establish a Certificate Practice Statement (CPS) 
and make it publicly available.

I have a feeling this is NOT what you meant. But I fail to understand 
exactly what security policy we now assume.

Thanks,
	Yaron

> Date: Tue, 25 Jan 2011 11:59:00 -0800
> From: Paul Hoffman<[email-masked]>
> Subject: [keyassure] Using trust anchor language:
> 	draft-ietf-dane-protocol-03.txt
> To: "[email-masked]"<[email-masked]>
> Message-ID:<[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> 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.
>
> The diffs are at
> <http://tools.ietf.org/rfcdiff?url2=draft-ietf-dane-protocol-03.txt>.
>
> If folks are happy with this clarification, it will close some of the
> open issues that were spurred by the language in 3.1.
>
> --Paul Hoffman
>
>
> ------------------------------
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>
>
> End of keyassure Digest, Vol 6, Issue 38
> ****************************************

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 25 Jan 2011 22:50:57 -0500
To: Paul Hoffman <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Using trust anchor language: draft-ietf-dane-protocol-03.txt

Paul,
This wording looks good to me.  Very clear.
--Richard

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

Date: Tue, 25 Jan 2011 11:59:00 -0800
From: Paul Hoffman <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [keyassure] Using trust anchor language: draft-ietf-dane-protocol-03.txt

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.

The diffs are at 
<http://tools.ietf.org/rfcdiff?url2=draft-ietf-dane-protocol-03.txt>.

If folks are happy with this clarification, it will close some of the 
open issues that were spurred by the language in 3.1.

--Paul Hoffman

From: [email-masked]
To: [email-masked]
Date: Tue, 25 Jan 2011 11:45:02 -0800
Cc: [email-masked]
Subject: [keyassure] I-D Action:draft-ietf-dane-protocol-03.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-03.txt
	Pages           : 10
	Date            : 2011-01-25

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-03.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-03.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--

From: Warren Kumari <[email-masked]>
To: Warren Kumari <[email-masked]>
Date: Tue, 25 Jan 2011 14:26:00 -0500
Cc: [email-masked]
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

[ Apologies to those who who may already have seen this data.]

Adam Langley (who works on Chrome) has some numbers on actual DNS  
latency as seen by users of Chrome.

-----
An experiment was conducted to help understand real world DNS latency  
and how it would affect things like TLSA....

A DNS lookup was made for RR type 13172 (taken from /dev/urandom).

This data was collected from some Chrome users who opted into  
statistics gathering.
The experiment was only enabled for Linux users and only in  
development versions of Chrome. Therefore, keep in mind that Linux  
users tend to have better network connections in general and the types  
of users who install development versions also tend to have better  
networks.

15,216 lookups were measured by 64-bit users and 9,516 by 32-bit  
users. For the 64-bit users:

51.3% of lookups finished in 0ms (i.e. a local cache, either the one  
within Chrome or a cache on the same LAN.) Afterwards, the curve  
trails off very slowly:

67.3% < 10ms
72.8% < 20ms
82% < 50ms
86.5 < 100ms
93% < 200ms
96.5 < 500ms
97.5 < 1000ms

0.56% of lookups didn't complete within 10 seconds (we don't have  
histogram buckets over 10 seconds).

For the 32-bit users the curve is similar, but shifted to the right:

68.5% < 50ms
79% < 100ms
94% < 500ms

1.4% >= 10 seconds.

------

I think that these number are really interesting, and should be kept  
in mind when we are discussing the solutions that involve multiple DNS  
round trips...

W

On Jan 17, 2011, at 3:46 PM, Warren Kumari wrote:

> I was hoping that would be able to stick to one open item at a time  
> but the discussions on #17 (Should the first doc be TLS only or try  
> be everything to everyone?) has wrapped directly to this issue, so:
>
> I'm opening up Issue #1 (Deal with multiple TLS-based services under  
> one domain name (http://trac.tools.ietf.org/wg/dane/trac/ticket/1))
> [ Dons frock, flaps hands, twirls the incense burner three times to  
> the left,  presses button to make water squirt out of daisy add  
> releases the 12 doves -- now it is official ]
> -----
> Description:
> How to deal with multiple TLS-based services running under one  
> domain name, such as a POP, IMAP, and SMTP server all running on  
> mail.example.com.
>
> Suggestions so far include:
> Prefacing the host name with a service name (_pop.mail.example.com)
> Prefacing the host name with a port number (_110.mail.example.com)
> Returning a set of records that contain port numbers in the response.
> SRV / ESRV
>
> -----
>
>
>
> W
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

From: Warren Kumari <[email-masked]>
To: [email-masked]
Date: Mon, 24 Jan 2011 18:35:00 -0500
Cc: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol

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

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

So, <nudge>.

W

On Jan 24, 2011, at 5:44 PM, Martin Rex wrote:

> Stephen Kent wrote:
>>
>>> 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.
>>
>> I don't think I agree with your characterization of the "original
>> design" rationale. Long ago there were many fewer TAs in browsers,
>> and the power shifted between CAs and browser vendors over time.  I
>> served as CTO for a major CA in the mid-90's, so I recall what things
>> were like then.
>
> Netscape 3.01 (~1996) already had 16 independent rootCA certs.
> (just looked at it -- yup, I still got one of those around).
>
> I remember that around year 2000,
>
> Thawte sold regular server certs a USD 100 and wildcard certs at USD  
> 400,
> and if you paid for 2 years in advance, you could get a server cert
> with 2 years lifetime.
>
> while VeriSign wanted USD 700 for a regular server cert and didn't
> offer any wildcard certs at all.
>
>
> So both, the multiple independent rootCA certs and the widely varying
> prices are really pretty old stuff.
>
> -Martin
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

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

From: Martin Rex <[email-masked]>
To: [email-masked] (Stephen Kent)
Date: Mon, 24 Jan 2011 23:44:39 +0100 (MET)
Cc: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol
Reply-To: [email-masked]

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

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

I remember that around year 2000,

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

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

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

-Martin

Date: Mon, 24 Jan 2011 16:26:21 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol

At 5:45 PM +0100 1/21/11, Martin Rex wrote:
>...
>
>Several protocol are in a poor shape because early implementations
>were "liberal in what they accept"ed far beyond reasonable levels.

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

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

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

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

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

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

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

>  > 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, but that does support my observation about the asymmetry here.

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

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

>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. it would not be useful to send all of them.

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

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

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

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

Steve

From: Martin Rex <[email-masked]>
To: [email-masked] (Stephen Kent)
Date: Fri, 21 Jan 2011 17:45:52 +0100 (MET)
Cc: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol
Reply-To: [email-masked]

Stephen Kent wrote:
> 
> >
> >But the entity should expect that the reciepient checks the _offered_path_,
> >even when the recipient uses a different path for acutal certificate
> >path validation, and therefore entities should refrain from sending
> >a path that they themselves can easily determine to be invalid.
> 
> I disagree. The only path that is relevant to an RP is the one that 
> the RP chooses to employ for cert validation.

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

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

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

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

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

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

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

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

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

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

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

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

-Martin

Date: Fri, 21 Jan 2011 10:38:55 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol

At 3:42 PM +0100 1/21/11, Martin Rex wrote:
>Stephen Kent wrote:
>>  >
>>  >This really isn't a client-server issue, since both sides have a need
>>  >to, when necessary, authenticate themselves to the other.  Like anything
>>  >communicating over IP we should think of each side as a peer.
>>
>>  Sorry, I should have used more precise terminology. Each relying
>>  party gets to choose its TAs. The entity offering a cert is free to
>>  propose a TA (or a cert path terminating at a TA) to the other end,
>>  but it cannot mandate that the RP use that path.
>
>But the entity should expect that the reciepient checks the _offered_path_,
>even when the recipient uses a different path for acutal certificate
>path validation, and therefore entities should refrain from sending
>a path that they themselves can easily determine to be invalid.

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

>  > I know that the server can send a cert path to the client,
>  > but does TLS support the client sending other than an EE cert to the
>>  server?
>
>In TLS, when the server explicitly requests a client certificate,
>then the client must either indicate that it does not have a
>(suitable) client cert, or the client MUST send the FULL cert path.
>Only the the self-signed cert at the end of the path may be omitted.
>    http://tools.ietf.org/html/rfc2246#page-39
>
>Since the TLS Server is supposed to (in SSLv3&TLSv1.0 the server MUST)
>announce the certificate signers that it trusts, when it requests a
>client certificate, one may argue that sending a client certificate
>with cert path up to at least one of the trusted signers, as announced
>by the server, should be OK.

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

Steve

Date: Fri, 21 Jan 2011 10:28:17 -0500
To: Geoff Beier <[email-masked]>
From: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol

At 7:21 PM -0500 1/20/11, Geoff Beier wrote:
>On Thu, Jan 20, 2011 at 17:38, Stephen Kent <[email-masked]> wrote:
>>  Also, of course, TLS is NOT a peer protocol; the
>>  protocol distinguishes between client and server.  I know that the server
>>  can send a cert path to the client, but does TLS support the client sending
>>  other than an EE cert to the server?  In contrast, I believe IKEv2 does
>
>TLS does support this. From RFC 5246, section 7.4.6:
>
>"This message conveys the client's certificate chain to the server;
>the server will use it when verifying the CertificateVerify message"
>
>I've seen interoperability problems when the client sends a
>certification path that the server does not trust even though the
>server could build an alternative path using certificates in its own
>trust store. For example:
>
>Client's trust store contains Root A. Root A has issued a cert to CA
>B, which has issued a cert to CA C. The server sends CA C in the hint
>list. The client then sends its EE cert along with CA C, CA B and Root
>A in the Client Certificate message. The server's trust store contains
>root D, which has issued a cert to CA C. The server then rejects the
>client because the path the client sent doesn't terminate in root D,
>even though it should have enough information to trust the EE cert
>based on the cert its own trust anchor issued.
>
>That's a little hard to explain but isn't hypothetical at all. I've
>seen it in the wild. It comes about because people are much more
>likely to have narrowed their server's trust store than their
>client's, and some cert processing libraries have been known to prefer
>longer certification paths over shorter ones when choosing from
>multiple possible paths.
>
>Geoff

Geoff,

Thanks for the clarification.

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

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

Steve

From: Martin Rex <[email-masked]>
To: [email-masked] (Stephen Kent)
Date: Fri, 21 Jan 2011 15:42:38 +0100 (MET)
Cc: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol
Reply-To: [email-masked]

Stephen Kent wrote:
> >
> >This really isn't a client-server issue, since both sides have a need
> >to, when necessary, authenticate themselves to the other.  Like anything
> >communicating over IP we should think of each side as a peer.
> 
> Sorry, I should have used more precise terminology. Each relying 
> party gets to choose its TAs. The entity offering a cert is free to 
> propose a TA (or a cert path terminating at a TA) to the other end, 
> but it cannot mandate that the RP use that path.

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

>
> I know that the server can send a cert path to the client, 
> but does TLS support the client sending other than an EE cert to the 
> server?

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

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

-Martin

From: Geoff Beier <[email-masked]>
Date: Thu, 20 Jan 2011 19:21:49 -0500
To: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol

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

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

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

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

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

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

Geoff

Date: Thu, 20 Jan 2011 17:38:07 -0500
To: James Cloos <[email-masked]>
From: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol

At 5:33 PM -0500 1/18/11, James Cloos wrote:
>  >>>>> "SK" == Stephen Kent <[email-masked]> writes:
>
>>>  One possible usage of DANE would be to limit which specific CAs from
>>>  those considered valid CAs under the TLS X.509 PKI, are also valid
>>>  signers for a particular server or a particular DNS domain.
>
>SK> I understand the attraction for this notion, but it does conflict
>SK> with the concept that, ultimately, the client (software) gets to
>SK> make decisions of this sort.
>
>This really isn't a client-server issue, since both sides have a need
>to, when necessary, authenticate themselves to the other.  Like anything
>communicating over IP we should think of each side as a peer.

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

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

agreed.

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

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

Steve

Date: Thu, 20 Jan 2011 12:10:02 -0500
To: "Carl Wallace" <[email-masked]>
From: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol

At 10:30 AM -0500 1/20/11, Carl Wallace wrote:
>  > > Another approach is to include constraints in each TA definition and
>>  > enforce them during path validation (a la RFC 5914 and 5937).  No
>>  > subjugation required.
>>
>>  Either way, you're changing the TA from its published format (a
>self-signed
>>  certificate) to something else, and changing the contents of the
>cert/TA in
>>  the process (adding name constraints).  The only difference between
>these
>>  two proposals is whether you change TAs as published into certs signed
>>  under your own TA or just convert them all into RFC 5914 TAs.  The
>former,
>>  cert-based approach makes validation slightly easier, because there's
>lots of
>>  support for self-signed certs as TAs in crypto libraries and not so
>much RFC
>>  5914, but the two are really equivalent.
>
>The cert-based approach requires you to make revocation information
>available.

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

Steve

Date: Thu, 20 Jan 2011 12:07:32 -0500
To: "Carl Wallace" <[email-masked]>
From: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol

At 7:44 AM -0500 1/20/11, Carl Wallace wrote:
>  > >Without a single root, (name) constraints extensions simply dont
>work.
>>
>>  not true.
>>
>>  >The "cross-certification" hack subjugates a signer that was
>originally
>>  >born somewhere else under your own root with constraints in order to
>>  >make the (name) constraints work.
>>
>>  yes, that's what it does, and that's OK, because every RP is supposed
>to be
>>  able to choose its set of TAs.  One example of how to do this, the one
>>  proposed in the SIDR work, is to have every RP be its own TA, and
>>  "subjugate" every purported TA under the RP.
>
>Another approach is to include constraints in each TA definition and
>enforce them during path validation (a la RFC 5914 and 5937).  No
>subjugation required.

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

Steve

Content-class: urn:content-classes:message
Date: Thu, 20 Jan 2011 10:30:51 -0500
From: "Carl Wallace" <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol

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

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

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 20 Jan 2011 10:18:17 -0500
To: Carl Wallace <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol

>>> Without a single root, (name) constraints extensions simply dont
> work.
>>=20
>> not true.
>>=20
>>> The "cross-certification" hack subjugates a signer that was
> originally
>>> born somewhere else under your own root with constraints in order to
>>> make the (name) constraints work.
>>=20
>> yes, that's what it does, and that's OK, because every RP is supposed
> to be
>> able to choose its set of TAs.  One example of how to do this, the =
one
>> proposed in the SIDR work, is to have every RP be its own TA, and
>> "subjugate" every purported TA under the RP.
>=20
> Another approach is to include constraints in each TA definition and
> enforce them during path validation (a la RFC 5914 and 5937).  No
> subjugation required.

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

--Richard=20=

Content-class: urn:content-classes:message
Date: Thu, 20 Jan 2011 07:44:10 -0500
From: "Carl Wallace" <[email-masked]>
To: <[email-masked]>
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol

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

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

Date: Wed, 19 Jan 2011 18:57:23 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol

At 3:30 AM +0100 1/19/11, Martin Rex wrote:
>...
>
>I agree that support for multiple fully-equivalent signatures on
>a certificate, similar to multiple signers in PKCS#7, would be
>more than just complex to define (and process), especially in
>combination with the existing constraints and revocation architecture.

agreed

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

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

>
>>
>>  >  > One could enable users to manage the TAs offered by browser vendors
>>  >  > in ways that limit the scope of them, e.g., through the use of name
>>  >>  constraints.  See the work in the SIDR WG on local TA management, for
>>  >>  example (draft-ietf-sidr-ltamgmt-00.txt).
>>  >
>>  >Name Constraints have the prerequisite of a strict X.509 hierarchy
>>  >with only one single globally trusted root and another prerequisite
>>  >that name constraints are fully supported by the entire installed base.
>>
>>  The name constraints extension does not require a single root; it
>>  does require a hierarchic name space. Don't confuse hierarchic name
>>  spaces (like the DNS) and hierarchic CA models. As PHB noted, cross
>>  certification has long been a feature of X.509 and that implies
>>  support for non-hierarchic CA relationships.
>
>I don't think this is a correct characterization.

it is.

>Without a single root, (name) constraints extensions simply
>dont work.

not true.

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

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

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

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

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

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

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

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

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

Steve

Date: Wed, 19 Jan 2011 11:16:19 -0500
To: "Steingruebl, Andy" <[email-masked]>
From: Stephen Kent <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol

At 4:21 PM -0700 1/18/11, Steingruebl, Andy wrote:
>  > -----Original Message-----
>>  From: [email-masked] [mailto:[email-masked]] On
>>  Behalf Of Stephen Kent
>
>
>>  I see no reference to "CAA" in the charter.  To what does that acronym
>>  refer?
>
>DNS Certification Authority Authorization (CAA) Resource Record
>http://tools.ietf.org/html/draft-hallambaker-donotissue-01
>
>- Andy

thanks,

Steve

From: Martin Rex <[email-masked]>
To: [email-masked]
Date: Wed, 19 Jan 2011 04:56:16 +0100 (MET)
Cc: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol
Reply-To: [email-masked]

Martin Rex wrote:
> 
> > 
> > ... and with X.509 one could require that an EE cert for a server 
> > link to a specific TA (or set of TAs).
> 
> With X.509, this option is available only to the client, not the
> server and/or DNS admin.
> 
> One possible client-side solution for such a requirement would be
> "pinning" of a server cert (or a server cert signer) similar to what
> is described here:
>     http://www.w3.org/TR/wsc-ui/#selfsignedcerts
> 
> However some folks in the IETF decided to completely subvert this:
> http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-14#section-6.6.1
> 
> by having a name match of a cert from any CA under the TLS X.509 PKI
> _unconditionally_ override client cert pinning.

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

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

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

-Martin

From: Martin Rex <[email-masked]>
To: [email-masked] (Stephen Kent)
Date: Wed, 19 Jan 2011 03:30:51 +0100 (MET)
Cc: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol
Reply-To: [email-masked]

Stephen Kent wrote:
> 
> >
> >The issue that X.509 does not provide room for an additional signature
> >is an X.509/PKIX shortcoming.  Would X.509 provide room to accomodate
> >an secondary signature, then one would not need DNSSEC/DANE to convey
> >a secondary signature (authenticated through the independent DNS PKI).
> 
> It is a deliberate design decision. In X.509/PKIX the issuer takes 
> responsibility for the  certs that it issues, and it has sole 
> authority for revocation of those certs.  if one has multiple sigs, 
> the revocation policy becomes more complex, at best.
> (The X.509 CRL relies on uniqueness of the serial number
>  associated with a cert, and that is a per-CA identifier.)
> There is also the issue of chaining complexity re validation, etc.

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

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

> 
> >  > One could enable users to manage the TAs offered by browser vendors
> >  > in ways that limit the scope of them, e.g., through the use of name
> >>  constraints.  See the work in the SIDR WG on local TA management, for
> >>  example (draft-ietf-sidr-ltamgmt-00.txt).
> >
> >Name Constraints have the prerequisite of a strict X.509 hierarchy
> >with only one single globally trusted root and another prerequisite
> >that name constraints are fully supported by the entire installed base.
> 
> The name constraints extension does not require a single root; it 
> does require a hierarchic name space. Don't confuse hierarchic name 
> spaces (like the DNS) and hierarchic CA models. As PHB noted, cross 
> certification has long been a feature of X.509 and that implies 
> support for non-hierarchic CA relationships.

I don't think this is a correct characterization.

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

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

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

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

-Martin

Date: Tue, 18 Jan 2011 21:16:39 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] draft-ietf-dane-protocol-02 posted - RR name

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

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

> On 1/16/11 2:51 AM, Yaron Sheffer wrote:
>
>> Hi Paul,
>>
>> No, I am not taking any sides regarding support for protocols that are
>> not mentioned in the charter (which is Issue #5). Note that IPsec itself
>> is, in fact, already in the charter.
>>
>> Neither am I proposing to expand the scope of the current document
>> (which is Issue #17). I actually prefer the current focus.
>>
>> I am just proposing the make the record's *name* protocol-agnostic, so
>> it can be reused in the future without excuses.
>>
>
> Ah, I didn't realize this was a bikeshed discussion. :-) I would prefer to
> keep the name as tied to what we know it will be used for and let other
> people do deltas if they want.

Not a bikeshed discussion at all.

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

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

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

<br><br><div class=3D"gmail_quote">On Sun, Jan 16, 2011 at 11:00 AM, Paul H=
offman <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">paul.=
[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 1/16/11 2:51 AM, Yaron Sheffer wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Hi Paul,<br>
<br>
No, I am not taking any sides regarding support for protocols that are<br>
not mentioned in the charter (which is Issue #5). Note that IPsec itself<br=
>
is, in fact, already in the charter.<br>
<br>
Neither am I proposing to expand the scope of the current document<br>
(which is Issue #17). I actually prefer the current focus.<br>
<br>
I am just proposing the make the record&#39;s *name* protocol-agnostic, so<=
br>
it can be reused in the future without excuses.<br>
</blockquote>
<br></div>
Ah, I didn&#39;t realize this was a bikeshed discussion. :-) I would prefer=
 to keep the name as tied to what we know it will be used for and let other=
 people do deltas if they want.</blockquote><div><br></div><div><br></div>
<div>Not a bikeshed discussion at all.=A0</div><div><br></div><div>How stro=
ng is this &#39;preference&#39; of yours. Do you think it is worth actually=
 arguing over or do you just think that you should have your way because yo=
u don&#39;t think it important even though others do?</div>
</div><br>-- <br>Website: <a href=3D"http://hallambaker.com/">http://hallam=
baker.com/</a><br><br>

--00163662e65b725e10049a299b45--

Date: Tue, 18 Jan 2011 18:04:26 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] draft-ietf-dane-protocol

On 1/18/11 5:28 PM, Steve Schultze wrote:
> I'm in favor of a version of Matt's text in section 3.0:
>
> http://www.ietf.org/mail-archive/web/keyassure/current/msg00923.html
>
> Any reason why that's not a good idea?

We have so far chosen not to get into any nuts-and-bolts of DNSSEC 
checking, and this would send us far down that path. It is a big step, 
and we should consider it carefully. FWIW, I think we should take that 
step because we have gotten no support from the DNSEXT WG on last-mile 
DNSSEC, but I know others here don't agree.

> I'm not totally sure whether
> the text should go into the intro to section 3 or in 3.1.  I'm not
> really a fan of the "The preceding paragraph is probably wrong"
> parenthetical in 3.1.

Nor are Jakob and I, of course. But early honesty helps shine a 
spotlight on places that need work.

From: Steve Schultze <[email-masked]>
Date: Tue, 18 Jan 2011 20:28:21 -0500
To: [email-masked]
Subject: [keyassure] draft-ietf-dane-protocol

I'm in favor of a version of Matt's text in section 3.0:

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

Any reason why that's not a good idea?  I'm not totally sure whether the =
text should go into the intro to section 3 or in 3.1.  I'm not really a =
fan of the "The preceding paragraph is probably wrong" parenthetical in =
3.1.=

From: Steve Schultze <[email-masked]>
Date: Tue, 18 Jan 2011 20:01:17 -0500
To: [email-masked]
Subject: Re: [keyassure] draft-ietf-dane-protocol-02 posted - RR name

On Jan 16, 2011, at 11:00 AM, Paul Hoffman wrote:
> On 1/16/11 2:51 AM, Yaron Sheffer wrote:
>> Hi Paul,
>>=20
>> No, I am not taking any sides regarding support for protocols that =
are
>> not mentioned in the charter (which is Issue #5). Note that IPsec =
itself
>> is, in fact, already in the charter.
>>=20
>> Neither am I proposing to expand the scope of the current document
>> (which is Issue #17). I actually prefer the current focus.
>>=20
>> I am just proposing the make the record's *name* protocol-agnostic, =
so
>> it can be reused in the future without excuses.
>=20
> Ah, I didn't realize this was a bikeshed discussion. :-) I would =
prefer to keep the name as tied to what we know it will be used for and =
let other people do deltas if they want.

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

From: Martin Rex <[email-masked]>
To: [email-masked] (Phillip Hallam-Baker)
Date: Wed, 19 Jan 2011 01:45:43 +0100 (MET)
Cc: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol
Reply-To: [email-masked]

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

I guess we live in different universes.

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

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

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

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

> 
> The systems have already converged. PGP key signing has never enjoyed any
> real market success as a host authentication mechanism.

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

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

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

-Martin

From: "Steingruebl, Andy" <[email-masked]>
To: Stephen Kent <[email-masked]>
Date: Tue, 18 Jan 2011 16:21:55 -0700
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol

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

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

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

- Andy

Date: Tue, 18 Jan 2011 17:48:58 -0500
To: Paul Wouters <[email-masked]>
From: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol

At 3:51 PM -0500 1/18/11, Paul Wouters wrote:
>On Tue, 18 Jan 2011, Stephen Kent wrote:
>
>>>One possible usage of DANE would be to limit which specific CAs from
>>>those considered valid CAs under the TLS X.509 PKI, are also valid
>>>signers for a particular server or a particular DNS domain.
>>
>>I understand the attraction for this notion, but it does conflict with the
>>concept that, ultimately, the client (software) gets to make 
>>decisions of this sort.
>
>Leave that to the CAA draft please.
>
>Paul

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

Steve

Date: Tue, 18 Jan 2011 17:41:09 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol

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

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

>  > One could enable users to manage the TAs offered by browser vendors
>  > in ways that limit the scope of them, e.g., through the use of name
>>  constraints.  See the work in the SIDR WG on local TA management, for
>>  example (draft-ietf-sidr-ltamgmt-00.txt).
>
>Name Constraints have the prerequisite of a strict X.509 hierarchy
>with only one single globally trusted root and another prerequisite
>that name constraints are fully supported by the entire installed base.

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

Steve

From: James Cloos <[email-masked]>
To: [email-masked]
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABHNCSVQICAgIfAhkiAAAAI1J REFUOE+lU9ESgCAIg64P1y+ngUdxhl5H8wFbbM0OmUiEhKkCYaZThXCo6KE5sCbA1DDX3genvO4d eBQgEMaM5qy6uWk4SfBYfdu9jvBN9nSVDOKRtwb+I3epboOsOX5pZbJNsBJFvmQQ05YMfieIBnYX FK2N6dOawd97r/e8RjkTLzmMsiVgrAoEugtviCM3v2WzjgAAAABJRU5ErkJggg==
Copyright: Copyright 2009 James Cloos
OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
Date: Tue, 18 Jan 2011 17:33:07 -0500
Lines: 27
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol

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

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

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

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

So feel free to invert client and server below.

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

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

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

From: James Cloos <[email-masked]>
To: [email-masked]
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABHNCSVQICAgIfAhkiAAAAI1J REFUOE+lU9ESgCAIg64P1y+ngUdxhl5H8wFbbM0OmUiEhKkCYaZThXCo6KE5sCbA1DDX3genvO4d eBQgEMaM5qy6uWk4SfBYfdu9jvBN9nSVDOKRtwb+I3epboOsOX5pZbJNsBJFvmQQ05YMfieIBnYX FK2N6dOawd97r/e8RjkTLzmMsiVgrAoEugtviCM3v2WzjgAAAABJRU5ErkJggg==
Copyright: Copyright 2009 James Cloos
OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
Date: Tue, 18 Jan 2011 17:23:43 -0500
Lines: 23
Cc: Phillip Hallam-Baker <[email-masked]>
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol

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

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

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

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

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

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

From: James Cloos <[email-masked]>
To: [email-masked]
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABHNCSVQICAgIfAhkiAAAAI1J REFUOE+lU9ESgCAIg64P1y+ngUdxhl5H8wFbbM0OmUiEhKkCYaZThXCo6KE5sCbA1DDX3genvO4d eBQgEMaM5qy6uWk4SfBYfdu9jvBN9nSVDOKRtwb+I3epboOsOX5pZbJNsBJFvmQQ05YMfieIBnYX FK2N6dOawd97r/e8RjkTLzmMsiVgrAoEugtviCM3v2WzjgAAAABJRU5ErkJggg==
Copyright: Copyright 2009 James Cloos
OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
Date: Tue, 18 Jan 2011 16:47:15 -0500
Lines: 12
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

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

WK> Description:
WK> How to deal with multiple TLS-based services running under
WK> one domain name, such as a POP, IMAP, and SMTP server all
WK> running on mail.example.com.

DDDS seems to be a good fit.  Cf RFCs 3401-3404.

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

Date: Tue, 18 Jan 2011 13:40:29 -0800
From: =JeffH <[email-masked]>
To: IETF DANE WG list <[email-masked]>
Subject: [keyassure] fyi: DNSSEC practice statements and associated documents

FYI, there already has been a fair amount of work done w.r.t. wrapping policy, 
procedures, and conventions around the technical capabilities of DNSSEC, a la 
what is done in the PKIX/X.509 world. Here's some pointers to relevant 
documents and repositories...

DNSSEC Policy & Practice Statement Framework (DRAFT)
http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-dps-framework

Abstract

    This document presents a framework to assist writers of DNSSEC Policy
    and Practice Statements such as Domain Managers and Zone Operators on
    both the top-level and secondary level, who is managing and operating
    a DNS zone with Security Extensions (DNSSEC) implemented.

    In particular, the framework provides a comprehensive list of topics
    that should be considered for inclusion into a DNSSEC Policy
    definition and Practice Statement.

--

DPS framework (slides)
<http://brussels38.icann.org/meetings/brussels2010/presentation-dnssec-dps-framework-ljunggren-23jun10-en.pdf>

DNSSEC in Sweden: Five Years of Practical Experience (slides)
<http://www.gc-sec.org/Events/Documents/AnneMarie%20Amel-2010-06-Rome-DNSSEC-workshop.pdf>

Root DNSSEC docs
----------------

Root DNSSEC - documentation (many documents)
http://www.root-dnssec.org/documentation/

IANA DNSSEC Information
https://www.iana.org/dnssec/

Individual DPSs
---------------

DNSSEC Practice Statement for the Root Zone KSK Operator
https://www.iana.org/dnssec/icann-dps.txt

Verisign DNSSEC Practice Statements
(.net, .edu, Signing Services, root zone ZSK operator)
https://verisigninc.com/en_US/repository/index.xhtml

RIPE DNSSEC Policy and Practice Statement
http://www.ripe.net/rs/reverse/dnssec/dps.html

DNSSEC Practice Statement (DPS)  -- .se
http://www.iis.se/docs/se-dnssec-dps-eng.pdf

DNSSEC Practice Statement for the JP Zone (JP DPS)
https://jprs.jp/doc/dnssec/jp-dps-eng.html

---
end

From: Martin Rex <[email-masked]>
To: [email-masked] (Stephen Kent)
Date: Tue, 18 Jan 2011 22:34:10 +0100 (MET)
Cc: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol
Reply-To: [email-masked]

Stephen Kent wrote:
> 
> >In the existing TLS X.509 PKI there is currently no means for a server
> >or domain admin to limit/restrict which CAs are allowed to confirm
> >a server credential as valid.  Any single one will do.  And according
> >to this research:  http://www.eff.org/files/DefconSSLiverse.pdf
> >(page 19) there are plenty of CAs for attackers to choose from.
> 
> yep.
> 
> >DANE could become a band-aid to mitigate this PKIX security problem,
> >by establishing a secondary requirement vaguely similar to "dual control"
> >(http://www.yourwindow.to/information-security/gl_dualcontrol.htm)
> 
> this is NOT a PKIX problem. It is a browser design problem.

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

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

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

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

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

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

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

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

> 
> >One possible usage of DANE would be to limit which specific CAs from
> >those considered valid CAs under the TLS X.509 PKI, are also valid
> >signers for a particular server or a particular DNS domain.
> 
> I understand the attraction for this notion, but it does conflict with
> the concept that, ultimately, the client (software) gets to make 
> decisions of this sort.

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

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

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

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

> 
> >With the PGP web-of-trust model, it would be technically possible
> >to require any number of additional signers for a server credential
> >before it is considered valid.
> 
> yes, and with X.509 one could require that an EE cert for a server 
> link to a specific TA (or set of TAs).

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

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

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

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

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

-Martin

Date: Tue, 18 Jan 2011 15:51:29 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol

On Tue, 18 Jan 2011, Stephen Kent wrote:

>> One possible usage of DANE would be to limit which specific CAs from
>> those considered valid CAs under the TLS X.509 PKI, are also valid
>> signers for a particular server or a particular DNS domain.
>
> I understand the attraction for this notion, but it does conflict with the
> concept that, ultimately, the client (software) gets to make decisions of 
> this sort.

Leave that to the CAA draft please.

Paul

Date: Tue, 18 Jan 2011 15:48:08 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Nicholas Weaver <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

On Tue, 18 Jan 2011, Nicholas Weaver wrote:

> because otherwise, how do you know which port for which service, which is IMO, necessary to really get things to work?

The application that is about to do TLS knows what port the service is
running on. The only question is, should it lookup the TLSA data on
the hostname or on the <service-modifiers>.hostname.

The first will result in the app potentially looking through multiple TLSA
records before it finds a match (something it might need to support anyway)

I dont think there are that mant TLS services on a single host that this
is worth the extra complications of the service specifiers. Especially since
we're mostly talking about mail and web, and otherwise with custom apps
for TLS, the whole "service" lookup becomes tricky anyway.

Also, if in the future we want to optimise this and return these along
with A records, it would be much better if they are for the same FQDN
and not some _service._transport modifier.

So if we do modifiers, I would really want to be able to use the
non-modified method as well.

Paul

Date: Tue, 18 Jan 2011 13:30:11 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol

At 3:17 PM +0100 1/18/11, Martin Rex wrote:
>Stephen Kent wrote:
>>
>>  The use of the phrase "n-factor authentication" in your message does
>>  not match what is commonly accepted in the security field.  In
>>  multi-factor authentication the factors represent different types of
>>  authentication data, not multiple instances of auth data of the same
>>  type.
>
>You're correct.  The term(s) 2-Factor and Multi-Factor have been
>squatted by marketeers and regulators for a very specific purpose.
>
>
>I was trying to describe a specific security feature at an abstract
>level using invalid terminology.

agreed.

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

agreed

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

yep.

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

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

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

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

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

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

>But in order to gauge the effective security, one needs to look at
>the overall picture not just one specific procedure.
>
>The TLS X.509 PKI traditionally has weaknesses, because it keys off
>the WHOIS database for issuing server certs, and some CA issuing procedures
>involven unauthenticated SMTP Email.  DANE will inherit its properties
>from the DNS administration procedures, so what matters is the difficulty
>of getting malicious DNS records into the DNS database that feeds
>into the automatic DNSSEC record signing service.

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

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

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

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

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

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

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

Steve

Date: Tue, 18 Jan 2011 14:15:40 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

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

On Tue, Jan 18, 2011 at 1:12 PM, Simon Josefsson <[email-masked]>wrote:

> Nicholas Weaver <[email-masked]> writes:
>
> > Isn't this the whole point of SRV records?  Why shouldn't we do them,
> with the natural DNSSEC authenticated flow of using the SRV record(s) to
> find the ports, and then lookup the key(s) associated with the ports
> selected.
> >
> > (hostname, service) -> Lookup SRV -> (hostname, port)+ -> Lookup keys by
> ports -> (hostname, port, key)+
>
> Many applications does not work like that today.  Users are typically
> asked to enter a hostname, and can provide an optional port number if
> the default port number for the application protocol (e.g., 25 for smtp)
> is not the intended port.
>
> I believe DANE should be agnostic of whether SRV are used or not.  Thus
> DANE could support both these look mechanisms:
>
> 1) SRV record used
>
> (hostname, service) -> Lookup SRV -> (hostname, port)+ -> Lookup keys by
> ports -> (hostname, port, key)+
>
> 2) SRV record not used
>
> (hostname, port)+ -> Lookup keys by ports -> (hostname, port, key)+
>
> This appears to be another argument for the option to prefix the
> hostname with a port number (not service), as in:
>
>
I agree.

Having the ability to declare a site wide policy is going to be totally fine
for many sites and completely meet their needs.

Other sites are going to need to have more fine control on their trust
configuration because they do things that are either more complex or involve
outsourcing or for other reasons.

I don't see any problem in having a scheme that supports more than one layer
of detail, particularly when the constraints imposed by DNS wildcards and
CNAMES are considered.

Those constraints mean that it is not possible to use prefix records in the
way that we would want to use them unless the prefix is attached to a name
that is canonical.

So any discovery scheme would have to have at least two stages:

Stage 1: Lookup the domain name without prefix, collect general records.

This stage could return a flag that says 'more detailed information
available' which would trigger a stage 2

Stage 2: Lookup protocol prefixed records for the service

This would be where SRV records would be handled and could be the place
where additional, more specific keying information is dealt with.

This could if necessary then trigger a third layer of resolution that would
be specific to the host.

Stage 3: Lookup protocol and port prefixed records for the host

Although such discovery requires three logical round trips it is entirely
feasible to elide this and combine all the round trips into one through use
of ENDS(0) extensions.

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

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

<br><br><div class=3D"gmail_quote">On Tue, Jan 18, 2011 at 1:12 PM, Simon J=
osefsson <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">simon=
@josefsson.org</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">Nicholas Weaver &lt;<a href=3D"mailto:[email-masked]=
ey.edu">[email-masked]</a>&gt; writes:<br>
<br>
&gt; Isn&#39;t this the whole point of SRV records? =A0Why shouldn&#39;t we=
 do them, with the natural DNSSEC authenticated flow of using the SRV recor=
d(s) to find the ports, and then lookup the key(s) associated with the port=
s selected.<br>

&gt;<br>
&gt; (hostname, service) -&gt; Lookup SRV -&gt; (hostname, port)+ -&gt; Loo=
kup keys by ports -&gt; (hostname, port, key)+<br>
<br>
</div>Many applications does not work like that today. =A0Users are typical=
ly<br>
asked to enter a hostname, and can provide an optional port number if<br>
the default port number for the application protocol (e.g., 25 for smtp)<br=
>
is not the intended port.<br>
<br>
I believe DANE should be agnostic of whether SRV are used or not. =A0Thus<b=
r>
DANE could support both these look mechanisms:<br>
<br>
1) SRV record used<br>
<div class=3D"im"><br>
(hostname, service) -&gt; Lookup SRV -&gt; (hostname, port)+ -&gt; Lookup k=
eys by ports -&gt; (hostname, port, key)+<br>
<br>
</div>2) SRV record not used<br>
<div class=3D"im"><br>
(hostname, port)+ -&gt; Lookup keys by ports -&gt; (hostname, port, key)+<b=
r>
<br>
</div>This appears to be another argument for the option to prefix the<br>
hostname with a port number (not service), as in:<br><br></blockquote><div>=
<br></div><div>I agree.</div><div><br></div><div>Having the ability to decl=
are a site wide policy is going to be totally fine for many sites and compl=
etely meet their needs.</div>
<div><br></div><div>Other sites are going to need to have more fine control=
 on their trust configuration because they do things that are either more c=
omplex or involve outsourcing or for other reasons.</div><div><br></div>
<div><br></div><div>I don&#39;t see any problem in having a scheme that sup=
ports more than one layer of detail, particularly when the constraints impo=
sed by DNS wildcards and CNAMES are considered.</div><div><br></div><div>
Those constraints mean that it is not possible to use prefix records in the=
 way that we would want to use them unless the prefix is attached to a name=
 that is canonical.</div><div><br></div><div><br></div><div>So any discover=
y scheme would have to have at least two stages:</div>
<div><br></div><div>Stage 1: Lookup the domain name without prefix, collect=
 general records.</div><div><br></div><div>This stage could return a flag t=
hat says &#39;more detailed information available&#39; which would trigger =
a stage 2</div>
<div><br></div><div>Stage 2: Lookup protocol prefixed records for the servi=
ce</div><div><br></div><div>This would be where SRV records would be handle=
d and could be the place where additional, more specific keying information=
 is dealt with.</div>
<div><br></div><div>This could if necessary then trigger a third layer of r=
esolution that would be specific to the host.</div><div><br></div><div>Stag=
e 3: Lookup protocol and port prefixed records for the host</div><div><br>
</div><div><br></div><div>Although such discovery requires three logical ro=
und trips it is entirely feasible to elide this and combine all the round t=
rips into one through use of ENDS(0) extensions.</div></div><br>-- <br>
Website: <a href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br=
><br>

--0016e644d5cceb0fd1049a23b9a1--

From: "Steingruebl, Andy" <[email-masked]>
To: Paul Wouters <[email-masked]>, Paul Hoffman <[email-masked]>
Date: Tue, 18 Jan 2011 11:45:52 -0700
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Possible fix for pkix/dane certificate disagreement

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

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

- Andy

From: Simon Josefsson <[email-masked]>
To: Nicholas Weaver <[email-masked]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 18 Jan 2011 19:12:22 +0100
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

Nicholas Weaver <[email-masked]> writes:

> Isn't this the whole point of SRV records?  Why shouldn't we do them, with the natural DNSSEC authenticated flow of using the SRV record(s) to find the ports, and then lookup the key(s) associated with the ports selected.
>
> (hostname, service) -> Lookup SRV -> (hostname, port)+ -> Lookup keys by ports -> (hostname, port, key)+

Many applications does not work like that today.  Users are typically
asked to enter a hostname, and can provide an optional port number if
the default port number for the application protocol (e.g., 25 for smtp)
is not the intended port.

I believe DANE should be agnostic of whether SRV are used or not.  Thus
DANE could support both these look mechanisms:

1) SRV record used

(hostname, service) -> Lookup SRV -> (hostname, port)+ -> Lookup keys by ports -> (hostname, port, key)+

2) SRV record not used

(hostname, port)+ -> Lookup keys by ports -> (hostname, port, key)+

This appears to be another argument for the option to prefix the
hostname with a port number (not service), as in:

_110.mail.example.org IN ...

/Simon

From: Simon Josefsson <[email-masked]>
To: Paul Hoffman <[email-masked]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 18 Jan 2011 19:07:37 +0100
Cc: [email-masked]
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

Paul Hoffman <[email-masked]> writes:

> On 1/18/11 5:01 AM, Simon Josefsson wrote:
>> Warren Kumari<[email-masked]>  writes:
>>
>>> I was hoping that would be able to stick to one open item at a time
>>> but the discussions on #17 (Should the first doc be TLS only or try be
>>> everything to everyone?) has wrapped directly to this issue, so:
>>>
>>> I'm opening up Issue #1 (Deal with multiple TLS-based services under
>>> one domain name (http://trac.tools.ietf.org/wg/dane/trac/ticket/1))
>>> [ Dons frock, flaps hands, twirls the incense burner three times to
>>> the left,  presses button to make water squirt out of daisy add
>>> releases the 12 doves -- now it is official ]
>>> -----
>>> Description:
>>> How to deal with multiple TLS-based services running under one domain
>>> name, such as a POP, IMAP, and SMTP server all running on
>>> mail.example.com.
>>>
>>> Suggestions so far include:
>>> Prefacing the host name with a service name (_pop.mail.example.com)
>>> Prefacing the host name with a port number (_110.mail.example.com)
>>> Returning a set of records that contain port numbers in the response.
>>> SRV / ESRV
>>>
>>> -----
>>
>> I believe this is an important problem that must be supported.  I
>> brought this up earlier:
>>
>> http://www.ietf.org/mail-archive/web/keyassure/current/msg00834.html
>>
>> Service names are not sufficient here, since you can have a SMTP server
>> listening on port 25, 80, 587, 4711, 11147 etc and using the service
>> name would not differentiate these but that may be important.
>>
>> A combination of service name and port number, like
>> _4711._smtp.mail.example.com, is another option and does carry more
>> information than only port numbers would -- however it is not clear to
>> me if this has any practical advantage.
>>
>> Port numbers could be easier to implement -- depending on
>> implementations, parts of this could be done by the TLS library, and it
>> often does not know what kind of application protocol is running on top
>> of TLS.
>
> When you say "port numbers could be easier to implement", do you port
> numbers in "Prefacing the host name..." or "Returning a set of
> records..."?

I mean "Prefacing the host name...".

I don't immediately see how SRV would be used here, so I don't have an
opinion on that approach.  Maybe someone could add an example, similar
to the existing examples for the other proposals, to this ticket?

/Simon

From: Nicholas Weaver <[email-masked]>
Date: Tue, 18 Jan 2011 09:57:21 -0800
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

On Jan 18, 2011, at 9:37 AM, Paul Hoffman wrote:

> On 1/18/11 8:27 AM, Nicholas Weaver wrote:
>>=20
>> On Jan 18, 2011, at 8:01 AM, Paul Hoffman wrote:
>>>>=20
>>>> I believe this is an important problem that must be supported.  I
>>>> brought this up earlier:
>>>>=20
>>>> =
http://www.ietf.org/mail-archive/web/keyassure/current/msg00834.html
>>>>=20
>>>> Service names are not sufficient here, since you can have a SMTP =
server
>>>> listening on port 25, 80, 587, 4711, 11147 etc and using the =
service
>>>> name would not differentiate these but that may be important.
>>>>=20
>>>> A combination of service name and port number, like
>>>> _4711._smtp.mail.example.com, is another option and does carry more
>>>> information than only port numbers would -- however it is not clear =
to
>>>> me if this has any practical advantage.
>>>>=20
>>>> Port numbers could be easier to implement -- depending on
>>>> implementations, parts of this could be done by the TLS library, =
and it
>>>> often does not know what kind of application protocol is running on =
top
>>>> of TLS.
>>>=20
>>> When you say "port numbers could be easier to implement", do you =
port numbers in "Prefacing the host name..." or "Returning a set of =
records..."?
>>=20
>> Isn't this the whole point of SRV records?  Why shouldn't we do them, =
with the natural DNSSEC authenticated flow of using the SRV record(s) to =
find the ports, and then lookup the key(s) associated with the ports =
selected.
>=20
> Yes. However, that doesn't answer the question in issue #1, which is =
why I was asking Simon (and now you) for clarification on which solution =
you prefer for the protocol.
>=20
>> (hostname, service) ->  Lookup SRV ->  (hostname, port)+ ->  Lookup =
keys by ports ->  (hostname, port, key)+
>>=20
>> Yes, this adds an additional RTT of lookup latency for the SRV =
lookup, but since there is a common (but not always universal) mapping =
of service to common ports, you could do, in parallel [1]
>> (host, service) ->  Lookup SRV
>> (host, port)    ->  Lookup Speculative Key
>=20
> This sounds like you prefer "Prefacing the host name with a port =
number (_110.mail.example.com)" over "Returning a set of records that =
contain port numbers in the response", but you (and Simon) were not =
specific.

I think the answer depends on if you are using SRV or not:

So with SRV, I'd personally like the convention of

_service._transport.hostname=20
_smtp._tcp.mail.example.com SRV -> 0 5 25 mail.example.com

_25._tcp.mail.example.com NEW_RR -> key =
material/thumbprint/certificate/whatever.

So yeah, I'd personally like a split model:

SRV is used to find the port for a service
the key record is used to find the key on a port.

Without using SRV, you'd need to have a combined record
_service._transport.hostname -> key material + port number

because otherwise, how do you know which port for which service, which =
is IMO, necessary to really get things to work?

Date: Tue, 18 Jan 2011 09:37:09 -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 1/18/11 8:27 AM, Nicholas Weaver wrote:
>
> On Jan 18, 2011, at 8:01 AM, Paul Hoffman wrote:
>>>
>>> I believe this is an important problem that must be supported.  I
>>> brought this up earlier:
>>>
>>> http://www.ietf.org/mail-archive/web/keyassure/current/msg00834.html
>>>
>>> Service names are not sufficient here, since you can have a SMTP server
>>> listening on port 25, 80, 587, 4711, 11147 etc and using the service
>>> name would not differentiate these but that may be important.
>>>
>>> A combination of service name and port number, like
>>> _4711._smtp.mail.example.com, is another option and does carry more
>>> information than only port numbers would -- however it is not clear to
>>> me if this has any practical advantage.
>>>
>>> Port numbers could be easier to implement -- depending on
>>> implementations, parts of this could be done by the TLS library, and it
>>> often does not know what kind of application protocol is running on top
>>> of TLS.
>>
>> When you say "port numbers could be easier to implement", do you port numbers in "Prefacing the host name..." or "Returning a set of records..."?
>
> Isn't this the whole point of SRV records?  Why shouldn't we do them, with the natural DNSSEC authenticated flow of using the SRV record(s) to find the ports, and then lookup the key(s) associated with the ports selected.

Yes. However, that doesn't answer the question in issue #1, which is why 
I was asking Simon (and now you) for clarification on which solution you 
prefer for the protocol.

> (hostname, service) ->  Lookup SRV ->  (hostname, port)+ ->  Lookup keys by ports ->  (hostname, port, key)+
>
> Yes, this adds an additional RTT of lookup latency for the SRV lookup, but since there is a common (but not always universal) mapping of service to common ports, you could do, in parallel [1]
> (host, service) ->  Lookup SRV
> (host, port)    ->  Lookup Speculative Key

This sounds like you prefer "Prefacing the host name with a port number 
(_110.mail.example.com)" over "Returning a set of records that contain 
port numbers in the response", but you (and Simon) were not specific.

> And use the speculative lookup if the SRV matches.

I think this will be a likely action by applications.

From: Nicholas Weaver <[email-masked]>
Date: Tue, 18 Jan 2011 08:27:55 -0800
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

On Jan 18, 2011, at 8:01 AM, Paul Hoffman wrote:
>>=20
>> I believe this is an important problem that must be supported.  I
>> brought this up earlier:
>>=20
>> http://www.ietf.org/mail-archive/web/keyassure/current/msg00834.html
>>=20
>> Service names are not sufficient here, since you can have a SMTP =
server
>> listening on port 25, 80, 587, 4711, 11147 etc and using the service
>> name would not differentiate these but that may be important.
>>=20
>> A combination of service name and port number, like
>> _4711._smtp.mail.example.com, is another option and does carry more
>> information than only port numbers would -- however it is not clear =
to
>> me if this has any practical advantage.
>>=20
>> Port numbers could be easier to implement -- depending on
>> implementations, parts of this could be done by the TLS library, and =
it
>> often does not know what kind of application protocol is running on =
top
>> of TLS.
>=20
> When you say "port numbers could be easier to implement", do you port =
numbers in "Prefacing the host name..." or "Returning a set of =
records..."?

Isn't this the whole point of SRV records?  Why shouldn't we do them, =
with the natural DNSSEC authenticated flow of using the SRV record(s) to =
find the ports, and then lookup the key(s) associated with the ports =
selected.

(hostname, service) -> Lookup SRV -> (hostname, port)+ -> Lookup keys by =
ports -> (hostname, port, key)+

Yes, this adds an additional RTT of lookup latency for the SRV lookup, =
but since there is a common (but not always universal) mapping of =
service to common ports, you could do, in parallel [1]
(host, service) -> Lookup SRV
(host, port)    -> Lookup Speculative Key

And use the speculative lookup if the SRV matches.

And its not like there are going to be many cases where a =
middlebox/proxy/server barfs on SRV records but allows the key-lookup =
records.

[1] Given how aggressively browsers prefetch A records these days, this =
seems like a trivial increase in overhead by comparison.

Date: Tue, 18 Jan 2011 08:01:05 -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 1/18/11 5:01 AM, Simon Josefsson wrote:
> Warren Kumari<[email-masked]>  writes:
>
>> I was hoping that would be able to stick to one open item at a time
>> but the discussions on #17 (Should the first doc be TLS only or try be
>> everything to everyone?) has wrapped directly to this issue, so:
>>
>> I'm opening up Issue #1 (Deal with multiple TLS-based services under
>> one domain name (http://trac.tools.ietf.org/wg/dane/trac/ticket/1))
>> [ Dons frock, flaps hands, twirls the incense burner three times to
>> the left,  presses button to make water squirt out of daisy add
>> releases the 12 doves -- now it is official ]
>> -----
>> Description:
>> How to deal with multiple TLS-based services running under one domain
>> name, such as a POP, IMAP, and SMTP server all running on
>> mail.example.com.
>>
>> Suggestions so far include:
>> Prefacing the host name with a service name (_pop.mail.example.com)
>> Prefacing the host name with a port number (_110.mail.example.com)
>> Returning a set of records that contain port numbers in the response.
>> SRV / ESRV
>>
>> -----
>
> I believe this is an important problem that must be supported.  I
> brought this up earlier:
>
> http://www.ietf.org/mail-archive/web/keyassure/current/msg00834.html
>
> Service names are not sufficient here, since you can have a SMTP server
> listening on port 25, 80, 587, 4711, 11147 etc and using the service
> name would not differentiate these but that may be important.
>
> A combination of service name and port number, like
> _4711._smtp.mail.example.com, is another option and does carry more
> information than only port numbers would -- however it is not clear to
> me if this has any practical advantage.
>
> Port numbers could be easier to implement -- depending on
> implementations, parts of this could be done by the TLS library, and it
> often does not know what kind of application protocol is running on top
> of TLS.

When you say "port numbers could be easier to implement", do you port 
numbers in "Prefacing the host name..." or "Returning a set of records..."?

Date: Tue, 18 Jan 2011 07:59:24 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious?

On 1/18/11 4:47 AM, Simon Josefsson wrote:
> Ondøej Surý<[email-masked]>  writes:
>
>> On 16.1.2011 15:27, Simon Josefsson wrote:
>>> As a reminder, TLS supports more than X.509.  The current draft is
>>> hard wired for X.509 only.
>>
>> Can we untie the draft from X.509?
>
> It is technically simple to do (compare my draft with the current one),
> but the impression I got was that authors preferred not to.

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

Date: Tue, 18 Jan 2011 07:56:02 -0800
From: Paul Hoffman <[email-masked]>
To: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] what PKIX is not

Thank you very much for this! It helps move the discussion forwards.

On 1/17/11 2:59 PM, Stephen Kent wrote:
> I've seen several references to PKIX in the context of TLS that suggest
> some confusion.
>
> It appears that some folks believe that the trust anchor (TA) management
> model that browsers have adopted is somehow a PKIX-based requirement.
> That is not true. Browser vendors have adopted a TA model that is
> generally compliant with what X.509 and PKIX require, but neither X.509
> nor PKIX mandate that model. So, for example, if DANE defines a way to
> distribute TAs via the DNS, that will not conflict with PKIX standards.

We currently don't talk in the document about the certificate 
association made by TLSA types 3 and 4 as being temporary trust anchors, 
but if we did so, it might clear up any confusion that people have about 
the relationship between TLSA and PKIX.

> The checks used to validate a TA are not specified in the core PKIX
> specs. (We do have other standards the define ways to deliver and
> validate TA material, but they are not the only game in town, e.g., see
> the SIDR WG spec on how to do this.) Section 6.1.1 of RFC 5280 says that
> the TA info used to validate a cert path includes
>
> (1) the trusted issuer name,
>
> (2) the trusted public key algorithm,
>
> (3) the trusted public key, and
>
> (4) optionally, the trusted public key parameters associated
> with the public key.
>
> So, if DANE defines a way to populate items 1-3 (and, optionally 4) from
> data acquired from the DNS, it can satisfy the 5280 requirements for a
> TA. This could be dine via a self-signed cert, or even using a raw key.
> It's up to DANE to decide what checks it imposes on the data it
> retrieves from the DNS before using that data to validate an EE cert for
> a TLS server, for example.

We can clear this up for types 3 and 4 by saying that the trust anchors 
gotten from TLSA act as full trust anchors for the client for the life 
of the TTL of the TLSA RR.

> If DANE decides that it will use a raw key from the DNS directly in a
> TLS handshake, for example, then it moves outside the PKIX/X.509 realm,
> as no certs are being validated. DANE would then need to decide what, if
> any, constraints it would impose of how the key is used, e.g., matched
> to the DNS name for a server.

Exactly. We could clear up types 1 and 2 by not calling them 
certificates but instead binary blobs that are compared against the 
first binary blob in the TLS "Certificate" structure. That way, if there 
is later a standards-track update to TLS to allow OpenPGP certs or bare 
keys or whatnot, TLSA will already work with those.

Date: Tue, 18 Jan 2011 10:14:49 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol

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

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

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

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

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

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

On Tue, Jan 18, 2011 at 9:17 AM, Martin Rex <[email-masked]> wrote:

> Stephen Kent wrote:
> >
> > The use of the phrase "n-factor authentication" in your message does
> > not match what is commonly accepted in the security field.  In
> > multi-factor authentication the factors represent different types of
> > authentication data, not multiple instances of auth data of the same
> > type.
>
> You're correct.  The term(s) 2-Factor and Multi-Factor have been
> squatted by marketeers and regulators for a very specific purpose.
>
>
> I was trying to describe a specific security feature at an abstract
> level using invalid terminology.
>
> X.509/PKIX credentials are confirmed as valid with one single digital
> signature. There is no means (native to X.509) to require multiple
> independent signatures (logical "AND").  On the contrary, when there
> are multiple omipotent CA trusted as credential signers (logical "OR"),
> then the bottom-line security is significantly impaired.
>
> In the existing TLS X.509 PKI there is currently no means for a server
> or domain admin to limit/restrict which CAs are allowed to confirm
> a server credential as valid.  Any single one will do.  And according
> to this research:  http://www.eff.org/files/DefconSSLiverse.pdf
> (page 19) there are plenty of CAs for attackers to choose from.
>
>
> DANE could become a band-aid to mitigate this PKIX security problem,
> by establishing a secondary requirement vaguely similar to "dual control"
> (http://www.yourwindow.to/information-security/gl_dualcontrol.htm)
>
> One possible usage of DANE would be to limit which specific CAs from
> those considered valid CAs under the TLS X.509 PKI, are also valid
> signers for a particular server or a particular DNS domain.
>
> With the PGP web-of-trust model, it would be technically possible
> to require any number of additional signers for a server credential
> before it is considered valid.
>
>
> But in order to gauge the effective security, one needs to look at
> the overall picture not just one specific procedure.
>
> The TLS X.509 PKI traditionally has weaknesses, because it keys off
> the WHOIS database for issuing server certs, and some CA issuing procedures
> involven unauthenticated SMTP Email.  DANE will inherit its properties
> from the DNS administration procedures, so what matters is the difficulty
> of getting malicious DNS records into the DNS database that feeds
> into the automatic DNSSEC record signing service.
>
>
> Two factor authentication schemes for humans may have similar problems.
> Although an authentication scheme involving a fingerprint and a token
> counts as two factor, a successful attack on this scheme usually
> requires only one single assault on one person.
>
>
> Similarly, a procedure to register/establish new multi-factor
> authentication
> credentials might require only one single proof of identity (ID-card).
>
>
> Requiring multiple signatures on a server key in a PGP web-of-trust style
> may improve security.  But if all of the necessary signatures can be
> obtained with the exact same "proof of ownership", then this mostly
> adds complexity without value (it would only protect from exploration
> of accidental unique flaws in the validation/issuing procedures
> of individual signers).
>
>
> -Martin
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

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

Martin seems to be referring to the original PGP paper rather than the code=
 that Phil Z. actually implemented.<div><br></div><div><br></div><div>In pr=
actice X.509 started to absorb features from PGP very early on. The single =
rooted hierarchy was gone in 1995 and cross certification was introduced ab=
out the same time and is increasingly deployed and used.</div>
<div><br></div><div>In practice it has been possible to do everything that =
can be done in PGP in X.509 for some time now. The only practical differenc=
e is that in PGP everyone is a trust provider and every key can be used for=
 trust provision and in X.509 anyone can be a trust provider but this is a =
distinct role and the keys used for this purpose are separate from end enti=
ty keys.</div>
<div><br></div><div><br></div><div>The systems have already converged. PGP =
key signing has never enjoyed any real market success as a host authenticat=
ion mechanism and even if it had the idea of a monolithic PKI hierarchy lik=
e DNSSEC is entirely antithetical to the PGP design goals.</div>
<div><br></div><div>Its like demanding that the Playboy mansion car park be=
 redesigned to accomodate the Pope-mobile.</div><div><br></div><div><br></d=
iv><div><br><div class=3D"gmail_quote">On Tue, Jan 18, 2011 at 9:17 AM, Mar=
tin Rex <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">[email-masked]<=
/a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;">Stephen Kent wrote:<br>
&gt;<br>
&gt; The use of the phrase &quot;n-factor authentication&quot; in your mess=
age does<br>
&gt; not match what is commonly accepted in the security field. =A0In<br>
&gt; multi-factor authentication the factors represent different types of<b=
r>
&gt; authentication data, not multiple instances of auth data of the same<b=
r>
&gt; type.<br>
<br>
You&#39;re correct. =A0The term(s) 2-Factor and Multi-Factor have been<br>
squatted by marketeers and regulators for a very specific purpose.<br>
<br>
<br>
I was trying to describe a specific security feature at an abstract<br>
level using invalid terminology.<br>
<br>
X.509/PKIX credentials are confirmed as valid with one single digital<br>
signature. There is no means (native to X.509) to require multiple<br>
independent signatures (logical &quot;AND&quot;). =A0On the contrary, when =
there<br>
are multiple omipotent CA trusted as credential signers (logical &quot;OR&q=
uot;),<br>
then the bottom-line security is significantly impaired.<br>
<br>
In the existing TLS X.509 PKI there is currently no means for a server<br>
or domain admin to limit/restrict which CAs are allowed to confirm<br>
a server credential as valid. =A0Any single one will do. =A0And according<b=
r>
to this research: =A0<a href=3D"http://www.eff.org/files/DefconSSLiverse.pd=
f" target=3D"_blank">http://www.eff.org/files/DefconSSLiverse.pdf</a><br>
(page 19) there are plenty of CAs for attackers to choose from.<br>
<br>
<br>
DANE could become a band-aid to mitigate this PKIX security problem,<br>
by establishing a secondary requirement vaguely similar to &quot;dual contr=
ol&quot;<br>
(<a href=3D"http://www.yourwindow.to/information-security/gl_dualcontrol.ht=
m" target=3D"_blank">http://www.yourwindow.to/information-security/gl_dualc=
ontrol.htm</a>)<br>
<br>
One possible usage of DANE would be to limit which specific CAs from<br>
those considered valid CAs under the TLS X.509 PKI, are also valid<br>
signers for a particular server or a particular DNS domain.<br>
<br>
With the PGP web-of-trust model, it would be technically possible<br>
to require any number of additional signers for a server credential<br>
before it is considered valid.<br>
<br>
<br>
But in order to gauge the effective security, one needs to look at<br>
the overall picture not just one specific procedure.<br>
<br>
The TLS X.509 PKI traditionally has weaknesses, because it keys off<br>
the WHOIS database for issuing server certs, and some CA issuing procedures=
<br>
involven unauthenticated SMTP Email. =A0DANE will inherit its properties<br=
>
from the DNS administration procedures, so what matters is the difficulty<b=
r>
of getting malicious DNS records into the DNS database that feeds<br>
into the automatic DNSSEC record signing service.<br>
<br>
<br>
Two factor authentication schemes for humans may have similar problems.<br>
Although an authentication scheme involving a fingerprint and a token<br>
counts as two factor, a successful attack on this scheme usually<br>
requires only one single assault on one person.<br>
<br>
<br>
Similarly, a procedure to register/establish new multi-factor authenticatio=
n<br>
credentials might require only one single proof of identity (ID-card).<br>
<br>
<br>
Requiring multiple signatures on a server key in a PGP web-of-trust style<b=
r>
may improve security. =A0But if all of the necessary signatures can be<br>
obtained with the exact same &quot;proof of ownership&quot;, then this most=
ly<br>
adds complexity without value (it would only protect from exploration<br>
of accidental unique flaws in the validation/issuing procedures<br>
of individual signers).<br>
<br>
<br>
-Martin<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>
</blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a href=3D"htt=
p://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--0016e644bc2e916828049a205cbf--

From: Martin Rex <[email-masked]>
To: [email-masked] (Stephen Kent)
Date: Tue, 18 Jan 2011 15:17:17 +0100 (MET)
Cc: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol
Reply-To: [email-masked]

Stephen Kent wrote:
> 
> The use of the phrase "n-factor authentication" in your message does 
> not match what is commonly accepted in the security field.  In 
> multi-factor authentication the factors represent different types of 
> authentication data, not multiple instances of auth data of the same 
> type.

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

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

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

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

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

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

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

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

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

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

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

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

-Martin

From: Simon Josefsson <[email-masked]>
To: Warren Kumari <[email-masked]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 18 Jan 2011 14:01:09 +0100
Cc: [email-masked]
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

Warren Kumari <[email-masked]> writes:

> I was hoping that would be able to stick to one open item at a time
> but the discussions on #17 (Should the first doc be TLS only or try be
> everything to everyone?) has wrapped directly to this issue, so:
>
> I'm opening up Issue #1 (Deal with multiple TLS-based services under
> one domain name (http://trac.tools.ietf.org/wg/dane/trac/ticket/1))
> [ Dons frock, flaps hands, twirls the incense burner three times to
> the left,  presses button to make water squirt out of daisy add
> releases the 12 doves -- now it is official ]
> -----
> Description:
> How to deal with multiple TLS-based services running under one domain
> name, such as a POP, IMAP, and SMTP server all running on
> mail.example.com.
>
> Suggestions so far include:
> Prefacing the host name with a service name (_pop.mail.example.com)
> Prefacing the host name with a port number (_110.mail.example.com)
> Returning a set of records that contain port numbers in the response.
> SRV / ESRV
>
> -----

I believe this is an important problem that must be supported.  I
brought this up earlier:

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

Service names are not sufficient here, since you can have a SMTP server
listening on port 25, 80, 587, 4711, 11147 etc and using the service
name would not differentiate these but that may be important.

A combination of service name and port number, like
_4711._smtp.mail.example.com, is another option and does carry more
information than only port numbers would -- however it is not clear to
me if this has any practical advantage.

Port numbers could be easier to implement -- depending on
implementations, parts of this could be done by the TLS library, and it
often does not know what kind of application protocol is running on top
of TLS.

/Simon

From: Simon Josefsson <[email-masked]>
To: =?iso-8859-2?Q?Ond=F8ej_Sur=FD?= <[email-masked]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Tue, 18 Jan 2011 13:47:52 +0100
Cc: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious?

Ond=F8ej Sur=FD <[email-masked]> writes:

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

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

/Simon

From: Jakob Schlyter <[email-masked]>
Date: Tue, 18 Jan 2011 10:42:29 +0100
To: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= <[email-masked]>
Cc: [email-masked], Phillip Hallam-Baker <[email-masked]>
Subject: Re: [keyassure] Multiple services at one name (issue #1)

On 18 jan 2011, at 08.46, Ond=C5=99ej Sur=C3=BD wrote:

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

Correct, we have two different mechanisms:

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

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

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

Phil; does this separation make sense?

	jakob

Date: Tue, 18 Jan 2011 08:51: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 17.1.2011 21:46, Warren Kumari wrote:
> I was hoping that would be able to stick to one open item at a time but
> the discussions on #17 (Should the first doc be TLS only or try be
> everything to everyone?) has wrapped directly to this issue, so:
>
> I'm opening up Issue #1 (Deal with multiple TLS-based services under one
> domain name (http://trac.tools.ietf.org/wg/dane/trac/ticket/1))
> [ Dons frock, flaps hands, twirls the incense burner three times to the
> left, presses button to make water squirt out of daisy add releases the
> 12 doves -- now it is official ]
> -----
> Description:
> How to deal with multiple TLS-based services running under one domain
> name, such as a POP, IMAP, and SMTP server all running on mail.example.com.
>
> Suggestions so far include:
> Prefacing the host name with a service name (_pop.mail.example.com)
> Prefacing the host name with a port number (_110.mail.example.com)
> Returning a set of records that contain port numbers in the response.
> SRV / ESRV
>
> -----

I would suggest adding using the SRVNames certificate extension to this 
list.  E.g. one would create multiple TLSA records, but each certificate 
would (if there's need) include SRVNames extension which would specify 
if it can be used for the protocol.  Since we honor certificate data 
(with notable exception of self-signed) that should just work[*] for 
type 1/2 certs (EE).

O.
* - I don't know if there is a support for SRVNames cert extension in 
the current implementations, since I didn't know about RFC 4985 until 
yesterday.
-- 
  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, 18 Jan 2011 08:46:48 +0100
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Multiple services at one name (issue #1)

On 17.1.2011 21:23, Phillip Hallam-Baker wrote:
>
>
> On Mon, Jan 17, 2011 at 2:40 PM, OndÅ™ej SurÃ½ <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>     Further thinking about this.  It seems to me that we have two issues
>     here:
>
>     Issue#1 - Multiple services at one name
>
>     Issue#tbd - Ignoring (or not) certificate data in self-signed certs
>
>
> Agreed
>
>     The solution for Issue#1 might be usage of SRVNames.
>
>
> I think so. SRV Names are the DNS way to address protocols, they are a
> very powerful and useful tool.
>
> They also allow us to focus on a much narrower set of concerns at a
> given instance. If we are talking about a record with an _https._tcp
> prefix then I am very happy to only be talking about TLS and only
> talking about HTTP.

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

Ondrej
-- 
  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: Warren Kumari <[email-masked]>
Date: Mon, 17 Jan 2011 22:02:46 -0500
To: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious?

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

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

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

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

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

W
> Steve

Date: Mon, 17 Jan 2011 19:04:14 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious?

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

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

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

> On 1/17/11 2:11 PM, Stephen Kent wrote:
>
>> I agree that getting DANE right for one protocol, e.g., TLS, is a lot
>> easier than trying to get it right for more than one. The big issue that
>> we need to keep in mind is to not impose design constraints, or make
>> design assumptions, at this stage that will conflict with late use of
>> DANE with IPsec, etc.
>>
>
> As an IPsec person who tests IPsec with PKIX certificates (<
> http://www.vpnc.org/testing.html#CertIKEv1Interop>), I am quite sure that
> nothing in the current draft will conflict with a future profile for IPsec,
> if that community wants such a profile. As co-author of the current draft,
> I'm pretty sure I would notice if a change was made that brought up such
> conflict and would prevent it.
>
> --Paul Hoffman, Director
> --VPN Consortium
>
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

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

That is all I was ever arguing for, not to box ourselves into a corner unne=
cessarily.<div><br><div class=3D"gmail_quote">On Mon, Jan 17, 2011 at 6:23 =
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:1p=
x #ccc solid;padding-left:1ex;"><div class=3D"im">On 1/17/11 2:11 PM, Steph=
en Kent wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I agree that getting DANE right for one protocol, e.g., TLS, is a lot<br>
easier than trying to get it right for more than one. The big issue that<br=
>
we need to keep in mind is to not impose design constraints, or make<br>
design assumptions, at this stage that will conflict with late use of<br>
DANE with IPsec, etc.<br>
</blockquote>
<br></div>
As an IPsec person who tests IPsec with PKIX certificates (&lt;<a href=3D"h=
ttp://www.vpnc.org/testing.html#CertIKEv1Interop" target=3D"_blank">http://=
www.vpnc.org/testing.html#CertIKEv1Interop</a>&gt;), I am quite sure that n=
othing in the current draft will conflict with a future profile for IPsec, =
if that community wants such a profile. As co-author of the current draft, =
I&#39;m pretty sure I would notice if a change was made that brought up suc=
h conflict and would prevent it.<br>
<font color=3D"#888888">
<br>
--Paul Hoffman, Director<br>
--VPN Consortium</font><div><div></div><div class=3D"h5"><br>
<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>

--0016e64f8f4a0ccadb049a13a431--

Date: Mon, 17 Jan 2011 18:30:31 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious?

On Mon, 17 Jan 2011, Paul Hoffman wrote:

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

Just a FYI:

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

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

Paul

Date: Mon, 17 Jan 2011 15:23:51 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious?

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

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

--Paul Hoffman, Director
--VPN Consortium

Date: Mon, 17 Jan 2011 18:23:28 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

On Mon, 17 Jan 2011, Paul Hoffman wrote:

>> In other words, is there actually a problem?
>
> There is. If I trust CA1 for issuing to my mail server but not my web server, 
> and CA2 for issuing to my web server but not my mail server, just having CA1 
> and CA2 in the response does not represent what I believe.

and using the same FQDN to access them I assume (or else there is no issue)

In that case, why not use type 1 or type 2? (eg end-user cert based TLSA instead of
CA type based)

Paul

Date: Mon, 17 Jan 2011 18:01:01 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support

At 4:45 PM +0100 1/17/11, Martin Rex wrote:
>Phillip Hallam-Baker wrote:
>>
>>  There are only two key formats that are widely used: X.509 and PGP. The PGP
>>  format is expressly designed to support Web of trust and so is irrelevant
>>  here because what we are doing is the exact opposite of what Phil Zimmerman
>>  proposed.
>
>Two-factor authentication has become popular for humans, because if
>adequately set up, administrated and used it will require the two
>simultaneous security breaches for an unauthorized access.
>
>The X.509 architecture has a design flaw that limits the security to
>n-factor (n<=1).  For the existing TLS X.509 PKI n is around 1/600  (0.00167)
>
>The PGP web of trust provides n-factor security  (n>=1), and obtaining
>(n>>1) is easy and straightforward.
>
>keyassurance through DNSSEC might be used to get back an n-factor security
>with X.509 TLS PKI closer to n=1 (or even slightly better). 
>
>While it's true that a PGP n-factor server authentication based on
>pre-shared PGP trust anchors would work entirely without DNSSEC-based
>key assurance (requiring PGP-enabled TLS on both ends, of course),
>it might still be useful for the situation where there are no
>pre-shared PGP trust anchors and either trusting DNSSEC or
>allowing a leap-of-faith distribution of PGP keys or trust anchors
>under protection of DNSSEC keys.
>
>-Martin

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

Steve

Date: Mon, 17 Jan 2011 17:59:13 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: [keyassure] what PKIX is not

--============_-916817079==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

I've seen several references to PKIX in the context of TLS that 
suggest some confusion.

It appears that some folks believe that the trust anchor (TA) 
management model that browsers have adopted is somehow a PKIX-based 
requirement. That is not true. Browser vendors have adopted a TA 
model that is generally compliant with what X.509 and PKIX require, 
but neither X.509 nor PKIX mandate that model. So, for example, if 
DANE defines a way to distribute TAs via the DNS, that will not 
conflict with PKIX standards.

The checks used to validate a TA are not specified in the core PKIX 
specs. (We do have other standards the define ways to deliver and 
validate TA material, but they are not the only game in town, e.g., 
see the SIDR WG spec on how to do this.)  Section 6.1.1 of RFC 5280 
says that the TA info used to validate a cert path includes

          (1)  the trusted issuer name,

          (2)  the trusted public key algorithm,

          (3)  the trusted public key, and

          (4)  optionally, the trusted public key parameters associated
               with the public key.

So, if DANE defines a way to populate items 1-3 (and, optionally 4) 
from data acquired from the DNS, it can satisfy the 5280 requirements 
for a TA.  This could be dine via a self-signed cert, or even using a 
raw key. It's up to DANE to decide what checks it imposes on the data 
it retrieves from the DNS before using that data to validate an EE 
cert for a TLS server, for example.

If DANE decides that it will use a raw key from the DNS directly in a 
TLS handshake, for example, then it moves outside the PKIX/X.509 
realm, as no certs are being validated.  DANE would then need to 
decide what, if any, constraints it would impose of how the key is 
used, e.g., matched to the DNS name for a server.

Steve

--============_-916817079==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>what PKIX is not</title></head><body>
<div>I've seen several references to PKIX in the context of TLS that
suggest some confusion. </div>
<div><br></div>
<div>It appears that some folks believe that the trust anchor (TA)
management model that browsers have adopted is somehow a PKIX-based
requirement. That is not true. Browser vendors have adopted a TA model
that is generally compliant with what X.509 and PKIX require, but
neither X.509 nor PKIX mandate that model. So, for example, if DANE
defines a way to distribute TAs via the DNS, that will not conflict
with PKIX standards.</div>
<div><br></div>
<div>The checks used to validate a TA are not specified in the core
PKIX specs. (We do have other standards the define ways to deliver and
validate TA material, but they are not the only game in town, e.g.,
see the SIDR WG spec on how to do this.)&nbsp; Section 6.1.1 of RFC
5280 says that the TA info used to validate a cert path includes</div>
<div><font face="Courier" size="+2" color="#000000"><br>
&nbsp;</font><font
color="#000000">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (1)&nbsp;
the trusted issuer name,<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (2)&nbsp; the trusted
public key algorithm,<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (3)&nbsp; the trusted
public key, and<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (4)&nbsp; optionally,
the trusted public key parameters associated<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span
></span>&nbsp;&nbsp; with the public key.</font></div>
<div><br></div>
<div>So, if DANE defines a way to populate items 1-3 (and, optionally
4) from data acquired from the DNS, it can satisfy the 5280
requirements for a TA.&nbsp; This could be dine via a self-signed
cert, or even using a raw key. It's up to DANE to decide what checks
it imposes on the data it retrieves from the DNS before using that
data to validate an EE cert for a TLS server, for example.</div>
<div><br></div>
<div>If DANE decides that it will use a raw key from the DNS directly
in a TLS handshake, for example, then it moves outside the PKIX/X.509
realm, as no certs are being validated.&nbsp; DANE would then need to
decide what, if any, constraints it would impose of how the key is
used, e.g., matched to the DNS name for a server.</div>
<div><br></div>
<div>Steve</div>
<div><br></div>
<div><br></div>
</body>
</html>
--============_-916817079==_ma============--

Date: Mon, 17 Jan 2011 18:03:28 -0500
To: Paul Wouters <[email-masked]>
From: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Possible fix for pkix/dane certificate disagreement

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

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

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

Steve

Date: Mon, 17 Jan 2011 17:11:02 -0500
To: Warren Kumari <[email-masked]>
From: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious?

Warren,

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

Steve

Date: Mon, 17 Jan 2011 14:23:38 -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 1/17/11 1:35 PM, Paul Wouters wrote:
> On Mon, 17 Jan 2011, Warren Kumari wrote:
>
>> Description:
>> How to deal with multiple TLS-based services running under one domain
>> name, such as a POP, IMAP, and SMTP server all running on
>> mail.example.com.
>>
>> Suggestions so far include:
>> Prefacing the host name with a service name (_pop.mail.example.com)
>> Prefacing the host name with a port number (_110.mail.example.com)
>> Returning a set of records that contain port numbers in the response.
>> SRV / ESRV
>
> Multiple TLSA records and letting the client find the matching one from
> the TLS handshake?

That is another possible solution, but...

> In other words, is there actually a problem?

There is. If I trust CA1 for issuing to my mail server but not my web 
server, and CA2 for issuing to my web server but not my mail server, 
just having CA1 and CA2 in the response does not represent what I believe.

Date: Mon, 17 Jan 2011 16:52:12 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

On Mon, 17 Jan 2011, Paul Hoffman wrote:

> I think SRV is an interesting approach, but simply naming the protocol is 
> completely insufficient. Could someone who supports this and has thought 
> about it a while give some rough text that we could consider?

It will also make it much harder to implement for the DNS administrator.

I'm not sure why this is required. If the administrator feels that they
need a separate TLSA entry, can't they just assign a different hostname
and put the certificate there? eg mail.example.com and www.example.com? or
payments.example.com?

When there are vastly different security requirements for a particular
service, they tend to be hosted on a separate server anyway, precisely
because of the different requirements (eg PCI compliance) and so they
have a different hostname and different TLSA location.

Using SRV's or _service._proto prefixes makes deployment harder in the
easy case, while using different domains for your complicated setup
only makes things harder for the harder case, and therefor to
me puts the complexity where it belongs.

And I don't think this approach "damages the internet" because of a
theoretical corner case of two widely different security levels running
on the same hostname in DNS, deploying both PKIX with CAs and DANE. I
do have an oustanding question there to Phillip to explain his use
case better, but if those cases are not forthcoming, my preference
would be to keep it simple.

Paul

Date: Mon, 17 Jan 2011 16:35:42 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Warren Kumari <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

On Mon, 17 Jan 2011, Warren Kumari wrote:

> Description:
> How to deal with multiple TLS-based services running under one domain name, 
> such as a POP, IMAP, and SMTP server all running on mail.example.com.
>
> Suggestions so far include:
> Prefacing the host name with a service name (_pop.mail.example.com)
> Prefacing the host name with a port number (_110.mail.example.com)
> Returning a set of records that contain port numbers in the response.
> SRV / ESRV

Multiple TLSA records and letting the client find the matching one from
the TLS handshake?

In other words, is there actually a problem?

Paul

Date: Mon, 17 Jan 2011 13:02:40 -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 1/17/11 12:46 PM, Warren Kumari wrote:
> I was hoping that would be able to stick to one open item at a time but
> the discussions on #17 (Should the first doc be TLS only or try be
> everything to everyone?) has wrapped directly to this issue, so:
>
> I'm opening up Issue #1 (Deal with multiple TLS-based services under one
> domain name (http://trac.tools.ietf.org/wg/dane/trac/ticket/1))
> [ Dons frock, flaps hands, twirls the incense burner three times to the
> left, presses button to make water squirt out of daisy add releases the
> 12 doves -- now it is official ]
> -----
> Description:
> How to deal with multiple TLS-based services running under one domain
> name, such as a POP, IMAP, and SMTP server all running on mail.example.com.
>
> Suggestions so far include:
> Prefacing the host name with a service name (_pop.mail.example.com)
> Prefacing the host name with a port number (_110.mail.example.com)
> Returning a set of records that contain port numbers in the response.
> SRV / ESRV
>
> -----

I think SRV is an interesting approach, but simply naming the protocol 
is completely insufficient. Could someone who supports this and has 
thought about it a while give some rough text that we could consider?

As for ESRV, there has been no noticeable interest in the WGs that the 
authors have brought it to, so I think we would be impossibly premature 
to rely on it for our protocol.

From: Warren Kumari <[email-masked]>
To: [email-masked]
Date: Mon, 17 Jan 2011 15:46:10 -0500
Subject: [keyassure] Issue #1 -- Deal with multiple TLS-based services under one domain name.

I was hoping that would be able to stick to one open item at a time  
but the discussions on #17 (Should the first doc be TLS only or try be  
everything to everyone?) has wrapped directly to this issue, so:

I'm opening up Issue #1 (Deal with multiple TLS-based services under  
one domain name (http://trac.tools.ietf.org/wg/dane/trac/ticket/1))
[ Dons frock, flaps hands, twirls the incense burner three times to  
the left,  presses button to make water squirt out of daisy add  
releases the 12 doves -- now it is official ]
-----
Description:
How to deal with multiple TLS-based services running under one domain  
name, such as a POP, IMAP, and SMTP server all running on  
mail.example.com.

Suggestions so far include:
Prefacing the host name with a service name (_pop.mail.example.com)
Prefacing the host name with a port number (_110.mail.example.com)
Returning a set of records that contain port numbers in the response.
SRV / ESRV

-----

W

Date: Mon, 17 Jan 2011 12:28:27 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Possible fix for pkix/dane certificate disagreement

On 1/17/11 12:00 PM, Yaron Sheffer wrote:
> I'd like to support Paul W.'s position here, and strongly disagree with
> Paul H.

Just to be clear (because people are changing views as we discuss), you 
are supporting having some end-entity certificate types that are labeled 
as "ignore everything other than the key" and some end-entity 
certificate types that are labeled as "treat all PKIX information as you 
would if you had not gotten the cert from TLSA", yes? I'm not fond of 
that because I think host admins will make the wrong choice, but it is a 
tenable solution.

> Of course the DNS records are specifying policy. They (in
> conjunction with the DANE RFC) tell the client what it is allowed to do.
> That's policy in my book.

But that's now what Paul W suggested: he had it as a suggestion, not 
what the client is allowed to do. That's what I objected to.

> And specifying new RR types where the client MUST ignore everything in
> the cert, other than the public key, is a nice way out of the
> contradiction we've gotten ourselves into by trying to "sort of, but not
> really" reuse PKIX.

Thus, we fully agree.

> An even cleaner way out is to specify exactly what fields MUST and MUST
> NOT exist in the cert, and retain the PKIX semantics for all fields.

Thus, we fully agree.

> It would have been even cleaner to use raw RSA keys instead of
> self-signed certs, but I don't know whether they would be usable in TLS.

It is easy to find out by looking in the TLS specification. They are not.

Date: Mon, 17 Jan 2011 15:23:19 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Multiple services at one name (issue #1)

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

On Mon, Jan 17, 2011 at 2:40 PM, Ond=C5=99ej Sur=C3=BD <[email-masked]>=
 wrote:
>
>
> Further thinking about this.  It seems to me that we have two issues here=
:
>
> Issue#1 - Multiple services at one name
>
> Issue#tbd - Ignoring (or not) certificate data in self-signed certs
>

Agreed

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

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

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

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

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

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

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

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

<br><br><div class=3D"gmail_quote">On Mon, Jan 17, 2011 at 2:40 PM, Ond=C5=
=99ej Sur=C3=BD <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]"=
>[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 class=3D"im">
<br></div>
Further thinking about this. =C2=A0It seems to me that we have two issues h=
ere:<br>
<br>
Issue#1 - Multiple services at one name<br><br></blockquote><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex;">
Issue#tbd - Ignoring (or not) certificate data in self-signed certs<br></bl=
ockquote><div><br></div><div>Agreed=C2=A0</div><div><br></div><div>=C2=A0</=
div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex;">

The solution for Issue#1 might be usage of SRVNames.<br></blockquote><div><=
br></div><div>I think so. SRV Names are the DNS way to address protocols, t=
hey are a very powerful and useful tool.</div><div><br></div><div>They also=
 allow us to focus on a much narrower set of concerns at a given instance. =
If we are talking about a record with an _https._tcp prefix then I am very =
happy to only be talking about TLS and only talking about HTTP.</div>
<div><br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
The solution to Issue#tbd might be in tool which would easily generate diff=
erent self-signed certs from one private key (or ability to do that on-fly)=
, hence defeating the need to ignore cert properties.</blockquote><div>
<br></div><div>Someone suggested being able to (optionally) put a critical =
extension in the cert with an SRV property.</div><div><br></div><div>I rath=
er like that proposal as it really ties everything very neatly to the DNS s=
et of identifiers and a DNS way of looking at the world.</div>
<div><br></div></div><br>-- <br>Website: <a href=3D"http://hallambaker.com/=
">http://hallambaker.com/</a><br><br>

--0016e644bc2e06c8ed049a108e78--

From: Matt McCutchen <[email-masked]>
To: =?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?= <[email-masked]>
Date: Mon, 17 Jan 2011 15:10:21 -0500
Cc: [email-masked]
Subject: Re: [keyassure] Multiple services at one name (issue #1)

On Mon, 2011-01-17 at 20:40 +0100, Ond=C5=99ej Sur=C3=BD wrote:
> On 17.1.2011 20:16, Ond=C5=99ej Sur=C3=BD wrote:
> > BTW do you realize that all the services you have named use the same
> > certificate? So the level of trust is probably same for all those ser=
vices.
>=20
> Just to make sure...  I was not arguing here with you, just pointing ou=
t=20
> that it's quite different to have all "mail" services under one name=20
> (and probably same policy) and to have "low-level" SMTP cert and some=20
> other high security protocol at other name (like running incoming SMTP=20
> server under www.paypal.com name)

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

> >> PKIX supports it via SRVNames (RFC 4985). DANE should support it too=
.
> >
> > I don't see a problem here for non-self-signed certs (3.1.4 says that
> > additional certificate data should be processed as normal).
> >
> > The only issue is with self-signed certs type 1/2 (type 3/4 is CA
> > self-signed cert). So basically you are saying (if I may generalize)
> > that we should not ignore certificate data in self-signed certs and t=
hus
> > support SRVNames in self-signed certs.
>=20
> Further thinking about this.  It seems to me that we have two issues he=
re:
>=20
> Issue#1 - Multiple services at one name
>=20
> Issue#tbd - Ignoring (or not) certificate data in self-signed certs

Right.

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

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

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

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

--=20
Matt

Date: Mon, 17 Jan 2011 22:00:51 +0200
From: Yaron Sheffer <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Possible fix for pkix/dane certificate disagreement

Hi,

I'd like to support Paul W.'s position here, and strongly disagree with 
Paul H. Of course the DNS records are specifying policy. They (in 
conjunction with the DANE RFC) tell the client what it is allowed to do. 
That's policy in my book.

And specifying new RR types where the client MUST ignore everything in 
the cert, other than the public key, is a nice way out of the 
contradiction we've gotten ourselves into by trying to "sort of, but not 
really" reuse PKIX.

An even cleaner way out is to specify exactly what fields MUST and MUST 
NOT exist in the cert, and retain the PKIX semantics for all fields.

It would have been even cleaner to use raw RSA keys instead of 
self-signed certs, but I don't know whether they would be usable in TLS.

Thanks,
     Yaron

Date: Mon, 17 Jan 2011 08:10:18 -0800
> From: Paul Hoffman<[email-masked]>
> Subject: Re: [keyassure] Possible fix for pkix/dane certificate
>     disagreement
> To: [email-masked]
> Message-ID:<[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 1/17/11 7:11 AM, Paul Wouters wrote:
> >
> > DANE is an alternative for PKIX.
> >
> > The important issue here is can someone use both or not, and can someone
> > migrate from one to the other. DANE should not be limited by PKIX, just
> > like PKIX should not be limited by DANE. But we have had this discussion
> > a few times already.
> >
> > My concern is for example with the regularly seen expired 
> certificates. I
> > forsee people, especially those using self signed certificates, to
> > generate TLSA records and forget about their certificate's expiry date.
> >
> > I think there is real value in ignoring all certificate properties. 
> But we
> > could decide on making such a TLSA record have its own "certificate 
> type".
> >
> > eg, we could add type 5/6 to section 2 of the DANE draft:
> >
> > 5 Hash of a public key taken from an end-entity certificate. All PKIX
> > elements are specifically ignored.
> >
> > 6 Full public key taken from an end-entity certificate. All PKIX
> > elements are specifically ignored.
>
> I agree that we should nail down in the spec whether PKIX information
> other than the key itself should be paid attention to in end-entity
> certificates gotten through TLSA. I disagree that we want to have two
> semantics based on different values in the TLSA record. Doing so says
> that the server gets to tell the client what security policy the client
> should use.
>
> --Paul Hoffman

Date: Mon, 17 Jan 2011 20:40:40 +0100
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Multiple services at one name (issue #1)

On 17.1.2011 20:16, OndÅ™ej SurÃ½ wrote:
> On 17.1.2011 19:51, Matt McCutchen wrote:
>> On Mon, 2011-01-17 at 15:50 +0100, OndÅ™ej SurÃ½ wrote:
>>> On 17.1.2011 15:30, Phillip Hallam-Baker wrote:
>>>> The specific concern would be that someone could make use of the
>>>> lightweight SMTP cert issue process to acquire a certificate for
>>>> another
>>>> service.
>>> >
>>>> Another concern would be that in a heavily outsourced deployment, I may
>>>> trust a company to run my inbound mail server but not want them to have
>>>> the ability to advertise other services (like accepting payments).
>>>>
>>>> The simplest, most direct way to enforce this type of restriction is to
>>>> put a note in the certificate governing acceptable use.
>>>
>>> No, the simplest, most direct way (apart from not using DANE at all) is
>>> to have different host names for inbound mail server and other services.
>>>
>>> You have painted the very rare scenario in which the canonical name (ie.
>>> the target of MX record) is same as some other service, and you document
>>> the degradation of security on such unlikely scenario.
>>>
>>> <chair hat>
>>> I propose that either you present an evidence that it will have any real
>>> impact or we just drop this issue since it's impact is negligible.
>>> Thank you.
>>> </chair hat>
>>
>> Here's an example: my university's student mail system provides POP3S,
>> IMAPS, SMTP with STARTTLS for message submission, and a HTTPS webmail
>> interface all on the same server name (mail.umd.edu).
>
> Thank you for the real world example.
>
>> This kind of configuration is convenient for users: they only have to
>> remember the one host name, not the prefixes used for the different
>> services (which are not standardized anywhere and will be different for
>> different service providers).
>
> BTW do you realize that all the services you have named use the same
> certificate? So the level of trust is probably same for all those services.

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

>> PKIX supports it via SRVNames (RFC 4985). DANE should support it too.
>
> I don't see a problem here for non-self-signed certs (3.1.4 says that
> additional certificate data should be processed as normal).
>
> The only issue is with self-signed certs type 1/2 (type 3/4 is CA
> self-signed cert). So basically you are saying (if I may generalize)
> that we should not ignore certificate data in self-signed certs and thus
> support SRVNames in self-signed certs.

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

Issue#1 - Multiple services at one name

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

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

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

O.
-- 
  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: Mon, 17 Jan 2011 14:37:13 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Multiple services at one name (issue #1)

On Mon, 17 Jan 2011, OndÅ™ej SurÃ½ wrote:

> I don't see a problem here for non-self-signed certs (3.1.4 says that 
> additional certificate data should be processed as normal).
>
> The only issue is with self-signed certs type 1/2 (type 3/4 is CA self-signed 
> cert).  So basically you are saying (if I may generalize) that we should not 
> ignore certificate data in self-signed certs and thus support SRVNames in 
> self-signed certs.

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

Paul

Date: Mon, 17 Jan 2011 14:33:20 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] Possible fix for pkix/dane certificate disagreement

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

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

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

Paul

Date: Mon, 17 Jan 2011 20:16:42 +0100
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Multiple services at one name (issue #1)

On 17.1.2011 19:51, Matt McCutchen wrote:
> On Mon, 2011-01-17 at 15:50 +0100, OndÅ™ej SurÃ½ wrote:
>> On 17.1.2011 15:30, Phillip Hallam-Baker wrote:
>>> The specific concern would be that someone could make use of the
>>> lightweight SMTP cert issue process to acquire a certificate for another
>>> service.
>>   >
>>> Another concern would be that in a heavily outsourced deployment, I may
>>> trust a company to run my inbound mail server but not want them to have
>>> the ability to advertise other services (like accepting payments).
>>>
>>> The simplest, most direct way to enforce this type of restriction is to
>>> put a note in the certificate governing acceptable use.
>>
>> No, the simplest, most direct way (apart from not using DANE at all) is
>> to have different host names for inbound mail server and other services.
>>
>> You have painted the very rare scenario in which the canonical name (ie.
>> the target of MX record) is same as some other service, and you document
>> the degradation of security on such unlikely scenario.
>>
>> <chair hat>
>> I propose that either you present an evidence that it will have any real
>> impact or we just drop this issue since it's impact is negligible.
>> Thank you.
>> </chair hat>
>
> Here's an example: my university's student mail system provides POP3S,
> IMAPS, SMTP with STARTTLS for message submission, and a HTTPS webmail
> interface all on the same server name (mail.umd.edu).

Thank you for the real world example.

> This kind of configuration is convenient for users: they only have to
> remember the one host name, not the prefixes used for the different
> services (which are not standardized anywhere and will be different for
> different service providers).

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

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

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

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

Correct?

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

From: Martin Rex <[email-masked]>
To: [email-masked] (Phillip Hallam-Baker)
Date: Mon, 17 Jan 2011 20:08:28 +0100 (MET)
Cc: [email-masked]
Subject: Re: [keyassure] keyassure Digest, Vol 6, Issue 16
Reply-To: [email-masked]

Phillip Hallam-Baker wrote:
> 
> OK, we will return to this in last call then
> 
> And in IETF last call
> 
> And when the PKIX people object to your whole spec on the grounds that you
> are changing theirs we can start DANE from scratch

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

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

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

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

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

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

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

-Martin

Date: Mon, 17 Jan 2011 11:04:57 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Possible fix for pkix/dane certificate disagreement

On 1/17/11 10:34 AM, Paul Wouters wrote:
> On Mon, 17 Jan 2011, Paul Hoffman wrote:
>
>>>> I agree that we should nail down in the spec whether PKIX information
>>>> other than the key itself should be paid attention to in end-entity
>>>> certificates gotten through TLSA. I disagree that we want to have two
>>>> semantics based on different values in the TLSA record. Doing so says
>>>> that the server gets to tell the client what security policy the
>>>> client should use.
>>>
>>> So change it from "ignored" to "MAY ignore" ?
>>
>> Clients "MAY ignore" anything already. It sounds like you are trying
>> to add bits that say "and I want you to enforce this even though I
>> have no idea what your local policy is". That doesn't sound like it
>> adds much value to me.
>
> I'm trying to addres Phillip's concern about implicitely changing PKIX
> validation
> by making it more explicit, and giving the administrator the local
> policy choice
> to put down a preference of either DANE or PKIX as their trust anchor.
>
> While most believe the existence of DANE itself signifies the
> preference, Phillip
> does not agree. A specific sub-type in section 2 for TLSA would address
> this.
>
> PKIX is all about the server teling the client policy, even if the
> precise policy
> bits are contained in a PKIX certificate and not in an RRTYPE. I don't
> see why
> DANE could not do the same (as long as the protocol allows specifying
> both policies)
>
> In the current spec, there is the contradiction of "expired cert" vs
> "valid RRSIG".
> It would be nice if a preference could be specified and that this use
> case would
> not end up being varying per implementation. (even though I think that
> implementations
> should ignore everything but the public key from a cert when using DANE)

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

Date: Mon, 17 Jan 2011 14:04:18 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Possible fix for pkix/dane certificate disagreement

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

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

> On 1/17/11 8:33 AM, Paul Wouters wrote:
>
>> On Mon, 17 Jan 2011, Paul Hoffman wrote:
>>
>>  I agree that we should nail down in the spec whether PKIX information
>>> other than the key itself should be paid attention to in end-entity
>>> certificates gotten through TLSA. I disagree that we want to have two
>>> semantics based on different values in the TLSA record. Doing so says
>>> that the server gets to tell the client what security policy the
>>> client should use.
>>>
>>
>> So change it from "ignored" to "MAY ignore" ?
>>
>
> Clients "MAY ignore" anything already. It sounds like you are trying to add
> bits that say "and I want you to enforce this even though I have no idea
> what your local policy is". That doesn't sound like it adds much value to
> me.

No, you are quite incorrect.

Clients 'may' do anything they like.

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

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

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

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

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

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

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

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

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

<br><br><div class=3D"gmail_quote">On Mon, Jan 17, 2011 at 12:13 PM, Paul H=
offman <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">paul.=
[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 1/17/11 8:33 AM, Paul Wouters wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On Mon, 17 Jan 2011, Paul Hoffman wrote:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I agree that we should nail down in the spec whether PKIX information<br>
other than the key itself should be paid attention to in end-entity<br>
certificates gotten through TLSA. I disagree that we want to have two<br>
semantics based on different values in the TLSA record. Doing so says<br>
that the server gets to tell the client what security policy the<br>
client should use.<br>
</blockquote>
<br>
So change it from &quot;ignored&quot; to &quot;MAY ignore&quot; ?<br>
</blockquote>
<br></div>
Clients &quot;MAY ignore&quot; anything already. It sounds like you are try=
ing to add bits that say &quot;and I want you to enforce this even though I=
 have no idea what your local policy is&quot;. That doesn&#39;t sound like =
it adds much value to me.</blockquote>
<div><br></div><div>No, you are quite incorrect.</div><div><br></div><div>C=
lients &#39;may&#39; do anything they like.</div><div><br></div><div>But th=
at does not mean that they &#39;MAY&#39; do anything in the sense of normat=
ive compliance. In the case of X.509 and PKIX there are very specific MUST =
requirements that have to be observed for interoperability.</div>
<div><br></div><div>One of them is that RPs MUST NOT accept a certificate w=
ith a critical extension that they do not understand. that is an interopera=
bility criteria.</div><div>=A0</div></div><div><br></div><div>In practice i=
t is a restriction that would take a great deal of effort to avoid enforcin=
g since existing code has those restrictions built in at a very low level.<=
/div>
<div><br></div><div>If we were to attempt to adopt the approach suggested a=
nd simply ignore critical extensions and expiry dates, the likely outcome i=
s going to be that some people are going to code to the DANE spec and other=
s are going to code to the PKIX spec. And as a PKIX person I am not going t=
o tell the person who is reading that document that they are wrong to ignor=
e the DANE requirements.</div>
<div><br></div><div>So to accept the proposal to ignore critical extensions=
, revocation, expiry is to create a huge amount of scope for interoperabili=
ty failures.</div><div><br></div><div><br></div><div>If people don&#39;t wa=
nt critical extensions then they shouldn&#39;t put them in their self-signe=
d certs. The only way that a critical extension is going to get in a cert i=
s if someone decides to put it there.</div>
<div><br></div><div>If people don&#39;t want to worry about expiry dates th=
en set them to the issue date plus 100 years.</div><div><br></div><div><br>=
</div>-- <br>Website: <a href=3D"http://hallambaker.com/">http://hallambake=
r.com/</a><br>
<br>

--0016e64f8f4a6b4113049a0f7380--

From: Matt McCutchen <[email-masked]>
To: =?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?= <[email-masked]>
Date: Mon, 17 Jan 2011 13:51:59 -0500
Cc: [email-masked]
Subject: Re: [keyassure] Multiple services at one name (issue #1)

On Mon, 2011-01-17 at 15:50 +0100, Ond=C5=99ej Sur=C3=BD wrote:
> On 17.1.2011 15:30, Phillip Hallam-Baker wrote:
> > The specific concern would be that someone could make use of the
> > lightweight SMTP cert issue process to acquire a certificate for anot=
her
> > service.
>  >
> > Another concern would be that in a heavily outsourced deployment, I m=
ay
> > trust a company to run my inbound mail server but not want them to ha=
ve
> > the ability to advertise other services (like accepting payments).
> >
> > The simplest, most direct way to enforce this type of restriction is =
to
> > put a note in the certificate governing acceptable use.
>=20
> No, the simplest, most direct way (apart from not using DANE at all) is=
=20
> to have different host names for inbound mail server and other services=
.
>=20
> You have painted the very rare scenario in which the canonical name (ie=
.=20
> the target of MX record) is same as some other service, and you documen=
t=20
> the degradation of security on such unlikely scenario.
>=20
> <chair hat>
> I propose that either you present an evidence that it will have any rea=
l=20
> impact or we just drop this issue since it's impact is negligible.=20
> Thank you.
> </chair hat>

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

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

--=20
Matt

Date: Mon, 17 Jan 2011 13:34:44 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Possible fix for pkix/dane certificate disagreement

On Mon, 17 Jan 2011, Paul Hoffman wrote:

>>> I agree that we should nail down in the spec whether PKIX information
>>> other than the key itself should be paid attention to in end-entity
>>> certificates gotten through TLSA. I disagree that we want to have two
>>> semantics based on different values in the TLSA record. Doing so says
>>> that the server gets to tell the client what security policy the
>>> client should use.
>> 
>> So change it from "ignored" to "MAY ignore" ?
>
> Clients "MAY ignore" anything already. It sounds like you are trying to add 
> bits that say "and I want you to enforce this even though I have no idea what 
> your local policy is". That doesn't sound like it adds much value to me.

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

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

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

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

Paul

Date: Mon, 17 Jan 2011 09:13:27 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Possible fix for pkix/dane certificate disagreement

On 1/17/11 8:33 AM, Paul Wouters wrote:
> On Mon, 17 Jan 2011, Paul Hoffman wrote:
>
>> I agree that we should nail down in the spec whether PKIX information
>> other than the key itself should be paid attention to in end-entity
>> certificates gotten through TLSA. I disagree that we want to have two
>> semantics based on different values in the TLSA record. Doing so says
>> that the server gets to tell the client what security policy the
>> client should use.
>
> So change it from "ignored" to "MAY ignore" ?

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

Date: Mon, 17 Jan 2011 09:11:28 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] keyassure Digest, Vol 6, Issue 16

On 1/17/11 8:18 AM, Phillip Hallam-Baker wrote:
> This is an existing security control established in PKIX

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

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

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

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

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

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

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

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

The use cases for TLSA are listed in the draft.

Date: Mon, 17 Jan 2011 11:33:32 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Possible fix for pkix/dane certificate disagreement

On Mon, 17 Jan 2011, Paul Hoffman wrote:

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

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

Paul

Date: Mon, 17 Jan 2011 08:10:18 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Possible fix for pkix/dane certificate disagreement

On 1/17/11 7:11 AM, Paul Wouters wrote:
>
> DANE is an alternative for PKIX.
>
> The important issue here is can someone use both or not, and can someone
> migrate from one to the other. DANE should not be limited by PKIX, just
> like PKIX should not be limited by DANE. But we have had this discussion
> a few times already.
>
> My concern is for example with the regularly seen expired certificates. I
> forsee people, especially those using self signed certificates, to
> generate TLSA records and forget about their certificate's expiry date.
>
> I think there is real value in ignoring all certificate properties. But we
> could decide on making such a TLSA record have its own "certificate type".
>
> eg, we could add type 5/6 to section 2 of the DANE draft:
>
> 5 Hash of a public key taken from an end-entity certificate. All PKIX
> elements are specifically ignored.
>
> 6 Full public key taken from an end-entity certificate. All PKIX
> elements are specifically ignored.

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

--Paul Hoffman

Date: Mon, 17 Jan 2011 11:18:57 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] keyassure Digest, Vol 6, Issue 16

--0016e64f8f4a43dc90049a0d241c
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

This is an existing security control established in PKIX

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

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

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

2011/1/17 Ond=F8ej Sur=FD <[email-masked]>

> I have politely asked you to provide evidence that it's going to be issue=
,
> so we can continue the discussion.  Yet you came back with threats about
> WGLC and IETFLC and a straw man argument that I block the discussion.
>
> Hence I believe no further discussion is possible.  If you have arguments
> which I have asked for then I would be more than happy to continue this
> discussion in productive and constructive manner.
>
> Ondrej
>
>
> On 17.1.2011 15:55, Phillip Hallam-Baker wrote:
>
>> OK, we will return to this in last call then
>>
>> And in IETF last call
>>
>> And when the PKIX people object to your whole spec on the grounds that
>> you are changing theirs we can start DANE from scratch
>>
>>
>> Blocking discussion of critical security issues in the WG is not going
>> to get you to RFC any faster.
>>
>> You cannot claim to have a WG consensus if your response to every issue
>> you don't like is to put your chair hart on and attempt to block
>> discussion.
>>
>>
>> On Mon, Jan 17, 2011 at 9:50 AM, Ond=F8ej Sur=FD <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>    On 17.1.2011 15:30, Phillip Hallam-Baker wrote:
>>
>>        The specific concern would be that someone could make use of the
>>        lightweight SMTP cert issue process to acquire a certificate for
>>        another
>>        service.
>>
>>     >
>>
>>        Another concern would be that in a heavily outsourced
>>        deployment, I may
>>        trust a company to run my inbound mail server but not want them
>>        to have
>>        the ability to advertise other services (like accepting payments)=
.
>>
>>        The simplest, most direct way to enforce this type of
>>        restriction is to
>>        put a note in the certificate governing acceptable use.
>>
>>
>>    No, the simplest, most direct way (apart from not using DANE at all)
>>    is to have different host names for inbound mail server and other
>>    services.
>>
>>    You have painted the very rare scenario in which the canonical name
>>    (ie. the target of MX record) is same as some other service, and you
>>    document the degradation of security on such unlikely scenario.
>>
>>    <chair hat>
>>    I propose that either you present an evidence that it will have any
>>    real impact or we just drop this issue since it's impact is
>>    negligible. Thank you.
>>    </chair hat>
>>
>>    BTW: I just hand checked top20 domain names from alexa list and all
>>    of them has something like [.*][mx|mail|smtp].<domainname1> for
>>    <domainname2> where usually domainname1 =3D domainname2.
>>
>>    O.
>>
>>    --
>>      Ond=F8ej Sur=FD
>>      vedouc=ED v=FDzkumu/Head of R&D department
>>      -------------------------------------------
>>      CZ.NIC, z.s.p.o.    --    Laborato=F8e CZ.NIC
>>      Americka 23, 120 00 Praha 2, Czech Republic
>>      mailto:[email-masked] <mailto:[email-masked]> http://nic.cz=
/
>>
>>      tel:+420.222745110       fax:+420.222745112
>>      -------------------------------------------
>>    _______________________________________________
>>    keyassure mailing list
>>    [email-masked] <mailto:[email-masked]>
>>
>>    https://www.ietf.org/mailman/listinfo/keyassure
>>
>>
>>
>>
>> --
>> Website: http://hallambaker.com/
>>
>>
>
> --
>  Ond=F8ej Sur=FD
>  vedouc=ED v=FDzkumu/Head of R&D department
>  -------------------------------------------
>  CZ.NIC, z.s.p.o.    --    Laborato=F8e 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
>

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

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

This is an existing security control established in PKIX<div><br></div><div=
>I believe the burden of proof is on those proposing to make a change that =
they are not going to cause damage.</div><div><br></div><div><br></div><div=
>
Now if you look at this thread, I have given numerous use cases that demons=
trate a need for what I am arguing for. I have not seen any use case given =
in favor of ignoring the information.</div><div><br></div><div>I have provi=
ded evidence, it is your side that has refused. I don&#39;t think I have se=
en a single use case from you ever.</div>
<div><br></div><div><br><br><div class=3D"gmail_quote">2011/1/17 Ond=F8ej S=
ur=FD <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">ondrej.su=
[email-masked]</a>&gt;</span><br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I have politely asked you to provide evidence that it&#39;s going to be iss=
ue, so we can continue the discussion. =A0Yet you came back with threats ab=
out WGLC and IETFLC and a straw man argument that I block the discussion.<b=
r>

<br>
Hence I believe no further discussion is possible. =A0If you have arguments=
 which I have asked for then I would be more than happy to continue this di=
scussion in productive and constructive manner.<br>
<br>
Ondrej<div class=3D"im"><br>
<br>
On 17.1.2011 15:55, Phillip Hallam-Baker wrote:<br>
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div class=3D"im">
OK, we will return to this in last call then<br>
<br>
And in IETF last call<br>
<br>
And when the PKIX people object to your whole spec on the grounds that<br>
you are changing theirs we can start DANE from scratch<br>
<br>
<br>
Blocking discussion of critical security issues in the WG is not going<br>
to get you to RFC any faster.<br>
<br>
You cannot claim to have a WG consensus if your response to every issue<br>
you don&#39;t like is to put your chair hart on and attempt to block discus=
sion.<br>
<br>
<br>
On Mon, Jan 17, 2011 at 9:50 AM, Ond=F8ej Sur=FD &lt;<a href=3D"mailto:ondr=
[email-masked]" target=3D"_blank">[email-masked]</a><br></div><div><div=
></div><div class=3D"h5">
&lt;mailto:<a href=3D"mailto:[email-masked]" target=3D"_blank">ondrej.s=
[email-masked]</a>&gt;&gt; wrote:<br>
<br>
 =A0 =A0On 17.1.2011 15:30, Phillip Hallam-Baker wrote:<br>
<br>
 =A0 =A0 =A0 =A0The specific concern would be that someone could make use o=
f the<br>
 =A0 =A0 =A0 =A0lightweight SMTP cert issue process to acquire a certificat=
e for<br>
 =A0 =A0 =A0 =A0another<br>
 =A0 =A0 =A0 =A0service.<br>
<br>
 =A0 =A0 &gt;<br>
<br>
 =A0 =A0 =A0 =A0Another concern would be that in a heavily outsourced<br>
 =A0 =A0 =A0 =A0deployment, I may<br>
 =A0 =A0 =A0 =A0trust a company to run my inbound mail server but not want =
them<br>
 =A0 =A0 =A0 =A0to have<br>
 =A0 =A0 =A0 =A0the ability to advertise other services (like accepting pay=
ments).<br>
<br>
 =A0 =A0 =A0 =A0The simplest, most direct way to enforce this type of<br>
 =A0 =A0 =A0 =A0restriction is to<br>
 =A0 =A0 =A0 =A0put a note in the certificate governing acceptable use.<br>
<br>
<br>
 =A0 =A0No, the simplest, most direct way (apart from not using DANE at all=
)<br>
 =A0 =A0is to have different host names for inbound mail server and other<b=
r>
 =A0 =A0services.<br>
<br>
 =A0 =A0You have painted the very rare scenario in which the canonical name=
<br>
 =A0 =A0(ie. the target of MX record) is same as some other service, and yo=
u<br>
 =A0 =A0document the degradation of security on such unlikely scenario.<br>
<br>
 =A0 =A0&lt;chair hat&gt;<br>
 =A0 =A0I propose that either you present an evidence that it will have any=
<br>
 =A0 =A0real impact or we just drop this issue since it&#39;s impact is<br>
 =A0 =A0negligible. Thank you.<br>
 =A0 =A0&lt;/chair hat&gt;<br>
<br>
 =A0 =A0BTW: I just hand checked top20 domain names from alexa list and all=
<br>
 =A0 =A0of them has something like [.*][mx|mail|smtp].&lt;domainname1&gt; f=
or<br>
 =A0 =A0&lt;domainname2&gt; where usually domainname1 =3D domainname2.<br>
<br>
 =A0 =A0O.<br>
<br>
 =A0 =A0--<br>
 =A0 =A0 =A0Ond=F8ej Sur=FD<br>
 =A0 =A0 =A0vedouc=ED v=FDzkumu/Head of R&amp;D department<br>
 =A0 =A0 =A0-------------------------------------------<br>
 =A0 =A0 =A0CZ.NIC, z.s.p.o. =A0 =A0-- =A0 =A0Laborato=F8e CZ.NIC<br>
 =A0 =A0 =A0Americka 23, 120 00 Praha 2, Czech Republic<br></div></div>
 =A0 =A0 =A0mailto:<a href=3D"mailto:[email-masked]" target=3D"_blank">=
[email-masked]</a> &lt;mailto:<a href=3D"mailto:[email-masked]" tar=
get=3D"_blank">[email-masked]</a>&gt; <a href=3D"http://nic.cz/" target=
=3D"_blank">http://nic.cz/</a><div class=3D"im">
<br>
 =A0 =A0 =A0tel:+420.222745110 =A0 =A0 =A0 fax:+420.222745112<br>
 =A0 =A0 =A0-------------------------------------------<br>
 =A0 =A0_______________________________________________<br>
 =A0 =A0keyassure mailing list<br></div>
 =A0 =A0<a href=3D"mailto:[email-masked]" target=3D"_blank">keyassure@i=
etf.org</a> &lt;mailto:<a href=3D"mailto:[email-masked]" target=3D"_bla=
nk">[email-masked]</a>&gt;<div class=3D"im"><br>
 =A0 =A0<a href=3D"https://www.ietf.org/mailman/listinfo/keyassure" target=
=3D"_blank">https://www.ietf.org/mailman/listinfo/keyassure</a><br>
<br>
<br>
<br>
<br>
--<br>
Website: <a href=3D"http://hallambaker.com/" target=3D"_blank">http://halla=
mbaker.com/</a><br>
<br>
</div></blockquote><div><div></div><div class=3D"h5">
<br>
<br>
-- <br>
=A0Ond=F8ej Sur=FD<br>
=A0vedouc=ED v=FDzkumu/Head of R&amp;D department<br>
=A0-------------------------------------------<br>
=A0CZ.NIC, z.s.p.o. =A0 =A0-- =A0 =A0Laborato=F8e CZ.NIC<br>
=A0Americka 23, 120 00 Praha 2, Czech Republic<br>
=A0mailto:<a href=3D"mailto:[email-masked]" target=3D"_blank">ondrej.su=
[email-masked]</a> =A0 =A0<a href=3D"http://nic.cz/" target=3D"_blank">http://ni=
c.cz/</a><br>
=A0tel:+420.222745110 =A0 =A0 =A0 fax:+420.222745112<br>
=A0-------------------------------------------<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>

--0016e64f8f4a43dc90049a0d241c--

From: Martin Rex <[email-masked]>
To: [email-masked] (Phillip Hallam-Baker)
Date: Mon, 17 Jan 2011 16:45:49 +0100 (MET)
Cc: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support
Reply-To: [email-masked]

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

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

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

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

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

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

-Martin

Date: Mon, 17 Jan 2011 10:11:35 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: [keyassure] Possible fix for pkix/dane certificate disagreement

DANE is an alternative for PKIX.

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

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

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

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

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

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

Paul

Date: Mon, 17 Jan 2011 16:09:23 +0100
From: =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] keyassure Digest, Vol 6, Issue 16

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

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

Ondrej

On 17.1.2011 15:55, Phillip Hallam-Baker wrote:
> OK, we will return to this in last call then
>
> And in IETF last call
>
> And when the PKIX people object to your whole spec on the grounds that
> you are changing theirs we can start DANE from scratch
>
>
> Blocking discussion of critical security issues in the WG is not going
> to get you to RFC any faster.
>
> You cannot claim to have a WG consensus if your response to every issue
> you don't like is to put your chair hart on and attempt to block discussion.
>
>
> On Mon, Jan 17, 2011 at 9:50 AM, Ondøej Surý <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     On 17.1.2011 15:30, Phillip Hallam-Baker wrote:
>
>         The specific concern would be that someone could make use of the
>         lightweight SMTP cert issue process to acquire a certificate for
>         another
>         service.
>
>      >
>
>         Another concern would be that in a heavily outsourced
>         deployment, I may
>         trust a company to run my inbound mail server but not want them
>         to have
>         the ability to advertise other services (like accepting payments).
>
>         The simplest, most direct way to enforce this type of
>         restriction is to
>         put a note in the certificate governing acceptable use.
>
>
>     No, the simplest, most direct way (apart from not using DANE at all)
>     is to have different host names for inbound mail server and other
>     services.
>
>     You have painted the very rare scenario in which the canonical name
>     (ie. the target of MX record) is same as some other service, and you
>     document the degradation of security on such unlikely scenario.
>
>     <chair hat>
>     I propose that either you present an evidence that it will have any
>     real impact or we just drop this issue since it's impact is
>     negligible. Thank you.
>     </chair hat>
>
>     BTW: I just hand checked top20 domain names from alexa list and all
>     of them has something like [.*][mx|mail|smtp].<domainname1> for
>     <domainname2> where usually domainname1 = domainname2.
>
>     O.
>
>     --
>       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] <mailto:[email-masked]> http://nic.cz/
>       tel:+420.222745110       fax:+420.222745112
>       -------------------------------------------
>     _______________________________________________
>     keyassure mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/keyassure
>
>
>
>
> --
> Website: http://hallambaker.com/
>

-- 
  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: Mon, 17 Jan 2011 09:56:56 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Wouters <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious?

--0016e644bc2ecdf0f2049a0bfe56
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

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

> On Mon, 17 Jan 2011, Phillip Hallam-Baker wrote:
>
>  2011/1/17 Ond=F8ej Sur=FD <[email-masked]>
>>
>>      We should solve the hardest problem first.
>>
>> Which in your opinion is?
>>
>> Working out how to support HTTP over TLS, SMTP over TLS and protocol X
>> over TLS without conflict.
>>
>
> Using which certificate validation scheme? DANE or PKIX/CA's? or Both?
>
> The last one is out of scope for DANE. The first one is by generating
> TLSA/HASTLS records that the application can look up - ignoring everythin=
g
> else in the certificate container.
>

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

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

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

<br><br><div class=3D"gmail_quote">2011/1/17 Paul Wouters <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>&gt;</span=
><br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">On Mon, 17 Jan 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">
2011/1/17 Ond=F8ej Sur=FD &lt;<a href=3D"mailto:[email-masked]" target=
=3D"_blank">[email-masked]</a>&gt;<br>
<br>
 =A0 =A0 =A0We should solve the hardest problem first.<br>
<br>
Which in your opinion is?<br>
<br>
Working out how to support HTTP over TLS, SMTP over TLS and protocol X over=
 TLS without conflict.<br>
</blockquote>
<br></div>
Using which certificate validation scheme? DANE or PKIX/CA&#39;s? or Both?<=
br>
<br>
The last one is out of scope for DANE. The first one is by generating<br>
TLSA/HASTLS records that the application can look up - ignoring everything<=
br>
else in the certificate container.<br></blockquote><div><br></div><div>DANE=
 has to prove that it can co-exist in the existing infrastructure without c=
ausing damage.</div><div><br></div><div><br></div></div><br>-- <br>Website:=
 <a href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br>
<br>

--0016e644bc2ecdf0f2049a0bfe56--

Date: Mon, 17 Jan 2011 09:55:25 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] keyassure Digest, Vol 6, Issue 16

--001636af0272566b92049a0bf958
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

OK, we will return to this in last call then

And in IETF last call

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

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

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

On Mon, Jan 17, 2011 at 9:50 AM, Ond=F8ej Sur=FD <[email-masked]> wrote=
:

> On 17.1.2011 15:30, Phillip Hallam-Baker wrote:
>
>> The specific concern would be that someone could make use of the
>> lightweight SMTP cert issue process to acquire a certificate for another
>> service.
>>
> >
>
>> Another concern would be that in a heavily outsourced deployment, I may
>> trust a company to run my inbound mail server but not want them to have
>> the ability to advertise other services (like accepting payments).
>>
>> The simplest, most direct way to enforce this type of restriction is to
>> put a note in the certificate governing acceptable use.
>>
>
> No, the simplest, most direct way (apart from not using DANE at all) is t=
o
> have different host names for inbound mail server and other services.
>
> You have painted the very rare scenario in which the canonical name (ie.
> the target of MX record) is same as some other service, and you document =
the
> degradation of security on such unlikely scenario.
>
> <chair hat>
> I propose that either you present an evidence that it will have any real
> impact or we just drop this issue since it's impact is negligible. Thank
> you.
> </chair hat>
>
> BTW: I just hand checked top20 domain names from alexa list and all of th=
em
> has something like [.*][mx|mail|smtp].<domainname1> for <domainname2> whe=
re
> usually domainname1 =3D domainname2.
>
> O.
>
> --
>  Ond=F8ej Sur=FD
>  vedouc=ED v=FDzkumu/Head of R&D department
>  -------------------------------------------
>  CZ.NIC, z.s.p.o.    --    Laborato=F8e 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
>

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

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

OK, we will return to this in last call then<div><br></div><div>And in IETF=
 last call</div><div><br></div><div>And when the PKIX people object to your=
 whole spec on the grounds that you are changing theirs we can start DANE f=
rom scratch</div>
<div><br></div><div><br></div><div>Blocking discussion of critical security=
 issues in the WG is not going to get you to RFC any faster.</div><div><br>=
</div><div>You cannot claim to have a WG consensus if your response to ever=
y issue you don&#39;t like is to put your chair hart on and attempt to bloc=
k discussion.</div>
<div><br></div><div><br><div class=3D"gmail_quote">On Mon, Jan 17, 2011 at =
9:50 AM, Ond=F8ej Sur=FD <span dir=3D"ltr">&lt;<a href=3D"mailto:ondrej.sur=
[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex;">
<div class=3D"im">On 17.1.2011 15:30, Phillip Hallam-Baker wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
The specific concern would be that someone could make use of the<br>
lightweight SMTP cert issue process to acquire a certificate for another<br=
>
service.<br>
</blockquote>
&gt;<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Another concern would be that in a heavily outsourced deployment, I may<br>
trust a company to run my inbound mail server but not want them to have<br>
the ability to advertise other services (like accepting payments).<br>
<br>
The simplest, most direct way to enforce this type of restriction is to<br>
put a note in the certificate governing acceptable use.<br>
</blockquote>
<br></div>
No, the simplest, most direct way (apart from not using DANE at all) is to =
have different host names for inbound mail server and other services.<br>
<br>
You have painted the very rare scenario in which the canonical name (ie. th=
e target of MX record) is same as some other service, and you document the =
degradation of security on such unlikely scenario.<br>
<br>
&lt;chair hat&gt;<br>
I propose that either you present an evidence that it will have any real im=
pact or we just drop this issue since it&#39;s impact is negligible. Thank =
you.<br>
&lt;/chair hat&gt;<br>
<br>
BTW: I just hand checked top20 domain names from alexa list and all of them=
 has something like [.*][mx|mail|smtp].&lt;domainname1&gt; for &lt;domainna=
me2&gt; where usually domainname1 =3D domainname2.<br><font color=3D"#88888=
8">
<br>
O.</font><div class=3D"im"><br>
-- <br>
=A0Ond=F8ej Sur=FD<br>
=A0vedouc=ED v=FDzkumu/Head of R&amp;D department<br>
=A0-------------------------------------------<br>
=A0CZ.NIC, z.s.p.o. =A0 =A0-- =A0 =A0Laborato=F8e CZ.NIC<br>
=A0Americka 23, 120 00 Praha 2, Czech Republic<br>
=A0mailto:<a href=3D"mailto:[email-masked]" target=3D"_blank">ondrej.su=
[email-masked]</a> =A0 =A0<a href=3D"http://nic.cz/" target=3D"_blank">http://ni=
c.cz/</a><br>
=A0tel:+420.222745110 =A0 =A0 =A0 fax:+420.222745112<br>
=A0-------------------------------------------<br>
_______________________________________________<br></div><div><div></div><d=
iv class=3D"h5">
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>

--001636af0272566b92049a0bf958--

Date: Mon, 17 Jan 2011 09:54:23 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious?

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

> 2011/1/17 Ondøej Surý <[email-masked]>
>
>       We should solve the hardest problem first.
> 
> Which in your opinion is?
> 
> Working out how to support HTTP over TLS, SMTP over TLS and protocol X over TLS without conflict.

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

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

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

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

Paul

Date: Mon, 17 Jan 2011 09:51:50 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] keyassure Digest, Vol 6, Issue 16

--0016e64405a088e817049a0bec42
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

2011/1/17 Ond=F8ej Sur=FD <[email-masked]>

> On 17.1.2011 15:20, Phillip Hallam-Baker wrote:
>
>> Rule number one is do no harm.
>>
>> If this group proposes a spec that damages the security of other
>> infrastructure it is going to be resisted.
>>
>
> You have created the hypothetical scenario in which the harm is created. =
 I
> find such scenario unlikely for security wise administrators (the admin
> blindly pasting output of some random sendmail script into the DNS).

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

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

Postulating a competent administrator is another way of saying 'lets rely o=
n
magic here'.

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

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

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

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

<br><br><div class=3D"gmail_quote">2011/1/17 Ond=F8ej Sur=FD <span dir=3D"l=
tr">&lt;<a href=3D"mailto:[email-masked]">[email-masked]</a>&gt;</s=
pan><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 17.1.2011 15:20, Phillip Hallam-Baker wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Rule number one is do no harm.<br>
<br>
If this group proposes a spec that damages the security of other<br>
infrastructure it is going to be resisted.<br>
</blockquote>
<br></div>
You have created the hypothetical scenario in which the harm is created. =
=A0I find such scenario unlikely for security wise administrators (the admi=
n blindly pasting output of some random sendmail script into the DNS).</blo=
ckquote>
<div><br></div><div>Relying on the competence of administrators to fix prot=
ocol security shortcomings is not acceptable.</div><div><br></div><div>All =
I am arguing for here is that this group does not presume to turn off secur=
ity controls that already exist in PKIX because it does not understand what=
 they are for.</div>
<div><br></div><div><br></div><div>Postulating a competent administrator is=
 another way of saying &#39;lets rely on magic here&#39;.</div><div><br></d=
iv><div>Anyone can design a system that is secure when someone who is compe=
tent (and honest) uses it. But in the real world only some people are compe=
tent some of the time.</div>
<div><br></div><div>Deployment of DNSSEC is already going to be a bear of a=
 job. And you are arguing that its ok to turn off controls to make it harde=
r.</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>

--0016e64405a088e817049a0bec42--

Date: Mon, 17 Jan 2011 15:50:34 +0100
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] keyassure Digest, Vol 6, Issue 16

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

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

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

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

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

O.
-- 
  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: Mon, 17 Jan 2011 09:38:12 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious?

--0016e644d5ccc7ae8c049a0bbb24
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

2011/1/17 Ond=F8ej Sur=FD <[email-masked]>

>
>  We should solve the hardest problem first.
>>
>
> Which in your opinion is?

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

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

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

2011/1/17 Ond=F8ej Sur=FD <span dir=3D"ltr">&lt;<a href=3D"mailto:ondrej.su=
[email-masked]">[email-masked]</a>&gt;</span><br><div class=3D"gmail_quote">=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;">
<div class=3D"im"><br></div><div class=3D"im">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
We should solve the hardest problem first.<br>
</blockquote>
<br></div>
Which in your opinion is?</blockquote><div><br></div><div>Working out how t=
o support HTTP over TLS, SMTP over TLS and protocol X over TLS without conf=
lict.</div><div><br></div><div><br></div></div><div><br></div><br>-- <br>
Website: <a href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br=
><br>

--0016e644d5ccc7ae8c049a0bbb24--

Date: Mon, 17 Jan 2011 15:34:55 +0100
From: =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] keyassure Digest, Vol 6, Issue 16

On 17.1.2011 15:20, Phillip Hallam-Baker wrote:
> Rule number one is do no harm.
>
> If this group proposes a spec that damages the security of other
> infrastructure it is going to be resisted.

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

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

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

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

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

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

Ondrej

> On Mon, Jan 17, 2011 at 8:48 AM, Ondøej Surý <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     On 17.1.2011 13:52, Phillip Hallam-Baker wrote:
>
>
>
>         On Sun, Jan 16, 2011 at 9:54 PM, Paul Wouters
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>             On Sun, 16 Jan 2011, Phillip Hallam-Baker wrote:
>
>                 I would like it to be possible for services like SMTP to
>                 establish TLS keys with minimal infrastructure. That
>                 can't happen if there is a risk that the low assurance
>         SMTP key
>                 will compromise the high assurance Web Server.
>
>
>             I'm not sure how this problem would work. Can you explain it
>         in a
>             little more detail?
>
>             Paul
>
>
>         Let us say that the authors of Sendmail decide that they want to
>         make it
>         easy to turn on STARTTLS.
>
>         So when the server is configured it looks to see if there is
>         DNSSEC on
>         the domain associated with its host name. If so it generates a
>         public
>         key pair, rolls itself a certificate and either tells the admin
>         the DNS
>         RR to insert in the zone or uses a TSIG type mechanism to
>         register the
>         key itself.
>
>
>         For this to be acceptable two conditions need to be met:
>
>         1) The security must be adequate for the SMTP service
>
>         2) The mechanism must not reduce the security of any other
>         service at
>         the domain
>
>
>         Since SMTP is generally engaged without cryptographic security, any
>         improvement is better than none and the first condition is a
>         really low bar.
>
>         But the second can be very complex. Particularly since the
>         authors of
>         the mail server don't want to have any idea what the rest of the
>         infrastructure might be at a site.
>
>         The safest way to make this work automatically is to make it
>         possible
>         for the mail service to mark its keys for SMTP use only.
>
>
>     I don't think we need to solve 2) from this babysitting perspective.
>
>     What you are talking about is about having different certs for
>     different services and we are back at issue #1 in the tracker.
>
>     If I take your example then most common case is that SMTP server is
>     named mail.<something>, f.e. mail.example.net
>     <http://mail.example.net>.  And I guess in most cases it will not
>     clash with another services under this name.  And it should be
>     handled by the admins in the few corner cases where the name of the
>     mail server is same as name of some other important service.
>
>     Ondrej
>     --
>       Ondøej Surý
>       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] <mailto:[email-masked]> http://nic.cz/
>       tel:+420.222745110       fax:+420.222745112
>       -------------------------------------------
>
>     _______________________________________________
>     keyassure mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/keyassure
>
>
>
>
> --
> Website: http://hallambaker.com/
>

-- 
  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: Mon, 17 Jan 2011 09:34:55 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] keyassure Digest, Vol 6, Issue 16

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

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

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

Paul

Date: Mon, 17 Jan 2011 09:32:48 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] keyassure Digest, Vol 6, Issue 16

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

> Rule number one is do no harm.
> If this group proposes a spec that damages the security of other infrastructure it is going to be resisted.

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

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

DANE would not change that.

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

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

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

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

Paul

> 
> On Mon, Jan 17, 2011 at 8:48 AM, Ondøej Surý <[email-masked]> wrote:
>       On 17.1.2011 13:52, Phillip Hallam-Baker wrote:
> 
>
>       On Sun, Jan 16, 2011 at 9:54 PM, Paul Wouters <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>    On Sun, 16 Jan 2011, Phillip Hallam-Baker wrote:
> 
>        I would like it to be possible for services like SMTP to
>        establish TLS keys with minimal infrastructure. That
>        can't happen if there is a risk that the low assurance SMTP key
>        will compromise the high assurance Web Server.
> 
> 
>    I'm not sure how this problem would work. Can you explain it in a
>    little more detail?
> 
>    Paul
> 
> 
> Let us say that the authors of Sendmail decide that they want to make it
> easy to turn on STARTTLS.
> 
> So when the server is configured it looks to see if there is DNSSEC on
> the domain associated with its host name. If so it generates a public
> key pair, rolls itself a certificate and either tells the admin the DNS
> RR to insert in the zone or uses a TSIG type mechanism to register the
> key itself.
> 
> 
> For this to be acceptable two conditions need to be met:
> 
> 1) The security must be adequate for the SMTP service
> 
> 2) The mechanism must not reduce the security of any other service at
> the domain
> 
> 
> Since SMTP is generally engaged without cryptographic security, any
> improvement is better than none and the first condition is a really low bar.
> 
> But the second can be very complex. Particularly since the authors of
> the mail server don't want to have any idea what the rest of the
> infrastructure might be at a site.
> 
> The safest way to make this work automatically is to make it possible
> for the mail service to mark its keys for SMTP use only.
> 
> 
> I don't think we need to solve 2) from this babysitting perspective.
> 
> What you are talking about is about having different certs for different services and we are back at issue #1 in the tracker.
> 
> If I take your example then most common case is that SMTP server is named mail.<something>, f.e. mail.example.net.  And I guess in most
> cases it will not clash with another services under this name.  And it should be handled by the admins in the few corner cases where the
> name of the mail server is same as name of some other important service.
> 
> Ondrej
> --
>  Ondøej Surý
>  vedoucí výzkumu/Head of R&D department
>  -------------------------------------------
>  CZ.NIC, z.s.p.o.    --    Laboratoøe CZ.NIC
>  Americka 23, 120 00 Praha 2, Czech Republic
>  mailto:[email-masked]    http://nic.cz/
>  tel:+420.222745110       fax:+420.222745112
>  -------------------------------------------
> 
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
> 
> 
> 
> 
> --
> Website: http://hallambaker.com/
> 
> 
>

Date: Mon, 17 Jan 2011 09:30:04 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Wouters <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] keyassure Digest, Vol 6, Issue 16

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

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

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

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

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

> On Mon, 17 Jan 2011, Phillip Hallam-Baker wrote:
>
>  Let us say that the authors of Sendmail decide that they want to make it
>> easy to turn on STARTTLS.
>> So when the server is configured it looks to see if there is DNSSEC on the
>> domain associated with its host name. If so it generates a public
>> key pair, rolls itself a certificate and either tells the admin the DNS RR
>> to insert in the zone or uses a TSIG type mechanism to register the
>> key itself.
>>
>> For this to be acceptable two conditions need to be met:
>>
>> 1) The security must be adequate for the SMTP service
>>
>> 2) The mechanism must not reduce the security of any other service at the
>> domain
>>
>
> It also assumes a "higher secure level" is available for the other (say
> www) service, which
> already has a cert - issued by the sysadmin and/or signed by a CA -thus
> using PKIX.
>
>
>  Since SMTP is generally engaged without cryptographic security, any
>> improvement is better than none and the first condition is a really low
>> bar.
>>
>
> Sure.
>
>
>  But the second can be very complex. Particularly since the authors of the
>> mail server don't want to have any idea what the rest of the
>> infrastructure might be at a site.
>>
>> The safest way to make this work automatically is to make it possible for
>> the mail service to mark its keys for SMTP use only.
>>
>
> I'm still unsure how this affects the cert on the web port? If we have
> multiple TLSA certs in DNS under the same name, and one appears on the
> mail server and one on the http server, how did the security of the http
> server get reduced by sendmail adding its cert to its config and DNS?
>
> At most, I can think of some compromise/mistake where the mail cert would
> get used on the httpd server. Eg a hacker compromises the webserver, the
> webserver cert is stored on disk (not in hardware) and password protected
> (which AFAIK is quite rare on web servers these days) and will now use
> the mail server cert on the web server to do evil. All of which I think
> could be done without restarting the webserver and thus losing the web
> server certificate.
>
> Any sufficiently important web server cert will be in stored in hardware
> and will be run on a dedicated server that is not also running mail.
>
> So I find it hard to see a real life use case where abusing the multiple
> TLSA certificates would provide a real life issue.
>
> Paul
>

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

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

The specific concern would be that someone could make use of the lightweigh=
t SMTP cert issue process to acquire a certificate for another service.<div=
><br></div><div><br></div><div>Another concern would be that in a heavily o=
utsourced deployment, I may trust a company to run my inbound mail server b=
ut not want them to have the ability to advertise other services (like acce=
pting payments).</div>
<div><br></div><div>The simplest, most direct way to enforce this type of r=
estriction is to put a note in the certificate governing acceptable use.</d=
iv><div><br></div><div><br><br><div class=3D"gmail_quote">On Mon, Jan 17, 2=
011 at 9:17 AM, Paul Wouters <span dir=3D"ltr">&lt;<a href=3D"mailto:paul@x=
elerance.com">[email-masked]</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;"><div class=3D"im">On Mon, 17 Jan 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">
Let us say that the authors of Sendmail decide that they want to make it ea=
sy to turn on STARTTLS.<br>
So when the server is configured it looks to see if there is DNSSEC on the =
domain associated with its host name. If so it generates a public<br>
key pair, rolls itself a certificate and either tells the admin the DNS RR =
to insert in the zone or uses a TSIG type mechanism to register the<br>
key itself.<br>
<br>
For this to be acceptable two conditions need to be met:<br>
<br>
1) The security must be adequate for the SMTP service<br>
<br>
2) The mechanism must not reduce the security of any other service at the d=
omain<br>
</blockquote>
<br></div>
It also assumes a &quot;higher secure level&quot; is available for the othe=
r (say www) service, which<br>
already has a cert - issued by the sysadmin and/or signed by a CA -thus usi=
ng PKIX.<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">
Since SMTP is generally engaged without cryptographic security, any improve=
ment is better than none and the first condition is a really low<br>
bar.<br>
</blockquote>
<br></div>
Sure.<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">
But the second can be very complex. Particularly since the authors of the m=
ail server don&#39;t want to have any idea what the rest of the<br>
infrastructure might be at a site.<br>
<br>
The safest way to make this work automatically is to make it possible for t=
he mail service to mark its keys for SMTP use only.=A0<br>
</blockquote>
<br></div>
I&#39;m still unsure how this affects the cert on the web port? If we have<=
br>
multiple TLSA certs in DNS under the same name, and one appears on the<br>
mail server and one on the http server, how did the security of the http<br=
>
server get reduced by sendmail adding its cert to its config and DNS?<br>
<br>
At most, I can think of some compromise/mistake where the mail cert would<b=
r>
get used on the httpd server. Eg a hacker compromises the webserver, the<br=
>
webserver cert is stored on disk (not in hardware) and password protected<b=
r>
(which AFAIK is quite rare on web servers these days) and will now use<br>
the mail server cert on the web server to do evil. All of which I think<br>
could be done without restarting the webserver and thus losing the web<br>
server certificate.<br>
<br>
Any sufficiently important web server cert will be in stored in hardware<br=
>
and will be run on a dedicated server that is not also running mail.<br>
<br>
So I find it hard to see a real life use case where abusing the multiple<br=
>
TLSA certificates would provide a real life issue.<br><font color=3D"#88888=
8">
<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>

--00163662e65bb6444b049a0b9ec3--

Date: Mon, 17 Jan 2011 09:25:14 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious?

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

> The only reason to narrow consideration to TLS would be to try to save time.
> AsI am pointing out here, we have three choices.
> 
> 1) TLS only
> 2) X.509 only
> 3) HTTP only

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

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

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

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

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

Paul

Date: Mon, 17 Jan 2011 09:20:27 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] keyassure Digest, Vol 6, Issue 16

--0016e645b848465c63049a0b7c24
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

Rule number one is do no harm.

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

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

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

On Mon, Jan 17, 2011 at 8:48 AM, Ond=F8ej Sur=FD <[email-masked]> wrote=
:

> On 17.1.2011 13:52, Phillip Hallam-Baker wrote:
>
>>
>>
>> On Sun, Jan 16, 2011 at 9:54 PM, Paul Wouters <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>    On Sun, 16 Jan 2011, Phillip Hallam-Baker wrote:
>>
>>        I would like it to be possible for services like SMTP to
>>        establish TLS keys with minimal infrastructure. That
>>        can't happen if there is a risk that the low assurance SMTP key
>>        will compromise the high assurance Web Server.
>>
>>
>>    I'm not sure how this problem would work. Can you explain it in a
>>    little more detail?
>>
>>    Paul
>>
>>
>> Let us say that the authors of Sendmail decide that they want to make it
>> easy to turn on STARTTLS.
>>
>> So when the server is configured it looks to see if there is DNSSEC on
>> the domain associated with its host name. If so it generates a public
>> key pair, rolls itself a certificate and either tells the admin the DNS
>> RR to insert in the zone or uses a TSIG type mechanism to register the
>> key itself.
>>
>>
>> For this to be acceptable two conditions need to be met:
>>
>> 1) The security must be adequate for the SMTP service
>>
>> 2) The mechanism must not reduce the security of any other service at
>> the domain
>>
>>
>> Since SMTP is generally engaged without cryptographic security, any
>> improvement is better than none and the first condition is a really low
>> bar.
>>
>> But the second can be very complex. Particularly since the authors of
>> the mail server don't want to have any idea what the rest of the
>> infrastructure might be at a site.
>>
>> The safest way to make this work automatically is to make it possible
>> for the mail service to mark its keys for SMTP use only.
>>
>
> I don't think we need to solve 2) from this babysitting perspective.
>
> What you are talking about is about having different certs for different
> services and we are back at issue #1 in the tracker.
>
> If I take your example then most common case is that SMTP server is named
> mail.<something>, f.e. mail.example.net.  And I guess in most cases it
> will not clash with another services under this name.  And it should be
> handled by the admins in the few corner cases where the name of the mail
> server is same as name of some other important service.
>
> Ondrej
> --
>  Ond=F8ej Sur=FD
>  vedouc=ED v=FDzkumu/Head of R&D department
>  -------------------------------------------
>  CZ.NIC, z.s.p.o.    --    Laborato=F8e 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
>

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

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

Rule number one is do no harm.<div><br></div><div>If this group proposes a =
spec that damages the security of other infrastructure it is going to be re=
sisted.</div><div><br></div><div><br></div><div>DNS name allocation has alw=
ays been left to site policy. The target of an MX record is required to be =
a canonical name. Thus it should be the unique name of the host.</div>
<div><br></div><div>If you want to propose unnecessary changes to DNS opera=
tions to make your specification proposal work then you are going to find g=
etting IETF consensus very difficult.</div><div><br></div><div><br></div>
<div><br></div><div><br><div class=3D"gmail_quote">On Mon, Jan 17, 2011 at =
8:48 AM, Ond=F8ej Sur=FD <span dir=3D"ltr">&lt;<a href=3D"mailto:ondrej.sur=
[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex;">
<div class=3D"im">On 17.1.2011 13:52, Phillip Hallam-Baker wrote:<br>
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div class=3D"im">
<br>
<br>
On Sun, Jan 16, 2011 at 9:54 PM, Paul Wouters &lt;<a href=3D"mailto:paul@xe=
lerance.com" target=3D"_blank">[email-masked]</a><br></div><div><div></=
div><div class=3D"h5">
&lt;mailto:<a href=3D"mailto:[email-masked]" target=3D"_blank">paul@xel=
erance.com</a>&gt;&gt; wrote:<br>
<br>
 =A0 =A0On Sun, 16 Jan 2011, Phillip Hallam-Baker wrote:<br>
<br>
 =A0 =A0 =A0 =A0I would like it to be possible for services like SMTP to<br=
>
 =A0 =A0 =A0 =A0establish TLS keys with minimal infrastructure. That<br>
 =A0 =A0 =A0 =A0can&#39;t happen if there is a risk that the low assurance =
SMTP key<br>
 =A0 =A0 =A0 =A0will compromise the high assurance Web Server.<br>
<br>
<br>
 =A0 =A0I&#39;m not sure how this problem would work. Can you explain it in=
 a<br>
 =A0 =A0little more detail?<br>
<br>
 =A0 =A0Paul<br>
<br>
<br>
Let us say that the authors of Sendmail decide that they want to make it<br=
>
easy to turn on STARTTLS.<br>
<br>
So when the server is configured it looks to see if there is DNSSEC on<br>
the domain associated with its host name. If so it generates a public<br>
key pair, rolls itself a certificate and either tells the admin the DNS<br>
RR to insert in the zone or uses a TSIG type mechanism to register the<br>
key itself.<br>
<br>
<br>
For this to be acceptable two conditions need to be met:<br>
<br>
1) The security must be adequate for the SMTP service<br>
<br>
2) The mechanism must not reduce the security of any other service at<br>
the domain<br>
<br>
<br>
Since SMTP is generally engaged without cryptographic security, any<br>
improvement is better than none and the first condition is a really low bar=
.<br>
<br>
But the second can be very complex. Particularly since the authors of<br>
the mail server don&#39;t want to have any idea what the rest of the<br>
infrastructure might be at a site.<br>
<br>
The safest way to make this work automatically is to make it possible<br>
for the mail service to mark its keys for SMTP use only.<br>
</div></div></blockquote>
<br>
I don&#39;t think we need to solve 2) from this babysitting perspective.<br=
>
<br>
What you are talking about is about having different certs for different se=
rvices and we are back at issue #1 in the tracker.<br>
<br>
If I take your example then most common case is that SMTP server is named m=
ail.&lt;something&gt;, f.e. <a href=3D"http://mail.example.net" target=3D"_=
blank">mail.example.net</a>. =A0And I guess in most cases it will not clash=
 with another services under this name. =A0And it should be handled by the =
admins in the few corner cases where the name of the mail server is same as=
 name of some other important service.<br>

<br>
Ondrej<br>
-- <br><font color=3D"#888888">
=A0Ond=F8ej Sur=FD<br>
=A0vedouc=ED v=FDzkumu/Head of R&amp;D department<br>
=A0-------------------------------------------<br>
=A0CZ.NIC, z.s.p.o. =A0 =A0-- =A0 =A0Laborato=F8e CZ.NIC<br>
=A0Americka 23, 120 00 Praha 2, Czech Republic<br>
=A0mailto:<a href=3D"mailto:[email-masked]" target=3D"_blank">ondrej.su=
[email-masked]</a> =A0 =A0<a href=3D"http://nic.cz/" target=3D"_blank">http://ni=
c.cz/</a><br>
=A0tel:+420.222745110 =A0 =A0 =A0 fax:+420.222745112<br>
=A0-------------------------------------------</font><div><div></div><div c=
lass=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>

--0016e645b848465c63049a0b7c24--

Date: Mon, 17 Jan 2011 09:17:37 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] keyassure Digest, Vol 6, Issue 16

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

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

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

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

Sure.

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

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

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

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

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

Paul

Date: Mon, 17 Jan 2011 15:10:53 +0100
From: =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious?

On 17.1.2011 14:02, Phillip Hallam-Baker wrote:
> The only reason to narrow consideration to TLS would be to try to
> save time.

Eh, I got lost, at first you wrote:

On 16.1.2011 14:50, Phillip Hallam-Baker wrote:
> 1) Should the protocol only support TLS
> 2) Should the protocol only support TLS+HTTP
> 3) Should the protocol only support TLS+HTTP for Web browsing.

and now you are writing:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> We should solve the hardest problem first.

Which in your opinion is?

O.
-- 
  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: Mon, 17 Jan 2011 14:48:54 +0100
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] keyassure Digest, Vol 6, Issue 16

On 17.1.2011 13:52, Phillip Hallam-Baker wrote:
>
>
> On Sun, Jan 16, 2011 at 9:54 PM, Paul Wouters <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     On Sun, 16 Jan 2011, Phillip Hallam-Baker wrote:
>
>         I would like it to be possible for services like SMTP to
>         establish TLS keys with minimal infrastructure. That
>         can't happen if there is a risk that the low assurance SMTP key
>         will compromise the high assurance Web Server.
>
>
>     I'm not sure how this problem would work. Can you explain it in a
>     little more detail?
>
>     Paul
>
>
> Let us say that the authors of Sendmail decide that they want to make it
> easy to turn on STARTTLS.
>
> So when the server is configured it looks to see if there is DNSSEC on
> the domain associated with its host name. If so it generates a public
> key pair, rolls itself a certificate and either tells the admin the DNS
> RR to insert in the zone or uses a TSIG type mechanism to register the
> key itself.
>
>
> For this to be acceptable two conditions need to be met:
>
> 1) The security must be adequate for the SMTP service
>
> 2) The mechanism must not reduce the security of any other service at
> the domain
>
>
> Since SMTP is generally engaged without cryptographic security, any
> improvement is better than none and the first condition is a really low bar.
>
> But the second can be very complex. Particularly since the authors of
> the mail server don't want to have any idea what the rest of the
> infrastructure might be at a site.
>
> The safest way to make this work automatically is to make it possible
> for the mail service to mark its keys for SMTP use only.

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

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

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

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

From: James Cloos <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABHNCSVQICAgIfAhkiAAAAI1J REFUOE+lU9ESgCAIg64P1y+ngUdxhl5H8wFbbM0OmUiEhKkCYaZThXCo6KE5sCbA1DDX3genvO4d eBQgEMaM5qy6uWk4SfBYfdu9jvBN9nSVDOKRtwb+I3epboOsOX5pZbJNsBJFvmQQ05YMfieIBnYX FK2N6dOawd97r/e8RjkTLzmMsiVgrAoEugtviCM3v2WzjgAAAABJRU5ErkJggg==
Copyright: Copyright 2009 James Cloos
OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
Date: Sun, 16 Jan 2011 20:42:08 -0500
Lines: 12
Cc: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious?

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

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

That makes very good sense.

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

Date: Mon, 17 Jan 2011 08:02:57 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious?

--001636af02722484ac049a0a6789
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable

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

AsI am pointing out here, we have three choices.

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

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

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

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

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

We should solve the hardest problem first.

On Mon, Jan 17, 2011 at 3:54 AM, Ond=F8ej Sur=FD <[email-masked]> wrote=
:

> On 16.1.2011 05:00, Warren Kumari wrote:
>
>>
>> On Jan 15, 2011, at 10:15 PM, Warren Kumari wrote:
>>
>>  Buoyed by actual progress on getting the first issue resolved, I'm
>>> proposing that we jump right into... the 17th issue.
>>>
>>> Issue #17: Should draft-ietf-dane-protocol support TLS only or be
>>> more ambitious?
>>> (http://trac.tools.ietf.org/wg/dane/trac/ticket/17):
>>>
>>> Description: ------- Please note: This is not the "what all
>>> protocols can / do we want to support" issue. That will be a
>>> separate (and probably lively!) discussion.
>>>
>>> The current version of draft-ietf-dane-protocol is titled "Using
>>> Secure DNS to Associate Certificates with Domain Names For TLS"
>>> and first goal / milestone is "First WG draft of standards-track
>>> protocol for using DNS to associate hosts with keys for TLS and
>>> DTLS".
>>>
>>> What I would like us to discuss is: Should *this* document simply
>>> specify how to support TLS and future protocols can be supported
>>> by saying "TLSA, but interpret field Foo to contain Bar" (or
>>> "Similar to TLSA, but this different RR, formatted like Baz"). Note
>>> that some other protocols already have similar RRtypes; for example
>>> SSH already has SSHFP.
>>>
>>
>> <no hats>
>>
>> This approach is my personal preference. Having a document that
>> clearly explains how something works for one simple, concrete use
>> case is (IMO) much easier to understand than a document that tried
>> to be all things to all people and cover all cases. This approach
>> should also allow us to make much faster progress, and will allow us
>> to gain experience and will address the largest use case up front.
>>
>
> <no hat>
>
> +1
>
>
> On 16.1.2011 15:27, Simon Josefsson wrote:
>
>> As a reminder, TLS supports more than X.509.  The current draft is
>> hard wired for X.509 only.
>>
>
> Can we untie the draft from X.509?
>
>
>  1) Should the protocol only support TLS with X.509
>> 2) Should the protocol only support TLS with X.509 + HTTP
>> 3) Should the protocol only support TLS with X.509 + HTTP for Web
>> browsing.
>>
>
> I certainly don't want to limit this to just HTTP.  One of my initial
> drives for this WG was to support and improve SMTP, where lot's of unsign=
ed
> certs happen to reside.
>
> </no hat>
>
> <chair hat>
>
> Anyway I think the issue #17 is TLS-only or more.  So we should focus on
> that and make separate issue out of the TLS+<any_proto> or TLS+HTTP. Let'=
s
> not widen our issues unless absolutely necessary.
>
> </chair hat>
>
> Ondrej
> --
>  Ond=F8ej Sur=FD
>  vedouc=ED v=FDzkumu/Head of R&D department
>  -------------------------------------------
>  CZ.NIC, z.s.p.o.    --    Laborato=F8e 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
>

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

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

The only reason to narrow consideration to TLS would be to try to save time=
.<div><br></div><div>AsI am pointing out here, we have three choices.</div>=
<div><br></div><div>1) TLS only</div><div>2) X.509 only</div><div>3) HTTP o=
nly</div>
<div><br></div><div>Any decent PKI architecture is going to be independent =
of the protocol that consumes the key. Choosing to only document TLS will s=
ave a some time. But only designing for TLS will not.=A0</div><div><br></di=
v>
<div>Choosing to support multiple key formats does greatly increase the com=
plexity of the specification but delivers zero value as the only people who=
 care about the use of the key format are a narrow technical clique. Suppor=
t for different key formats will not increase the practical value of the sp=
ec in any way whatsoever.</div>
<div><br></div><div>Support for multiple application protocols is essential=
. There are more application protocols that may be used than there is code =
space for DNS RRs. If we don&#39;t address this use case the whole scheme i=
s worthless.</div>
<div><br></div><div><br></div><div>So suggest that we stop talking about #1=
7 at this point because it is not the most relevant decision. It is a choic=
e that people are wanting to take to fool themselves that they are getting =
focused when they are doing no such thing.=A0</div>
<div><br></div><div>We should solve the hardest problem first.=A0</div><div=
><br><br><div class=3D"gmail_quote">On Mon, Jan 17, 2011 at 3:54 AM, Ond=F8=
ej Sur=FD <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">ondre=
[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><div></div><div class=3D"h5">On 16.1.2=
011 05:00, Warren Kumari wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<br>
On Jan 15, 2011, at 10:15 PM, Warren Kumari wrote:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Buoyed by actual progress on getting the first issue resolved, I&#39;m<br>
proposing that we jump right into... the 17th issue.<br>
<br>
Issue #17: Should draft-ietf-dane-protocol support TLS only or be<br>
more ambitious?<br>
(<a href=3D"http://trac.tools.ietf.org/wg/dane/trac/ticket/17" target=3D"_b=
lank">http://trac.tools.ietf.org/wg/dane/trac/ticket/17</a>):<br>
<br>
Description: ------- Please note: This is not the &quot;what all<br>
protocols can / do we want to support&quot; issue. That will be a<br>
separate (and probably lively!) discussion.<br>
<br>
The current version of draft-ietf-dane-protocol is titled &quot;Using<br>
Secure DNS to Associate Certificates with Domain Names For TLS&quot;<br>
and first goal / milestone is &quot;First WG draft of standards-track<br>
protocol for using DNS to associate hosts with keys for TLS and<br>
DTLS&quot;.<br>
<br>
What I would like us to discuss is: Should *this* document simply<br>
specify how to support TLS and future protocols can be supported<br>
by saying &quot;TLSA, but interpret field Foo to contain Bar&quot; (or<br>
&quot;Similar to TLSA, but this different RR, formatted like Baz&quot;). No=
te<br>
that some other protocols already have similar RRtypes; for example<br>
SSH already has SSHFP.<br>
</blockquote>
<br>
&lt;no hats&gt;<br>
<br>
This approach is my personal preference. Having a document that<br>
clearly explains how something works for one simple, concrete use<br>
case is (IMO) much easier to understand than a document that tried<br>
to be all things to all people and cover all cases. This approach<br>
should also allow us to make much faster progress, and will allow us<br>
to gain experience and will address the largest use case up front.<br>
</blockquote>
<br></div></div>
&lt;no hat&gt;<br>
<br>
+1<div class=3D"im"><br>
<br>
On 16.1.2011 15:27, Simon Josefsson wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
As a reminder, TLS supports more than X.509. =A0The current draft is<br>
hard wired for X.509 only.<br>
</blockquote>
<br></div>
Can we untie the draft from X.509?<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">
1) Should the protocol only support TLS with X.509<br>
2) Should the protocol only support TLS with X.509 + HTTP<br>
3) Should the protocol only support TLS with X.509 + HTTP for Web<br>
browsing.<br>
</blockquote>
<br></div>
I certainly don&#39;t want to limit this to just HTTP. =A0One of my initial=
 drives for this WG was to support and improve SMTP, where lot&#39;s of uns=
igned certs happen to reside.<br>
<br>
&lt;/no hat&gt;<br>
<br>
&lt;chair hat&gt;<br>
<br>
Anyway I think the issue #17 is TLS-only or more. =A0So we should focus on =
that and make separate issue out of the TLS+&lt;any_proto&gt; or TLS+HTTP. =
Let&#39;s not widen our issues unless absolutely necessary.<br>
<br>
&lt;/chair hat&gt;<br>
<br>
Ondrej<br>
-- <br><font color=3D"#888888">
=A0Ond=F8ej Sur=FD<br>
=A0vedouc=ED v=FDzkumu/Head of R&amp;D department<br>
=A0-------------------------------------------<br>
=A0CZ.NIC, z.s.p.o. =A0 =A0-- =A0 =A0Laborato=F8e CZ.NIC<br>
=A0Americka 23, 120 00 Praha 2, Czech Republic<br>
=A0mailto:<a href=3D"mailto:[email-masked]" target=3D"_blank">ondrej.su=
[email-masked]</a> =A0 =A0<a href=3D"http://nic.cz/" target=3D"_blank">http://ni=
c.cz/</a><br>
=A0tel:+420.222745110 =A0 =A0 =A0 fax:+420.222745112<br>
=A0-------------------------------------------</font><div><div></div><div c=
lass=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>

--001636af02722484ac049a0a6789--

Date: Mon, 17 Jan 2011 07:52:22 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Wouters <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] keyassure Digest, Vol 6, Issue 16

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

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

> On Sun, 16 Jan 2011, Phillip Hallam-Baker wrote:
>
>> I would like it to be possible for services like SMTP to establish TLS
>> keys with minimal infrastructure. That
>> can't happen if there is a risk that the low assurance SMTP key will
>> compromise the high assurance Web Server.
>>
>
> I'm not sure how this problem would work. Can you explain it in a little
> more detail?
>
> Paul
>

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

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

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

1) The security must be adequate for the SMTP service

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

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

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

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

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

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

<br><br><div class=3D"gmail_quote">On Sun, Jan 16, 2011 at 9:54 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 Sun, 16 Jan 2011, Phillip Hallam-Baker wrote:<br></div=
><div class=3D"im">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I would like it to be possible for services like SMTP to establish TLS keys=
 with minimal infrastructure. That<br>
can&#39;t happen if there is a risk that the low assurance SMTP key will co=
mpromise the high assurance Web Server.<br>
</blockquote>
<br></div>
I&#39;m not sure how this problem would work. Can you explain it in a littl=
e more detail?<br><font color=3D"#888888">
<br>
Paul<br>
</font></blockquote></div><br>Let us say that the authors of Sendmail decid=
e that they want to make it easy to turn on STARTTLS.<div><br></div><div>So=
 when the server is configured it looks to see if there is DNSSEC on the do=
main associated with its host name. If so it generates a public key pair, r=
olls itself a certificate and either tells the admin the DNS RR to insert i=
n the zone or uses a TSIG type mechanism to register the key itself.<br cle=
ar=3D"all">
<br></div><div><br></div><div>For this to be acceptable two conditions need=
 to be met:</div><div><br></div><div>1) The security must be adequate for t=
he SMTP service</div><div><br></div><div>2) The mechanism must not reduce t=
he security of any other service at the domain</div>
<div><br></div><div><br></div><div>Since SMTP is generally engaged without =
cryptographic security, any improvement is better than none and the first c=
ondition is a really low bar.</div><div><br></div><div>But the second can b=
e very complex. Particularly since the authors of the mail server don&#39;t=
 want to have any idea what the rest of the infrastructure might be at a si=
te.</div>
<div><br></div><div>The safest way to make this work automatically is to ma=
ke it possible for the mail service to mark its keys for SMTP use only.=A0<=
/div><div><br></div><div><br></div><div><br>-- <br>Website: <a href=3D"http=
://hallambaker.com/">http://hallambaker.com/</a><br>
<br>
</div>

--0016e64f8f4a4e1c74049a0a41fa--

Date: Mon, 17 Jan 2011 09:54:44 +0100
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious?

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

<no hat>

+1

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

Can we untie the draft from X.509?

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

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

</no hat>

<chair hat>

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

</chair hat>

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

Date: Sun, 16 Jan 2011 21:54:17 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] keyassure Digest, Vol 6, Issue 16

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

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

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

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

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

Paul

Date: Sun, 16 Jan 2011 21:32:38 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Wouters <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] keyassure Digest, Vol 6, Issue 16

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

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

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

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

> On Sun, 16 Jan 2011, Phillip Hallam-Baker wrote:
>
>  Mostly agree
>> But restrictions on the validity and/or use of the certificate MUST still
>> be observed.
>>
>> i.e. if a self-signed certificate says that the subject is Bank of Ethel
>> then that is a positive statement and
>> MUST be ignored.
>>
>> But if the certificate says 'not valid after X' or 'only for protocol Y'
>> or has an unknown critical extension
>> then it MUST be rejected.
>>
>
> I am not sure if I agree (or disagree)
>
> If the pubkey is DNSSEC validated, shouldn't it be treated as valid?
> especially in the
> absence of a validation by a CA (eg a self signed cert)
>
> I forsee people adding existing non-CA, self signed certs in DNS and
> forgetting their
> validity period. And in some sense whether or not the validated pubkey is
> in DNSSEC,
> is the claim of validity.
>
> However I also expect browsers not to take these certificates too different
> from their
> existing policies with respect to displaying non-validated certificate
> properties. So
> this issue is somewhat moot, the admin should generate a proper certificate
> and hopefully
> later can use a bare public key TLS variant to avoid all of this.
>
> I guess I could live with either, which means its probably a local
> user/vendor policy
> decision? eg I could see a browser popup for this.
>
> The one thing I am feeling more strongly about, is the ignoring of the CN=
> in self signed
> certs and taking the DNS location of the TLSA record as the authority for
> the certificate
> being valid, even if the CN= does not match. Specifically because it eases
> larger scale
> ssl deployment, which I think is one of the goals of this draft.
>
> Paul
>
>
>  On Sun, Jan 16, 2011 at 2:42 PM, Yaron Sheffer <[email-masked]>
>> wrote:
>>      Hi Paul,
>>
>>      For the first sentence of 3.1.2, I don't care if it's SHOULD or MUST.
>> But it's got to be
>>      normative.
>>
>>      Having reread 3.1.3, I am literally shocked by the way we propose to
>> deal with certs that (1)
>>      validate OK with respect to DNSSEC but (2) do not chain up to a known
>> trust anchor. We propose to
>>      leave the decision to the user, just like the bad old days of PKI!
>>
>>      Instead, I suggest to replace *both* 3.1.3 and 3.1.4 by the following
>> text:
>>
>>      3.1.3 Non-Validated Certificates
>>
>>      Certificates that are correctly associated with a domain name, but
>> which do not chain into a
>>      locally stored trust anchor, are no different from self-signed
>> certificates. Therefore, only their
>>      public key can be used in conjunction with the associated domain
>> name. Other pertinent data in the
>>      certificate, such as the Subject, Issuer and Subject Alternative Name
>> fields, as well as EV
>>      indications, MUST be ignored. In particular, TLS clients MUST NOT
>> present such data to the user.
>>
>>      [Alternatively, if we suggest to give Type 3/4 associations the full
>> CA treatment, where the
>>      complete cert chain becomes trusted, this may also be fine. But we
>> should not leave this decision
>>      to the end user!]
>>
>>      Thanks,
>>             Yaron
>>
>>            Date: Sat, 15 Jan 2011 17:08:11 -0800
>>            From: Paul Hoffman<[email-masked]>
>>            Subject: Re: [keyassure] draft-ietf-dane-protocol-02 posted -
>> cert
>>                   validation
>>            To: [email-masked]
>>            Message-ID:<[email-masked]>
>>            Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>>            On 1/15/11 1:15 PM, Yaron Sheffer wrote:
>>                  Sec. 3.1.2 of the draft singles out self-signed certs,
>> where "host
>>                  names" (in the section title) or "all data other than the
>> key" (first
>>                  paragraph) is ignored.
>>
>>                  I have two issues here:
>>
>>                  - The first paragraph should have a normative SHOULD,
>> instead of "can".
>>                  The data is indeed untrustworthy and clients SHOULD
>> ignore it unless
>>                  validated otherwise.
>>
>>
>>            This was argued about previously, I think. This should be a new
>> open
>>            issue because it deals with adding a 2119-level restriction.
>> Also, why
>>            "SHOULD" and not "MUST"? When is is OK to not ignore the data?
>> (FWIW, I
>>            don't have strong feelings either way on any of this).
>>
>>                  - The exact same considerations apply to non-self signed
>> certs. I don't
>>                  see a reason to talk specifically about self-signed
>> certs.
>>
>>
>>            We disagree here. The Issuer field in a CA certificate cannot
>> be ignored
>>            when doing PKIX chaining.
>>
>>                  Just because
>>                  someone presents a cert that has, say, Verisign as the
>> Issuer, doesn't
>>                  mean it is a valid Verisign certificate unless validated
>> in the
>>                  traditional manner.
>>
>>
>>            Um, exactly. But self-signed certs are not "validated in the
>> traditional
>>            manner", which is why this section exists.
>>
>>                  So none of the certificate data can be trusted,
>>                  including the important Subject and SubjectAltName
>> fields. Sec. 3.1.4
>>                  kind of implies this fact, but the incorrect
>> differentiation between
>>                  regular and self-signed certs remains.
>>
>>
>>            I believe there is a strong differentiation between "was
>> validated" and
>>            "wasn't validated". If you and I are saying the same thing, I
>> would love
>>            to see text to clarify what we have written.
>>
>>            --Paul Hoffman
>>
>>      _______________________________________________
>>      keyassure mailing list
>>      [email-masked]
>>      https://www.ietf.org/mailman/listinfo/keyassure
>>
>>
>>
>>
>> --
>> Website: http://hallambaker.com/
>>
>>
>>
>>

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

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

If the creator of a self signed certificate chose to put restrictions on it=
s use then those should be respected.<div><br></div><div><br></div><div>I w=
ould like it to be possible for services like SMTP to establish TLS keys wi=
th minimal infrastructure. That can&#39;t happen if there is a risk that th=
e low assurance SMTP key will compromise the high assurance Web Server.</di=
v>
<div><br></div><div><br><div class=3D"gmail_quote">On Sun, Jan 16, 2011 at =
9:08 PM, Paul Wouters <span dir=3D"ltr">&lt;<a href=3D"mailto:paul@xeleranc=
e.com">[email-masked]</a>&gt;</span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex;">
<div class=3D"im">On Sun, 16 Jan 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">
Mostly agree<br>
But restrictions on the validity and/or use of the certificate MUST still b=
e observed.<br>
<br>
i.e. if a self-signed certificate says that the subject is Bank of Ethel th=
en that is a positive statement and<br>
MUST be ignored.<br>
<br>
But if the certificate says &#39;not valid after X&#39; or &#39;only for pr=
otocol Y&#39; or has an unknown critical extension<br>
then it MUST be rejected.<br>
</blockquote>
<br></div>
I am not sure if I agree (or disagree)<br>
<br>
If the pubkey is DNSSEC validated, shouldn&#39;t it be treated as valid? es=
pecially in the<br>
absence of a validation by a CA (eg a self signed cert)<br>
<br>
I forsee people adding existing non-CA, self signed certs in DNS and forget=
ting their<br>
validity period. And in some sense whether or not the validated pubkey is i=
n DNSSEC,<br>
is the claim of validity.<br>
<br>
However I also expect browsers not to take these certificates too different=
 from their<br>
existing policies with respect to displaying non-validated certificate prop=
erties. So<br>
this issue is somewhat moot, the admin should generate a proper certificate=
 and hopefully<br>
later can use a bare public key TLS variant to avoid all of this.<br>
<br>
I guess I could live with either, which means its probably a local user/ven=
dor policy<br>
decision? eg I could see a browser popup for this.<br>
<br>
The one thing I am feeling more strongly about, is the ignoring of the CN=
=3D in self signed<br>
certs and taking the DNS location of the TLSA record as the authority for t=
he certificate<br>
being valid, even if the CN=3D does not match. Specifically because it ease=
s larger scale<br>
ssl deployment, which I think is one of the goals of this draft.<br><font c=
olor=3D"#888888">
<br>
Paul</font><div><div></div><div class=3D"h5"><br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On Sun, Jan 16, 2011 at 2:42 PM, Yaron Sheffer &lt;<a href=3D"mailto:yaronf=
[email-masked]" target=3D"_blank">[email-masked]</a>&gt; wrote:<br>
 =A0 =A0 =A0Hi Paul,<br>
<br>
 =A0 =A0 =A0For the first sentence of 3.1.2, I don&#39;t care if it&#39;s S=
HOULD or MUST. But it&#39;s got to be<br>
 =A0 =A0 =A0normative.<br>
<br>
 =A0 =A0 =A0Having reread 3.1.3, I am literally shocked by the way we propo=
se to deal with certs that (1)<br>
 =A0 =A0 =A0validate OK with respect to DNSSEC but (2) do not chain up to a=
 known trust anchor. We propose to<br>
 =A0 =A0 =A0leave the decision to the user, just like the bad old days of P=
KI!<br>
<br>
 =A0 =A0 =A0Instead, I suggest to replace *both* 3.1.3 and 3.1.4 by the fol=
lowing text:<br>
<br>
 =A0 =A0 =A03.1.3 Non-Validated Certificates<br>
<br>
 =A0 =A0 =A0Certificates that are correctly associated with a domain name, =
but which do not chain into a<br>
 =A0 =A0 =A0locally stored trust anchor, are no different from self-signed =
certificates. Therefore, only their<br>
 =A0 =A0 =A0public key can be used in conjunction with the associated domai=
n name. Other pertinent data in the<br>
 =A0 =A0 =A0certificate, such as the Subject, Issuer and Subject Alternativ=
e Name fields, as well as EV<br>
 =A0 =A0 =A0indications, MUST be ignored. In particular, TLS clients MUST N=
OT present such data to the user.<br>
<br>
 =A0 =A0 =A0[Alternatively, if we suggest to give Type 3/4 associations the=
 full CA treatment, where the<br>
 =A0 =A0 =A0complete cert chain becomes trusted, this may also be fine. But=
 we should not leave this decision<br>
 =A0 =A0 =A0to the end user!]<br>
<br>
 =A0 =A0 =A0Thanks,<br>
 =A0 =A0 =A0=A0 =A0 =A0 =A0Yaron<br>
<br>
 =A0 =A0 =A0 =A0 =A0 =A0Date: Sat, 15 Jan 2011 17:08:11 -0800<br>
 =A0 =A0 =A0 =A0 =A0 =A0From: Paul Hoffman&lt;<a href=3D"mailto:paul.hoffma=
[email-masked]" target=3D"_blank">[email-masked]</a>&gt;<br>
 =A0 =A0 =A0 =A0 =A0 =A0Subject: Re: [keyassure] draft-ietf-dane-protocol-0=
2 posted - cert<br>
 =A0 =A0 =A0 =A0 =A0 =A0=A0 =A0 =A0 =A0validation<br>
 =A0 =A0 =A0 =A0 =A0 =A0To: <a href=3D"mailto:[email-masked]" target=3D=
"_blank">[email-masked]</a><br>
 =A0 =A0 =A0 =A0 =A0 =A0Message-ID:&lt;<a href=3D"mailto:4D3244FB.9050305@v=
pnc.org" target=3D"_blank">[email-masked]</a>&gt;<br>
 =A0 =A0 =A0 =A0 =A0 =A0Content-Type: text/plain; charset=3DISO-8859-1; for=
mat=3Dflowed<br>
<br>
 =A0 =A0 =A0 =A0 =A0 =A0On 1/15/11 1:15 PM, Yaron Sheffer wrote:<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Sec. 3.1.2 of the draft singles out sel=
f-signed certs, where &quot;host<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0names&quot; (in the section title) or &=
quot;all data other than the key&quot; (first<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0paragraph) is ignored.<br>
<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0I have two issues here:<br>
<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- The first paragraph should have a nor=
mative SHOULD, instead of &quot;can&quot;.<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0The data is indeed untrustworthy and cl=
ients SHOULD ignore it unless<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0validated otherwise.<br>
<br>
<br>
 =A0 =A0 =A0 =A0 =A0 =A0This was argued about previously, I think. This sho=
uld be a new open<br>
 =A0 =A0 =A0 =A0 =A0 =A0issue because it deals with adding a 2119-level res=
triction. Also, why<br>
 =A0 =A0 =A0 =A0 =A0 =A0&quot;SHOULD&quot; and not &quot;MUST&quot;? When i=
s is OK to not ignore the data? (FWIW, I<br>
 =A0 =A0 =A0 =A0 =A0 =A0don&#39;t have strong feelings either way on any of=
 this).<br>
<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- The exact same considerations apply t=
o non-self signed certs. I don&#39;t<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0see a reason to talk specifically about=
 self-signed certs.<br>
<br>
<br>
 =A0 =A0 =A0 =A0 =A0 =A0We disagree here. The Issuer field in a CA certific=
ate cannot be ignored<br>
 =A0 =A0 =A0 =A0 =A0 =A0when doing PKIX chaining.<br>
<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Just because<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0someone presents a cert that has, say, =
Verisign as the Issuer, doesn&#39;t<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mean it is a valid Verisign certificate=
 unless validated in the<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0traditional manner.<br>
<br>
<br>
 =A0 =A0 =A0 =A0 =A0 =A0Um, exactly. But self-signed certs are not &quot;va=
lidated in the traditional<br>
 =A0 =A0 =A0 =A0 =A0 =A0manner&quot;, which is why this section exists.<br>
<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0So none of the certificate data can be =
trusted,<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0including the important Subject and Sub=
jectAltName fields. Sec. 3.1.4<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0kind of implies this fact, but the inco=
rrect differentiation between<br>
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0regular and self-signed certs remains.<=
br>
<br>
<br>
 =A0 =A0 =A0 =A0 =A0 =A0I believe there is a strong differentiation between=
 &quot;was validated&quot; and<br>
 =A0 =A0 =A0 =A0 =A0 =A0&quot;wasn&#39;t validated&quot;. If you and I are =
saying the same thing, I would love<br>
 =A0 =A0 =A0 =A0 =A0 =A0to see text to clarify what we have written.<br>
<br>
 =A0 =A0 =A0 =A0 =A0 =A0--Paul Hoffman<br>
<br>
 =A0 =A0 =A0_______________________________________________<br>
 =A0 =A0 =A0keyassure mailing list<br>
 =A0 =A0 =A0<a href=3D"mailto:[email-masked]" target=3D"_blank">keyassu=
[email-masked]</a><br>
 =A0 =A0 =A0<a href=3D"https://www.ietf.org/mailman/listinfo/keyassure" tar=
get=3D"_blank">https://www.ietf.org/mailman/listinfo/keyassure</a><br>
<br>
<br>
<br>
<br>
--<br>
Website: <a href=3D"http://hallambaker.com/" target=3D"_blank">http://halla=
mbaker.com/</a><br>
<br>
<br>
<br>
</blockquote>
</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>

--0016e64f8f4af93eab049a01989d--

Date: Sun, 16 Jan 2011 21:08:29 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] keyassure Digest, Vol 6, Issue 16

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

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

I am not sure if I agree (or disagree)

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

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

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

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

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

Paul

> On Sun, Jan 16, 2011 at 2:42 PM, Yaron Sheffer <[email-masked]> wrote:
>       Hi Paul,
>
>       For the first sentence of 3.1.2, I don't care if it's SHOULD or MUST. But it's got to be
>       normative.
>
>       Having reread 3.1.3, I am literally shocked by the way we propose to deal with certs that (1)
>       validate OK with respect to DNSSEC but (2) do not chain up to a known trust anchor. We propose to
>       leave the decision to the user, just like the bad old days of PKI!
>
>       Instead, I suggest to replace *both* 3.1.3 and 3.1.4 by the following text:
>
>       3.1.3 Non-Validated Certificates
>
>       Certificates that are correctly associated with a domain name, but which do not chain into a
>       locally stored trust anchor, are no different from self-signed certificates. Therefore, only their
>       public key can be used in conjunction with the associated domain name. Other pertinent data in the
>       certificate, such as the Subject, Issuer and Subject Alternative Name fields, as well as EV
>       indications, MUST be ignored. In particular, TLS clients MUST NOT present such data to the user.
>
>       [Alternatively, if we suggest to give Type 3/4 associations the full CA treatment, where the
>       complete cert chain becomes trusted, this may also be fine. But we should not leave this decision
>       to the end user!]
>
>       Thanks,
>              Yaron
>
>             Date: Sat, 15 Jan 2011 17:08:11 -0800
>             From: Paul Hoffman<[email-masked]>
>             Subject: Re: [keyassure] draft-ietf-dane-protocol-02 posted - cert
>                    validation
>             To: [email-masked]
>             Message-ID:<[email-masked]>
>             Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>             On 1/15/11 1:15 PM, Yaron Sheffer wrote:
>                   Sec. 3.1.2 of the draft singles out self-signed certs, where "host
>                   names" (in the section title) or "all data other than the key" (first
>                   paragraph) is ignored.
>
>                   I have two issues here:
>
>                   - The first paragraph should have a normative SHOULD, instead of "can".
>                   The data is indeed untrustworthy and clients SHOULD ignore it unless
>                   validated otherwise.
> 
>
>             This was argued about previously, I think. This should be a new open
>             issue because it deals with adding a 2119-level restriction. Also, why
>             "SHOULD" and not "MUST"? When is is OK to not ignore the data? (FWIW, I
>             don't have strong feelings either way on any of this).
>
>                   - The exact same considerations apply to non-self signed certs. I don't
>                   see a reason to talk specifically about self-signed certs.
> 
>
>             We disagree here. The Issuer field in a CA certificate cannot be ignored
>             when doing PKIX chaining.
>
>                   Just because
>                   someone presents a cert that has, say, Verisign as the Issuer, doesn't
>                   mean it is a valid Verisign certificate unless validated in the
>                   traditional manner.
> 
>
>             Um, exactly. But self-signed certs are not "validated in the traditional
>             manner", which is why this section exists.
>
>                   So none of the certificate data can be trusted,
>                   including the important Subject and SubjectAltName fields. Sec. 3.1.4
>                   kind of implies this fact, but the incorrect differentiation between
>                   regular and self-signed certs remains.
> 
>
>             I believe there is a strong differentiation between "was validated" and
>             "wasn't validated". If you and I are saying the same thing, I would love
>             to see text to clarify what we have written.
>
>             --Paul Hoffman
>
>       _______________________________________________
>       keyassure mailing list
>       [email-masked]
>       https://www.ietf.org/mailman/listinfo/keyassure
> 
> 
> 
> 
> --
> Website: http://hallambaker.com/
> 
> 
>

Date: Sun, 16 Jan 2011 17:40:51 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Jakob Schlyter <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious?

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

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

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

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

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

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

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

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

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

Working at a general level creates standards that are of higher quality ove=
rall and less likely to have the corner cases swept under the rug.<div><br>=
</div><div>I would separate out the documentation of the trust mechanism it=
self from the specific binding to TLS / HTTP and Web browsing consideration=
s. I don&#39;t propose actually writing an IPSEC or SSH binding. But we sho=
uld be pretty confident we could write one if necessary.</div>
<div><br></div><div><br></div><div><br></div><div>If the architecture is ri=
ght the distinction between the two should be very clear. If there is exces=
sive special pleading it is a sign that the architecture is wrong. Its like=
 having the warnings flag on a compiler - it helps avoid mistakes.</div>
<div><br></div><div>We have done this in SAML, Web Services and pretty much=
 every other specification of this type that I am familiar with.</div><div>=
<br><br><div class=3D"gmail_quote">On Sun, Jan 16, 2011 at 4:14 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"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;"><div class=3D"im">On 16 jan 2011, at 05.00,=
 Warren Kumari wrote:<br>
<br>
&gt; Having a document that clearly explains how something works for one si=
mple, concrete use case is (IMO) much easier to understand than a document =
that tried to be all things to all people and cover all cases.<br>
&gt; This approach should also allow us to make much faster progress, and w=
ill allow us to gain experience and will address the largest use case up fr=
ont.<br>
<br>
</div>Speaking as author of RFC 4255 (SSHFP), I agree with the above and be=
lieve that draft-ietf-dane-protocol should support TLS only.<br>
<font color=3D"#888888"><br>
 =A0 =A0 =A0 =A0jakob<br>
</font><div><div></div><div class=3D"h5"><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>

--001636af02720875b20499fe5c30--

Date: Sun, 16 Jan 2011 16:23:54 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Yaron Sheffer <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] keyassure Digest, Vol 6, Issue 16

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

Mostly agree

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

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

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

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

> Hi Paul,
>
> For the first sentence of 3.1.2, I don't care if it's SHOULD or MUST. But
> it's got to be normative.
>
> Having reread 3.1.3, I am literally shocked by the way we propose to deal
> with certs that (1) validate OK with respect to DNSSEC but (2) do not chain
> up to a known trust anchor. We propose to leave the decision to the user,
> just like the bad old days of PKI!
>
> Instead, I suggest to replace *both* 3.1.3 and 3.1.4 by the following text:
>
> 3.1.3 Non-Validated Certificates
>
> Certificates that are correctly associated with a domain name, but which do
> not chain into a locally stored trust anchor, are no different from
> self-signed certificates. Therefore, only their public key can be used in
> conjunction with the associated domain name. Other pertinent data in the
> certificate, such as the Subject, Issuer and Subject Alternative Name
> fields, as well as EV indications, MUST be ignored. In particular, TLS
> clients MUST NOT present such data to the user.
>
> [Alternatively, if we suggest to give Type 3/4 associations the full CA
> treatment, where the complete cert chain becomes trusted, this may also be
> fine. But we should not leave this decision to the end user!]
>
> Thanks,
>        Yaron
>
>  Date: Sat, 15 Jan 2011 17:08:11 -0800
>> From: Paul Hoffman<[email-masked]>
>> Subject: Re: [keyassure] draft-ietf-dane-protocol-02 posted - cert
>>        validation
>> To: [email-masked]
>> Message-ID:<[email-masked]>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> On 1/15/11 1:15 PM, Yaron Sheffer wrote:
>>
>>> Sec. 3.1.2 of the draft singles out self-signed certs, where "host
>>> names" (in the section title) or "all data other than the key" (first
>>> paragraph) is ignored.
>>>
>>> I have two issues here:
>>>
>>> - The first paragraph should have a normative SHOULD, instead of "can".
>>> The data is indeed untrustworthy and clients SHOULD ignore it unless
>>> validated otherwise.
>>>
>>
>> This was argued about previously, I think. This should be a new open
>> issue because it deals with adding a 2119-level restriction. Also, why
>> "SHOULD" and not "MUST"? When is is OK to not ignore the data? (FWIW, I
>> don't have strong feelings either way on any of this).
>>
>>  - The exact same considerations apply to non-self signed certs. I don't
>>> see a reason to talk specifically about self-signed certs.
>>>
>>
>> We disagree here. The Issuer field in a CA certificate cannot be ignored
>> when doing PKIX chaining.
>>
>>  Just because
>>> someone presents a cert that has, say, Verisign as the Issuer, doesn't
>>> mean it is a valid Verisign certificate unless validated in the
>>> traditional manner.
>>>
>>
>> Um, exactly. But self-signed certs are not "validated in the traditional
>> manner", which is why this section exists.
>>
>>  So none of the certificate data can be trusted,
>>> including the important Subject and SubjectAltName fields. Sec. 3.1.4
>>> kind of implies this fact, but the incorrect differentiation between
>>> regular and self-signed certs remains.
>>>
>>
>> I believe there is a strong differentiation between "was validated" and
>> "wasn't validated". If you and I are saying the same thing, I would love
>> to see text to clarify what we have written.
>>
>> --Paul Hoffman
>>
>>  _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

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

Mostly agree<div><br></div><div>But restrictions on the validity and/or use=
 of the certificate MUST still be observed.</div><div><br></div><div>i.e. i=
f a self-signed certificate says that the subject is Bank of Ethel then tha=
t is a positive statement and MUST be ignored.</div>
<div><br></div><div>But if the certificate says &#39;not valid after X&#39;=
 or &#39;only for protocol Y&#39; or has an unknown critical extension then=
 it MUST be rejected.<br><br></div><div><br></div><div><br><div class=3D"gm=
ail_quote">
On Sun, Jan 16, 2011 at 2:42 PM, 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 Paul,<br>
<br>
For the first sentence of 3.1.2, I don&#39;t care if it&#39;s SHOULD or MUS=
T. But it&#39;s got to be normative.<br>
<br>
Having reread 3.1.3, I am literally shocked by the way we propose to deal w=
ith certs that (1) validate OK with respect to DNSSEC but (2) do not chain =
up to a known trust anchor. We propose to leave the decision to the user, j=
ust like the bad old days of PKI!<br>

<br>
Instead, I suggest to replace *both* 3.1.3 and 3.1.4 by the following text:=
<br>
<br>
3.1.3 Non-Validated Certificates<br>
<br>
Certificates that are correctly associated with a domain name, but which do=
 not chain into a locally stored trust anchor, are no different from self-s=
igned certificates. Therefore, only their public key can be used in conjunc=
tion with the associated domain name. Other pertinent data in the certifica=
te, such as the Subject, Issuer and Subject Alternative Name fields, as wel=
l as EV indications, MUST be ignored. In particular, TLS clients MUST NOT p=
resent such data to the user.<br>

<br>
[Alternatively, if we suggest to give Type 3/4 associations the full CA tre=
atment, where the complete cert chain becomes trusted, this may also be fin=
e. But we should not leave this decision to the end user!]<br>
<br>
Thanks,<br>
 =A0 =A0 =A0 =A0Yaron<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Date: Sat, 15 Jan 2011 17:08:11 -0800<br>
From: Paul Hoffman&lt;<a href=3D"mailto:[email-masked]" target=3D"_b=
lank">[email-masked]</a>&gt;<br>
Subject: Re: [keyassure] draft-ietf-dane-protocol-02 posted - cert<br>
 =A0 =A0 =A0 =A0validation<br>
To: <a href=3D"mailto:[email-masked]" target=3D"_blank">keyassure@ietf.=
org</a><br>
Message-ID:&lt;<a href=3D"mailto:[email-masked]" target=3D"_blan=
k">[email-masked]</a>&gt;<br>
Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed<br>
<br>
On 1/15/11 1:15 PM, Yaron Sheffer wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Sec. 3.1.2 of the draft singles out self-signed certs, where &quot;host<br>
names&quot; (in the section title) or &quot;all data other than the key&quo=
t; (first<br>
paragraph) is ignored.<br>
<br>
I have two issues here:<br>
<br>
- The first paragraph should have a normative SHOULD, instead of &quot;can&=
quot;.<br>
The data is indeed untrustworthy and clients SHOULD ignore it unless<br>
validated otherwise.<br>
</blockquote>
<br>
This was argued about previously, I think. This should be a new open<br>
issue because it deals with adding a 2119-level restriction. Also, why<br>
&quot;SHOULD&quot; and not &quot;MUST&quot;? When is is OK to not ignore th=
e data? (FWIW, I<br>
don&#39;t have strong feelings either way on any of this).<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
- The exact same considerations apply to non-self signed certs. I don&#39;t=
<br>
see a reason to talk specifically about self-signed certs.<br>
</blockquote>
<br>
We disagree here. The Issuer field in a CA certificate cannot be ignored<br=
>
when doing PKIX chaining.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Just because<br>
someone presents a cert that has, say, Verisign as the Issuer, doesn&#39;t<=
br>
mean it is a valid Verisign certificate unless validated in the<br>
traditional manner.<br>
</blockquote>
<br>
Um, exactly. But self-signed certs are not &quot;validated in the tradition=
al<br>
manner&quot;, which is why this section exists.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
So none of the certificate data can be trusted,<br>
including the important Subject and SubjectAltName fields. Sec. 3.1.4<br>
kind of implies this fact, but the incorrect differentiation between<br>
regular and self-signed certs remains.<br>
</blockquote>
<br>
I believe there is a strong differentiation between &quot;was validated&quo=
t; and<br>
&quot;wasn&#39;t validated&quot;. If you and I are saying the same thing, I=
 would love<br>
to see text to clarify what we have written.<br>
<br>
--Paul Hoffman<br>
<br>
</blockquote>
_______________________________________________<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>

--0016e644d5ccda18940499fd4875--

From: Jakob Schlyter <[email-masked]>
Date: Sun, 16 Jan 2011 22:14:47 +0100
To: Warren Kumari <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious?

On 16 jan 2011, at 05.00, Warren Kumari wrote:

> Having a document that clearly explains how something works for one =
simple, concrete use case is (IMO) much easier to understand than a =
document that tried to be all things to all people and cover all cases.=20=

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

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

	jakob

Date: Sun, 16 Jan 2011 21:42:49 +0200
From: Yaron Sheffer <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] keyassure Digest, Vol 6, Issue 16

Hi Paul,

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

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

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

3.1.3 Non-Validated Certificates

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

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

Thanks,
	Yaron

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

Date: Sun, 16 Jan 2011 14:03:38 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked], Phillip Hallam-Baker <[email-masked]>
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious?

On Sun, 16 Jan 2011, Simon Josefsson wrote:

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

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

Paul

From: James Cloos <[email-masked]>
To: [email-masked]
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABHNCSVQICAgIfAhkiAAAAI1J REFUOE+lU9ESgCAIg64P1y+ngUdxhl5H8wFbbM0OmUiEhKkCYaZThXCo6KE5sCbA1DDX3genvO4d eBQgEMaM5qy6uWk4SfBYfdu9jvBN9nSVDOKRtwb+I3epboOsOX5pZbJNsBJFvmQQ05YMfieIBnYX FK2N6dOawd97r/e8RjkTLzmMsiVgrAoEugtviCM3v2WzjgAAAABJRU5ErkJggg==
Copyright: Copyright 2009 James Cloos
OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
Date: Sun, 16 Jan 2011 12:42:34 -0500
Lines: 9
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious?

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

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

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

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

From: James Cloos <[email-masked]>
To: [email-masked]
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAABHNCSVQICAgIfAhkiAAAAI1J REFUOE+lU9ESgCAIg64P1y+ngUdxhl5H8wFbbM0OmUiEhKkCYaZThXCo6KE5sCbA1DDX3genvO4d eBQgEMaM5qy6uWk4SfBYfdu9jvBN9nSVDOKRtwb+I3epboOsOX5pZbJNsBJFvmQQ05YMfieIBnYX FK2N6dOawd97r/e8RjkTLzmMsiVgrAoEugtviCM3v2WzjgAAAABJRU5ErkJggg==
Copyright: Copyright 2009 James Cloos
OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
Date: Sun, 16 Jan 2011 12:47:05 -0500
Lines: 12
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious?

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

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

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

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

Date: Sun, 16 Jan 2011 08:00:20 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] draft-ietf-dane-protocol-02 posted - RR name

On 1/16/11 2:51 AM, Yaron Sheffer wrote:
> Hi Paul,
>
> No, I am not taking any sides regarding support for protocols that are
> not mentioned in the charter (which is Issue #5). Note that IPsec itself
> is, in fact, already in the charter.
>
> Neither am I proposing to expand the scope of the current document
> (which is Issue #17). I actually prefer the current focus.
>
> I am just proposing the make the record's *name* protocol-agnostic, so
> it can be reused in the future without excuses.

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

Date: Sun, 16 Jan 2011 07:59:13 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious?

On 1/15/11 10:40 PM, Paul Wouters wrote:
> On Sat, 15 Jan 2011, Warren Kumari wrote:
>
>>> The other alternative would be to make *this* document be much more
>>> generic and able to support arbitrary key bindings.
>>
>> I am concerned that, no matter how well the document is written,
>> trying to make it sufficiently generic will end up hard to understand,
>> vague and difficult to implement from. Even getting the terminology
>> sufficiently precise for clear discussions while still being generic
>> is tricky....
>
> I think so too.
>
> SSH and IPsec already have their own RRTYPE.

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

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

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

Date: Sun, 16 Jan 2011 10:01:28 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious?

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

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

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

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

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

I think some people have their priorities wrong here.

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

On Sun, Jan 16, 2011 at 9:27 AM, Simon Josefsson <[email-masked]>wrote:

> Phillip Hallam-Baker <[email-masked]> writes:
>
> > There are actually three issues here
> >
> > 1) Should the protocol only support TLS
> > 2) Should the protocol only support TLS+HTTP
> > 3) Should the protocol only support TLS+HTTP for Web browsing.
>
> As a reminder, TLS supports more than X.509.  The current draft is hard
> wired for X.509 only.  So it is more like:
>
> 1) Should the protocol only support TLS with X.509
> 2) Should the protocol only support TLS with X.509 + HTTP
> 3) Should the protocol only support TLS with X.509 + HTTP for Web browsing.
>
> Our WG charter does not say "X.509" so I think a proposal for TLS that
> encompass other certificate formats would be useful.  I'm considering
> updating my early proposal that has this support:
>
> http://tools.ietf.org/html/draft-josefsson-keyassure-tls-00
>
> /Simon
>

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

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

People have written drafts which purport to show use of different keying mo=
des. That is not the same thing at all.<div><br></div><div>At the end of th=
e day the cert format is just a packaging issue and the only things that re=
ally matter are that it is acceptably secure and everyone does the same thi=
ng.</div>
<div><br></div><div><br></div><div>We seem to have a very peculiar set of p=
riorities here. Support for SPKI keying which nobody uses and support for P=
GP key signature formats which are not designed for directory based PKI are=
 discussed as if they were important and useful options.</div>
<div><br></div><div>Meanwhile support for widely used protocols is treated =
as if it was a somewhat eccentric idea.</div><div><br></div><div><br></div>=
<div>I think some people have their priorities wrong here.</div><div><br>
</div><div><br></div><div>There are only two key formats that are widely us=
ed: X.509 and PGP. The PGP format is expressly designed to support Web of t=
rust and so is irrelevant here because what we are doing is the exact oppos=
ite of what Phil Zimmerman proposed.</div>
<div><br></div><div><div><br><div class=3D"gmail_quote">On Sun, Jan 16, 201=
1 at 9:27 AM, Simon Josefsson <span dir=3D"ltr">&lt;<a href=3D"mailto:simon=
@josefsson.org">[email-masked]</a>&gt;</span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex;">
<div class=3D"im">Phillip Hallam-Baker &lt;<a href=3D"mailto:[email-masked]=
om">[email-masked]</a>&gt; writes:<br>
<br>
&gt; There are actually three issues here<br>
&gt;<br>
&gt; 1) Should the protocol only support TLS<br>
&gt; 2) Should the protocol only support TLS+HTTP<br>
&gt; 3) Should the protocol only support TLS+HTTP for Web browsing.<br>
<br>
</div>As a reminder, TLS supports more than X.509. =A0The current draft is =
hard<br>
wired for X.509 only. =A0So it is more like:<br>
<br>
1) Should the protocol only support TLS with X.509<br>
2) Should the protocol only support TLS with X.509 + HTTP<br>
3) Should the protocol only support TLS with X.509 + HTTP for Web browsing.=
<br>
<br>
Our WG charter does not say &quot;X.509&quot; so I think a proposal for TLS=
 that<br>
encompass other certificate formats would be useful. =A0I&#39;m considering=
<br>
updating my early proposal that has this support:<br>
<br>
<a href=3D"http://tools.ietf.org/html/draft-josefsson-keyassure-tls-00" tar=
get=3D"_blank">http://tools.ietf.org/html/draft-josefsson-keyassure-tls-00<=
/a><br>
<font color=3D"#888888"><br>
/Simon<br>
</font></blockquote></div><br><br clear=3D"all"><br>-- <br>Website: <a href=
=3D"http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div></div>

--0016368e1bf02752f10499f7f1ce--

From: Simon Josefsson <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Sun, 16 Jan 2011 15:27:05 +0100
Cc: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious?

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

> There are actually three issues here
>
> 1) Should the protocol only support TLS
> 2) Should the protocol only support TLS+HTTP
> 3) Should the protocol only support TLS+HTTP for Web browsing.

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

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

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

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

/Simon

Date: Sun, 16 Jan 2011 08:50:10 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Warren Kumari <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious?

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

There are actually three issues here

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

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

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

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

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

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

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

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

There are actually three issues here
<div><br></div><div>1) Should the protocol only support TLS</div><div>2) Sh=
ould the protocol only support TLS+HTTP</div><div>3) Should the protocol on=
ly support TLS+HTTP for Web browsing.</div><div><br></div><div>Options 1 an=
d 2 are both very broad. Only option 3 is actually narrowly focused but it =
is rather hard to separate out.</div>
<div><br></div><div><br></div><div>Currently TLS is in use to secure practi=
cally every application layer protocol - SMTP, POP, IMAP, HTTP. It is also =
used to support several thousand Web Services protocols built on HTTP. Over=
 the next few years that number of protocols will grow to tens of thousands=
.</div>
<div><br></div><div><br></div><div>Deciding only to support TLS gives the i=
llusion of focus but does not provide any focus whatsoever because we use T=
LS to secure 99% of stuff today. As a historical matter, X.509 was designed=
 long before TLS but worked fine for TLS keying because the architecture wa=
s right.</div>
<div><br></div><div>Stove pipe protocols tend to be too narrowly focused so=
 that they end up not even supporting their own needs.=A0</div><div><br></d=
iv><div>Take a look a PKIX, it did not get complex overnight. It got comple=
x because the initial design was inadequate for real-world needs and was on=
ly extended piecemeal.</div>
<div><br></div><div><br></div><div>Working out how to apply a scheme to mul=
tiple protocols is the best way to make sure that what is produced is worth=
 producing.=A0</div><div><br></div>

--0016e644d5cc2ba8180499f6f284--

Date: Sun, 16 Jan 2011 12:51:22 +0200
From: Yaron Sheffer <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] draft-ietf-dane-protocol-02 posted - RR name

Hi Paul,

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

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

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

Thanks,
	Yaron

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

Date: Sun, 16 Jan 2011 09:25:44 +0200
From: Ilari Liusvaara <[email-masked]>
To: Paul Wouters <[email-masked]>
Sender: Ilari Liusvaara <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious?

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

Agreed.

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

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

-Ilari

Date: Sun, 16 Jan 2011 01:40:45 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Warren Kumari <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious?

On Sat, 15 Jan 2011, Warren Kumari wrote:

>> The other alternative would be to make *this* document be much more generic and able to support arbitrary key bindings.
>
> I am concerned that, no matter how well the document is written, trying to make it sufficiently generic will end up hard to understand, vague and difficult to implement from. Even getting the terminology sufficiently precise for clear discussions while still being generic is tricky....

I think so too.

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

Paul

From: Warren Kumari <[email-masked]>
Date: Sat, 15 Jan 2011 23:00:40 -0500
To: Warren Kumari <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious?

On Jan 15, 2011, at 10:15 PM, Warren Kumari wrote:

> Buoyed by actual progress on getting the first issue resolved, I'm =
proposing that we jump right into... the 17th issue.
>=20
> Issue #17: Should draft-ietf-dane-protocol support TLS only or be more =
ambitious? (http://trac.tools.ietf.org/wg/dane/trac/ticket/17):
>=20
> Description:
> -------
> Please note: This is not the "what all protocols can / do we want to =
support" issue. That will be a separate (and probably lively!) =
discussion.
>=20
> The current version of draft-ietf-dane-protocol is titled "Using =
Secure DNS to Associate Certificates with Domain Names For TLS" and =
first goal / milestone is "First WG draft of standards-track protocol =
for using DNS to associate hosts with keys for TLS and DTLS".
>=20
> What I would like us to discuss is:
> Should *this* document simply specify how to support TLS and future =
protocols can be supported by saying "TLSA, but interpret field Foo to =
contain Bar" (or "Similar to TLSA, but this different RR, formatted like =
Baz"). Note that some other protocols already have similar RRtypes; for =
example SSH already has SSHFP.

<no hats>

This approach is my personal preference.
Having a document that clearly explains how something works for one =
simple, concrete use case is (IMO) much easier to understand than a =
document that tried to be all things to all people and cover all cases.=20=

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

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

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

W
</no hats>

> ------
>=20
> Getting consensus on this issue soon would be good, as it affects how =
the document is written...
>=20
> W

From: Warren Kumari <[email-masked]>
Date: Sat, 15 Jan 2011 22:15:46 -0500
To: [email-masked]
Subject: [keyassure] Issue #17 - Should draft-ietf-dane-protocol support TLS only or be more ambitious?

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

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

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

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

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

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

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

W=

Date: Sat, 15 Jan 2011 17:08:11 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] draft-ietf-dane-protocol-02 posted - cert validation

On 1/15/11 1:15 PM, Yaron Sheffer wrote:
> Sec. 3.1.2 of the draft singles out self-signed certs, where "host
> names" (in the section title) or "all data other than the key" (first
> paragraph) is ignored.
>
> I have two issues here:
>
> - The first paragraph should have a normative SHOULD, instead of "can".
> The data is indeed untrustworthy and clients SHOULD ignore it unless
> validated otherwise.

This was argued about previously, I think. This should be a new open 
issue because it deals with adding a 2119-level restriction. Also, why 
"SHOULD" and not "MUST"? When is is OK to not ignore the data? (FWIW, I 
don't have strong feelings either way on any of this).

> - The exact same considerations apply to non-self signed certs. I don't
> see a reason to talk specifically about self-signed certs.

We disagree here. The Issuer field in a CA certificate cannot be ignored 
when doing PKIX chaining.

> Just because
> someone presents a cert that has, say, Verisign as the Issuer, doesn't
> mean it is a valid Verisign certificate unless validated in the
> traditional manner.

Um, exactly. But self-signed certs are not "validated in the traditional 
manner", which is why this section exists.

> So none of the certificate data can be trusted,
> including the important Subject and SubjectAltName fields. Sec. 3.1.4
> kind of implies this fact, but the incorrect differentiation between
> regular and self-signed certs remains.

I believe there is a strong differentiation between "was validated" and 
"wasn't validated". If you and I are saying the same thing, I would love 
to see text to clarify what we have written.

--Paul Hoffman

Date: Sat, 15 Jan 2011 17:00:44 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] draft-ietf-dane-protocol-02 posted

On 1/15/11 1:00 PM, Yaron Sheffer wrote:

> I have an issue with the name of the DNS record type. "TLSA" implies one
> specific protocol. The working group's scope includes additional ones,
> and those and possibly others will want to use the same record type,
> hopefully.

This would be issue #5 on our open issues list (reminder: 
<http://trac.tools.ietf.org/wg/dane/trac/report/1>). Are you trying to 
get the chairs to start this discussion sooner than the others they 
might want? :-) [1]

--Paul Hoffman

[1] The smiley there is because Yaron is co-chair of the IPsecME WG with 
me and we tend to run our group off the issue tracker.

Date: Sat, 15 Jan 2011 23:15:42 +0200
From: Yaron Sheffer <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] draft-ietf-dane-protocol-02 posted - cert validation

Hi,

Sec. 3.1.2 of the draft singles out self-signed certs, where "host 
names" (in the section title) or "all data other than the key" (first 
paragraph) is ignored.

I have two issues here:

- The first paragraph should have a normative SHOULD, instead of "can". 
The data is indeed untrustworthy and clients SHOULD ignore it unless 
validated otherwise.

- The exact same considerations apply to non-self signed certs. I don't 
see a reason to talk specifically about self-signed certs. Just because 
someone presents a cert that has, say, Verisign as the Issuer, doesn't 
mean it is a valid Verisign certificate unless validated in the 
traditional manner. So none of the certificate data can be trusted, 
including the important Subject and SubjectAltName fields. Sec. 3.1.4 
kind of implies this fact, but the incorrect differentiation between 
regular and self-signed certs remains.

Thanks,
	Yaron

Date: Sat, 15 Jan 2011 08:21:17 -0800
> From: Paul Hoffman<[email-masked]>
> Subject: [keyassure] draft-ietf-dane-protocol-02 posted
> To: "[email-masked]"<[email-masked]>
> Message-ID:<[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> The main change is the definition of the wire format to match the
> consensus call made yesterday closing issue #4. Jakob and I intend to
> keep pumping out drafts as issues are closed. We probably won't do one
> draft per consensus call, but hope to do one when each "big" issue is
> closed.
>
> --Paul Hoffman

Date: Sat, 15 Jan 2011 23:00:38 +0200
From: Yaron Sheffer <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] draft-ietf-dane-protocol-02 posted

Hi,

I have an issue with the name of the DNS record type. "TLSA" implies one 
specific protocol. The working group's scope includes additional ones, 
and those and possibly others will want to use the same record type, 
hopefully. How about adopting a protocol-agnostic name? To throw 
something out, I suggest NEE: Named End Entity.

Thanks,
	Yaron

Date: Sat, 15 Jan 2011 08:21:17 -0800
> From: Paul Hoffman<[email-masked]>
> Subject: [keyassure] draft-ietf-dane-protocol-02 posted
> To: "[email-masked]"<[email-masked]>
> Message-ID:<[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> The main change is the definition of the wire format to match the
> consensus call made yesterday closing issue #4. Jakob and I intend to
> keep pumping out drafts as issues are closed. We probably won't do one
> draft per consensus call, but hope to do one when each "big" issue is
> closed.
>
> --Paul Hoffman

Date: Sat, 15 Jan 2011 08:21:17 -0800
From: Paul Hoffman <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [keyassure] draft-ietf-dane-protocol-02 posted

The main change is the definition of the wire format to match the 
consensus call made yesterday closing issue #4. Jakob and I intend to 
keep pumping out drafts as issues are closed. We probably won't do one 
draft per consensus call, but hope to do one when each "big" issue is 
closed.

--Paul Hoffman

From: [email-masked]
To: [email-masked]
Date: Sat, 15 Jan 2011 08:00:02 -0800
Cc: [email-masked]
Subject: [keyassure] I-D Action:draft-ietf-dane-protocol-02.txt

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF.

	Title           : Using Secure DNS to Associate Certificates with Domain Names For TLS
	Author(s)       : P. Hoffman, J. Schlyter
	Filename        : draft-ietf-dane-protocol-02.txt
	Pages           : 12
	Date            : 2011-01-15

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body; name="draft-ietf-dane-protocol-02.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--

From: Warren Kumari <[email-masked]>
To: Ilari Liusvaara <[email-masked]>
Date: Fri, 14 Jan 2011 17:49:09 -0500
Cc: Jim Schaad <[email-masked]>, [email-masked], 'Paul Hoffman' <[email-masked]>
Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types."

Ok, after discussions with my cochair, we are calling consensus.

WG consensus is that we will ask the IANA to create and maintain a  
(one octet) registry to identify the hash and cert types.
This does still allow for the registration and use of things like ODI  
(and parameterized hash functions, and other cool things) by allowing  
them to
specify how the "body" ("bytes containing the certificate or the hash  
of the associated certificate") is interpreted.

I would like to thank everyone who contributed to getting consensus on  
this issue-- don't for a minute think that you are off the hook now  
though, there are many more issues to work through :-P

W
On Jan 14, 2011, at 2:02 AM, Ilari Liusvaara wrote:

> On Thu, Jan 13, 2011 at 09:22:06PM -0800, Jim Schaad wrote:
>> Is there any reason to worry about any of the parameterized hash  
>> functions
>> such as the randomized hash function proposal presented at the SAAG  
>> meeting
>> in SFO?
>
> I think those can be handled by defining the "hashes" to include the
> parameters in hash-function specific way.
>
> -Ilari
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

--
"Have you got any previous convictions?"

"Well, I dunno... I suppose I used to believe very firmly that a penny  
saved is a penny earned--"
-- Terry Pratchett

Date: Fri, 14 Jan 2011 07:19:23 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types."

On 1/13/11 11:02 PM, Ilari Liusvaara wrote:
> On Thu, Jan 13, 2011 at 09:22:06PM -0800, Jim Schaad wrote:
>> Is there any reason to worry about any of the parameterized hash functions
>> such as the randomized hash function proposal presented at the SAAG meeting
>> in SFO?
>
> I think those can be handled by defining the "hashes" to include the
> parameters in hash-function specific way.

+1. Any parameterized hash function needs to be able to say where those 
parameters go in the the outside protocol. For example, they could be 
stuffed at the beginning or end of the hash value here.

Date: Fri, 14 Jan 2011 09:02:51 +0200
From: Ilari Liusvaara <[email-masked]>
To: Jim Schaad <[email-masked]>
Sender: Ilari Liusvaara <[email-masked]>
Cc: [email-masked], 'Paul Hoffman' <[email-masked]>
Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types."

On Thu, Jan 13, 2011 at 09:22:06PM -0800, Jim Schaad wrote:
> Is there any reason to worry about any of the parameterized hash functions
> such as the randomized hash function proposal presented at the SAAG meeting
> in SFO?

I think those can be handled by defining the "hashes" to include the
parameters in hash-function specific way.

-Ilari

From: "Jim Schaad" <[email-masked]>
To: "'Paul Hoffman'" <[email-masked]>, <[email-masked]>
Date: Thu, 13 Jan 2011 21:22:06 -0800
Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types."

Is there any reason to worry about any of the parameterized hash functions
such as the randomized hash function proposal presented at the SAAG meeting
in SFO?

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Paul Hoffman
> Sent: Saturday, January 08, 2011 11:13 AM
> To: [email-masked]
> Subject: Re: [keyassure] Starting to work through the issues: Issue #4 --
> "Identification of hash and cert types."
> 
> On 1/8/11 11:04 AM, Warren Kumari wrote:
> > Ok, so I'm proposing a compromise here as a third option. As this is a
> > compromise, I'm assuming no-one will love it, but maybe folk will be
> > willing to accept it...
> 
> If that's the way you think the consensus is going, that's fine. I didn't
see it
> going that way. Phill had one proposal with (possibly one) person behind
it. I
> had another with a small handful behind it. Others had not weighed in yet.
> 
> Of the now three proposals for the format, I still feel that "a two-octet
number"
> is better than ODI or a mixture of the two, FWIW.
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

From: Nicholas Weaver <[email-masked]>
Date: Wed, 12 Jan 2011 09:04:40 -0800
To: Paul Wouters <[email-masked]>
Cc: Dan Kaminsky <[email-masked]>, Nicholas Weaver <[email-masked]>, [email-masked]
Subject: Re: [keyassure] Phreeload, Dan Kaminsky's prototype client

On Jan 12, 2011, at 8:28 AM, Paul Wouters wrote:
>> Since systems are often, by default, configured to use (and ONLY know =
about) the NAT's DNS gateway, doing just about anything with DNSSEC to =
the client means that the stub resolver MUST be willing to bypass the =
recursive resolver infrastructure completely, and even then, be prepared =
for failures, including failures of new RTYPES to work when old RTYPES =
work successfully.
>=20
> How much of those ENDS0 clients allow TCP? Because if not, then your =
DNSSEC limit is
> already at 90% without even considering new RRTYPE's, and I'd think =
that there is a large
> overlap in systems not able to do EDNS0/TCP and systems not able to do =
new RRTYPEs.

Its pretty good.  DNS over TCP is much MUCH less mangled than DNS over =
UDP.=20

> Also, if you are asking TLSA/HASTLS/TXT records, you *are* an endpoint =
either doing DNSSEC
> yourself, or you are using a DNSSEC-capable resolver. In neither case =
are you using a bad
> NAT router DNS stub forwarder as listed above in the list of broken =
stuff out there.

The model of doing DNSSEC yourself [1] requires either being able to =
query the appropriate records from the configured recursive resolver or =
bypassing it entirely.  This shows that the model of 'only get from the =
recursive resolver', as the recursive resolver IS the NAT proxy in many =
many cases, doesn't work, you MUST be prepared to bypass it.

Oh, and the NAT can only handle an unknown RTYPE=3D1169 [2] in 91% of =
the cases, and can handle either a TXT record OR an unknown RTYPE in 92% =
of the cases, so unknown RTYPES really aren't that much worse than TXT =
records (its highly coupled between the two) from the NAT viewpoint.

And its been pointed out that, oops, you need to look at correlation on =
the direct case as well:  98.2% were able to get a TXT or Unknown rtype =
on a direct connection, compared with 98.1% for TXT only and 97.0% for =
unknown only (and this unknown IS a meta type, so if anything will get =
shot down, it will).

So in conclusion, I was wrong, it actually is a myth that new RTYPES =
perform significantly worse than TXT records:  So don't be afraid to =
design new RTYPEs instead of shoving it into a TXT record: TXT records =
don't work better enough for this to be worth doing.=20

>=20
> Paul
> Paul

[1] ObIMO, the only place that makes sense: the recursive resolver is =
PROVED untrustworthy, and doing validation on the recursive resolver =
provides effectively no meaningful increase in security while creating a =
huge hit on reliability)=20

[2] There was a bug in this test that before December 5th, would have =
the test try 169 rather than 1169.

Date: Wed, 12 Jan 2011 11:28:57 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Nicholas Weaver <[email-masked]>,  Dan Kaminsky <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Phreeload, Dan Kaminsky's prototype client

On Wed, 12 Jan 2011, Nicholas Weaver wrote:

> Date: Wed, 12 Jan 2011 08:09:54 -0800
> From: Nicholas Weaver <[email-masked]>
> Cc: [email-masked]
> To: Andrew Sullivan <[email-masked]>
> Subject: Re: [keyassure] Phreeload, Dan Kaminsky's prototype client
> 
>
> On Jan 12, 2011, at 7:32 AM, Andrew Sullivan wrote:
>> What bothers me about this is that anything that can do DNSSEC
>> _anyway_ can already cope with unknown RRTYPEs.  Moreover, anyone who
>> is interested in this right now is obviously going to be willing to
>> keep their system up to date too.  The difficulty of dealing with
>> RRTYPE numbers one doesn't know is a zombie fact: something that used
>> to be true but now will not die.  I don't expect everyone to
>> understand this, but I do expect people who are promoting DNSSEC to do
>> so.
>
> Not necessarily.  Even directly over the network (so direct client to server) you see a greater problem requesting an unknown RTYPE rather than a TXT record, and you see problems fetching records with EDNS0 enabled once you hit >512B responses.
>
> Success rate in Netalyzr
> EDNS0			98.5%
> EDNS0 1400B response	95.8%
> (old test, so always run)
>
> TXT			98.1%
> RTYPE=169		97.0%
> (newer test)
>
> The situation is MUCH MUCH MUCH worse when you are talking about probing the NAT's DNS gateway:
> EDNS0			90%
> TXT			92%
> AAAA			95%
> (the unknown rtype test was bugged, so its not considered here).
>
> Since systems are often, by default, configured to use (and ONLY know about) the NAT's DNS gateway, doing just about anything with DNSSEC to the client means that the stub resolver MUST be willing to bypass the recursive resolver infrastructure completely, and even then, be prepared for failures, including failures of new RTYPES to work when old RTYPES work successfully.

How much of those ENDS0 clients allow TCP? Because if not, then your DNSSEC limit is
already at 90% without even considering new RRTYPE's, and I'd think that there is a large
overlap in systems not able to do EDNS0/TCP and systems not able to do new RRTYPEs.

Also, if you are asking TLSA/HASTLS/TXT records, you *are* an endpoint either doing DNSSEC
yourself, or you are using a DNSSEC-capable resolver. In neither case are you using a bad
NAT router DNS stub forwarder as listed above in the list of broken stuff out there.

Paul
Paul

Date: Wed, 12 Jan 2011 10:15:52 -0600 (GMT-06:00)
From: "Jeffrey A. Williams" <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Phreeload, Dan Kaminsky's prototype client
Reply-To: "Jeffrey A. Williams" <[email-masked]>

Andrew and all,

  Isn't that Phreebird instead of Phreeload?
See: http://www.darkreading.com/authentication/167901072/security/application-security/228200646/index.html

Otherwise I agree.  >:)

-----Original Message-----
>From: Andrew Sullivan <[email-masked]>
>Sent: Jan 12, 2011 9:32 AM
>To: [email-masked]
>Subject: Re: [keyassure] Phreeload, Dan Kaminsky's prototype client
>
>On Tue, Jan 11, 2011 at 10:12:50PM -0500, Paul Wouters wrote:
>
>> He is also aware of the TLS/HASTLA drafts. I talked to him two weeks ago
>> about this. I also asked him for a somewhat more formal specification of
>> his TXT records, though I urged him to be part of the IETF process in
>> getting the right new RRTYPE. His fears are mostly based on old software
>> seeing and having to configure decimal numbers for new RRTYPEs.
>
>What bothers me about this is that anything that can do DNSSEC
>_anyway_ can already cope with unknown RRTYPEs.  Moreover, anyone who
>is interested in this right now is obviously going to be willing to
>keep their system up to date too.  The difficulty of dealing with
>RRTYPE numbers one doesn't know is a zombie fact: something that used
>to be true but now will not die.  I don't expect everyone to
>understand this, but I do expect people who are promoting DNSSEC to do
>so.
>
>A
>
>-- 
>Andrew Sullivan
>[email-masked]
>Shinkuro, Inc.
>_______________________________________________
>keyassure mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyassure

Kindest Regards,

Jeffrey A. Williams
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
IT/network security Eng. SR. Eng. Network data security,
IT/information and web security.
ABA member in good standing member ID 01257402 
E-Mail [email-masked]
Phone: 214-244-4827

From: Nicholas Weaver <[email-masked]>
Date: Wed, 12 Jan 2011 08:09:54 -0800
To: Andrew Sullivan <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Phreeload, Dan Kaminsky's prototype client

On Jan 12, 2011, at 7:32 AM, Andrew Sullivan wrote:
> What bothers me about this is that anything that can do DNSSEC
> _anyway_ can already cope with unknown RRTYPEs.  Moreover, anyone who
> is interested in this right now is obviously going to be willing to
> keep their system up to date too.  The difficulty of dealing with
> RRTYPE numbers one doesn't know is a zombie fact: something that used
> to be true but now will not die.  I don't expect everyone to
> understand this, but I do expect people who are promoting DNSSEC to do
> so.

Not necessarily.  Even directly over the network (so direct client to =
server) you see a greater problem requesting an unknown RTYPE rather =
than a TXT record, and you see problems fetching records with EDNS0 =
enabled once you hit >512B responses.

Success rate in Netalyzr
EDNS0			98.5%
EDNS0 1400B response	95.8%
(old test, so always run)

TXT			98.1%
RTYPE=3D169		97.0%
(newer test)

The situation is MUCH MUCH MUCH worse when you are talking about probing =
the NAT's DNS gateway:
EDNS0			90%
TXT			92%
AAAA			95%
(the unknown rtype test was bugged, so its not considered here).

Since systems are often, by default, configured to use (and ONLY know =
about) the NAT's DNS gateway, doing just about anything with DNSSEC to =
the client means that the stub resolver MUST be willing to bypass the =
recursive resolver infrastructure completely, and even then, be prepared =
for failures, including failures of new RTYPES to work when old RTYPES =
work successfully.

Date: Wed, 12 Jan 2011 10:32:33 -0500
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Phreeload, Dan Kaminsky's prototype client

On Tue, Jan 11, 2011 at 10:12:50PM -0500, Paul Wouters wrote:

> He is also aware of the TLS/HASTLA drafts. I talked to him two weeks ago
> about this. I also asked him for a somewhat more formal specification of
> his TXT records, though I urged him to be part of the IETF process in
> getting the right new RRTYPE. His fears are mostly based on old software
> seeing and having to configure decimal numbers for new RRTYPEs.

What bothers me about this is that anything that can do DNSSEC
_anyway_ can already cope with unknown RRTYPEs.  Moreover, anyone who
is interested in this right now is obviously going to be willing to
keep their system up to date too.  The difficulty of dealing with
RRTYPE numbers one doesn't know is a zombie fact: something that used
to be true but now will not die.  I don't expect everyone to
understand this, but I do expect people who are promoting DNSSEC to do
so.

A

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

Date: Wed, 12 Jan 2011 09:21:46 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Ilari Liusvaara <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] Starting to work through the issues: Issue #4 --

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

I am pretty sure that the X.500 OID and the RSADSI OID are actually for
different packaging formats.

When the X.500 directory was specified the OID did not specify the PKCS#1
bit packaging. That was specified later when Dorothy Denning pointed out
that there are security implications to the packaging format.

These should have different identifiers since they are actually different
algorithms and cannot be substituted. Later on Rogaway and Bellare came out
with important work.

RSADSI have actually assigned 6 different code points for different versions
of RSA over the years. And the differences actually matter quite a bit.

I cannot understand what you would need that 64K array for either

Crypto APIs already have code for managing OIDs. You are really not helping
anyone here. All you are doing is ensuring that the application has to be
revised to use a new algorithm rather than allowing the crypto library to
announce that it is available.

What I care about here is that people can take an ODI from another context
and cut and paste it into this use without it causing problems.

That will work perfectly provided I have the code point 0x30 or 0x30 0x12
reserved for ODI.

If people want to have additional codes for shortcuts for the mandatory
algorithms then I really don't have a problem with that. If all we are going
to do is to track the mandatory algorithms with the registry then a single
byte code will be adequate. If we do run out then people will have to use
the ODI scheme for mandatory algs as well.

On Wed, Jan 12, 2011 at 12:01 AM, Ilari Liusvaara <
[email-masked]> wrote:

> On Wed, Jan 12, 2011 at 03:29:57AM +0100, Martin Rex wrote:
> > Paul Hoffman wrote:
> > >
> >
> > My preference would also be a fixed size integer.
>
> Same (1 or 2 octets).
>
> The reason for this is that with 2 octets, one gets 65536 entry array
> if one lays it out in full. Too large for embedded code, but any general
> purpose computer has an OS capable of demand paging. And in environment
> like that, the resources used by full table are penuts (and it is very
> easy to program).
>
> > Is there a problem for a registry to contain more than a
> > primitive mapping 2-tuple (IntegerValue,AlgorithmName) and rather
> > something like (IntegerValue,AlgorithmName,StandardizationLevel)
> > with StandardizationLevel values such as
> > { required, recommended, optional, experimental, discouraged }
>
> Aren't registeries usually like that?
>
> > The problem with ASN.1 OIDs is that they wasteful (in terms of code,
> storage
> > network bandwidth, cpu cycles), variable-sized blobs and therefore a
> royal
> > PITA to use in software.
> >
> > I strongly prefer
> >
> >    switch(algorithm_cp) {
> >       case A: /* code for A */
> >               break;
> >       case B: /* code for B */
> >               break;
> >       case C: /* code for C */
> >               break;
> >       default: /* produce some useful error msg about unsupported alg */
> >               break;
> >    }
>
> Or even:
>
> #define MAXHASHOUTPUT 256
>
> struct hash_algo* dane_hashes[65536];
>
> int h;
> struct hash_algo* H;
> unsigned char hashbuffer[MAXHASHOUTPUT];
>
> h = p[2] * 256 + p[3];
> H = dane_hashes[h];
> if(!H)
>        return -1;
>
> H->hash(hashbuffer, data, datalen);
> return memcmp(hashbuffer, p + 4, H->hashlen) ? 0 : 1;
>
>
> > ASN.1 OIDs in PKIX are a pain, and they're ambiguous.
> >
> > e.g. for RSA there seem to be two(!) OIDs in use in X.509,
> > something which is not going to happen with a single registry:
> >
> >     2.5.8.1.1
> >     1.2.840.113549.1.1.1
>
> What, only two? :-)
>
> Yeah. Aliases. Brings nothing useful... Only interop problems.
>
> > Finding out the meaning of an OID you do _not_ happen to know
> > is far from trivial, something that will not happen with a registry.
> >
> > The difficulty with OIDs (or other complex variable sized objects)
> > is not in sending/emitting them, but in receiving/parsing them.
> > The code to produce a meaningful error message for an unrecognized
> > value is trivial for a scalar integer value and complex for an OID
> > (to produce an error message that can be copy&pasted into google).
>
> Oh, and don't forget the NULL vs. empty parameters problem. Wonder
> how much code gets that wrong... Probably LOTS.
>
>
> -Ilari
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

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

I am pretty sure that the X.500 OID and the RSADSI OID are actually for dif=
ferent packaging formats.<div><br></div><div>When the X.500 directory was s=
pecified the OID did not specify the PKCS#1 bit packaging. That was specifi=
ed later when Dorothy Denning pointed out that there are security implicati=
ons to the packaging format.=A0</div>
<div><br></div><div>These should have different identifiers since they are =
actually different algorithms and cannot be substituted. Later on Rogaway a=
nd Bellare came out with important work.</div><div><br></div><div><br></div=
>
<div>RSADSI have actually assigned 6 different code points for different ve=
rsions of RSA over the years. And the differences actually matter quite a b=
it.</div><div><br></div><div><br></div><div>I cannot understand what you wo=
uld need that 64K array for either</div>
<div><br></div><div>Crypto APIs already have code for managing OIDs. You ar=
e really not helping anyone here. All you are doing is ensuring that the ap=
plication has to be revised to use a new algorithm rather than allowing the=
 crypto library to announce that it is available.</div>
<div><br></div><div><br></div><div>What I care about here is that people ca=
n take an ODI from another context and cut and paste it into this use witho=
ut it causing problems.</div><div><br></div><div>That will work perfectly p=
rovided I have the code point 0x30 or 0x30 0x12 reserved for ODI.</div>
<div><br></div><div>If people want to have additional codes for shortcuts f=
or the mandatory algorithms then I really don&#39;t have a problem with tha=
t. If all we are going to do is to track the mandatory algorithms with the =
registry then a single byte code will be adequate. If we do run out then pe=
ople will have to use the ODI scheme for mandatory algs as well.</div>
<div><br><br></div><div><br></div><div><br><div class=3D"gmail_quote">On We=
d, Jan 12, 2011 at 12:01 AM, Ilari Liusvaara <span dir=3D"ltr">&lt;<a href=
=3D"mailto:[email-masked]">[email-masked]</a>&gt;=
</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;"><div class=3D"im">On Wed, Jan 12, 2011 at 0=
3:29:57AM +0100, Martin Rex wrote:<br>
&gt; Paul Hoffman wrote:<br>
&gt; &gt;<br>
&gt;<br>
&gt; My preference would also be a fixed size integer.<br>
<br>
</div>Same (1 or 2 octets).<br>
<br>
The reason for this is that with 2 octets, one gets 65536 entry array<br>
if one lays it out in full. Too large for embedded code, but any general<br=
>
purpose computer has an OS capable of demand paging. And in environment<br>
like that, the resources used by full table are penuts (and it is very<br>
easy to program).<br>
<div class=3D"im"><br>
&gt; Is there a problem for a registry to contain more than a<br>
&gt; primitive mapping 2-tuple (IntegerValue,AlgorithmName) and rather<br>
&gt; something like (IntegerValue,AlgorithmName,StandardizationLevel)<br>
&gt; with StandardizationLevel values such as<br>
&gt; { required, recommended, optional, experimental, discouraged }<br>
<br>
</div>Aren&#39;t registeries usually like that?<br>
<div class=3D"im"><br>
&gt; The problem with ASN.1 OIDs is that they wasteful (in terms of code, s=
torage<br>
&gt; network bandwidth, cpu cycles), variable-sized blobs and therefore a r=
oyal<br>
&gt; PITA to use in software.<br>
&gt;<br>
&gt; I strongly prefer<br>
&gt;<br>
&gt; =A0 =A0switch(algorithm_cp) {<br>
&gt; =A0 =A0 =A0 case A: /* code for A */<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 break;<br>
&gt; =A0 =A0 =A0 case B: /* code for B */<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 break;<br>
&gt; =A0 =A0 =A0 case C: /* code for C */<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 break;<br>
&gt; =A0 =A0 =A0 default: /* produce some useful error msg about unsupporte=
d alg */<br>
&gt; =A0 =A0 =A0 =A0 =A0 =A0 =A0 break;<br>
&gt; =A0 =A0}<br>
<br>
</div>Or even:<br>
<br>
#define MAXHASHOUTPUT 256<br>
<br>
struct hash_algo* dane_hashes[65536];<br>
<br>
int h;<br>
struct hash_algo* H;<br>
unsigned char hashbuffer[MAXHASHOUTPUT];<br>
<br>
h =3D p[2] * 256 + p[3];<br>
H =3D dane_hashes[h];<br>
if(!H)<br>
 =A0 =A0 =A0 =A0return -1;<br>
<br>
H-&gt;hash(hashbuffer, data, datalen);<br>
return memcmp(hashbuffer, p + 4, H-&gt;hashlen) ? 0 : 1;<br>
<div class=3D"im"><br>
<br>
&gt; ASN.1 OIDs in PKIX are a pain, and they&#39;re ambiguous.<br>
&gt;<br>
&gt; e.g. for RSA there seem to be two(!) OIDs in use in X.509,<br>
&gt; something which is not going to happen with a single registry:<br>
&gt;<br>
&gt; =A0 =A0 2.5.8.1.1<br>
&gt; =A0 =A0 1.2.840.113549.1.1.1<br>
<br>
</div>What, only two? :-)<br>
<br>
Yeah. Aliases. Brings nothing useful... Only interop problems.<br>
<div class=3D"im"><br>
&gt; Finding out the meaning of an OID you do _not_ happen to know<br>
&gt; is far from trivial, something that will not happen with a registry.<b=
r>
&gt;<br>
&gt; The difficulty with OIDs (or other complex variable sized objects)<br>
&gt; is not in sending/emitting them, but in receiving/parsing them.<br>
&gt; The code to produce a meaningful error message for an unrecognized<br>
&gt; value is trivial for a scalar integer value and complex for an OID<br>
&gt; (to produce an error message that can be copy&amp;pasted into google).=
<br>
<br>
</div>Oh, and don&#39;t forget the NULL vs. empty parameters problem. Wonde=
r<br>
how much code gets that wrong... Probably LOTS.<br>
<font color=3D"#888888"><br>
<br>
-Ilari<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>

--0016e64f8f4ac94c140499a6ebd6--

Date: Wed, 12 Jan 2011 07:01:31 +0200
From: Ilari Liusvaara <[email-masked]>
To: Martin Rex <[email-masked]>
Sender: Ilari Liusvaara <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] Starting to work through the issues: Issue #4 --

On Wed, Jan 12, 2011 at 03:29:57AM +0100, Martin Rex wrote:
> Paul Hoffman wrote:
> > 
> 
> My preference would also be a fixed size integer.

Same (1 or 2 octets). 

The reason for this is that with 2 octets, one gets 65536 entry array
if one lays it out in full. Too large for embedded code, but any general
purpose computer has an OS capable of demand paging. And in environment
like that, the resources used by full table are penuts (and it is very
easy to program).

> Is there a problem for a registry to contain more than a
> primitive mapping 2-tuple (IntegerValue,AlgorithmName) and rather
> something like (IntegerValue,AlgorithmName,StandardizationLevel)
> with StandardizationLevel values such as
> { required, recommended, optional, experimental, discouraged }

Aren't registeries usually like that?

> The problem with ASN.1 OIDs is that they wasteful (in terms of code, storage
> network bandwidth, cpu cycles), variable-sized blobs and therefore a royal
> PITA to use in software.
> 
> I strongly prefer
> 
>    switch(algorithm_cp) {
>       case A: /* code for A */
>               break;
>       case B: /* code for B */
>               break;
>       case C: /* code for C */
>               break;
>       default: /* produce some useful error msg about unsupported alg */
>               break;
>    }
 
Or even:

#define MAXHASHOUTPUT 256

struct hash_algo* dane_hashes[65536];

int h;
struct hash_algo* H;
unsigned char hashbuffer[MAXHASHOUTPUT];

h = p[2] * 256 + p[3];
H = dane_hashes[h];
if(!H)
	return -1;

H->hash(hashbuffer, data, datalen);
return memcmp(hashbuffer, p + 4, H->hashlen) ? 0 : 1;

> ASN.1 OIDs in PKIX are a pain, and they're ambiguous.
> 
> e.g. for RSA there seem to be two(!) OIDs in use in X.509,
> something which is not going to happen with a single registry:
> 
>     2.5.8.1.1
>     1.2.840.113549.1.1.1

What, only two? :-)

Yeah. Aliases. Brings nothing useful... Only interop problems.

> Finding out the meaning of an OID you do _not_ happen to know
> is far from trivial, something that will not happen with a registry.
> 
> The difficulty with OIDs (or other complex variable sized objects)
> is not in sending/emitting them, but in receiving/parsing them.
> The code to produce a meaningful error message for an unrecognized
> value is trivial for a scalar integer value and complex for an OID
> (to produce an error message that can be copy&pasted into google).

Oh, and don't forget the NULL vs. empty parameters problem. Wonder
how much code gets that wrong... Probably LOTS.

-Ilari

Date: Tue, 11 Jan 2011 22:12:50 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Matt McCutchen <[email-masked]>
Cc: keyassure <[email-masked]>
Subject: Re: [keyassure] Phreeload, Dan Kaminsky's prototype client

On Tue, 11 Jan 2011, Matt McCutchen wrote:

> I thought I would mention, for those not already aware, that Dan
> Kaminsky has a prototype client for a DANE-like system; he just picked a
> record format.  The client is called Phreeload, part of the Phreebird
> Suite (http://dankaminsky.com/phreebird/).  I have been playing with it
> and have added the necessary record at mattmccutchen.net .  It should be
> pretty easy to modify Phreeload to understand whatever record format we
> decide on.

He is also aware of the TLS/HASTLA drafts. I talked to him two weeks ago
about this. I also asked him for a somewhat more formal specification of
his TXT records, though I urged him to be part of the IETF process in
getting the right new RRTYPE. His fears are mostly based on old software
seeing and having to configure decimal numbers for new RRTYPEs.

Paul

From: Matt McCutchen <[email-masked]>
To: keyassure <[email-masked]>
Date: Tue, 11 Jan 2011 21:51:00 -0500
Subject: [keyassure] Phreeload, Dan Kaminsky's prototype client

I thought I would mention, for those not already aware, that Dan
Kaminsky has a prototype client for a DANE-like system; he just picked a
record format.  The client is called Phreeload, part of the Phreebird
Suite (http://dankaminsky.com/phreebird/).  I have been playing with it
and have added the necessary record at mattmccutchen.net .  It should be
pretty easy to modify Phreeload to understand whatever record format we
decide on.

-- 
Matt

From: Martin Rex <[email-masked]>
To: [email-masked] (Paul Hoffman)
Date: Wed, 12 Jan 2011 03:29:57 +0100 (MET)
Cc: [email-masked]
Subject: Re: [keyassure] Starting to work through the issues: Issue #4 --
Reply-To: [email-masked]

Paul Hoffman wrote:
> 
> On 1/7/11 3:12 PM, Warren Kumari wrote:
> > 
> > If possible I'd like us to try and separate the discussions of "Who gets
> > / how to get an identifier for an algorithm" from the question of how we
> > actually identify these -- while I realize that there are
> > interdependencies in the two issues and they are not fully separable,
> > I'd appreciate it if we can try and separate them as much as possible so
> > that it is easier to call consensus....
> 
> Just to be clear, my preferences are:
> 
> - Somewhat liberal policy for assigning: "RFC published", not "IETF 
> consensus" or "expert review"
> 
> - two-byte integers for identifying, with 1000 reserved for private use

My preference would also be a fixed size integer.

Is there a problem for a registry to contain more than a
primitive mapping 2-tuple (IntegerValue,AlgorithmName) and rather
something like (IntegerValue,AlgorithmName,StandardizationLevel)
with StandardizationLevel values such as
{ required, recommended, optional, experimental, discouraged }

The problem with ASN.1 OIDs is that they wasteful (in terms of code, storage
network bandwidth, cpu cycles), variable-sized blobs and therefore a royal
PITA to use in software.

I strongly prefer

   switch(algorithm_cp) {
      case A: /* code for A */
              break;
      case B: /* code for B */
              break;
      case C: /* code for C */
              break;
      default: /* produce some useful error msg about unsupported alg */
              break;
   }

to 
   if ( 0==compare_OID(parsed_oid,A_oid) ) {
      /* code for A */
   } else if ( 0==compare_OID(parsed_oid,B_oid) ) {
      /* code for B */
   } else if ( 0==compare_OID(parsed_oid,C_oid) ) {
      /* code for C */
   } else {
      /* produce some useful error msg about unsupported alg */
   }

ASN.1 OIDs in PKIX are a pain, and they're ambiguous.

e.g. for RSA there seem to be two(!) OIDs in use in X.509,
something which is not going to happen with a single registry:

    2.5.8.1.1
    1.2.840.113549.1.1.1

Finding out the meaning of an OID you do _not_ happen to know
is far from trivial, something that will not happen with a registry.

The difficulty with OIDs (or other complex variable sized objects)
is not in sending/emitting them, but in receiving/parsing them.
The code to produce a meaningful error message for an unrecognized
value is trivial for a scalar integer value and complex for an OID
(to produce an error message that can be copy&pasted into google).

Phillip Hallam-Baker wrote:
>
> Actually PKCS#1 which is the RSA spec also uses ASN.1 as the prep for the
> packaging format.
>
> So it really is unavoidable.

This information appears outdated.  The PKCS#1 v1.5 signature scheme
was actually tightened up in PKCS#1 v2.1 to completely obviate
the royal PITA part of ASN.1, the _parsing_: 

  http://tools.ietf.org/html/rfc3447#section-9.2

And an implementation is likely to not even attempt to decrypt
the PKCS#1 signature blob if it does not recognize the RSA-based
signature AlgID accompanying it...

-Martin

Date: Tue, 11 Jan 2011 13:35:58 +0100
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Apology...

Hi all,

I'm joining with the appology.  I had a long deserved vacation during 
end of the year and then I had to focus my attention on the work and 
some stuff in my personal life.  This was resolved yesterday and I 
should have some more time.

I'll try to dig through the tons of emails this week.

Ondrej

On 5.1.2011 00:46, Warren Kumari wrote:
> Hi all,
>
> I'd just quickly like to apologize for not having been nearly as
> involved recently as I should have been -- I got sidetracked with
> $dayjob (and other things) and haven't been giving DANE as much
> attention as it deserves.
>
> I have almost managed to clean off my plate (and dig out from under a
> mountain of mail) and should be able to devote more time soon...
>
> Apologies again,
> W
>
> --
> "Let's just say that if complete and utter chaos was lightning, he'd be
> the sort to stand on a hilltop in a thunderstorm wearing wet copper
> armour and shouting 'All gods are bastards'."
>
> -- Rincewind discussing Twoflower (Terry Pratchett, The Colour of Magic)
>
>
> _______________________________________________
> 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
  -------------------------------------------

Date: Mon, 10 Jan 2011 11:11:39 -0800
From: =JeffH <[email-masked]>
To: IETF DANE WG list <[email-masked]>
Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types."

PaulH replied..
 >
 > On 1/7/11 3:12 PM, Warren Kumari wrote:
 >
 >> If possible I'd like us to try and separate the discussions of "Who gets
 >> / how to get an identifier for an algorithm" from the question of how we
 >> actually identify these -- while I realize that there are
 >> interdependencies in the two issues and they are not fully separable,
 >> I'd appreciate it if we can try and separate them as much as possible so
 >> that it is easier to call consensus....
 >
 > Just to be clear, my preferences are:
 >
 > - Somewhat liberal policy for assigning: "RFC published", not "IETF
 > consensus" or "expert review"
 >
 > - two-byte integers for identifying, with 1000 reserved for private use

+1

altho we could probably get by with just one octet for hash alg identifiers, I 
wouldn't go to the mat over having two.

HTH,

=JeffH

Date: Sun, 9 Jan 2011 22:19:16 +0200
From: Ilari Liusvaara <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Sender: Ilari Liusvaara <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types."

On Sun, Jan 09, 2011 at 12:06:16AM -0500, Phillip Hallam-Baker wrote:
> Actually PKCS#1 which is the RSA spec also uses ASN.1 as the prep for the
> packaging format.
> 
> So it really is unavoidable.

I agree that it is _currently_ unavoidable, but I don't agree that it is
_fundamental_ requirement of TLS. 

I.e. it may be avoidable in future (even without a new TLS version)!

Based on my reading of relevant RFCs:

The only reason (partial) ASN.1 decoding is _currently_ unavoidable for a
TLS v1.2 client is lack of ASN.1-free raw key format[*].

Define a ASN.1-free raw key format, get codepoint for it (IETF consensus)
and this goes away.

Bonus points for new SignatureAlgorithm that is ASN.1-free RSA (specification
required). The existing RSA there is PKCS#1 v1.5 anyway...

[*] You hit PKCS#1 signature verification in implementing OpenPGP (to handle
the case where primary key is RSA).

-Ilari

Date: Sun, 9 Jan 2011 00:06:16 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Wouters <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types."

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

Actually PKCS#1 which is the RSA spec also uses ASN.1 as the prep for the
packaging format.

So it really is unavoidable.

You can fake it of course (most people do in fact) but that is exactly what
I suggested for ODI

If we adopt Warren's suggestion then we only need one byte since we can
always use ODIs if the registry is exhausted.

Having seen the mess caused by the decision to use 4 byte IP addresses, I am
not keen to see a repeat. And contrary to what some may claim there were
several people who pointed out that 4 billion addresses was too small at the
time the decision was taken.

On Sat, Jan 8, 2011 at 11:38 PM, Paul Wouters <[email-masked]> wrote:

> On Sat, 8 Jan 2011, Phillip Hallam-Baker wrote:
>
>  Here you are interfacing to PKIX which is an ASN.1 spec.
>>
>
> Not only. Once bare public key TLS support is there, things could move
> towards a full drop of ASN.1/PKIX.
>
> In fact, one could argue one of the reasons we need DANE is to fix
> limitations in PKIX, and the DANE spec is more then happy to provide
> side benefits to the PKIX community to help address those limitations,
> but DANE is clearly not a subset of PKIX protocols.
>
>
>  And in the
>> unlikely event that we did people can read the full ASN.1 documentation
>> that explains exactly what to do.]
>>
>
> Problems, not solutions, start with the phrase "read the full ASN.1
> documentation".
>
> Paul
>

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

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

Actually PKCS#1 which is the RSA spec also uses ASN.1 as the prep for the p=
ackaging format.<div><br></div><div>So it really is unavoidable.=A0</div><d=
iv><br></div><div>You can fake it of course (most people do in fact) but th=
at is exactly what I suggested for ODI</div>
<div><br></div><div><br></div><div>If we adopt Warren&#39;s suggestion then=
 we only need one byte since we can always use ODIs if the registry is exha=
usted.</div><div><br></div><div><br></div><div>Having seen the mess caused =
by the decision to use 4 byte IP addresses, I am not keen to see a repeat. =
And contrary to what some may claim there were several people who pointed o=
ut that 4 billion addresses was too small at the time the decision was take=
n.</div>
<div><br><br><div class=3D"gmail_quote">On Sat, Jan 8, 2011 at 11:38 PM, Pa=
ul Wouters <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">paul=
@xelerance.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">On Sat, 8 Jan 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">
Here you are interfacing to PKIX which is an ASN.1 spec.<br>
</blockquote>
<br></div>
Not only. Once bare public key TLS support is there, things could move<br>
towards a full drop of ASN.1/PKIX.<br>
<br>
In fact, one could argue one of the reasons we need DANE is to fix<br>
limitations in PKIX, and the DANE spec is more then happy to provide<br>
side benefits to the PKIX community to help address those limitations,<br>
but DANE is clearly not a subset of PKIX protocols.<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">
And in the<br>
unlikely event that we did people can read the full ASN.1 documentation tha=
t explains exactly what to do.]<br>
</blockquote>
<br></div>
Problems, not solutions, start with the phrase &quot;read the full ASN.1 do=
cumentation&quot;.<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>

--0016368e1bf0ab73ec049962cf35--

Date: Sat, 8 Jan 2011 23:38:21 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types."

On Sat, 8 Jan 2011, Phillip Hallam-Baker wrote:

> Here you are interfacing to PKIX which is an ASN.1 spec.

Not only. Once bare public key TLS support is there, things could move
towards a full drop of ASN.1/PKIX.

In fact, one could argue one of the reasons we need DANE is to fix
limitations in PKIX, and the DANE spec is more then happy to provide
side benefits to the PKIX community to help address those limitations,
but DANE is clearly not a subset of PKIX protocols.

> And in the
> unlikely event that we did people can read the full ASN.1 documentation that explains exactly what to do.]

Problems, not solutions, start with the phrase "read the full ASN.1 documentation".

Paul

Date: Sat, 8 Jan 2011 23:23:50 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types."

On Sat, 8 Jan 2011, Phillip Hallam-Baker wrote:

> The problem with attempting to re-use the DNSSEC registries is that
> the DNSEXT people presumably chose to have their own registry so as to
> have control themselves.

Is that really the reason?

> What happens if we want to use an algorithm and they do not?

Who is "we" and who is "they"?

DANE is about validating crypto identities via DNS? That means "we" are "they".

If I take all the SHA1 and SHA2 and SHA3 candidates, we end up with
what? 25 hashing algorithms in 25 years? So one byte would give us
about 200 years?

Add a few new container formats (eg bare public key, and some x.509 v4+ or
something) and I still don't see this hitting 256. Though I guess one more
byte to be super safe would not hurt either.

Paul

Date: Sat, 8 Jan 2011 14:40:05 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Warren Kumari <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types."

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

OK if that is your proposal, I will take the code point 30 12 for an ODI
reference minus the initial ASN.1 SEQ identifier (30 12).

On Sat, Jan 8, 2011 at 2:04 PM, Warren Kumari <[email-masked]> wrote:

> <chair hat>
> Boys! Please...
> </chair hat>
>
> <no hat>
> Ok, so I'm proposing a compromise here as a third option. As this is a
> compromise, I'm assuming no-one will love it, but maybe folk will be willing
> to accept it...
>
> We ask the IANA to create us a registry (I'm proposing 2 octet codespace,
> with some portion chopped out for experimental values -- this gives us >65k
> usable values (and I don't want to live in a world where we approach that
> :-P), but that's just a thought). ODI can be assigned a value from this
> space, and once / if everyone discovers that they like it, folk will no
> longer bother trying to get assignments from our registry, which would
> remove the "registering new values" burden from the IANA.
>
>
> The obvious downsides are:
> 1: If ODI becomes the standard that everyone converges on,  we will have
> burnt 16 bits for nothing.
> 2: In instances where ODI is used the "payload" will not be in the same
> place in the structure. Implementations that do not support ODI obviously
> just treat these as they would any other case where they do not understand
> the identified algorithm / registered value....
>
> The parsing for this is simple (in c-ish psudocode):
> switch (dane_struct->codepoint) {
>  case  CP_SHA_256:
>      handle_sha256(dane_struct);
>      break;
>  case CP_SHA_512:
>      handle_sha512(dane_struct);
>      break;
> #ifdef HAVE_ODI
>  case_CP_ODI:
>      handle_odi(dane_struct);
>      break;
> #endif
>  case default:
>      debug("Not yet supported algorithm number: ", dane_struct->codepoint);
>      break;
> }
>
>
> To my mind, these downsides are minor... Thoughts?
>
> W
> </no hat>
>
>
>
> On Jan 8, 2011, at 12:35 PM, Paul Hoffman wrote:
>
>  On 1/8/11 8:37 AM, Phillip Hallam-Baker wrote:
>>
>>> On Sat, Jan 8, 2011 at 11:18 AM, Paul Hoffman <[email-masked]
>>> <mailto:[email-masked]>> wrote:
>>>
>>>   On 1/8/11 6:07 AM, Phillip Hallam-Baker wrote:
>>>
>>>       Since this is precisely the type of change that KEYPROV was
>>> required
>>>       to make during IESG review, I would have to disagree.
>>>
>>>       We had specified our own password string prep, we were told we
>>>       had to
>>>       use the existing string prep from another spec.
>>>
>>>
>>>   The "precisely" in the first paragraph completely disagrees with the
>>>   second paragraph. The format of the identifier is completely
>>>   dissimilar from a modification of a difficult internationalization
>>>   process.
>>>
>>>
>>> No, it was a change the WG debated at considerable length when there was
>>> no need to as it was not a decision it should have made.
>>>
>>
>> Then you should blame the WG chairs (you were one of them).
>>
>>    That's fine for you to predict, but I predict differently. I think
>>>   if we choose either a short numeric identifier (as is already used
>>>   in most DNS protocols) or an OID (as is already used in PKIX and
>>>   S/MIME), the IESG will be fine.
>>>
>>>
>>> We also had a draft written by the current IETF chair and one of the
>>> IETF Security Area directors that converted all our XML formats into
>>> ASN.1. The other Security AD told us to add it as a WG item.
>>>
>>
>> Correct. If this WG was considering having our algorithm identifiers as
>> XML structures, we might have the same. Fortunately, we don't.
>>
>>  Have you any idea how much the security area likes ASN.1?
>>>
>>
>> Having written a handful of Security Area RFCs that use ASN.1: yes, I do.
>>
>>  Here you are interfacing to PKIX which is an ASN.1 spec.
>>>
>>
>> So? IKEv1 and IKEv2 and TLS and SSH all "interface" (blech) with PKIX in a
>> similar fashion, and neither are in ASN.1 format. To the best of my
>> knowledge, no one ever suggested that they should be.
>> _______________________________________________
>> keyassure mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/keyassure
>>
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

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

OK if that is your proposal, I will take the code point 30 12 for an ODI re=
ference minus the initial ASN.1 SEQ identifier (30 12).<div><br></div><div>=
<br></div><div><div><br><div class=3D"gmail_quote">On Sat, Jan 8, 2011 at 2=
:04 PM, Warren Kumari <span dir=3D"ltr">&lt;<a href=3D"mailto:warren@kumari=
.net">[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;">&lt;chair hat&gt;<br>
Boys! Please...<br>
&lt;/chair hat&gt;<br>
<br>
&lt;no hat&gt;<br>
Ok, so I&#39;m proposing a compromise here as a third option. As this is a =
compromise, I&#39;m assuming no-one will love it, but maybe folk will be wi=
lling to accept it...<br>
<br>
We ask the IANA to create us a registry (I&#39;m proposing 2 octet codespac=
e, with some portion chopped out for experimental values -- this gives us &=
gt;65k usable values (and I don&#39;t want to live in a world where we appr=
oach that :-P), but that&#39;s just a thought). ODI can be assigned a value=
 from this space, and once / if everyone discovers that they like it, folk =
will no longer bother trying to get assignments from our registry, which wo=
uld remove the &quot;registering new values&quot; burden from the IANA.<br>

<br>
<br>
The obvious downsides are:<br>
1: If ODI becomes the standard that everyone converges on, =A0we will have =
burnt 16 bits for nothing.<br>
2: In instances where ODI is used the &quot;payload&quot; will not be in th=
e same place in the structure. Implementations that do not support ODI obvi=
ously just treat these as they would any other case where they do not under=
stand the identified algorithm / registered value....<br>

<br>
The parsing for this is simple (in c-ish psudocode):<br>
switch (dane_struct-&gt;codepoint) {<br>
 =A0case =A0CP_SHA_256:<br>
 =A0 =A0 =A0handle_sha256(dane_struct);<br>
 =A0 =A0 =A0break;<br>
 =A0case CP_SHA_512:<br>
 =A0 =A0 =A0handle_sha512(dane_struct);<br>
 =A0 =A0 =A0break;<br>
#ifdef HAVE_ODI<br>
 =A0case_CP_ODI:<br>
 =A0 =A0 =A0handle_odi(dane_struct);<br>
 =A0 =A0 =A0break;<br>
#endif<br>
 =A0case default:<br>
 =A0 =A0 =A0debug(&quot;Not yet supported algorithm number: &quot;, dane_st=
ruct-&gt;codepoint);<br>
 =A0 =A0 =A0break;<br>
}<br>
<br>
<br>
To my mind, these downsides are minor... Thoughts?<br>
<br>
W<br>
&lt;/no hat&gt;<div><div></div><div class=3D"h5"><br>
<br>
<br>
On Jan 8, 2011, at 12:35 PM, Paul Hoffman wrote:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On 1/8/11 8:37 AM, Phillip Hallam-Baker wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On Sat, Jan 8, 2011 at 11:18 AM, Paul Hoffman &lt;<a href=3D"mailto:paul.ho=
[email-masked]" target=3D"_blank">[email-masked]</a><br>
&lt;mailto:<a href=3D"mailto:[email-masked]" target=3D"_blank">paul.=
[email-masked]</a>&gt;&gt; wrote:<br>
<br>
 =A0 On 1/8/11 6:07 AM, Phillip Hallam-Baker wrote:<br>
<br>
 =A0 =A0 =A0 Since this is precisely the type of change that KEYPROV was re=
quired<br>
 =A0 =A0 =A0 to make during IESG review, I would have to disagree.<br>
<br>
 =A0 =A0 =A0 We had specified our own password string prep, we were told we=
<br>
 =A0 =A0 =A0 had to<br>
 =A0 =A0 =A0 use the existing string prep from another spec.<br>
<br>
<br>
 =A0 The &quot;precisely&quot; in the first paragraph completely disagrees =
with the<br>
 =A0 second paragraph. The format of the identifier is completely<br>
 =A0 dissimilar from a modification of a difficult internationalization<br>
 =A0 process.<br>
<br>
<br>
No, it was a change the WG debated at considerable length when there was<br=
>
no need to as it was not a decision it should have made.<br>
</blockquote>
<br>
Then you should blame the WG chairs (you were one of them).<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
 =A0 That&#39;s fine for you to predict, but I predict differently. I think=
<br>
 =A0 if we choose either a short numeric identifier (as is already used<br>
 =A0 in most DNS protocols) or an OID (as is already used in PKIX and<br>
 =A0 S/MIME), the IESG will be fine.<br>
<br>
<br>
We also had a draft written by the current IETF chair and one of the<br>
IETF Security Area directors that converted all our XML formats into<br>
ASN.1. The other Security AD told us to add it as a WG item.<br>
</blockquote>
<br>
Correct. If this WG was considering having our algorithm identifiers as XML=
 structures, we might have the same. Fortunately, we don&#39;t.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Have you any idea how much the security area likes ASN.1?<br>
</blockquote>
<br>
Having written a handful of Security Area RFCs that use ASN.1: yes, I do.<b=
r>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Here you are interfacing to PKIX which is an ASN.1 spec.<br>
</blockquote>
<br>
So? IKEv1 and IKEv2 and TLS and SSH all &quot;interface&quot; (blech) with =
PKIX in a similar fashion, and neither are in ASN.1 format. To the best of =
my knowledge, no one ever suggested that they should be.<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>
<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>

--0016e6434bced34d8b04995ae687--

Date: Sat, 8 Jan 2011 13:23:12 -0600 (GMT-06:00)
From: "Jeffrey A. Williams" <[email-masked]>
To: Warren Kumari <[email-masked]>, Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Starting to work through the issues: Issue #4 --	"Identification of hash and cert types."
Reply-To: "Jeffrey A. Williams" <[email-masked]>

warren and all,

  Good compermise third option IMO.

Kindest Regards,

Jeffrey A. Williams
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
IT/network security Eng. SR. Eng. Network data security,
IT/information and web security.
ABA member in good standing member ID 01257402 
E-Mail [email-masked]
Phone: 214-244-4827

-----Original Message-----
>From: Warren Kumari <[email-masked]>
>Sent: Jan 8, 2011 1:04 PM
>To: Paul Hoffman <[email-masked]>
>Cc: [email-masked]
>Subject: Re: [keyassure] Starting to work through the issues: Issue #4 --	"Identification of hash and cert types."
>
><chair hat>
>Boys! Please...
></chair hat>
>
><no hat>
>Ok, so I'm proposing a compromise here as a third option. As this is a  
>compromise, I'm assuming no-one will love it, but maybe folk will be  
>willing to accept it...
>
>We ask the IANA to create us a registry (I'm proposing 2 octet  
>codespace, with some portion chopped out for experimental values --  
>this gives us >65k usable values (and I don't want to live in a world  
>where we approach that :-P), but that's just a thought). ODI can be  
>assigned a value from this space, and once / if everyone discovers  
>that they like it, folk will no longer bother trying to get  
>assignments from our registry, which would remove the "registering new  
>values" burden from the IANA.
>
>
>The obvious downsides are:
>1: If ODI becomes the standard that everyone converges on,  we will  
>have burnt 16 bits for nothing.
>2: In instances where ODI is used the "payload" will not be in the  
>same place in the structure. Implementations that do not support ODI  
>obviously just treat these as they would any other case where they do  
>not understand the identified algorithm / registered value....
>
>The parsing for this is simple (in c-ish psudocode):
>switch (dane_struct->codepoint) {
>   case  CP_SHA_256:
>       handle_sha256(dane_struct);
>       break;
>   case CP_SHA_512:
>       handle_sha512(dane_struct);
>       break;
>#ifdef HAVE_ODI
>   case_CP_ODI:
>       handle_odi(dane_struct);
>       break;
>#endif
>   case default:
>       debug("Not yet supported algorithm number: ", dane_struct- 
> >codepoint);
>       break;
>}
>
>
>To my mind, these downsides are minor... Thoughts?
>
>W
></no hat>
>
>
>On Jan 8, 2011, at 12:35 PM, Paul Hoffman wrote:
>
>> On 1/8/11 8:37 AM, Phillip Hallam-Baker wrote:
>>> On Sat, Jan 8, 2011 at 11:18 AM, Paul Hoffman <[email-masked]
>>> <mailto:[email-masked]>> wrote:
>>>
>>>    On 1/8/11 6:07 AM, Phillip Hallam-Baker wrote:
>>>
>>>        Since this is precisely the type of change that KEYPROV was  
>>> required
>>>        to make during IESG review, I would have to disagree.
>>>
>>>        We had specified our own password string prep, we were told we
>>>        had to
>>>        use the existing string prep from another spec.
>>>
>>>
>>>    The "precisely" in the first paragraph completely disagrees with  
>>> the
>>>    second paragraph. The format of the identifier is completely
>>>    dissimilar from a modification of a difficult internationalization
>>>    process.
>>>
>>>
>>> No, it was a change the WG debated at considerable length when  
>>> there was
>>> no need to as it was not a decision it should have made.
>>
>> Then you should blame the WG chairs (you were one of them).
>>
>>>    That's fine for you to predict, but I predict differently. I think
>>>    if we choose either a short numeric identifier (as is already used
>>>    in most DNS protocols) or an OID (as is already used in PKIX and
>>>    S/MIME), the IESG will be fine.
>>>
>>>
>>> We also had a draft written by the current IETF chair and one of the
>>> IETF Security Area directors that converted all our XML formats into
>>> ASN.1. The other Security AD told us to add it as a WG item.
>>
>> Correct. If this WG was considering having our algorithm identifiers  
>> as XML structures, we might have the same. Fortunately, we don't.
>>
>>> Have you any idea how much the security area likes ASN.1?
>>
>> Having written a handful of Security Area RFCs that use ASN.1: yes,  
>> I do.
>>
>>> Here you are interfacing to PKIX which is an ASN.1 spec.
>>
>> So? IKEv1 and IKEv2 and TLS and SSH all "interface" (blech) with  
>> PKIX in a similar fashion, and neither are in ASN.1 format. To the  
>> best of my knowledge, no one ever suggested that they should be.
>> _______________________________________________
>> keyassure mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/keyassure
>
>_______________________________________________
>keyassure mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyassure

Date: Sat, 08 Jan 2011 11:13:28 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types."

On 1/8/11 11:04 AM, Warren Kumari wrote:
> Ok, so I'm proposing a compromise here as a third option. As this is a
> compromise, I'm assuming no-one will love it, but maybe folk will be
> willing to accept it...

If that's the way you think the consensus is going, that's fine. I 
didn't see it going that way. Phill had one proposal with (possibly one) 
person behind it. I had another with a small handful behind it. Others 
had not weighed in yet.

Of the now three proposals for the format, I still feel that "a 
two-octet number" is better than ODI or a mixture of the two, FWIW.

From: Warren Kumari <[email-masked]>
To: Paul Hoffman <[email-masked]>
Date: Sat, 8 Jan 2011 14:04:59 -0500
Cc: [email-masked]
Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types."

<chair hat>
Boys! Please...
</chair hat>

<no hat>
Ok, so I'm proposing a compromise here as a third option. As this is a  
compromise, I'm assuming no-one will love it, but maybe folk will be  
willing to accept it...

We ask the IANA to create us a registry (I'm proposing 2 octet  
codespace, with some portion chopped out for experimental values --  
this gives us >65k usable values (and I don't want to live in a world  
where we approach that :-P), but that's just a thought). ODI can be  
assigned a value from this space, and once / if everyone discovers  
that they like it, folk will no longer bother trying to get  
assignments from our registry, which would remove the "registering new  
values" burden from the IANA.

The obvious downsides are:
1: If ODI becomes the standard that everyone converges on,  we will  
have burnt 16 bits for nothing.
2: In instances where ODI is used the "payload" will not be in the  
same place in the structure. Implementations that do not support ODI  
obviously just treat these as they would any other case where they do  
not understand the identified algorithm / registered value....

The parsing for this is simple (in c-ish psudocode):
switch (dane_struct->codepoint) {
   case  CP_SHA_256:
       handle_sha256(dane_struct);
       break;
   case CP_SHA_512:
       handle_sha512(dane_struct);
       break;
#ifdef HAVE_ODI
   case_CP_ODI:
       handle_odi(dane_struct);
       break;
#endif
   case default:
       debug("Not yet supported algorithm number: ", dane_struct- 
 >codepoint);
       break;
}

To my mind, these downsides are minor... Thoughts?

W
</no hat>

On Jan 8, 2011, at 12:35 PM, Paul Hoffman wrote:

> On 1/8/11 8:37 AM, Phillip Hallam-Baker wrote:
>> On Sat, Jan 8, 2011 at 11:18 AM, Paul Hoffman <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>    On 1/8/11 6:07 AM, Phillip Hallam-Baker wrote:
>>
>>        Since this is precisely the type of change that KEYPROV was  
>> required
>>        to make during IESG review, I would have to disagree.
>>
>>        We had specified our own password string prep, we were told we
>>        had to
>>        use the existing string prep from another spec.
>>
>>
>>    The "precisely" in the first paragraph completely disagrees with  
>> the
>>    second paragraph. The format of the identifier is completely
>>    dissimilar from a modification of a difficult internationalization
>>    process.
>>
>>
>> No, it was a change the WG debated at considerable length when  
>> there was
>> no need to as it was not a decision it should have made.
>
> Then you should blame the WG chairs (you were one of them).
>
>>    That's fine for you to predict, but I predict differently. I think
>>    if we choose either a short numeric identifier (as is already used
>>    in most DNS protocols) or an OID (as is already used in PKIX and
>>    S/MIME), the IESG will be fine.
>>
>>
>> We also had a draft written by the current IETF chair and one of the
>> IETF Security Area directors that converted all our XML formats into
>> ASN.1. The other Security AD told us to add it as a WG item.
>
> Correct. If this WG was considering having our algorithm identifiers  
> as XML structures, we might have the same. Fortunately, we don't.
>
>> Have you any idea how much the security area likes ASN.1?
>
> Having written a handful of Security Area RFCs that use ASN.1: yes,  
> I do.
>
>> Here you are interfacing to PKIX which is an ASN.1 spec.
>
> So? IKEv1 and IKEv2 and TLS and SSH all "interface" (blech) with  
> PKIX in a similar fashion, and neither are in ASN.1 format. To the  
> best of my knowledge, no one ever suggested that they should be.
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Date: Sat, 08 Jan 2011 09:35:19 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types."

On 1/8/11 8:37 AM, Phillip Hallam-Baker wrote:
> On Sat, Jan 8, 2011 at 11:18 AM, Paul Hoffman <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     On 1/8/11 6:07 AM, Phillip Hallam-Baker wrote:
>
>         Since this is precisely the type of change that KEYPROV was required
>         to make during IESG review, I would have to disagree.
>
>         We had specified our own password string prep, we were told we
>         had to
>         use the existing string prep from another spec.
>
>
>     The "precisely" in the first paragraph completely disagrees with the
>     second paragraph. The format of the identifier is completely
>     dissimilar from a modification of a difficult internationalization
>     process.
>
>
> No, it was a change the WG debated at considerable length when there was
> no need to as it was not a decision it should have made.

Then you should blame the WG chairs (you were one of them).

>     That's fine for you to predict, but I predict differently. I think
>     if we choose either a short numeric identifier (as is already used
>     in most DNS protocols) or an OID (as is already used in PKIX and
>     S/MIME), the IESG will be fine.
>
>
> We also had a draft written by the current IETF chair and one of the
> IETF Security Area directors that converted all our XML formats into
> ASN.1. The other Security AD told us to add it as a WG item.

Correct. If this WG was considering having our algorithm identifiers as 
XML structures, we might have the same. Fortunately, we don't.

> Have you any idea how much the security area likes ASN.1?

Having written a handful of Security Area RFCs that use ASN.1: yes, I do.

> Here you are interfacing to PKIX which is an ASN.1 spec.

So? IKEv1 and IKEv2 and TLS and SSH all "interface" (blech) with PKIX in 
a similar fashion, and neither are in ASN.1 format. To the best of my 
knowledge, no one ever suggested that they should be.

Date: Sat, 8 Jan 2011 11:37:18 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types."

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

On Sat, Jan 8, 2011 at 11:18 AM, Paul Hoffman <[email-masked]> wrote:

> On 1/8/11 6:07 AM, Phillip Hallam-Baker wrote:
>
>> Since this is precisely the type of change that KEYPROV was required
>> to make during IESG review, I would have to disagree.
>>
>> We had specified our own password string prep, we were told we had to
>> use the existing string prep from another spec.
>>
>
> The "precisely" in the first paragraph completely disagrees with the second
> paragraph. The format of the identifier is completely dissimilar from a
> modification of a difficult internationalization process.

No, it was a change the WG debated at considerable length when there was no
need to as it was not a decision it should have made.

That's fine for you to predict, but I predict differently. I think if we
> choose either a short numeric identifier (as is already used in most DNS
> protocols) or an OID (as is already used in PKIX and S/MIME), the IESG will
> be fine.

We also had a draft written by the current IETF chair and one of the IETF
Security Area directors that converted all our XML formats into ASN.1. The
other Security AD told us to add it as a WG item.

Have you any idea how much the security area likes ASN.1?

Here you are interfacing to PKIX which is an ASN.1 spec.

> As for the negatives on OIDs, your description of how to encode ODIs is, so
> far, incomplete (hint: large integers), so even you can't say how easy or
> hard it is.
>
>
Another difference is that when I make a technical point I make a technical
point rather than asking people to play guessing games.

If you have a point then make your point.

Hint: You don't exactly have the standing in the field to be condescending
towards others.

As it is you seem to be criticizing me for not explaining how to handle an
edge case that could not possibly occur unless our entire understanding of
crypto suddenly changed.

[Since the output of all currently used digest algorithms is fixed, an
implementation that supports a fixed number of digest algorithms is not
going to require any length greater than 127 bytes and thus the large
integer issue would never occur.

Furthermore, unless there are unexpected developments in computing we really
should not be expecting to use digests of more than 256 bits. And in the
unlikely event that we did people can read the full ASN.1 documentation that
explains exactly what to do.]

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

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

<br><br><div class=3D"gmail_quote">On Sat, Jan 8, 2011 at 11:18 AM, Paul Ho=
ffman <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]">paul.h=
[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 1/8/11 6:07 AM, Phillip Hallam-Baker wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Since this is precisely the type of change that KEYPROV was required<br>
to make during IESG review, I would have to disagree.<br>
<br>
We had specified our own password string prep, we were told we had to<br>
use the existing string prep from another spec.<br>
</blockquote>
<br></div>
The &quot;precisely&quot; in the first paragraph completely disagrees with =
the second paragraph. The format of the identifier is completely dissimilar=
 from a modification of a difficult internationalization process.</blockquo=
te>
<div><br></div><div>No, it was a change the WG debated at considerable leng=
th when there was no need to as it was not a decision it should have made.<=
/div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
That&#39;s fine for you to predict, but I predict differently. I think if w=
e choose either a short numeric identifier (as is already used in most DNS =
protocols) or an OID (as is already used in PKIX and S/MIME), the IESG will=
 be fine.</blockquote>
<div><br></div><div>We also had a draft written by the current IETF chair a=
nd one of the IETF Security Area directors that converted all our XML forma=
ts into ASN.1.=A0The other Security AD told us to add it as a WG item.</div=
>
<div><br></div><div>Have you any idea how much the security area likes ASN.=
1?</div><div><br></div><div>Here you are interfacing to PKIX which is an AS=
N.1 spec.</div><div><br></div><div><br></div><div>=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex;">

As for the negatives on OIDs, your description of how to encode ODIs is, so=
 far, incomplete (hint: large integers), so even you can&#39;t say how easy=
 or hard it is.<div><div></div><div class=3D"h5"><br></div></div></blockquo=
te>
<div><br></div><div>Another difference is that when I make a technical poin=
t I make a technical point rather than asking people to play guessing games=
.</div><div><br></div><div>If you have a point then make your point.=A0</di=
v>
<div><br></div><div>Hint: You don&#39;t exactly have the standing in the fi=
eld to be condescending towards others.</div><div><br></div><div>As it is y=
ou seem to be criticizing me for not explaining how to handle an edge case =
that could not possibly occur unless our entire understanding of crypto sud=
denly changed.</div>
<div><br></div><div><br></div><div>[Since the output of all currently used =
digest algorithms is fixed, an implementation that supports a fixed number =
of digest algorithms is not going to require any length greater than 127 by=
tes and thus the large integer issue would never occur.</div>
<div><br></div><div>Furthermore, unless there are unexpected developments i=
n computing we really should not be expecting to use digests of more than 2=
56 bits. And in the unlikely event that we did people can read the full ASN=
.1 documentation that explains exactly what to do.]</div>
</div><br>-- <br>Website: <a href=3D"http://hallambaker.com/">http://hallam=
baker.com/</a><br><br>

--0016e644dbc62875f904995859fe--

Date: Sat, 08 Jan 2011 08:18:45 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types."

On 1/8/11 6:07 AM, Phillip Hallam-Baker wrote:
> Since this is precisely the type of change that KEYPROV was required
> to make during IESG review, I would have to disagree.
>
> We had specified our own password string prep, we were told we had to
> use the existing string prep from another spec.

The "precisely" in the first paragraph completely disagrees with the 
second paragraph. The format of the identifier is completely dissimilar 
from a modification of a difficult internationalization process.

>> From a process point of view I think that the chances of being told to
> move from ASN.1 to a custom registry are essentially 0% while the
> chance of being told to move from a custom registry to ASN.1 is
> approximately 50:50%

That's fine for you to predict, but I predict differently. I think if we 
choose either a short numeric identifier (as is already used in most DNS 
protocols) or an OID (as is already used in PKIX and S/MIME), the IESG 
will be fine.

> Proliferating crypto registries imposes a cost on the whole
> organization. It is making busy-work that is not necessary.

And yet IETF WGs do it on a regular basis, with the full approval of the 
IESG.

> The point of working in the IETF as opposed to doing a roll your own
> standards organization is meant to be building on the work of others.
> ODI is designed to be a re-usable building block that can be used in
> other places. It builds on ASN.1 which is itself a frequently used
> building block that is essentially a standard in the crypto world.

...and yet your ODI proposal, which you brought to many WGs, has 
garnered almost no support.

> So far I have given concrete benefits for my design choices. In
> contrast the opposition has been 'well I prefer' without giving actual
> benefits.

The fact that you don't like the actual benefits that we have listed 
repeatedly doesn't mean we didn't give them.

> The nearest we got was Paul's rather silly claim that ODI is
> difficult to code (false) and the vague idea that having a registry
> puts you in control.

That is not a vague idea: it is one that is embraced by virtually every 
WG in the IETF. Further, the idea of "I know how to encode a two-octet 
integer" is easy to understand. The fact that they are shorter is a 
benefit, even though a small one.

As for the negatives on OIDs, your description of how to encode ODIs is, 
so far, incomplete (hint: large integers), so even you can't say how 
easy or hard it is.

Date: Sat, 08 Jan 2011 08:09:41 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-01.txt

On 1/7/11 11:41 PM, Jakob Schlyter wrote:
> FYI, -01 contains a set of editorial edits and clarifications based on comments from the list.

To be more precise, we included all the edits and clarifications that we 
thought were non-controversial. If you brought up an issue during the 
review of the -00 and we didn't include it, and you still think it is an 
issue, be sure that the WG chairs/secretary open an issue on the topic 
so the WG can discuss it and come to consensus.

Date: Sat, 08 Jan 2011 08:07:53 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types."

On 1/7/11 7:23 PM, John Gilmore wrote:
> Let's be sure I understand the issue before jumping in.
>
> Some people want to use a small numerical value, such as one octet, to
> designate which hash or crypto algorithm is in use in a DNS record.
> For example, the DNSKEY record contains a 1-octet "algorithm" field,
> defined in RFC 4034.  The field's initial definition was in the RFC,
> Appendix A.1, and subsequent assignments are done by IANA.  There are
> reserved values for subsequent extension of the protocol by IETF, for
> private extensions, and values reserved for the indefinite future.
>
> Other people want to use an ASN.1 "OID" (or "ODR"), which is a
> multibyte sequence of arbitrary length, each subsequence of which
> defines a code point for allocating sub-code-points.  Sort of like a
> domain name system for naming things in binary.  For example, (someone
> come up with a field in an existing approved Standards Track RFC,
> please).  This field would be restricted to have a known prefix of a
> number of fixed byte values (specified in its RFC), and a set of known
> suffixes, which are fixed byte strings, each of which would represent
> an algorithm.  The organization identified by the initial prefix would
> have the power to define additional suffixes that identify additional
> algorithms, without amendment of the RFC and without further action
> by IETF.
>
> Is that really the issue?  If not, please edit and repost similar text
> to provide a succinct 2-paragraph description of the issue.

You have intertwined the issues, as have others. Warren asked us to 
detwine them, which I think is good. Using your text above, one issue is 
"format is small numerical value or ASN.1 OID". The second issue is "who 
gets to put other values into the specified format, and with what 
difficulty". Hope this helps.

Date: Sat, 8 Jan 2011 10:00:33 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Matt McCutchen <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types."

On Sat, Jan 8, 2011 at 9:46 AM, Matt McCutchen <[email-masked]> wro=
te:
> On Sat, 2011-01-08 at 09:34 -0500, Phillip Hallam-Baker wrote:
>> The technical impact of this choice is
>>
>> 1) Whether the identifier is 1 or 2 bytes or an average of about 8.
>
> No, it's more than 8; for example, here is the 20-byte prefix for a "CA
> certificate" with SHA-256:
>
> 30 12 06 03 55 04 25 06 09 60 86 48 01 65 03 04 02 01 04 20

ODI has two identifiers in it. The algorithm ones are from the NIST
arc so are the shorter ones.

We do need to have a mechanism to identify both parts.

>> I don't think that the shaving of a few bytes here is relevant. If we
>> go for 1 byte it is very likely we end up with an exhaustion issue
>> down the line.
>
> I don't think so. =A0Are hash algorithms really being invented at such a
> rate that over the likely lifespan of DANE (is 30 years a safe high
> estimate?) more than 200 or so algorithms would be registered? =A0There
> are only 10 entries in the DNSSEC registry so far. =A0On the other hand,
> using OIDs lets us do slick things like let organizations assign their
> own globally unique algorithm IDs.

We need to have a different identifier for each strength. So we have
six slots taken by SHA2 and the expected SHA3 for a start. There are
currently 5 finalists, that would be 18 identifiers used if we did
them all.

The risk of exhaustion may not be very high, but fixed length fields
make many of us nervous.

I expect to be around in 30 years time. I don't expect there will have
been major changes to IP or HTTP in that time. I have been writing
HTTP code 19 years now and that has not changed.

My personal design horizon for protocols is never less than a
millennia, Having had to deal with other people's short sightedness I
would argue against a design horizon of less than 200 years.

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

From: Matt McCutchen <[email-masked]>
To: keyassure <[email-masked]>
Date: Sat, 08 Jan 2011 09:58:52 -0500
Subject: [keyassure] ODI should not include object type

AIUI, an ODI is a stand-in for the object itself via a hash algorithm.
And ASN.1 objects are not self-typing.  Therefore, I do not think the
object type belongs in ODIs either.  Self-typing, if desired, is a
purpose orthogonal to hashing.

In the DANE draft, the expected object type (i.e., PKIX certificate) is
known from context.  And that must be so for the sake of the
"certificate type" values 2 and 4 that embed the object without
additional metadata.  So having the object type in ODIs is not helpful
to DANE.

Removing the object type will help make the overhead of ODIs more
reasonable.

-- 
Matt

From: Matt McCutchen <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 08 Jan 2011 09:51:55 -0500
Cc: [email-masked]
Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types."

On Sat, 2011-01-08 at 09:41 -0500, Phillip Hallam-Baker wrote:
> The problem with attempting to re-use the DNSSEC registries is that
> the DNSEXT people presumably chose to have their own registry so as to
> have control themselves.

I wouldn't presume that.  We would have to look back through their
discussion.  They may have just thought that the use of one-byte values
was more in keeping with the design of DNS.

Even so, if we determine that our goals are the same as theirs (as I
would guess), there is no issue.

> What happens if we want to use an algorithm and they do not?

That would be problematic.

> What happens if they add a code point for an algorithm that we do not want?

We just publish advice for people not to use it.

-- 
Matt

From: Matt McCutchen <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 08 Jan 2011 09:46:10 -0500
Cc: [email-masked]
Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types."

On Sat, 2011-01-08 at 09:34 -0500, Phillip Hallam-Baker wrote:
> The technical impact of this choice is
> 
> 1) Whether the identifier is 1 or 2 bytes or an average of about 8.

No, it's more than 8; for example, here is the 20-byte prefix for a "CA
certificate" with SHA-256:

30 12 06 03 55 04 25 06 09 60 86 48 01 65 03 04 02 01 04 20

> I don't think that the shaving of a few bytes here is relevant. If we
> go for 1 byte it is very likely we end up with an exhaustion issue
> down the line.

I don't think so.  Are hash algorithms really being invented at such a
rate that over the likely lifespan of DANE (is 30 years a safe high
estimate?) more than 200 or so algorithms would be registered?  There
are only 10 entries in the DNSSEC registry so far.  On the other hand,
using OIDs lets us do slick things like let organizations assign their
own globally unique algorithm IDs.

-- 
Matt

Date: Sat, 8 Jan 2011 09:41:13 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Matt McCutchen <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types."

On Sat, Jan 8, 2011 at 9:34 AM, Matt McCutchen <[email-masked]> wro=
te:
> On Sat, 2011-01-08 at 09:07 -0500, Phillip Hallam-Baker wrote:
>> Proliferating crypto registries imposes a cost on the whole
>> organization. It is making busy-work that is not necessary.
>
> I agree.
>
>> The point of working in the IETF as opposed to doing a roll your own
>> standards organization is meant to be building on the work of others.
>> ODI is designed to be a re-usable building block that can be used in
>> other places.
>
> Right, but it is a /new/ re-usable building block. =A0Reusing the DNSSEC
> registry would be a more conservative choice than inventing ODI and
> would still achieve the goal of not proliferating crypto registries.
> There is a trade-off.

The problem with attempting to re-use the DNSSEC registries is that
the DNSEXT people presumably chose to have their own registry so as to
have control themselves.

What happens if we want to use an algorithm and they do not?

What happens if they add a code point for an algorithm that we do not want?

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

From: Matt McCutchen <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 08 Jan 2011 09:34:55 -0500
Cc: [email-masked]
Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types."

On Sat, 2011-01-08 at 09:07 -0500, Phillip Hallam-Baker wrote:
> Proliferating crypto registries imposes a cost on the whole
> organization. It is making busy-work that is not necessary.

I agree.

> The point of working in the IETF as opposed to doing a roll your own
> standards organization is meant to be building on the work of others.
> ODI is designed to be a re-usable building block that can be used in
> other places.

Right, but it is a /new/ re-usable building block.  Reusing the DNSSEC
registry would be a more conservative choice than inventing ODI and
would still achieve the goal of not proliferating crypto registries.
There is a trade-off.

> So far I have given concrete benefits for my design choices. In
> contrast the opposition has been 'well I prefer' without giving actual
> benefits.

In order to verify this kind of claim, I have to dig back through the
mail and assess whether the benefits claimed for the alternative
solution are "actual", etc., and possibly miss something.  This is
frustrating and leads to discussions that go around in circles.  Could
we perhaps maintain a list of benefits for each solution in one place on
the wiki?  (I am having trouble with loginmgr though; I contacted
[email-masked] on Wednesday and haven't heard back yet.)

-- 
Matt

Date: Sat, 8 Jan 2011 09:34:30 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Warren Kumari <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types."

On Fri, Jan 7, 2011 at 6:12 PM, Warren Kumari <[email-masked]> wrote:

> If possible I'd like us to try and separate the discussions of "Who gets /
> how to get an identifier for an algorithm" from the question of how we
> actually identify these -- while I realize that there are interdependencies
> in the two issues and they are not fully separable, I'd appreciate it if we
> can try and separate them as much as possible so that it is easier to call
> consensus....

The technical impact of this choice is

1) Whether the identifier is 1 or 2 bytes or an average of about 8.
2) Whether the identifier space can be exhausted or not
3) What are the criteria for gating access to the registry.

I don't think that the shaving of a few bytes here is relevant. If we
go for 1 byte it is very likely we end up with an exhaustion issue
down the line.

If we go for a self-describing length scheme we endup with something
that looks like ASN.1

If people want we could have a hybrid scheme in which we asked IANA to
establish a registry of the ASN.1 identifiers for the mandatory to
implement and preferred algorithms for use.

This registry would then ideally have two initial entries as followed

SHA2 256bits  MANDATORY ...
SHA2 512bits  MANDATORY ...

Anyone who wants to use vanity crypto simply uses their own code
point. It is possible to use any algorithm people like in private
between consenting adults. But the registry only has to track the ones
that are either mentioned in a spec or have been added because there
is a consensus they should be supported.

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

Date: Sat, 8 Jan 2011 09:07:42 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Warren Kumari <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types."

Since this is precisely the type of change that KEYPROV was required
to make during IESG review, I would have to disagree.

We had specified our own password string prep, we were told we had to
use the existing string prep from another spec.

>From a process point of view I think that the chances of being told to
move from ASN.1 to a custom registry are essentially 0% while the
chance of being told to move from a custom registry to ASN.1 is
approximately 50:50%

Proliferating crypto registries imposes a cost on the whole
organization. It is making busy-work that is not necessary.

The point of working in the IETF as opposed to doing a roll your own
standards organization is meant to be building on the work of others.
ODI is designed to be a re-usable building block that can be used in
other places. It builds on ASN.1 which is itself a frequently used
building block that is essentially a standard in the crypto world.

So far I have given concrete benefits for my design choices. In
contrast the opposition has been 'well I prefer' without giving actual
benefits. The nearest we got was Paul's rather silly claim that ODI is
difficult to code (false) and the vague idea that having a registry
puts you in control.

On Fri, Jan 7, 2011 at 6:04 PM, Warren Kumari <[email-masked]> wrote:
> [ Resending, my mail server et the first one ]
> On Jan 7, 2011, at 6:52 AM, Phillip Hallam-Baker wrote:
>
>> ODI already describes a bare key mechanism in the CAA draft.
>>
>> We have not got a code point assigned yet, but I have asked the ADs abou=
t
>> it.
>>
>>
>> I am somewhat surprised that we settled on this issue to discuss first
>> since it affects the whole security area.
>>
>
> I'm sorry, but I disagree with you here. I assume we all agree that folk
> need to be able to tell what algorithm was used to generate
> 0x1234ABCD....212 ?
>
> How does it "affect the whole security area" if we decide "We'll ask the
> IANA to please keep track of the fact that 17 means AlgorithmX" or "We'll
> choose which Smurf looks most like the algorithm in question and use the
> ROT13 encoded version of his name to identify it"?
>
> As long as there are a base set of algorithms that implementations are
> expected to implement (and a means to get new algorithms added and old on=
es
> retired) and way to uniquely identify them, I fail to see how what the
> identifier is is such a big issue....
>
> W
>
>
>>
>>
>> On Thu, Jan 6, 2011 at 9:49 PM, Paul Wouters <[email-masked]> wrote:
>>>
>>> On Thu, 6 Jan 2011, Phillip Hallam-Baker wrote:
>>>
>>>> PKIX and S/MIME already use ASN.1 OIDS as algorithm identifiers.
>>>
>>> DANE should be usable for people without PKIX or ASN.1. If we get a TLS
>>> scheme for "bare public key" then we can't use OIDs for hash references=
.
>>>
>>> I'm in favour of our own registry, re-using where possible the same alg=
o
>>> numbers as in other dnssec registries.
>>>
>>> Paul
>>>
>>
>>
>>
>> --
>> Website: http://hallambaker.com/
>> _______________________________________________
>> keyassure mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/keyassure
>
> Life is a concentration camp. =A0You're stuck here and there's no way out=
 and
> you can only rage impotently against your persecutors.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Woody Allen
>
>
>
>

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

From: Jakob Schlyter <[email-masked]>
Date: Sat, 8 Jan 2011 08:41:39 +0100
To: [email-masked]
Subject: Re: [keyassure] I-D Action:draft-ietf-dane-protocol-01.txt

FYI, -01 contains a set of editorial edits and clarifications based on =
comments from the list.

	jakob

From: [email-masked]
To: [email-masked]
Date: Fri, 07 Jan 2011 23:30:02 -0800
Cc: [email-masked]
Subject: [keyassure] I-D Action:draft-ietf-dane-protocol-01.txt

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF.

	Title           : Using Secure DNS to Associate Certificates with Domain Names For TLS
	Author(s)       : P. Hoffman, J. Schlyter
	Filename        : draft-ietf-dane-protocol-01.txt
	Pages           : 10
	Date            : 2011-01-07

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body; name="draft-ietf-dane-protocol-01.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--

To: Phillip Hallam-Baker <[email-masked]>
Comments: In-reply-to Phillip Hallam-Baker <[email-masked]> message dated "Fri, 07 Jan 2011 13:19:59 -0500."
Date: Fri, 07 Jan 2011 19:23:22 -0800
From: John Gilmore <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types."

Let's be sure I understand the issue before jumping in.

Some people want to use a small numerical value, such as one octet, to
designate which hash or crypto algorithm is in use in a DNS record.
For example, the DNSKEY record contains a 1-octet "algorithm" field,
defined in RFC 4034.  The field's initial definition was in the RFC,
Appendix A.1, and subsequent assignments are done by IANA.  There are
reserved values for subsequent extension of the protocol by IETF, for
private extensions, and values reserved for the indefinite future.

Other people want to use an ASN.1 "OID" (or "ODR"), which is a
multibyte sequence of arbitrary length, each subsequence of which
defines a code point for allocating sub-code-points.  Sort of like a
domain name system for naming things in binary.  For example, (someone
come up with a field in an existing approved Standards Track RFC,
please).  This field would be restricted to have a known prefix of a
number of fixed byte values (specified in its RFC), and a set of known
suffixes, which are fixed byte strings, each of which would represent
an algorithm.  The organization identified by the initial prefix would
have the power to define additional suffixes that identify additional
algorithms, without amendment of the RFC and without further action
by IETF.

Is that really the issue?  If not, please edit and repost similar text
to provide a succinct 2-paragraph description of the issue.

	John Gilmore

From: Warren Kumari <[email-masked]>
Date: Fri, 7 Jan 2011 20:18:30 -0500
To: Paul Hoffman <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types."

Awesome, thanks for the clarity...

W

Warren Kumari
------
Please excuse typing, etc -- This was sent from a device with a tiny keyboar=
d.

On Jan 7, 2011, at 6:38 PM, Paul Hoffman <[email-masked]> wrote:

> On 1/7/11 3:12 PM, Warren Kumari wrote:
>=20
>> If possible I'd like us to try and separate the discussions of "Who gets
>> / how to get an identifier for an algorithm" from the question of how we
>> actually identify these -- while I realize that there are
>> interdependencies in the two issues and they are not fully separable,
>> I'd appreciate it if we can try and separate them as much as possible so
>> that it is easier to call consensus....
>=20
> Just to be clear, my preferences are:
>=20
> - Somewhat liberal policy for assigning: "RFC published", not "IETF consen=
sus" or "expert review"
>=20
> - two-byte integers for identifying, with 1000 reserved for private use
>=20
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Date: Fri, 07 Jan 2011 15:38:04 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types."

On 1/7/11 3:12 PM, Warren Kumari wrote:

> If possible I'd like us to try and separate the discussions of "Who gets
> / how to get an identifier for an algorithm" from the question of how we
> actually identify these -- while I realize that there are
> interdependencies in the two issues and they are not fully separable,
> I'd appreciate it if we can try and separate them as much as possible so
> that it is easier to call consensus....

Just to be clear, my preferences are:

- Somewhat liberal policy for assigning: "RFC published", not "IETF 
consensus" or "expert review"

- two-byte integers for identifying, with 1000 reserved for private use

From: Warren Kumari <[email-masked]>
To: Paul Wouters <[email-masked]>
Date: Fri, 7 Jan 2011 18:12:27 -0500
Cc: [email-masked], Phillip Hallam-Baker <[email-masked]>, Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types."

[  Top posting intentional -- this is a meta point and not a response  
to Paul Wouters' mail. ]
[ Resending, mail-server fun -- I've been passing outbound mail though  
SpamAssassin and spamd has started dying on messages with an (as yet  
unidentified) set of strings... ]

So far it looks to me like the group is leaning towards us having our  
own registry (and using simple ordinals from the registry to identify  
the hash / cert / algorithm), but I'd like to A: hear a few more  
voices and B: wait for Ondrej to be back.

If possible I'd like us to try and separate the discussions of "Who  
gets / how to get an identifier for an algorithm" from the question of  
how we actually identify these -- while I realize that there are  
interdependencies in the two issues and they are not fully separable,  
I'd appreciate it if we can try and separate them as much as possible  
so that it is easier to call consensus....

I'd also like to thank everyone who has contributed and to thank folk  
for staying on topic -- I know how tempting it is to go off on a  
tangent so thanks for staying focused and clearly stating preferences.

W
On Jan 7, 2011, at 11:16 AM, Paul Wouters wrote:

> On Fri, 7 Jan 2011, Phillip Hallam-Baker wrote:
>
>> ODI already describes a bare key mechanism in the CAA draft.
>
> CAA is about PKIX, Dane is not exlusively PKIX.
>
> I like my IANA registries as technology agnostic as possible, and  
> definitely not
> drag in ASN.1 for technologies that are not PKIX based.
>
> It is certainly in line with the other DNS(SEC) related IANA  
> registries to use
> simple octet based algorithm and type definitions.
>
> Paul
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

--
"Have you got any previous convictions?"

"Well, I dunno... I suppose I used to believe very firmly that a penny  
saved is a penny earned--"
-- Terry Pratchett

From: Warren Kumari <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 7 Jan 2011 18:04:48 -0500
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types."

[ Resending, my mail server et the first one ]
On Jan 7, 2011, at 6:52 AM, Phillip Hallam-Baker wrote:

> ODI already describes a bare key mechanism in the CAA draft.
>
> We have not got a code point assigned yet, but I have asked the ADs  
> about it.
>
>
> I am somewhat surprised that we settled on this issue to discuss first
> since it affects the whole security area.
>

I'm sorry, but I disagree with you here. I assume we all agree that  
folk need to be able to tell what algorithm was used to generate  
0x1234ABCD....212 ?

How does it "affect the whole security area" if we decide "We'll ask  
the IANA to please keep track of the fact that 17 means AlgorithmX" or  
"We'll choose which Smurf looks most like the algorithm in question  
and use the ROT13 encoded version of his name to identify it"?

As long as there are a base set of algorithms that implementations are  
expected to implement (and a means to get new algorithms added and old  
ones retired) and way to uniquely identify them, I fail to see how  
what the identifier is is such a big issue....

W

>
>
> On Thu, Jan 6, 2011 at 9:49 PM, Paul Wouters <[email-masked]>  
> wrote:
>> On Thu, 6 Jan 2011, Phillip Hallam-Baker wrote:
>>
>>> PKIX and S/MIME already use ASN.1 OIDS as algorithm identifiers.
>>
>> DANE should be usable for people without PKIX or ASN.1. If we get a  
>> TLS
>> scheme for "bare public key" then we can't use OIDs for hash  
>> references.
>>
>> I'm in favour of our own registry, re-using where possible the same  
>> algo
>> numbers as in other dnssec registries.
>>
>> Paul
>>
>
>
>
> -- 
> Website: http://hallambaker.com/
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Life is a concentration camp.  You're stuck here and there's no way  
out and you can only rage impotently against your persecutors.
                 -- Woody Allen

Date: Fri, 7 Jan 2011 13:19:59 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Wouters <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types."

The ODI spec is not tied to PKIX at all. It is expressly intended to
be totally generic. An ODI could reference a HTML document or a MIME
package.

Unless of course you know something about ODI that I do not.

On Fri, Jan 7, 2011 at 11:16 AM, Paul Wouters <[email-masked]> wrote:
> On Fri, 7 Jan 2011, Phillip Hallam-Baker wrote:
>
>> ODI already describes a bare key mechanism in the CAA draft.
>
> CAA is about PKIX, Dane is not exlusively PKIX.
>
> I like my IANA registries as technology agnostic as possible, and definitely
> not
> drag in ASN.1 for technologies that are not PKIX based.
>
> It is certainly in line with the other DNS(SEC) related IANA registries to
> use
> simple octet based algorithm and type definitions.
>
> Paul
>

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

From: Jakob Schlyter <[email-masked]>
Date: Fri, 7 Jan 2011 19:15:40 +0100
To: [email-masked]
Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types."

On 7 jan 2011, at 03.49, Paul Wouters wrote:

> I'm in favour of our own registry, re-using where possible the same algo
> numbers as in other dnssec registries.

+1

	jakob

Date: Fri, 7 Jan 2011 11:16:35 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types."

On Fri, 7 Jan 2011, Phillip Hallam-Baker wrote:

> ODI already describes a bare key mechanism in the CAA draft.

CAA is about PKIX, Dane is not exlusively PKIX.

I like my IANA registries as technology agnostic as possible, and definitely not
drag in ASN.1 for technologies that are not PKIX based.

It is certainly in line with the other DNS(SEC) related IANA registries to use
simple octet based algorithm and type definitions.

Paul

Date: Fri, 7 Jan 2011 06:52:28 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Wouters <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types."

ODI already describes a bare key mechanism in the CAA draft.

We have not got a code point assigned yet, but I have asked the ADs about it.

I am somewhat surprised that we settled on this issue to discuss first
since it affects the whole security area.

On Thu, Jan 6, 2011 at 9:49 PM, Paul Wouters <[email-masked]> wrote:
> On Thu, 6 Jan 2011, Phillip Hallam-Baker wrote:
>
>> PKIX and S/MIME already use ASN.1 OIDS as algorithm identifiers.
>
> DANE should be usable for people without PKIX or ASN.1. If we get a TLS
> scheme for "bare public key" then we can't use OIDs for hash references.
>
> I'm in favour of our own registry, re-using where possible the same algo
> numbers as in other dnssec registries.
>
> Paul
>

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

Date: Thu, 6 Jan 2011 21:49:42 -0500 (EST)
From: Paul Wouters <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types."

On Thu, 6 Jan 2011, Phillip Hallam-Baker wrote:

> PKIX and S/MIME already use ASN.1 OIDS as algorithm identifiers.

DANE should be usable for people without PKIX or ASN.1. If we get a TLS
scheme for "bare public key" then we can't use OIDs for hash references.

I'm in favour of our own registry, re-using where possible the same algo
numbers as in other dnssec registries.

Paul

Date: Thu, 06 Jan 2011 17:28:32 -0800
From: Paul Hoffman <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types."

On 1/6/11 5:05 PM, Phillip Hallam-Baker wrote:
> Working Groups have a limited lifespan. Which has created no end of
> problem in the security area as we have groups whose primary reason
> for continuing at the moment is maintaining the set of algorithms.

This doesn't match my experience. Can you name even one WG that has that 
as a primary reason for existing? For that matter, can you name one 
whose last charter was that?

> That type of maintenance is not something that IETF process was
> designed to support and is not cost free.

Correct. That's why we don't do it.

> Because a WG that is open
> for maintenance of algorithms tends to find other reasons for keeping
> itself busy.

Fully agree. That's why we don't do it.

> We already have S/MIME, TLS, IPSEC, DNSSEC and PKIX, choosing
> algorithms.

S/MINE is close. TLS hasn't done any algorithm choosing in a while; nor 
has IPsecME. DNSSEC just went through an unfortunate round of that while 
they did other work. PKIX hasn't done that in a while (although they are 
not doing anything I consider all that useful...).

> But its the same people making the choices on the basis of
> the same set of criteria.

If that were only true. Unfortunately, it is not.

> And at the end of the day that particular
> set of protocols really form a single family and should really be
> using a common set of algorithms.

But the IETF has refused to do that for over a decade, unfortunately.

> As far as interoperability is concerned, I think it is very simple:
> the group mandates an initial MUST support algorithm and later RFCs
> may update that requirement across the whole family of protocols.

Sounds good to me.

> If people want to use something that is not the mandated algorithm of
> an IETF consensus successor (as I expect SHA3 will prove) then they
> have to expect to pay the price of losing interoperability.

Correct.

> But the
> people who do vanity crypto know all about that from the start. That
> is their own funeral.

Correct (except if you are GOST...)

> The problem with vanity crypto is the implicit endorsement that comes
> from being assigned a code point, not the possible lack of
> interoperability. As people will have observed on the IETF mailing
> list, some people make the strangest claims on the basis of what
> appears in published RFCs.

They can make such claims without us. You are calling for a highly 
restricted registry that requires IETF consensus to change. This argues 
against your earlier point of the cost of doing reviews.

> Apart from the representatives of the government behind it, there is
> not one single person who has come to me and said that they are really
> keen to implement GHOST. I have however had people tell me that GHOST
> is an IETF sanctioned and endorsed algorithm on the basis of the
> assignment of a DNSSEC code point.

You probably meant "GOST" there, the Russian crypto standard. And I have 
heard from multiple vendors who want to implement GOST so that they can 
sell to the Russian market. Some are even keen to implement SEED for 
similar reasons in South Korea. And so on. The fact that they have not 
come to you to say this is somewhat off-topic.

> So the ODI/ODR scheme is quite explicitly and deliberately designed to
> deny that type of implicit endorsement. If people want to use any
> algorithm other than the standard set of algorithms they are on notice
> that they are on their own with regards to both interoperability and
> quality of the algorithm.

If the WG wants such restrictions, we don't need OIDs: we can just make 
entry to the registry as restrictive as we want. I propose liberalness 
so that it wastes less time arguing, but others like restrictiveness.

> PKIX and S/MIME already use ASN.1 OIDS as algorithm identifiers. I
> would like to see DNSSEC and TLS eventually take the same approach to
> specify non-mandatory algorithm suites.

Noted (although I have not seen your proposals to those WGs to do so).

Date: Thu, 6 Jan 2011 20:05:46 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types."

Working Groups have a limited lifespan. Which has created no end of
problem in the security area as we have groups whose primary reason
for continuing at the moment is maintaining the set of algorithms.

That type of maintenance is not something that IETF process was
designed to support and is not cost free. Because a WG that is open
for maintenance of algorithms tends to find other reasons for keeping
itself busy.

We already have S/MIME, TLS, IPSEC, DNSSEC and PKIX, choosing
algorithms. But its the same people making the choices on the basis of
the same set of criteria. And at the end of the day that particular
set of protocols really form a single family and should really be
using a common set of algorithms.

As far as interoperability is concerned, I think it is very simple:
the group mandates an initial MUST support algorithm and later RFCs
may update that requirement across the whole family of protocols.

If people want to use something that is not the mandated algorithm of
an IETF consensus successor (as I expect SHA3 will prove) then they
have to expect to pay the price of losing interoperability. But the
people who do vanity crypto know all about that from the start. That
is their own funeral.

The problem with vanity crypto is the implicit endorsement that comes
from being assigned a code point, not the possible lack of
interoperability. As people will have observed on the IETF mailing
list, some people make the strangest claims on the basis of what
appears in published RFCs.

Apart from the representatives of the government behind it, there is
not one single person who has come to me and said that they are really
keen to implement GHOST. I have however had people tell me that GHOST
is an IETF sanctioned and endorsed algorithm on the basis of the
assignment of a DNSSEC code point.

So the ODI/ODR scheme is quite explicitly and deliberately designed to
deny that type of implicit endorsement. If people want to use any
algorithm other than the standard set of algorithms they are on notice
that they are on their own with regards to both interoperability and
quality of the algorithm.

PKIX and S/MIME already use ASN.1 OIDS as algorithm identifiers. I
would like to see DNSSEC and TLS eventually take the same approach to
specify non-mandatory algorithm suites.

Date: Thu, 06 Jan 2011 10:00:05 -0800
From: Paul Hoffman <[email-masked]>
To: Matt McCutchen <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types."

On 1/6/11 9:39 AM, Matt McCutchen wrote:
> On Thu, 2011-01-06 at 08:37 -0800, Paul Hoffman wrote:
>> On 1/6/11 8:26 AM, Matt McCutchen wrote:
>>> On Thu, 2011-01-06 at 08:14 -0800, Paul Hoffman wrote:
>>> Sure.  So:
>>>
>>> Benefits of operating our own registry:
>>> - ?
>>
>> - Developers know how to interoperate with each other when they are
>> using the same hash algorithm
>
> What do you mean?  A hash algorithm is just a mathematical function, no
> matter where it is defined.  It's not as if anything extra has to be
> specified in order to use it with DANE.

Registries are for identifiers. How do you know that "17" means "SHA-1" 
and not "SHA-256"? You look it up in a registry.

> Be sure to count maintenance over time.

Ummm, how much maintenance do you think is needed for a registry? 
Someone proposes a new hash algorithm, we say "yes, here's your number", 
and don.

>> is probably worth the benefit of us being
>> sure that it contains what we want for first developers.
>
> (*) You are proposing that the registry constitute implicit advice about
> what algorithms developers should consider implementing beyond the
> mandatory ones.

No, I am *not*. Please don't put words in my mouth. I never said that.

> Alternatively, we could use a wide-open registry

Alternatively, we could (as I proposed earlier) use a registry with easy 
but not trivial registration and a bunch of pre-defined private use values.

> and
> give such advice elsewhere, or not give advice at all.

Fully agree.

> Assuming we give
> advice, I prefer the separation of purposes in the second approach, but
> it may still lead to vanity crypto trouble, in which case the advantage
> over operating our own registry would be lost.

Fully agree about the "advice elsewhere", but am open to what others 
might want. Different WGs in the IETF are wildly inconsistent on this.

What is "vanity crypto trouble"? Someone registers their vanity crypto 
algorithm in our registry: what is the problem?

>>> As Phill has pointed out
>>> (http://www.ietf.org/mail-archive/web/keyassure/current/msg01097.html),
>>> OIDs are not any harder to use than any other registry because any given
>>> application can just recognize the hard-coded prefixes for the
>>> algorithms it supports.
>>
>> "hard-coded prefixes" means "our own registry", by definition.
>
> How so?  Anyone can calculate the prefix for an OID without our
> involvement.

You do want interoperability, yes? If so, how would what you just 
proposed work?

>> We gain nothing by using OIDs
>
> Assuming we want a completely open registry, the OID registry is a
> popular one in which organizations can get their own subtrees (e.g., my
> university has one) and then allocate globally unique identifiers.

...and no one knows how to interoperate. Well, they will know because 
someone will make a registry-like system that says which OIDs means 
what, and now we have the worst of both worlds.

>> other than bytes of overhead
>
> It comes to about 20 bytes per record, and that will go down if full
> compression of DNS responses is ever implemented.  I think it's a small
> price to pay for the elegance, but this is subjective.

Quite. You seem to think that the problems that we have had in the PKIX 
world with muffed OIDs is worth the "elegance"; I disagree.

>> plus forcing developers to understand their encoding.
>
> Not really, whoever advocates the use of a given algorithm with DANE
> will publish all the information the developers need.

And all the developers will be able to understand the OID encoding rules 
given with no errors, of course.

From: Matt McCutchen <[email-masked]>
To: Paul Hoffman <[email-masked]>
Date: Thu, 06 Jan 2011 12:39:16 -0500
Cc: [email-masked]
Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types."

On Thu, 2011-01-06 at 08:37 -0800, Paul Hoffman wrote:
> On 1/6/11 8:26 AM, Matt McCutchen wrote:
> > On Thu, 2011-01-06 at 08:14 -0800, Paul Hoffman wrote:
> > Sure.  So:
> >
> > Benefits of operating our own registry:
> > - ?
> 
> - Developers know how to interoperate with each other when they are 
> using the same hash algorithm

What do you mean?  A hash algorithm is just a mathematical function, no
matter where it is defined.  It's not as if anything extra has to be
specified in order to use it with DANE.

> - When a developer sees a record with a value for the hash algorithm 
> that they don't know, that developer can quickly determine if he cares 
> enough to update his implementation.

See below (*)

> > Benefits of reusing another appropriate registry:

> > - We don't have to deal with political issues regarding "vanity crypto"
> > (http://www.ietf.org/mail-archive/web/keyassure/current/msg01108.html)
> 
> False: we are just exporting the problem to whomever is running the 
> registry we are using.

Indeed.  I said "we" meaning the DANE group.

> That is, I have no problem with using someone else's registry, but the 
> overhead of creating our own (Jakob and I spend 10 minutes writing an 
> IANA Considerations section)

Be sure to count maintenance over time.

> is probably worth the benefit of us being 
> sure that it contains what we want for first developers.

(*) You are proposing that the registry constitute implicit advice about
what algorithms developers should consider implementing beyond the
mandatory ones.  Alternatively, we could use a wide-open registry and
give such advice elsewhere, or not give advice at all.  Assuming we give
advice, I prefer the separation of purposes in the second approach, but
it may still lead to vanity crypto trouble, in which case the advantage
over operating our own registry would be lost.

> > As Phill has pointed out
> > (http://www.ietf.org/mail-archive/web/keyassure/current/msg01097.html),
> > OIDs are not any harder to use than any other registry because any given
> > application can just recognize the hard-coded prefixes for the
> > algorithms it supports.
> 
> "hard-coded prefixes" means "our own registry", by definition.

How so?  Anyone can calculate the prefix for an OID without our
involvement.

> We gain nothing by using OIDs

Assuming we want a completely open registry, the OID registry is a
popular one in which organizations can get their own subtrees (e.g., my
university has one) and then allocate globally unique identifiers.

> other than bytes of overhead

It comes to about 20 bytes per record, and that will go down if full
compression of DNS responses is ever implemented.  I think it's a small
price to pay for the elegance, but this is subjective.

> plus forcing developers to understand their encoding.

Not really, whoever advocates the use of a given algorithm with DANE
will publish all the information the developers need.

-- 
Matt

Date: Thu, 06 Jan 2011 08:37:02 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types."

On 1/6/11 8:26 AM, Matt McCutchen wrote:
> On Thu, 2011-01-06 at 08:14 -0800, Paul Hoffman wrote:
> Sure.  So:
>
> Benefits of operating our own registry:
> - ?

- Developers know how to interoperate with each other when they are 
using the same hash algorithm

- When a developer sees a record with a value for the hash algorithm 
that they don't know, that developer can quickly determine if he cares 
enough to update his implementation.

> Benefits of reusing another appropriate registry:
> - Less work for us and for registrants (though maybe not by much, you
> have said)

True.

> - We don't have to deal with political issues regarding "vanity crypto"
> (http://www.ietf.org/mail-archive/web/keyassure/current/msg01108.html)

False: we are just exporting the problem to whomever is running the 
registry we are using.

That is, I have no problem with using someone else's registry, but the 
overhead of creating our own (Jakob and I spend 10 minutes writing an 
IANA Considerations section) is probably worth the benefit of us being 
sure that it contains what we want for first developers.

> As Phill has pointed out
> (http://www.ietf.org/mail-archive/web/keyassure/current/msg01097.html),
> OIDs are not any harder to use than any other registry because any given
> application can just recognize the hard-coded prefixes for the
> algorithms it supports.

"hard-coded prefixes" means "our own registry", by definition. We gain 
nothing by using OIDs other than bytes of overhead plus forcing 
developers to understand their encoding.

Date: Thu, 6 Jan 2011 16:35:47 +0000
From: Ben Laurie <[email-masked]>
To: Matt McCutchen <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types."

On 6 January 2011 16:31, Matt McCutchen <[email-masked]> wrote:
> On Thu, 2011-01-06 at 16:20 +0000, Ben Laurie wrote:
>> On 6 January 2011 16:08, Matt McCutchen <[email-masked]> wrote:
>> > I don't think this is a valid argument, in light of Phill's previous
>> > comments on the subject. =A0Why would we have to choose which entries =
are
>> > valid, and not just state that any entry representing a hash algorithm
>> > is potentially valid and let each implementation choose which ones to
>> > support?
>>
>> Someone has to choose which ones are actually valid - you can't punt
>> to implementations, because then interop is impossible.
>
> The mandatory algorithms provide interop. =A0If some parties wish to use
> another algorithm, it is their responsibility to make sure the peer
> supports it.

This is how you end up with people using CRC-32 as a cryptographic
hash. I don't think it is acceptable to burden developers with such
decisions.

I do agree that a route needs to be provided for those who want to do
their own thing, though. But it must be clear that they're doing their
own thing.

Unless there's a registry which has appropriate policies around
strength already in existence, that means its our problem to define
what is OK to use and what is not.

From: Matt McCutchen <[email-masked]>
To: Ben Laurie <[email-masked]>
Date: Thu, 06 Jan 2011 11:31:06 -0500
Cc: [email-masked]
Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types."

On Thu, 2011-01-06 at 16:20 +0000, Ben Laurie wrote:
> On 6 January 2011 16:08, Matt McCutchen <[email-masked]> wrote:
> > I don't think this is a valid argument, in light of Phill's previous
> > comments on the subject.  Why would we have to choose which entries are
> > valid, and not just state that any entry representing a hash algorithm
> > is potentially valid and let each implementation choose which ones to
> > support?
> 
> Someone has to choose which ones are actually valid - you can't punt
> to implementations, because then interop is impossible.

The mandatory algorithms provide interop.  If some parties wish to use
another algorithm, it is their responsibility to make sure the peer
supports it.

-- 
Matt

From: Matt McCutchen <[email-masked]>
To: Paul Hoffman <[email-masked]>
Date: Thu, 06 Jan 2011 11:26:52 -0500
Cc: [email-masked]
Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types."

On Thu, 2011-01-06 at 08:14 -0800, Paul Hoffman wrote:
> On 1/6/11 8:08 AM, Matt McCutchen wrote:
> > On Thu, 2011-01-06 at 15:56 +0000, Ben Laurie wrote:
> 
> >> I vote for our own registry, the reason being that we will have to, in
> >> any case, choose which entries in someone else's are valid, and which
> >> are mandatory. By the time we've specified that we might as well
> >> allocate our own identifiers, too.
> >
> > I don't think this is a valid argument, in light of Phill's previous
> > comments on the subject.  Why would we have to choose which entries are
> > valid, and not just state that any entry representing a hash algorithm
> > is potentially valid and let each implementation choose which ones to
> > support?
> 
> If our registry (a) is easy for someone to add to and (b) has plenty of 
> private use values pre-allocated, "we" would not have to choose which 
> entries are valid. Regardless, implementations would choose which ones 
> to support. Someone might make an applicability profile (like has just 
> been done in the DNSEXT WG for DNSSEC), and someone else might make a 
> different profile.

Sure.  So:

Benefits of operating our own registry:
- ?

Benefits of reusing another appropriate registry:
- Less work for us and for registrants (though maybe not by much, you
have said)
- We don't have to deal with political issues regarding "vanity crypto"
(http://www.ietf.org/mail-archive/web/keyassure/current/msg01108.html)

As Phill has pointed out
(http://www.ietf.org/mail-archive/web/keyassure/current/msg01097.html),
OIDs are not any harder to use than any other registry because any given
application can just recognize the hard-coded prefixes for the
algorithms it supports.

-- 
Matt

Date: Thu, 6 Jan 2011 16:20:11 +0000
From: Ben Laurie <[email-masked]>
To: Matt McCutchen <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types."

On 6 January 2011 16:08, Matt McCutchen <[email-masked]> wrote:
> On Thu, 2011-01-06 at 15:56 +0000, Ben Laurie wrote:
>> On 5 January 2011 20:00, Warren Kumari <[email-masked]> wrote:
>> > Matt will be adding additional issues to the tracker but for now can w=
e try
>> > and take a stab at #4 -- http://trac.tools.ietf.org/wg/dane/trac/ticke=
t/4 ?
>> > Hopefully this will be one of the easier / less controversial issues t=
o
>> > address, and we can quickly wrap it up and move on...
>> >
>> > Please excuse the poor quality of the description -- the issue was cre=
ated
>> > from the thread: "Object Digest Reference" =A0(started here:
>> > http://www.ietf.org/mail-archive/web/keyassure/current/msg01084.html) =
-- as
>> > with many of our threads this went off the rails and didn't come to cl=
ear
>> > consensus.
>> > I'd like us to revisit this and decide on a means of identifying what =
the
>> > hash / =A0cert type are.
>>
>> It seems to me there's a simplifying decision we can take, namely: our
>> own registry or someone else's? If we choose our own, then a lot of
>> pointless debate about which someone else can be avoided.
>>
>> I vote for our own registry, the reason being that we will have to, in
>> any case, choose which entries in someone else's are valid, and which
>> are mandatory. By the time we've specified that we might as well
>> allocate our own identifiers, too.
>
> I don't think this is a valid argument, in light of Phill's previous
> comments on the subject. =A0Why would we have to choose which entries are
> valid, and not just state that any entry representing a hash algorithm
> is potentially valid and let each implementation choose which ones to
> support?

Someone has to choose which ones are actually valid - you can't punt
to implementations, because then interop is impossible.

Date: Thu, 06 Jan 2011 08:14:35 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types."

On 1/6/11 8:08 AM, Matt McCutchen wrote:
> On Thu, 2011-01-06 at 15:56 +0000, Ben Laurie wrote:

>> I vote for our own registry, the reason being that we will have to, in
>> any case, choose which entries in someone else's are valid, and which
>> are mandatory. By the time we've specified that we might as well
>> allocate our own identifiers, too.
>
> I don't think this is a valid argument, in light of Phill's previous
> comments on the subject.  Why would we have to choose which entries are
> valid, and not just state that any entry representing a hash algorithm
> is potentially valid and let each implementation choose which ones to
> support?

If our registry (a) is easy for someone to add to and (b) has plenty of 
private use values pre-allocated, "we" would not have to choose which 
entries are valid. Regardless, implementations would choose which ones 
to support. Someone might make an applicability profile (like has just 
been done in the DNSEXT WG for DNSSEC), and someone else might make a 
different profile.

Date: Thu, 06 Jan 2011 08:11:57 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types."

On 1/6/11 7:56 AM, Ben Laurie wrote:

> It seems to me there's a simplifying decision we can take, namely: our
> own registry or someone else's? If we choose our own, then a lot of
> pointless debate about which someone else can be avoided.
>
> I vote for our own registry, the reason being that we will have to, in
> any case, choose which entries in someone else's are valid, and which
> are mandatory. By the time we've specified that we might as well
> allocate our own identifiers, too.

+1

From: Matt McCutchen <[email-masked]>
To: Ben Laurie <[email-masked]>
Date: Thu, 06 Jan 2011 11:08:18 -0500
Cc: [email-masked]
Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types."

On Thu, 2011-01-06 at 15:56 +0000, Ben Laurie wrote:
> On 5 January 2011 20:00, Warren Kumari <[email-masked]> wrote:
> > Matt will be adding additional issues to the tracker but for now can we try
> > and take a stab at #4 -- http://trac.tools.ietf.org/wg/dane/trac/ticket/4 ?
> > Hopefully this will be one of the easier / less controversial issues to
> > address, and we can quickly wrap it up and move on...
> >
> > Please excuse the poor quality of the description -- the issue was created
> > from the thread: "Object Digest Reference"  (started here:
> > http://www.ietf.org/mail-archive/web/keyassure/current/msg01084.html) -- as
> > with many of our threads this went off the rails and didn't come to clear
> > consensus.
> > I'd like us to revisit this and decide on a means of identifying what the
> > hash /  cert type are.
> 
> It seems to me there's a simplifying decision we can take, namely: our
> own registry or someone else's? If we choose our own, then a lot of
> pointless debate about which someone else can be avoided.
> 
> I vote for our own registry, the reason being that we will have to, in
> any case, choose which entries in someone else's are valid, and which
> are mandatory. By the time we've specified that we might as well
> allocate our own identifiers, too.

I don't think this is a valid argument, in light of Phill's previous
comments on the subject.  Why would we have to choose which entries are
valid, and not just state that any entry representing a hash algorithm
is potentially valid and let each implementation choose which ones to
support?

-- 
Matt

Date: Thu, 6 Jan 2011 15:56:21 +0000
From: Ben Laurie <[email-masked]>
To: Warren Kumari <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types."

On 5 January 2011 20:00, Warren Kumari <[email-masked]> wrote:
> Matt will be adding additional issues to the tracker but for now can we t=
ry
> and take a stab at #4 -- http://trac.tools.ietf.org/wg/dane/trac/ticket/4=
 ?
> Hopefully this will be one of the easier / less controversial issues to
> address, and we can quickly wrap it up and move on...
>
> Please excuse the poor quality of the description -- the issue was create=
d
> from the thread: "Object Digest Reference" =A0(started here:
> http://www.ietf.org/mail-archive/web/keyassure/current/msg01084.html) -- =
as
> with many of our threads this went off the rails and didn't come to clear
> consensus.
> I'd like us to revisit this and decide on a means of identifying what the
> hash / =A0cert type are.

It seems to me there's a simplifying decision we can take, namely: our
own registry or someone else's? If we choose our own, then a lot of
pointless debate about which someone else can be avoided.

I vote for our own registry, the reason being that we will have to, in
any case, choose which entries in someone else's are valid, and which
are mandatory. By the time we've specified that we might as well
allocate our own identifiers, too.

Cheers,

Ben.

From: Warren Kumari <[email-masked]>
To: [email-masked]
Date: Wed, 5 Jan 2011 15:00:20 -0500
Subject: [keyassure] Starting to work through the issues: Issue #4 -- "Identification of hash and cert types."

Hello all,

I'd like us to start working through the issues that we have listed in  
the tracker (http://trac.tools.ietf.org/wg/dane/trac/report/1) -- this  
will hopefully allow us to actually come to some consensus and avoid  
having the same set of discussions over and over again...

Matt will be adding additional issues to the tracker but for now can  
we try and take a stab at #4 -- http://trac.tools.ietf.org/wg/dane/trac/ticket/4 
  ? Hopefully this will be one of the easier / less controversial  
issues to address, and we can quickly wrap it up and move on...

Please excuse the poor quality of the description -- the issue was  
created from the thread: "Object Digest Reference"  (started here: http://www.ietf.org/mail-archive/web/keyassure/current/msg01084.html) 
  -- as with many of our threads this went off the rails and didn't  
come to clear consensus.
I'd like us to revisit this and decide on a means of identifying what  
the hash /  cert type are.

W

--
"Real children don't go hoppity-skip unless they are on drugs."

     -- Susan, the ultimate sensible governess (Terry Pratchett,  
Hogfather)

From: Warren Kumari <[email-masked]>
To: [email-masked]
Date: Tue, 4 Jan 2011 18:46:17 -0500
Subject: [keyassure] Apology...

Hi all,

I'd just quickly like to apologize for not having been nearly as  
involved recently as I should have been -- I got sidetracked with  
$dayjob (and other things) and haven't been giving DANE as much  
attention as it deserves.

I have almost managed to clean off my plate (and dig out from under a  
mountain of mail) and should be able to devote more time soon...

Apologies again,
W

--
"Let's just say that if complete and utter chaos was lightning, he'd  
be the sort to stand on a hilltop in a thunderstorm wearing wet copper  
armour and shouting 'All gods are bastards'."

     -- Rincewind discussing Twoflower (Terry Pratchett, The Colour of  
Magic)