Subject: [dane] Hash specs, and examples in sec. 2.3

From: John Gilmore <[email-masked]>
Date: Mon, 13 Feb 2012 15:24:31 -0800

According to https://www.ietf.org/id-info/checklist.html section 4.3:

  If any sort of end-to-end checksum or integrity check is being used
  (especially, but not limited to, cryptographic checksums or MACs),
  specify precisely the contents of the fields to be checksummed, and
  exactly what order the operations are done in.  Pay special attention
  to any area reserved for the checksum itself.

Therefore, I think we should clarify the text in section 2.1.4.  

I also think we should include a worked-out example TLSA RRs in
section 2.3 that shows a full certificate (in hexadecimal) in the
RDATA, a second TLSA RR that instead uses THAT CERTIFICATE'S extracted
SubjectPublicKeyInfo, another TLSA RR that provides a SHA-256 hash of
that same full certificate, and another TLSA RR that provides a
SHA-512 hash of the extracted SubjectPublicKeyInfo.  This will provide
a simple sanity check for implementers, showing whether they have the
extraction and hashing right.

(The full certificate in the example can be a small cert, e.g. a
self-signed one with few internal fields, and using short keys and
signatures, to avoid verbosity).

Would the WG like me to work on producing such example text, or is
there someone else who has the tools for this close at hand?

	John

---

From: Pieter Lexis <[email-masked]>
Date: Tue, 14 Feb 2012 00:36:03 +0100

WG and John,

When making swede I used a selfsigned cert (and a cert signed by comodo using the same csr) to create a test bed. I'd be happy to supply the WG with the certificates, keys and other material to include a (partial) test vector.

--
Pieter

John Gilmore <[email-masked]> wrote:

	John
_____________________________________________

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

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 13 Feb 2012 16:44:49 -0800

> Therefore, I think we should clarify the text in section 2.1.4.  

As always, specific wording is appreciated. We've worked on this section a lot, and may have lost some of the clarity you desire.

> extraction and hashing right.

If someone does this work, I would prefer that in goes in an appendix.

NOTE HOWEVER, that even if we get two people to assure that the examples are right, there is a good chance they will be wrong AND WILL MESS UP IMPLEMENTERS. We have seen this over and over in the IETF, and as author of some of those documents, I'm pretty gun-shy here, strongly preferring to let "the market" work it out with dynamic test code that is not locked into an RFC. Someone just discovered a many-years-old error in the PKIX spec, for example.

--Paul Hoffman

---

From: Martin Rex <[email-masked]>
Date: Tue, 14 Feb 2012 23:08:29 +0100 (MET)

Paul Hoffman wrote:
> NOTE HOWEVER, that even if we get two people to assure that the examples
> are right, there is a good chance they will be wrong AND WILL MESS UP
> IMPLEMENTERS. We have seen this over and over in the IETF, and as author
> of some of those documents, I'm pretty gun-shy here, strongly preferring
> to let "the market" work it out with dynamic test code that is not locked
> into an RFC. Someone just discovered a many-years-old error in the PKIX
> spec, for example.

This sounds really scary to me, Paul.

The reason why we produce standards is that people *OUTSIDE* of the IETF
can implement them without having participated discussions.  Your
messages suggests that there might be to much "hot air" and too little
running code & experience for the current document to be useful
for creating independent interoperable implementations.

But you should keep in mind that a typical implementation receives
much less review than what dane-protocol could receive.

I believe, if we can not produce examples that can be easily reviewed
for correctness, then this is more likely a sign of unnecessary complexity
in the protocol design or lack of clarity in the document, rather than
inability to ensure that examples are correct.

My personal experience is, that with more detail and redundancy it
is easier to (a) recognize and (b) compensate defects in the spec
when implementing it.  A very fruitful means to review a spec for
inconsistencies and ambiguities, is to implement it
(and that is what I thought the "we believe in running code" refers to).

-Martin

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 14 Feb 2012 15:06:01 -0800

> This sounds really scary to me, Paul.

It should. We spend inordinate amounts of time arguing about what to do when "helpful" examples in protocol specs in fact turn out to be harmful.

> can implement them without having participated discussions.  

Yes.

> Your

No, they don't suggest that at all. This particular message suggests that the best way to help developers is to not make it too easy to copy examples and think they don't have to read the spec. Notice the difference?

Since you read the list, you know that there are already multiple initial implementations out there. None of those developers came to the list and said "I can't do this unless you put more examples in the document". They seem to be testing with each other just fine.

> much less review than what dane-protocol could receive.

Absolutely correct.

> inability to ensure that examples are correct.

We would disagree about that.

> (and that is what I thought the "we believe in running code" refers to).

No offense, but is this really hurting your ability to actively implement DANE? Or are you saying that you believe this is true for other, unnamed developers?

Again, the IETF has decades of experience with problems of examples that were reviewed, but insufficiently. Why is TLSA different?

--Paul Hoffman

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 24 Feb 2012 17:15:49 +0100

Hi WG and early implementors,

anybody of you willing to work on text to clarify 2.1.4?  I am Ccing people with know implementation, so you can:

a) provide the text, since you have the experience
b) cross-check the text

Please at least one of you, say yes.  Thanks.

> Therefore, I think we should clarify the text in section 2.1.4.  

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: Ondřej Surý <[email-masked]>
Date: Fri, 24 Feb 2012 17:18:06 +0100

Pieter,

> When making swede I used a selfsigned cert (and a cert signed by comodo using the same csr) to create a test bed. I'd be happy to supply the WG with the certificates, keys and other material to inc…

That would be great.

Paul, I share your concern, but I see a value in providing examples.  If we can carefully and independently check provided examples, then I think we don't have to worry too much.

O.

---

From: Pieter Lexis <[email-masked]>
Date: Fri, 24 Feb 2012 17:53:31 +0100

Hi Ondřej,

On 02/24/2012 05:15 PM, Ondřej Surý wrote:
> anybody of you willing to work on text to clarify 2.1.4?  I am
> Ccing people with know implementation, so you can:
> 

Not sure how this should be written, should it be pseudo-code or text?
A small try:

  The data in this field is created as follows:
   o Based the on the selector, use either the full certificate or
     the SubjectPublicKeyInfo from the certificate for the next step.
   o Retrieve the DER representation for the data from the previous
     step.
   o If the matching type states the use of a hashing algorithm, hash
     the result of the previous step using that algorithm.
   o The resulting bytes are the data for this field.

Pseudocode (loosly typed and ugly, but I do python ;-)):

  Data = Certificate_for_association
  if (selector == 1) {
    Data = get_SubjectPublicKeyInfo(Data)
  }
  Data = as_DER(Data)
  if (matching_type != 0) {
    Data = Hash(Data)
  }
  // Data now contains the association data.

I hope this gives the WG a start to work with.

- --
Pieter

---

From: Pieter Lexis <[email-masked]>
Date: Sat, 25 Feb 2012 10:38:23 +0100

WARNING: contains banned part

Subject: Re: [dane] Hash specs, and examples in sec. 2.3
From: Pieter Lexis <[email-masked]>
To: Ondřej Surý <[email-masked]>
Cc: Paul Hoffman <[email-masked]>, IETF DANE WG list <[email-masked]>
Date: Sat, 25 Feb 2012 10:38:23 +0100

Hi,

On 02/24/2012 05:18 PM, Ondřej Surý wrote:
>> When making swede I used a selfsigned cert (and a cert signed by
>>  comodo using the same csr) to create a test bed. I'd be happy to
>>  supply the WG with the certificates, keys and other material to
>>  include a (partial) test vector.
> 
> That would be great.

I've included the self-signed certificate, as the permutations of the
usage field are unimportant for these examples. I would also like to see
the document to RECOMMEND using hashing, as a full certificate is large
(for me it's over 1100 bytes for a cert with a 3072 bit key).

This data can also be retrieved from DNS:
 _150X._tcp.dane.kiev.practicum.os3.nl
Where X is between 0 and 5 (inclusive).

> Paul, I share your concern, but I see a value in providing
> examples. If we can carefully and independently check provided
> examples, then I think we don't have to worry too much.

These record were created using swede, so don't use it to verify the
correctness of them :).

S = Selector
M = Matching Type

S M Association Data
0 0 30820454308202BC020900AB58D24E77AD2AF6300D06092A86
    4886F70D0101050500306C310B3009060355040613024E4C31163014
    0603550408130D4E6F6F72642D486F6C6C616E643112301006035504
    071309416D7374657264616D310C300A060355040A13034F53333123
    30210603550403131A64616E652E6B6965762E70726163746963756D
    2E6F73332E6E6C301E170D3132303131363136353730335A170D3232
    303131333136353730335A306C310B3009060355040613024E4C3116
    30140603550408130D4E6F6F72642D486F6C6C616E64311230100603
    5504071309416D7374657264616D310C300A060355040A13034F5333
    312330210603550403131A64616E652E6B6965762E70726163746963
    756D2E6F73332E6E6C308201A2300D06092A864886F70D0101010500
    0382018F003082018A0282018100E62C84A5AFE59F0A2A6B250DEE68
    7AC8C5C604F57D26CEB2119140FFAC38C4B9CBBE8923082E7F81626B
    6AD5DEA0C8771C74E3CAA7F613054AEFA3673E48FFE47B3F7AF987DE
    281A68230B24B9DA1A98DCBE51195B60E42FD7517C328D983E26A827
    C877AB914EE4C1BFDEAD48BD25BE5F2C473BA9C1CBBDDDA0C374D0D5
    8C389CC3D6D8C20662E19CF768F32441B7F7D14AEA8966CE7C32A172
    2AB38623D008029A9E4702883F8B977A1A1E5292BF8AD72239D40393
    37B86A3AC60FA001290452177BF1798609A05A130F033457A5212629
    FBDDB8E70E2A9E6556873C4F7CA46AE4A8B178F05FB319005E1C1C7D
    4BD77DFA34035563C126AA2C3328B900E7990AC9787F01DA82F74C3D
    4B6674CCECE1FD4C6EF9E6644F4635EDEDA39D8B0E2F7C8E06DAE775
    6213BD3D60831175BE290442B4AFC5AE6F46B769855A067C1097E617
    962529E166F22AEE10DDB981B8CD6FF17D3D70723169038DBFBC1A44
    9C8D0D31BC683C5F3CE26148E42EC9BBD4D9F261569B25B53C1D7FC2
    DDFF6B4CAC050203010001300D06092A864886F70D01010505000382
    0181002B2ABE063E9C86AC4A1F7835372091079C8276A9C2C5D1EC57
    64DE523FDDABDEAB3FD34E6FE6CBA054580A6785A663595D90132B93
    D473929E81FA0887D2FFF78A81C7D014B97778AB6AC9E5E690F6F5A9
    E92BB5FBAB71B857AE69B6E18BDCCB0BA6FCD9D4B084A34F3635148C
    495D48FE635903B888EC1DEB2610548EDD48D63F86513A4562469831
    48C0D5DB82D73A4C350A42BB661D763430FC6C8E5F9D13EA1B76AA52
    A4C358E5EA04000F794618303AB6CEEA4E9A8E9C74D73C1B0B7BAF16
    DEDE7696B5E2F206F777100F5727E1684D4132F5E692F47AF6756EA8
    B421000BE031B5D8F0220E436B51FB154FE9595333C13A2403F9DE08
    E5DDC5A22FD6182E339593E26374450220BC14F3E40FF33F084526B0
    9C34250702E8A352B332CCCB0F9DE2CF2B338823B92AFC61C0B6B8AB
    DB5AF718ED8DDA97C298E46B82A01B14814868CFA4F2C36268BFFF4A
    591F42658BF75918902D3E426DFE1D5FF0FC6A212071F6DA8BD833FE
    2E560D87775E8EE9333C05B6FB8EB56589D910DB5EA903

0 1 EFDDF0D915C7BDC5782C0881E1B2A95AD099FBDD06D7B1F779
    82D9364338D955

0 2 81EE7F6C0ECC6B09B7785A9418F54432DE630DD54DC6EE9E3C
    49DE547708D236D4C413C3E97E44F969E635958AA410495844127C04
    883503E5B024CF7A8F6A94

1 0 308201A2300D06092A864886F70D01010105000382018F0030
    82018A0282018100E62C84A5AFE59F0A2A6B250DEE687AC8C5C604F5
    7D26CEB2119140FFAC38C4B9CBBE8923082E7F81626B6AD5DEA0C877
    1C74E3CAA7F613054AEFA3673E48FFE47B3F7AF987DE281A68230B24
    B9DA1A98DCBE51195B60E42FD7517C328D983E26A827C877AB914EE4
    C1BFDEAD48BD25BE5F2C473BA9C1CBBDDDA0C374D0D58C389CC3D6D8
    C20662E19CF768F32441B7F7D14AEA8966CE7C32A1722AB38623D008
    029A9E4702883F8B977A1A1E5292BF8AD72239D4039337B86A3AC60F
    A001290452177BF1798609A05A130F033457A5212629FBDDB8E70E2A
    9E6556873C4F7CA46AE4A8B178F05FB319005E1C1C7D4BD77DFA3403
    5563C126AA2C3328B900E7990AC9787F01DA82F74C3D4B6674CCECE1
    FD4C6EF9E6644F4635EDEDA39D8B0E2F7C8E06DAE7756213BD3D6083
    1175BE290442B4AFC5AE6F46B769855A067C1097E617962529E166F2
    2AEE10DDB981B8CD6FF17D3D70723169038DBFBC1A449C8D0D31BC68
    3C5F3CE26148E42EC9BBD4D9F261569B25B53C1D7FC2DDFF6B4CAC05
    0203010001

1 1 8755CDAA8FE24EF16CC0F2C918063185E433FAAF1415664911
    D9E30A924138C4

1 2 D43165B4CDF8F8660AECCCC5344D9D9AE45FFD7E6AAB7AB9EE
    C169B58E11F227ED90C17330CC17B5CCEF0390066008C720CEC6AAE5
    33A934B3A2D7E232C94AB4

- --
Pieter

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 25 Feb 2012 13:37:48 +0200

On Sat, Feb 25, 2012 at 10:38:23AM +0100, Pieter Lexis wrote:

Did some verification on these.

> These record were created using swede, so don't use it to verify the

Well, I used some custom tool (hex to binary converter), sha256sum,
sha512sum and dumpasn1.
 
> 0 0 30820454308202BC020900AB58D24E77AD2AF6300D06092A86
<snip>
>     2E560D87775E8EE9333C05B6FB8EB56589D910DB5EA903

- Parses without errors/warnings using dumpasn1
- No extraneous outer wrapping seen.
- Seems to match the syntax defined by RFC1422 (x509v1).

> 0 1 EFDDF0D915C7BDC5782C0881E1B2A95AD099FBDD06D7B1F779

- SHA-256 I get matches.

>     49DE547708D236D4C413C3E97E44F969E635958AA410495844127C04

- SHA-512 I get matches.
 
> 1 0 308201A2300D06092A864886F70D01010105000382018F0030
<snip>

- Parses without errors/warnings using dumpasn1
- Substring of full certificate.
- No extraneous outer wrapping seen.
- The only part of the certificate that looks even remotely
like SPKI.

> 1 1 8755CDAA8FE24EF16CC0F2C918063185E433FAAF1415664911

- SHA-256 I get matches.

>     C169B58E11F227ED90C17330CC17B5CCEF0390066008C720CEC6AAE5

- SHA-512 I get matches.

-Ilari