Subject: [keyassure] Issues that no longer issues?

From: Warren Kumari <[email-masked]>
Date: Sun, 20 Mar 2011 14:57:36 -0400

Hi there all,

It seems that there are a bunch of issues that are not anymore....

Issue #9: Self-Signed Certificates --- Addressed in the current version of the draft.

Issue #11: Hash Function Strength --- Addressed in the current version of the draft, was discussed (and resolved) in issue #21.

Issue #20: Change the format of the two fields to have fewer certificate types ---- Resolved quite a while ago, and discussed in issue #21. We used different numbers / algorithms.

Issue #5 is out of scope for the current draft, I think we'll close it and it can be reopened for a new draft that extends this sometime in the future....

Seeing as there are done, we are planning on closing them (unless we hear any objections, preferably with text!).
I'm about to get on a plane for Prague, so don't expect fast replies....

W

---

From: Paul Wouters <[email-masked]>
Date: Sun, 20 Mar 2011 19:54:49 -0400 (EDT)

> Issue #20: Change the format of the two fields to have fewer certificate types ---- Resolved quite a while ago, and discussed in issue #21. We used different numbers / algorithms.

John Gilmore and me looked at TLS bare public key support and we realised
that it requires no TLS protocol changes if we use RFC6066 trusted_ca_keys
set to pre-agreed(0) in the client's extended hello options,meaning the
server will supress sending any PKI certs.

This means we will want to add bare public key into this draft, as it
is the only document that would require changes for bare public key to work.

It would require specifying the various bare public key formats (likely
re-use the format from PKIX pubkey field, but use base64 encoding instead
of DER encoding)

This would also require a few textual changes in the draft where it now
states "certificate", as we could be using either a certificate or a bare
public key.

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 20 Mar 2011 17:13:11 -0700

> server will supress sending any PKI certs.

The definition in RFC 6066 for pre-agreed is "no CA root key identity supplied".  Later in the section it says "The option to include no CA root keys is included to allow the client to indicate possession of some pre-defined set of CA root keys." Note the use of "CA root key" in both of those.

> is the only document that would require changes for bare public key to work.

If you want to add bare CA keys, that's fine, but I suspect that you actually want to add bare end entity keys, and RFC 6066 doesn't allow that.

> states "certificate", as we could be using either a certificate or a bare

If you are truly interested in bare CA keys, we can make that change if the WG wants. However, I have heard no interest in bare CA keys from anyone (including you) before today; all of the discussion of bare keys was for end entity keys. For that, I believe you actually need to write an extension to TLS.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Sun, 20 Mar 2011 20:40:35 -0400 (EDT)

> The definition in RFC 6066 for pre-agreed is "no CA root key identity supplied".  Later in the section it says "The option to include no CA root keys is included to allow the client to indicate pos…

Yes. The predefined set of (required) CA root keys is the empty set. But whether
it is a preloaded set from Versign or a preloaded set from Komodo, or a preloaded
empty set is irrelevant to the server receiving a TLS trusted_ca_keys extended option.

> If you want to add bare CA keys, that's fine, but I suspect that you actually want to add bare end entity keys, and RFC 6066 doesn't allow that.

That difference is muddy anyway, isn't it? Isn't a self-signed certificate a CA?

> If you are truly interested in bare CA keys, we can make that change if the WG wants. However, I have heard no interest in bare CA keys from anyone (including you) before today; all of the discussi…

We are talking about end entity keys.

The client sends its hello message saying "I have all the CA root trust
anchors I need from pre-agreement".  Whether that means it got information
from DNSSEC/DANE or elsewhere does not matter. What matters is, is that
the client can start the TLS handshake without the server sending any
PKIX certs.

It can already accomplish this without using trusted_ca_keys, or if the
server does not support the 6066 extension to supress sending its CA
cert chain(s).

Whether the client does this because it is "memory starved" (as per 6066)
or because it obtained trust in the server pubkey via another set of
non-CA trust anchors does not really matter. All the server needs to
know is that it can ommit sending a giant blob of PKIX to the client.

The *only* thing needed for bare public keys to work is that the client
does the DNS lookup for the bare key using DANE. No TLS protocol change
is needed. Therefor, all we need is a method for specifying bare public
keys in DNS, for which my previous email proposed a structure.

Yes, we could make a TLS extension for "public_key" that works like server_name,
or we could extend server_name to take a new type "public_key", but there
is simply no need for such an extension, as the server does not need this
information and cannot do anyting with this information that is not already
covered with trusted_ca_keys.

Paul

---

From: Matt McCutchen <[email-masked]>
Date: Sun, 20 Mar 2011 21:06:26 -0400

> That difference is muddy anyway, isn't it? Isn't a self-signed certificate a CA?

It is not used to sign any certificates (except itself, but that is
irrelevant because no one ever relies on the self signature), so no.

> the client can start the TLS handshake without the server sending any

How does this look at the message level?  The server sends a Certificate
message containing a zero-length sequence of certificates?  This is not
at all what is envisioned by RFC 6066.  To say that your scheme involves
no TLS protocol changes is a little misleading: you are using existing
messages but dramatically repurposing them.  IMO, this scheme should be
standardized and subjected to the attendant level of scrutiny before we
consider supporting it in DANE.

-- 
Matt

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 20 Mar 2011 18:10:21 -0700

On Mar 20, 2011, at 5:40 PM, Paul Wouters wrote:

> That difference is muddy anyway, isn't it?

No, not at all. Please see draft-ietf-dane-protocol-06, where Jakob and I go into this in detail, including quoting from the PKIX standard.

> Isn't a self-signed certificate a CA?

Not unless it sets the right bits; again, see the current draft.

> We are talking about end entity keys.

...which is not what RFC 6066 is talking about.

> the client can start the TLS handshake without the server sending any

How do you get this from Section 7.4.2 of RFC 5246? Many sentences in that section indicate that the server must send its PKIX certificate. I believe the only way around that is to define a certificate type of "bare key".

> server does not support the 6066 extension to supress sending its CA

Not and be compatible with TLS 1.2, I believe.

> covered with trusted_ca_keys.

We fully disagree about what the TLS 1.2 spec says. I'm happy to be wrong about this if folks in the TLS WG agree with you, but your interpretation seems novel, to say the least. I understand you not wanting to spend the effort to do this properly with an extension to TLS; however, this WG cannot just say that we don't care about the requirements in TLS 1.2.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Sun, 20 Mar 2011 22:18:22 -0400 (EDT)

> irrelevant because no one ever relies on the self signature), so no.

So if instead, I would send a list of 1 trusted_root_ca with the selfsigned
Ca, then thatwould be "in spirit" or 6066?

> message containing a zero-length sequence of certificates?

No, it sends an Hello TLS extension of type "trusted_ca_keys" containing
in its "extension_data" a 'struct' TrustedAuthorities containing one
"TrustedAuthority" that has an "IdentifierType" of "agreed" which is
'struct {}'

>  This is not
> messages but dramatically repurposing them.

Not at all! According to 6066:

6. Trusted CA Indication

    Constrained clients that, due to memory limitations, possess only a
    small number of CA root keys may wish to indicate to servers which
    root keys they possess, in order to avoid repeated handshake
    failures.

    In order to indicate which CA root keys they possess, clients MAY
    include an extension of type "trusted_ca_keys" in the (extended)
    client hello.  The "extension_data" field of this extension SHALL
    contain "TrustedAuthorities" where:

       struct {
           TrustedAuthority trusted_authorities_list<0..2^16-1>;
       } TrustedAuthorities;

       struct {
           IdentifierType identifier_type;
           select (identifier_type) {
               case pre_agreed: struct {};
               case key_sha1_hash: SHA1Hash;
               case x509_name: DistinguishedName;
               case cert_sha1_hash: SHA1Hash;
           } identifier;
       } TrustedAuthority;

       enum {
           pre_agreed(0), key_sha1_hash(1), x509_name(2),
           cert_sha1_hash(3), (255)
       } IdentifierType;

       opaque DistinguishedName<1..2^16-1>;

    Here, "TrustedAuthorities" provides a list of CA root key identifiers
    that the client possesses.  Each CA root key is identified via
    either:

    -  "pre_agreed": no CA root key identity supplied.

> IMO, this scheme should be

The only thing that is different here is that I am using a client contraint
that is different from the examples listed at the start of section 6. Was that
list supposed to be an all encompassing list?

I did not even add "pre_agreed". It is already there!

Paul

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 21 Mar 2011 08:37:01 -0700

> We fully disagree about what the TLS 1.2 spec says. I'm happy to be wrong about this if folks in the TLS WG agree with you, but your interpretation seems novel, to say the least. I understand you n…

[Speaking as an individual]
IMO the requirements of 5246 are fairly clear here:

7.4.2.  Server Certificate

   When this message will be sent:

      The server MUST send a Certificate message whenever the agreed-
      upon key exchange method uses certificates for authentication
      (this includes all key exchange methods defined in this document
      except DH_anon).  This message will always immediately follow the
      ServerHello message.

   Meaning of this message:

      This message conveys the server's certificate chain to the client.

      The certificate MUST be appropriate for the negotiated cipher
      suite's key exchange algorithm and any negotiated extensions.

   Structure of this message:

      opaque ASN.1Cert<1..2^24-1>;

      struct {
          ASN.1Cert certificate_list<0..2^24-1>;
      } Certificate;

   certificate_list
      This is a sequence (chain) of certificates.  The sender's
      certificate MUST come first in the list.  Each following
      certificate MUST directly certify the one preceding it.  Because
      certificate validation requires that root keys be distributed
      independently, the self-signed certificate that specifies the root
      certificate authority MAY be omitted from the chain, under the
      assumption that the remote end must already possess it in order to
      validate it in any case.

In other words, when using any of the ordinarily certificate-based cipher suites
(i.e., all the ones that everyone actually uses), it is not
permissible either to omit the
Certificate message or to have it be empty. This is not to say, of
course, that you
could not design an extension which would modify this behavior, but in the
absence of such an extension, any server which does not send its certificate
would not comply with RFC 5246.

[Speaking as TLS WG Chair]
An extension along the lines indicated would change basic properties of TLS and
IMO would need to go through the TLS WG, and certainly is outside the remit
of this WG.

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Mon, 21 Mar 2011 16:51:05 +0100 (MET)

> Not at all! According to 6066:
 
The part most relevant to this discussion is this:

   Servers that receive a client hello containing the "trusted_ca_keys"
   extension MAY use the information contained in the extension to guide
   their selection of an appropriate certificate chain to return to the
   client.  In this event, the server SHALL include an extension of type
   "trusted_ca_keys" in the (extended) server hello.  The
   "extension_data" field of this extension SHALL be empty.

This TLS extension is merely a hint, never a requirement.

In the currently defined TLS protocol (and additional cipher suites
documents) the Server Certificate handshake message is always sent,
except for (1) anonymous cipher suites (dh_anon), or (2) TLS-PSK
cipher suites (pre-shared keys, such as rfc4279).

See http://tools.ietf.org/html/rfc5246#section-7.4.2

which part of the "MUST send" is unclear to you?

What might be slighly misleading in that section is that it
defines a handshake message that is used in two situations
(Server Certificate and Client Certificate) and the semantics of an
empty Certificate handshake message is only defined for the
"Client Certificate" handshake message, but _NOT_ for the Server Certificate
handshake message.

-Martin

---

From: Ondřej Surý <[email-masked]>
Date: Mon, 21 Mar 2011 18:31:32 +0100

> Seeing as there are done, we are planning on closing them (unless we hear any objections, preferably with text!).

Just a friendly reminder, with Warren on the plain, I plan to close 
those issues with no comments (#9, #11 and #5) on tuesday/wednesday, so 
we have a cleaner table during the meeting.

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: Stephen Kent <[email-masked]>
Date: Mon, 21 Mar 2011 14:33:32 -0400

At 9:06 PM -0400 3/20/11, Matt McCutchen wrote:
>>  > If you want to add bare CA keys, that's fine, but I suspect that 
>>you actually want to add bare end entity keys, and RFC 6066 doesn't 
>>allow that.
>>

as per the various 580 cites that Paul H. has put in the most recent version
of the DANE spec, an SS cert is a CA cert, irrespective of whether it is
used to verify sigs on other certs.  The one slightly "muddy" 
situation is when an SS cert is used to convey a trust anchor.  A TA 
is a CA in the usual case, but the cert is just a convenient 
container to convey the TA data, so there are no checks (in 5280) 
that are mandated for this case.

Steve

---

From: Paul Wouters <[email-masked]>
Date: Mon, 21 Mar 2011 15:57:04 -0400 (EDT)

> would not comply with RFC 5246.

That extension seems to already have been made in RFC 6066.

> IMO would need to go through the TLS WG, and certainly is outside the remit

Didn't 6066 go through that process?

Should an errata be issued stating that RFC6066, section 6,
TrustedAuthority case "pre_agreed" is deprecated?

I do feel one of these choices has to be made. Either pre_agreed is a valid part of
TLS, or it is not. It cannot be both.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Mon, 21 Mar 2011 16:02:04 -0400 (EDT)

> "Client Certificate" handshake message, but _NOT_ for the Server Certificate

Section 7 of 5246 shows me:

     Client                                               Server

       ClientHello                  -------->
                                                       ServerHello
                                                      Certificate*
                                                ServerKeyExchange*
                                               CertificateRequest*
                                    <--------      ServerHelloDone
       Certificate*
       ClientKeyExchange
       CertificateVerify*
       [ChangeCipherSpec]
       Finished                     -------->
                                                [ChangeCipherSpec]
                                    <--------             Finished
       Application Data             <------->     Application Data

* Indicates optional or situation-dependent messages that are not
    always sent.

To me this seems to say that "Certificate*" on the server side could
be omitted in situation-dependent messages.

Paul

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 21 Mar 2011 13:11:16 -0700

> That extension seems to already have been made in RFC 6066.

In my opinion, RFC 6066 does not relax the restriction to send Certificates
nor does it relax the restriction that it contain the EE's certificate.

> Didn't 6066 go through that process?

Yes.

> TLS, or it is not. It cannot be both.

It is a valid part of TLS, but it is not designed to be used for the purpose you
indicate. I think that's quite clear from the context of 6066.

Obviously, nobody is going to stop you from doing whatever you want
in your implementation. However, if you want to have an IETF standards
track document that specifies that a TLS stack behave in a certain way then
it would be good for that to match the TLS WG's understanding of what the
documents say.

-Ekr

---

From: Matt McCutchen <[email-masked]>
Date: Mon, 21 Mar 2011 16:21:03 -0400

> be omitted in situation-dependent messages.

Yes, as described elsewhere in the standard.  It doesn't mean that you
can omit the Certificate message whenever you please.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Mon, 21 Mar 2011 16:29:30 -0400

For completeness (I think the main points have been also made
elsewhere):

> "TrustedAuthority" that has an "IdentifierType" of "agreed" which is

I understand that part.  I was asking about the "without the server
sending any PKIX certs" part.

>     -  "pre_agreed": no CA root key identity supplied.

"pre_agreed" stands for a set of one or more trust anchors that is
already known to the other side in the context of a particular
deployment.  Hence, bandwidth is saved by not sending identifiers for
the trust anchors.  Using "pre_agreed" to tell the server it can skip
sending a certificate chain is not envisioned by RFC 6066.

> that is different from the examples listed at the start of section 6.

What is different is that the server does not send a certificate chain.

-- 
Matt

---

From: Paul Wouters <[email-masked]>
Date: Mon, 21 Mar 2011 16:39:01 -0400 (EDT)

On Mon, 21 Mar 2011, Matt McCutchen wrote:

> the trust anchors.

which is the case of the TLS client has gotten the public key from DNS using
DANE. But it does not matter how the client obtained the trust. The client
is telling the server it has all the required trust anchors, and that the
server can ommit sending them over. That is exactly what the option is meant
to do.

I can see how we would want the TLS client behaviour to be written down in a
standards document, and I am more then happy to do so. But adding a new
TLS client/server extension is silly. it would have the exact same semantics
as "pre_agreed", as I don't think we would want to state that the "new pre-agreed"
can only be used if the client has used DANE to validate the key. This is like
writing separate laws for email spam and fax spam....

> Using "pre_agreed" to tell the server it can skip

On the contrary, that is *exactly* what the goal of 6066 is. It specifies as
reason "memory starved clients" and "reducing bandwidth", but why is that
list treated as an exclusive list?

> What is different is that the server does not send a certificate chain.

Which is exactly what happens on a TLS client preloaded with the root CA of the
server, in a low memory or low bandwidth situation sending the "pre_agreed"
option. Just because for bare public keys the client has a different format (or
method) of getting that information should be irrelevant to 6066.

Paul

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 21 Mar 2011 13:49:39 -0700

On Mon, Mar 21, 2011 at 1:39 PM, Paul Wouters <[email-masked]> wrote:
> server can ommit sending them over.

There's a difference between end-entity certificates and trust anchors, and the
RFC 6066 text simply does not say that you can omit the EE cert.

> That is exactly what the option is meant
> to do.

I'm not sure it makes sense to get into questions of textual hermeneutics here,
but I don't recall anyone suggesting the omission of the EE cert while this
draft was under discussion, so I don't think this assertion is very convincing.

> standards document, and I am more then happy to do so.

In my opinion this is what would be required, and that document would need to
be standardized by the TLS WG.

> But adding a new

That's for the TLS WG to decide.

> list treated as an exclusive list?

See above.

-Ekr

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 21 Mar 2011 17:05:26 -0400

As a meta point here, the only point to doing work in IETF is to 1) get buy
in from people in your working group and 2) get buy in from people in other
working groups.

Trying to use DANE as a means of eliminating X.509 from TLS is a non-starter
as far as I am concerned. If this group is not going to listen to the TLS WG
or the PKIX WG there is not a lot of point in it being here. Its like going
to the Bayreuth festival and not wanting to go to opera.

Trying to modify Internet protocols is like trying to change the wheels on a
bike while the rider is still riding it (yeah, people really do that for a
job).

Trying to modify Internet security protocols is like playing a game of Jenga
on the rider's helmet with the guy trying to change his wheel.

What might appear to be a minor change to the protocol can have significant
and unpredictable results throughout the system.

The way we avoid such results is mostly to avoid changes that do not have a
very very good justification.

Not liking ASN.1 is not a justification in my view.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 21 Mar 2011 17:34:11 -0400 (EDT)

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

> As a meta point here, the only point to doing work in IETF is to 1) get buy in from people in your working group and 2)
> get buy in from people in other working groups.

Which is why i'm here instead of jumping on the Kaminsky TXT band wagon.

> Trying to use DANE as a means of eliminating X.509 from TLS is a non-starter as far as I am concerned.

That has been loud and clear. However, it does not mean others should stop trying to innovate and move forward.

[remainder vague generalities snipped]

---

From: Paul Wouters <[email-masked]>
Date: Mon, 21 Mar 2011 17:40:52 -0400 (EDT)

> RFC 6066 text simply does not say that you can omit the EE cert.

Thank you for pointing this out. Only now I understand what the objection
is. Rereading 6066, it does seem to indicate the EE cert was not meant
to be omitted, though the handshake diagram in 5246 seems to suggest it
can be omitted. I will do some more re-reading of 5246.

> be standardized by the TLS WG.

Okay.

Thanks,

Paul

---

From: Martin Rex <[email-masked]>
Date: Mon, 21 Mar 2011 22:42:17 +0100 (MET)

> list treated as an exclusive list?

The real purpose of rfc6066 is really only what the last paragraph
of the definition of this TLS extension says:

http://tools.ietf.org/html/rfc6066#section-6

The semantics of a "Server Certificate" handshake message with
no Certificates in it is UNDEFINED and therefore prohibited.

The semantics of a "Client Certificate" handshake message with
no Certificates is "NO client certificate" with _no_ slack.

The TLS requirement for the Certificate handshake message says this:

http://tools.ietf.org/html/rfc5246#section-7.4.2

      struct {

   certificate_list

There certainly are no "pre_agreed" semantics for the End-Entity(!)
certificate in the TLS Certificate handshake message.

What might be permissible (but is not an official part of the TLS spec)
is to send the certificate chain only up to a signer known to the
TLS peer.  The CertificateRequest handshake message conveys the
signer trusted by the Server to the client, so certificate path
validation should be possible for a cert chain up to one of the
announced trusted signers.

If the client uses the TrustedAuthorities TLS extension, then
personally, I would consider it permissible (but that is not
officially part of the spec!) for the server to send his own
cert chain only up to one of the trusted signers announced
by the client through the TrustedAuthorities TLS extension.

-Martin

---

From: Matt McCutchen <[email-masked]>
Date: Mon, 21 Mar 2011 17:42:25 -0400

On Mon, 2011-03-21 at 17:05 -0400, Phillip Hallam-Baker wrote:
> Trying to use DANE as a means of eliminating X.509 from TLS is a
> non-starter as far as I am concerned. If this group is not going to
> listen to the TLS WG

Agreed: we are targeting TLS.

> or the PKIX WG there is not a lot of point in it being here.

Digression (because this thread only pertains to the TLS WG): I would
not agree that following PKIX methods is a requirement per se of the
DANE WG.  PKIX is relevant to us inasmuch as (1) the TLS protocol
currently supports X.509 certificates, and we should not replace that
format just for the sake of replacing it, and (2) people will want to
use DANE in conjunction with PKIX CAs.

> What might appear to be a minor change to the protocol can have
> significant and unpredictable results throughout the system.
> 
> The way we avoid such results is mostly to avoid changes that do not
> have a very very good justification.

This is true to a point, beyond which it is FUD.  In all cases, the
risks of a change are to be balanced against its benefits.

> Not liking ASN.1 is not a justification in my view.

Agreed.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Mon, 21 Mar 2011 17:43:55 -0400

On Mon, 2011-03-21 at 17:40 -0400, Paul Wouters wrote:
> though the handshake diagram in 5246 seems to suggest [the EE cert]
> can be omitted.

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

-- 
Matt

---

From: Martin Rex <[email-masked]>
Date: Mon, 21 Mar 2011 23:01:03 +0100 (MET)

> can be omitted. I will do some more re-reading of 5246.

The diagram   http://tools.ietf.org/html/rfc5246#page-36

      Client                                               Server

      ClientHello                  -------->
                                                      ServerHello
                                                     Certificate*
                                               ServerKeyExchange*
                                              CertificateRequest*

             Figure 1.  Message flow for a full handshake

means that in some handshake the entire "Server Certificate" might
be omitted, and the definition of the "Server Certificate" handshake
message tells you, which handshakes or situations these are.

There is a proposal to omit a pre-agreed server certificate (chain) from
the TLS handshake here:

  http://tools.ietf.org/html/draft-ietf-tls-cached-info-09

but the document got stuck on the algorithm agility discussions for
this proposal a while ago...

-Martin

---

From: Paul Wouters <[email-masked]>
Date: Wed, 23 Mar 2011 06:30:35 -0400 (EDT)

On Mon, 21 Mar 2011, Paul Wouters wrote:

>> non-starter as far as I am concerned.
>

Especially considering the latest CA compromise where a CA issued a rogue
certificate for addons.mozilla.org. And this is not some el cheapo CA,
but one that is respected and has people very active within the IETF, the
good guys....

http://blog.torproject.org/blog/detecting-certificate-authority-compromises-and-web-browser-collusion

This is another clear signal that DANE is needed, and the need for the
X509 storage format is unneccessary. So people can simply take control
of SSL for servers within their own DNS zones.

Paul

---

From: Jeff Schmidt <[email-masked]>
Date: Wed, 23 Mar 2011 14:15:33 +0000

I'm new here, so I please accept all relevant apologies and I ask for all relevant leniance and guidance.  

On Mon, 21 Mar 2011, Paul Wouters wrote

> of SSL for servers within their own DNS zones.

I have been tracking this conversation with interest.  I am of the opinion that X.509 is an artifact of the past, when public keys were distributed outside of any useful namespace, and we needed additional "stuff" to establish provenance, chain of trust, etc.  X.509 is essentially a way to (1) map a public key to a hostname/email address, and (2) establish a chain of trust.

Of course, we don't need (1) when the key is in DNS, and hopefully we're moving away from practices that would need (2) for all the reasons the CA trust model is broken.  So, X.509 brings a lot of overhead/baggage without providing anything useful in return.(*)  Thus, I agree that we should be designing DANE (and other approaches) for the future, which will hopefully be a post-X.509/CA world.

The (*) is interoperability with TLS, which we obviously need.  So, here's the idea: why don't we design DANE to support both methods of operation: publishing X.509 certs/hashes and bare keys.  This gives us interoperability in the near term and flexibility into the future (to combat the TXT approaches).

As I see it, we could generalize the "TLSA Certificate Types" registry to support several methods of operation - something like "TLSA Data Types" then add to the initial registry:
   n: Bare public key to identify an end entity
   n: Bare public key trust anchor

Hash types still applies as written; some other language would need smoothing here and there, but it pretty much works.

If I'm not way off base here, I'd be happy to take a shot at some edits to -06 if desired.

Thanks,
Jeff

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 23 Mar 2011 08:19:31 -0700

> I'm new here, so I please accept all relevant apologies and I ask for all relevant leniance and guidance.

Guidance: read the list archives relevant to your concern. Search for issue #14, which was finished some time ago, and "bare key". This current thread is an attempt to re-open the issue.

> If I'm not way off base here, I'd be happy to take a shot at some edits to -06 if desired.

Guidance: The WG already has draft authors (I'm one, Jakob Schlyter is the other). We take direction from the WG chairs when issues are closed, then put out a new draft.

--Paul Hoffman

---

From: Matt McCutchen <[email-masked]>
Date: Wed, 23 Mar 2011 11:26:28 -0400

On Wed, 2011-03-23 at 06:30 -0400, Paul Wouters wrote:
> This is another clear signal that DANE is needed,

Indeed.

> and the need for the X509 storage format is unneccessary.

Non sequitur.  What does the compromise of a CA have to do with the use
(or not) of X.509 as a container in DANE?

-- 
Matt

---

From: Douglas Otis <[email-masked]>
Date: Wed, 23 Mar 2011 19:29:34 -0700

On 3/23/11 3:30 AM, Paul Wouters wrote:
>> That has been loud and clear. However, it does not mean others should 
>> stop trying to innovate and move forward.
>
Could this end the practice of stapling Certs to server responses that 
might be cached for weeks to support ultra-fast browsers?  Perfect 
MitM.  Do these browser insist on seeing valid nonce extensions, as this 
would hurt performance?

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Thu, 24 Mar 2011 11:43:51 -0700

On 3/23/11 7:29 PM, Douglas Otis wrote:
>>> That has been loud and clear. However, it does not mean others 
>>> should stop trying to innovate and move forward.
>>
> MitM.  Do these browser insist on seeing valid nonce extensions, as 
> this would hurt performance?
It was a mistake referring to the stapling of Certs.  The concern was in 
regard to stapling of OSCP-responses as defined in RFC4366.  
Unfortunately, this RFC did not establish a convention for NONCE tokens 
indicating it represented POSIX time where receivers could be required 
to reject any that were more than 1 hour old, for example.   This would 
mean OSCP responses should never be more than 1 hour old.  Otherwise, a 
response will always be delayed by an embedded OSCP response, which 
would also eliminates the speed advantage being sought.

-Doug

---

From: Henry Story <[email-masked]>
Date: Fri, 25 Mar 2011 07:55:24 +0100

> Guidance: read the list archives relevant to your concern. Search for issue #14, which was finished some time ago, and "bare key". This current thread is an attempt to re-open the issue.

Just to make that simpler, you can find it here:

http://trac.tools.ietf.org/wg/dane/trac/ticket/14

It was a long thread, so I added a pointer to one mail where I tried to summarise the issues on that issue page. There is at least a reasonably standard way to publish the keys, the one defined by X509 itself. 

What was still open was why one should add bare public keys, other than for reasons of elegance and bandwidth (which could be important, tests needed) to the options specified in Dane. Those arguing against claimed it could make things very difficult for a lot of software.

Henry

---

From: Paul Wouters <[email-masked]>
Date: Fri, 25 Mar 2011 05:03:32 -0400 (EDT)

On Wed, 23 Mar 2011, Douglas Otis wrote:

> Could this end the practice of stapling Certs to server responses that might 
> be cached for weeks to support ultra-fast browsers?  Perfect MitM.  Do these 
> browser insist on seeing valid nonce extensions, as this would hurt 
> performance?

I was also pretty disappointed to see that when you send a
trusted_ca_keys: pre_agreed value, that this is totally ignored on
servers, including openssl.org. I have a rough patch for openssl I used
for testing, but not one that takes any of the other RFC 6066 options (yet)

In fact, if I understood the versioning right, basically no one is
running TLS v1.2 yet, and the comments in the openssl 1.0.1 snapshot
suggested it had only partially started on TLs v1.1.

I did not expect this backlog on the TLS implementations.

Paul

---

From: Ben Laurie <[email-masked]>
Date: Fri, 25 Mar 2011 10:13:39 +0000

On 25 March 2011 09:03, Paul Wouters <[email-masked]> wrote:
>> might be cached for weeks to support ultra-fast browsers?  Perfect MitM.  Do
>> these browser insist on seeing valid nonce extensions, as this would hurt
>> performance?
>

Happy to shepherd OpenSSL patches...

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

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 25 Mar 2011 06:14:23 -0400

> What was still open was why one should add bare public keys, other than for reasons of elegance and bandwidth (which could be important, tests needed) to the options specified in Dane. Those arguin…

"Those arguing against" had additional claims. The one I heard a few times was "there is no good reason to have bare keys in DANE if you cannot have them in TLS". That is, you can't do straight matching with a bare key because that is not a form that is allowed by TLS. If TLS is extended with a standards-track extension that adds bare keys, I would argue that TLSA should have it as well, but probably not until then.

--Paul Hoffman

---

From: Matt McCutchen <[email-masked]>
Date: Fri, 25 Mar 2011 10:21:07 -0400

On Fri, 2011-03-25 at 05:03 -0400, Paul Wouters wrote:
> servers, including openssl.org.

What else would you have expected?  That value is only meaningful in
contexts where the server knows what set of trust anchors you are
talking about.

-- 
Matt

---

From: Paul Wouters <[email-masked]>
Date: Fri, 25 Mar 2011 19:36:48 -0400 (EDT)

> contexts where the server knows what set of trust anchors you are

I would have expected to only get the EE cert, and no CA certs whatsoever.

Paul

---

From: Matt McCutchen <[email-masked]>
Date: Fri, 25 Mar 2011 21:03:23 -0400

> I would have expected to only get the EE cert, and no CA certs whatsoever.

Why?  The https://www.openssl.org server is not part of a deployment in
which the pre_agreed value has a well-known meaning.  I think you're
still (willfully?) misreading RFC 6066.

-- 
Matt