Subject: Re: [dane] AppsDir review of draft-ietf-dane-protocol-18

From: Paul Hoffman <[email-masked]>
Date: Sun, 1 Apr 2012 17:33:00 -0700

>> From: "Murray S. Kucherawy" <[email-masked]>
>> Subject: AppsDir review of draft-ietf-dane-protocol-18
>> Date: March 31, 2012 1:39:56 PM PDT
>> To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
>> 
>> Major Issues (things I think the WG needs to think about, clarify, reconsider, overhaul, describe better, fret about, talk me out of, etc.):
>>  
>> Section 2.1.3: I don’t know understand why this is a SHOULD.  Doesn’t it have to match exactly?  

The hash being described in 2.1.3 is *in addition* to the hash used in the key's signature, so there is no matching between these two hashes.

>> What’s an example of a situation where one could/should/would legitimately deviate from what this field says with a meaningful result?  

The person putting together the DNS record might not even know what's in the certificate.

>> The pseudocode in Appendix B leaves no room for SHOULD-style evaluation, so maybe this really ought to be a MUST.

The pseudocode gets this right: it's a second level of hash.

>> Section 10: RFC1034 and RFC1035 should be normative references, probably dragged in very early in this document.  The examples in Section 2.3 rely on zone file syntax defined there, and Appendix A.2 includes quite a bit of material that requires DNS familiarity.  A reference for DNAME (I don’t have it handy) would probably also be a good idea, though that one could be informative.

I'm leery of "you must understand DNS" being the same as "these two RFCs are what you need to understand". There is a whole lot after RFCs 103{4|5} that people need to understand to understand the DNS. How do others feel about this?

--Paul Hoffman

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 2 Apr 2012 04:33:33 +0000

Hi Paul, thanks for the reply.

> -----Original Message-----
> From: Paul Hoffman [mailto:[email-masked]]
> Sent: Sunday, April 01, 2012 5:33 PM
> To: dane list
> Cc: Murray S. Kucherawy
> Subject: Re: [dane] AppsDir review of draft-ietf-dane-protocol-18
> 
> >> Section 2.1.3: I don't know understand why this is a SHOULD.
> >> Doesn't it have to match exactly?
> 
> The hash being described in 2.1.3 is *in addition* to the hash used in
> the key's signature, so there is no matching between these two hashes.
> 
> >> What's an example of a situation where one could/should/would
> >> legitimately deviate from what this field says with a meaningful
> >> result?
> 

Ah, I see now.  Then my question swings the other way: Is there a reason to use SHOULD at all, since it's a hash of already-hashed data?  What interoperability

> I'm leery of "you must understand DNS" being the same as "these two
> RFCs are what you need to understand". There is a whole lot after RFCs
> 103{4|5} that people need to understand to understand the DNS. How do
> others feel about this?

If I look at http://tools.ietf.org/html/rfc1034, it lists 15 RFCs that update it.  RFC1035 has 22.  At least in our parlance, that means one might reasonably be expected to know or at least be familiar with (or be aware of) the full set if either or both of those are normative here.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 2 Apr 2012 04:34:43 +0000

Terrific, I found some magic "send this now while I'm still typing" key sequence in this client.  Apologies.

> From: Murray S. Kucherawy
> Sent: Sunday, April 01, 2012 9:34 PM
> To: dane list
> Subject: RE: [dane] AppsDir review of draft-ietf-dane-protocol-18
> 
> Ah, I see now.  Then my question swings the other way: Is there a
> reason to use SHOULD at all, since it's a hash of already-hashed data?
> What interoperability

...is lost if this were to be removed, for example?

-MSK

---

From: Lawrence Conroy <[email-masked]>
Date: Mon, 2 Apr 2012 11:00:28 +0100

Hi Murray, folks,
 True, and useful to know, but ...
In the time I've been using the RFC series, I've always used the ASCII versions of referenced RFCs, which are not updated (and so don't have this metadata).
Yes, one *could* get the latest copy of rfc-index to see the metadata for any RFC, or use this new-fangled online mechanism to get it.

However, I would prefer that an RFC references the docs we expect implementers to read (and so, in effect, carries its own metadata).
Particularly with DNS, there is such a thicket of docs, searching through all of the "updated by" docs to see if the section they update is the one germane to this document is a tad harsh.
(IMHO) that would not help interop as implementers shouldn't NEED to be experts in the RFC series.
-- look through this ML for the Talmudic discussions there have been to see the fun that may raise.

all the best,
  Lawrence

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 2 Apr 2012 05:23:45 -0700

On Apr 1, 2012, at 9:33 PM, Murray S. Kucherawy wrote:

> Ah, I see now.  Then my question swings the other way: Is there a reason to use SHOULD at all, since it's a hash of already-hashed data?  What interoperability is lost if this were to be removed, for example?

Assume that the inner hash algorithm (on the certificate) is SHA1 and the outer hash algorithm (on DNSSEC) is SHA256. We know that the relying party MUST have SHA1 in order to validate the signature in the certificate, but they might not have SHA256 on their computer. By saying "you should use the same alg if you know it", we're saying "this is more likely to work".

> If I look at http://tools.ietf.org/html/rfc1034, it lists 15 RFCs that update it.  RFC1035 has 22.  At least in our parlance, that means one might reasonably be expected to know or at least be fami…

Noted. I'm going to take this one to the DNSEXT WG mailing list to see what they say.

--Paul Hoffman

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 2 Apr 2012 17:17:36 +0000

> Sent: Monday, April 02, 2012 5:24 AM
> To: Murray S. Kucherawy
> Cc: dane list
> > What interoperability is lost if this were to be removed, for example?
> 
> Assume that the inner hash algorithm (on the certificate) is SHA1 and
> the outer hash algorithm (on DNSSEC) is SHA256. We know that the
> relying party MUST have SHA1 in order to validate the signature in the
> certificate, but they might not have SHA256 on their computer. By
> saying "you should use the same alg if you know it", we're saying "this
> is more likely to work".

Excellent.  I suggest adding a sentence or two to tie this all together.

> > If I look at http://tools.ietf.org/html/rfc1034, it lists 15 RFCs
> > that update it.  RFC1035 has 22.  At least in our parlance, that means
> > one might reasonably be expected to know or at least be familiar with
> > (or be aware of) the full set if either or both of those are normative
> > here.
> 

Also excellent.  Thanks for the follow-up.

-MSK

---

From: John Gilmore <[email-masked]>
Date: Tue, 10 Apr 2012 16:53:00 -0700

> The person putting together the DNS record might not even know what's in the certificate.

In general, the person putting together the DNS record does indeed
have to know what's in the certificate.  If they use selector 0, they
have to have the certificate itself so they can insert its hash into
the DNS record; if they use selector 1, they have to extract the
SubjectPublicKeyInfo from the relevant certificate, and then hash it.

   If the TLSA record's matching type is a hash, the record SHOULD use
   the same hash algorithm that was used in the signature in the
   certificate.  This will assist clients that support a small number of
   hash algorithms.

If the committee agrees, we can downgrade this SHOULD to a mere
suggestion, e.g.:

   If the TLSA record's matching type is a hash, using the same hash
   algorithm that was used in the signature in the certificate would
   assist interoperability with clients that only support a small
   number of hash algorithms.

	John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 10 Apr 2012 23:57:27 +0000

Hi John,

> From: [email-masked] [mailto:[email-masked]] On Behalf Of John Gilmore
> Sent: Tuesday, April 10, 2012 4:53 PM
> To: Paul Hoffman
> Cc: dane list
> Subject: Re: [dane] AppsDir review: SHOULD on hash algs
> 
> In general, the person putting together the DNS record does indeed have
> to know what's in the certificate.  If they use selector 0, they have
> to have the certificate itself so they can insert its hash into the DNS
> record; if they use selector 1, they have to extract the

After Paul explained it, I thought it would be fine as a SHOULD once some text was added to explain why the SHOULD was appropriate (e.g., when one would deviate from the normative statement).  In particular, it meant the consumer of the data has to have the certificate's hash algorithm to make use of it anyway, so this is an interoperability improvement point; explaining that by itself would satisfy my question.

Your text would also be fine.

-MSK

---

From: Martin Rex <[email-masked]>
Date: Thu, 12 Apr 2012 00:17:16 +0200 (MEST)

>    number of hash algorithms.

The use of SHOULD would be confusing and inappropriate, because the
vast majority of certs use a SHA1 based signatures (and the same
applies to DNSSEC signatures) whereas dane-protocol does _not_
support SHA-1 at all (dane-protocol minimum is SHA-256)

  http://tools.ietf.org/html/draft-ietf-dane-protocol-19#section-7.4

-Martin