I have reviewed the draft.
Since the last update of this draft, a full collision has been found.
Do the authors intend to update the draft to state that SHA1 SHOULD NOT be used
for DNSSEC signing (DNSKEY algorithm 5,6,7) and for DNSSEC Delegation (DS and
CDS algorithm 1) ?
Please also refrain
On Tue, 28 Feb 2017, Roy Arends wrote:
Since the last update of this draft, a full collision has been found.
Do the authors intend to update the draft to state that SHA1 SHOULD NOT be used
for DNSSEC signing (DNSKEY algorithm 5,6,7) and for DNSSEC Delegation (DS and
CDS algorithm 1) ?
That
The recommendations in the document are completely unclear if it is
talking about:
- what should be in signer implementations
- what should be in validator implementations
- what someone who is starting to sign today SHOULD/MUST use
- what someone who is already signing SHOULD/MUST use
I think
On Tue, 28 Feb 2017, Paul Hoffman wrote:
The recommendations in the document are completely unclear if it is talking
about:
- what should be in signer implementations
- what should be in validator implementations
That is clearly Section 3 in two seperate columns
- what someone who is start
> On 28 Feb 2017, at 21:35, Paul Wouters wrote:
>
> On Tue, 28 Feb 2017, Roy Arends wrote:
>
>> Since the last update of this draft, a full collision has been found.
>>
>> Do the authors intend to update the draft to state that SHA1 SHOULD NOT be
>> used for DNSSEC signing (DNSKEY algorithm 5
On Tue, 28 Feb 2017, Roy Arends wrote:
We can't stuff PDF prefixes into this,
We don’t need to.
there are a lot less bytes
for an attacker to play with.
A CNAME chain will give you plenty of bytes to futz with.
None of the SHA1 hases we use are covering a chain of records.
Please also
