Subject: [dane] Starting WGLC for draft-ietf-dane-protocol-16.

From: Warren Kumari <[email-masked]>
Date: Wed, 8 Feb 2012 12:28:02 -0800

Hello WG,

Firstly I would like to remind the Working Group about the IETF IRP rules, and once again draw the WG's attention to the IETF Note Well ( http://www.ietf.org/about/note-well.html ) and RFC 5378 and RFC 3979 (updated by RFC 4879). I understand that most of the participants in this WG are long-time participants, and are already very familiar with the IRP rules, but please take a moment again to consider if there is anything that you need to / should have disclosed.

Phew.

We are kicking off WGLC for the protocol doc -- draft-ietf-dane-protocol ( http://tools.ietf.org/html/draft-ietf-dane-protocol-16 ) and will end on Feb 23rd at 00:00UTC.

This has been our primary document for a long time, and we have all been working towards getting it done / done right. The contents of the draft has been arrived at largely by using the IETF Issues Tracker to track the issues, the discussions and then the consensus. This provides us a great resource to understand how we got to where we are, so, during WGLC, before raising concerns / issues, please have a look if this was already opened and discussed, and how / why we ended where we did. I guess, this is another way of saying, please don't reopen issues that we have already achieved consensus on.  Just because the consensus wasn't what you wanted it to be, doesn't mean it's wrong :-P

We wish to (again) thank the WG for all of your hard work and willingness to discuss and listen to other folk's viewpoint. We would also like to thank the WG for helping us chairs to learn from this experience (I'm not sure *what* we learnt, but…:-P ) 

W

--
Don't be impressed with unintelligible stuff said condescendingly.
    -- Radia Perlman.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 09 Feb 2012 14:42:15 -0500

> We are kicking off WGLC for the protocol doc -- draft-ietf-dane-protocol ( http://tools.ietf.org/html/draft-ietf-dane-protocol-16 ) and will end on Feb 23rd at 00:00UTC.

I have reviewed the document and I'm impressed with the quality of the 
doucument, the editors have done a GREAT job producing this readable 
document.

I support that the document be advanced, below are few minor nits that 
need attention:

Section 2.1.3
Old:
  Because clients' support for multiple hash algorithms might be
    limited, it is advisable to use the same hash algorithm for the
    matching type as is used for the signature in the certificate.  Doing
    so will increase the likelihood of interoperability.

This reads like a the long way around using an RFC2119 word:
Proposed new text:
It is RECOMMENDED that TLSA record use the same hash algorithm for 
matching time as is used for the signature of the certificate. This will 
assist clients that support small number of hash algorithms.

Section A.2.2
Currently the text says this section needs to be written up or dropped.
I looked at the issues and there are 3 different cases to consider
1. delegation at the service name "
     sub5.example.com  NS ns1.example.net
    In this case the resolver will follow the delegation just like
     it would for example.net.

2. delegation at the protocol prefix
	_tcp.sub5.example.com  NS ns1.example.net
    DNS lookup will proceed just like before, the only "gotcha" is that,
    _tcp.... zone MUST be signed as well,

3. Delegation at the port prefix
	_443._tcp.sub5.example.com NS ns1.example.net
    Practically Identical to case 2.

So the only thing that this section needs to say is the same as when 
CNAME/DNAME points out of the zone:

      "In-order for TLSA validation to work the target DNS zone MUST be 
signed"

Disclaimer: I did not try to understand Appendix B.

	Olafur

---

From: James Cloos <[email-masked]>
Date: Thu, 09 Feb 2012 17:01:15 -0500

>>>>> "OG" == Olafur Gudmundsson <[email-masked]> writes:

OG> Section 2.1.3
OG> Proposed new text:
OG> It is RECOMMENDED that TLSA record use the same hash algorithm for
OG> matching time as is used for the signature of the certificate. This
OG> will assist clients that support small number of hash algorithms.

Perhaps:

> If the TLSA record's Matching Type uses a hash, It is RECOMMENDED that
> it use the same hash algorithm which was used for the signature in the
> certificate.  This will assist clients which support a small number of
> hash algorithms.

Or maybe, for the last sentence:

> This can help clients which support fewer cryptographic algorithms.

But +1 on the concept of using RECOMMENDED.

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

---

From: Ondrej Mikle <[email-masked]>
Date: Fri, 10 Feb 2012 00:34:30 +0100

> But +1 on the concept of using RECOMMENDED.

+1 on RECOMMENDED and +1 on James's formulation ("if matching type is a hash...").

Maybe yet another formulation:

If the TLSA record's Matching Type uses a hash, it is RECOMMENDED that it uses
the hash algorithm as close as possible to the hash used for the signature in
the certificate on a linear scale "MD2-MD5-SHA1-SHA256-SHA384-SHA512". In case
of ambiguity, favor the algorithm to the right. This can help clients which
support fewer cryptographic algorithms.

I originally meant to add it to the "Creating TLSA records" subsection, but it
may be a bit "overspecified" and a bit bumpy because of SHA-384 (and missing GOST).

Ondrej

---

From: Ondrej Mikle <[email-masked]>
Date: Fri, 10 Feb 2012 14:16:32 +0100

> support fewer cryptographic algorithms.

A more readable version that could be added to "Creating TLSA records"
to reference Olafur's or James's formulation of the recommendation in 2.1.3:

A.1.3 Choosing a Matching Type

  Using a hash algorithm in matching type has a performance advantage in
  shorter length of a TLSA record's association data field. Expanding on
  the recommendation expressed in section 2.1.3, guidelines for choosing
  hash in matching type are as follows - when using a hash algorithm in
  matching type, then:

  o  Use SHA-512 (matching type 2) if the associated certificate uses
     SHA-512 or SHA-384 in signature algorithm.
  o  Use SHA-256 (matching type 1) otherwise.

Ondrej Mikle

---

From: James Cloos <[email-masked]>
Date: Fri, 10 Feb 2012 10:46:41 -0500

>>>>> "OM" == Ondrej Mikle <[email-masked]> writes:

OM> A.1.3 Choosing a Matching Type

OM>   Using a hash algorithm in matching type has a performance advantage in
OM>   shorter length of a TLSA record's association data field. Expanding on
OM>   the recommendation expressed in section 2.1.3, guidelines for choosing
OM>   hash in matching type are as follows - when using a hash algorithm in
OM>   matching type, then:

OM>   o  Use SHA-512 (matching type 2) if the associated certificate uses
OM>      SHA-512 or SHA-384 in signature algorithm.
OM>   o  Use SHA-256 (matching type 1) otherwise.

Yes, that is readable and well formulated.

-JimC

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 10 Feb 2012 13:21:52 -0500

>    o  Use SHA-256 (matching type 1) otherwise.

Couple of questions:
How does this work when SHA-3 is added as a matching type?
Does the SHA-3 document have to "obsolete" this section and write a new 
section ?

Is SHA-256 the right default ?

	Olafur

---

From: Ondrej Mikle <[email-masked]>
Date: Sat, 11 Feb 2012 02:09:00 +0100

On 02/10/2012 07:21 PM, Olafur Gudmundsson wrote:
> Does the SHA-3 document have to "obsolete" this section and write a new section ?
> 

Frankly, I don't have yet the experience as to what happens when RFC is updated.
SHA-256 is likely a safe default for the nearest future.

My expectation is that when SHA-3 is standardized by NIST, then the "2.1.3
Matching Type" section will be updated to include SHA-3, as well as the "A.1.3"
section.

Ondrej

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 10 Feb 2012 17:16:09 -0800

On Feb 9, 2012, at 11:42 AM, Olafur Gudmundsson wrote:

> It is RECOMMENDED that TLSA record use the same hash algorithm for matching time as is used for the signature of the certificate. This will assist clients that support small number of hash algorithms.

SHOULDized version based on later suggestions will appear in the next draft.

> So the only thing that this section needs to say is the same as when CNAME/DNAME points out of the zone:
> 
>     "In-order for TLSA validation to work the target DNS zone MUST be signed"

If that is all there is to it, I think we should just nuke the appendix, give that we say that in the body of the text.

--Paul Hoffman

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 10 Feb 2012 20:49:17 -0800

I have reviewed this document and think it is ready for publication.  Couple of minor editorial suggestions follow.
--Richard

Section 1:
OLD
"
must trust a trust anchor upon which the server's certificate is rooted, and must successfully validate the certificate.
"
NEW
"
must successfully validate the certificate, including chaining to a trust anchor.
"

Section 4 just seems like a more verbose version of Section 2.1.1.  Propose removing to avoid confusion.
Section 4.4: Domain-issued certificates are actually supported by both usage 2 and usage 3.

On Feb 8, 2012, at 12:28 PM, Warren Kumari wrote:

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

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 11 Feb 2012 09:33:33 -0800

> must successfully validate the certificate, including chaining to a trust anchor.

Much clearer, yes.

> Section 4 just seems like a more verbose version of Section 2.1.1.  Propose removing to avoid confusion.

Y'know, I thought of that when I was reviewing it a revision or two ago. Is the WG OK with Jakob and I nuking the section and making sure all the semantics are just in 2.1.1?

> Section 4.4: Domain-issued certificates are actually supported by both usage 2 and usage 3.

Yes, maybe, but I think that would confuse the section. This point is covered at the beginning of Section 6; is it important to bring it up here as well?

--Paul Hoffman

---

From: Zack Weinberg <[email-masked]>
Date: Sat, 11 Feb 2012 10:11:53 -0800

> Y'know, I thought of that when I was reviewing it a revision or two ago. Is the WG OK with Jakob and I nuking the section and making sure all the semantics are just in 2.1.1?

I support removing the duplication, but I'd prefer to keep the section
4 text and lose the section 2.1.1 text -- it's longer, but it's
clearer IMHO.

zw

---

From: Pieter Lexis <[email-masked]>
Date: Sat, 11 Feb 2012 19:56:46 +0100

On 02/11/2012 06:33 PM, Paul Hoffman wrote:
> Y'know, I thought of that when I was reviewing it a revision or two
> ago. Is the WG OK with Jakob and I nuking the section and making sure
> all the semantics are just in 2.1.1?

+1 on merging 4 into 2.1.1.

- --
Pieter

---

From: Ondrej Mikle <[email-masked]>
Date: Sun, 12 Feb 2012 02:11:27 +0100

> Is SHA-256 the right default ?

I added a note saying to use SHA-512 matching type when certificate uses one of
future SHA-3 hashes (before algorithms from the SHA-3 family are added to
matching type field):

"""

  o  Use SHA-512 (matching type 2) if the associated certificate uses
     SHA-512, SHA-384 or a stronger algorithm (e.g. a hash from the
     future SHA-3 hash family) in signature algorithm.
  o  Use SHA-256 (matching type 1) otherwise.
"""

Ondrej Mikle

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Mon, 13 Feb 2012 16:04:44 +0100

Hi,

I reviewed draft dane-16 and I endorse it.  Review comments below.

* s/Some people want/There is/  in section 1.0.

* At 2.1.1 usage type 0 says 'chain through', does that include start
and end?  From appendix B I see it includes every cert in the chain.
I suggest:
s/a CA certificate/a CA certificate (begin and end of chain included)/

* At the bottom of page 10 it says: ';otherwise, ...' but that talks
about one usage field value.  Also it does not specify that one TLSA
match is sufficient.  New text:
; otherwise, that application attempts to use every usable TLSA
record, until a TLSA record works out to a secure TLS connection, or
all usable TLSA records fail and the TLS connection is aborted.
(( or remove the old text and insert no new text)).

* 9. in the security considerations, please add a new paragraph:
If an administrator wishes to stop using a TLSA record, the
administrator can simply remove it from the DNS.  Normal clients stop
using the TLSA record after the TTL has expired.  Replay attacks are
no longer possible after the expiration date on the RRSIG.

Best regards,
   Wouter

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 13 Feb 2012 07:32:46 -0800

> s/a CA certificate/a CA certificate (begin and end of chain included)/

Given the earlier discussion that led to type 3, I believe that this should only be the beginning (root) of the chain, yes?

> no longer possible after the expiration date on the RRSIG.

Looks right to me; do others agree?

--Paul Hoffman

---

From: Ondrej Mikle <[email-masked]>
Date: Mon, 13 Feb 2012 18:19:55 +0100

> Given the earlier discussion that led to type 3, I believe that this should only be the beginning (root) of the chain, yes?

So far I've understood usage type 0 as "including beginning and end of
chain". IIRC the usage type 3 was added to address variant (3) here:
https://www.ietf.org/mail-archive/web/dane/current/msg04188.html

Since usage type 0 does not add a TA, the "private CA scenario" does not
matter.

> Looks right to me; do others agree?

Seems fine to me as well.

Ondrej

---

From: James Cloos <[email-masked]>
Date: Mon, 13 Feb 2012 12:52:09 -0500

>>>>> "PH" == Paul Hoffman <[email-masked]> writes:

[relating to usage type 0]

PH> Given the earlier discussion that led to type 3, I believe that this
PH> should only be the beginning (root) of the chain, yes?

It seems that it is reasonable to specify an intermediate CA cert, not
only the chain's root cert.

-JimC

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 13 Feb 2012 10:37:27 -0800

On Feb 13, 2012, at 9:19 AM, Ondrej Mikle wrote:

> chain".

Whoops, my bad. The end of the chain is a CA, not the EE cert.

--Paul Hoffman

---

From: Matthijs Mekking <[email-masked]>
Date: Wed, 15 Feb 2012 10:09:45 +0100

> 4 text and lose the section 2.1.1 text -- it's longer, but it's

+1 for that.

I support this document being published. Review comments (nits and
questions) follow:

Section 5:
* Last sentence has a double "the the".

* First bullet point states that a TLSA RRset that is secure MUST be
used as a certificate association for TLS *unless* a local policy would
prohibit the use of the association. Does that mean that clients can
ignore the binding preference between domain and certificate, given by
the DNS administrator? Why is this 'unless' necessary?

* The section requires that in some cases the certificate association
MUST be marked as unusable. For how long? First thought is for the
corresponding TTL, but that value is not trustworthy, so maybe a smaller
value SHOULD be encouraged.

Section 6:
* No Downgrade: Here it says that if the TSLA RRset is bogus, TLS is not
attempted at all, while section 5 describes a fallback mechanism to TLS
in the normal fashion if zero usable certificate associations are found.

To me, having Appendix A.2.2. (Provisioning TSLA Records with NS
Records) doesn't make sense. I have never seen before such a section in
a publication that introduces a new RRtype for provisioning, why should
this one have one? I suggest to remove it.

Best regards,
  Matthijs

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 15 Feb 2012 07:32:41 -0800

> the DNS administrator? Why is this 'unless' necessary?

This came out of a discussion on the list where some people wanted it to be explicit that local policy is allowed. So, yes, it means clients can ignore anything they like as long as it is due to local policy.

> value SHOULD be encouraged.

Why do you say that the TTL value is not trustworthy? I thought that section 2.2 of RFC 4035 says that it is.

> in the normal fashion if zero usable certificate associations are found.

Note that earlier wording is that if the record is bogus, "this MUST cause TLS not to be started or, if the TLS negotiation is already in progress, MUST cause the connection to be aborted". The text in section 5 does not over-ride this.

> this one have one? I suggest to remove it.

How do others feel about this?

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 15 Feb 2012 07:35:11 -0800

On Feb 15, 2012, at 1:09 AM, Matthijs Mekking wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

It seems like there is a fair amount of support for this editorial change. Are there any objections?

--Paul Hoffman

---

From: Matthijs Mekking <[email-masked]>
Date: Wed, 15 Feb 2012 17:38:54 +0100

On 02/15/2012 04:32 PM, Paul Hoffman wrote:
>> * First bullet point states that a TLSA RRset that is secure MUST 
>> be used as a certificate association for TLS *unless* a local 
>> policy would prohibit the use of the association. Does that mean 
>> that clients can ignore the binding preference between domain and 
>> certificate, given by the DNS administrator? Why is this 'unless' 
>> necessary?
> 
> This came out of a discussion on the list where some people wanted
> it to be explicit that local policy is allowed. So, yes, it means 
> clients can ignore anything they like as long as it is due to local 
> policy.

I don't like that bit, but I guess if there were strong feelings about
it I should let it slide.

>> * The section requires that in some cases the certificate 
>> association MUST be marked as unusable. For how long? First
>> thought is for the corresponding TTL, but that value is not
>> trustworthy, so maybe a smaller value SHOULD be encouraged.
> 

The TTL cannot be trustworthy if the RRset state is intermediate,
insecure or bogus. In order to mitigate the effect of caching the
results of an attack, you should not use the value of a TTL, especially
if its high. Picking a smaller value is a similar approach as
implementing a BAD CACHE.

>> Section 6: * No Downgrade: Here it says that if the TSLA RRset is 
>> bogus, TLS is not attempted at all, while section 5 describes a 
>> fallback mechanism to TLS in the normal fashion if zero usable 
>> certificate associations are found.
> 
> Note that earlier wording is that if the record is bogus, "this MUST 
> cause TLS not to be started or, if the TLS negotiation is already in 
> progress, MUST cause the connection to be aborted". The text in 
> section 5 does not over-ride this.

So if an application receives a bogus TLSA RRset, thus zero usable
certificate associations, what happens? TLS is not attempted at all or
TLS is attempted in the normal fashion?

>> Records) doesn't make sense. I have never seen before such a 
>> section in a publication that introduces a new RRtype for 
>> provisioning, why should this one have one? I suggest to remove 
>> it.
> 
> 
> _______________________________________________ dane mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/dane

---

From: Richard Barnes <[email-masked]>
Date: Wed, 15 Feb 2012 12:28:06 -0500

> It seems like there is a fair amount of support for this editorial change. Are there any objections?

I do like the fact that 2.1.1 has RFC 2119 language.  But perhaps the single sentences from 2.1.1 could be used as first sentences for the paragraphs in section 4 ?

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 15 Feb 2012 09:30:07 -0800

> it I should let it slide.

My view is that we either tacitly admit that local policy will be used, or we pretend that it won't be and then have to deal with that lie later.

> implementing a BAD CACHE.

Sorry, I mis-read your original comment. I do not think marking an association that is marked as unusable should be cached. For example, "insecure" can easily be due to a temporary network failure. Picking any value other than 0 seems unnecessary to me; what value do you see?

> TLS is attempted in the normal fashion?

The former. If you see text that would lead you to think the latter, we should fix that.

--Paul Hoffman

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 16 Feb 2012 10:10:57 +0100

On 02/15/2012 06:30 PM, Paul Hoffman wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>>>> * First bullet point states that a TLSA RRset that is secure 
>>>> MUST be used as a certificate association for TLS *unless* a 
>>>> local policy would prohibit the use of the association. Does 
>>>> that mean that clients can ignore the binding preference 
>>>> between domain and certificate, given by the DNS
>>>> administrator? Why is this 'unless' necessary?
>>> 
>>> This came out of a discussion on the list where some people 
>>> wanted it to be explicit that local policy is allowed. So,
>>> yes, it means clients can ignore anything they like as long as
>>> it is due to local policy.
>> 
>> I don't like that bit, but I guess if there were strong feelings 
>> about it I should let it slide.
> 
> My view is that we either tacitly admit that local policy will be 
> used, or we pretend that it won't be and then have to deal with
> that lie later.
> 
>>> Why do you say that the TTL value is not trustworthy? I
>>> thought that section 2.2 of RFC 4035 says that it is.
>> 
>>  insecure or bogus. In order to mitigate the effect of caching
>> the results of an attack, you should not use the value of a TTL, 
>> especially if its high. Picking a smaller value is a similar 
>> approach as implementing a BAD CACHE.
> 
> Sorry, I mis-read your original comment. I do not think marking an 
> association that is marked as unusable should be cached. For
> example, "insecure" can easily be due to a temporary network
> failure. Picking any value other than 0 seems unnecessary to me;
> what value do you see?

I interpret the word mark incorrectly I guess. This makes this review
comment a nit. To me, you mark data so that you can make a decision
about it in the future. What about 'MUST be considered as unusable' or
'MUST NOT be considered as usable'.

>> 
>>>> Section 6: * No Downgrade: Here it says that if the TSLA
>>>> RRset is bogus, TLS is not attempted at all, while section 5 
>>>> describes a fallback mechanism to TLS in the normal fashion
>>>> if zero usable certificate associations are found.
>>> 
>>> Note that earlier wording is that if the record is bogus,
>>> "this MUST cause TLS not to be started or, if the TLS
>>> negotiation is already in progress, MUST cause the connection
>>> to be aborted". The text in section 5 does not over-ride this.
>> 
>> So if an application receives a bogus TLSA RRset, thus zero
>> usable certificate associations, what happens? TLS is not
>> attempted at all or TLS is attempted in the normal fashion?
> 

Yes, I thought a bogus TLSA RRset leaves you with zero usable
certificate associations, thus a fallback can occur. Rereading it
again, makes me think that I falsely made that assumption, probably
because its in the list of 'determining whether a TLSA RRset can be used'.

I also would move the paragraph:

   If an application receives zero usable certificate associations
(not bogus), it
   processes TLS in the normal fashion without any input from the TLSA
   records; otherwise, that application attempts to match each
   certificate association with the TLS server's end entity certificate.

towards the end of the section, so that it falls after all references
to TSLA RRsets being unusable. Note that I suggested to add '(not
bogus)' in there.

Best regards,
  Matthijs

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 16 Feb 2012 13:07:24 -0800

> 'MUST NOT be considered as usable'.

Sounds fine.

> to TSLA RRsets being unusable. Note that I suggested to add '(not

The move seems fine. I think putting in "(not bogus)" is not a good idea, because it mixes two ideas (usable vs. DNSSEC status). It also ignores "insecure" and "indeterminate".

--Paul Hoffman