Subject: Re: [keyassure] The draft and subj alt names
From: Jay Daley <[email-masked]>
To: Richard L. Barnes <[email-masked]>
Cc: [email-masked]
Date: Fri, 1 Apr 2011 16:15:22 +1300
List-Id: Key Assurance With DNSSEC <keyassure.ietf.org>

On 1/04/2011, at 3:06 PM, Richard L. Barnes wrote:

> The only choice that avoids updating several RFCs is 5.

Is that your only reason for not wanting to tackle this?  Do you have any view on the nature of trust that DNSSEC provides to applications or not?

>  Just leave it alone!

No.

warmest regards
Jay

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

-- 
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840

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

The only choice that avoids updating several RFCs is 5.  Just leave it alone!
--Richard

On Mar 31, 2011, at 10:41 PM, Jay Daley wrote:

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

From: Jay Daley <[email-masked]>
Date: Fri, 1 Apr 2011 09:41:24 +1300
To: Richard L. Barnes <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] The draft and subj alt names

On 1/04/2011, at 12:12 AM, Richard L. Barnes wrote:

> As I've said in other threads, this WG should be silent on requirements for certificate names, since different applications use TLS certificate names in different ways.  See for example the difference between RFC 2818 and RFC 6125.  The text you reference in the draft is technically harmless ("must" not "MUST"), but should probably be deleted anyway.

There are two separate issues here:
a) whether we think name matching is still needed with DANE
b) what the draft should say about that

On a) I would make the case that name matching is should not be done because
- DNSSEC provides sufficient trust
- name matching forces certain operational decisions onto end user (e.g. multiple certs, cert reuse) that are unreasonable

On b) There are six options for the draft:

1.  State that name matching must be done
2.  State that name matching must not be done
3.  Leave it to applications with a recommendation to match
4.  Leave it to applications with a recommendation not to match
5.  Leave it to applications with no recommendation
6.  Add a flag into TLSA that specifies whether name matching is to be done or not

My choice, in order of preference would be 2, 6, 4.  

Jay

> 
> --Richard
> 
> 
> 
> On Mar 31, 2011, at 12:05 PM, Olle E. Johansson wrote:
> 
>> I have read the draft and reacted to one thing. Sorry if this already have been discussed on the list.
>> 
>> The draft -06 says
>> "The end entity certificate from TLS, regardless of whether it was
>>  matched with a TLSA type 1 certificate or chained to a TLSA type 2 CA
>>  certificate, must have at least one identifier in the subject or
>>  subjectAltName field of the matched certificates matches the expected
>>  identifier for the TLS server. "
>> 
>> The new RFC 6125 tells us that we should:
>> "Move toward including and checking even more specific
>>     subjectAlternativeName extensions where appropriate for using the
>>     protocol (e.g., uniformResourceIdentifier and the otherName form
>>     SRVName)."
>> 
>> I feel we need to be more specific in the draft.  What type of subjectAltName should we match with?
>> dnsName?
>> 
>> And if we're using SIP, and have URI's in the certificate - should that be part of this draft
>> or should we open for protocol-specific specifications for other types of subject Alt Names?
>> 
>> /O
>> _______________________________________________
>> keyassure mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/keyassure
> 
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

-- 
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840

Date: Thu, 31 Mar 2011 19:08:33 +0200
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ=?= <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Mis-issued certs for Google / Yahoo / Skype, etc.

On 24.3.2011 09:17, Warren Kumari wrote:
> I'm assuming everyone has already seen this, but on the off-chance that you haven't:
>
> http://threatpost.com/en_us/blogs/phony-web-certificates-issued-google-yahoo-skype-others-032311#
>
> Being able to state "That ain't my cert" is one of the drivers for this work....

And there is a follow-up:

http://www.h-online.com/security/news/item/Comodo-two-more-resellers-were-compromised-1218517.html

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: James Cloos <[email-masked]>
To: [email-masked]
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC
Copyright: Copyright 2011 James Cloos
OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
Date: Thu, 31 Mar 2011 10:02:48 -0400
Lines: 25
Cc: [email-masked]
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models

>>>>> "MR" = Martin Rex <[email-masked]> writes:

MR> In a first round of attack, the attacker inserts a fake unsigned
MR> TLSA record (DNS poisoning) that the victim is accessing with TLS
MR> frequently and where the DNS admin is not using DNSSEC.

Why would an attacker insert a fake tlsa w/o a matching fake a or aaaa?

More likely they inject both and send the user off to a fake site with
matching fake credentials.

The client software might notice that the creds have changed since the
last time it visited (/if/ it has ever visited), but how many do that
for longer than a "session"?  Any?

Without dane the attacker just does the fake a/aaaa, fake server and
fake cert an still wins.  So it isn't a regression.  But dtls w/o
dnssec doesn't actually help either.

Injecting a dtls w/o also injecting other fake RRs might get done as
a lark, but any real attacks will be more sophisticated.

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

From: Martin Rex <[email-masked]>
To: [email-masked] (Richard L. Barnes)
Date: Thu, 31 Mar 2011 15:36:41 +0200 (MEST)
Cc: [email-masked]
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models
Reply-To: [email-masked]

Richard L. Barnes wrote:
> 
> So it's a social engineering attack?  Might as well just send an email trojan.
> 
> This is the same result as
> -- Hijacking the TCP session and feeding in a fake cert 
> -- Spoofing the A record and sending the client to the wrong host (like ekr said)
> 
> --Richard

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

-Martin

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 31 Mar 2011 15:29:18 +0200
To: [email-masked]
Cc: [email-masked]
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models

So it's a social engineering attack?  Might as well just send an email trojan.

This is the same result as
-- Hijacking the TCP session and feeding in a fake cert 
-- Spoofing the A record and sending the client to the wrong host (like ekr said)

--Richard

On Mar 31, 2011, at 3:02 PM, Martin Rex wrote:

> Eric Rescorla wrote:
>> 
>> On Thu, Mar 31, 2011 at 2:38 AM, Martin Rex <[email-masked]> wrote:
>>> Martin Rex wrote:
>>>> 
>>>>> 
>>>>> I think this is an important consideration. However a relevant
>>>>> question for a 2119-level MUST seems to be whether we wish to have
>>>>> this data rejected if not DNSSEC signed.
>>>>> What's your view on that?
>>>> 
>>>> I'm much less worried about false positives resulting in DoS, which
>>>> can be more easily achieved attacking at the network layer (IP, TCP).
>>> 
>>> Actually, a DoS based on spoofing an DANE TLSA record with incorrect
>>> data and a long TTL into a DNS cache might turn out to be devastatingly
>>> effective when unsiged TLSA records are accepted.
>> 
>> How is this different from a spoofed A record with a long TTL?
> 
> In a first round of attack, the attacker inserts a fake unsigned
> TLSA record (DNS poisoning) that the victim is accessing with TLS
> frequently and where the DNS admin is not using DNSSEC.
> 
> After constantly running into validation failures although one is
> connecting to the correct server and gets presented the correct
> TLS server cert, either his help desk or the victim will disable DANE
> or switch to a browser that doesn't have it yet.  At that point
> the victim becomes vulnerable to mis-issued certs even for sites
> where the DNS admin uses DANE with DNSSEC.
> 
> -Martin
> 
> 
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

From: Yoav Nir <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Thu, 31 Mar 2011 15:28:54 +0200
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models

On Mar 31, 2011, at 3:09 PM, Martin Rex wrote:

> Yoav Nir wrote:
>> 
>> On Mar 31, 2011, at 2:38 PM, Michael Richardson wrote:
>>> 
>>>   Yoav> Cert-lock (and CA-lock) are what EKR calls supplementary,
>>>   Yoav> while the others are the restrictive. While the sever (and
>>>   Yoav> domain owner) can't dictate client policy, they should be able
>>>   Yoav> to indicate whether the Certificate (TA or EE) that's in the
>>>   Yoav> TLSA record is supposed to be validatable or not. The client
>>>   Yoav> (relying party) may have a policy to ignore records that push
>>>   Yoav> a non-valid certificate, but if you're going to publish a
>>>   Yoav> record with a certificate that you have just issued using
>>>   Yoav> openssl on your laptop and expires in 1975, the TLSA record
>>>   Yoav> had better reflect that this certificate is just a container
>>>   Yoav> for a public key, not something you can chain and validate. 
>>> 
>>> So, you are arguing that the protocol must signal the intent.
>> 
>> It's not strictly speaking "intent". It's more of an attribute.
>> Either "this certificate of mine, you can use your regular validation
>> techniques" or "this certificate of mine, just make sure you get this one."
> 
> I also think that leaving it up to the client to make assumptions
> about what type of TLS Server cert validation scheme should be used
> is likely going to result in a lot of bad decisions among the
> implementors.
> 
> If the TLSA record includes the information on the intended validation
> scheme for this information, then there is going to be more consistency
> among the implementations.
> 
> When a particular HTML page renders without apparent problems in
> one particular web browser, this is no proof that the page is correctly
> formed and can be expected to render without problems in other
> browsers as well.

Just as long as we avoid the rat-hole of calling it "policy"

From: Martin Rex <[email-masked]>
To: [email-masked] (Yoav Nir)
Date: Thu, 31 Mar 2011 15:09:30 +0200 (MEST)
Cc: [email-masked]
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models
Reply-To: [email-masked]

Yoav Nir wrote:
> 
> On Mar 31, 2011, at 2:38 PM, Michael Richardson wrote:
> > 
> >    Yoav> Cert-lock (and CA-lock) are what EKR calls supplementary,
> >    Yoav> while the others are the restrictive. While the sever (and
> >    Yoav> domain owner) can't dictate client policy, they should be able
> >    Yoav> to indicate whether the Certificate (TA or EE) that's in the
> >    Yoav> TLSA record is supposed to be validatable or not. The client
> >    Yoav> (relying party) may have a policy to ignore records that push
> >    Yoav> a non-valid certificate, but if you're going to publish a
> >    Yoav> record with a certificate that you have just issued using
> >    Yoav> openssl on your laptop and expires in 1975, the TLSA record
> >    Yoav> had better reflect that this certificate is just a container
> >    Yoav> for a public key, not something you can chain and validate. 
> > 
> > So, you are arguing that the protocol must signal the intent.
> 
> It's not strictly speaking "intent". It's more of an attribute.
> Either "this certificate of mine, you can use your regular validation
> techniques" or "this certificate of mine, just make sure you get this one."

I also think that leaving it up to the client to make assumptions
about what type of TLS Server cert validation scheme should be used
is likely going to result in a lot of bad decisions among the
implementors.

If the TLSA record includes the information on the intended validation
scheme for this information, then there is going to be more consistency
among the implementations.

When a particular HTML page renders without apparent problems in
one particular web browser, this is no proof that the page is correctly
formed and can be expected to render without problems in other
browsers as well.

-Martin

From: Martin Rex <[email-masked]>
To: [email-masked] (Eric Rescorla)
Date: Thu, 31 Mar 2011 15:02:10 +0200 (MEST)
Cc: [email-masked]
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models
Reply-To: [email-masked]

Eric Rescorla wrote:
> 
> On Thu, Mar 31, 2011 at 2:38 AM, Martin Rex <[email-masked]> wrote:
> > Martin Rex wrote:
> >>
> >> >
> >> > I think this is an important consideration. However a relevant
> >> > question for a 2119-level MUST seems to be whether we wish to have
> >> > this data rejected if not DNSSEC signed.
> >> > What's your view on that?
> >>
> >> I'm much less worried about false positives resulting in DoS, which
> >> can be more easily achieved attacking at the network layer (IP, TCP).
> >
> > Actually, a DoS based on spoofing an DANE TLSA record with incorrect
> > data and a long TTL into a DNS cache might turn out to be devastatingly
> > effective when unsiged TLSA records are accepted.
> 
> How is this different from a spoofed A record with a long TTL?

In a first round of attack, the attacker inserts a fake unsigned
TLSA record (DNS poisoning) that the victim is accessing with TLS
frequently and where the DNS admin is not using DNSSEC.

After constantly running into validation failures although one is
connecting to the correct server and gets presented the correct
TLS server cert, either his help desk or the victim will disable DANE
or switch to a browser that doesn't have it yet.  At that point
the victim becomes vulnerable to mis-issued certs even for sites
where the DNS admin uses DANE with DNSSEC.

-Martin

From: Yoav Nir <[email-masked]>
To: Michael Richardson <[email-masked]>
Date: Thu, 31 Mar 2011 15:01:19 +0200
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models

On Mar 31, 2011, at 2:38 PM, Michael Richardson wrote:

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

It's not strictly speaking "intent". It's more of an attribute. Either "this certificate of mine, you can use your regular validation techniques" or "this certificate of mine, just make sure you get this one."

Yoav

From: Michael Richardson <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Thu, 31 Mar 2011 14:38:16 +0200
Sender: [email-masked]
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models

>>>>> "Yoav" = Yoav Nir <[email-masked]> writes:
    Yoav> So it's really down to 4 cases:
    Yoav> - CA-lock (I only use Verisign)
    Yoav> - Cert-lock (I only use this cert)
    Yoav> - This CA (This is the CA cert that issues my certificate, and
    Yoav> it may not be in your TAS) 

    Yoav> - This Cert (this is the cert I'll be using, and I'm not
    Yoav> promising that you can validate it) 

    Yoav> While I see some value in cert-lock, I don't see much value in
    Yoav> CA-lock. It would solve Comodogate if I was a customer of
    Yoav> another CA, but not if I was a customer of Comodo. 

Presumably, if you were a customer, they would never issue two certs for
the same DN to different customers.

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

So, you are arguing that the protocol must signal the intent.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition. 

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 31 Mar 2011 13:12:32 +0200
To: "Olle E. Johansson" <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] The draft and subj alt names

As I've said in other threads, this WG should be silent on requirements for certificate names, since different applications use TLS certificate names in different ways.  See for example the difference between RFC 2818 and RFC 6125.  The text you reference in the draft is technically harmless ("must" not "MUST"), but should probably be deleted anyway.

--Richard

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

> I have read the draft and reacted to one thing. Sorry if this already have been discussed on the list.
> 
> The draft -06 says
> "The end entity certificate from TLS, regardless of whether it was
>   matched with a TLSA type 1 certificate or chained to a TLSA type 2 CA
>   certificate, must have at least one identifier in the subject or
>   subjectAltName field of the matched certificates matches the expected
>   identifier for the TLS server. "
> 
> The new RFC 6125 tells us that we should:
> "Move toward including and checking even more specific
>      subjectAlternativeName extensions where appropriate for using the
>      protocol (e.g., uniformResourceIdentifier and the otherName form
>      SRVName)."
> 
> I feel we need to be more specific in the draft.  What type of subjectAltName should we match with?
> dnsName?
> 
> And if we're using SIP, and have URI's in the certificate - should that be part of this draft
> or should we open for protocol-specific specifications for other types of subject Alt Names?
> 
> /O
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 31 Mar 2011 12:05:48 +0200
To: [email-masked]
Subject: [keyassure] The draft and subj alt names

I have read the draft and reacted to one thing. Sorry if this already have been discussed on the list.

The draft -06 says
"The end entity certificate from TLS, regardless of whether it was
   matched with a TLSA type 1 certificate or chained to a TLSA type 2 CA
   certificate, must have at least one identifier in the subject or
   subjectAltName field of the matched certificates matches the expected
   identifier for the TLS server. "

The new RFC 6125 tells us that we should:
"Move toward including and checking even more specific
      subjectAlternativeName extensions where appropriate for using the
      protocol (e.g., uniformResourceIdentifier and the otherName form
      SRVName)."

I feel we need to be more specific in the draft.  What type of subjectAltName should we match with?
dnsName?

And if we're using SIP, and have URI's in the certificate - should that be part of this draft
or should we open for protocol-specific specifications for other types of subject Alt Names?

/O

From: Yoav Nir <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>
Date: Thu, 31 Mar 2011 11:39:22 +0200
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models

On Mar 31, 2011, at 11:15 AM, Richard L. Barnes wrote:

>>>> If the attacker injects fake dns records pointing to a fake server, they
>>>> can include a dane rr.  It only makes the attack slightly harder, doesn't it?
>>> 
>>> Yes, but as ekr pointed out, injecting fake DANE RRs can only cause the connection to fail, it won't result in the client connecting to a bogus server.   That's why it's RECOMMENDED instead of REQUIRED.
>> 
>> Not if you are a MITM on the wire as well (more star bucks wifi use cases) and
>> you're directing the user to your own website with a dane rr matching public key.
> 
> You're confusing the "Cert Lock" and "Install TA" use cases.  If all the server doing is "Cert Lock", then the bogus DANE record will simply cause the client to reject the server's cert and the connection to fail.  In the "Install TA" case, DNSSEC would be REQUIRED, for exactly the reason you note.

So it's really down to 4 cases:
- CA-lock (I only use Verisign)
- Cert-lock (I only use this cert)
- This CA (This is the CA cert that issues my certificate, and it may not be in your TAS)
- This Cert (this is the cert I'll be using, and I'm not promising that you can validate it)

While I see some value in cert-lock, I don't see much value in CA-lock. It would solve Comodogate if I was a customer of another CA, but not if I was a customer of Comodo.

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

So I think the requirements document should describe EKR's use cases, and require that the TLSA record be able to differentiate between records that are appropriate for the two use cases.

And yes, a certificate from a known CA can be appropriate for both use cases, and I expect that at least initially those would be more popular, as they work with "legacy" relying parties.

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 31 Mar 2011 11:15:31 +0200
To: Paul Wouters <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models

>>> If the attacker injects fake dns records pointing to a fake server, they
>>> can include a dane rr.  It only makes the attack slightly harder, doesn't it?
>> 
>> Yes, but as ekr pointed out, injecting fake DANE RRs can only cause the connection to fail, it won't result in the client connecting to a bogus server.   That's why it's RECOMMENDED instead of REQUIRED.
> 
> Not if you are a MITM on the wire as well (more star bucks wifi use cases) and
> you're directing the user to your own website with a dane rr matching public key.

You're confusing the "Cert Lock" and "Install TA" use cases.  If all the server doing is "Cert Lock", then the bogus DANE record will simply cause the client to reject the server's cert and the connection to fail.  In the "Install TA" case, DNSSEC would be REQUIRED, for exactly the reason you note.

--Richard

From: Michael Richardson <[email-masked]>
To: [email-masked]
Date: Thu, 31 Mar 2011 10:16:37 +0200
Sender: [email-masked]
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models

>>>>> "Warren" = Warren Kumari <[email-masked]> writes:
    Warren> In Eric's Case / Objective 1 (where DNSSEC might not be
    Warren> needed): Scenario 1: If I am the operator of example.com and
    Warren> Mallory manages to trick EzCerts into issuing him a cert for
    Warren> example.com.  Let's say that Mallory is powerful, and can
    Warren> monkey with DNS traffic for users behind ISP Foo (and only
    Warren> behind ISP Foo).  If we allow TLSA without DNSSEC to say
    Warren> "Cert X must appear in the path" Malloy can do bad things to
    Warren> users of ISP Foo (by stripping the record, changing it to
    Warren> his, etc). BUT all users NOT behind ISP Foo (and all users
    Warren> of ISP Foo who do DNSSEC validation) will know not to accept
    Warren> Mallory's cert for example.com.  As the operator of
    Warren> example.com, I am unhappy, but I have at least limited the
    Warren> scope of the attack....

There is an assumption here that the days of widespread DNS cache
poisioning are over.  That Mallory essentially can now only do an
on-path attack on DNS.

I'm not claiming this isn't true, but just stating this assumption.
There are still lots of open recursive resolvers.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition. 

Date: Thu, 31 Mar 2011 09:50:08 +0200
From: Eric Rescorla <[email-masked]>
To: Paul Wouters <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models

On Thu, Mar 31, 2011 at 9:40 AM, Paul Wouters <[email-masked]> wrote:
> On Wed, 30 Mar 2011, Eric Rescorla wrote:
>
>> It's obviously better if DANE is DNSSEC secured, but it's not dangerous
>> if they aren't signed, since that just brings you back to where you were
>> without DANE.
>
> That assumes DANE is an addition to PKIX. Once you assume it is a
> replacement
> for PKIX, you can't have DNSSEC being optional. (If you don't agree, let's
> have coffee at starbucks and use their wifi :)

The context has been lost here, but I was talking about the cert lock
application, not the alternate CA application.

-Ekr

Date: Thu, 31 Mar 2011 03:42:05 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models

On Wed, 30 Mar 2011, Richard L. Barnes wrote:

>> If the attacker injects fake dns records pointing to a fake server, they
>> can include a dane rr.  It only makes the attack slightly harder, doesn't it?
>
> Yes, but as ekr pointed out, injecting fake DANE RRs can only cause the connection to fail, it won't result in the client connecting to a bogus server.   That's why it's RECOMMENDED instead of REQUIRED.

Not if you are a MITM on the wire as well (more star bucks wifi use cases) and
you're directing the user to your own website with a dane rr matching public key.

Paul

Date: Thu, 31 Mar 2011 03:40:29 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Eric Rescorla <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models

On Wed, 30 Mar 2011, Eric Rescorla wrote:

> It's obviously better if DANE is DNSSEC secured, but it's not dangerous
> if they aren't signed, since that just brings you back to where you were
> without DANE.

That assumes DANE is an addition to PKIX. Once you assume it is a replacement
for PKIX, you can't have DNSSEC being optional. (If you don't agree, let's
have coffee at starbucks and use their wifi :)

Paul

Date: Thu, 31 Mar 2011 07:07:33 +0200
From: Eric Rescorla <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models

On Thu, Mar 31, 2011 at 2:38 AM, Martin Rex <[email-masked]> wrote:
> Martin Rex wrote:
>>
>> >
>> > I think this is an important consideration. However a relevant
>> > question for a 2119-level MUST seems to be whether we wish to have
>> > this data rejected if not DNSSEC signed.
>> > What's your view on that?
>>
>> I'm much less worried about false positives resulting in DoS, which
>> can be more easily achieved attacking at the network layer (IP, TCP).
>
> Actually, a DoS based on spoofing an DANE TLSA record with incorrect
> data and a long TTL into a DNS cache might turn out to be devastatingly
> effective when unsiged TLSA records are accepted.

How is this different from a spoofed A record with a long TTL?

-Ekr

From: Martin Rex <[email-masked]>
To: [email-masked] (Eric Rescorla)
Date: Thu, 31 Mar 2011 03:05:20 +0200 (MEST)
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [keyassure] CN/SAN matching (was: End entity certificate
Reply-To: [email-masked]

Eric Rescorla wrote:
> 
> Jay Daley <[email-masked]> wrote:
> >
> > Richard L. Barnes wrote:
> > >
> > > Nope, it's up to applications. �If you want SN/CAN *not* to be
> > > checked for HTTPS, then you need to go revise RFC 2818; for SMTP,
> > > RFC 3207; for IMAP/POP3, RFC 2595.
> >
> > Indeed.
> >
> > I assumed we were updating RFC 2818.
> 
> In that case, this document will need to be dual last called in the
> TLS WG, since 2818 was a TLS product.

While it doesn't call itself an update to rfc2818 by its document header,
I always assumed it wanted to be this update.

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

The question is more about "if the creator of the certificate placed
attributes in that certificates that are traditionally considered
"constraints" or "usage restrictions", should these be still be honoured,
even if there is no PKIX cert path validation performed on the certificate.

This is why personally, I have a preference to use X.509v1 certs as
self-signed TLS server certs -- there are significantly less attributes
to get wrong by accident.

But the real issue is more about determining intent.
Maybe the DANE TLSA record should also carry a hint whether or not
the cert attributes (anything besides the public key) should
be ignored (= not checked, not seen as usage limitations).

There may be clients in the installed base that have certain
checks or assumptions about presence of specific attributes in
a certificate hardcoded, and the TLS server admin may want to
provide the attributes only/specifically for those old clients
in the installed base -- not for DANE-aware new clients.

-Martin

From: Martin Rex <[email-masked]>
To: [email-masked]
Date: Thu, 31 Mar 2011 02:38:59 +0200 (MEST)
Cc: [email-masked]
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models
Reply-To: [email-masked]

Martin Rex wrote:
> 
> > 
> > I think this is an important consideration. However a relevant
> > question for a 2119-level MUST seems to be whether we wish to have
> > this data rejected if not DNSSEC signed.
> > What's your view on that?
> 
> I'm much less worried about false positives resulting in DoS, which
> can be more easily achieved attacking at the network layer (IP, TCP).

Actually, a DoS based on spoofing an DANE TLSA record with incorrect
data and a long TTL into a DNS cache might turn out to be devastatingly
effective when unsiged TLSA records are accepted.

-Martin

From: Martin Rex <[email-masked]>
To: [email-masked] (Eric Rescorla)
Date: Thu, 31 Mar 2011 02:26:21 +0200 (MEST)
Cc: [email-masked]
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models
Reply-To: [email-masked]

Eric Rescorla wrote:
> 
> Jay Daley <[email-masked]> wrote:
> >
> > Richard L. Barnes wrote:
> > >
> > > Yes, but as ekr pointed out, injecting fake DANE RRs can only
> > > cause the connection to fail, it won't result in the client
> > > connecting to a bogus server. � That's why it's RECOMMENDED
> > > instead of REQUIRED.
> >
> > That's still potentially a devastating DOS attack if done well and
> > against an important target. �Worthy of a REQUIRED for that alone.
> >
> > There is also the layer 9 interpretation issue here - if we say that
> > DANE in its entirety requires DNSSEC then that message can be shouted
> > loud and clear, reinforced and hopefully entrenched. �If we say that
> > only some parts need it then people, for entirely fallible reasons,
> > get confused, doubt DANE, can use this to attack DANE and so on.
> 
> I think this is an important consideration. However a relevant
> question for a 2119-level MUST seems to be whether we wish to have
> this data rejected if not DNSSEC signed.
> What's your view on that?

I'm much less worried about false positives resulting in DoS, which
can be more easily achieved attacking at the network layer (IP, TCP).

What worries me is the false negatives resulting from a
"successful verification" of an unsigned DANE RR.

The prerequisite for a "successful DANE validation" is that the
DANE TLSA record has been DNSSEC validated.  And my concern is that
some GUIs might get that wrong unless the spec is crystal clear
what constitutes a successful DANE validation (DNSSEC required)
and what not.

I'm OK with interpreting even an unsigned TLSA validation failure
as "something is goofy here, abort the connection", but that causes
the DANE validation result to have 3-states "good/not-obviously-bad/bad"
rather than a boolean "good/bad", and a 3-state may get mapped incorrectly
to binary UI indicators (icon present/absent).

-Martin

From: Warren Kumari <[email-masked]>
Date: Thu, 31 Mar 2011 01:14:15 +0200
To: [email-masked]
Cc: [email-masked]
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models

On Mar 30, 2011, at 11:55 PM, Martin Rex wrote:

> Eric Rescorla wrote:
>> 
>> Martin Rex <[email-masked]> wrote:
>>> 
>>> Maybe I'm dense at the moment, but I don't understand
>>> "the DANE data need not be DNSSEC secured".
>>> 
>>> Without DNSSEC, you have a vulnerability, because you can not
>>> enforce a CA or EE cert lock.  An attacker can DNS-spoof DANE records
>>> for the mis-issued certs of his choice or DNS-spoof the absence
>>> of DANE records (and the absence of DANE records will be quite
>>> common for more than just a few days).
>> 
>> It's obviously better if DANE is DNSSEC secured, but it's not dangerous
>> if they aren't signed, since that just brings you back to where you were
>> without DANE. However, the DANE records can be set with fairly long
>> expiries (like HSTS), thus providing a partial firewall against comodo-type
>> problems.
> 
> I still don't understand.
> 
> As Bruce Schneier says "security must be evaluated not based
> on how it works, but on how it fails".
> 
> DANE without DNSSEC is a vulnerability by itself, because it can
> be abused by an attacker to make things work that shouldn't work
> (the trust rooted to DNS case) and can create a false impression
> about security that is not provided (the cert/CA lock case).
> 
> Verification of unsigned DANE TLSA records may cause a warm
> fuzzy feeling for some, but does not provide any security
> against a determined and powerful attacker.

I suspect think that you are talking past each other, so I'm going to try provide scenarios (and also make sure I understand):

In Eric's Case / Objective 1 (where DNSSEC might not be needed):
Scenario 1: If I am the operator of example.com and Mallory manages to trick EzCerts into issuing him a cert for example.com.
Let's say that Mallory is powerful, and can monkey with DNS traffic for users behind ISP Foo (and only behind ISP Foo).  If we allow TLSA without DNSSEC to say "Cert X must appear in the path" Malloy can do bad things to users of ISP Foo (by stripping the record, changing it to his, etc). BUT all users NOT behind ISP Foo (and all users of ISP Foo who do DNSSEC validation) will know not to accept Mallory's cert for example.com.   As the operator of example.com, I am unhappy, but I have at least limited the scope of the attack....

Scenario 2: I am the operator of example.com and Eve is has the ability to spoof DNS. She wants to cause a DoS against example.com, so she inserts a "false" TLSA record -- she does this so that users connecting though that path will fail the DANE check and be unable to connect.... This *is* a new DoS vulnerability, but if Eve is in a position to monkey with the DNS / inject DNS she *already* has the ability to cause a DoS by simply changing A / AAAA records, etc.

In both of these (and all the scenarios I can come up with), TLSA without DNSSEC validation doesn't make problems worse, but sometimes makes things better...

I think that Martin's concerns are all in Eric's Case / Objective 2, where DNSSEC *is* required...

> 
> Commodogate may have been a government-backed hack.  The may be
> more such about which we don't know yet.  They could prevent OCSP-checks
> by making the relevant requests fail at the network layer.
> Similarly, they could prevent browser updates (with blacklists of
> the mis-issued certs) at the network level.  And they could spoof
> DNS replies as well.

Yes, but if we allow TLSA without DNSSEC *only for objective / case 1*, "they" can still attack victims for whom they can spoof DNS replies, but at least everyone else if better protected. Obviously TLSA with DNSSEC is far better, but allowing it without does have some benefits (and can be deployed much faster).

W

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

Date: Thu, 31 Mar 2011 00:14:38 +0200
From: Eric Rescorla <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models

On Wed, Mar 30, 2011 at 11:55 PM, Martin Rex <[email-masked]> wrote:
> Eric Rescorla wrote:
>>
>> Martin Rex <[email-masked]> wrote:
>> >
>> > Maybe I'm dense at the moment, but I don't understand
>> > "the DANE data need not be DNSSEC secured".
>> >
>> > Without DNSSEC, you have a vulnerability, because you can not
>> > enforce a CA or EE cert lock. �An attacker can DNS-spoof DANE records
>> > for the mis-issued certs of his choice or DNS-spoof the absence
>> > of DANE records (and the absence of DANE records will be quite
>> > common for more than just a few days).
>>
>> It's obviously better if DANE is DNSSEC secured, but it's not dangerous
>> if they aren't signed, since that just brings you back to where you were
>> without DANE. However, the DANE records can be set with fairly long
>> expiries (like HSTS), thus providing a partial firewall against comodo-type
>> problems.
>
> I still don't understand.

I don't disagree with you about the facts of the situation, merely about how
they should be interpreted..

Best
-Ekr

> As Bruce Schneier says "security must be evaluated not based
> on how it works, but on how it fails".
>
> DANE without DNSSEC is a vulnerability by itself, because it can
> be abused by an attacker to make things work that shouldn't work
> (the trust rooted to DNS case) and can create a false impression
> about security that is not provided (the cert/CA lock case).
>
> Verification of unsigned DANE TLSA records may cause a warm
> fuzzy feeling for some, but does not provide any security
> against a determined and powerful attacker.
>
> Commodogate may have been a government-backed hack. �The may be
> more such about which we don't know yet. �They could prevent OCSP-checks
> by making the relevant requests fail at the network layer.
> Similarly, they could prevent browser updates (with blacklists of
> the mis-issued certs) at the network level. �And they could spoof
> DNS replies as well.
>
>
> -Martin
>

From: Warren Kumari <[email-masked]>
Date: Thu, 31 Mar 2011 00:03:33 +0200
To: [email-masked]
Subject: [keyassure] Use cases document.

Hi there all,

So it became (blindingly) clear during the meeting today that we need a use-cases type document to clearly explain what we believe the actual use cases are, what we think we can do, etc.

This discussion has already progressed nicely on-list ("Objective: Restrictive versus Supplementary Models"), but we would like to keep the momentum going, strike while the iron is hot and various similar idioms, so:

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

2: We are starting a consensus call to add a milestone for the use-case document.
From the meeting it seems that there is likely to be strong consensus for creating this, but please provide input on list....

I would like to apologize for not realizing earlier that the group wanted this document -- it is very easy to get swept up in the "Let's fix this thing" and assuming that everyone has the same idea of what the "thing" actually is.... I thought that we had figured this out on-list right back at the beginning of time, but a: not as clearly as I thought and b: we didn't clearly capture this....

W

From: Martin Rex <[email-masked]>
To: [email-masked] (Eric Rescorla)
Date: Wed, 30 Mar 2011 23:55:36 +0200 (MEST)
Cc: [email-masked]
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models
Reply-To: [email-masked]

Eric Rescorla wrote:
> 
> Martin Rex <[email-masked]> wrote:
> >
> > Maybe I'm dense at the moment, but I don't understand
> > "the DANE data need not be DNSSEC secured".
> >
> > Without DNSSEC, you have a vulnerability, because you can not
> > enforce a CA or EE cert lock. �An attacker can DNS-spoof DANE records
> > for the mis-issued certs of his choice or DNS-spoof the absence
> > of DANE records (and the absence of DANE records will be quite
> > common for more than just a few days).
> 
> It's obviously better if DANE is DNSSEC secured, but it's not dangerous
> if they aren't signed, since that just brings you back to where you were
> without DANE. However, the DANE records can be set with fairly long
> expiries (like HSTS), thus providing a partial firewall against comodo-type
> problems.

I still don't understand.

As Bruce Schneier says "security must be evaluated not based
on how it works, but on how it fails".

DANE without DNSSEC is a vulnerability by itself, because it can
be abused by an attacker to make things work that shouldn't work
(the trust rooted to DNS case) and can create a false impression
about security that is not provided (the cert/CA lock case).

Verification of unsigned DANE TLSA records may cause a warm
fuzzy feeling for some, but does not provide any security
against a determined and powerful attacker.

Commodogate may have been a government-backed hack.  The may be
more such about which we don't know yet.  They could prevent OCSP-checks
by making the relevant requests fail at the network layer.
Similarly, they could prevent browser updates (with blacklists of
the mis-issued certs) at the network level.  And they could spoof
DNS replies as well.

-Martin

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 30 Mar 2011 22:39:57 +0200
To: Jay Daley <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models

To re-focus this discussion, I would just like to point out that whether DNSSEC is REQUIRED or RECOMMENDED is not material to the structure of the use case.  We can have that debate when it comes time to decide on mechanism.

--Richard

On Mar 30, 2011, at 10:27 PM, Jay Daley wrote:

> 
> On 31/03/2011, at 9:17 AM, Eric Rescorla wrote:
> 
>>>>> RLB> 1. Cert-lock / CA-lock
>>>>> RLB> 1.3. DNSSEC RECOMMENDED, not REQUIRED; attacker can only cause connection failure
>>>>> 
>>>>> If the attacker injects fake dns records pointing to a fake server, they
>>>>> can include a dane rr.  It only makes the attack slightly harder, doesn't it?
>>>> 
>>>> Yes, but as ekr pointed out, injecting fake DANE RRs can only cause the connection to fail, it won't result in the client connecting to a bogus server.   That's why it's RECOMMENDED instead of REQUIRED.
>>> 
>>> That's still potentially a devastating DOS attack if done well and against an important target.  Worthy of a REQUIRED for that alone.
>>> 
>>> There is also the layer 9 interpretation issue here - if we say that DANE in its entirety requires DNSSEC then that message can be shouted loud and clear, reinforced and hopefully entrenched.  If we say that only some parts need it then people, for entirely fallible reasons, get confused, doubt DANE, can use this to attack DANE and so on.
>> 
>> I think this is an important consideration. However a relevant
>> question for a 2119-level MUST seems
>> to be whether we wish to have this data rejected if not DNSSEC signed.
>> What's your view on that?
> 
> If unsigned then the data should be ignored.  That exactly maps to the current situation, which gives a clean split between that or using DANE as an all-or-nothing improvement on top of that.  
> 
> Jay 
> 
>> 
>> -Ekr
> 
> 
> -- 
> Jay Daley
> Chief Executive
> .nz Registry Services (New Zealand Domain Name Registry Limited)
> desk: +64 4 931 6977
> mobile: +64 21 678840
> 

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 30 Mar 2011 22:36:38 +0200
To: Jay Daley <[email-masked]>
Cc: Peter Palfrader <[email-masked]>, [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] CN/SAN matching (was: End entity certificate matching, trust anchors, and protocol-06)

The milestone reads:
"
April 2011 - First WG draft of standards-track protocol for using DNS to associate hosts with keys for TLS and DTLS
"
So no, not updating 2818, 3207, etc.

The upshot of this naming discussion is that nothing that touches names is going to be general to TLS and DTLS.  So if you want to update 2818 to use DANE for name matching, you'll have to do it in a separate document, either as a new DANE milestone or (more likely) in TLS.  

--Richard

On Mar 30, 2011, at 10:14 PM, Jay Daley wrote:

> 
> On 31/03/2011, at 9:03 AM, Richard L. Barnes wrote:
> 
>> Nope, it's up to applications.  If you want SN/CAN *not* to be checked for HTTPS, then you need to go revise RFC 2818; for SMTP, RFC 3207; for IMAP/POP3, RFC 2595.
> 
> Indeed.
> 
> I assumed we were updating RFC 2818.
> 
> As for RFC 3207 that says this gem, which is as much use as a chocolate teapot and so will need updating:
> 
> -  A SMTP client would probably only want to authenticate an SMTP
>   server whose server certificate has a domain name that is the
>   domain name that the client thought it was connecting to."
> 
> And RFC 2595 is going to need updating because the name check is specific:
> 
>   - The client MUST use the server hostname it used to open the
>     connection as the value to compare against the server name as
>     expressed in the server certificate.  The client MUST NOT use any
>     form of the server hostname derived from an insecure remote source
>     (e.g., insecure DNS lookup).  CNAME canonicalization is not done.
> 
> Jay
> 
>> 
>> --Richard
>> 
>> 
>> 
>> On Mar 30, 2011, at 9:45 PM, Jay Daley wrote:
>> 
>>> I would argue the complete opposite - that it is in scope for DANE to state that names in certificates should not be checked because the trust chain has been provided by DNSSEC.  Doing that allows individuals and organisations to reuse certificates as they need to for operational reasons and not as dictated to by suppliers or paranoid protocol developers.
>>> 
>>> Jay
>>> 
>>> On 31/03/2011, at 12:55 AM, Richard L. Barnes wrote:
>>> 
>>>> This is outside of DANE's scope.  Checking of names in certificates is up to the application that uses TLS.
>>>> --Richard
>>>> 
>>>> 
>>>> On Mar 30, 2011, at 1:19 PM, Stephen Kent wrote:
>>>> 
>>>>> At 11:14 AM +0200 3/30/11, Peter Palfrader wrote:
>>>>>> On Mon, 21 Mar 2011, Paul Hoffman wrote:
>>>>>> 
>>>>>>> On Mar 21, 2011, at 6:04 AM, Peter Palfrader wrote:
>>>>>>>> Why is it needed in the first place?
>>>>>>> 
>>>>>>> That's a very good question. I don't feel that it is a "need", but it
>>>>>>> "makes some sense". That is, if I want to go to www.example.com, and I
>>>>>>> get an A record for www.example.com, and I get a TLSA record for
>>>>>>> _http._tcp.www.example.com, and I get a certificate that says "this
>>>>>>> key is associated with www.somethingelse.com", what does it mean?
>>>>>>> 
>>>>>>> I can see both ways: "it doesn't matter what the cert says, we are
>>>>>>> trusting the binding from the DNS" vs. "the cert needs to mean
>>>>>>> something"? Jakob and I have that text in because a number of people
>>>>>>> on the list were in the latter category, but it seems like a
>>>>>>> reasonable question to ask separately.
>>>>>> 
>>>>>> I wonder if one approach here would be to require a match if, and only
>>>>>> if, any naming attributes (CN, SubjectAltName) are in the certificate.
>>>>>> 
>>>>>> If there are no CN and no SAN attributes in the certificate then that
>>>>>> would be acceptable too.
>>>>>> 
>>>>>> Cheers,
>>>>>> Peter
>>>>> 
>>>>> A CN is a type of attribute in the Subject DN.  A SAN admits a variety of name types, some of which can have attributes. Do you mean to focus on DNS names as SANs or did you have a broader range of SANs in mind?
>>>>> 
>>>>> Steve
>>>>> _______________________________________________
>>>>> keyassure mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/keyassure
>>>> 
>>>> _______________________________________________
>>>> keyassure mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/keyassure
>>> 
>>> 
>>> -- 
>>> Jay Daley
>>> Chief Executive
>>> .nz Registry Services (New Zealand Domain Name Registry Limited)
>>> desk: +64 4 931 6977
>>> mobile: +64 21 678840
>>> 
>> 
> 
> 
> -- 
> Jay Daley
> Chief Executive
> .nz Registry Services (New Zealand Domain Name Registry Limited)
> desk: +64 4 931 6977
> mobile: +64 21 678840
> 

From: Jay Daley <[email-masked]>
Date: Thu, 31 Mar 2011 09:27:36 +1300
To: Eric Rescorla <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models

On 31/03/2011, at 9:17 AM, Eric Rescorla wrote:

>>>> RLB> 1. Cert-lock / CA-lock
>>>> RLB> 1.3. DNSSEC RECOMMENDED, not REQUIRED; attacker can only cause connection failure
>>>> 
>>>> If the attacker injects fake dns records pointing to a fake server, they
>>>> can include a dane rr.  It only makes the attack slightly harder, doesn't it?
>>> 
>>> Yes, but as ekr pointed out, injecting fake DANE RRs can only cause the connection to fail, it won't result in the client connecting to a bogus server.   That's why it's RECOMMENDED instead of REQUIRED.
>> 
>> That's still potentially a devastating DOS attack if done well and against an important target.  Worthy of a REQUIRED for that alone.
>> 
>> There is also the layer 9 interpretation issue here - if we say that DANE in its entirety requires DNSSEC then that message can be shouted loud and clear, reinforced and hopefully entrenched.  If we say that only some parts need it then people, for entirely fallible reasons, get confused, doubt DANE, can use this to attack DANE and so on.
> 
> I think this is an important consideration. However a relevant
> question for a 2119-level MUST seems
> to be whether we wish to have this data rejected if not DNSSEC signed.
> What's your view on that?

If unsigned then the data should be ignored.  That exactly maps to the current situation, which gives a clean split between that or using DANE as an all-or-nothing improvement on top of that.  

Jay 

> 
> -Ekr

-- 
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840

From: James Cloos <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC
Copyright: Copyright 2011 James Cloos
OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
Date: Wed, 30 Mar 2011 16:13:14 -0400
Lines: 20
Cc: [email-masked]
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models

>>>>> "RLB" = Richard L Barnes <[email-masked]> writes:

JC> If the attacker injects fake dns records pointing to a fake server, they
JC> can include a dane rr.  It only makes the attack slightly harder, doesn't it?

RLB> Yes, but as ekr pointed out, injecting fake DANE RRs can only cause
RLB> the connection to fail, it won't result in the client connecting to a
RLB> bogus server.  That's why it's RECOMMENDED instead of REQUIRED.

If an attacker is going to inject fake RRs, they will inject fake A
and/or AAAA RRs too, not only fake dane RRs.

So the attacker will direct the victem to its fake site with its fake
cert tree which matches the fake dane rr.

I don't see how that is any different than the (non-dnssec) status quo.

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

Date: Wed, 30 Mar 2011 22:20:21 +0200
From: Eric Rescorla <[email-masked]>
To: Jay Daley <[email-masked]>
Cc: Peter Palfrader <[email-masked]>, [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] CN/SAN matching (was: End entity certificate matching, trust anchors, and protocol-06)

On Wed, Mar 30, 2011 at 10:14 PM, Jay Daley <[email-masked]> wrote:
>
> On 31/03/2011, at 9:03 AM, Richard L. Barnes wrote:
>
>> Nope, it's up to applications. �If you want SN/CAN *not* to be checked for HTTPS, then you need to go revise RFC 2818; for SMTP, RFC 3207; for IMAP/POP3, RFC 2595.
>
> Indeed.
>
> I assumed we were updating RFC 2818.

In that case, this document will need to be dual last called in the
TLS WG, since 2818 was a TLS product.

-Ekr

Date: Wed, 30 Mar 2011 22:17:47 +0200
From: Eric Rescorla <[email-masked]>
To: Jay Daley <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models

On Wed, Mar 30, 2011 at 10:06 PM, Jay Daley <[email-masked]> wrote:
>
> On 31/03/2011, at 8:32 AM, Richard L. Barnes wrote:
>
>>>>>>>> "RLB" == Richard L Barnes <[email-masked]> writes:
>>>
>>> RLB> 1. Cert-lock / CA-lock
>>> RLB> 1.3. DNSSEC RECOMMENDED, not REQUIRED; attacker can only cause connection failure
>>>
>>> If the attacker injects fake dns records pointing to a fake server, they
>>> can include a dane rr. �It only makes the attack slightly harder, doesn't it?
>>
>> Yes, but as ekr pointed out, injecting fake DANE RRs can only cause the connection to fail, it won't result in the client connecting to a bogus server. � That's why it's RECOMMENDED instead of REQUIRED.
>
> That's still potentially a devastating DOS attack if done well and against an important target. �Worthy of a REQUIRED for that alone.
>
> There is also the layer 9 interpretation issue here - if we say that DANE in its entirety requires DNSSEC then that message can be shouted loud and clear, reinforced and hopefully entrenched. �If we say that only some parts need it then people, for entirely fallible reasons, get confused, doubt DANE, can use this to attack DANE and so on.

I think this is an important consideration. However a relevant
question for a 2119-level MUST seems
to be whether we wish to have this data rejected if not DNSSEC signed.
What's your view on that?

-Ekr

From: Jay Daley <[email-masked]>
Date: Thu, 31 Mar 2011 09:14:24 +1300
To: "Richard L. Barnes" <[email-masked]>
Cc: Peter Palfrader <[email-masked]>, [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] CN/SAN matching (was: End entity certificate matching, trust anchors, and protocol-06)

On 31/03/2011, at 9:03 AM, Richard L. Barnes wrote:

> Nope, it's up to applications.  If you want SN/CAN *not* to be checked for HTTPS, then you need to go revise RFC 2818; for SMTP, RFC 3207; for IMAP/POP3, RFC 2595.

Indeed.

I assumed we were updating RFC 2818.

As for RFC 3207 that says this gem, which is as much use as a chocolate teapot and so will need updating:

-  A SMTP client would probably only want to authenticate an SMTP
   server whose server certificate has a domain name that is the
   domain name that the client thought it was connecting to."

And RFC 2595 is going to need updating because the name check is specific:

   - The client MUST use the server hostname it used to open the
     connection as the value to compare against the server name as
     expressed in the server certificate.  The client MUST NOT use any
     form of the server hostname derived from an insecure remote source
     (e.g., insecure DNS lookup).  CNAME canonicalization is not done.

Jay

> 
> --Richard
> 
> 
> 
> On Mar 30, 2011, at 9:45 PM, Jay Daley wrote:
> 
>> I would argue the complete opposite - that it is in scope for DANE to state that names in certificates should not be checked because the trust chain has been provided by DNSSEC.  Doing that allows individuals and organisations to reuse certificates as they need to for operational reasons and not as dictated to by suppliers or paranoid protocol developers.
>> 
>> Jay
>> 
>> On 31/03/2011, at 12:55 AM, Richard L. Barnes wrote:
>> 
>>> This is outside of DANE's scope.  Checking of names in certificates is up to the application that uses TLS.
>>> --Richard
>>> 
>>> 
>>> On Mar 30, 2011, at 1:19 PM, Stephen Kent wrote:
>>> 
>>>> At 11:14 AM +0200 3/30/11, Peter Palfrader wrote:
>>>>> On Mon, 21 Mar 2011, Paul Hoffman wrote:
>>>>> 
>>>>>> On Mar 21, 2011, at 6:04 AM, Peter Palfrader wrote:
>>>>>>> Why is it needed in the first place?
>>>>>> 
>>>>>> That's a very good question. I don't feel that it is a "need", but it
>>>>>> "makes some sense". That is, if I want to go to www.example.com, and I
>>>>>> get an A record for www.example.com, and I get a TLSA record for
>>>>>> _http._tcp.www.example.com, and I get a certificate that says "this
>>>>>> key is associated with www.somethingelse.com", what does it mean?
>>>>>> 
>>>>>> I can see both ways: "it doesn't matter what the cert says, we are
>>>>>> trusting the binding from the DNS" vs. "the cert needs to mean
>>>>>> something"? Jakob and I have that text in because a number of people
>>>>>> on the list were in the latter category, but it seems like a
>>>>>> reasonable question to ask separately.
>>>>> 
>>>>> I wonder if one approach here would be to require a match if, and only
>>>>> if, any naming attributes (CN, SubjectAltName) are in the certificate.
>>>>> 
>>>>> If there are no CN and no SAN attributes in the certificate then that
>>>>> would be acceptable too.
>>>>> 
>>>>> Cheers,
>>>>> Peter
>>>> 
>>>> A CN is a type of attribute in the Subject DN.  A SAN admits a variety of name types, some of which can have attributes. Do you mean to focus on DNS names as SANs or did you have a broader range of SANs in mind?
>>>> 
>>>> Steve
>>>> _______________________________________________
>>>> keyassure mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/keyassure
>>> 
>>> _______________________________________________
>>> keyassure mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/keyassure
>> 
>> 
>> -- 
>> Jay Daley
>> Chief Executive
>> .nz Registry Services (New Zealand Domain Name Registry Limited)
>> desk: +64 4 931 6977
>> mobile: +64 21 678840
>> 
> 

-- 
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840

From: Jay Daley <[email-masked]>
Date: Thu, 31 Mar 2011 09:06:46 +1300
To: Richard L. Barnes <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models

On 31/03/2011, at 8:32 AM, Richard L. Barnes wrote:

>>>>>>> "RLB" == Richard L Barnes <[email-masked]> writes:
>> 
>> RLB> 1. Cert-lock / CA-lock
>> RLB> 1.3. DNSSEC RECOMMENDED, not REQUIRED; attacker can only cause connection failure
>> 
>> If the attacker injects fake dns records pointing to a fake server, they
>> can include a dane rr.  It only makes the attack slightly harder, doesn't it?
> 
> Yes, but as ekr pointed out, injecting fake DANE RRs can only cause the connection to fail, it won't result in the client connecting to a bogus server.   That's why it's RECOMMENDED instead of REQUIRED.

That's still potentially a devastating DOS attack if done well and against an important target.  Worthy of a REQUIRED for that alone.

There is also the layer 9 interpretation issue here - if we say that DANE in its entirety requires DNSSEC then that message can be shouted loud and clear, reinforced and hopefully entrenched.  If we say that only some parts need it then people, for entirely fallible reasons, get confused, doubt DANE, can use this to attack DANE and so on.

Jay

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

-- 
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 30 Mar 2011 22:03:27 +0200
To: Jay Daley <[email-masked]>
Cc: Peter Palfrader <[email-masked]>, [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] CN/SAN matching (was: End entity certificate matching, trust anchors, and protocol-06)

Nope, it's up to applications.  If you want SN/CAN *not* to be checked for HTTPS, then you need to go revise RFC 2818; for SMTP, RFC 3207; for IMAP/POP3, RFC 2595.

--Richard

On Mar 30, 2011, at 9:45 PM, Jay Daley wrote:

> I would argue the complete opposite - that it is in scope for DANE to state that names in certificates should not be checked because the trust chain has been provided by DNSSEC.  Doing that allows individuals and organisations to reuse certificates as they need to for operational reasons and not as dictated to by suppliers or paranoid protocol developers.
> 
> Jay
> 
> On 31/03/2011, at 12:55 AM, Richard L. Barnes wrote:
> 
>> This is outside of DANE's scope.  Checking of names in certificates is up to the application that uses TLS.
>> --Richard
>> 
>> 
>> On Mar 30, 2011, at 1:19 PM, Stephen Kent wrote:
>> 
>>> At 11:14 AM +0200 3/30/11, Peter Palfrader wrote:
>>>> On Mon, 21 Mar 2011, Paul Hoffman wrote:
>>>> 
>>>>> On Mar 21, 2011, at 6:04 AM, Peter Palfrader wrote:
>>>>>> Why is it needed in the first place?
>>>>> 
>>>>> That's a very good question. I don't feel that it is a "need", but it
>>>>> "makes some sense". That is, if I want to go to www.example.com, and I
>>>>> get an A record for www.example.com, and I get a TLSA record for
>>>>> _http._tcp.www.example.com, and I get a certificate that says "this
>>>>> key is associated with www.somethingelse.com", what does it mean?
>>>>> 
>>>>> I can see both ways: "it doesn't matter what the cert says, we are
>>>>> trusting the binding from the DNS" vs. "the cert needs to mean
>>>>> something"? Jakob and I have that text in because a number of people
>>>>> on the list were in the latter category, but it seems like a
>>>>> reasonable question to ask separately.
>>>> 
>>>> I wonder if one approach here would be to require a match if, and only
>>>> if, any naming attributes (CN, SubjectAltName) are in the certificate.
>>>> 
>>>> If there are no CN and no SAN attributes in the certificate then that
>>>> would be acceptable too.
>>>> 
>>>> Cheers,
>>>> Peter
>>> 
>>> A CN is a type of attribute in the Subject DN.  A SAN admits a variety of name types, some of which can have attributes. Do you mean to focus on DNS names as SANs or did you have a broader range of SANs in mind?
>>> 
>>> Steve
>>> _______________________________________________
>>> keyassure mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/keyassure
>> 
>> _______________________________________________
>> keyassure mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/keyassure
> 
> 
> -- 
> Jay Daley
> Chief Executive
> .nz Registry Services (New Zealand Domain Name Registry Limited)
> desk: +64 4 931 6977
> mobile: +64 21 678840
> 

From: Jay Daley <[email-masked]>
Date: Thu, 31 Mar 2011 08:45:36 +1300
To: Richard L. Barnes <[email-masked]>
Cc: Peter Palfrader <[email-masked]>, [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] CN/SAN matching (was: End entity certificate matching, trust anchors, and protocol-06)

I would argue the complete opposite - that it is in scope for DANE to state that names in certificates should not be checked because the trust chain has been provided by DNSSEC.  Doing that allows individuals and organisations to reuse certificates as they need to for operational reasons and not as dictated to by suppliers or paranoid protocol developers.

Jay

On 31/03/2011, at 12:55 AM, Richard L. Barnes wrote:

> This is outside of DANE's scope.  Checking of names in certificates is up to the application that uses TLS.
> --Richard
> 
> 
> On Mar 30, 2011, at 1:19 PM, Stephen Kent wrote:
> 
>> At 11:14 AM +0200 3/30/11, Peter Palfrader wrote:
>>> On Mon, 21 Mar 2011, Paul Hoffman wrote:
>>> 
>>>> On Mar 21, 2011, at 6:04 AM, Peter Palfrader wrote:
>>>>> Why is it needed in the first place?
>>>> 
>>>> That's a very good question. I don't feel that it is a "need", but it
>>>> "makes some sense". That is, if I want to go to www.example.com, and I
>>>> get an A record for www.example.com, and I get a TLSA record for
>>>> _http._tcp.www.example.com, and I get a certificate that says "this
>>>> key is associated with www.somethingelse.com", what does it mean?
>>>> 
>>>> I can see both ways: "it doesn't matter what the cert says, we are
>>>> trusting the binding from the DNS" vs. "the cert needs to mean
>>>> something"? Jakob and I have that text in because a number of people
>>>> on the list were in the latter category, but it seems like a
>>>> reasonable question to ask separately.
>>> 
>>> I wonder if one approach here would be to require a match if, and only
>>> if, any naming attributes (CN, SubjectAltName) are in the certificate.
>>> 
>>> If there are no CN and no SAN attributes in the certificate then that
>>> would be acceptable too.
>>> 
>>> Cheers,
>>> Peter
>> 
>> A CN is a type of attribute in the Subject DN.  A SAN admits a variety of name types, some of which can have attributes. Do you mean to focus on DNS names as SANs or did you have a broader range of SANs in mind?
>> 
>> Steve
>> _______________________________________________
>> keyassure mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/keyassure
> 
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

-- 
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 30 Mar 2011 21:32:40 +0200
To: James Cloos <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models

>>>>>> "RLB" == Richard L Barnes <[email-masked]> writes:
> 
> RLB> 1. Cert-lock / CA-lock
> RLB> 1.3. DNSSEC RECOMMENDED, not REQUIRED; attacker can only cause connection failure
> 
> If the attacker injects fake dns records pointing to a fake server, they
> can include a dane rr.  It only makes the attack slightly harder, doesn't it?

Yes, but as ekr pointed out, injecting fake DANE RRs can only cause the connection to fail, it won't result in the client connecting to a bogus server.   That's why it's RECOMMENDED instead of REQUIRED.

Date: Wed, 30 Mar 2011 21:27:31 +0200
From: Eric Rescorla <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models

On Wed, Mar 30, 2011 at 8:18 PM, Martin Rex <[email-masked]> wrote:
> Eric Rescorla wrote:
>>
>> 1. Protecting against CA mis-issue (as in CA/cert lock).
>>
>> In the first case, the idea would be that the relying party would go
>> through its ordinary validation logic and if that failed, would reject
>> the certificate. However, if the validation succeeded,
>> it would check DNS and if that check failed, would then reject the
>> certificate. Only if both checks succeeded would the certificate
>> be accepted. [0] The objective of this type of mechanism would be
>> simply to defend against unauthorized certificate issuance.
>> Note that in this case, the DANE data need not be DNSSEC secured,
>> because an attacker who tampers with it will solely be able to
>> cause a connection failure, and in many cases (TLS, SSH, etc.)
>> an attacker with those capabilities can tamper with
>> the A record and block the connection that way.
>
> Maybe I'm dense at the moment, but I don't understand
> "the DANE data need not be DNSSEC secured".
>
> Without DNSSEC, you have a vulnerability, because you can not
> enforce a CA or EE cert lock. �An attacker can DNS-spoof DANE records
> for the mis-issued certs of his choice or DNS-spoof the absence
> of DANE records (and the absence of DANE records will be quite
> common for more than just a few days).

It's obviously better if DANE is DNSSEC secured, but it's not dangerous
if they aren't signed, since that just brings you back to where you were
without DANE. However, the DANE records can be set with fairly long
expiries (like HSTS), thus providing a partial firewall against comodo-type
problems.

-Ekr

From: Martin Rex <[email-masked]>
To: [email-masked] (Richard L. Barnes)
Date: Wed, 30 Mar 2011 20:43:46 +0200 (MEST)
Cc: [email-masked]
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models
Reply-To: [email-masked]

Richard L. Barnes wrote:
> 
> >> To follow up on my comments at the microphone, there are two potential
> >> objectives for
> >> technology of this type:
> >> 
> >> 1. Protecting against CA mis-issue (as in CA/cert lock).
> >> 2. Allowing TLS to work without getting a certificate from one of the
> >> established trust
> >> anchors.
> > 
> > 3. Enhancing privacy by reducing OCSP lookups to CA operators potentially
> > keeping statistics on these (as proven recently with Comodogate)
> 
> This is isomorphic to the use of domain-issued certs, case 2 above.
> If the TLS server is using a CA-issued cert, the client *should* use
> OCSP (or a CRL) to make sure it hasn't been revoked.  With a
> domain-issued cert, there's probably no place to go for OCSP.

Looking at the recent rush of Browser patches to address Commodogate,
I'm somewhat in doubt that certificate revocation ever really worked.

A sufficiently powerful attacker might be able to interfere with
OCSP lookups and CRL download attempts (making them fail at the
network level).  The necessesity to blacklist the mis-issued certs
seems to indicate that most browser did not (and maybe still don't)
check server certs for revocation when encountering a network error
trying to access OCSP or CRL download URLs from the server's cert.

-Martin

From: Martin Rex <[email-masked]>
To: [email-masked] (Eric Rescorla)
Date: Wed, 30 Mar 2011 20:18:37 +0200 (MEST)
Cc: [email-masked]
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models
Reply-To: [email-masked]

Eric Rescorla wrote:
> 
> 1. Protecting against CA mis-issue (as in CA/cert lock).
> 
> In the first case, the idea would be that the relying party would go
> through its ordinary validation logic and if that failed, would reject
> the certificate. However, if the validation succeeded,
> it would check DNS and if that check failed, would then reject the
> certificate. Only if both checks succeeded would the certificate
> be accepted. [0] The objective of this type of mechanism would be
> simply to defend against unauthorized certificate issuance.
> Note that in this case, the DANE data need not be DNSSEC secured,
> because an attacker who tampers with it will solely be able to
> cause a connection failure, and in many cases (TLS, SSH, etc.)
> an attacker with those capabilities can tamper with
> the A record and block the connection that way.

Maybe I'm dense at the moment, but I don't understand
"the DANE data need not be DNSSEC secured".

Without DNSSEC, you have a vulnerability, because you can not
enforce a CA or EE cert lock.  An attacker can DNS-spoof DANE records
for the mis-issued certs of his choice or DNS-spoof the absence
of DANE records (and the absence of DANE records will be quite
common for more than just a few days).

>
> 2. Allowing TLS to work without getting a certificate from one of the
>    established trust anchors.
>
>  [...]
>
> The draft to some extent conflates these two objectives, since it
> *both* injects a new trust anchor and restricts the list of potential
> certificates. It does not allow you to simply restrict
> the list of CAs/certificates without also injecting a new trust point.

Personally, I would also prefer if the information conveyed through
DANE would include a tag that clearly distinguishes "CA/cert lock" (for
a server cert issued under the traditional TLS X.509 PKI of browsers)
from a certificate path validation based solely on DNSSEC trust.

But ultimately, whoever gains control over the DNSSEC zone contents
will be able to preempt the validation under the traditional TLS X.509 PKI
for a server cert by supplying appropriately crafted DNSSEC-signed DANE
records.

Therefore, the existence of DANE will make DNS admins much more interesting
targets for attacks (as an alternative to attacking issuing procedures
of commercial CAs).

-Martin

From: James Cloos <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC
Copyright: Copyright 2011 James Cloos
OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
Date: Wed, 30 Mar 2011 11:56:36 -0400
Lines: 11
Cc: [email-masked]
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models

>>>>> "RLB" = Richard L Barnes <[email-masked]> writes:

RLB> 1. Cert-lock / CA-lock
RLB> 1.3. DNSSEC RECOMMENDED, not REQUIRED; attacker can only cause connection failure

If the attacker injects fake dns records pointing to a fake server, they
can include a dane rr.  It only makes the attack slightly harder, doesn't it?

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

From: James Cloos <[email-masked]>
To: [email-masked]
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC
Copyright: Copyright 2011 James Cloos
OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B  63E7 997A 9F17 ED7D AEA6
Date: Wed, 30 Mar 2011 11:52:41 -0400
Lines: 40
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models

>>>>> "ER" = Eric Rescorla <[email-masked]> writes:

ER> 1. Protecting against CA mis-issue (as in CA/cert lock).

I hadn't though of doing this as Eric later describes (such that dnssec
isn't required for this usage).

I can understand how even an unsigned specification that a resource
uses this-and-only-this CA might be an improvement over the status quo.

But isn't false RR injection combined with a matching false cert chain
still a relevant problem in that scenario?

Perhaps the rfc should spec that, but with a threat analysis.

ER> 2. Allowing TLS to work without getting a certificate from one
ER>    of the established trust anchors.

The above said, this is my primary motivation.  Commercial trust anchors
provide little value and significant burden.  

It isn't just about "convenience".

Obviously there is still a lot of third-party trust involved.  You have
to trust that the DS RRs are properly handled by the registrars, root &
tld zone operators, et al.

But we already have to trust them to do the same with the NS glue RRs.

Ie, if the NS glue is mishandled the game is over anyway.  So why not
trust them correctly to handle the DS glue, too?

The one thing that does become significantly more convenient, though,
is more frequent rollover.

Eric's second scenario should be DANE's primary mission.

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

From: Michael Richardson <[email-masked]>
To: [email-masked]
Date: Wed, 30 Mar 2011 17:28:22 +0200
Sender: [email-masked]
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models

>>>>> "Richard" = Richard L Barnes <[email-masked]> writes:
    Richard> Fair enough.  Revised version below allows for the
    Richard> possibility of short-circuiting based on exact match with
    Richard> an EE cert.  (Trying to maintain an integral version that
    Richard> can be called for consensus later.) 

okay, but is there a bit that tells the client which case they are
trying to implement?  Or do we even need such a thing?

Paul and I were discussing things from the point of view that the client
does one process only, and that it has to work for both cases.

1. client looks up A/AAAA record. DNSSEC recommended. If no DNSSEC,
          attacker can mis-direct connection.
2a. client initiates TCP socket to target. (Attacker may do IP-level
    redirection, even if A/AAAA is correct)
2b. client looks up DANE/TLSA record (if any).
3. If TLSA found, client adds DANE CA and/or EE certs to TA store,
   dropping all others (*)
4. Client performs normal TLS/PKIX checks.

This is secure for domain-managed authentication if DNSSEC.
This is is also secure for cert-lock even in the face of Comodogate.

This may fail for some corporate environments where there is a forced
proxy of all TLS connections to some auditing firewall device.
Apparently some vendors let you force new sets of trust anchors
to desktops so that the desktops will wind up trusting the official
man-in-the-middle device.   If in step 3, one drops that trust anchor,
then the MitM is detected.  This may be a feature or not.

The question that we came up with was: is the act of dropping other
trust anchors something that should be controlled by the owner the
domain via the TLSA record, or is this a question of local policy?

You *HAVE* to drop them to get the cert-lock to be effective.

    Richard> 1. Cert-lock / CA-lock
    Richard> 1.1. Use case:
    Richard> 1.1.1. Client initiates TLS connection and gets server cert chain
    Richard> 1.1.2. Client performs normal TLS/PKIX validation on cert chain
    Richard> 1.1.3. Client retrieves DANE records from DNS
    Richard> 1.1.4. DANE records specify EE or CA certs that MUST be present in cert chain
    Richard> 1.1.5. Client verifies that TLS cert chain meets DANE constraints
    Richard> 1.2. Security goal: Defend against issuance of other certs for this domain
    Richard> 1.3. DNSSEC RECOMMENDED, not REQUIRED; attacker can only cause connection failure

    Richard> 2. Domain-managed authentication
    Richard> 2.1. Use case:
    Richard> 2.1.1. Client retrieves DANE records from DNS
    Richard> 2.1.2. DANE records specify Trust Anchors for PKIX certificate validation
    Richard> 2.1.3. Client adds DANE CA certs to TA store (optionally, drops all others)
    Richard> 2.1.3. [TBD] If DANE provides EE cert, accept/reject based on exact match
    Richard> 2.1.4. Client initiates TLS connection and gets server cert chain
    Richard> 2.1.5. Client performs normal TLS/PKIX validation on cert chain
    Richard> 2.2. Security goal: Allow TLS to work without pre-configured TAs
    Richard> 2.3. DNSSEC REQUIRED; attacker can insert bogus TAs

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 30 Mar 2011 14:46:55 +0200
To: Eric Rescorla <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Musing on design based on proposed use cases

>> So the proposed validation algorithm would have roughly the following form:
>> A. Given a set of DANE records and a cert chain...
>> B. Verify that all DANE certs with the "critical" flag set are present in the cert chain
> 
> This seems problematic. Say what I'm trying to do is cert lock and I
> have multiple servers,
> each with its own cert. If I list all the certs, this will obvious break.

Fair enough.  Could also be "Verify that at least one DANE CA cert with the "critical" flag set is present in the cert chain".  Assuming that you never want to specify more than one cert in the chain (I don't see why you would).

--Richard

Date: Wed, 30 Mar 2011 14:43:52 +0200
From: Eric Rescorla <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Musing on design based on proposed use cases

Without endorsing this design overall...

On Wed, Mar 30, 2011 at 2:40 PM, Richard L. Barnes <[email-masked]> wrote:
> So I think the use cases EKR described are clear enough to design to -- and they're not satisfied by the current design. �ISTM that there will probably be a need for a couple of flags to distinguish the two semantics:
> 1. "critical": MUST require that this cert be present in the chain
> 2. "trusted": �MUST use this cert as a TA
> 3. "exclusive": Trusted + MUST NOT use any other TAs.
>
> The latter two come with a caveat: Clearly, the relying party can choose to ignore the DANE TAs, so the flag would be a recommendation from the domain owner to the relying party. �(There are clearly interactions between the flags, e.g., no "exclusive" without "trusted"; see table at the bottom. �There are also potential interactions between records w.r.t. the "exclusive" flag.)
>
> So the proposed validation algorithm would have roughly the following form:
> A. Given a set of DANE records and a cert chain...
> B. Verify that all DANE certs with the "critical" flag set are present in the cert chain

This seems problematic. Say what I'm trying to do is cert lock and I
have multiple servers,
each with its own cert. If I list all the certs, this will obvious break.

> C. [TBD-Consensus] If there is a "critical" EE cert, accept/reject based on exact match
> E. If any DANE record is flagged "exclusive", remove all TAs from the local TA store
> D. Add all DANE certs with the "trusted" flag set to the local TA store
> F. Perform normal PKIX validation

-Ekr

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 30 Mar 2011 14:42:48 +0200
To: Eric Rescorla <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models

Fair enough.  Revised version below allows for the possibility of short-circuiting based on exact match with an EE cert.  (Trying to maintain an integral version that can be called for consensus later.)

1. Cert-lock / CA-lock
1.1. Use case:
1.1.1. Client initiates TLS connection and gets server cert chain
1.1.2. Client performs normal TLS/PKIX validation on cert chain
1.1.3. Client retrieves DANE records from DNS
1.1.4. DANE records specify EE or CA certs that MUST be present in cert chain
1.1.5. Client verifies that TLS cert chain meets DANE constraints
1.2. Security goal: Defend against issuance of other certs for this domain
1.3. DNSSEC RECOMMENDED, not REQUIRED; attacker can only cause connection failure

2. Domain-managed authentication
2.1. Use case:
2.1.1. Client retrieves DANE records from DNS
2.1.2. DANE records specify Trust Anchors for PKIX certificate validation
2.1.3. Client adds DANE CA certs to TA store (optionally, drops all others)
2.1.3. [TBD] If DANE provides EE cert, accept/reject based on exact match
2.1.4. Client initiates TLS connection and gets server cert chain
2.1.5. Client performs normal TLS/PKIX validation on cert chain
2.2. Security goal: Allow TLS to work without pre-configured TAs
2.3. DNSSEC REQUIRED; attacker can insert bogus TAs

On Mar 30, 2011, at 2:27 PM, Eric Rescorla wrote:

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

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 30 Mar 2011 14:40:28 +0200
To: [email-masked]
Subject: [keyassure] Musing on design based on proposed use cases

So I think the use cases EKR described are clear enough to design to -- and they're not satisfied by the current design.  ISTM that there will probably be a need for a couple of flags to distinguish the two semantics:
1. "critical": MUST require that this cert be present in the chain
2. "trusted":  MUST use this cert as a TA
3. "exclusive": Trusted + MUST NOT use any other TAs.

The latter two come with a caveat: Clearly, the relying party can choose to ignore the DANE TAs, so the flag would be a recommendation from the domain owner to the relying party.  (There are clearly interactions between the flags, e.g., no "exclusive" without "trusted"; see table at the bottom.  There are also potential interactions between records w.r.t. the "exclusive" flag.)

So the proposed validation algorithm would have roughly the following form:
A. Given a set of DANE records and a cert chain...
B. Verify that all DANE certs with the "critical" flag set are present in the cert chain
C. [TBD-Consensus] If there is a "critical" EE cert, accept/reject based on exact match
E. If any DANE record is flagged "exclusive", remove all TAs from the local TA store 
D. Add all DANE certs with the "trusted" flag set to the local TA store
F. Perform normal PKIX validation

Submitted for consideration...
--Richard

CTE
000 [disallowed]
001 [disallowed]
010 MUST use as a TA
011 MUST NOT use any other TAs
100 MUST be present in cert chain
101 [disallowed]
110 MUST be present and used as a TA
111 MUST be present and used as only TA

Date: Wed, 30 Mar 2011 14:27:34 +0200
From: Eric Rescorla <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models

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

I don't think this last point has consensus. Certainly, in the case where the
certificate in question is the terminal certificate, I think at least
some people
don't care if it's invalid from a PKIX perspective.

-Ekr

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

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 30 Mar 2011 14:18:15 +0200
To: Eric Rescorla <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models

I agree with Ekr and Steve that these are the right goals.  I don't have any further goals to add.  Just trying to re-state in bullet-point form:

1. Cert-lock / CA-lock
1.1. Use case:
1.1.1. Client initiates TLS connection and gets server cert chain
1.1.2. Client performs normal TLS/PKIX validation on cert chain
1.1.3. Client retrieves DANE records from DNS
1.1.4. DANE records specify EE or CA certs that MUST be present in cert chain
1.1.5. Client verifies that TLS cert chain meets DANE constraints
1.2. Security goal: Defend against issuance of other certs for this domain
1.3. DNSSEC RECOMMENDED, not REQUIRED; attacker can only cause connection failure

2. Domain-managed authentication
2.1. Use case:
2.1.1. Client retrieves DANE records from DNS
2.1.2. DANE records specify Trust Anchors for PKIX certificate validation
2.1.3. Client adds DANE CA certs to TA store (optionally, drops all others)
2.1.3. Client initiates TLS connection and gets server cert chain
2.1.4. Client performs normal TLS/PKIX validation on cert chain
2.2. Security goal: Allow TLS to work without pre-configured TAs
2.3. DNSSEC REQUIRED; attacker can insert bogus TAs

On Mar 30, 2011, at 10:48 AM, Eric Rescorla wrote:

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

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 30 Mar 2011 13:55:48 +0200
To: Stephen Kent <[email-masked]>
Cc: Peter Palfrader <[email-masked]>, [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] CN/SAN matching (was: End entity certificate matching, trust anchors, and protocol-06)

This is outside of DANE's scope.  Checking of names in certificates is up to the application that uses TLS.
--Richard

On Mar 30, 2011, at 1:19 PM, Stephen Kent wrote:

> At 11:14 AM +0200 3/30/11, Peter Palfrader wrote:
>> On Mon, 21 Mar 2011, Paul Hoffman wrote:
>> 
>>> On Mar 21, 2011, at 6:04 AM, Peter Palfrader wrote:
>>> > Why is it needed in the first place?
>>> 
>>> That's a very good question. I don't feel that it is a "need", but it
>>> "makes some sense". That is, if I want to go to www.example.com, and I
>>> get an A record for www.example.com, and I get a TLSA record for
>>> _http._tcp.www.example.com, and I get a certificate that says "this
>>> key is associated with www.somethingelse.com", what does it mean?
>>> 
>>> I can see both ways: "it doesn't matter what the cert says, we are
>>> trusting the binding from the DNS" vs. "the cert needs to mean
>>> something"? Jakob and I have that text in because a number of people
>>> on the list were in the latter category, but it seems like a
>>> reasonable question to ask separately.
>> 
>> I wonder if one approach here would be to require a match if, and only
>> if, any naming attributes (CN, SubjectAltName) are in the certificate.
>> 
>> If there are no CN and no SAN attributes in the certificate then that
>> would be acceptable too.
>> 
>> Cheers,
>> Peter
> 
> A CN is a type of attribute in the Subject DN.  A SAN admits a variety of name types, some of which can have attributes. Do you mean to focus on DNS names as SANs or did you have a broader range of SANs in mind?
> 
> Steve
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 30 Mar 2011 13:54:48 +0200
To: Paul Wouters <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models

>> To follow up on my comments at the microphone, there are two potential
>> objectives for
>> technology of this type:
>> 
>> 1. Protecting against CA mis-issue (as in CA/cert lock).
>> 2. Allowing TLS to work without getting a certificate from one of the
>> established trust
>> anchors.
> 
> 3. Enhancing privacy by reducing OCSP lookups to CA operators potentially
> keeping statistics on these (as proven recently with Comodogate)

This is isomorphic to the use of domain-issued certs, case 2 above.  If the TLS server is using a CA-issued cert, the client *should* use OCSP (or a CRL) to make sure it hasn't been revoked.  With a domain-issued cert, there's probably no place to go for OCSP.

--Richard

Date: Wed, 30 Mar 2011 13:53:51 +0200
From: Eric Rescorla <[email-masked]>
To: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Another comment from the mic

On Wed, Mar 30, 2011 at 1:16 PM, Stephen Kent <[email-masked]> wrote:
> At 10:57 AM +0200 3/30/11, Eric Rescorla wrote:
>>
>> As I said at the mic, the vast majority of the certificate warnings
>> you see on the network
>> are not because of attacks, but rather are due to:
>>
>> - Self-signed certs
>> - Certificates from legitimate CAs which are uncompromised but invalid
>> for some technical
>> � reason (expired certs, trivial name mismatches, etc.)
>>
>> One of the purposes of my "permissive" case-2 model in my previous
>> email is to allow those
>> self-signed certificate servers to have verifiable credentials.
>> However, anything we do that
>> has the consequence that certificates which should verify don't for
>> mostly-irrelevant technical
>> reasons (e.g., certs which are validated by DANE but are expired or
>> have the wrong keyusage
>> bits) will defeat this purpose to some extent. Perhaps that's worth
>> doing in service of the correctness
>> of the validation chain, but it does need to be considered.
>>
>> -Ekr
>
> I fully agree with the goal of avoiding error messages that confuse a user,
> especially ones that make it hard to tell the difference between a sloppy
> admin and an attacker. �But, it may be hard to tell the difference in some
> cases :-). Maybe we can reduce the incidence of bad self-signed certs by
> providing better tools to generate these certs, and including defaults to
> make it easy to avoid the typical errors.

This seems like a very worthy goal.

-Ekr

Date: Wed, 30 Mar 2011 07:19:39 -0400
To: Peter Palfrader <[email-masked]>
From: Stephen Kent <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] CN/SAN matching (was: End entity certificate matching, trust anchors, and protocol-06)

At 11:14 AM +0200 3/30/11, Peter Palfrader wrote:
>On Mon, 21 Mar 2011, Paul Hoffman wrote:
>
>>  On Mar 21, 2011, at 6:04 AM, Peter Palfrader wrote:
>>  > Why is it needed in the first place?
>>
>>  That's a very good question. I don't feel that it is a "need", but it
>>  "makes some sense". That is, if I want to go to www.example.com, and I
>>  get an A record for www.example.com, and I get a TLSA record for
>>  _http._tcp.www.example.com, and I get a certificate that says "this
>>  key is associated with www.somethingelse.com", what does it mean?
>>
>>  I can see both ways: "it doesn't matter what the cert says, we are
>>  trusting the binding from the DNS" vs. "the cert needs to mean
>>  something"? Jakob and I have that text in because a number of people
>>  on the list were in the latter category, but it seems like a
>>  reasonable question to ask separately.
>
>I wonder if one approach here would be to require a match if, and only
>if, any naming attributes (CN, SubjectAltName) are in the certificate.
>
>If there are no CN and no SAN attributes in the certificate then that
>would be acceptable too.
>
>Cheers,
>Peter

A CN is a type of attribute in the Subject DN.  A SAN admits a 
variety of name types, some of which can have attributes. Do you mean 
to focus on DNS names as SANs or did you have a broader range of SANs 
in mind?

Steve

Date: Wed, 30 Mar 2011 07:13:08 -0400
To: Paul Wouters <[email-masked]>, Eric Rescorla <[email-masked]>
From: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models

At 4:51 AM -0400 3/30/11, Paul Wouters wrote:
>On Wed, 30 Mar 2011, Eric Rescorla wrote:
>
>>  To follow up on my comments at the microphone, there are two potential
>>  objectives for
>>  technology of this type:
>>
>>  1. Protecting against CA mis-issue (as in CA/cert lock).

Eric's text provide a good rationale for this, and I think a solid 
rationale is an important part of the requirements spec.  I would be 
a bit more precise, and note that the CAs that pose a threat are the 
TAs configured into the system, any CAs below those TAs, and any 
other CAs that have been accepted by the client as TAs.

>  > 2. Allowing TLS to work without getting a certificate from one of the
>>  established trust
>>  anchors.

right. also, don't we want the TAs acquired via DANE to be treated, 
for the session in question, to be as god as the configured TAs, 
i.e., yield no error messages/  (I'll duck for the moment the issue 
of EV certs and whether we ought
to have a DANE-validated icon, and what color it should be :-).)

>3. Enhancing privacy by reducing OCSP lookups to CA operators potentially
>keeping statistics on these (as proven recently with Comodogate)
>
>Paul

Presumably #3 applies only to the configured TAs (and their offspring), right?

Steve

Date: Wed, 30 Mar 2011 07:16:15 -0400
To: Eric Rescorla <[email-masked]>
From: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Another comment from the mic

At 10:57 AM +0200 3/30/11, Eric Rescorla wrote:
>As I said at the mic, the vast majority of the certificate warnings
>you see on the network
>are not because of attacks, but rather are due to:
>
>- Self-signed certs
>- Certificates from legitimate CAs which are uncompromised but invalid
>for some technical
>    reason (expired certs, trivial name mismatches, etc.)
>
>One of the purposes of my "permissive" case-2 model in my previous
>email is to allow those
>self-signed certificate servers to have verifiable credentials.
>However, anything we do that
>has the consequence that certificates which should verify don't for
>mostly-irrelevant technical
>reasons (e.g., certs which are validated by DANE but are expired or
>have the wrong keyusage
>bits) will defeat this purpose to some extent. Perhaps that's worth
>doing in service of the correctness
>of the validation chain, but it does need to be considered.
>
>-Ekr

I fully agree with the goal of avoiding error messages that confuse a 
user, especially ones that make it hard to tell the difference 
between a sloppy
admin and an attacker.  But, it may be hard to tell the difference in some
cases :-). Maybe we can reduce the incidence of bad self-signed certs 
by providing better tools to generate these certs, and including 
defaults to
make it easy to avoid the typical errors.

Steve

From: Yoav Nir <[email-masked]>
To: Eric Rescorla <[email-masked]>
Date: Wed, 30 Mar 2011 11:15:23 +0200
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models

On Mar 30, 2011, at 10:48 AM, Eric Rescorla wrote:

> To follow up on my comments at the microphone, there are two potential
> objectives for
> technology of this type:
> 
> 1. Protecting against CA mis-issue (as in CA/cert lock).
> 2. Allowing TLS to work without getting a certificate from one of the
> established trust
> anchors.

I think the current draft is mostly focused on the second objective. Unless we declare #2 to be a non-goal, a (web) client cannot do the regular PKIX validation of the certificate.

More specifically, with a type-2 certificate (CA cert in the record) you anyway have to validate the EE certificate using regular PKIX procedure, except that you replace the trust anchor store with the CA certificate in the DNS record. This makes sense for the 2nd objective, but not for the first (you could put the Verisign root certificate in the DNS record, but then you're protected from mis-issue only by the other CAs). So with a type #2 record, you get both objectives

With a type-1 certificate (EE cert in the record) you get objective #1, but how is a client to know whether it is intended to just compare bits or also to validate the certificate? As long as objective #2 is not a non-goal, the client can't rely on such a record containing a certificate that can be validated. Maybe we need three types of records: CA certificate, untrusted EE certificate, and PKIX EE certificate. In that case, I don't the what advantage an "untrusted EE certificate" has over bare keys. So maybe it should be: CA certificate, PKIX certificate (that needs to be validated) and bare keys. 

Date: Wed, 30 Mar 2011 11:14:16 +0200
From: Peter Palfrader <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] CN/SAN matching (was: End entity certificate	matching, trust anchors, and protocol-06)

On Mon, 21 Mar 2011, Paul Hoffman wrote:

> On Mar 21, 2011, at 6:04 AM, Peter Palfrader wrote:
> > Why is it needed in the first place?
> 
> That's a very good question. I don't feel that it is a "need", but it
> "makes some sense". That is, if I want to go to www.example.com, and I
> get an A record for www.example.com, and I get a TLSA record for
> _http._tcp.www.example.com, and I get a certificate that says "this
> key is associated with www.somethingelse.com", what does it mean?
> 
> I can see both ways: "it doesn't matter what the cert says, we are
> trusting the binding from the DNS" vs. "the cert needs to mean
> something"? Jakob and I have that text in because a number of people
> on the list were in the latter category, but it seems like a
> reasonable question to ask separately.

I wonder if one approach here would be to require a match if, and only
if, any naming attributes (CN, SubjectAltName) are in the certificate.

If there are no CN and no SAN attributes in the certificate then that
would be acceptable too.

Cheers,
Peter
-- 
                           |  .''`.       ** Debian **
      Peter Palfrader      | : :' :      The  universal
 http://www.palfrader.org/ | `. `'      Operating System
                           |   `-    http://www.debian.org/

Date: Wed, 30 Mar 2011 10:57:38 +0200
From: Eric Rescorla <[email-masked]>
To: [email-masked]
Subject: [keyassure] Another comment from the mic

As I said at the mic, the vast majority of the certificate warnings
you see on the network
are not because of attacks, but rather are due to:

- Self-signed certs
- Certificates from legitimate CAs which are uncompromised but invalid
for some technical
   reason (expired certs, trivial name mismatches, etc.)

One of the purposes of my "permissive" case-2 model in my previous
email is to allow those
self-signed certificate servers to have verifiable credentials.
However, anything we do that
has the consequence that certificates which should verify don't for
mostly-irrelevant technical
reasons (e.g., certs which are validated by DANE but are expired or
have the wrong keyusage
bits) will defeat this purpose to some extent. Perhaps that's worth
doing in service of the correctness
of the validation chain, but it does need to be considered.

-Ekr

Date: Wed, 30 Mar 2011 04:51:54 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Eric Rescorla <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models

On Wed, 30 Mar 2011, Eric Rescorla wrote:

> To follow up on my comments at the microphone, there are two potential
> objectives for
> technology of this type:
> 
> 1. Protecting against CA mis-issue (as in CA/cert lock).
> 2. Allowing TLS to work without getting a certificate from one of the
> established trust
> anchors.

3. Enhancing privacy by reducing OCSP lookups to CA operators potentially
keeping statistics on these (as proven recently with Comodogate)

Paul

Date: Wed, 30 Mar 2011 10:48:53 +0200
From: Eric Rescorla <[email-masked]>
To: [email-masked]
Subject: [keyassure] Objective: Restrictive versus Supplementary Models

To follow up on my comments at the microphone, there are two potential
objectives for
technology of this type:

1. Protecting against CA mis-issue (as in CA/cert lock).
2. Allowing TLS to work without getting a certificate from one of the
established trust
anchors.

In the first case, the idea would be that the relying party would go
through its ordinary validation
logic and if that failed, would reject the certificate. However, if
the validation succeeded,
it would check DNS and if that check failed, would then reject the
certificate. Only if both
checks succeeded would the certificate be accepted. [0] The objective
of this type of
mechanism would be simply to defend against unauthorized certificate issuance.
Note that in this case, the DANE data need not be DNSSEC secured,
because an attacker
who tampers with it will solely be able to cause a connection failure,
and in many cases
(TLS, SSH, etc.) an attacker with those capabilities can tamper with
the A record and
block the connection that way.

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

The draft to some extent conflates these two objectives, since it
*both* injects a new trust
anchor and restricts the list of potential certificates. It does not
allow you to simply restrict
the list of CAs/certificates without also injecting a new trust point.

Opinion follows:
For my money the most important driving use case for this work is the
first case, for two
reasons. First, it's the more pressing problem since it's not really
*that* hard to get a
certificate from one of the existing CAs, but this also means that we
have to worry about
mis-issue by misbehaving CAs, as we have recently seen. Second, the
incremental deployment
story is much easier, since clients which don't speak DANE will just
not be protected against
attack, whereas in the second case clients which don't speak DANE will
experience certificate
errors when connecting to a DANE-only site.

-Ekr

[0] The checks can be done in either order. This is only for clarity.

Date: Wed, 30 Mar 2011 02:54:01 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Zack Weinberg <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] PROPOSAL: Revision of DANE client requirements

On Tue, 29 Mar 2011, Zack Weinberg wrote:

[more later after the WG meeting]

> Do you have a link to your proposal?  

ftp://ftp.xelerance.com/tls-oob/

Note that I have not finished it yet. Please consider it a pre-release

Paul

Sender: [email-masked]
Date: Tue, 29 Mar 2011 16:23:52 -0700
From: Zack Weinberg <[email-masked]>
To: Jay Daley <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] TLSA record does not mandate the given certificate

On Mon, Mar 28, 2011 at 6:27 PM, Jay Daley <[email-masked]> wrote:
>>> 1.  How is the current text in 3. not good enough?
>>>
>>> "If a match between one of the certificate association(s) and the
>>>   server's end entity certificate in TLS is found, the TLS client
>>>   continues the TLS handshake.  If no match between the usable
>>>   certificate association(s) and the server's end entity certificate in
>>>   TLS is found, the TLS client MUST abort the handshake with an
>>>   "access_denied" error."
>>
>> Only in being more confusing than I would like.  I think it's vital to
>> be crystal clear how a client should behave in all cases.
>
> Sorry to be a pain, but I struggle to see how this is confusing.  Can you explain?

Had to think about it for a while, but my big problem with it is the
"match between one of the certificate associations and the end entity
certificate" language.   An _association_ is a weird thing to _match_.

There is also a jumble of MUST-language and non-MUST language in here
("the TLS client continues" versus "the TLS client MUST abort".

>>> "A DANE client must determine whether the certificate bundle provided in the TLS handshake from a server found at a domain name matches a trusted TLSA record for that domain name.  If it does not ..."
>>
>> I changed the terminology (see text above this),
>
> I'm not sure what you are referring to.  Did I miss some text?

The "definitions" section in my proposal.  The way you'd say this in
my language is

   ... must determine whether the server's certificate bundle ... can
be associated with the
   server's domain name by at least one of the TLSA records for that
domain name ...

Note how the TLSA record is not itself an "association", it's just a
"record", whose effect is to _match_ one of the certificates in the
in-band bundle, and thus form an association between the bundle and
the _name_.

In my next draft, having taken on board some of Paul Wouters'
comments, I think I'll say that the association is between the
_server_ and the name.

zw

Sender: [email-masked]
Date: Tue, 29 Mar 2011 16:09:07 -0700
From: Zack Weinberg <[email-masked]>
To: Paul Wouters <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] PROPOSAL: Revision of DANE client requirements

On Tue, Mar 29, 2011 at 2:24 AM, Paul Wouters <[email-masked]> wrote:
>
> I think the client should decide which trust models (DANE, PKIX, others)
> it intends to trust. I do not think these trust models should make
> statements about the other models. The original section 3 starts out
> with doing this ("MUST be marked as unusable." [Paul: by DANE])
> correctly, but then later on assumes DANE trumps everything ("MUST abort
> the handshake ")

We disagree so profoundly that I can only conclude you have an
entirely different notion of what DANE is good for than I do.

Here's how I see it: The gating audience for DANE is site admins, who
must be persuaded that adding TLSA records (and DNSSEC signatures) to
their zones is a valuable thing for them to do.  Site admins are not
going to go for this pitch:  "If you put TLSA records in your zone and
sign it, then DANE-compliant clients will do something with that
information.  We can't tell you what, because we thought that policy
should be up to the client.  Some of your users might get some sort of
security benefit out of it.  Others might find themselves unable to
use your site."

They are much more likely to go for this pitch: "If you put TLSA
records in your zone and sign it, then all DANE-compliant clients will
react to those records in this predictable fashion: [....] This
protects those users from these actual security threats: [....]
However, if your site is ever misconfigured in this specific way:
[...] then it will become inaccessible to DANE-compliant clients, so
you need to make sure that your operational procedures never let that
happen."

Therefore, I do not think the client should decide who to trust.  I
think DANE needs to decide and specify that decision with as little
wiggle room as possible, and I think it *especially* needs to specify
what to do when DANE disagrees with other trust models (PKIX being the
only such at present).  And that's what I've tried to do with my
revisions.

>> Second, I have added constraints on client behavior based on DNSSEC
>> status alone.  This is arguably out of scope for this standard, but
>> I think the additions are necessary to preserve the security benefits
>> of DANE in the presence of active tampering with the DNS.
>
> DNSSEC should be a requirement for DANE. I thought this was already in
> the 06 draft? Ah, it is in Section 3.

The new requirement I added is "MUST NOT proceed with a connection to
a server if the DNSSEC validation status is 'bogus' for _any_ DNS
records relating to that server".  The old language could be read to
say that TLSA records should be _ignored_ when DNSSEC validation came
back "bogus", and did not state anything about what should happen if
the TLSA record was properly signed but the A record was bogus.

With my wording, the only way an attacker with the power to tamper
with DNS responses can downgrade a client to backward-compatible
PKIX-only mode (for a server that does provide signed TLSA records) is
by suppressing _all_ DNSSEC information.  I think this is a valuable
property.

>> Section 1.2: Delete the sentence "The DNSSEC signature MUST be
>> validated on all responses in order to assure the proof of origin of
>> the data" and the subsequent paragraph break.  (An equivalent, but
>> more specific, requirement will reappear in section 3.)
>
> I think it would be good to state the relationship between DNSSEC and TLSA
> at the beginning of the draft. I agree that this sentence is not the best,
> because it kind of implies the client has to do the validation itself from
> the root down, and not trust the AD bit on responses received from its
> (secure) connection to a validating name server, which I think is not what
> the authors intended. Though it is clarified in the orignal section 3.

The main reason I proposed modifications to sections 1 and 2 is to
_consolidate_ all requirements upon the client in section 3, for
clarity's sake.  I'd be okay with leaving an informative sentence
early in the document along the lines of "TLSA records are only useful
for security when the DNS zone they appear in is protected from
tampering by DNSSEC signatures", but I want that to be redundant to
normative, MUST-requirement text in section 3.

...
>>    If it is desired to use other certificate
>>   formats with this specification in the future, those formats must
>>   be assigned their own certificate type numbers, and the definition
>>   of "associated" in section 3.1 of this specification must be revised
>>   appropriately.
>
> I am not sure if this is required after the previous paragraph.

I wouldn't especially miss it, but equivalent language was in the -06
draft and I didn't see any harm in preserving it.

> Note also that in the future, there will be other type of TLSA records not
> involving PKIX certificates, such as those containing just bare public keys.
> Ideally, I would like to see a different name for "certificate type" and
> call it "identifier type" or something. Then part of this text should move
> to the section describing the type 1 and type 2 identifiers specifically.

I would support that change.  However, I feel it is off-topic for this
change proposal, which I would prefer to keep focused on nailing down
client behavior.

>>   The primary purpose of TLSA records is security.  However, TLSA
>>   information might also be useful for protocol optimizations that
>>   require advance knowledge of what the server's end-entity
>>   certificate should be.  Clients that use TLSA information only for
>>   such optimizations, and not for security decisions, are exempt
>>   from all other requirements in this section.
>
> I assume you are trying to say that client/servers supporting this could
> skip the exchange of PKIX information in the TLS handshake.

Sort of.  I was specifically thinking of snap start [
http://tools.ietf.org/html/draft-agl-tls-snapstart-00 ] when I wrote
that paragraph - that perhaps having the end-entity certificate
out-of-band would allow a client to do snap start on the first
connection to a previously unknown server.  Having reread the snap
start spec, it looks like that won't work (the client needs to know
several other things) and even if it did, it would be a bad idea to do
it on insecure/indeterminate data.  And it's off topic anyway.  I will
drop this part of the proposal.

>>   Clients that make security decisions based on TLSA information
>>   MUST be, or have access to, security-aware DNS resolvers as
>>   defined by RFC 4033.  The rest of this section applies only to
>>   such clients, which will be referred to as "DANE clients".
>
> This is a DANE document, you cannot really say in the above paragraph that
> such a client using insecure TLSA from DNSSEC is not a "DANE client".
> Clients
> using this draft/rfc are "DANE clients".

Dropping the optimization-only text would render this moot, I think?
I could just say "Clients MUST themselves be, or have secure access
to, security-aware DNS resolvers" and scrap the "DANE client" wording
below.

>> 3.1. Definitions
>>
>>   A certificate received in the TLS handshake is said to _match_ a
>>   TLSA record if:
>>
>>   o  The TLSA record has reference type 0 and the certificate from
>>      the handshake is byte-for-byte identical to the certificate for
>>      association; or
>>
>>   o  The TLSA record has some other reference type, and the hash of
>>      the certificate from the handshake (using the hash algorithm
>>      specified by the reference type) is byte-for-byte identical to
>>      the certificate for association.
>
> With my proposed TLS extension, the whole PKIX transmission could be
> suppressed, but this paragraph assumes it is always sent.

Do you have a link to your proposal?  I'm happy to adjust the wording
appropriately - the intent is just to be clear about what exactly is
being "matched".

> I also get
> nervous about terms lie "byte for byte" since we have things like network
> ordered bytes.

Fair point, but the comparison function needs to be specified
precisely - "identical" is not precise in my book - and pace Peter
Gutmann's complaints about "memcmp() is the only way to compare PKIX
certificates", I don't know a better option than "byte-for-byte".
Maybe the thing to do is nail down the byte order of the certificate
for association in section 2.

>>   A certificate bundle received in the TLS handshake is said to be
>>   _associated_ with a domain name by DANE, if a TLSA record for the
>>   host, protocol, and port exists, the end-entity certificate in the
>>   bundle contains a name record that matches the host, and:
>
> I see more people using wildcard certs (*.xelerance.com) which would not
> match "a name record"....

I'm open to suggestions for better wording here.  I don't have a lot
of experience with DNS wildcards _or_ certificate wildcards.

>>   DANE clients MUST NOT proceed with a connection to a server if the
>>   DNSSEC validation status is "bogus" for _any_ DNS records relating
>>   to that server.
>
> Don't say "connection". Say that the "DANE trust path" must be aborted. The
> client might still do PKIX or other methods. The DANE specification should
> not forbid those so it should not dictate to close the connection.

On the contrary.  If DANE can't dictate a connection abort it is
useless, and if DANE allows a client to proceed with a connection when
DNSSEC signature checks have come back "bogus", a DNS-tampering
attacker can subvert it.

The DANE specification _absolutely must_ dictate a connection abort
under these circumstances.  If equivalent wording is not in the final
draft I will raise a formal objection (or whatever the appropriate
term is, sorry, I know W3C procedure a lot better than IETF
procedure).

>>   DANE clients MUST ignore TLSA records whose DNSSEC validation
>>   status is "insecure" or "indeterminate" (however, such records MAY
>>   be used for TLS handshake optimizations as mentioned above).
>
> See above. I still don't understand this "insecure use" of TLSA.

Will drop the parenthetical.  Do you agree that ignoring the record is
the Right Thing when DNSSEC validation comes back insecure or
indeterminate?

>>   A TLSA record whose DNSSEC status is "secure", and whose
>>   certificate and hash types are understood by the client processing
>>   it, will henceforth be referred to as a _trusted_ TLSA record.
>
> Again, I don't agree with a "untrusted TLSA record" concept.

This is just meant to make it unambiguous, below, that records that
were ignored for lack of a zone signature, or because the client
doesn't understand the type codes, do not count.  Maybe I should
replace "trusted" with "usable"?

> I think we definitely need to discuss the "no others" part. I can see
> its use to ignore any bogus PKIX issued certificates, but I don't think
> this should be a zone administrator decision. It should probably be a client
> decision to disable PKIX or disable PKIX in the precense of DANE records.

It has to be a zone administrator decision, so that the zone
administrator knows the consequences of adding TLSA records to their
zone (see discussion way up top).  Leaving this as an application
decision will only ensure that nobody uses DANE.

>>   However, if there is any _other_ reason why a server's end-entity
>>   certificate would have been rejected in the absence of TLSA
>>   information, a DANE client SHOULD still reject that certificate.
...
> I would say if you store full PKIX into DNS then you should ensure that
> both the DNS and the PKIX information is valid, and reject it if either
> one fails.

That was in fact the intent of my text.  How was it unclear?

> Especially if a method is available where you can store the
> bare public key in DNS and avoid all these conflicts.

I'm good with a bare-public-key option but I will not make this
proposal depend on the addition of a bare-public-key option.  The WG
has been arguing over bare public keys for weeks now, and I've got
plenty of potential for controversy in here already, thanks.

>>   DANE associations provide a trust anchor _only_ for end-entity
>>   certificates, even if the TLSA record has certificate type 2.
>>   A DANE client MUST NOT allow any non-end-entity certificate in
>>   a certificate bundle that is anchored by a DANE association to
>>   become trusted for any domain name other than the one in the
>>   original association.
>
> This might get complicated with wildcards, both in DNS as well as in
> the CN= or SubjectAltname=

The intent is to trust only the end-entity cert and only for the
domain name that was *queried*.  Please suggest wording improvements.

>>   DANE does not assure any information in a certificate other than
>>   the public key and its binding to host, protocol, and port.
>
> This is a real problem, as clients would have to store the certificate
> in their certificate pool, yet mark it was obtained by DANE and/or what
> parts were validated. I was told by at least one major browser vendor
> that this is a serious problem. I would say that if the entire cert
> was in DANE, then DANE assures ALL the information in that certificate.
> After all, the RRSIG was over the entire certificate.

What I'm really going after here is the DV/EV distinction; I want to
specify that DANE does _not_ provide EV.  However, EV is a marketing
term rather than a technical term, so it doesn't belong in a spec like
this.  The _effect_ of EV is, if a certificate is signed by a
particular CA certificate, then more of the name fields are considered
trustworthy.  So by saying "does not assure any information other than
..." I was trying to specify a similar effect (or rather, the absence
of a similar effect). Again, I'm open to wording improvements.

>> 3.5. User override
>>
>>   DANE clients SHOULD NOT allow their human users to force the
>>   establishment of a connection that has been aborted for any of the
>>   reasons listed in sections 3.2 or 3.3.
>
> That's not up to the network protocol to decide.

That's why it's a SHOULD rather than a MUST (and why there is a
specific example of an application that might ignore the
recommendation).  But I think it's important to have this advice to
applications in the spec, again, so that the behavior of clients is
predictable - in this case, so that site admins can assume fail-hard
behavior.

> Even if you state it here, it will get ignored.

I will be making efforts to ensure it doesn't for HTTPS (by working
with browser vendors).

zw

Sender: [email-masked]
Date: Tue, 29 Mar 2011 08:09:15 -0700
From: Zack Weinberg <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] TLSA record does not mandate the given certificate

On Tue, Mar 29, 2011 at 1:43 AM, Richard L. Barnes <[email-masked]> wrote:
> I actually really disagree with the idea that DANE would be some parallel, alternative path to PKIX validation.  If DANE is going to be meaningful, it needs to be able to cause the TLS handshake to fail -- this is the correct behavior when the server says (through DANE) that things should be one way and they aren't.

I concur with this.  I see this as possibly *the* security benefit
relative to the status quo.

zw

Date: Tue, 29 Mar 2011 15:36:33 +0200
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ=?= <[email-masked]>
To: "Richard L. Barnes" <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Administrivia: Rename the mailing list to [email-masked]

Either he will, or I'll take care of it.

O.

On 29.3.2011 15:27, Richard L. Barnes wrote:
> Is the listmaster moving everyone over, or do we have to re-subscribe?
> --Richard
>
> On Mar 29, 2011, at 3:18 PM, Ondřej Surý wrote:
>
>> Hi,
>>
>> this is a reminder, that the mailing list will be renamed to the [email-masked] after the IETF.  I already spoke to listmaster and he needs just couple of days, so I thought it might be a good idea to do that while everybody is travelling home.
>>
>> So, if the [email-masked] starts bouncing, use [email-masked].  I'll try to make sure everything else works (aka the subscriber list is the same) and I will send the announce message after the move is done.
>>
>> If you adjust your filters before you will not probably notice the move at all :).
>>
>> O.
>>
>> On 1.2.2011 15:18, Ondřej Surý wrote:
>>> Hi,
>>>
>>> I would like to ask the listmaster to rename the mailing list to
>>> [email-masked] to keep it with sync with the WG name.
>>>
>>> Any objections?
>>>
>>> I'll keep you posted on the dates, etc. when I know more details.
>>>
>>> Ondrej
>>
>>
>> --
>> Ondřej Surý
>> vedoucí výzkumu/Head of R&D department
>> -------------------------------------------
>> CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
>> Americka 23, 120 00 Praha 2, Czech Republic
>> mailto:[email-masked]    http://nic.cz/
>> tel:+420.222745110       fax:+420.222745112
>> -------------------------------------------
>> _______________________________________________
>> keyassure mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/keyassure
>

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

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 29 Mar 2011 15:27:30 +0200
To: =?utf-8?Q?Ondřej_Surý?= <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Administrivia: Rename the mailing list to [email-masked]

Is the listmaster moving everyone over, or do we have to re-subscribe?
--Richard

On Mar 29, 2011, at 3:18 PM, Ondřej Surý wrote:

> Hi,
> 
> this is a reminder, that the mailing list will be renamed to the [email-masked] after the IETF.  I already spoke to listmaster and he needs just couple of days, so I thought it might be a good idea to do that while everybody is travelling home.
> 
> So, if the [email-masked] starts bouncing, use [email-masked].  I'll try to make sure everything else works (aka the subscriber list is the same) and I will send the announce message after the move is done.
> 
> If you adjust your filters before you will not probably notice the move at all :).
> 
> O.
> 
> On 1.2.2011 15:18, Ondřej Surý wrote:
>> Hi,
>> 
>> I would like to ask the listmaster to rename the mailing list to
>> [email-masked] to keep it with sync with the WG name.
>> 
>> Any objections?
>> 
>> I'll keep you posted on the dates, etc. when I know more details.
>> 
>> 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

Date: Tue, 29 Mar 2011 15:18:35 +0200
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ=?= <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Administrivia: Rename the mailing list to [email-masked]

Hi,

this is a reminder, that the mailing list will be renamed to the 
[email-masked] after the IETF.  I already spoke to listmaster and he 
needs just couple of days, so I thought it might be a good idea to do 
that while everybody is travelling home.

So, if the [email-masked] starts bouncing, use [email-masked].  I'll 
try to make sure everything else works (aka the subscriber list is the 
same) and I will send the announce message after the move is done.

If you adjust your filters before you will not probably notice the move 
at all :).

O.

On 1.2.2011 15:18, Ondřej Surý wrote:
> Hi,
>
> I would like to ask the listmaster to rename the mailing list to
> [email-masked] to keep it with sync with the WG name.
>
> Any objections?
>
> I'll keep you posted on the dates, etc. when I know more details.
>
> Ondrej

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

Date: Tue, 29 Mar 2011 05:24:09 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Zack Weinberg <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] PROPOSAL: Revision of DANE client requirements

On Mon, 28 Mar 2011, Zack Weinberg wrote:

> The exceptions are: First, it is not clear to me whether the present
> intent of the spec is that a TLSA record for site S specifying
> certificate X forbids a compliant client from proceeding with the
> handshake if it receives certificate Y.  I think the answer to this
> question must be an unambiguous "yes", and I have made changes to that
> effect in my edits.  If the answer is meant to be "no", then I will
> have to raise a formal objection, because that would IMHO mean that
> DANE provided no improvements over the status quo.

I think the client should decide which trust models (DANE, PKIX, others)
it intends to trust. I do not think these trust models should make
statements about the other models. The original section 3 starts out
with doing this ("MUST be marked as unusable." [Paul: by DANE])
correctly, but then later on assumes DANE trumps everything ("MUST abort
the handshake ")

> Second, I have added constraints on client behavior based on DNSSEC
> status alone.  This is arguably out of scope for this standard, but
> I think the additions are necessary to preserve the security benefits
> of DANE in the presence of active tampering with the DNS.

DNSSEC should be a requirement for DANE. I thought this was already in
the 06 draft? Ah, it is in Section 3.

> Third, I have added text about a potential non-security use of TLSA
> records -- to enable TLS handshake optimizations -- and about user
> override of TLSA-based rejection of a certificate.  These were not
> addressed in the current draft, but I believe they add value.

> Section 1.2: Delete the sentence "The DNSSEC signature MUST be
> validated on all responses in order to assure the proof of origin of
> the data" and the subsequent paragraph break.  (An equivalent, but
> more specific, requirement will reappear in section 3.)

I think it would be good to state the relationship between DNSSEC and TLSA
at the beginning of the draft. I agree that this sentence is not the best,
because it kind of implies the client has to do the validation itself from
the root down, and not trust the AD bit on responses received from its
(secure) connection to a validating name server, which I think is not what
the authors intended. Though it is clarified in the orignal section 3.

> Section 1.3: Delete the entire second paragraph.

Agreed. My reasoning being that DANE should not exlucde PKIX (just like PKIX
should not be allowed to exclude DANE). This should be a client choice.
See above on the contraction in the original section 3.

> Section 2.2: Replace the paragraph that begins "Both types are
> structured ..." with this text:
>
>    Certificates of type 1 and 2 MUST be in PKIX format: that is, they
>    must be structured according to the formatting rules in RFC 5280,
>    and encoded using ASN.1 DER.  However, as described in section 3.4,
>    type 1 certificates do not need to adhere to all the semantic
>    rules in RFC 5280.

This sounds okay.

>     If it is desired to use other certificate
>    formats with this specification in the future, those formats must
>    be assigned their own certificate type numbers, and the definition
>    of "associated" in section 3.1 of this specification must be revised
>    appropriately.

I am not sure if this is required after the previous paragraph.

Note also that in the future, there will be other type of TLSA records not
involving PKIX certificates, such as those containing just bare public keys.
Ideally, I would like to see a different name for "certificate type" and
call it "identifier type" or something. Then part of this text should move
to the section describing the type 1 and type 2 identifiers specifically.

> Section 3: Replace entire section with this text:
>
> 3. Client application behavior in the presence of TLSA records
>
>    The primary purpose of TLSA records is security.  However, TLSA
>    information might also be useful for protocol optimizations that
>    require advance knowledge of what the server's end-entity
>    certificate should be.  Clients that use TLSA information only for
>    such optimizations, and not for security decisions, are exempt
>    from all other requirements in this section.

I assume you are trying to say that client/servers supporting this could
skip the exchange of PKIX information in the TLS handshake. In fact, that
is pretty much what my draft for "TLS Extensions for out of bound public
key validation" adds an option for. However, the above paragraph stating
something like "you can use this info but not treat it as secure" makes me
very nervous. I would be uncomfortable introducing a concept of "insecurely
obtaining TLS public keys from DNS". My TLS extension draft addresses this
by saying the TLS client could have cached the TLS public key from a previous
handshake or have obtained this via another secure(!) method like DANE or LDAP.

>    Clients that make security decisions based on TLSA information
>    MUST be, or have access to, security-aware DNS resolvers as
>    defined by RFC 4033.  The rest of this section applies only to
>    such clients, which will be referred to as "DANE clients".

This is a DANE document, you cannot really say in the above paragraph that
such a client using insecure TLSA from DNSSEC is not a "DANE client". Clients
using this draft/rfc are "DANE clients".

> 3.1. Definitions
>
>    A certificate received in the TLS handshake is said to _match_ a
>    TLSA record if:
>
>    o  The TLSA record has reference type 0 and the certificate from
>       the handshake is byte-for-byte identical to the certificate for
>       association; or
>
>    o  The TLSA record has some other reference type, and the hash of
>       the certificate from the handshake (using the hash algorithm
>       specified by the reference type) is byte-for-byte identical to
>       the certificate for association.

With my proposed TLS extension, the whole PKIX transmission could be
suppressed, but this paragraph assumes it is always sent. I also get
nervous about terms lie "byte for byte" since we have things like network
ordered bytes.

>    A certificate bundle received in the TLS handshake is said to be
>    _associated_ with a domain name by DANE, if a TLSA record for the
>    host, protocol, and port exists, the end-entity certificate in the
>    bundle contains a name record that matches the host, and:

I see more people using wildcard certs (*.xelerance.com) which would not
match "a name record"....

>    o  The TLSA record has certificate type 1, and it matches the
>       end-entity certificate in the bundle; or
>
>    o  The TLSA record has certificate type 2, it matches one of the
>       non-end-entity certificates in the bundle, and the end-entity
>       certificate in the bundle has a valid chain to the certificate
>       that matched the TLSA record.
>
> 3.2. DNSSEC validation
>
>    DANE clients MUST NOT proceed with a connection to a server if the
>    DNSSEC validation status is "bogus" for _any_ DNS records relating
>    to that server.

Don't say "connection". Say that the "DANE trust path" must be aborted. The
client might still do PKIX or other methods. The DANE specification should
not forbid those so it should not dictate to close the connection.

>    DANE clients MUST ignore TLSA records whose DNSSEC validation
>    status is "insecure" or "indeterminate" (however, such records MAY
>    be used for TLS handshake optimizations as mentioned above).

See above. I still don't understand this "insecure use" of TLSA. Either you
obtained it securely outside of DANE to use, in which case DANE does not apply,
or you only got it via DANE, in which case you should not use it if it was not
secured. One DoS attack I could imagine here is spoofing bogus DANE records and
the client trying to "optimise" to the server and botching the TLS handshake
repeatedly.

>    DANE clients MUST also ignore TLSA records whose certificate type
>    or hash type they do not understand.
>
>    A TLSA record whose DNSSEC status is "secure", and whose
>    certificate and hash types are understood by the client processing
>    it, will henceforth be referred to as a _trusted_ TLSA record.

Again, I don't agree with a "untrusted TLSA record" concept.

> 3.3. DANE validation
>
>    The presence in the DNS of a trusted TLSA record is an assertion
>    by the zone administrator that the legitimate server(s) for that
>    host, protocol, and port will use certificate bundles that can be
>    associated with the domain name by that record (as defined in
>    section 3.1), and no others.

I think we definitely need to discuss the "no others" part. I can see
its use to ignore any bogus PKIX issued certificates, but I don't think
this should be a zone administrator decision. It should probably be a client
decision to disable PKIX or disable PKIX in the precense of DANE records.

>    However, if there is any _other_ reason why a server's end-entity
>    certificate would have been rejected in the absence of TLSA
>    information, a DANE client SHOULD still reject that certificate.

This is the fundamental problem of storing things like "Validity"
of the PKIX into a DNS record with a validatity based on TTL/RRSIG
lifetimes. This is also why I am writing the DANE public key draft, which
has as one of its goals not to add possibly contradicting information
from PKIX into DNS.

I would say if you store full PKIX into DNS then you should ensure that
both the DNS and the PKIX information is valid, and reject it if either
one fails. Especially if a method is available where you can store the
bare public key in DNS and avoid all these conflicts.

One of the advantages of DANE is you can put your public key in DNS and
forget about things like re-signing your certificate and expiration.

>    For instance, if a certificate anywhere in the server's bundle has
>    expired or has been revoked by its issuing CA, a DANE client
>    SHOULD reject the end-entity certificate, even if the TLSA record
>    matches a point in the chain before the invalid certificate.

Should it? I am not sure I agree (or disagree)
If we have a bare public key option, then I can agree with this, as
anyone who cares can then pub just the pubkey in DNS and then for
compat reasons (or other) keep a valid PKIX on the server as well.

>    DANE associations provide a trust anchor _only_ for end-entity
>    certificates, even if the TLSA record has certificate type 2.
>    A DANE client MUST NOT allow any non-end-entity certificate in
>    a certificate bundle that is anchored by a DANE association to
>    become trusted for any domain name other than the one in the
>    original association.

This might get complicated with wildcards, both in DNS as well as in
the CN= or SubjectAltname
>    DANE does not assure any information in a certificate other than
>    the public key and its binding to host, protocol, and port.

This is a real problem, as clients would have to store the certificate
in their certificate pool, yet mark it was obtained by DANE and/or what
parts were validated. I was told by at least one major browser vendor
that this is a serious problem. I would say that if the entire cert
was in DANE, then DANE assures ALL the information in that certificate.
After all, the RRSIG was over the entire certificate.

And again, this assumes the alternative of bare public keys in DANE
exist for those who only want to assure the port/transport/name and
public key.

>  Most importantly, DANE does _not_ assure any non-DNS name records.

How is an implementation supposed to keep track? I would strongly suggest
people who desire this should use bare public keys in DANE instead.

> 3.5. User override
>
>    DANE clients SHOULD NOT allow their human users to force the
>    establishment of a connection that has been aborted for any of the
>    reasons listed in sections 3.2 or 3.3.

That's not up to the network protocol to decide. Leave that up to the
application developers to deal with. Even if you state it here, it will
get ignored. But I don't think the protocol should tell me how much I
should trust it. Just like I want to decide how much to trust (or not)
PKIX, I will decide how much to trust DANE. That not every enduser can
make an informative decision is something the application people are
much better suited to address properly then network protocol engineers.

Paul

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 29 Mar 2011 10:43:11 +0200
To: Paul Wouters <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] TLSA record does not mandate the given certificate

I actually really disagree with the idea that DANE would be some parallel, alternative path to PKIX validation.  If DANE is going to be meaningful, it needs to be able to cause the TLS handshake to fail -- this is the correct behavior when the server says (through DANE) that things should be one way and they aren't.

The relationship between DANE and PKIX is one of the topics for discussion at the DANE meeting tomorrow.  As I'll present (in a discussion too long for this email), they can actually work together very naturally.

--Richard

On Mar 29, 2011, at 10:34 AM, Paul Wouters wrote:

> On Tue, 29 Mar 2011, Jay Daley wrote:
> 
>> Two questions:
>> 
>> 1.  How is the current text in 3. not good enough?
>> 
>> "If a match between one of the certificate association(s) and the
>>  server's end entity certificate in TLS is found, the TLS client
>>  continues the TLS handshake.  If no match between the usable
>>  certificate association(s) and the server's end entity certificate in
>>  TLS is found, the TLS client MUST abort the handshake with an
>>  "access_denied" error."
> 
> I am assuming we will see deployment of DANE and PKIX alongside,
> where there might be contradictions or discrepancies between these two
> (or even other methods of obtaining this information out of band). I
> think what should be stated is that the "DANE validation path" should
> be aborted. We should not dictate to abort the TLS handshake. It would
> be up to a client/browser to implement one or more trust anchor methods
> (PKIX, DANE, LDAP, caching) and decide to abort the TLS handhshake only
> after all its trusted methods have failed.
> 
> Paul
> 
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Date: Tue, 29 Mar 2011 04:34:49 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Jay Daley <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] TLSA record does not mandate the given certificate

On Tue, 29 Mar 2011, Jay Daley wrote:

> Two questions:
>
> 1.  How is the current text in 3. not good enough?
>
> "If a match between one of the certificate association(s) and the
>   server's end entity certificate in TLS is found, the TLS client
>   continues the TLS handshake.  If no match between the usable
>   certificate association(s) and the server's end entity certificate in
>   TLS is found, the TLS client MUST abort the handshake with an
>   "access_denied" error."

I am assuming we will see deployment of DANE and PKIX alongside,
where there might be contradictions or discrepancies between these two
(or even other methods of obtaining this information out of band). I
think what should be stated is that the "DANE validation path" should
be aborted. We should not dictate to abort the TLS handshake. It would
be up to a client/browser to implement one or more trust anchor methods
(PKIX, DANE, LDAP, caching) and decide to abort the TLS handhshake only
after all its trusted methods have failed.

Paul

From: Jay Daley <[email-masked]>
Date: Tue, 29 Mar 2011 14:27:57 +1300
To: Zack Weinberg <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] TLSA record does not mandate the given certificate

On 29/03/2011, at 2:02 PM, Zack Weinberg wrote:

> On Mon, Mar 28, 2011 at 5:39 PM, Jay Daley <[email-masked]> wrote:
>> 
>> Two questions:
>> 
>> 1.  How is the current text in 3. not good enough?
>> 
>> "If a match between one of the certificate association(s) and the
>>   server's end entity certificate in TLS is found, the TLS client
>>   continues the TLS handshake.  If no match between the usable
>>   certificate association(s) and the server's end entity certificate in
>>   TLS is found, the TLS client MUST abort the handshake with an
>>   "access_denied" error."
> 
> Only in being more confusing than I would like.  I think it's vital to
> be crystal clear how a client should behave in all cases.

Sorry to be a pain, but I struggle to see how this is confusing.  Can you explain?

> By highlighting this text you reassure me that my changes to emphasize
> the exclusivity properties of TLSA really are editorial, though, so
> that's a relief.

Good.

>> 2.  Assuming there is a problem with that text and your replacement text is needed, then shouldn't this be more explicit about multiple TLSA records? (And also use correct terminology)
>> 
>> "A DANE client must determine whether the certificate bundle provided in the TLS handshake from a server found at a domain name matches a trusted TLSA record for that domain name.  If it does not ..."
> 
> I changed the terminology (see text above this),

I'm not sure what you are referring to.  Did I miss some text?

Jay

> again, to reduce
> confusion.  An entire certificate bundle does not match anything
> anymore, it can only be associated.  Only single certificates match.
> 
> You're right, though, I forgot to consider the case of multiple TLSA
> records.  I'll need to tweak wording throughout to fix that, I think.
> 
> zw

-- 
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840

Sender: [email-masked]
Date: Mon, 28 Mar 2011 18:02:30 -0700
From: Zack Weinberg <[email-masked]>
To: Jay Daley <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] TLSA record does not mandate the given certificate

On Mon, Mar 28, 2011 at 5:39 PM, Jay Daley <[email-masked]> wrote:
>
> Two questions:
>
> 1.  How is the current text in 3. not good enough?
>
> "If a match between one of the certificate association(s) and the
>   server's end entity certificate in TLS is found, the TLS client
>   continues the TLS handshake.  If no match between the usable
>   certificate association(s) and the server's end entity certificate in
>   TLS is found, the TLS client MUST abort the handshake with an
>   "access_denied" error."

Only in being more confusing than I would like.  I think it's vital to
be crystal clear how a client should behave in all cases.

By highlighting this text you reassure me that my changes to emphasize
the exclusivity properties of TLSA really are editorial, though, so
that's a relief.

> 2.  Assuming there is a problem with that text and your replacement text is needed, then shouldn't this be more explicit about multiple TLSA records? (And also use correct terminology)
>
> "A DANE client must determine whether the certificate bundle provided in the TLS handshake from a server found at a domain name matches a trusted TLSA record for that domain name.  If it does not ..."

I changed the terminology (see text above this), again, to reduce
confusion.  An entire certificate bundle does not match anything
anymore, it can only be associated.  Only single certificates match.

You're right, though, I forgot to consider the case of multiple TLSA
records.  I'll need to tweak wording throughout to fix that, I think.

zw

From: Jay Daley <[email-masked]>
Date: Tue, 29 Mar 2011 13:39:52 +1300
To: Zack Weinberg <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] TLSA record does not mandate the given certificate

On 29/03/2011, at 10:01 AM, Zack Weinberg wrote:

>>    Zack> The presence in the DNS of a trusted TLSA record is an assertion
>>    Zack> by the zone administrator that the legitimate server(s) for that
>>    Zack> host, protocol, and port will use certificate bundles that can be
>>    Zack> associated with the domain name by that record (as defined in
>>    Zack> section 3.1), and no others.
>> 
>>    Zack> Therefore, a DANE client in possession of a trusted TLSA record
>>    Zack> for a server MUST determine whether that TLSA record associates
>>    Zack> the server's domain name with the certificate bundle it provides
>>    Zack> in the TLS handshake.  If it does not, a DANE client MUST reject
>>    Zack> the end-entity certificate and abort the TLS handshake with an
>>    Zack> "access_denied" error.  This rule applies even if the end-entity
>>    Zack> certificate would have been trusted in the absence of the TLSA
>>    Zack> record.
> 
> If it's not, please let me know how I could improve it.

Two questions:

1.  How is the current text in 3. not good enough?

"If a match between one of the certificate association(s) and the
   server's end entity certificate in TLS is found, the TLS client
   continues the TLS handshake.  If no match between the usable
   certificate association(s) and the server's end entity certificate in
   TLS is found, the TLS client MUST abort the handshake with an
   "access_denied" error."

2.  Assuming there is a problem with that text and your replacement text is needed, then shouldn't this be more explicit about multiple TLSA records? (And also use correct terminology)

"A DANE client must determine whether the certificate bundle provided in the TLS handshake from a server found at a domain name matches a trusted TLSA record for that domain name.  If it does not ..."

Jay

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

-- 
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840

Sender: [email-masked]
Date: Mon, 28 Mar 2011 14:01:26 -0700
From: Zack Weinberg <[email-masked]>
To: Michael Richardson <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] TLSA record does not mandate the given certificate

On Mon, Mar 28, 2011 at 12:34 PM, Michael Richardson <[email-masked]> wrote:
>
> {I think you should start three threads for your three proposals}

It is one proposal.  I could split out the additional text about
non-security use, but apart from that, it doesn't make sense to try to
break up the changes.

> I can't parse "yes"/"no" in the above sentence.
> Do you mean:
>
>  A TLSA record for site S specifying certificate X forbids a compliant
>  client from proceeding with the handshake if it receives certificate Y.
>
> or do you mean to object to this statement?  I think you mean to support
> it but I couldn't tell from the overview, and only from the text you supplied.

I mean to support it.  This is meant to be clear from this text of the proposal:

>    Zack> The presence in the DNS of a trusted TLSA record is an assertion
>    Zack> by the zone administrator that the legitimate server(s) for that
>    Zack> host, protocol, and port will use certificate bundles that can be
>    Zack> associated with the domain name by that record (as defined in
>    Zack> section 3.1), and no others.
>
>    Zack> Therefore, a DANE client in possession of a trusted TLSA record
>    Zack> for a server MUST determine whether that TLSA record associates
>    Zack> the server's domain name with the certificate bundle it provides
>    Zack> in the TLS handshake.  If it does not, a DANE client MUST reject
>    Zack> the end-entity certificate and abort the TLS handshake with an
>    Zack> "access_denied" error.  This rule applies even if the end-entity
>    Zack> certificate would have been trusted in the absence of the TLSA
>    Zack> record.

If it's not, please let me know how I could improve it.

zw

From: Michael Richardson <[email-masked]>
To: [email-masked]
Date: Mon, 28 Mar 2011 21:34:12 +0200
Sender: [email-masked]
Subject: [keyassure] TLSA record does not mandate the given certificate

{I think you should start three threads for your three proposals}

>>>>> "Zack" = Zack Weinberg <[email-masked]> writes:
    Zack> The exceptions are: First, it is not clear to me whether the present
    Zack> intent of the spec is that a TLSA record for site S specifying
    Zack> certificate X forbids a compliant client from proceeding with the
    Zack> handshake if it receives certificate Y.  I think the answer to this
    Zack> question must be an unambiguous "yes", and I have made changes
    Zack> to that effect in my edits.  If the answer is meant to be
    Zack> "no", then I will have to raise a formal objection, because
    Zack> that would IMHO mean that 
    Zack> DANE provided no improvements over the status quo.

I can't parse "yes"/"no" in the above sentence.
Do you mean:

  A TLSA record for site S specifying certificate X forbids a compliant
  client from proceeding with the handshake if it receives certificate Y. 

or do you mean to object to this statement?  I think you mean to support
it but I couldn't tell from the overview, and only from the text you supplied.

    Zack> o  The TLSA record has certificate type 1, and it matches the
    Zack> end-entity certificate in the bundle; or

    Zack> o  The TLSA record has certificate type 2, it matches one of the
    Zack> non-end-entity certificates in the bundle, and the end-entity
    Zack> certificate in the bundle has a valid chain to the certificate
    Zack> that matched the TLSA record.

...

    Zack> 3.3. DANE validation

    Zack> The presence in the DNS of a trusted TLSA record is an assertion
    Zack> by the zone administrator that the legitimate server(s) for that
    Zack> host, protocol, and port will use certificate bundles that can be
    Zack> associated with the domain name by that record (as defined in
    Zack> section 3.1), and no others.

    Zack> Therefore, a DANE client in possession of a trusted TLSA record
    Zack> for a server MUST determine whether that TLSA record associates
    Zack> the server's domain name with the certificate bundle it provides
    Zack> in the TLS handshake.  If it does not, a DANE client MUST reject
    Zack> the end-entity certificate and abort the TLS handshake with an
    Zack> "access_denied" error.  This rule applies even if the end-entity
    Zack> certificate would have been trusted in the absence of the TLSA
    Zack> record.

    Zack> Conversely, if the TLSA record _does_ associate the server's
    Zack> certificate bundle with its domain name, a DANE client MUST treat
    Zack> the end-entity certificate as possessing a valid chain to a trust
    Zack> anchor, until the TTL of the TLSA record expires.  In other words,
    Zack> under these circumstances a DANE client MUST NOT reject a server's
    Zack> end-entity certificate solely for lack of a trust anchor.
    Zack> Furthermore, if the TLSA record providing the association has
    Zack> certificate type 1, a DANE client MUST NOT reject an end-entity
    Zack> certificate for violation of the PKIX rules that are relaxed by
    Zack> section 3.4 of this specification.

    Zack> However, if there is any _other_ reason why a server's end-entity
    Zack> certificate would have been rejected in the absence of TLSA
    Zack> information, a DANE client SHOULD still reject that certificate.
    Zack> For instance, if a certificate anywhere in the server's bundle has
    Zack> expired or has been revoked by its issuing CA, a DANE client
    Zack> SHOULD reject the end-entity certificate, even if the TLSA record
    Zack> matches a point in the chain before the invalid certificate.

    Zack> DANE associations provide a trust anchor _only_ for end-entity
    Zack> certificates, even if the TLSA record has certificate type 2.
    Zack> A DANE client MUST NOT allow any non-end-entity certificate in
    Zack> a certificate bundle that is anchored by a DANE association to
    Zack> become trusted for any domain name other than the one in the
    Zack> original association.

    Zack> DANE does not assure any information in a certificate other than
    Zack> the public key and its binding to host, protocol, and port.  Most
    Zack> importantly, DANE does _not_ assure any non-DNS name records.

I like your text.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition. 

Sender: [email-masked]
Date: Mon, 28 Mar 2011 09:46:50 -0700
From: Zack Weinberg <[email-masked]>
To: [email-masked]
Subject: [keyassure] PROPOSAL: Revision of DANE client requirements

I'd like to propose some revisions to the text of DANE.
Specifically, I want to make the requirements upon TLS clients that
implement the spec clearer, and I also want to consolidate them in one
place.  The current draft
(http://tools.ietf.org/html/draft-ietf-dane-protocol-06) scatters
client requirements all around the text, and it is IMO a bit too vague
about exactly what *is* a requirement.  I want to avoid a situation
where not all clients interpret TLSA records the same way, and I also
want to avoid a situation where a site administrator might be confused
about the effects of adding TLSA records to their zones.  With a few
exceptions, I believe all my proposed changes are strictly editorial
-- that is, I have not removed or added any requirements upon TLS
clients, I have just made it clearer what they are.

The exceptions are: First, it is not clear to me whether the present
intent of the spec is that a TLSA record for site S specifying
certificate X forbids a compliant client from proceeding with the
handshake if it receives certificate Y.  I think the answer to this
question must be an unambiguous "yes", and I have made changes to that
effect in my edits.  If the answer is meant to be "no", then I will
have to raise a formal objection, because that would IMHO mean that
DANE provided no improvements over the status quo.

Second, I have added constraints on client behavior based on DNSSEC
status alone.  This is arguably out of scope for this standard, but
I think the additions are necessary to preserve the security benefits
of DANE in the presence of active tampering with the DNS.

Third, I have added text about a potential non-security use of TLSA
records -- to enable TLS handshake optimizations -- and about user
override of TLSA-based rejection of a certificate.  These were not
addressed in the current draft, but I believe they add value.

I am speaking as a security researcher and as a Web browser
implementor.  I am not speaking on behalf of any other individual or
organization; however, I have received positive feedback on earlier
drafts of these edits from other browser implementors.

Thanks for your attention,
zw

---- proposal begins ----

Section 1.2: Delete the sentence "The DNSSEC signature MUST be
validated on all responses in order to assure the proof of origin of
the data" and the subsequent paragraph break.  (An equivalent, but
more specific, requirement will reappear in section 3.)

Section 1.3: Delete the entire second paragraph.

Section 2.2: Replace the paragraph that begins "Both types are
structured ..." with this text:

    Certificates of type 1 and 2 MUST be in PKIX format: that is, they
    must be structured according to the formatting rules in RFC 5280,
    and encoded using ASN.1 DER.  However, as described in section 3.4,
    type 1 certificates do not need to adhere to all the semantic
    rules in RFC 5280.  If it is desired to use other certificate
    formats with this specification in the future, those formats must
    be assigned their own certificate type numbers, and the definition
    of "associated" in section 3.1 of this specification must be revised
    appropriately.

Delete the paragraph that begins "Certificate types 1 and 2 explicitly
only apply ..." (having been folded into the above).

Section 2.3:  Delete all text before the beginning of section 2.3.1.
(Equivalent but clearer text will reappear in section 3.)

Section 2.3.1: Move contents to section 3.4 (marked below).

Section 3: Replace entire section with this text:

 3. Client application behavior in the presence of TLSA records

    The primary purpose of TLSA records is security.  However, TLSA
    information might also be useful for protocol optimizations that
    require advance knowledge of what the server's end-entity
    certificate should be.  Clients that use TLSA information only for
    such optimizations, and not for security decisions, are exempt
    from all other requirements in this section.

    Clients that make security decisions based on TLSA information
    MUST be, or have access to, security-aware DNS resolvers as
    defined by RFC 4033.  The rest of this section applies only to
    such clients, which will be referred to as "DANE clients".

 3.1. Definitions

    A certificate received in the TLS handshake is said to _match_ a
    TLSA record if:

    o  The TLSA record has reference type 0 and the certificate from
       the handshake is byte-for-byte identical to the certificate for
       association; or

    o  The TLSA record has some other reference type, and the hash of
       the certificate from the handshake (using the hash algorithm
       specified by the reference type) is byte-for-byte identical to
       the certificate for association.

    A certificate bundle received in the TLS handshake is said to be
    _associated_ with a domain name by DANE, if a TLSA record for the
    host, protocol, and port exists, the end-entity certificate in the
    bundle contains a name record that matches the host, and:

    o  The TLSA record has certificate type 1, and it matches the
       end-entity certificate in the bundle; or

    o  The TLSA record has certificate type 2, it matches one of the
       non-end-entity certificates in the bundle, and the end-entity
       certificate in the bundle has a valid chain to the certificate
       that matched the TLSA record.

 3.2. DNSSEC validation

    DANE clients MUST NOT proceed with a connection to a server if the
    DNSSEC validation status is "bogus" for _any_ DNS records relating
    to that server.

    DANE clients MUST ignore TLSA records whose DNSSEC validation
    status is "insecure" or "indeterminate" (however, such records MAY
    be used for TLS handshake optimizations as mentioned above).
    DANE clients MUST also ignore TLSA records whose certificate type
    or hash type they do not understand.

    A TLSA record whose DNSSEC status is "secure", and whose
    certificate and hash types are understood by the client processing
    it, will henceforth be referred to as a _trusted_ TLSA record.

 3.3. DANE validation

    The presence in the DNS of a trusted TLSA record is an assertion
    by the zone administrator that the legitimate server(s) for that
    host, protocol, and port will use certificate bundles that can be
    associated with the domain name by that record (as defined in
    section 3.1), and no others.

    Therefore, a DANE client in possession of a trusted TLSA record
    for a server MUST determine whether that TLSA record associates
    the server's domain name with the certificate bundle it provides
    in the TLS handshake.  If it does not, a DANE client MUST reject
    the end-entity certificate and abort the TLS handshake with an
    "access_denied" error.  This rule applies even if the end-entity
    certificate would have been trusted in the absence of the TLSA
    record.

    Conversely, if the TLSA record _does_ associate the server's
    certificate bundle with its domain name, a DANE client MUST treat
    the end-entity certificate as possessing a valid chain to a trust
    anchor, until the TTL of the TLSA record expires.  In other words,
    under these circumstances a DANE client MUST NOT reject a server's
    end-entity certificate solely for lack of a trust anchor.
    Furthermore, if the TLSA record providing the association has
    certificate type 1, a DANE client MUST NOT reject an end-entity
    certificate for violation of the PKIX rules that are relaxed by
    section 3.4 of this specification.

    However, if there is any _other_ reason why a server's end-entity
    certificate would have been rejected in the absence of TLSA
    information, a DANE client SHOULD still reject that certificate.
    For instance, if a certificate anywhere in the server's bundle has
    expired or has been revoked by its issuing CA, a DANE client
    SHOULD reject the end-entity certificate, even if the TLSA record
    matches a point in the chain before the invalid certificate.

    DANE associations provide a trust anchor _only_ for end-entity
    certificates, even if the TLSA record has certificate type 2.
    A DANE client MUST NOT allow any non-end-entity certificate in
    a certificate bundle that is anchored by a DANE association to
    become trusted for any domain name other than the one in the
    original association.

    DANE does not assure any information in a certificate other than
    the public key and its binding to host, protocol, and port.  Most
    importantly, DANE does _not_ assure any non-DNS name records.

 3.4. Relaxation of PKIX semantics for self-signed certificates

    (insert former contents of section 2.3.1 here)

 3.5. User override

    DANE clients SHOULD NOT allow their human users to force the
    establishment of a connection that has been aborted for any of the
    reasons listed in sections 3.2 or 3.3.

    A client that has good reason not to comply with this requirement,
    such as a forensic tool, SHOULD assume that the other end of a
    forced connection is actively malicious.  Therefore, the client
    SHOULD take precautions to avoid compromising the local computer
    or any of the user's data, such as:

    o  Not transmitting "cookies" or any other information that should be
       confidential to the legitimate server;
    o  Not executing any code (e.g. JavaScript) received over the
       connection;
    o  Not triggering further network traffic based on the normal
       semantics of the data received (e.g. images referenced by an
       HTML page) without explicit user instructions to do so.

---- proposal ends ----

Date: Mon, 28 Mar 2011 08:56:48 -0400
From: Olafur Gudmundsson <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Asserting DANE exclusivity for an entire domain

On 03/02/2011 11:45 AM, James Cloos wrote:
>>>>>> "MM" = Matt McCutchen<[email-masked]>  writes:
>
>>> Since we rely on DNSSEC anyway, DS records are the ideal way to
>>> determine zone cut points.  They are grabbed anyway as a matter
>>> of course and provide all the clue required.
>
> MM>  Right... but do DNSSEC client libraries make it easy to access this
> MM>  information without doing a separate query for the DS record?
>
> Even if they do not, the resolver had to grab the DS as part of the
> validation, so the round trip for an extra DS lookup by the end client
> is by definition local, often even same-process.
>
> -JimC

Actually the RRSIG(DTLS) is an even better indicator the zone name =
signer name, there is no need to look up the DS record from the client.

	Olafur

From: Matt McCutchen <[email-masked]>
To: Paul Wouters <[email-masked]>
Date: Fri, 25 Mar 2011 21:03:23 -0400
Cc: [email-masked]
Subject: Re: [keyassure] Bare keys again

On Fri, 2011-03-25 at 19:36 -0400, Paul Wouters wrote:
> On Fri, 25 Mar 2011, Matt McCutchen wrote:
> > On Fri, 2011-03-25 at 05:03 -0400, Paul Wouters wrote:
> >> 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.
> >
> > 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.
> 
> 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

Date: Fri, 25 Mar 2011 19:36:48 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Matt McCutchen <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Bare keys again

On Fri, 25 Mar 2011, Matt McCutchen wrote:

> On Fri, 2011-03-25 at 05:03 -0400, Paul Wouters wrote:
>> 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.
>
> 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.

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

Paul

From: Matt McCutchen <[email-masked]>
To: Paul Wouters <[email-masked]>
Date: Fri, 25 Mar 2011 10:21:07 -0400
Cc: [email-masked]
Subject: Re: [keyassure] Bare keys again

On Fri, 2011-03-25 at 05:03 -0400, Paul Wouters wrote:
> 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.

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: "dane issue tracker" <[email-masked]>
Auto-Submitted: auto-generated
To: [email-masked]
Date: Fri, 25 Mar 2011 11:00:20 -0000
Cc: [email-masked]
Subject: Re: [keyassure] [dane] #14: Bare Public Keys

#14: Bare Public Keys

Comment(by henry.story@…):

 Paul Hoffman added in http://www.ietf.org/mail-
 archive/web/keyassure/current/msg02129.html

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

-- 
--------------------------------+-------------------------------------------
 Reporter:  mlepinsk@…          |       Owner:     
     Type:  defect              |      Status:  new
 Priority:  minor               |   Milestone:     
Component:  protocol            |     Version:     
 Severity:  Active WG Document  |    Keywords:     
--------------------------------+-------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/dane/trac/ticket/14#comment:3>
dane <http://tools.ietf.org/dane/>

From: Paul Hoffman <[email-masked]>
Date: Fri, 25 Mar 2011 06:14:23 -0400
To: Henry Story <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Bare keys again

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

"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

Date: Fri, 25 Mar 2011 10:13:39 +0000
From: Ben Laurie <[email-masked]>
To: Paul Wouters <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Bare keys again

On 25 March 2011 09:03, Paul Wouters <[email-masked]> wrote:
> On Wed, 23 Mar 2011, Douglas Otis wrote:
>
>>>
>>> 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.
>>
>> 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)

Happy to shepherd OpenSSL patches...

>
> 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
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

Date: Fri, 25 Mar 2011 05:03:32 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Douglas Otis <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Bare keys again

On Wed, 23 Mar 2011, Douglas Otis wrote:

>> 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.
> 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: Henry Story <[email-masked]>
Date: Fri, 25 Mar 2011 07:55:24 +0100
To: Paul Hoffman <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Bare keys again

On 23 Mar 2011, at 16:19, Paul Hoffman wrote:

> On Mar 23, 2011, at 7:15 AM, Jeff Schmidt wrote:
> 
>> 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.

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: "dane issue tracker" <[email-masked]>
Auto-Submitted: auto-generated
To: [email-masked]
Date: Fri, 25 Mar 2011 06:43:30 -0000
Cc: [email-masked]
Subject: Re: [keyassure] [dane] #14: Bare Public Keys

#14: Bare Public Keys

Comment(by henry.story@…):

 That ended up being a long thread.

 One part of the discussion was on what the keys should look like. A simple
 and standard compliant bare public key format would be the one defined by
 X509 itself, namely the subset of X509 that defines.

 RSAPublicKey ::= SEQUENCE {
     modulus           INTEGER,  -- n
     publicExponent    INTEGER   -- e
   }

 More on this here:

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

 The thread of February 14th is long, and one summary of the pros and cons
 can be found here, with pointers

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

-- 
--------------------------------+-------------------------------------------
 Reporter:  mlepinsk@…          |       Owner:     
     Type:  defect              |      Status:  new
 Priority:  minor               |   Milestone:     
Component:  protocol            |     Version:     
 Severity:  Active WG Document  |    Keywords:     
--------------------------------+-------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/dane/trac/ticket/14#comment:2>
dane <http://tools.ietf.org/dane/>

Date: Thu, 24 Mar 2011 11:43:51 -0700
From: Douglas Otis <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Bare keys again

On 3/23/11 7:29 PM, Douglas Otis wrote:
> On 3/23/11 3:30 AM, Paul Wouters wrote:
>> On Mon, 21 Mar 2011, Paul Wouters wrote:
>>
>>>> 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.
>>
>> 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.
> 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?
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: Warren Kumari <[email-masked]>
Date: Thu, 24 Mar 2011 09:17:56 +0100
To: [email-masked]
Subject: [keyassure] Mis-issued certs for Google / Yahoo / Skype, etc.

I'm assuming everyone has already seen this, but on the off-chance that you haven't:

http://threatpost.com/en_us/blogs/phony-web-certificates-issued-google-yahoo-skype-others-032311#

Being able to state "That ain't my cert" is one of the drivers for this work....

W

From: "dane issue tracker" <[email-masked]>
Auto-Submitted: auto-generated
To: [email-masked]
Date: Thu, 24 Mar 2011 03:19:15 -0000
Cc: [email-masked]
Subject: Re: [keyassure] [dane] #22: Provide the security of the strongest digest supported by both sides

#22: Provide the security of the strongest digest supported by both sides

Comment(by matt@…):

 For the curious: [https://www.ietf.org/mail-
 archive/web/dnsext/current/msg11006.html George Barwood took my claim that
 the issue affects DNSSEC DS to the dnsext list] and discussion ensued.  It
 turns out DNSSEC DS has a solution that I was unaware of: assume that the
 DS RRset is formed as a Cartesian product of DNSKEYs with digest
 algorithms, and then the client uses the strongest algorithm it supports
 that appears in the set.

 This makes three possible solutions:
  1. Allow each RR to contain a set of (digest type, digest value) pairs
 for the same certificate.
  1. Require the RRset to be a Cartesian product of certificates with
 digest algorithms.
  1. Add an ID field to each RR to cross-reference all digests of the same
 object.
 IMO, solution 1 is the cleanest.

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

Ticket URL: <http://tools.ietf.org/wg/dane/trac/ticket/22#comment:1>
dane <http://tools.ietf.org/dane/>

Date: Wed, 23 Mar 2011 19:29:34 -0700
From: Douglas Otis <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Bare keys again

On 3/23/11 3:30 AM, Paul Wouters wrote:
> On Mon, 21 Mar 2011, Paul Wouters wrote:
>
>>> 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.
>
> 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.
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: Matt McCutchen <[email-masked]>
To: keyassure <[email-masked]>
Date: Wed, 23 Mar 2011 11:26:28 -0400
Subject: Re: [keyassure] Bare keys again

On Wed, 2011-03-23 at 06:30 -0400, Paul Wouters wrote:
> 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,

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: Paul Hoffman <[email-masked]>
Date: Wed, 23 Mar 2011 08:19:31 -0700
To: Jeff Schmidt <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Bare keys again

On Mar 23, 2011, at 7:15 AM, Jeff Schmidt wrote:

> 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: Jeff Schmidt <[email-masked]>
To: Paul Wouters <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 23 Mar 2011 14:15:33 +0000
Accept-Language: en-US
Subject: Re: [keyassure] Bare keys again

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

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

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: "dane issue tracker" <[email-masked]>
Auto-Submitted: auto-generated
To: [email-masked]
Date: Wed, 23 Mar 2011 11:51:58 -0000
Cc: [email-masked]
Subject: Re: [keyassure] [dane] #11: Hash Function Strength

#11: Hash Function Strength

Changes (by ondrej.sury@…):

  * status:  new => closed
  * resolution:  => fixed

-- 
------------------------------+---------------------------------------------
 Reporter:  mlepinsk@…        |        Owner:        
     Type:  defect            |       Status:  closed
 Priority:  minor             |    Milestone:        
Component:  protocol          |      Version:        
 Severity:  -                 |   Resolution:  fixed 
 Keywords:                    |  
------------------------------+---------------------------------------------

Ticket URL: <http://wiki.tools.ietf.org/wg/dane/trac/ticket/11#comment:2>
dane <http://tools.ietf.org/dane/>

From: "dane issue tracker" <[email-masked]>
Auto-Submitted: auto-generated
To: [email-masked], [email-masked]
Date: Wed, 23 Mar 2011 11:51:33 -0000
Cc: [email-masked]
Subject: Re: [keyassure] [dane] #9: Self-Signed Certificates

#9: Self-Signed Certificates

Changes (by ondrej.sury@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Resolved in the current draft draft-ietf-dane-protocol-06.

-- 
--------------------------------+-------------------------------------------
 Reporter:  mlepinsk@…          |        Owner:        
     Type:  defect              |       Status:  closed
 Priority:  minor               |    Milestone:        
Component:  protocol            |      Version:        
 Severity:  Active WG Document  |   Resolution:  fixed 
 Keywords:                      |  
--------------------------------+-------------------------------------------

Ticket URL: <http://wiki.tools.ietf.org/wg/dane/trac/ticket/9#comment:2>
dane <http://tools.ietf.org/dane/>

From: "dane issue tracker" <[email-masked]>
Auto-Submitted: auto-generated
To: [email-masked]
Date: Wed, 23 Mar 2011 11:50:53 -0000
Cc: [email-masked]
Subject: Re: [keyassure] [dane] #11: Hash Function Strength

#11: Hash Function Strength

Comment(by ondrej.sury@…):

 Resolved in the current draft draft-ietf-dane-protocol-06.

-- 
------------------------------+---------------------------------------------
 Reporter:  mlepinsk@…        |       Owner:     
     Type:  defect            |      Status:  new
 Priority:  minor             |   Milestone:     
Component:  protocol          |     Version:     
 Severity:  -                 |    Keywords:     
------------------------------+---------------------------------------------

Ticket URL: <http://tools.ietf.org/wg/dane/trac/ticket/11#comment:1>
dane <http://tools.ietf.org/dane/>

From: "dane issue tracker" <[email-masked]>
Auto-Submitted: auto-generated
To: [email-masked]
Date: Wed, 23 Mar 2011 11:50:23 -0000
Cc: [email-masked]
Subject: Re: [keyassure] [dane] #5: Protocol support -- TLS / DTLS / IPsec or larger.

#5: Protocol support -- TLS / DTLS / IPsec or larger.

Changes (by ondrej.sury@…):

  * status:  new => closed
  * resolution:  => wontfix

Comment:

 Out of scope for the current draft.  We may reopen if needed for a new
 draft in the future.

-- 
-------------------------------+--------------------------------------------
 Reporter:  warren@…           |        Owner:         
     Type:  task               |       Status:  closed 
 Priority:  major              |    Milestone:         
Component:  protocol           |      Version:         
 Severity:  -                  |   Resolution:  wontfix
 Keywords:                     |  
-------------------------------+--------------------------------------------

Ticket URL: <http://tools.ietf.org/wg/dane/trac/ticket/5#comment:1>
dane <http://tools.ietf.org/dane/>

Date: Wed, 23 Mar 2011 06:30:35 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Bare keys again

On Mon, 21 Mar 2011, Paul Wouters wrote:

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

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: Martin Rex <[email-masked]>
To: [email-masked] (Paul Wouters)
Date: Mon, 21 Mar 2011 23:01:03 +0100 (MET)
Cc: [email-masked]
Subject: Re: [keyassure] Bare keys again
Reply-To: [email-masked]

Paul Wouters wrote:
> 
> 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.

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

      Client                                               Server

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

             Figure 1.  Message flow for a full handshake

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

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.

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

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: Matt McCutchen <[email-masked]>
To: Paul Wouters <[email-masked]>
Date: Mon, 21 Mar 2011 17:43:55 -0400
Cc: [email-masked]
Subject: Re: [keyassure] Bare keys again

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: Matt McCutchen <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 21 Mar 2011 17:42:25 -0400
Cc: [email-masked]
Subject: Re: [keyassure] Bare keys again

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: Martin Rex <[email-masked]>
To: [email-masked] (Paul Wouters)
Date: Mon, 21 Mar 2011 22:42:17 +0100 (MET)
Cc: [email-masked]
Subject: Re: [keyassure] Bare keys again
Reply-To: [email-masked]

Paul Wouters wrote:
> 
> 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?

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

   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.

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

   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.

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

Date: Mon, 21 Mar 2011 17:40:52 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Eric Rescorla <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Bare keys again

On Mon, 21 Mar 2011, Eric Rescorla wrote:

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

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.

>> 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.
>
> In my opinion this is what would be required, and that document would need to
> be standardized by the TLS WG.

Okay.

Thanks,

Paul

Date: Mon, 21 Mar 2011 17:34:11 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Bare keys again

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]

Date: Mon, 21 Mar 2011 17:05:26 -0400
From: Phillip Hallam-Baker <[email-masked]>
To: Eric Rescorla <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Bare keys again

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

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.

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

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.
<div><br></div><div>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.</div>
<div><br></div><div><br></div><div>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).</div><div><br></div><div>Trying to modify Internet security protocols is like playing a game of Jenga on the rider&#39;s helmet with the guy trying to change his wheel.</div>
<div><br></div><div><br></div><div>What might appear to be a minor change to the protocol can have significant and unpredictable results throughout the system.</div><div><br></div><div>The way we avoid such results is mostly to avoid changes that do not have a very very good justification.</div>
<div><br></div><div><br></div><div>Not liking ASN.1 is not a justification in my view.</div>

--20cf303343e99e548b049f047cb5--

Date: Mon, 21 Mar 2011 13:49:39 -0700
From: Eric Rescorla <[email-masked]>
To: Paul Wouters <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Bare keys again

On Mon, Mar 21, 2011 at 1:39 PM, Paul Wouters <[email-masked]> wrote:
> On Mon, 21 Mar 2011, Matt McCutchen wrote:
>
>>> � �- �"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.
>
> 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.

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.

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

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

That's for the TLS WG to decide.

>> Using "pre_agreed" to tell the server it can skip
>> sending a certificate chain is not envisioned by RFC 6066.
>
> 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?

See above.

-Ekr

Date: Mon, 21 Mar 2011 16:39:01 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Matt McCutchen <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Bare keys again

On Mon, 21 Mar 2011, Matt McCutchen wrote:

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

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
> sending a certificate chain is not envisioned by RFC 6066.

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?

>> 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.
>
> 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: Matt McCutchen <[email-masked]>
To: Paul Wouters <[email-masked]>
Date: Mon, 21 Mar 2011 16:29:30 -0400
Cc: [email-masked]
Subject: Re: [keyassure] Bare keys again

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

On Sun, 2011-03-20 at 22:18 -0400, Paul Wouters wrote:
> On Sun, 20 Mar 2011, Matt McCutchen wrote:
> 
> >> 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.
> >
> > How does this look at the message level?  The server sends a Certificate
> > 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 {}'

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

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

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

> > IMO, this scheme should be
> > standardized and subjected to the attendant level of scrutiny before we
> > consider supporting it in DANE.
> 
> 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.

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

-- 
Matt

From: Matt McCutchen <[email-masked]>
To: Paul Wouters <[email-masked]>
Date: Mon, 21 Mar 2011 16:21:03 -0400
Cc: [email-masked]
Subject: Re: [keyassure] Bare keys again

On Mon, 2011-03-21 at 16:02 -0400, Paul Wouters wrote:
> 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.

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

-- 
Matt

Date: Mon, 21 Mar 2011 13:11:16 -0700
From: Eric Rescorla <[email-masked]>
To: Paul Wouters <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] Bare keys again

On Mon, Mar 21, 2011 at 12:57 PM, Paul Wouters <[email-masked]> wrote:
> On Mon, 21 Mar 2011, Eric Rescorla wrote:
>
>> [Speaking as an individual]
>> IMO the requirements of 5246 are fairly clear here:
>
>> 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.
>
> 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.

>> [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.
>
> Didn't 6066 go through that process?

Yes.

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

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

Date: Mon, 21 Mar 2011 16:02:04 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Martin Rex <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] Bare keys again

On Mon, 21 Mar 2011, Martin Rex wrote:

> See http://tools.ietf.org/html/rfc5246#section-7.4.2
>
>   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.
>
> 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.

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

Date: Mon, 21 Mar 2011 15:57:04 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Eric Rescorla <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] Bare keys again

On Mon, 21 Mar 2011, Eric Rescorla wrote:

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

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

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

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

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: Matt McCutchen <[email-masked]>
To: Paul Wouters <[email-masked]>
Date: Mon, 21 Mar 2011 15:56:52 -0400
Cc: [email-masked]
Subject: Re: [keyassure] [dane] #23: Asserting DANE exclusivity for an entire domain

On Mon, 2011-03-21 at 15:50 -0400, Paul Wouters wrote:
> On Mon, 21 Mar 2011, dane issue tracker wrote:
> 
> > #23: Asserting DANE exclusivity for an entire domain
> >
> > I would like to be able to assert DANE exclusivity for an entire domain so
> > that, with respect to clients that check DANE first and fall back to a
> > mainstream public CA list, a public CA cannot fabricate a TLS service I do
> > not offer.
> 
> Could this not be done by adding an "empty" CAA record?

CAA is not DANE.

> Also, is this not what people here call "dictating policy to the client" ?

I responded to this objection the first time it was raised.

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

-- 
Matt

Date: Mon, 21 Mar 2011 15:50:33 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: dane issue tracker <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] [dane] #23: Asserting DANE exclusivity for an entire domain

On Mon, 21 Mar 2011, dane issue tracker wrote:

> #23: Asserting DANE exclusivity for an entire domain
>
> I would like to be able to assert DANE exclusivity for an entire domain so
> that, with respect to clients that check DANE first and fall back to a
> mainstream public CA list, a public CA cannot fabricate a TLS service I do
> not offer.

Could this not be done by adding an "empty" CAA record?

Also, is this not what people here call "dictating policy to the client" ?

Paul

Date: Mon, 21 Mar 2011 15:46:28 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: Peter Palfrader <[email-masked]>, [email-masked]
Subject: Re: [keyassure] CN/SAN matching (was: End entity certificate matching, trust anchors, and protocol-06)

On Mon, 21 Mar 2011, Paul Hoffman wrote:

>> Why is it needed in the first place?
>
>
> That's a very good question. I don't feel that it is a "need", but it "makes some sense". That is, if I want to go to www.example.com, and I get an A record for www.example.com, and I get a TLSA record for _http._tcp.www.example.com, and I get a certificate that says "this key is associated with www.somethingelse.com", what does it mean?
>
> I can see both ways: "it doesn't matter what the cert says, we are trusting the binding from the DNS" vs. "the cert needs to mean something"? Jakob and I have that text in because a number of people on the list were in the latter category, but it seems like a reasonable question to ask separately.

This is exactly why bare public keys are good for those who do not wish to deal with
a CA or making up arbitrary CN= entries in certificates only used to contain a public
key verified by DNS.

In fact, if forced to use a cert container, I would use a self signed *.xelerance.com,
but I definitely not add a *.xelerance.com wildcard in DNS.

Demanding information that will be filled in with bogus or unvalidatable information
makes no sense from a security point of view.

Paul

From: "dane issue tracker" <[email-masked]>
Auto-Submitted: auto-generated
To: [email-masked]
Date: Mon, 21 Mar 2011 19:32:33 -0000
Cc: [email-masked]
Subject: [keyassure] [dane] #23: Asserting DANE exclusivity for an entire domain

#23: Asserting DANE exclusivity for an entire domain

 I would like to be able to assert DANE exclusivity for an entire domain so
 that, with respect to clients that check DANE first and fall back to a
 mainstream public CA list, a public CA cannot fabricate a TLS service I do
 not offer.

 Previously discussed in [http://www.ietf.org/mail-
 archive/web/keyassure/current/msg01641.html this thread], but no final
 decision was reached.

 One approach to achieve this is to compose (1) a means of asserting the
 nonexistence of a TLS service at a (hostname, transport, port) triple and
 (2) a means of applying such an assertion to an entire domain except where
 otherwise specified.  Zack Weinberg made a reasonable proposal for (1):
 use a single RR with "certificate type" 0 and no "certificate for
 association".  (2) can be done with DNSSEC wildcards, but that is a little
 messy and will seriously bloat the zone if several different RRtypes each
 require this treatment.

-- 
------------------------------------+---------------------------------------
 Reporter:  matt@…                  |       Owner:     
     Type:  enhancement             |      Status:  new
 Priority:  major                   |   Milestone:     
Component:  protocol                |     Version:     
 Severity:  -                       |    Keywords:     
------------------------------------+---------------------------------------

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

Date: Mon, 21 Mar 2011 14:33:32 -0400
To: Matt McCutchen <[email-masked]>
From: Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Bare keys again

At 9:06 PM -0400 3/20/11, Matt McCutchen wrote:
>On Sun, 2011-03-20 at 20:40 -0400, Paul Wouters wrote:
>>  On Sun, 20 Mar 2011, Paul Hoffman 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.
>>
>>  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.

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: "dane issue tracker" <[email-masked]>
Auto-Submitted: auto-generated
To: [email-masked]
Date: Mon, 21 Mar 2011 18:19:35 -0000
Cc: [email-masked]
Subject: [keyassure] [dane] #22: Provide the security of the strongest digest supported by both sides

#22: Provide the security of the strongest digest supported by both sides

 I posit that as a general principle, security protocols that support
 several alternative algorithms should provide the strength of the
 strongest algorithm supported by both sides.  (TLS generally does this in
 the absence of active attacks.)  For DANE, this principle means that I
 should be able to publish SHA-256 and SHA-512 digests in such a way that a
 client that supports SHA-512 gets the strength of SHA-512 and a client
 that supports only SHA-256 still works.

 This is not possible under the current design of the TLSA RRset.  If I
 publish SHA-256 and SHA-512 digests, then clients that support SHA-512
 will still accept any certificate that matches the SHA-256 digest.
 Indeed, there is no way for them to distinguish this scenario from one in
 which I have published the SHA-256 of one certificate and the SHA-512 of a
 different certificate.  The necessary and sufficient fix is to indicate
 which digests refer to the same certificate, either via an ID number or by
 just putting all the digests of the same certificate in the same RR.

 The TLSA RRset is based on the DNSSEC DS RRset, which has the same
 problem.  The DS RR contains a key tag, which could almost be used as an
 ID number, but [https://tools.ietf.org/html/rfc4034#appendix-B RFC 4034
 Appendix B] says, "Implementations MUST NOT assume that the key tag
 uniquely identifies a DNSKEY RR."  I would like to get the problem fixed
 in DNSSEC too, but I have not looked into that yet.

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

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

Date: Mon, 21 Mar 2011 18:31:32 +0100
From: =?UTF-8?B?T25kxZllaiBTdXLDvQ=?= <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Issues that no longer issues?

On 20.3.2011 19:57, Warren Kumari wrote:
> 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!).

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: Paul Hoffman <[email-masked]>
Date: Mon, 21 Mar 2011 08:59:48 -0700
To: Peter Palfrader <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] CN/SAN matching (was: End entity certificate	matching, trust anchors, and protocol-06)

On Mar 21, 2011, at 6:04 AM, Peter Palfrader wrote:

> On Mon, 21 Mar 2011, Jakob Schlyter wrote:
> 
>> On 21 mar 2011, at 10.25, Peter Palfrader wrote:
>> 
>>> Updating the certificate and its corresponding binding in DNS is not
>>> dissimilar to updating DNSKEY and DS records: care must be taken to get
>>> the timing right, so that's a potential source of error.
>> 
>> Update TLSA resource records is very different from update DNSKEY et
>> al. - as long as you take the TTL into consideration, you can update
>> as you wish.
> 
> Create a new cert, create its hash, send to the DNS guys for inclusion.
> Wait TTL.
> Deploy new cert.
> Mail the DNS people that they can now remove the old hash.
> 
> That's not really something you want to have to do all that often.
> 
>>> But even if we do require SNI for TLSA to be useful with virtual
>>> hosting, that still means a virtual hosting provider has to create a
>>> certificate for each of the domains they want to serve[2].
>> 
>> Yes, why would that be a problem?
> 
> Why is it needed in the first place?

That's a very good question. I don't feel that it is a "need", but it "makes some sense". That is, if I want to go to www.example.com, and I get an A record for www.example.com, and I get a TLSA record for _http._tcp.www.example.com, and I get a certificate that says "this key is associated with www.somethingelse.com", what does it mean?

I can see both ways: "it doesn't matter what the cert says, we are trusting the binding from the DNS" vs. "the cert needs to mean something"? Jakob and I have that text in because a number of people on the list were in the latter category, but it seems like a reasonable question to ask separately.

--Paul Hoffman

From: Martin Rex <[email-masked]>
To: [email-masked] (Paul Wouters)
Date: Mon, 21 Mar 2011 16:51:05 +0100 (MET)
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] Bare keys again
Reply-To: [email-masked]

Paul Wouters wrote:
> 
> >  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.
> 
> Not at all! According to 6066:
> 
> 6. Trusted CA Indication
 
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

   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.

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

Date: Mon, 21 Mar 2011 08:37:01 -0700
From: Eric Rescorla <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Bare keys again

On Sun, Mar 20, 2011 at 6:10 PM, Paul Hoffman <[email-masked]> wrote:
> On Mar 20, 2011, at 5:40 PM, Paul Wouters wrote:
>> 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.
>
> 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.

[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

Date: Mon, 21 Mar 2011 14:04:30 +0100
From: Peter Palfrader <[email-masked]>
To: [email-masked]
Cc: Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] CN/SAN matching (was: End entity certificate	matching, trust anchors, and protocol-06)

On Mon, 21 Mar 2011, Jakob Schlyter wrote:

> On 21 mar 2011, at 10.25, Peter Palfrader wrote:
> 
> > Updating the certificate and its corresponding binding in DNS is not
> > dissimilar to updating DNSKEY and DS records: care must be taken to get
> > the timing right, so that's a potential source of error.
> 
> Update TLSA resource records is very different from update DNSKEY et
> al. - as long as you take the TTL into consideration, you can update
> as you wish.

Create a new cert, create its hash, send to the DNS guys for inclusion.
Wait TTL.
Deploy new cert.
Mail the DNS people that they can now remove the old hash.

That's not really something you want to have to do all that often.

> > But even if we do require SNI for TLSA to be useful with virtual
> > hosting, that still means a virtual hosting provider has to create a
> > certificate for each of the domains they want to serve[2].
> 
> Yes, why would that be a problem?

Why is it needed in the first place?

-- 
                           |  .''`.       ** Debian **
      Peter Palfrader      | : :' :      The  universal
 http://www.palfrader.org/ | `. `'      Operating System
                           |   `-    http://www.debian.org/

From: Jakob Schlyter <[email-masked]>
Date: Mon, 21 Mar 2011 10:59:39 +0100
To: Peter Palfrader <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] CN/SAN matching (was: End entity certificate matching, trust	anchors, and protocol-06)

On 21 mar 2011, at 10.25, Peter Palfrader wrote:

> Updating the certificate and its corresponding binding in DNS is not
> dissimilar to updating DNSKEY and DS records: care must be taken to get
> the timing right, so that's a potential source of error.

Update TLSA resource records is very different from update DNSKEY et al. - as long as you take the TTL into consideration, you can update as you wish.

> But even if we do require SNI for TLSA to be useful with virtual
> hosting, that still means a virtual hosting provider has to create a
> certificate for each of the domains they want to serve[2].

Yes, why would that be a problem?

	jakob

Date: Mon, 21 Mar 2011 10:25:14 +0100
From: Peter Palfrader <[email-masked]>
To: [email-masked]
Cc: Paul Hoffman <[email-masked]>
Subject: [keyassure] CN/SAN matching (was: End entity certificate matching, trust	anchors, and protocol-06)

On Sat, 12 Mar 2011, Paul Hoffman wrote:

> Comments are, of course, welcome.

Verison 06 of the draft, in section 2.3, introduces this new paragraph:

|  The end entity certificate from TLS, regardless of whether it was
|  matched with a TLSA type 1 certificate or chained to a TLSA type 2 CA
|  certificate, must have at least one identifier in the subject or
|  subjectAltName field of the matched certificates matches the expected
|  identifier for the TLS server.
[..]

This requirement has been discussed in passing earlier already (e.g in
the thread around [1]), but I think never exhaustively.  If it has and I
just missed it please accept my apologies (and I'd appreciate a pointer
to the right thread).

Do we assume that every client that will ever support TLSA will also
support SNI?  If not, then this would require that every time a virtual
host is added to, or removed from a webserver the certificate be
re-generated to update the list of SANs and the corresponding TLSA
information be updated.

Updating the certificate and its corresponding binding in DNS is not
dissimilar to updating DNSKEY and DS records: care must be taken to get
the timing right, so that's a potential source of error.

Another drawback is that a having all the domains listed as
subjectAltNames in a certificate leaks that list of domains hosted on a
given server.

But even if we do require SNI for TLSA to be useful with virtual
hosting, that still means a virtual hosting provider has to create a
certificate for each of the domains they want to serve[2].

This requirement seems to place some additional burden on the entity
implementing TLSA, but it does not provide any benefit that is obvious
to me.  So I wonder what the rationale for needing a matching CN or SAN
in the certificate is.

Thanks,
Peter

1. http://www.ietf.org/mail-archive/web/keyassure/current/msg01582.html
2. I am not familiar with hardware accelerators for RSA, but I assume
   there are certain limits on the number of keys such a thing can hold
   and some overhead for switching keys, so in the end a hoster might be
   tempted to create all the certificates from the same key material,
   maybe.
-- 
                           |  .''`.       ** Debian **
      Peter Palfrader      | : :' :      The  universal
 http://www.palfrader.org/ | `. `'      Operating System
                           |   `-    http://www.debian.org/

Date: Sun, 20 Mar 2011 22:18:22 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Matt McCutchen <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] Bare keys again

On Sun, 20 Mar 2011, Matt McCutchen wrote:

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

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

>> 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.
>
> How does this look at the message level?  The server sends a Certificate
> 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
> 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.

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
> standardized and subjected to the attendant level of scrutiny before we
> consider supporting it in DANE.

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: Paul Hoffman <[email-masked]>
Date: Sun, 20 Mar 2011 18:10:21 -0700
To: Paul Wouters <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Bare keys again

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

> On Sun, 20 Mar 2011, Paul Hoffman wrote:
> 
>> 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.
> 
> 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.
> 
>>> 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.
>> 
>> 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?

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.

>> 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.
> 
> We are talking about end entity keys.

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

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

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

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

Not and be compatible with TLS 1.2, I believe.

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

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: Matt McCutchen <[email-masked]>
To: Paul Wouters <[email-masked]>
Date: Sun, 20 Mar 2011 21:06:26 -0400
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] Bare keys again

On Sun, 2011-03-20 at 20:40 -0400, Paul Wouters wrote:
> On Sun, 20 Mar 2011, Paul Hoffman 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.
> 
> 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.

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

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

Date: Sun, 20 Mar 2011 20:40:35 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Bare keys again

On Sun, 20 Mar 2011, Paul Hoffman wrote:

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

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.

>> 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.
>
> 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 discussion of bare keys was for end entity keys. For that, I believe you actually need to write an extension to TLS.

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: Paul Hoffman <[email-masked]>
Date: Sun, 20 Mar 2011 17:13:11 -0700
To: [email-masked]
Subject: [keyassure] Bare keys again

On Mar 20, 2011, at 4:54 PM, Paul Wouters wrote:

> On Sun, 20 Mar 2011, Warren Kumari wrote:
> 
>> 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.

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.

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

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.

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

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

Date: Sun, 20 Mar 2011 19:54:49 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Warren Kumari <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: Re: [keyassure] Issues that no longer issues?

On Sun, 20 Mar 2011, Warren Kumari wrote:

> 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: Warren Kumari <[email-masked]>
Date: Sun, 20 Mar 2011 15:02:08 -0400
To: [email-masked]
Subject: [keyassure] Starting Working Group Last Call for draft-ietf-dane-protocol-06

........

Ok, we are not really doing this now, but, if we were, wouldn't if be good to know what's actually *in* the draft?!
[This is a subtle hint to go read it *before* the meeting]

Here it is: https://datatracker.ietf.org/doc/draft-ietf-dane-protocol/

W

From: Warren Kumari <[email-masked]>
Date: Sun, 20 Mar 2011 14:57:36 -0400
To: [email-masked]
Subject: [keyassure] Issues that no longer issues?

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: Henry Story <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] publishing the public key
Date: Mon, 14 Mar 2011 23:30:48 -0000

<html><body class="ApplePlainTextBody" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "></body></html>

Date: Sun, 13 Mar 2011 16:37:35 +0000
To: [email-masked]
From: Richard Clayton <[email-masked]>
Subject: [keyassure] Call for Participation: SATIN 2011

Call for Participation: Securing and Trusting Internet Names, SATIN 2011
====================================

Registration is now open, and we look forward to seeing as many people
as may wish to attend.

When:       Monday 4 & Tuesday 5 April 2011
            Note that IETF 80 is in Prague, CZ the previous week

Where:      National Physical Laboratory (NPL)
            Teddington, London, UK

Agenda:     http://conferences.npl.co.uk/satin/agenda.html

The intent is to make this a workshop that will expose the academics to
the real problems that industry is encountering, and to show industry
what academia has to offer them. To improve the flow of information,
presentations will be restricted to 15 minutes with 15 minutes of
general discussion to follow.

The agenda also includes a "rump session" for brief presentations of
"work in progress" by any attendee.

More at:    http://conferences.npl.co.uk/satin/

- -- 
Dr Richard Clayton                      <richard.clayton AT cl.cam.ac.uk>
                                           <richard.clayton AT npl.co.uk>
                            tel: +44 1223 763570, mobile: +44 7887 794090
                    Computer Laboratory, University of Cambridge, CB3 0FD
         National Physical Laboratory, Hampton Road, Teddington, TW11 0LW

From: Peter Gutmann <[email-masked]>
To: [email-masked]
Date: Sun, 13 Mar 2011 15:51:59 +1300
Subject: Re: [keyassure] End entity certificate matching, trust anchors, and protocol-06

Paul Hoffman <[email-masked]> writes:

>You may be surprised both by the restrictions that PKIX puts on us (namely
>that self-signed certificates are always CA certificates) and by the measures
>suggested in -06 (format validation on end entity certificates is relaxed to
>allow self-signed certificates for end entities).

This particular issue has been an ongoing problem for years.  More than a
decade ago I proposed the ability to create straightforward self-issued
certificates:

http://www.cs.auckland.ac.nz/~pgut001/pubs/autonomous.txt

but it was nixed by the PKIX chair with the comment "we're not going to turn
X.509 into PGP".  The need for this is as real as it was ten years ago, but
I'm not sure how to progress it (I was told at the time that it would be seen
by the IETF as falling within PKIX' purview, and they'd never allow it to be
published, which is why I abandoned work on it).

On a more general note, it's not surprising then that the current draft has to 
incorporate wording to say that you have to ignore the PKIX requirements.

Peter.

From: Peter Gutmann <[email-masked]>
To: [email-masked], [email-masked]
Date: Sun, 13 Mar 2011 15:42:44 +1300
Subject: Re: [keyassure] End entity certificate matching, trust anchors, and protocol-06

Paul Hoffman <[email-masked]> writes:

>Comments are, of course, welcome.

Using http://tools.ietf.org/rfcdiff?url2=draft-ietf-dane-protocol-06.txt
(which presnets -06 as diffs against -05) may be helpful here.

Peter.

Date: Sat, 12 Mar 2011 15:01:21 -0800
From: Paul Hoffman <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [keyassure] End entity certificate matching, trust anchors, and protocol-06

Greetings again. Draft -06 has two major changes, mandatory-to-implement 
algorithms and revised semantics for End entity certificate matching and 
trust anchors. The first is fairly straight-forward and hopefully 
exactly what was prescribed for the resolution to now-closed issue #21.

The second is more problematic, which is reflected in the fact that 
there is now much more text. Please read the new text carefully, 
including the quoted text from RFC 5280. You may be surprised both by 
the restrictions that PKIX puts on us (namely that self-signed 
certificates are always CA certificates) and by the measures suggested 
in -06 (format validation on end entity certificates is relaxed to allow 
self-signed certificates for end entities).

Comments are, of course, welcome. Proposals for new wording if needed 
are even more welcome. If we have made mistakes in reading RFC 5280, 
quoting from that document in your messages will be helpful to the 
entire WG.

We will be presenting on this in Prague, but would love to see 
discussion happen in the weeks before then.

--Paul Hoffman

From: [email-masked]
To: [email-masked]
Date: Sat, 12 Mar 2011 14:45:02 -0800
Cc: [email-masked]
Subject: [keyassure] I-D Action:draft-ietf-dane-protocol-06.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-06.txt
	Pages           : 13
	Date            : 2011-03-12

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

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

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

--NextPart--

Date: Fri, 11 Mar 2011 16:18:24 -0500
From: Tony Hansen <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

On 3/8/2011 11:26 AM, Paul Hoffman wrote:
> On 3/8/11 8:10 AM, Nicholas Weaver wrote:
>> (Not that I'm saying it should impede this group, I'm happing with 
>> the language above or similar, I just want to know why people want to 
>> use SHA-384 instead of SHA-512!)
>
> There is some reason to believe that the final SHA-3 spec will have a 
> 384-bit hash that will be faster to calculate than the 512-bit version, 

Given what NIST is doing with FIPS-180-4-draft and defining SHA-512/t, 
I'd be surprised if that were true. But it will be interesting to see 
what comes out of SHA3.

> and it will be hard to convince people who were using SHA-2-512 that 
> going to SHA-3-384 is a good move. They'll claim that it is less safe 
> because they didn't realize that they didn't even need the strength in 
> SHA-2-256 to start with.
>
> It's all headology, unfortunately.

     Tony Hansen
     [email-masked]

From: Warren Kumari <[email-masked]>
Date: Fri, 11 Mar 2011 14:00:10 -0500
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

On Mar 11, 2011, at 1:57 PM, Paul Hoffman wrote:

> On 3/11/11 10:45 AM, Warren Kumari wrote:
>> Ok,
>> 
>> We are calling (rough) consensus as:
>> 
>> SHA-256 MUST be implemented.
>> SHA-512 SHOULD be implemented.
>> 
>> We fully expect to support SHA-3 once it is finalized, but we are not currently reserving code-points for it.
>> We can re-visit code-points for SHA-3 as we know more about it, how many code-points it should have, etc.
> 
> Jakob and I will put out a new draft on Monday with this plus some different wording on trust anchors (the latter being still confusing to some folks).

The chairs would like to thank our authors for being on top of things, quickly integrating WG consensus and writing such a readable doc....

W

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

Date: Fri, 11 Mar 2011 10:57:43 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

On 3/11/11 10:45 AM, Warren Kumari wrote:
> Ok,
>
> We are calling (rough) consensus as:
>
> SHA-256 MUST be implemented.
> SHA-512 SHOULD be implemented.
>
> We fully expect to support SHA-3 once it is finalized, but we are not currently reserving code-points for it.
> We can re-visit code-points for SHA-3 as we know more about it, how many code-points it should have, etc.

Jakob and I will put out a new draft on Monday with this plus some 
different wording on trust anchors (the latter being still confusing to 
some folks).

--Paul Hoffman

From: "dane issue tracker" <[email-masked]>
Auto-Submitted: auto-generated
To: [email-masked]
Date: Fri, 11 Mar 2011 18:52:50 -0000
Cc: [email-masked]
Subject: Re: [keyassure] [dane] #21: Need to specify which crypto algorithms and certificate types are mandatory to implement

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

Changes (by warren@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 We are calling (rough) consensus as:

 SHA-256 MUST be implemented.
 SHA-512 SHOULD be implemented.

 We fully expect to support SHA-3 once it is finalized, but we are not
 currently reserving code-points for it.
 We can re-visit code-points for SHA-3 as we know more about it, how many
 code-points it should have, etc.

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

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

From: Warren Kumari <[email-masked]>
Date: Fri, 11 Mar 2011 13:45:54 -0500
To: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

Ok, 

We are calling (rough) consensus as:

SHA-256 MUST be implemented.
SHA-512 SHOULD be implemented.

We fully expect to support SHA-3 once it is finalized, but we are not currently reserving code-points for it. 
We can re-visit code-points for SHA-3 as we know more about it, how many code-points it should have, etc. 

W

Date: Tue, 08 Mar 2011 16:18:00 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

On 3/8/11 3:48 PM, Peter Gutmann wrote:
>
> Martin Rex<[email-masked]>  writes:
>
>> The only two situations, where *I* believe that having more than one
>> mandatory to implement hash algorithms for DANE would make sense:
>>
>> 1)  when SHA-1 was permitted (which no one seems to be asking for)
>> 2)  when the SHA-3 winner has been determined (which hasn't happened yet)
>>
>> Personally, I would strongly prefer the hash algorithm list for DANE to be
>>
>>    1)   SHA-256      (FIPS 180-3)    MUST implement
>>    2)   SHA-512      (FIPS 180-3)    SHOULD implement
>
> +1.

FWIW, I have been saying that I support two MUSTs, but I think most of 
the milage of that is gotten by one MUST and one SHOULD.

From: Peter Gutmann <[email-masked]>
To: [email-masked], [email-masked]
Date: Wed, 09 Mar 2011 12:51:55 +1300
Cc: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

[email-masked] writes:

>given the pace of the IETF processes, I fully expect there will be a SHA-3 
>finalist selected before this spec lands. (YMMV of course)

That was my feeling as well, which is why I've been pushing for slots for
SHA3 (specifically, SHA3-256 MUST, SHA3-512 MAY).

Peter.

From: Peter Gutmann <[email-masked]>
To: [email-masked]
Date: Wed, 09 Mar 2011 12:48:47 +1300
Cc: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

Martin Rex <[email-masked]> writes:

>The only two situations, where *I* believe that having more than one 
>mandatory to implement hash algorithms for DANE would make sense:
>
> 1)  when SHA-1 was permitted (which no one seems to be asking for)
> 2)  when the SHA-3 winner has been determined (which hasn't happened yet)
>
>Personally, I would strongly prefer the hash algorithm list for DANE to be
>
>   1)   SHA-256      (FIPS 180-3)    MUST implement
>   2)   SHA-512      (FIPS 180-3)    SHOULD implement

+1.

>Personally, I believe that SHA-384, and more so SHA-224 should have never 
>been defined by NIST, because they constantly confuse the crypto-clueless 
>about the purpose of these algorithms and cause needless discussions.

Even more so.

Peter.

From: Peter Gutmann <[email-masked]>
To: [email-masked], [email-masked]
Date: Wed, 09 Mar 2011 12:42:56 +1300
Cc: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

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

>Given that SHA2-512 is fastest on 64 bit machines and given that these are 
>now the mainstream, 

Really?  When did smart phones and the like switch to 64-bit processors? I must 
have missed the announcement.

(The platforms where performance is irrelevant because the CPU is just sitting 
there twiddling its thumbs waiting for the next job, desktop PCs and the like, 
are 64-bit, although even there most are running in 32-bit mode.  The platforms 
where performance is critical because of lack of CPU power and lack of battery 
power to drive it, are all 32 bit).

Peter.

Date: Tue, 08 Mar 2011 15:21:58 -0800
From: Chris Palmer <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

On 03/08/2011 12:47 PM, Phillip Hallam-Baker wrote:

> Given that SHA2-512 is fastest on 64 bit machines and given that these
> are now the mainstream,

Not necessarily. For normal servers, yes of course; but having spiffy
machines means that the previous generation of spiffy machines is now
available for use in cheap appliances. Lots of people want those, too,
and want them to perform well.

I personally wouldn't mind having SHA-512 be the only mandatory hash,
but reasonable people will bring up this "why penalize cheap servers"
argument.

-- 
Chris Palmer
Technology Director, Electronic Frontier Foundation
https://www.eff.org/code

Date: Tue, 8 Mar 2011 15:47:06 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

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

Quite possibly, but most people know not to wait for IETF process before
deployment.

I don't like the idea of SHA2-512/256 because the new IV is going to require
people to use a different code library to get support and that may be
tricky.

Given that SHA2-512 is fastest on 64 bit machines and given that these are
now the mainstream, would it not make sense to simply go to SHA2-384 or
SHA2-512 as the only mandatory for the time being with the expectation of
adding in some flavor of SHA3 when that is possible?

I think we need to break this down in matrix fashion

1) Attack
    A compromise that could lead an attacker to break DANE.

2) Reputation
   A compromise that falls short of enabling an actual attack against DANE
but will lead to concerns amongst users and pressure for a new algorithm.
(c.f. demands to change HMAC-MD5 despite no evidence this is necessary).

3) Support
   Is the algorithm supported in standard cryptographic toolkits, is
widespread support to be expected in the future.

4) Performance
    Not really a factor for this application but will determine whether it
is used for other purposes.

5) Industry
   Is the algorithm THE industry standard or merely A standard.

SHA-1:  Good for 20 years on attack but unknown as far as reputation. Is the
main target of cryptanalysis at the moment. Support is universal.

SHA2-256: Good for 30+ years on attack and at least 10 for reputation.
Support is near universal.

SHA2-386: Good for 40+ years on attack and probably 30+ for reputation.
Support is near universal

SHA2-512: Good for 50+ years on attack but likely 20+ on reputation due to
the fact that if 512 bits is specified in a protocol it is difficult to
explain why less than 512 bits are necessary.

SHA3-*: Will be THE standard in some strength as far as we can predict.
While it is possible something else will beat SHA3, I can't see that
happening and people being happy with SHA2.

So my recommendation would be

1) Do not define any code point for SHA1.

2) Define code point for SHA2-384

3) Expect to support SHA3 in the future via some mechanism. Add it to the
draft if the competition schedule makes this practical.

As a general rule I would prefer to only define IANA code points for
algorithms that the IETF REQUIRES.

I would support all other crypto by reserving one code point for specifying
algorithms by means of ASN.1 OID prefix.

The reason for doing that is that it means that the group does not need to
consider the inevitable requests to support other algorithms or deal with
the damage caused when a refusal is ignored.

We cannot stop the Russian federation from using GOST but we can stop them
getting a reserved code point.

On Tue, Mar 8, 2011 at 1:05 PM, <[email-masked]> wrote:

> On Tue, Mar 08, 2011 at 05:57:34PM +0100, Martin Rex wrote:
> >
> > It fosters on the premise that SHA-1 is completely and throroughly
> > broken and SHA-256 impaired by more serious attacks than currently
> > known for SHA-1 _long_ before a SHA-3 finalist is selected.
> >
> >
> > -Martin
>
>        my working analog here is that you don't shoot at a moving
>        target - you shoot ahead of it.
>
>        given the pace of the IETF processes, I fully expect there will
>        be a SHA-3 finalist selected before this spec lands.  (YMMV of
> course)
>
> --bill
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

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

Quite possibly, but most people know not to wait for IETF process before deployment.<div><br></div><div>I don&#39;t like the idea of SHA2-512/256 because the new IV is going to require people to use a different code library to get support and that may be tricky.</div>
<div><br></div><div>Given that SHA2-512 is fastest on 64 bit machines and given that these are now the mainstream, would it not make sense to simply go to SHA2-384 or SHA2-512 as the only mandatory for the time being with the expectation of adding in some flavor of SHA3 when that is possible?</div>
<div><br></div><div><br></div><div>I think we need to break this down in matrix fashion</div><div><br></div><div>1) Attack</div><div>�� �A compromise that could lead an attacker to break DANE.</div><div><br></div><div>2) Reputation</div>
<div>�� A compromise that falls short of enabling an actual attack against DANE but will lead to concerns amongst users and pressure for a new algorithm. (c.f. demands to change HMAC-MD5 despite no evidence this is necessary).</div>
<div><br></div><div>3) Support</div><div>�� Is the algorithm supported in standard cryptographic toolkits, is widespread support to be expected in the future.</div><div><br></div><div>4) Performance</div><div>�� �Not really a factor for this application but will determine whether it is used for other purposes.</div>
<div><br></div><div>5) Industry</div><div>�� Is the algorithm THE industry standard or merely A standard.</div><div><br></div><div>SHA-1: �Good for 20 years on attack but unknown as far as reputation. Is the main target of cryptanalysis at the moment. Support is universal.</div>
<div><br></div><div>SHA2-256: Good for 30+ years on attack and at least 10 for reputation. Support is near universal.�</div><div><br></div><div>SHA2-386: Good for 40+ years on attack and probably 30+ for reputation. Support is near universal</div>
<div><br></div><div>SHA2-512: Good for 50+ years on attack but likely 20+ on reputation due to the fact that if 512 bits is specified in a protocol it is difficult to explain why less than 512 bits are necessary.<br><div>
<br></div><div>SHA3-*: Will be THE standard in some strength as far as we can predict. While it is possible something else will beat SHA3, I can&#39;t see that happening and people being happy with SHA2.�</div><div><br></div>
<div>So my recommendation would be</div><div><br></div><div>1) Do not define any code point for SHA1.</div><div><br></div><div>2) Define code point for SHA2-384</div><div><br></div><div>3) Expect to support SHA3 in the future via some mechanism. Add it to the draft if the competition schedule makes this practical.</div>
<div><br></div><div><br></div><div>As a general rule I would prefer to only define IANA code points for algorithms that the IETF REQUIRES.</div><div><br></div><div>I would support all other crypto by reserving one code point for specifying algorithms by means of ASN.1 OID prefix.</div>
<div><br></div><div>The reason for doing that is that it means that the group does not need to consider the inevitable requests to support other algorithms or deal with the damage caused when a refusal is ignored.</div><div>
<br></div><div>We cannot stop the Russian federation from using GOST but we can stop them getting a reserved code point.</div><div><br><div class="gmail_quote">On Tue, Mar 8, 2011 at 1:05 PM,  <span dir="ltr">&lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:</div>
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On Tue, Mar 08, 2011 at 05:57:34PM +0100, Martin Rex wrote:<br>
&gt;<br>
&gt; It fosters on the premise that SHA-1 is completely and throroughly<br>
&gt; broken and SHA-256 impaired by more serious attacks than currently<br>
&gt; known for SHA-1 _long_ before a SHA-3 finalist is selected.<br>
&gt;<br>
&gt;<br>
</div>&gt; -Martin<br>
<br>
 � � � �my working analog here is that you don&#39;t shoot at a moving<br>
 � � � �target - you shoot ahead of it.<br>
<br>
 � � � �given the pace of the IETF processes, I fully expect there will<br>
 � � � �be a SHA-3 finalist selected before this spec lands. �(YMMV of course)<br>
<br>
--bill<br>
<div><div></div><div class="h5">_______________________________________________<br>
keyassure mailing list<br>
<a href="mailto:[email-masked]">[email-masked]</a><br>
<a href="https://www.ietf.org/mailman/listinfo/keyassure" target="_blank">https://www.ietf.org/mailman/listinfo/keyassure</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Website: <a href="http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div></div>

--001636ed6d011fd7ff049dfeb7af--

From: Yoav Nir <[email-masked]>
To: Paul Hoffman <[email-masked]>
Date: Tue, 8 Mar 2011 22:41:30 +0200
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

On Mar 8, 2011, at 6:26 PM, Paul Hoffman wrote:

> On 3/8/11 8:10 AM, Nicholas Weaver wrote:
>> (Not that I'm saying it should impede this group, I'm happing with the language above or similar, I just want to know why people want to use SHA-384 instead of SHA-512!)
> 
> There is some reason to believe that the final SHA-3 spec will have a 
> 384-bit hash that will be faster to calculate than the 512-bit version, 
> and it will be hard to convince people who were using SHA-2-512 that 
> going to SHA-3-384 is a good move. They'll claim that it is less safe 
> because they didn't realize that they didn't even need the strength in 
> SHA-2-256 to start with.

That would explain the relatively slow adoption of ECDSA. I want my 2048 bits of security.

Date: Tue, 8 Mar 2011 18:05:16 +0000
From: [email-masked]
To: Martin Rex <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

On Tue, Mar 08, 2011 at 05:57:34PM +0100, Martin Rex wrote:
> 
> It fosters on the premise that SHA-1 is completely and throroughly
> broken and SHA-256 impaired by more serious attacks than currently
> known for SHA-1 _long_ before a SHA-3 finalist is selected.
> 
> 
> -Martin

	my working analog here is that you don't shoot at a moving
	target - you shoot ahead of it.

	given the pace of the IETF processes, I fully expect there will
	be a SHA-3 finalist selected before this spec lands.  (YMMV of course)

--bill

Date: Tue, 8 Mar 2011 17:39:24 +0000
From: [email-masked]
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

On Tue, Mar 08, 2011 at 08:26:18AM -0800, Paul Hoffman wrote:
> On 3/8/11 8:10 AM, Nicholas Weaver wrote:
> >(Not that I'm saying it should impede this group, I'm happing with the 
> >language above or similar, I just want to know why people want to use 
> >SHA-384 instead of SHA-512!)
> 
> There is some reason to believe that the final SHA-3 spec will have a 
> 384-bit hash that will be faster to calculate than the 512-bit version, 
> and it will be hard to convince people who were using SHA-2-512 that 
> going to SHA-3-384 is a good move. They'll claim that it is less safe 
> because they didn't realize that they didn't even need the strength in 
> SHA-2-256 to start with.

	and what are those reasons?

--bill

> 
> It's all headology, unfortunately.
> 
> --Paul Hoffman
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

From: Martin Rex <[email-masked]>
To: [email-masked] (Nicholas Weaver)
Date: Tue, 8 Mar 2011 17:57:34 +0100 (MET)
Cc: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto
Reply-To: [email-masked]

Nicholas Weaver wrote:
> 
> I still don't get why SHA-384 instead of SHA-512.
> SHA-384 just seems silly to me: its no FASTER than SHA-512,
> it MUST be less secure than SHA-512.

There is no reason to this (in the sense of reasonable explanation).

It fosters on the premise that SHA-1 is completely and throroughly
broken and SHA-256 impaired by more serious attacks than currently
known for SHA-1 _long_ before a SHA-3 finalist is selected.

The only two situations, where *I* believe that having more than
one mandatory to implement hash algorithms for DANE would make sense:

  1)  when SHA-1 was permitted (which no one seems to be asking for)
  2)  when the SHA-3 winner has been determined (which hasn't happened yet)

Personally, I would strongly prefer the hash algorithm list for
DANE to be

   1)   SHA-256      (FIPS 180-3)    MUST implement
   2)   SHA-512      (FIPS 180-3)    SHOULD implement

Personally, I believe that SHA-384, and more so SHA-224 should have
never been defined by NIST, because they constantly confuse the
crypto-clueless about the purpose of these algorithms and cause
needless discussions.

-Martin

Date: Tue, 08 Mar 2011 08:26:18 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

On 3/8/11 8:10 AM, Nicholas Weaver wrote:
> (Not that I'm saying it should impede this group, I'm happing with the language above or similar, I just want to know why people want to use SHA-384 instead of SHA-512!)

There is some reason to believe that the final SHA-3 spec will have a 
384-bit hash that will be faster to calculate than the 512-bit version, 
and it will be hard to convince people who were using SHA-2-512 that 
going to SHA-3-384 is a good move. They'll claim that it is less safe 
because they didn't realize that they didn't even need the strength in 
SHA-2-256 to start with.

It's all headology, unfortunately.

--Paul Hoffman

From: Nicholas Weaver <[email-masked]>
Date: Tue, 8 Mar 2011 08:10:21 -0800
To: Sean Turner <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

On Mar 8, 2011, at 7:58 AM, Sean Turner wrote:
> I think I'm in this camp.  It's hard to use 2119-language for something that nobody can claim conformance to.  Somebody is still going to need to write a draft that says here's the SHA-3 alg, here's it's reference and we're updating the registry regardless so I think the draft could just as well do this:
> 
>   Value        Short description       Ref.
>   -----------------------------------------------------
>   0            No hash used            [This]
>   1            SHA-1                   NIST FIPS 180-3
>   2            SHA-256                 NIST FIPS 180-3
>   3            SHA-384                 NIST FIPS 180-3
>   4-254        Unassigned
> 
>   Applications to the registry can request specific values that have
>   yet to be assigned. Note that there is every intent to update this
>   registry when [SHA-3] is finalized.  Implementors are strongly
>   encouraged to support a flexible implementation strategy in order
>   to support an orderly migration to [SHA-3] shortly after this
>   registry is updated.

I still don't get why SHA-384 instead of SHA-512.  SHA-384 just seems silly to me: its no FASTER than SHA-512, it MUST be less secure than SHA-512, and the "every bit is sacred" zombie-idea in DNS needs its head lopped off: 16B larger hashes does NOT make a difference in DNS, especially for a single signature over a big blob of data.

(Not that I'm saying it should impede this group, I'm happing with the language above or similar, I just want to know why people want to use SHA-384 instead of SHA-512!)

Date: Tue, 08 Mar 2011 10:58:49 -0500
From: Sean Turner <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

On 3/8/11 2:20 AM, Jakob Schlyter wrote:
> On 8 mar 2011, at 07.23, Brian Smith wrote:
>
>> It would be better to have both SHA-384 mandatory for clients. Those two algorithms are already practically required because they are both required for a good implementation of TLS 1.2. Making SHA-384 mandatory for clients makes it easier for server administrators to switch from SHA-256 to SHA-384 if that would ever be helpful; that could be a real possibility considering the deployment of SHA-3 on clients is a long way off.
>
> +1 - having two algorithms (although from the same family) from the start is better than just one. And we add SHA-3 and friends later - no need to "reserve" code points for them at this point.

I think I'm in this camp.  It's hard to use 2119-language for something 
that nobody can claim conformance to.  Somebody is still going to need 
to write a draft that says here's the SHA-3 alg, here's it's reference 
and we're updating the registry regardless so I think the draft could 
just as well do this:

    Value        Short description       Ref.
    -----------------------------------------------------
    0            No hash used            [This]
    1            SHA-1                   NIST FIPS 180-3
    2            SHA-256                 NIST FIPS 180-3
    3            SHA-384                 NIST FIPS 180-3
    4-254        Unassigned

    Applications to the registry can request specific values that have
    yet to be assigned. Note that there is every intent to update this
    registry when [SHA-3] is finalized.  Implementors are strongly
    encouraged to support a flexible implementation strategy in order
    to support an orderly migration to [SHA-3] shortly after this
    registry is updated.

or something like that.

I can already envision the GEN-Art comment/IESG discuss on needing a 
stable reference for SHA-3 if it's a normative reference.  If there's no 
requirements associated with it you'll probably get away with an 
informative reference to [SHA-3]:

[SHA-3] "Cryptographic Hash Algorithm Competition", NIST Computer
         Security Resource Center Cryptographic Hash Project.

There is precedent to using this reference but it was in a draft with an 
intended status of informational and it was an informational reference.

spt

From: "George Barwood" <[email-masked]>
To: "Ben Laurie" <[email-masked]>, "Peter Gutmann" <[email-masked]>
Date: Tue, 8 Mar 2011 10:24:02 -0000
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

From: Rob Stradling <[email-masked]>
To: [email-masked], [email-masked]
Date: Tue, 8 Mar 2011 09:32:25 +0000
Cc: Phillip Hallam-Baker <[email-masked]>, [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

On Monday 07 Mar 2011 14:25:57 Martin Rex wrote:
> Phillip Hallam-Baker wrote:
> > We do require TLS however.
> > 
> > VeriSign and Comodo have created roots with SHA2-256 and SHA2-384, the
> > choice is thus not 'oddball'.
> 
> I assume you rather mean the signature algorithms
> sha256WithRsaEncryption OID { 1, 2, 840, 113549, 1, 1, 11 }
> sha384WithRsaEncryption OID { 1, 2, 840, 113549, 1, 1, 12 }

Yes, and also...

ecdsa-with-SHA384 OID { 1 2 840 10045 4 3 3 }

> rather than the hash algorithms.
> 
> > The criteria for abandoning an existing digest is not when the work
> > factor below a certain threshold, it is when the work factor falls
> > significantly below that advertised.
> 
> Nope, I doesn't have anything to do with advertisements.
> The problem is when _assumptions_ about an algorithms strength are
> shown to not hold, independent of how "strong" that algorithm is
> advertised.
> 
> This is why we do worry about md5 when used for digital signatures,
> and worry much less when md5 is used as HMAC-MD5 for integrity protection
> of online communication protocols.
> 
> > So SHA2-384 is to be preferred over SHA2-512 because even though it is
> > easier to break, it has a much higher safety factor.
> > 
> > If someone comes up with an attack against SHA2-512 with O(2^480/2)
> > complexity it would reduce the cost of attacking SHA2-512 but not the
> > cost of attacking SHA2-384. So the 512 bit version would be
> > 'compromised' but the 384 version would not.
> 
> That is marketing nonsense.
> 
> With that reasoning, we should use SHA-512/256 rather than SHA-256
> 
>   http://www.schneier.com/blog/archives/2011/02/nist_defines_ne.html
>   http://csrc.nist.gov/publications/PubsDrafts.html#fips-180-4
> 
> 
> I don't see any value in mandating any algorithm beyond SHA-256
> at this point -- anticipating that there is going to be SHA-3
> in the not so far future and a desire to support SHA-3 in DANE.
> 
> 
> 
> -Martin
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
  3rd Floor, 26 Office Village, Exchange Quay,
  Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by replying
to the e-mail containing this attachment. Replies to this email may be
monitored by Comodo for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no liability
can be accepted and the recipient is requested to use their own virus checking
software.

Date: Tue, 8 Mar 2011 09:06:35 +0000
From: Ben Laurie <[email-masked]>
To: Peter Gutmann <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

On 8 March 2011 04:06, Peter Gutmann <[email-masked]> wrote:
> Paul Hoffman <[email-masked]> writes:
>
>>Are you saying that the rough consensus is obvious, or that you believe there
>>can be none and we should give up, or...?
>
> I believe we should shoot anyone who doesn't agree that { SHA256 + SHA3 } is
> the right solution. �Then we will have consensus and can move on. �But that's
> just my opinion...

+1 :-)

Don't really see the point of SHA-384 myself, but I'm not particularly
opposed to its inclusion.

SHA3 obviously doesn't exist yet, but happy to have it included in the plan.

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

From: Jakob Schlyter <[email-masked]>
Date: Tue, 8 Mar 2011 08:20:50 +0100
To: Brian Smith <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

On 8 mar 2011, at 07.23, Brian Smith wrote:

> It would be better to have both SHA-384 mandatory for clients. Those two algorithms are already practically required because they are both required for a good implementation of TLS 1.2. Making SHA-384 mandatory for clients makes it easier for server administrators to switch from SHA-256 to SHA-384 if that would ever be helpful; that could be a real possibility considering the deployment of SHA-3 on clients is a long way off.

+1 - having two algorithms (although from the same family) from the start is better than just one. And we add SHA-3 and friends later - no need to "reserve" code points for them at this point.

	jakob

Date: Mon, 7 Mar 2011 22:23:08 -0800 (PST)
From: Brian Smith <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

Chris Palmer wrote:
> Actually, I thought that people had roughly agreed to specify SHA-256
> and -384 and to create a slot for SHA-3. If I'm wrong and that's not
> what people have roughly agreed, then I apologize and here are my two
> cents: As long as the minimum is -256 with a plan for SHA-3, I'm
> happy.

It would be better to have both SHA-384 mandatory for clients. Those two algorithms are already practically required because they are both required for a good implementation of TLS 1.2. Making SHA-384 mandatory for clients makes it easier for server administrators to switch from SHA-256 to SHA-384 if that would ever be helpful; that could be a real possibility considering the deployment of SHA-3 on clients is a long way off.

Cheers,
Brian

Date: Tue, 8 Mar 2011 04:55:08 +0000
From: [email-masked]
To: Peter Gutmann <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

On Tue, Mar 08, 2011 at 05:06:29PM +1300, Peter Gutmann wrote:
> Paul Hoffman <[email-masked]> writes:
> 
> >Are you saying that the rough consensus is obvious, or that you believe there
> >can be none and we should give up, or...?
> 
> I believe we should shoot anyone who doesn't agree that { SHA256 + SHA3 } is
> the right solution.  Then we will have consensus and can move on.  But that's
> just my opinion...
> 
> Peter.

	two to the chest, one to the head...

or in other words

+1

--bill (I beleive also)

From: Peter Gutmann <[email-masked]>
To: [email-masked], [email-masked]
Date: Tue, 08 Mar 2011 17:06:29 +1300
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

Paul Hoffman <[email-masked]> writes:

>Are you saying that the rough consensus is obvious, or that you believe there
>can be none and we should give up, or...?

I believe we should shoot anyone who doesn't agree that { SHA256 + SHA3 } is
the right solution.  Then we will have consensus and can move on.  But that's
just my opinion...

Peter.

From: Chris Palmer <[email-masked]>
Date: Mon, 7 Mar 2011 17:41:20 -0800
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

On Mar 7, 2011, at 5:03 PM, Paul Hoffman wrote:

> One specific thing that this author would like to see is what you and others specifically mean by "a slot for SHA-3" and "a plan for SHA-3". To me, those are quite different. We already have slots for SHA-3, SHA-42, and so on; they are not named as such, but they are there.

Change this:

"""
4.3.  TLSA Hash Types

   This document creates a new registry, "Hash Types for TLSA Resource
   Records".  The registry policy is "Specification Required".  The
   initial entries in the registry are:

   Value        Short description       Ref.
   -----------------------------------------------------
   0            No hash used            [This]
   1            SHA-1                   NIST FIPS 180-2
   2            SHA-256                 NIST FIPS 180-2
   3            SHA-384                 NIST FIPS 180-2
   4-254        Unassigned

   Applications to the registry can request specific values that have
   yet to be assigned.
"""

To something like this:

4.3.  TLSA Hash Types

   This document creates a new registry, "Hash Types for TLSA Resource
   Records".  The registry policy is "Specification Required".  The
   initial entries in the registry are:

   Value        Short description       Ref.
   -----------------------------------------------------
   0            No hash used            [This]
   1            SHA-1                   NIST FIPS 180-2
   2            SHA-256                 NIST FIPS 180-2
   3            SHA-384                 NIST FIPS 180-2
   4            Reserved
   5            Reserved
   6-254        Unassigned

   Applications to the registry can request specific values that have
   yet to be assigned. Note that that types 4 and 5 are reserved to
   indicate the SHA-3 algorithm, when it is defined. Future revisions
   to this document SHALL require implementations to support SHA-3, and
   implementors SHOULD prepare for this with a flexible implementation
   strategy.

I don't really speak RFC-ese, but hopefully this makes enough sense. :)

-- 
Chris Palmer
Technology Director, Electronic Frontier Foundation

Date: Mon, 07 Mar 2011 17:03:32 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

On 3/7/11 4:05 PM, Chris Palmer wrote:
> Actually, I thought that people had roughly agreed to specify SHA-256
> and -384 and to create a slot for SHA-3. If I'm wrong and that's not
> what people have roughly agreed, then I apologize and here are my two
> cents: As long as the minimum is -256 with a plan for SHA-3, I'm
> happy.

One specific thing that this author would like to see is what you and 
others specifically mean by "a slot for SHA-3" and "a plan for SHA-3". 
To me, those are quite different. We already have slots for SHA-3, 
SHA-42, and so on; they are not named as such, but they are there.

We do not have a plan for anything that is not currently listed in the 
document: they are just slots. If you or others want "a plan for SHA-3", 
what would that say in specific?

My personal opinion is "SHA-256 and SHA-384 (or 'and SHA-512') and slots 
for others in the future but with no plan for those slots", but a few 
folks here have spoken of plans (which means more words), so I don't 
have words to suggest for plans.

--Paul Hoffman

From: Chris Palmer <[email-masked]>
Date: Mon, 7 Mar 2011 16:05:39 -0800
To: Warren Kumari <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

On Mar 7, 2011, at 3:09 PM, Warren Kumari wrote:

> The WG chairs (well, this one at least) sees no consensus yet[0]....

Actually, I thought that people had roughly agreed to specify SHA-256 and -384 and to create a slot for SHA-3. If I'm wrong and that's not what people have roughly agreed, then I apologize and here are my two cents: As long as the minimum is -256 with a plan for SHA-3, I'm happy.

-- 
Chris Palmer
Technology Director, Electronic Frontier Foundation

From: Warren Kumari <[email-masked]>
Date: Mon, 7 Mar 2011 18:09:23 -0500
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

On Mar 7, 2011, at 1:19 PM, Paul Hoffman wrote:

> On 3/7/11 10:02 AM, Chris Palmer wrote:
>> Let's end this thread and move to the next important topic.
> 
> The document authors need to hear from the WG chairs what the rough consensus on this issue is before we can instantiate it in the next draft.

<chair hat>
The WG chairs (well, this one at least) sees no consensus yet[0]....
</chair hat>

> Are you saying that the rough consensus is obvious, or that you believe there can be none and we should give up, or...?

W
[0]: I'm sure that you already knew that (and that that was your point), but figured I'd make it explicit....

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

Date: Mon, 07 Mar 2011 10:19:03 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

On 3/7/11 10:02 AM, Chris Palmer wrote:
> Let's end this thread and move to the next important topic.

The document authors need to hear from the WG chairs what the rough 
consensus on this issue is before we can instantiate it in the next 
draft. Are you saying that the rough consensus is obvious, or that you 
believe there can be none and we should give up, or...?

From: Chris Palmer <[email-masked]>
Date: Mon, 7 Mar 2011 10:02:31 -0800
To: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

Let's end this thread and move to the next important topic.

-- 
Chris Palmer
Technology Director, Electronic Frontier Foundation

From: Yoav Nir <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Mon, 7 Mar 2011 16:52:54 +0200
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>, Phillip Hallam-Baker <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

On Mar 7, 2011, at 4:25 PM, Martin Rex wrote:

>> So SHA2-384 is to be preferred over SHA2-512 because even though it is
>> easier to break, it has a much higher safety factor.
>> 
>> If someone comes up with an attack against SHA2-512 with O(2^480/2)
>> complexity it would reduce the cost of attacking SHA2-512 but not the cost
>> of attacking SHA2-384. So the 512 bit version would be 'compromised' but the
>> 384 version would not.
> 
> That is marketing nonsense.
> 
> With that reasoning, we should use SHA-512/256 rather than SHA-256
> 
>  http://www.schneier.com/blog/archives/2011/02/nist_defines_ne.html
>  http://csrc.nist.gov/publications/PubsDrafts.html#fips-180-4

The point of SHA-512/256 is not marketing or even security, but speed.
http://eprint.iacr.org/2010/548.pdf

> I don't see any value in mandating any algorithm beyond SHA-256
> at this point -- anticipating that there is going to be SHA-3
> in the not so far future and a desire to support SHA-3 in DANE.

I disagree. SHA-512 (and -384) are touted for longevity - we hope that they will be resistant to pre-image and collision attacks for longer than SHA-256. This is important for document signing and somewhat for certificates, but not so much for resource records. If it takes a year from "sha-256 broken" to "exploit in the wild", that's plenty of time to replace all resource records.

So it doesn't make sense to publish SHA-384 resource records now, but we need the consumers of such records to be ready for SHA-384 records. The reason that the transition from MD5 to SHA-1 certificates was so smooth is that all browsers at the time supported SHA-1. 

Yoav

From: Martin Rex <[email-masked]>
To: [email-masked] (Phillip Hallam-Baker)
Date: Mon, 7 Mar 2011 15:25:57 +0100 (MET)
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto
Reply-To: [email-masked]

Phillip Hallam-Baker wrote:
> 
> We do require TLS however.
> 
> VeriSign and Comodo have created roots with SHA2-256 and SHA2-384, the
> choice is thus not 'oddball'.

I assume you rather mean the signature algorithms
sha256WithRsaEncryption OID { 1, 2, 840, 113549, 1, 1, 11 }
sha384WithRsaEncryption OID { 1, 2, 840, 113549, 1, 1, 12 }

rather than the hash algorithms.

> 
> The criteria for abandoning an existing digest is not when the work factor
> below a certain threshold, it is when the work factor falls significantly
> below that advertised.

Nope, I doesn't have anything to do with advertisements.
The problem is when _assumptions_ about an algorithms strength are
shown to not hold, independent of how "strong" that algorithm is
advertised.

This is why we do worry about md5 when used for digital signatures,
and worry much less when md5 is used as HMAC-MD5 for integrity protection
of online communication protocols.

> 
> So SHA2-384 is to be preferred over SHA2-512 because even though it is
> easier to break, it has a much higher safety factor.
> 
> If someone comes up with an attack against SHA2-512 with O(2^480/2)
> complexity it would reduce the cost of attacking SHA2-512 but not the cost
> of attacking SHA2-384. So the 512 bit version would be 'compromised' but the
> 384 version would not.

That is marketing nonsense.

With that reasoning, we should use SHA-512/256 rather than SHA-256

  http://www.schneier.com/blog/archives/2011/02/nist_defines_ne.html
  http://csrc.nist.gov/publications/PubsDrafts.html#fips-180-4

I don't see any value in mandating any algorithm beyond SHA-256
at this point -- anticipating that there is going to be SHA-3
in the not so far future and a desire to support SHA-3 in DANE.

-Martin

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

On 5 mar 2011, at 16.59, Paul Hoffman wrote:

> This is not an argument against SHA-512, but if we are going to make arguments for its use, let's make sensible ones. I don't think there are many sensible ones for anything other than SHA-1, so we can just pick what we want.

I agree and after some more thinking (and reading) about this I do believe we should settle for SHA-256 and SHA-384 as the initial set of, and mandatory to implement, digest algorithms for TLSA (just as Warren proposed).

	jakob

Date: Sat, 5 Mar 2011 11:43:02 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: George Barwood <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto algorithms and certificate types are mandatory to implement"

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

On Sat, Mar 5, 2011 at 11:26 AM, George Barwood <
[email-masked]> wrote:

>
> ----- Original Message -----
> From: "Paul Hoffman" <[email-masked]>
> To: <[email-masked]>
> Sent: Saturday, March 05, 2011 3:59 PM
> Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto
> algorithms and certificate types are mandatory to implement"
>
>
> > It is not correct in that DNSSEC only defines hashes as part of
> > signature algorithms, not separately.
>
> Not quite, there are actually three contexts where DNSSEC defines hashes.
>
> Signature algorithms, where RSASHA256 and RSASHA512 are the most modern.
>
> The DigestType for a DS record, where SHA1 and SHA256 are the ones defined.
>
> And finally the NSEC3 hash function, where only SHA1 is defined.
>

Lets say you live in a house built in 1980, it does not have smoke alarms.
But you want to buy a new house, it has to have smoke alarms and if you
renovate an old house, you have to retrofit.

We can't depend on existing protocols for precedent here. DNSSEC is in the
middle of a deployment phase and the code base is going to be changing for
some time. I do not expect us to have a final code base for verifiers until
long after the algorithm competition concludes in 2012.

At the conclusion of the competition I expect that we will have a complete
suite of symmetric algorithms that there is a broad industry consensus to
support. At that point I would expect that to become a requirement across
the board.

The concern about the security of SHA1 is sufficient to make use in new
protocols inappropriate but does not rise to the level of justifying
emergency action to update existing protocols.

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

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

On Sat, Mar 5, 2011 at 11:26 AM, George Barwood <span dir="ltr">&lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
----- Original Message -----<br>
From: &quot;Paul Hoffman&quot; &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br>
To: &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br>
Sent: Saturday, March 05, 2011 3:59 PM<br>
Subject: Re: [keyassure] Opening issue #21: &quot;Need to specify which crypto algorithms and certificate types are mandatory to implement&quot;<br>
<br>
<br>
&gt; It is not correct in that DNSSEC only defines hashes as part of<br>
&gt; signature algorithms, not separately.<br>
<br>
</div>Not quite, there are actually three contexts where DNSSEC defines hashes.<br>
<br>
Signature algorithms, where RSASHA256 and RSASHA512 are the most modern.<br>
<br>
The DigestType for a DS record, where SHA1 and SHA256 are the ones defined.<br>
<br>
And finally the NSEC3 hash function, where only SHA1 is defined.<font class="Apple-style-span" color="#888888"><br></font></blockquote></div><div><br></div><div><br></div><div>Lets say you live in a house built in 1980, it does not have smoke alarms. But you want to buy a new house, it has to have smoke alarms and if you renovate an old house, you have to retrofit.</div>
<br>We can&#39;t depend on existing protocols for precedent here. DNSSEC is in the middle of a deployment phase and the code base is going to be changing for some time. I do not expect us to have a final code base for verifiers until long after the algorithm competition concludes in 2012.<div>
<br></div><div><br></div><div>At the conclusion of the competition I expect that we will have a complete suite of symmetric algorithms that there is a broad industry consensus to support. At that point I would expect that to become a requirement across the board.<br>
<div><br></div><div>The concern about the security of SHA1 is sufficient to make use in new protocols inappropriate but does not rise to the level of justifying emergency action to update existing protocols.</div><div><br clear="all">
<br>-- <br>Website: <a href="http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div></div>

--00032555450ebacfba049dbef445--

Date: Sat, 05 Mar 2011 08:35:46 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto algorithms and certificate types are mandatory to implement"

On 3/5/11 8:26 AM, George Barwood wrote:
>
> ----- Original Message -----
> From: "Paul Hoffman"<[email-masked]>
> To:<[email-masked]>
> Sent: Saturday, March 05, 2011 3:59 PM
> Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto algorithms and certificate types are mandatory to implement"
>
>
>> It is not correct in that DNSSEC only defines hashes as part of
>> signature algorithms, not separately.
>
> Not quite, there are actually three contexts where DNSSEC defines hashes.
>
> Signature algorithms, where RSASHA256 and RSASHA512 are the most modern.
>
> The DigestType for a DS record, where SHA1 and SHA256 are the ones defined.
>
> And finally the NSEC3 hash function, where only SHA1 is defined.
>

<sigh> Quite right. And, for those of you who want to find these (I 
missed the middle one and purposely ignored the last one), they are at

- Signature algs: <http://www.iana.org/assignments/dns-sec-alg-numbers>

- DigestType for DS: <http://www.iana.org/assignments/ds-rr-types/>

- NSEC3: <http://www.iana.org/assignments/dnssec-nsec3-parameters>

Date: Sat, 5 Mar 2011 11:33:01 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto algorithms and certificate types are mandatory to implement"

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

We do require TLS however.

VeriSign and Comodo have created roots with SHA2-256 and SHA2-384, the
choice is thus not 'oddball'.

>From a strict security point of view SHA2-512 is more secure than SHA2-384,
there is no attack on 512 that will not also break 384.

However, there is an interesting piece of logic at work here.

First, let me point out that SHA2-384 (m) = trunc (SHA2-512 (m), 384). Its
the same algorithm, just truncated.

The criteria for abandoning an existing digest is not when the work factor
below a certain threshold, it is when the work factor falls significantly
below that advertised.

Thus we started getting worried about SHA1 when attacks were announced that
shaved only about 15 bits off the strength, even though what remained was
sufficient for any purpose. The reason we got worried was that customers
started to ask questions and that starts to cost real money when you have a
lot of customers and a lot of sales people.

So SHA2-384 is to be preferred over SHA2-512 because even though it is
easier to break, it has a much higher safety factor.

If someone comes up with an attack against SHA2-512 with O(2^480/2)
complexity it would reduce the cost of attacking SHA2-512 but not the cost
of attacking SHA2-384. So the 512 bit version would be 'compromised' but the
384 version would not.

On Sat, Mar 5, 2011 at 10:59 AM, Paul Hoffman <[email-masked]> wrote:

> On 3/5/11 1:01 AM, Jakob Schlyter wrote:
>
>> On 4 mar 2011, at 18.37, Ben Laurie wrote:
>>
>>  On 3 March 2011 19:36, Warren Kumari<[email-masked]>  wrote:
>>>
>>>> Hi all,
>>>>
>>>> After watching the thread, I'd like to propose this as a strawman:
>>>>
>>>> Mandatory to implement algorithms are SHA-256 and SHA-384. For now,
>>>> these are all we specify.
>>>>
>>>> My reasoning behind this is:
>>>> 3: In order to do DANE, you have to be able to do DNSSEC -- in order to
>>>> do DNSSEC you should already support the above.
>>>>
>>>
>>> Hang on. SHA-384? I don't think that is required by DNSSEC.
>>>
>>
>> Correct, in order to require what DNSSEC use we should specify SHA-256 and
>> SHA-512.
>>
>
> Not actually correct, and not actually relevant.
>
> It is not correct in that DNSSEC only defines hashes as part of signature
> algorithms, not separately. And, if we are going to go that route, the only
> hash that is mandatory for DNSSEC is SHA-1; it feels like this WG doesn't
> want to go there.
>
> It is also not relevant because we do not demand TLS applications to be
> doing DNSSEC themselves: they simply need to know that DNSSEC was used on
> the data they receive.
>
> This is not an argument against SHA-512, but if we are going to make
> arguments for its use, let's make sensible ones. I don't think there are
> many sensible ones for anything other than SHA-1, so we can just pick what
> we want.
>
> --Paul Hoffman
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

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

We do require TLS however.<div><br></div><div>VeriSign and Comodo have created roots with SHA2-256 and SHA2-384, the choice is thus not &#39;oddball&#39;.</div><div><br></div><div>From a strict security point of view SHA2-512 is more secure than SHA2-384, there is no attack on 512 that will not also break 384.</div>
<div><br></div><div>However, there is an interesting piece of logic at work here.�</div><div><br></div><div><meta charset="utf-8"><div><br></div><div>First, let me point out that SHA2-384 (m) = trunc (SHA2-512 (m), 384). Its the same algorithm, just truncated.</div>
</div><div><br></div><div><br></div><div>The criteria for abandoning an existing digest is not when the work factor below a certain threshold, it is when the work factor falls significantly below that advertised.</div><div>
<br></div><div>Thus we started getting worried about SHA1 when attacks were announced that shaved only about 15 bits off the strength, even though what remained was sufficient for any purpose. The reason we got worried was that customers started to ask questions and that starts to cost real money when you have a lot of customers and a lot of sales people.</div>
<div><br></div><div>So SHA2-384 is to be preferred over SHA2-512 because even though it is easier to break, it has a much higher safety factor.</div><div><br></div><div>If someone comes up with an attack against SHA2-512 with O(2^480/2) complexity it would reduce the cost of attacking SHA2-512 but not the cost of attacking SHA2-384. So the 512 bit version would be &#39;compromised&#39; but the 384 version would not.</div>
<div><br></div><div><br></div><div><br><div class="gmail_quote">On Sat, Mar 5, 2011 at 10:59 AM, Paul Hoffman <span dir="ltr">&lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 3/5/11 1:01 AM, Jakob Schlyter wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 4 mar 2011, at 18.37, Ben Laurie wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 3 March 2011 19:36, Warren Kumari&lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; �wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi all,<br>
<br>
After watching the thread, I&#39;d like to propose this as a strawman:<br>
<br>
Mandatory to implement algorithms are SHA-256 and SHA-384. For now, these are all we specify.<br>
<br>
My reasoning behind this is:<br>
3: In order to do DANE, you have to be able to do DNSSEC -- in order to do DNSSEC you should already support the above.<br>
</blockquote>
<br>
Hang on. SHA-384? I don&#39;t think that is required by DNSSEC.<br>
</blockquote>
<br>
Correct, in order to require what DNSSEC use we should specify SHA-256 and SHA-512.<br>
</blockquote>
<br></div>
Not actually correct, and not actually relevant.<br>
<br>
It is not correct in that DNSSEC only defines hashes as part of signature algorithms, not separately. And, if we are going to go that route, the only hash that is mandatory for DNSSEC is SHA-1; it feels like this WG doesn&#39;t want to go there.<br>

<br>
It is also not relevant because we do not demand TLS applications to be doing DNSSEC themselves: they simply need to know that DNSSEC was used on the data they receive.<br>
<br>
This is not an argument against SHA-512, but if we are going to make arguments for its use, let&#39;s make sensible ones. I don&#39;t think there are many sensible ones for anything other than SHA-1, so we can just pick what we want.<br>
<font color="#888888">
<br>
--Paul Hoffman</font><div><div></div><div class="h5"><br>
_______________________________________________<br>
keyassure mailing list<br>
<a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>
<a href="https://www.ietf.org/mailman/listinfo/keyassure" target="_blank">https://www.ietf.org/mailman/listinfo/keyassure</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Website: <a href="http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div>

--0015175def8ceb8938049dbed06d--

From: "George Barwood" <[email-masked]>
To: "Paul Hoffman" <[email-masked]>, <[email-masked]>
Date: Sat, 5 Mar 2011 16:26:29 -0000
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto algorithms and certificate types are mandatory to implement"

Date: Sat, 05 Mar 2011 07:59:48 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto algorithms and certificate types are mandatory to implement"

On 3/5/11 1:01 AM, Jakob Schlyter wrote:
> On 4 mar 2011, at 18.37, Ben Laurie wrote:
>
>> On 3 March 2011 19:36, Warren Kumari<[email-masked]>  wrote:
>>> Hi all,
>>>
>>> After watching the thread, I'd like to propose this as a strawman:
>>>
>>> Mandatory to implement algorithms are SHA-256 and SHA-384. For now, these are all we specify.
>>>
>>> My reasoning behind this is:
>>> 3: In order to do DANE, you have to be able to do DNSSEC -- in order to do DNSSEC you should already support the above.
>>
>> Hang on. SHA-384? I don't think that is required by DNSSEC.
>
> Correct, in order to require what DNSSEC use we should specify SHA-256 and SHA-512.

Not actually correct, and not actually relevant.

It is not correct in that DNSSEC only defines hashes as part of 
signature algorithms, not separately. And, if we are going to go that 
route, the only hash that is mandatory for DNSSEC is SHA-1; it feels 
like this WG doesn't want to go there.

It is also not relevant because we do not demand TLS applications to be 
doing DNSSEC themselves: they simply need to know that DNSSEC was used 
on the data they receive.

This is not an argument against SHA-512, but if we are going to make 
arguments for its use, let's make sensible ones. I don't think there are 
many sensible ones for anything other than SHA-1, so we can just pick 
what we want.

--Paul Hoffman

From: Jakob Schlyter <[email-masked]>
Date: Sat, 5 Mar 2011 10:01:31 +0100
To: Ben Laurie <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto algorithms and certificate types are mandatory to implement"

On 4 mar 2011, at 18.37, Ben Laurie wrote:

> On 3 March 2011 19:36, Warren Kumari <[email-masked]> wrote:
>> Hi all,
>> 
>> After watching the thread, I'd like to propose this as a strawman:
>> 
>> Mandatory to implement algorithms are SHA-256 and SHA-384. For now, these are all we specify.
>> 
>> My reasoning behind this is:
>> 3: In order to do DANE, you have to be able to do DNSSEC -- in order to do DNSSEC you should already support the above.
> 
> Hang on. SHA-384? I don't think that is required by DNSSEC.

Correct, in order to require what DNSSEC use we should specify SHA-256 and SHA-512.

	jakob

Date: Fri, 4 Mar 2011 17:37:18 +0000
From: Ben Laurie <[email-masked]>
To: Warren Kumari <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto algorithms and certificate types are mandatory to implement"

On 3 March 2011 19:36, Warren Kumari <[email-masked]> wrote:
> Hi all,
>
> After watching the thread, I'd like to propose this as a strawman:
>
> Mandatory to implement algorithms are SHA-256 and SHA-384. For now, these are all we specify.
>
> My reasoning behind this is:
> 3: In order to do DANE, you have to be able to do DNSSEC -- in order to do DNSSEC you should already support the above.

Hang on. SHA-384? I don't think that is required by DNSSEC.

From: "Murray S. Kucherawy" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Fri, 4 Mar 2011 08:49:43 -0800
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto algorithms and certificate types are mandatory to implement"

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Hoffman
> Sent: Thursday, March 03, 2011 5:46 PM
> To: [email-masked]
> Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto algorithms and certificate types are mandatory to implement"
> 
> On 3/3/11 4:29 PM, Phillip Hallam-Baker wrote:
> > That works for me
> 
> And me as well.

+1

From: "Murray S. Kucherawy" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Fri, 4 Mar 2011 08:48:07 -0800
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Gutmann
> Sent: Friday, March 04, 2011 6:13 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto
> 
> >If SHA3 is ready in time (i.e. we are still not ready in 2012) we could
> >consider making SHA3-256 the required algorithm. If not make SHA2-256 and
> >SHA2-512 the required algorithms.
> 
> Sounds good, although I'd make 256 a MUST and 512 a MAY, both to keep the
> every-bit-is-sacred crowd happy and because in practice there's going to be a
> de facto universal default that everyone uses, and my guess is it'll be -256,
> in the same way that currently the universal default that everyone uses is
> SHA1, no matter what other algorithms the spec allows.

If the experience with DKIM (which did MUST for SHA1 and SHOULD for SHA256) is any indication, your guess is right on the money.

Date: Fri, 4 Mar 2011 11:15:50 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

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

On Fri, Mar 4, 2011 at 9:39 AM, Paul Hoffman <[email-masked]> wrote:

> On 3/4/11 5:57 AM, Phillip Hallam-Baker wrote:
>
>> OK, how about this
>>
>> Define code points for
>>
>> SHA2-256
>> SHA2-512
>> SHA3-256 (reserved)
>> SHA3-512 (reserved)
>>
>
> This would only work if we knew today that there will be algorithms with
> those exact names. Those of us following the NIST hash competition have seen
> that there is a good chance that will *not* be the case: NIST is explicitly
> allowing (some would say encouraging) parameters on the functions.

All the finalists are designed to be used as a drop in replacement for SHA2,
which is a mandatory requirement.

But I do prefer using a hash that incorporates random data in the hash
mechanism. It provides a lot of protection against attack, in most cases an
attacker has to achieve a first preimage attack rather than a second.

So while we could certainly reserve a slot now, it is likely that there will
be further discussion on the choice of mode. And I would really like us to
be having one IETF conversation at that point and not ten with different
combinations of what is mostly the same people.

Since we are going to be using this with TLS it is probably going to make
most sense to consider what algorithms TLS is going to use.

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

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

On Fri, Mar 4, 2011 at 9:39 AM, Paul Hoffman <span dir="ltr">&lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 3/4/11 5:57 AM, Phillip Hallam-Baker wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
OK, how about this<br>
<br>
Define code points for<br>
<br>
SHA2-256<br>
SHA2-512<br>
SHA3-256 (reserved)<br>
SHA3-512 (reserved)<br>
</blockquote>
<br></div>
This would only work if we knew today that there will be algorithms with those exact names. Those of us following the NIST hash competition have seen that there is a good chance that will *not* be the case: NIST is explicitly allowing (some would say encouraging) parameters on the functions.</blockquote>
<div><br></div><div>All the finalists are designed to be used as a drop in replacement for SHA2, which is a mandatory requirement.</div><div><br></div><div>But I do prefer using a hash that incorporates random data in the hash mechanism. It provides a lot of protection against attack, in most cases an attacker has to achieve a first preimage attack rather than a second.�</div>
<div>�</div><div><br></div><div>So while we could certainly reserve a slot now, it is likely that there will be further discussion on the choice of mode.�And I would really like us to be having one IETF conversation at that point and not ten with different combinations of what is mostly the same people.</div>
<div><br></div><div>Since we are going to be using this with TLS it is probably going to make most sense to consider what algorithms TLS is going to use.</div><div><br></div><div><br></div></div>-- <br>Website: <a href="http://hallambaker.com/">http://hallambaker.com/</a><br>
<br>

--0015175cf8d4a5ba18049daa759a--

Date: Fri, 4 Mar 2011 15:19:34 +0000
From: [email-masked]
To: Andrew Sullivan <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

On Fri, Mar 04, 2011 at 07:13:18AM -0500, Andrew Sullivan wrote:
> On Fri, Mar 04, 2011 at 11:51:10PM +1300, Peter Gutmann wrote:
> > is finalised all I need to do is plug the algorithm in.  Putting the same
> > thing into DANE isn't hard, and makes it easier to deploy future-compatible
> > implementations from day one.
> 
> I don't see any reason to say specifically, "We'll be moving to _x_ so
> you better have a placeholder for it".  That will simply encourage
> foolish programmers to write one placeholder spot, and then when SHA-4
> or whatever comes along we have a new problem.

	depends on how the spec is written.  you have already 
	indicated a preference for more than one algo.  Lets call
	them current & future.  for current, lets say we use SHA-256
	and future, SHA3.   we could then move SHA3 to current and
	move AndrewsKewlKode to future...  and so on...  right?

> The right way to do this is something like the unknown RRTYPE in DNS.
> In that case, you have to be able to handle anything you get (within
> the valid codepoint range) _even if_ you don't understand it.  By
> "handle", I mean, "be able to pass messages; not spit up and die," and
> so on.  It does not mean, of course, that you have to be able to do
> whatever additional section processing or whatever is required, and
> you don't need to be able to do anything useful (if you don't know
> what NSEC3 is, you're not going to be able to validate with it).  
> 
> I'm not sure how to say something similar in this case, but I think
> it's the right sort of framework.
> 
> A
> 
> -- 
> Andrew Sullivan
> [email-masked]
> Shinkuro, Inc.
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Date: Fri, 04 Mar 2011 06:58:32 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

On 3/4/11 6:13 AM, Peter Gutmann wrote:
> Phillip Hallam-Baker<[email-masked]>  writes:
>
>> OK, how about this
>>
>> Define code points for
>>
>> SHA2-256
>> SHA2-512
>> SHA3-256 (reserved)
>> SHA3-512 (reserved)
>>
>> If SHA3 is ready in time (i.e. we are still not ready in 2012) we could
>> consider making SHA3-256 the required algorithm. If not make SHA2-256 and
>> SHA2-512 the required algorithms.
>
> Sounds good, although I'd make 256 a MUST and 512 a MAY, both to keep the
> every-bit-is-sacred crowd happy and because in practice there's going to be a
> de facto universal default that everyone uses, and my guess is it'll be -256,
> in the same way that currently the universal default that everyone uses is
> SHA1, no matter what other algorithms the spec allows.

While I prefer Warren's original proposal (two mandatory algorithms 
now), I can see a reason to have just one now followed by strong wording 
that we are likely to change this in the foreseeable future to a 
specific code point so implementers need to plan for that now. We don't 
have to be specific about what will go in that code point because we 
won't know until NIST is finished, but we can say that we expect that to 
become mandatory as well.

--Paul Hoffman

Date: Fri, 4 Mar 2011 09:51:29 -0500
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

On Fri, Mar 04, 2011 at 06:36:42AM -0800, Paul Hoffman wrote:
> The way I read Warren's proposal, we get exactly what you want. There  
> are two different mandatory code points defined for two different  
> hashes, so we are sure that the deployed code will be able to handle  
> hash agility. We don't care which algorithm people use in practice  
> because they are both mandatory, so there is no spitting up or dying.
>
> Does that work for you?

Sort of.  Maybe it's recent exposure to brain-dead programmers, but
I've encountered the situation where a spec says, "There are now two;
there might be more in the future."  What the programmer does is go
away and write an implementation that has the two, and puts a comment
in the code that says, "Future code changes may need to be here,
because there might be new things defined."  Or something like that.

As I say, I can't think of much to say about this that's different, so
maybe I'm fretting over nothing.  But algorithm maintenance is already
a headache for DNSSEC, and we've only started deployment.

A

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

Date: Fri, 04 Mar 2011 06:39:12 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

On 3/4/11 5:57 AM, Phillip Hallam-Baker wrote:
> OK, how about this
>
> Define code points for
>
> SHA2-256
> SHA2-512
> SHA3-256 (reserved)
> SHA3-512 (reserved)

This would only work if we knew today that there will be algorithms with 
those exact names. Those of us following the NIST hash competition have 
seen that there is a good chance that will *not* be the case: NIST is 
explicitly allowing (some would say encouraging) parameters on the 
functions.

--Paul Hoffman

Date: Fri, 04 Mar 2011 06:36:42 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

On 3/4/11 4:13 AM, Andrew Sullivan wrote:
> On Fri, Mar 04, 2011 at 11:51:10PM +1300, Peter Gutmann wrote:
>> is finalised all I need to do is plug the algorithm in.  Putting the same
>> thing into DANE isn't hard, and makes it easier to deploy future-compatible
>> implementations from day one.
>
> I don't see any reason to say specifically, "We'll be moving to _x_ so
> you better have a placeholder for it".  That will simply encourage
> foolish programmers to write one placeholder spot, and then when SHA-4
> or whatever comes along we have a new problem.
>
> The right way to do this is something like the unknown RRTYPE in DNS.
> In that case, you have to be able to handle anything you get (within
> the valid codepoint range) _even if_ you don't understand it.  By
> "handle", I mean, "be able to pass messages; not spit up and die," and
> so on.  It does not mean, of course, that you have to be able to do
> whatever additional section processing or whatever is required, and
> you don't need to be able to do anything useful (if you don't know
> what NSEC3 is, you're not going to be able to validate with it).
>
> I'm not sure how to say something similar in this case, but I think
> it's the right sort of framework.

The way I read Warren's proposal, we get exactly what you want. There 
are two different mandatory code points defined for two different 
hashes, so we are sure that the deployed code will be able to handle 
hash agility. We don't care which algorithm people use in practice 
because they are both mandatory, so there is no spitting up or dying.

Does that work for you?

--Paul Hoffman

From: Peter Gutmann <[email-masked]>
To: [email-masked], [email-masked]
Date: Sat, 05 Mar 2011 03:13:26 +1300
Cc: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

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

>OK, how about this
>
>Define code points for
>
>SHA2-256
>SHA2-512
>SHA3-256 (reserved)
>SHA3-512 (reserved)
>
>If SHA3 is ready in time (i.e. we are still not ready in 2012) we could
>consider making SHA3-256 the required algorithm. If not make SHA2-256 and
>SHA2-512 the required algorithms.

Sounds good, although I'd make 256 a MUST and 512 a MAY, both to keep the
every-bit-is-sacred crowd happy and because in practice there's going to be a
de facto universal default that everyone uses, and my guess is it'll be -256,
in the same way that currently the universal default that everyone uses is
SHA1, no matter what other algorithms the spec allows.

Peter.

Date: Fri, 4 Mar 2011 08:57:09 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

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

OK, how about this

Define code points for

SHA2-256
SHA2-512
SHA3-256 (reserved)
SHA3-512 (reserved)

If SHA3 is ready in time (i.e. we are still not ready in 2012) we could
consider making SHA3-256 the required algorithm. If not make SHA2-256 and
SHA2-512 the required algorithms.

I don't see the objective here being 'algorithm agility' like we were
fixated on in the 90s. We are not picking eight algorithms with a similar
level of security in the hope that one of them is going to be secure.

What we are doing here is coping with the fact that at the moment we do not
have an industry standard digest function that we can be completely happy
with and we are currently in the mid point of a transition.

On Fri, Mar 4, 2011 at 7:46 AM, Martin Rex <[email-masked]> wrote:

> Warren Kumari wrote:
> >
> > After watching the thread, I'd like to propose this as a strawman:
> >
> > Mandatory to implement algorithms are SHA-256 and SHA-384.
> > For now, these are all we specify.
> >
> > 2: Having more than 1 algorithm forces implementations to understand that
> > there is not just one, and so should help lead towards algorithm agility
>
> I'm OK with defining SHA-256 plus another, stronger hash for use with DANE
>
> I'm OK with mandating SHA-256.
>
>
> I do NOT buy the assertion that it is necessary to have _two_mandatory_
> algorithms for algorithm agility.  For other protocols in the security
> area, one single manadatory and additional recommended&optional
> algorithms are perfectly sufficient.
>
> SHA-384 also looks like an oddball to me.  For agility and interop tests,
> defining SHA-512 should be fine.  I would expect that by the time
> we need to move away from SHA-256, there is a SHA-3 available, and
> it would be OK for DANE to move from SHA-256 mandatory to SHA-3 manadatory
> without ever making SHA-512 mandatory (only recommended).
>
> -Martin
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

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

OK, how about this<div><br></div><div>Define code points for�</div><div><br></div><div>SHA2-256</div><div>SHA2-512</div><div>SHA3-256 (reserved)</div><div>SHA3-512 (reserved)</div><div><br></div><div>If SHA3 is ready in time (i.e. we are still not ready in 2012) we could consider making SHA3-256 the required algorithm. If not make SHA2-256 and SHA2-512 the required algorithms.</div>
<div><br></div><div><br></div><div>I don&#39;t see the objective here being &#39;algorithm agility&#39; like we were fixated on in the 90s. We are not picking eight algorithms with a similar level of security in the hope that one of them is going to be secure.�</div>
<div><br></div><div>What we are doing here is coping with the fact that at the moment we do not have an industry standard digest function that we can be completely happy with and we are currently in the mid point of a transition.</div>
<div><div><br><br><div class="gmail_quote">On Fri, Mar 4, 2011 at 7:46 AM, Martin Rex <span dir="ltr">&lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Warren Kumari wrote:<br>
&gt;<br>
&gt; After watching the thread, I&#39;d like to propose this as a strawman:<br>
&gt;<br>
&gt; Mandatory to implement algorithms are SHA-256 and SHA-384.<br>
&gt; For now, these are all we specify.<br>
&gt;<br>
&gt; 2: Having more than 1 algorithm forces implementations to understand that<br>
&gt; there is not just one, and so should help lead towards algorithm agility<br>
<br>
I&#39;m OK with defining SHA-256 plus another, stronger hash for use with DANE<br>
<br>
I&#39;m OK with mandating SHA-256.<br>
<br>
<br>
I do NOT buy the assertion that it is necessary to have _two_mandatory_<br>
algorithms for algorithm agility. �For other protocols in the security<br>
area, one single manadatory and additional recommended&amp;optional<br>
algorithms are perfectly sufficient.<br>
<br>
SHA-384 also looks like an oddball to me. �For agility and interop tests,<br>
defining SHA-512 should be fine. �I would expect that by the time<br>
we need to move away from SHA-256, there is a SHA-3 available, and<br>
it would be OK for DANE to move from SHA-256 mandatory to SHA-3 manadatory<br>
without ever making SHA-512 mandatory (only recommended).<br>
<font color="#888888"><br>
-Martin<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
keyassure mailing list<br>
<a href="mailto:[email-masked]">[email-masked]</a><br>
<a href="https://www.ietf.org/mailman/listinfo/keyassure" target="_blank">https://www.ietf.org/mailman/listinfo/keyassure</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Website: <a href="http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div></div>

--0016e6d6415aa5dc08049da88515--

From: Martin Rex <[email-masked]>
To: [email-masked] (Warren Kumari)
Date: Fri, 4 Mar 2011 13:46:17 +0100 (MET)
Cc: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto
Reply-To: [email-masked]

Warren Kumari wrote:
> 
> After watching the thread, I'd like to propose this as a strawman:
>
> Mandatory to implement algorithms are SHA-256 and SHA-384.
> For now, these are all we specify.
> 
> 2: Having more than 1 algorithm forces implementations to understand that
> there is not just one, and so should help lead towards algorithm agility

I'm OK with defining SHA-256 plus another, stronger hash for use with DANE

I'm OK with mandating SHA-256.

I do NOT buy the assertion that it is necessary to have _two_mandatory_
algorithms for algorithm agility.  For other protocols in the security
area, one single manadatory and additional recommended&optional
algorithms are perfectly sufficient.

SHA-384 also looks like an oddball to me.  For agility and interop tests,
defining SHA-512 should be fine.  I would expect that by the time
we need to move away from SHA-256, there is a SHA-3 available, and
it would be OK for DANE to move from SHA-256 mandatory to SHA-3 manadatory
without ever making SHA-512 mandatory (only recommended).

-Martin

Date: Fri, 4 Mar 2011 07:13:18 -0500
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

On Fri, Mar 04, 2011 at 11:51:10PM +1300, Peter Gutmann wrote:
> is finalised all I need to do is plug the algorithm in.  Putting the same
> thing into DANE isn't hard, and makes it easier to deploy future-compatible
> implementations from day one.

I don't see any reason to say specifically, "We'll be moving to _x_ so
you better have a placeholder for it".  That will simply encourage
foolish programmers to write one placeholder spot, and then when SHA-4
or whatever comes along we have a new problem.

The right way to do this is something like the unknown RRTYPE in DNS.
In that case, you have to be able to handle anything you get (within
the valid codepoint range) _even if_ you don't understand it.  By
"handle", I mean, "be able to pass messages; not spit up and die," and
so on.  It does not mean, of course, that you have to be able to do
whatever additional section processing or whatever is required, and
you don't need to be able to do anything useful (if you don't know
what NSEC3 is, you're not going to be able to validate with it).  

I'm not sure how to say something similar in this case, but I think
it's the right sort of framework.

A

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

From: Peter Gutmann <[email-masked]>
To: [email-masked], [email-masked]
Date: Fri, 04 Mar 2011 23:51:10 +1300
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

Yoav Nir <[email-masked]> writes:
>On Mar 4, 2011, at 4:26 AM, Nicholas Weaver wrote:
>> We should not try to scrimp 16B out in message formatting in this case, its
>> silly, redundant, AND encouraging brokenness (bad fragmentation & truncation
>> behavior) to remain borken.
>
>I agree.

Ditto.

>That's weird text. If when SHA-3 arrives, the RFC had been published, we make
>a 3-page "SHA-3 and its use in DANE" draft. If it hasn't, we open an issue and
>add it.

It would be good though to include a placeholder for SHA3 to that, at most,
implementations just have to drop in the implementation code.  I've had a
placeholder in my code for a while now, it's been tested throughout the code
(by using a dummy implementation that returns a constant "hash"), so when SHA3
is finalised all I need to do is plug the algorithm in.  Putting the same
thing into DANE isn't hard, and makes it easier to deploy future-compatible
implementations from day one.

Peter.

From: Yoav Nir <[email-masked]>
To: Nicholas Weaver <[email-masked]>
Date: Fri, 4 Mar 2011 08:07:41 +0200
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>, Phillip Hallam-Baker <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

On Mar 4, 2011, at 4:26 AM, Nicholas Weaver wrote:

> 
> On Mar 3, 2011, at 5:44 PM, Phillip Hallam-Baker wrote:
> 
>> 
>> 
>> On Thu, Mar 3, 2011 at 8:19 PM, Peter Gutmann <[email-masked]> wrote:
>> Paul Hoffman <[email-masked]> writes:
>> 
>>> 1) Make support for SHA2-256 and SHA2-384 REQUIRED
>> 
>> Why the oddball SHA384, which is just a truncated SHA512?  If SHA256 isn't
>> enough then use the full SHA512, not some oddball variant.
>> 
>> Because we are working in DNS and so the number of bits is actually an issue.
>> 
>> I agree that there is little point to the truncation step when the digest is used with a digital signature. But here the extra bits do count.
> 
> A whopping 16 bytes does NOT count:  In very VERY few cases will it cause the DNS message to fall past the magic ~1472B and ~4000B boundries where you start to have fragmentation & truncation, AND in those cases, the resolver damn well better be able to handle it.
> 
> We should not try to scrimp 16B out in message formatting in this case, its silly, redundant, AND encouraging brokenness (bad fragmentation & truncation behavior) to remain borken.

I agree.

> 
>> When is your estimate for the SHA3 process completing?
>> 
>> I am a bit nervous having a WG depend on the output of any external process.
> 
> Why not "AND, when NIST approves it, SHA3"? in the text?

That's weird text. If when SHA-3 arrives, the RFC had been published, we make a 3-page "SHA-3 and its use in DANE" draft. If it hasn't, we open an issue and add it.

From: Nicholas Weaver <[email-masked]>
Date: Thu, 3 Mar 2011 18:26:36 -0800
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

On Mar 3, 2011, at 5:44 PM, Phillip Hallam-Baker wrote:

> 
> 
> On Thu, Mar 3, 2011 at 8:19 PM, Peter Gutmann <[email-masked]> wrote:
> Paul Hoffman <[email-masked]> writes:
> 
> >1) Make support for SHA2-256 and SHA2-384 REQUIRED
> 
> Why the oddball SHA384, which is just a truncated SHA512?  If SHA256 isn't
> enough then use the full SHA512, not some oddball variant.
> 
> Because we are working in DNS and so the number of bits is actually an issue.
> 
> I agree that there is little point to the truncation step when the digest is used with a digital signature. But here the extra bits do count.

A whopping 16 bytes does NOT count:  In very VERY few cases will it cause the DNS message to fall past the magic ~1472B and ~4000B boundries where you start to have fragmentation & truncation, AND in those cases, the resolver damn well better be able to handle it.

We should not try to scrimp 16B out in message formatting in this case, its silly, redundant, AND encouraging brokenness (bad fragmentation & truncation behavior) to remain borken.

> When is your estimate for the SHA3 process completing?
> 
> I am a bit nervous having a WG depend on the output of any external process.

Why not "AND, when NIST approves it, SHA3"? in the text?

Date: Thu, 03 Mar 2011 17:45:30 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto algorithms and certificate types are mandatory to implement"

On 3/3/11 4:29 PM, Phillip Hallam-Baker wrote:
> That works for me

And me as well.

--Paul Hoffman

Date: Thu, 3 Mar 2011 20:44:52 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Peter Gutmann <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

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

On Thu, Mar 3, 2011 at 8:19 PM, Peter Gutmann <[email-masked]>wrote:

> Paul Hoffman <[email-masked]> writes:
>
> >1) Make support for SHA2-256 and SHA2-384 REQUIRED
>
> Why the oddball SHA384, which is just a truncated SHA512?  If SHA256 isn't
> enough then use the full SHA512, not some oddball variant.
>

Because we are working in DNS and so the number of bits is actually an
issue.

I agree that there is little point to the truncation step when the digest is
used with a digital signature. But here the extra bits do count.

> In any case what we should really be specifying is SHA256 and SHA3.  If
> SHA256
> really isn't cromulent enough for people then SHA384 won't be either, and
> by
> the time this sees significant deployment we'll have SHA3 anyway.  How much
> real-world support is there for SHA384?  I've only just seen SHA256
> creeping
> in here and there, but never SHA384.  Again, by the time there's even
> single-
> digit deployment of SHA384 (if there ever is), we'll have SHA3 ready to go.

When is your estimate for the SHA3 process completing?

I am a bit nervous having a WG depend on the output of any external process.

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

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

<br><br><div class="gmail_quote">On Thu, Mar 3, 2011 at 8:19 PM, Peter Gutmann <span dir="ltr">&lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">Paul Hoffman &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt; writes:<br>
<br>
&gt;1) Make support for SHA2-256 and SHA2-384 REQUIRED<br>
<br>
</div>Why the oddball SHA384, which is just a truncated SHA512? �If SHA256 isn&#39;t<br>
enough then use the full SHA512, not some oddball variant.<br></blockquote><div><br></div><div>Because we are working in DNS and so the number of bits is actually an issue.</div><div><br></div><div>I agree that there is little point to the truncation step when the digest is used with a digital signature. But here the extra bits do count.</div>
<div><br></div><div>�</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
In any case what we should really be specifying is SHA256 and SHA3. �If SHA256<br>
really isn&#39;t cromulent enough for people then SHA384 won&#39;t be either, and by<br>
the time this sees significant deployment we&#39;ll have SHA3 anyway. �How much<br>
real-world support is there for SHA384? �I&#39;ve only just seen SHA256 creeping<br>
in here and there, but never SHA384. �Again, by the time there&#39;s even single-<br>
digit deployment of SHA384 (if there ever is), we&#39;ll have SHA3 ready to go.</blockquote><div><br></div><div>When is your estimate for the SHA3 process completing?</div><div><br></div><div>I am a bit nervous having a WG depend on the output of any external process.</div>
<div>�</div></div><br>-- <br>Website: <a href="http://hallambaker.com/">http://hallambaker.com/</a><br><br>

--0016e6d6415ad8d1d1049d9e4ac2--

From: Peter Gutmann <[email-masked]>
To: [email-masked], [email-masked]
Date: Fri, 04 Mar 2011 14:19:48 +1300
Cc: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

Paul Hoffman <[email-masked]> writes:

>1) Make support for SHA2-256 and SHA2-384 REQUIRED

Why the oddball SHA384, which is just a truncated SHA512?  If SHA256 isn't
enough then use the full SHA512, not some oddball variant.

In any case what we should really be specifying is SHA256 and SHA3.  If SHA256
really isn't cromulent enough for people then SHA384 won't be either, and by
the time this sees significant deployment we'll have SHA3 anyway.  How much
real-world support is there for SHA384?  I've only just seen SHA256 creeping
in here and there, but never SHA384.  Again, by the time there's even single-
digit deployment of SHA384 (if there ever is), we'll have SHA3 ready to go.

Peter.

Date: Thu, 03 Mar 2011 17:17:02 -0800
From: Paul Hoffman <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [keyassure] Not yet for WG consideration: draft-hoffman-dane-smime-00.txt

This is a multi-part message in MIME format.
--------------020105010507090504000909
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

This is just a heads-up that Jakob and I have submitted a new draft that 
might be considered by the WG, BUT NOT YET. We did this now so that we 
can do a brief presentation at the Prague meeting, but the chairs have 
asked that we *not* take WG focus from the current TLSA work, and that 
sounds fine to us.

--Paul Hoffman

-------- Original Message --------
Subject: I-D Action:draft-hoffman-dane-smime-00.txt
Date: Thu, 03 Mar 2011 13:45:01 -0800
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title           : Using Secure DNS to Associate Certificates with 
Domain Names For S/MIME
	Author(s)       : P. Hoffman, J. Schlyter
	Filename        : draft-hoffman-dane-smime-00.txt
	Pages           : 8
	Date            : 2011-03-03

S/MIME uses certificates for authenticating and encrypting messages.
Users want their mail user agents to securely associate a certificate
with the sender of an encrypted and/or signed message.  DNSSEC
provides a mechanism for a zone operator to sign DNS information
directly.  This way, bindings of certificates to users within a
domain are asserted not by external entities, but by the entities
that operate the DNS.  This document describes how to use secure DNS
to associate an S/MIME user's certificate with the the intended
domain name.

IMPORTANT NOTE: This draft is intentionally sketchy.  It is meant as
a possible starting point for the DANE WG if it wants to consider
making a protocol similar to TLSA, as described in
draft-ietf-dane-protocol, but that applies to S/MIME.  The WG may or
may not want to adopt such work, or if it does, may want to use a
very different scheme from the one described here.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hoffman-dane-smime-00.txt

--------------020105010507090504000909
Content-Type: Message/External-body;
 name="draft-hoffman-dane-smime-00.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="draft-hoffman-dane-smime-00.txt"

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

--------------020105010507090504000909
Content-Type: text/plain;
 name="Attached Message Part"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="Attached Message Part"

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--------------020105010507090504000909--

From: Peter Gutmann <[email-masked]>
To: [email-masked], [email-masked]
Date: Fri, 04 Mar 2011 13:57:53 +1300
Cc: [email-masked]
Subject: Re: [keyassure] crypto hash alg deprecation is a myth

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

>The reason that there is concern about algorithm support in protocols is that
>it takes a very very long time to get changes through the system. It can take
>five years to persuade vendors to make changes and then another ten for the
>old software to work through the system.

See also Question J of
http://www.cs.auckland.ac.nz/~pgut001/pubs/crypto_guide.txt (based on a very
ad hoc survey of a bunch of implementers, but it's good enough as a rough
guide).

Peter.

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

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

That works for me

On Thu, Mar 3, 2011 at 2:36 PM, Warren Kumari <[email-masked]> wrote:

> Hi all,
>
> After watching the thread, I'd like to propose this as a strawman:
>
> Mandatory to implement algorithms are SHA-256 and SHA-384. For now, these
> are all we specify.
>
> My reasoning behind this is:
> 1: We don't want to support too many algorithms -- it leads to complexity
> (which leads to weaker security) and opens the door to interoperability
> issues and fights over why algorithm X was allowed and Y was not.
>
> 2: Having more than 1 algorithm forces implementations to understand that
> there is not just one, and so should help lead towards algorithm agility
>
> 3: In order to do DANE, you have to be able to do DNSSEC -- in order to do
> DNSSEC you should already support the above.
>
> 4: (IMO, an important one, even if not technical one) giving people the
> ability to choose will lead to greater deployment. Some folk will claim that
> SHA-256 is too short. Some will claim that SHA-384 is excessively long and
> computationally expensive. Some will claim something completely random.
> Almost none of them will have any (rational) basis for their claims, but
> allowing them to use the algorithm they believe is superior will make them
> more likely to deploy.
>
> 5: 2 algorithms seems like enough. While SHA1 may or may not be suitable
> (my (and to be completely blunt, your) views don't really matter) -- there
> are enough strong views on the strength / lifetime that we are likely to get
> bogged down / splinter over this. If we were already deployed with SHA1 this
> would be an important decision, but seeing as we're not, I think that
> avoiding fight (and living to see another day) is best.
> Once again, I'm not saying that I think that SHA1 is (or isn't) fine for
> this, rather that, in order to get deployed, we should avoid the issue.
>
> #4 and #5 might be pandering, but if it doesn't decrease security, and
> leads to sooner / more deployment it seems like a win....
>
> Does anyone object to this (for any reasons other than "You're running away
> from the fight, you coward!")?
> Please speak soon, as we'd love to close this out....
>
> <chair hat>
> Please don't let this dissolve into a "algorithm X is better than Y, and Z
> is a pile o' rubble" discussion -- while that may be true, this is not the
> time or place to have it....
> </chair hat>
>
> W
>
>
> On Feb 25, 2011, at 4:31 PM, Warren Kumari wrote:
>
> > Hi all,
> >
> > While we are all ruminating on the other issues, I figured we might as
> well try address this one:
> >
> > Need to specify which crypto algorithms and certificate types are
> mandatory to implement --
> http://trac.tools.ietf.org/wg/dane/trac/ticket/21
> >
> > Description:
> > Currently, the draft is silent on which crypto algorithms and certificate
> types must be implemented for interoperability. It should be specific before
> the document is finished.
> >
> >
> > 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/

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

That works for me<div><br><div><br><div class="gmail_quote">On Thu, Mar 3, 2011 at 2:36 PM, Warren Kumari <span dir="ltr">&lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi all,<br>
<br>
After watching the thread, I&#39;d like to propose this as a strawman:<br>
<br>
Mandatory to implement algorithms are SHA-256 and SHA-384. For now, these are all we specify.<br>
<br>
My reasoning behind this is:<br>
1: We don&#39;t want to support too many algorithms -- it leads to complexity (which leads to weaker security) and opens the door to interoperability issues and fights over why algorithm X was allowed and Y was not.<br>
<br>
2: Having more than 1 algorithm forces implementations to understand that there is not just one, and so should help lead towards algorithm agility<br>
<br>
3: In order to do DANE, you have to be able to do DNSSEC -- in order to do DNSSEC you should already support the above.<br>
<br>
4: (IMO, an important one, even if not technical one) giving people the ability to choose will lead to greater deployment. Some folk will claim that SHA-256 is too short. Some will claim that SHA-384 is excessively long and computationally expensive. Some will claim something completely random. Almost none of them will have any (rational) basis for their claims, but allowing them to use the algorithm they believe is superior will make them more likely to deploy.<br>

<br>
5: 2 algorithms seems like enough. While SHA1 may or may not be suitable (my (and to be completely blunt, your) views don&#39;t really matter) -- there are enough strong views on the strength / lifetime that we are likely to get bogged down / splinter over this. If we were already deployed with SHA1 this would be an important decision, but seeing as we&#39;re not, I think that avoiding fight (and living to see another day) is best.<br>

Once again, I&#39;m not saying that I think that SHA1 is (or isn&#39;t) fine for this, rather that, in order to get deployed, we should avoid the issue.<br>
<br>
#4 and #5 might be pandering, but if it doesn&#39;t decrease security, and leads to sooner / more deployment it seems like a win....<br>
<br>
Does anyone object to this (for any reasons other than &quot;You&#39;re running away from the fight, you coward!&quot;)?<br>
Please speak soon, as we&#39;d love to close this out....<br>
<br>
&lt;chair hat&gt;<br>
Please don&#39;t let this dissolve into a &quot;algorithm X is better than Y, and Z is a pile o&#39; rubble&quot; discussion -- while that may be true, this is not the time or place to have it....<br>
&lt;/chair hat&gt;<br>
<font color="#888888"><br>
W<br>
</font><div><div></div><div class="h5"><br>
<br>
On Feb 25, 2011, at 4:31 PM, Warren Kumari wrote:<br>
<br>
&gt; Hi all,<br>
&gt;<br>
&gt; While we are all ruminating on the other issues, I figured we might as well try address this one:<br>
&gt;<br>
&gt; Need to specify which crypto algorithms and certificate types are mandatory to implement -- <a href="http://trac.tools.ietf.org/wg/dane/trac/ticket/21" target="_blank">http://trac.tools.ietf.org/wg/dane/trac/ticket/21</a><br>

&gt;<br>
&gt; Description:<br>
&gt; Currently, the draft is silent on which crypto algorithms and certificate types must be implemented for interoperability. It should be specific before the document is finished.<br>
&gt;<br>
&gt;<br>
&gt; W<br>
&gt; _______________________________________________<br>
&gt; keyassure mailing list<br>
&gt; <a href="mailto:[email-masked]">[email-masked]</a><br>
&gt; <a href="https://www.ietf.org/mailman/listinfo/keyassure" target="_blank">https://www.ietf.org/mailman/listinfo/keyassure</a><br>
&gt;<br>
<br>
_______________________________________________<br>
keyassure mailing list<br>
<a href="mailto:[email-masked]">[email-masked]</a><br>
<a href="https://www.ietf.org/mailman/listinfo/keyassure" target="_blank">https://www.ietf.org/mailman/listinfo/keyassure</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Website: <a href="http://hallambaker.com/">http://hallambaker.com/</a><br><br>
</div></div>

--485b393ab631a158ad049d9d3ee9--

Date: Thu, 3 Mar 2011 15:26:12 -0500
From: Scott Schmit <[email-masked]>
To: [email-masked]
Mail-Followup-To: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto algorithms and certificate types are mandatory to implement"

On Thu, Mar 03, 2011 at 02:36:21PM -0500, Warren Kumari wrote keyassure:
> Hi all,
> 
> After watching the thread, I'd like to propose this as a strawman:
> 
> Mandatory to implement algorithms are SHA-256 and SHA-384. For now, these are all we specify.
> 
<snip>

Seems like a perfectly reasonable compromise to me.

-- 
Scott Schmit

From: Warren Kumari <[email-masked]>
Date: Thu, 3 Mar 2011 14:36:21 -0500
To: Warren Kumari <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto algorithms and certificate types are mandatory to implement"

Hi all,

After watching the thread, I'd like to propose this as a strawman:

Mandatory to implement algorithms are SHA-256 and SHA-384. For now, these are all we specify.

My reasoning behind this is:
1: We don't want to support too many algorithms -- it leads to complexity (which leads to weaker security) and opens the door to interoperability issues and fights over why algorithm X was allowed and Y was not.

2: Having more than 1 algorithm forces implementations to understand that there is not just one, and so should help lead towards algorithm agility

3: In order to do DANE, you have to be able to do DNSSEC -- in order to do DNSSEC you should already support the above.

4: (IMO, an important one, even if not technical one) giving people the ability to choose will lead to greater deployment. Some folk will claim that SHA-256 is too short. Some will claim that SHA-384 is excessively long and computationally expensive. Some will claim something completely random. Almost none of them will have any (rational) basis for their claims, but allowing them to use the algorithm they believe is superior will make them more likely to deploy. 

5: 2 algorithms seems like enough. While SHA1 may or may not be suitable (my (and to be completely blunt, your) views don't really matter) -- there are enough strong views on the strength / lifetime that we are likely to get bogged down / splinter over this. If we were already deployed with SHA1 this would be an important decision, but seeing as we're not, I think that avoiding fight (and living to see another day) is best.
Once again, I'm not saying that I think that SHA1 is (or isn't) fine for this, rather that, in order to get deployed, we should avoid the issue.

#4 and #5 might be pandering, but if it doesn't decrease security, and leads to sooner / more deployment it seems like a win....

Does anyone object to this (for any reasons other than "You're running away from the fight, you coward!")? 
Please speak soon, as we'd love to close this out....

<chair hat>
Please don't let this dissolve into a "algorithm X is better than Y, and Z is a pile o' rubble" discussion -- while that may be true, this is not the time or place to have it....
</chair hat>

W

On Feb 25, 2011, at 4:31 PM, Warren Kumari wrote:

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

Date: Thu, 3 Mar 2011 09:34:16 -0500
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] crypto hash alg deprecation is a myth

On Thu, Mar 03, 2011 at 08:57:04AM -0500, Phillip Hallam-Baker wrote:
> 
> One of the very few signals available that is listened to is to stop
> supporting old algorithms in new protocols.

But as I think Warren said upthread, we simply don't need to list the
protocols we don't want _at all_.  Then they're not supported from the
get go.  We don't need to talk about algorithms we don't want to
support.

The key thing, I think we all agree, is to make sure algorithm change
can happen.  This is an area where DNSSEC is still somewhat less than
perfect, for instance.

A

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

Date: Thu, 3 Mar 2011 08:57:04 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Rob Stradling <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] crypto hash alg deprecation is a myth

On another algorithm issue, certain people were waiting for CAs to
support the new algorithm before implementing them in application
software.

By support, they meant issue certificates that would break with their software.

The reason that there is concern about algorithm support in protocols
is that it takes a very very long time to get changes through the
system. It can take five years to persuade vendors to make changes and
then another ten for the old software to work through the system.

Auto update helps, but that may only prove to be a temporary change.
There are enough applications out there that do auto update very badly
that people are being taught to turn them off.

One of the very few signals available that is listened to is to stop
supporting old algorithms in new protocols.

On Thu, Mar 3, 2011 at 2:46 AM, Rob Stradling <[email-masked]> wrote:
> On Thursday 03 Mar 2011 05:09:15 Martin Rex wrote:
>> Phillip Hallam-Baker wrote:
>> > Further, even though we stopped using MD5 in the mid 90s
>>
> <snip>
>> Firefox happily verifies md5WithRsaEncryption signatures on TLS server
>> certs.
>
> Not for much longer.
>
> https://wiki.mozilla.org/CA:MD5and1024 says:
> " � �* June 30, 2011 � Mozilla will stop accepting MD5 as a hash algorithm for
> intermediate and end-entity certificates. After this date software published
> by Mozilla will return an error when a certificate with an MD5-based signature
> is used.
> � � � � �o This change is being tracked in
> https://bugzilla.mozilla.org/show_bug.cgi?id=590364"
>
> <snip>
>> MSIE 8 on Windows 7 (and prior) will happily talk to TLS servers
>> using certs signed not only with md5WithRsaSignature, but also
>> md2WithRsaSignature and even (**cough**) md4WithRsaSignature!
>
> http://technet.microsoft.com/en-us/library/cc751157.aspx#EMAA says:
> "In the event of an imminent MD5 pre-image attack
> Microsoft may update Windows to reject all MD2, MD4 or MD5 end-entity and
> subordinate CA certificates when it has reasons to believe that successful MD5
> pre-image attacks are imminent."
>
> Perhaps somebody should ask them to consider switching off MD2 and MD4 sooner
> than that.
>
> <snip>
>> (If it is possible to disable md5WithRsaEncryption signature verification
>> �in Firefox 3.5 -- then it is sufficiently well hidden that I don't
>> �see it.)
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=590364 suggests setting the
> following environment variable:
>
> NSS_HASH_ALG_SUPPORT=-MD2,-MD5
>
> <snip>
>
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online
>

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

From: Rob Stradling <[email-masked]>
To: [email-masked], [email-masked]
Date: Thu, 3 Mar 2011 07:46:52 +0000
Cc: Phillip Hallam-Baker <[email-masked]>
Subject: Re: [keyassure] crypto hash alg deprecation is a myth

On Thursday 03 Mar 2011 05:09:15 Martin Rex wrote:
> Phillip Hallam-Baker wrote:
> > Further, even though we stopped using MD5 in the mid 90s
> 
<snip>
> Firefox happily verifies md5WithRsaEncryption signatures on TLS server
> certs.

Not for much longer.

https://wiki.mozilla.org/CA:MD5and1024 says:
"    * June 30, 2011 – Mozilla will stop accepting MD5 as a hash algorithm for 
intermediate and end-entity certificates. After this date software published 
by Mozilla will return an error when a certificate with an MD5-based signature 
is used.
          o This change is being tracked in 
https://bugzilla.mozilla.org/show_bug.cgi?id=590364"

<snip>
> MSIE 8 on Windows 7 (and prior) will happily talk to TLS servers
> using certs signed not only with md5WithRsaSignature, but also
> md2WithRsaSignature and even (**cough**) md4WithRsaSignature!

http://technet.microsoft.com/en-us/library/cc751157.aspx#EMAA says:
"In the event of an imminent MD5 pre-image attack
Microsoft may update Windows to reject all MD2, MD4 or MD5 end-entity and 
subordinate CA certificates when it has reasons to believe that successful MD5 
pre-image attacks are imminent."

Perhaps somebody should ask them to consider switching off MD2 and MD4 sooner 
than that.

<snip>
> (If it is possible to disable md5WithRsaEncryption signature verification
>  in Firefox 3.5 -- then it is sufficiently well hidden that I don't
>  see it.)

https://bugzilla.mozilla.org/show_bug.cgi?id=590364 suggests setting the 
following environment variable:

NSS_HASH_ALG_SUPPORT=-MD2,-MD5

<snip>

Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

From: Martin Rex <[email-masked]>
To: [email-masked] (Phillip Hallam-Baker)
Date: Thu, 3 Mar 2011 06:09:15 +0100 (MET)
Cc: [email-masked]
Subject: [keyassure] crypto hash alg deprecation is a myth
Reply-To: [email-masked]

Phillip Hallam-Baker wrote:
> 
> Further, even though we stopped using MD5 in the mid 90s

This seems wrong for most "we" and most environments
that I can think of, certainly for the use of TLS on the internet.

The very little thing that TLSv1.0 changed at the beginning
of the new millenium is that it removed MD5 from the PRF that
derives the TLS session master-secret and traffic keys.
TLS did not affect in any way the use of MD5 for digitial signatures.

On my scorecard, neither deprecation of the MD5 hash
algorithms, nor migration away from MD5 hash algorithm
has happend so far.

Firefox happily verifies md5WithRsaEncryption signatures on TLS server
certs.  Only digital signature algorithms based on MD4 and MD2
seem to have been disabled since 3.0.something.

MSIE 8 on Windows 7 (and prior) will happily talk to TLS servers
using certs signed not only with md5WithRsaSignature, but also
md2WithRsaSignature and even (**cough**) md4WithRsaSignature!

Some may think "but Windows has a FIPS-compliant crypto algs switch".
This (carefully hidden) switch disables SSLv3, but does NOT
affect the acceptance of TLS server certificates signed with
md5withRsaEncryption, md2WithRsaEncryption or md4WithRsaEncryption.

(If it is possible to disable md5WithRsaEncryption signature verification
 in Firefox 3.5 -- then it is sufficiently well hidden that I don't
 see it.)

To me, the claim that MD5 in digital signatures was deprecated
in mid-90's is seriously defying the real world.  It may have
happened in small isolated environments, but it definitely did
not happen yet where TLS is used on the internet today.

I'm puzzled why so many commercial CAs are fiercly resisting
the deprecation of obsolete digital signature algorithms such
as md2WithRsaEncryption and md5WithRsaEncryption by continuing
to distribute TrustAnchors as self-signed X.509 certs with such
signatures on them.  Look in the cert store of your favourite
browser, or look into Microsofts TrustList distribution that
my Windows box tries polling from here:

http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab

-Martin

From: Martin Rex <[email-masked]>
To: [email-masked] (Paul Hoffman)
Date: Thu, 3 Mar 2011 05:57:04 +0100 (MET)
Cc: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto
Reply-To: [email-masked]

Paul Hoffman wrote:
> 
> Phillip Hallam-Baker wrote:
> >
> > 1) Make support for SHA2-256 and SHA2-384 REQUIRED
> > 2) Ensure that it is feasible to transition from use of SHA2
> >    to a new algorithm
> > 3) Deprecate use of MD2,MD4,MD5 and SHA1.
> 
> We disagree on #1 in that I don't think that requiring SHA-384 has any 
> practical value and adds a second code path where none is needed.
> 
> We agree only partially on #2. You keep saying "SHA2" when you probably 
> mean "SHA-256 and SHA-384". I agree that making the transition feasible 
> is good, and we already have that.
> 
> We disagree on #3, and deprecating crypto is a different issue than 
> mandating crypto.

I agree to all what Paul wrote.

Iff SHA-256 is to be a mandatory to implement hash for DANE, then
I see _no_ point in supporting SHA-1 at all (and saves us migration).

-Martin

Date: Wed, 2 Mar 2011 22:55:20 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

On Wed, Mar 2, 2011 at 7:59 PM, Paul Hoffman <[email-masked]> wrote:
> On 3/2/11 3:24 PM, Phillip Hallam-Baker wrote:
>>
>> There is currently no evidence that SHA2-256 is unacceptably weak.
>>
>> However it is based on the same construction as MD4, MD5 and SHA1. And
>> thus the reason for the current NIST competition.
>
> I believe that NIST said many times that it is *a* reason, not *the* reason.
>
>> Since the NIST competition is not currently complete, there is
>> currently no viable alternative to SHA2. While there are other
>> algorithms in use, I would expect the competition to supersede those
>> as well.
>
> It would be useful to this discussion for each of us to speak only for
> ourselves and for those who have asked us to speak for them, or to quote
> others whom we think are authorities. NIST has not, I believe, said that the
> results of the competition will supersede SHA-2; if I'm wrong, please send
> full quotes.

Pot, kettle black.

I would really prefer it if you Paul would not take it upon yourself
to chair this particular working group because (1) you are not the
chair and (2) your contributions appear to me to be a constant stream
of personal attacks.

When I say "I would expect the competition to supersede those as
well." the group should assume that I am speaking for myself and that
I have in fact consulted myself on the topic in question.

As it happens I was probably the first person to suggest a digest
competition to NIST since I met with Bill Burr less than an hour after
the weakness in the SHA-1 construction was announced by Adi Shamir. I
had previously had discussions with Burt Kaliski, Rivest and others in
the field.

By the end of the show it was clear that there would be a digest
algorithm competition, the only question was whether it would be
sponsored by NIST or another party. I probably wasn't the only person
who had authorization to offer to underwrite a competition.

So on this particular topic, as with many others, your sniping and
carping is completely off base. I was there and you were not.

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

Date: Wed, 02 Mar 2011 16:59:13 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

On 3/2/11 3:24 PM, Phillip Hallam-Baker wrote:
> There is currently no evidence that SHA2-256 is unacceptably weak.
>
> However it is based on the same construction as MD4, MD5 and SHA1. And
> thus the reason for the current NIST competition.

I believe that NIST said many times that it is *a* reason, not *the* reason.

> Since the NIST competition is not currently complete, there is
> currently no viable alternative to SHA2. While there are other
> algorithms in use, I would expect the competition to supersede those
> as well.

It would be useful to this discussion for each of us to speak only for 
ourselves and for those who have asked us to speak for them, or to quote 
others whom we think are authorities. NIST has not, I believe, said that 
the results of the competition will supersede SHA-2; if I'm wrong, 
please send full quotes.

> I think that what we should do here is
>
> 1) Make support for SHA2-256 and SHA2-384 REQUIRED
> 2) Ensure that it is feasible to transition from use of SHA2 to a new algorithm
> 3) Deprecate use of MD2,MD4,MD5 and SHA1.
>
>
> The second point is really rather important since even though it is
> possible to emit bit strings that use SHA2 in protocols such as SSL
> and S/MIME, it is not feasible to use them in practice because there
> is no way to know whether the other party is one of those which is
> capable of using them.

We disagree on #1 in that I don't think that requiring SHA-384 has any 
practical value and adds a second code path where none is needed.

We agree only partially on #2. You keep saying "SHA2" when you probably 
mean "SHA-256 and SHA-384". I agree that making the transition feasible 
is good, and we already have that.

We disagree on #3, and deprecating crypto is a different issue than 
mandating crypto.

--Paul Hoffman

Date: Wed, 02 Mar 2011 19:50:31 -0500
From: Sean Turner <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

On 3/2/11 6:43 PM, Warren Kumari wrote:
>
> On Mar 2, 2011, at 6:24 PM, Phillip Hallam-Baker wrote:
>
>> There is currently no evidence that SHA2-256 is unacceptably weak.
>>
>> However it is based on the same construction as MD4, MD5 and SHA1. And
>> thus the reason for the current NIST competition.
>>
>>
>> Since the NIST competition is not currently complete, there is
>> currently no viable alternative to SHA2. While there are other
>> algorithms in use, I would expect the competition to supersede those
>> as well.
>>
>> I think that what we should do here is
>>
>> 1) Make support for SHA2-256 and SHA2-384 REQUIRED
>> 2) Ensure that it is feasible to transition from use of SHA2 to a new
>> algorithm
>
> <no hats>
> Shouldn't this be much much more general? "Ensure that it is feasible to
> transition to new algorithms"? <note: I don't know how we do this, but I
> also don't see why "from SHA2" would be a special case>
>
>> 3) Deprecate use of MD2,MD4,MD5 and SHA1.
>>
>
> Um, I'm confused by number 3 -- I think that the only things we need to
> do *here* is decide what we *do* support....
> Deprecating the use of other things, while fine and good, doesn't need
> to happen *here* if we don't support them...
>
> W
> </no hats>

#3 is kind of taken care of.  MD2 and MD4 are being made historic:

http://datatracker.ietf.org/doc/draft-turner-md2-to-historic/
http://datatracker.ietf.org/doc/draft-turner-md4-to-historic/

and the security considerations for MD5 were updated:

http://datatracker.ietf.org/doc/draft-turner-md5-seccon-update/

spt

>>
>> The second point is really rather important since even though it is
>> possible to emit bit strings that use SHA2 in protocols such as SSL
>> and S/MIME, it is not feasible to use them in practice because there
>> is no way to know whether the other party is one of those which is
>> capable of using them.
>>
>> On Tue, Mar 1, 2011 at 5:38 PM, Paul Hoffman <[email-masked]>
>> wrote:
>>> On 3/1/11 1:37 PM, Phillip Hallam-Baker wrote:
>>>>
>>>> This particular topic is one on which the Security ADs and the IETF
>>>> chair have very very specific opinions on. And given their role in
>>>> trying to effect an industry wide transition to stronger algorithms, I
>>>> think that they are quite right to insist on them.
>>>
>>> If you can quote previous statements from any of them suggesting that
>>> SHA-256 is suspect, that would be more useful than you simply suggesting
>>> that they had said something. It would be useful to this discussion
>>> for each
>>> of us to speak only for ourselves and for those who have asked us to
>>> speak
>>> for them, or to quote others whom we think are authorities.
>>> _______________________________________________
>>> keyassure mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/keyassure
>>>
>>
>>
>>
>> --
>> Website: http://hallambaker.com/
>> _______________________________________________
>> keyassure mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/keyassure
>>
>
> --
> We know about as much about software quality problems as they knew about
> the Black Plague in the 1600s. We've seen the victims' agonies and
> helped burn the corpses. We don't know what causes it; we don't really
> know if there is only one disease. We just suffer -- and keep pouring
> our sewage into our water supply.
>
> -- Tom Van Vleck
>
>
>
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

From: Warren Kumari <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 2 Mar 2011 18:43:54 -0500
Cc: [email-masked], Paul Hoffman <[email-masked]>
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

On Mar 2, 2011, at 6:24 PM, Phillip Hallam-Baker wrote:

> There is currently no evidence that SHA2-256 is unacceptably weak.
>
> However it is based on the same construction as MD4, MD5 and SHA1. And
> thus the reason for the current NIST competition.
>
>
> Since the NIST competition is not currently complete, there is
> currently no viable alternative to SHA2. While there are other
> algorithms in use, I would expect the competition to supersede those
> as well.
>
> I think that what we should do here is
>
> 1) Make support for SHA2-256 and SHA2-384 REQUIRED
> 2) Ensure that it is feasible to transition from use of SHA2 to a  
> new algorithm

<no hats>
Shouldn't this be much much more general? "Ensure that it is feasible  
to transition to new algorithms"? <note: I don't know how we do this,  
but I also don't see why "from SHA2" would be a special case>

> 3) Deprecate use of MD2,MD4,MD5 and SHA1.
>

Um, I'm confused by number 3 -- I think that the only things we need  
to do *here* is decide what we *do* support....
Deprecating the use of other things, while fine and good, doesn't need  
to happen *here* if we don't support them...

W
</no hats>

>
> The second point is really rather important since even though it is
> possible to emit bit strings that use SHA2 in protocols such as SSL
> and S/MIME, it is not feasible to use them in practice because there
> is no way to know whether the other party is one of those which is
> capable of using them.
>
> On Tue, Mar 1, 2011 at 5:38 PM, Paul Hoffman <[email-masked]>  
> wrote:
>> On 3/1/11 1:37 PM, Phillip Hallam-Baker wrote:
>>>
>>> This particular topic is one on which the Security ADs and the IETF
>>> chair have very very specific opinions on. And given their role in
>>> trying to effect an industry wide transition to stronger  
>>> algorithms, I
>>> think that they are quite right to insist on them.
>>
>> If you can quote previous statements from any of them suggesting that
>> SHA-256 is suspect, that would be more useful than you simply  
>> suggesting
>> that they had said something. It would be useful to this discussion  
>> for each
>> of us to speak only for ourselves and for those who have asked us  
>> to speak
>> for them, or to quote others whom we think are authorities.
>> _______________________________________________
>> keyassure mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/keyassure
>>
>
>
>
> -- 
> Website: http://hallambaker.com/
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

--
We know about as much about software quality problems as they knew  
about the Black Plague in the 1600s. We've seen the victims' agonies  
and helped burn the corpses. We don't know what causes it; we don't  
really know if there is only one disease. We just suffer -- and keep  
pouring our sewage into our water supply.

-- Tom Van Vleck

Date: Wed, 2 Mar 2011 18:24:43 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Paul Hoffman <[email-masked]>
Cc: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

There is currently no evidence that SHA2-256 is unacceptably weak.

However it is based on the same construction as MD4, MD5 and SHA1. And
thus the reason for the current NIST competition.

Since the NIST competition is not currently complete, there is
currently no viable alternative to SHA2. While there are other
algorithms in use, I would expect the competition to supersede those
as well.

I think that what we should do here is

1) Make support for SHA2-256 and SHA2-384 REQUIRED
2) Ensure that it is feasible to transition from use of SHA2 to a new algorithm
3) Deprecate use of MD2,MD4,MD5 and SHA1.

The second point is really rather important since even though it is
possible to emit bit strings that use SHA2 in protocols such as SSL
and S/MIME, it is not feasible to use them in practice because there
is no way to know whether the other party is one of those which is
capable of using them.

On Tue, Mar 1, 2011 at 5:38 PM, Paul Hoffman <[email-masked]> wrote:
> On 3/1/11 1:37 PM, Phillip Hallam-Baker wrote:
>>
>> This particular topic is one on which the Security ADs and the IETF
>> chair have very very specific opinions on. And given their role in
>> trying to effect an industry wide transition to stronger algorithms, I
>> think that they are quite right to insist on them.
>
> If you can quote previous statements from any of them suggesting that
> SHA-256 is suspect, that would be more useful than you simply suggesting
> that they had said something. It would be useful to this discussion for each
> of us to speak only for ourselves and for those who have asked us to speak
> for them, or to quote others whom we think are authorities.
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

Date: Wed, 02 Mar 2011 23:17:09 +0000
From: Stephen Farrell <[email-masked]>
To: Phillip Hallam-Baker <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

I think this is a good enough statement of the situation as I
understand it.

Thanks,
S.

On 02/03/11 23:09, Phillip Hallam-Baker wrote:
> What I meant to write was that SHA1 is only marginally more secure
> than MD5 was when we decided to stop using it. Obviously with 32 extra
> bits it is harder to break.
> 
> 
> If you look at the internals of SHA1-0, the original proposal, you
> will find that it is in effect simply MD5 with an additional set of
> state variables to extend the size to 160 bits.
> 
> The spec was amended to add in an additional expansion function before
> it was approved. In a private conversation in 1995 at the time the
> Dobbertin attack was first circulated, Rivest was of the opinion that
> this would make it somewhat more resistant to the Dobbertin attack but
> not considerably so.
> 
> 
> While the attacks on SHA1 are currently theoretical, they are rapidly
> approaching the point at which we started to decide that use of MD5
> should be avoided.
> 
> Further, even though we stopped using MD5 in the mid 90s, it is still
> possible to use MD5 securely but doing so requires considerable
> attention to other security precautions. So even if there is a
> theoretical break of SHA1 we are hardly in a situation where we will
> face an immediate crisis.
> 
> If SHA1 is 'broken' tomorrow it is likely going to be 2020 before
> there is a practical exploit based on that attack. But that is not
> reason for complacency as it is likely to take us a decade to dig our
> way out of using SHA1.
> 
> 
> On Wed, Mar 2, 2011 at 4:37 PM, Stephen Farrell
> <[email-masked]> wrote:
>>
>>
>> On 2 Mar 2011, at 21:24, Phillip Hallam-Baker <[email-masked]> wrote:
>>
>>> Which is why I am arguing it is time to withdraw SHA1 from service. It
>>> is only marginally more secure than MD5.
>>
>> "Marginally"? Evidence please? I dont think exageration helps your case.
>>
>> S
>>
>>
>>>
>>>
>>>
>>> On Wed, Mar 2, 2011 at 12:24 PM, Martin Rex <[email-masked]> wrote:
>>>> Phillip Hallam-Baker wrote:
>>>>>
>>>>> The use of MD2 in a self signed cert has little risk as far as use of
>>>>> the cert itself goes since it only serves as proof of possession which
>>>>> is only relevant when the browser provider chooses to install it in
>>>>> the browser.
>>>>
>>>> In the universe where I live, there exist collision attacks against MD2.
>>>>  (check http://en.wikipedia.org/wiki/MD2_%28cryptography%29)
>>>>
>>>> So an RSA-key for which a PKCS#1 encrypted MD2 signature has been
>>>> published is a real security problem and ought to have been discarded
>>>> long ago.
>>>>
>>>> Else someone could try to use the preimage attack to issue himself
>>>> an intermediate CA cert under such a root cert, reusing the md2-based
>>>> signature on the RootCA cert.
>>>>
>>>> I would REALLY like to kill md2withRsaEncryption as a digital
>>>> signature algorithm from our PKI implementation, like I did
>>>> with all of md4-based digital signature algorithms.
>>>>
>>>>
>>>> Getting rid of "tainted" RSA keys is also important.
>>>>
>>>> Why do you think that FIPS 186-3 says that you are not allowed
>>>> to use an RSA keypair for both PKCS-v1.5 and PKCS-PSS signatures?
>>>> Because you "taint" your RSA key on the first time that you use it
>>>> for a weak scheme.
>>>>
>>>> -Martin
>>>>
>>>
>>>
>>>
>>> --
>>> Website: http://hallambaker.com/
>>> _______________________________________________
>>> keyassure mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/keyassure
>>
> 
> 
> 

Date: Wed, 2 Mar 2011 18:09:11 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

What I meant to write was that SHA1 is only marginally more secure
than MD5 was when we decided to stop using it. Obviously with 32 extra
bits it is harder to break.

If you look at the internals of SHA1-0, the original proposal, you
will find that it is in effect simply MD5 with an additional set of
state variables to extend the size to 160 bits.

The spec was amended to add in an additional expansion function before
it was approved. In a private conversation in 1995 at the time the
Dobbertin attack was first circulated, Rivest was of the opinion that
this would make it somewhat more resistant to the Dobbertin attack but
not considerably so.

While the attacks on SHA1 are currently theoretical, they are rapidly
approaching the point at which we started to decide that use of MD5
should be avoided.

Further, even though we stopped using MD5 in the mid 90s, it is still
possible to use MD5 securely but doing so requires considerable
attention to other security precautions. So even if there is a
theoretical break of SHA1 we are hardly in a situation where we will
face an immediate crisis.

If SHA1 is 'broken' tomorrow it is likely going to be 2020 before
there is a practical exploit based on that attack. But that is not
reason for complacency as it is likely to take us a decade to dig our
way out of using SHA1.

On Wed, Mar 2, 2011 at 4:37 PM, Stephen Farrell
<[email-masked]> wrote:
>
>
> On 2 Mar 2011, at 21:24, Phillip Hallam-Baker <[email-masked]> wrote:
>
>> Which is why I am arguing it is time to withdraw SHA1 from service. It
>> is only marginally more secure than MD5.
>
> "Marginally"? Evidence please? I dont think exageration helps your case.
>
> S
>
>
>>
>>
>>
>> On Wed, Mar 2, 2011 at 12:24 PM, Martin Rex <[email-masked]> wrote:
>>> Phillip Hallam-Baker wrote:
>>>>
>>>> The use of MD2 in a self signed cert has little risk as far as use of
>>>> the cert itself goes since it only serves as proof of possession which
>>>> is only relevant when the browser provider chooses to install it in
>>>> the browser.
>>>
>>> In the universe where I live, there exist collision attacks against MD2.
>>> �(check http://en.wikipedia.org/wiki/MD2_%28cryptography%29)
>>>
>>> So an RSA-key for which a PKCS#1 encrypted MD2 signature has been
>>> published is a real security problem and ought to have been discarded
>>> long ago.
>>>
>>> Else someone could try to use the preimage attack to issue himself
>>> an intermediate CA cert under such a root cert, reusing the md2-based
>>> signature on the RootCA cert.
>>>
>>> I would REALLY like to kill md2withRsaEncryption as a digital
>>> signature algorithm from our PKI implementation, like I did
>>> with all of md4-based digital signature algorithms.
>>>
>>>
>>> Getting rid of "tainted" RSA keys is also important.
>>>
>>> Why do you think that FIPS 186-3 says that you are not allowed
>>> to use an RSA keypair for both PKCS-v1.5 and PKCS-PSS signatures?
>>> Because you "taint" your RSA key on the first time that you use it
>>> for a weak scheme.
>>>
>>> -Martin
>>>
>>
>>
>>
>> --
>> Website: http://hallambaker.com/
>> _______________________________________________
>> keyassure mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/keyassure
>

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

Date: Wed, 02 Mar 2011 23:03:10 +0000
From: Stephen Farrell <[email-masked]>
To: Nicholas Weaver <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Phillip Hallam-Baker <[email-masked]>
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

On 02/03/11 22:47, Nicholas Weaver wrote:
> I'll take Ron Rivest's word on it: http://mail.python.org/pipermail/python-dev/2005-December/058850.html

Note the date on that is 2005. We've been moving away from sha-1
since then and continue to do so as we should. Overstating the
situation is not a good way to make progress in that.

S.

Date: Tue, 01 Mar 2011 14:38:09 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

On 3/1/11 1:37 PM, Phillip Hallam-Baker wrote:
> This particular topic is one on which the Security ADs and the IETF
> chair have very very specific opinions on. And given their role in
> trying to effect an industry wide transition to stronger algorithms, I
> think that they are quite right to insist on them.

If you can quote previous statements from any of them suggesting that 
SHA-256 is suspect, that would be more useful than you simply suggesting 
that they had said something. It would be useful to this discussion for 
each of us to speak only for ourselves and for those who have asked us 
to speak for them, or to quote others whom we think are authorities.

From: Nicholas Weaver <[email-masked]>
Date: Wed, 2 Mar 2011 14:47:22 -0800
To: Stephen Farrell <[email-masked]>
Cc: Phillip Hallam-Baker <[email-masked]>, Nicholas Weaver <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

On Mar 2, 2011, at 2:35 PM, Stephen Farrell wrote:

> 
> 
> On 2 Mar 2011, at 21:41, Nicholas Weaver <[email-masked]> wrote:
> 
>> 
>> On Mar 2, 2011, at 1:37 PM, Stephen Farrell wrote:
>> 
>>> 
>>> 
>>> On 2 Mar 2011, at 21:24, Phillip Hallam-Baker <[email-masked]> wrote:
>>> 
>>>> Which is why I am arguing it is time to withdraw SHA1 from service. It
>>>> is only marginally more secure than MD5.
>>> 
>>> "Marginally"? Evidence please? I dont think exageration helps your case.
>>> 
>>> S
>> 
>> http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html
> 
> Yes, sha2 is the hash algorithm of the day. 
> 
> But where's it say there's only a marginal difference between sha1 and md5? Absent evidence that's just spreading FUD which is not a good way to argue, even for the right thing.

I'll take Ron Rivest's word on it: http://mail.python.org/pipermail/python-dev/2005-December/058850.html

> I'm curious as to the status of upgrading cryptographic
> hash function support in Python, now that md5 and sha1 are
> both clearly broken (in terms of collision-resistance).

If he puts the two in the same category of broken, I'd trust that judgement.

Date: Wed, 02 Mar 2011 13:42:06 -0800
From: Paul Hoffman <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

On 3/2/11 1:24 PM, Phillip Hallam-Baker wrote:

> Which is why I am arguing it is time to withdraw SHA1 from service. It
> is only marginally more secure than MD5.

The wording for Issue #21 is:

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

It sounds like you want to open a different issue that deals with which 
crypto algorithms MUST NOT be supported. Does that sound correct?

--Paul Hoffman

z3t uBsoBZdImxi0EemaL6IB/qVbniXreK82W2c3zQ=; bqyi47yo08NT94TxrLpf GMYNY3px4VxPCyuPEFyTGj5VjuwQNIVI++SgH9syuGJad0/KJ073MfWb+397h0mj Q8LbQDAUznyaSe0+AtxT0CJ76pdUM7nBDMF2b6j2ieeCRCpZwJjMiyZzc8xlJCrt EmFeOyu5rA21iGxoJAP32HImdPRDIJESzo0DxYTfJFKHTEnZe451lQF9vqORfUrW tUOmC4e3xqxVBeI8eO+0c0ci/efAlLjzDPFXDCGCvwRRGUBVqpnq2JlPVgV2Y7Oo qjkbBx7A+dE4TD598QvBE3i/QM8OfzVDxHckUQD2p3oskaTLNRvpBMNjdp0shoJ6 g=
From: Stephen Farrell <[email-masked]>
Date: Wed, 2 Mar 2011 22:35:49 +0000
To: Nicholas Weaver <[email-masked]>
Cc: Phillip Hallam-Baker <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

On 2 Mar 2011, at 21:41, Nicholas Weaver <[email-masked]> wrote:

> 
> On Mar 2, 2011, at 1:37 PM, Stephen Farrell wrote:
> 
>> 
>> 
>> On 2 Mar 2011, at 21:24, Phillip Hallam-Baker <[email-masked]> wrote:
>> 
>>> Which is why I am arguing it is time to withdraw SHA1 from service. It
>>> is only marginally more secure than MD5.
>> 
>> "Marginally"? Evidence please? I dont think exageration helps your case.
>> 
>> S
> 
> http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html

Yes, sha2 is the hash algorithm of the day. 

But where's it say there's only a marginal difference between sha1 and md5? Absent evidence that's just spreading FUD which is not a good way to argue, even for the right thing.

S

> 
>> March 15, 2006: The SHA-2 family of hash functions (i.e., SHA-224, SHA-256, SHA-384 and SHA-512) may be used by Federal agencies for all applications using secure hash algorithms. Federal agencies should stop using SHA-1 for digital signatures, digital time stamping and other applications that require collision resistance as soon as practical, and must use the SHA-2 family of hash functions for these applications after 2010. After 2010, Federal agencies may use SHA-1 only for the following applications: hash-based message authentication codes (HMACs); key derivation functions (KDFs); and random number generators (RNGs). Regardless of use, NIST encourages application and protocol designers to use the SHA-2 family of hash functions for all new applications and protocols.
> 
> I agree with depricating SHA-1 in DANE.
> 

Date: Wed, 02 Mar 2011 13:56:16 -0800
From: Chris Palmer <[email-masked]>
To: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

On 03/02/2011 01:41 PM, Nicholas Weaver wrote:

> I agree with depricating SHA-1 in DANE.

Indeed, I can hardly understand why we're arguing about it. SHA-1 is
over and has no place in new protocols.

-- 
Chris Palmer
Technology Director, Electronic Frontier Foundation

From: Nicholas Weaver <[email-masked]>
Date: Wed, 2 Mar 2011 13:41:04 -0800
To: Stephen Farrell <[email-masked]>
Cc: Phillip Hallam-Baker <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

On Mar 2, 2011, at 1:37 PM, Stephen Farrell wrote:

> 
> 
> On 2 Mar 2011, at 21:24, Phillip Hallam-Baker <[email-masked]> wrote:
> 
>> Which is why I am arguing it is time to withdraw SHA1 from service. It
>> is only marginally more secure than MD5.
> 
> "Marginally"? Evidence please? I dont think exageration helps your case.
> 
> S

http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html

> March 15, 2006: The SHA-2 family of hash functions (i.e., SHA-224, SHA-256, SHA-384 and SHA-512) may be used by Federal agencies for all applications using secure hash algorithms. Federal agencies should stop using SHA-1 for digital signatures, digital time stamping and other applications that require collision resistance as soon as practical, and must use the SHA-2 family of hash functions for these applications after 2010. After 2010, Federal agencies may use SHA-1 only for the following applications: hash-based message authentication codes (HMACs); key derivation functions (KDFs); and random number generators (RNGs). Regardless of use, NIST encourages application and protocol designers to use the SHA-2 family of hash functions for all new applications and protocols.

I agree with depricating SHA-1 in DANE.

From: Stephen Farrell <[email-masked]>
Date: Wed, 2 Mar 2011 21:37:09 +0000
To: Phillip Hallam-Baker <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

On 2 Mar 2011, at 21:24, Phillip Hallam-Baker <[email-masked]> wrote:

> Which is why I am arguing it is time to withdraw SHA1 from service. It
> is only marginally more secure than MD5.

"Marginally"? Evidence please? I dont think exageration helps your case.

S

> 
> 
> 
> On Wed, Mar 2, 2011 at 12:24 PM, Martin Rex <[email-masked]> wrote:
>> Phillip Hallam-Baker wrote:
>>> 
>>> The use of MD2 in a self signed cert has little risk as far as use of
>>> the cert itself goes since it only serves as proof of possession which
>>> is only relevant when the browser provider chooses to install it in
>>> the browser.
>> 
>> In the universe where I live, there exist collision attacks against MD2.
>>  (check http://en.wikipedia.org/wiki/MD2_%28cryptography%29)
>> 
>> So an RSA-key for which a PKCS#1 encrypted MD2 signature has been
>> published is a real security problem and ought to have been discarded
>> long ago.
>> 
>> Else someone could try to use the preimage attack to issue himself
>> an intermediate CA cert under such a root cert, reusing the md2-based
>> signature on the RootCA cert.
>> 
>> I would REALLY like to kill md2withRsaEncryption as a digital
>> signature algorithm from our PKI implementation, like I did
>> with all of md4-based digital signature algorithms.
>> 
>> 
>> Getting rid of "tainted" RSA keys is also important.
>> 
>> Why do you think that FIPS 186-3 says that you are not allowed
>> to use an RSA keypair for both PKCS-v1.5 and PKCS-PSS signatures?
>> Because you "taint" your RSA key on the first time that you use it
>> for a weak scheme.
>> 
>> -Martin
>> 
> 
> 
> 
> -- 
> Website: http://hallambaker.com/
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Date: Wed, 2 Mar 2011 16:24:40 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

I was aware of that attack.

That is not a problem with the use of MD2 in a self-signed certificate.

That is a problem of having used MD2.

The problem there is that if you have a key that has been used to sign
with MD2 it is going to be permanently tainted regardless of what
place the cert is in the chain and regardless of what type of cert it
is. The attacker can 'correct' for any defect wrt cert type, validity
interval etc.

There is only one effective defense against that attack and that is to
withdraw the MD2 algorithm from service.

You don't get any additional security from adding additional stronger
algorithms to the support list. You only get additional security from
withdrawing a weak algorithm from service.

Which is why I am arguing it is time to withdraw SHA1 from service. It
is only marginally more secure than MD5.

On Wed, Mar 2, 2011 at 12:24 PM, Martin Rex <[email-masked]> wrote:
> Phillip Hallam-Baker wrote:
>>
>> The use of MD2 in a self signed cert has little risk as far as use of
>> the cert itself goes since it only serves as proof of possession which
>> is only relevant when the browser provider chooses to install it in
>> the browser.
>
> In the universe where I live, there exist collision attacks against MD2.
> �(check http://en.wikipedia.org/wiki/MD2_%28cryptography%29)
>
> So an RSA-key for which a PKCS#1 encrypted MD2 signature has been
> published is a real security problem and ought to have been discarded
> long ago.
>
> Else someone could try to use the preimage attack to issue himself
> an intermediate CA cert under such a root cert, reusing the md2-based
> signature on the RootCA cert.
>
> I would REALLY like to kill md2withRsaEncryption as a digital
> signature algorithm from our PKI implementation, like I did
> with all of md4-based digital signature algorithms.
>
>
> Getting rid of "tainted" RSA keys is also important.
>
> Why do you think that FIPS 186-3 says that you are not allowed
> to use an RSA keypair for both PKCS-v1.5 and PKCS-PSS signatures?
> Because you "taint" your RSA key on the first time that you use it
> for a weak scheme.
>
> -Martin
>

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

From: Martin Rex <[email-masked]>
To: [email-masked] (Phillip Hallam-Baker)
Date: Wed, 2 Mar 2011 18:24:55 +0100 (MET)
Cc: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto
Reply-To: [email-masked]

Phillip Hallam-Baker wrote:
> 
> The use of MD2 in a self signed cert has little risk as far as use of
> the cert itself goes since it only serves as proof of possession which
> is only relevant when the browser provider chooses to install it in
> the browser.

In the universe where I live, there exist collision attacks against MD2.
 (check http://en.wikipedia.org/wiki/MD2_%28cryptography%29)

So an RSA-key for which a PKCS#1 encrypted MD2 signature has been
published is a real security problem and ought to have been discarded
long ago.

Else someone could try to use the preimage attack to issue himself
an intermediate CA cert under such a root cert, reusing the md2-based
signature on the RootCA cert.

I would REALLY like to kill md2withRsaEncryption as a digital
signature algorithm from our PKI implementation, like I did
with all of md4-based digital signature algorithms.

Getting rid of "tainted" RSA keys is also important.

Why do you think that FIPS 186-3 says that you are not allowed
to use an RSA keypair for both PKCS-v1.5 and PKCS-PSS signatures?
Because you "taint" your RSA key on the first time that you use it
for a weak scheme.

-Martin

Date: Wed, 2 Mar 2011 12:04:56 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

The use of MD2 in a self signed cert has little risk as far as use of
the cert itself goes since it only serves as proof of possession which
is only relevant when the browser provider chooses to install it in
the browser.

Under windows the cert is actually authenticated under the CTL
structure which uses SHA1 at the least.

There are certainly issues with MD2, but that is not one of them.

Argument by analogy is a really bad way to conduct a security review.
We are not at all happy with the situation with respect to digets
algorithms. Moving away from SHA1 is going to be a huge problem for
the industry.

If anyone here thinks that DANE is going to be allowed to add to that
problem, well they need learning otherwise.

Choice of the crypto alg is meant to be the easy part of the problem.

On Wed, Mar 2, 2011 at 10:29 AM, Martin Rex <[email-masked]> wrote:
> Martin Rex wrote:
>>
>> And there are still a number of TrustAnchors in every Browser that
>> carry an md5WithRsaEncryption signature.
>>
>> But it's actually worse than that -- VeriSign still has a CA cert
>> in service with an md2WithRsaEncryption -- and is still using it
>> productively (check https://www.hp.com/).
>
> I'm terribly sorry, I mixed up the (by now long) list of VeriSign
> RootCA certs.
>
> The RootCA cert under which the server cert for https://www.hp.com
> is "VeriSign Class 3 Public Primary Certification Authority - G2"
> and uses sha1WithRsaEncryption. �But it still is an X.509v1 cert.
>
> My Firefox 3.5.13 comes with these three VeriSign RooCA certs
> that are X.509v1, use md2WithRsaSignature and valid until 02-Aug-2028:
>
> � "VeriSign Class 1 Public Primary Certification Authority"
> � "VeriSign Class 2 Public Primary Certification Authority"
> � "VeriSign Class 3 Public Primary Certification Authority"
>
>
> -Martin
>

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

From: Martin Rex <[email-masked]>
To: [email-masked]
Date: Wed, 2 Mar 2011 16:29:15 +0100 (MET)
Cc: [email-masked], [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto
Reply-To: [email-masked]

Martin Rex wrote:
> 
> And there are still a number of TrustAnchors in every Browser that
> carry an md5WithRsaEncryption signature.
> 
> But it's actually worse than that -- VeriSign still has a CA cert
> in service with an md2WithRsaEncryption -- and is still using it
> productively (check https://www.hp.com/).

I'm terribly sorry, I mixed up the (by now long) list of VeriSign
RootCA certs.

The RootCA cert under which the server cert for https://www.hp.com
is "VeriSign Class 3 Public Primary Certification Authority - G2"
and uses sha1WithRsaEncryption.  But it still is an X.509v1 cert.

My Firefox 3.5.13 comes with these three VeriSign RooCA certs
that are X.509v1, use md2WithRsaSignature and valid until 02-Aug-2028:

   "VeriSign Class 1 Public Primary Certification Authority"
   "VeriSign Class 2 Public Primary Certification Authority"
   "VeriSign Class 3 Public Primary Certification Authority"

-Martin

From: Martin Rex <[email-masked]>
To: [email-masked] (Phillip Hallam-Baker)
Date: Wed, 2 Mar 2011 02:50:58 +0100 (MET)
Cc: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto
Reply-To: [email-masked]

Phillip Hallam-Baker wrote:
> 
> Plenty is not the point.
> 
> SHA1 is no longer regarded as acceptably secure. SHA2 is based on the
> same construction and is thus similarly suspect.
> 
> We don't use SHA1 in legacy browsers because we like it. We use SHA1
> in legacy browsers because we have not worked out how to transition
> away from it. The transition from MD5 to SHA1 was painless only
> because all browsers were required to support both standards.

Transition from MD5 to SHA1?  I seem to have missed that entirely.

MD5 was removed from the PRF in the SSLv3->TLSv1.0 protocol revision,
but even TLSv1.1 uses a combination of MD5+SHA1 for digital signatures.

And there are still a number of TrustAnchors in every Browser that
carry an md5WithRsaEncryption signature.

But it's actually worse than that -- VeriSign still has a CA cert
in service with an md2WithRsaEncryption -- and is still using it
productively (check https://www.hp.com/).

Considering the transition SHA-1 --> SHA-256.  That was goofed
in TLSv1.2, by defining the default hash algorithm for the digital
signature structs to default to SHA-1 (only) -- which is actually
weaker than SSLv3/TLSv1.0/TLSv1.1 ...

> 
> This particular topic is one on which the Security ADs and the IETF
> chair have very very specific opinions on. And given their role in
> trying to effect an industry wide transition to stronger algorithms, I
> think that they are quite right to insist on them.

DANEs security is vitally dependent on DNSSEC, and for DNSSEC, SHA-1
seems to be the mandatory-to-implement algorithm for signatures.

Inuitively, why don't we tie DANE's hash algorithm to DNSSECs algorithm?

Making DANE an early adopter of SHA-3 while DNSSEC still uses SHA-1
amounts to silicon snake oil -- i.e. needless complexity.

-Martin

From: Warren Kumari <[email-masked]>
To: Warren Kumari <[email-masked]>
Date: Tue, 1 Mar 2011 18:47:54 -0500
Cc: [email-masked]
Subject: Re: [keyassure] Meeting in Prague.

On Feb 25, 2011, at 12:15 PM, Warren Kumari wrote:

> Hello all.
>
> We have been granted a meeting slot in Prague.
>
> If anyone wants agenda time to discuss things *in our charter*, let  
> the chairs know well ahead of time so that we can schedule you.

A gentle reminder -- please give us as much notice as possible...

W
> TLS is also scheduled to meet -- if what you want to discuss  
> involves changes to TLS (like bare keys), please take it to TLS....
>
> Also, if you want  to suggest something like TLSA for a non-TLS  
> protocol that doesn't already have keys, that is fine too, *as long  
> as you have a published draft before the meeting*.
>
> Cutoff date for -00 submissions:
> 2011-03-07 (Monday): Internet Draft Cut-off for initial document  
> (-00) submission by 17:00 PT (01:00 Tuesday, March 8 UTC), upload  
> using IETF ID Submission Tool.
>
> Thank you and hope to see you in Prague!
> W
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

For every complex problem, there is a solution that is simple, neat,  
and wrong.
                 -- H. L. Mencken

Date: Tue, 1 Mar 2011 16:37:27 -0500
From: Phillip Hallam-Baker <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto

Plenty is not the point.

SHA1 is no longer regarded as acceptably secure. SHA2 is based on the
same construction and is thus similarly suspect.

We don't use SHA1 in legacy browsers because we like it. We use SHA1
in legacy browsers because we have not worked out how to transition
away from it. The transition from MD5 to SHA1 was painless only
because all browsers were required to support both standards.

This particular topic is one on which the Security ADs and the IETF
chair have very very specific opinions on. And given their role in
trying to effect an industry wide transition to stronger algorithms, I
think that they are quite right to insist on them.

On Tue, Mar 1, 2011 at 1:15 PM, Martin Rex <[email-masked]> wrote:
> Phillip Hallam-Baker wrote:
>>
>> Currently, the only digest algorithm that can be recommended is SHA-2
>>
>> We really do need SHA2 in here as a MUST, unless we are still discussing
>> this when the SHA3 competition results are out.
>
> SHA-256 looks like plenty.
>
> You do realize, that many (if not most) implementations of TLS are going
> to use SHA-1 for digital signatures for quite some time to come?
>
> And even document like the updated TLS extensions document (rfc6066)
> use SHA-1 all over the place.
>
> -Martin
>

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

From: Martin Rex <[email-masked]>
To: [email-masked] (Phillip Hallam-Baker)
Date: Tue, 1 Mar 2011 19:15:56 +0100 (MET)
Cc: [email-masked]
Subject: Re: [keyassure] Opening issue #21: "Need to specify which crypto
Reply-To: [email-masked]

Phillip Hallam-Baker wrote:
> 
> Currently, the only digest algorithm that can be recommended is SHA-2
> 
> We really do need SHA2 in here as a MUST, unless we are still discussing
> this when the SHA3 competition results are out.

SHA-256 looks like plenty.

You do realize, that many (if not most) implementations of TLS are going
to use SHA-1 for digital signatures for quite some time to come?

And even document like the updated TLS extensions document (rfc6066)
use SHA-1 all over the place.

-Martin