Re: [Cfrg] I-D Action: draft-irtf-cfrg-xmss-hash-based-signatures-06.txt

["A. Huelsing" <[e-mail]>]

I have the slight feeling that we get several things mixed up in this
discussion.

To me it looks as if there are several topics on the table:

1. "Cryptographic security": I think people on the list agree by now
that the
chances that XMSS will be broken by cryptanalysis is not higher than for
any deployed signature scheme (in fact, I personally would claim that it is
strictly more secure than any deployed signature scheme that can handle
arbitrary length messages, as such schemes need a secure cryptographic
hash function at least in the strongest sense that is used by XMSS, i.e.
extended target collision resistant). Note that the above also includes the
non-quantum attacks case!

2. "Implementation security": No one disagreed on the fact that there is
hardly any experience with implementing stateful signature schemes. We
emphasize this through out the draft and it was discussed here a lot. I am
totally happy to add a special "note to IETF working groups"  to the draft
where we repeat this once more, writing e.g. something along the lines
of what Kenny suggested.

3. "Politics": Should we deploy post-quantum crypto now, possibly at the
cost of not deploying advanced "classical" crypto. This is an issue that in
my opinion should not be mixed with the above two but the decision on
this should be motivated by the answers to the above. I think we got here
a special case for hash-based signatures as -- in contrast to other
pq-proposals -- we do not introduce new hardness assumptions.
This being said, I understand that there are other reasons that motivate
people not to deploy any pq-crypto right now. However, in that case we
should debate about these reasons and don't start a mock debate (hope
this is the proper English word) about the XMSS draft.

Looking forward to a fruitful discussion,

Andreas



On 07/24/16 14:09, Stephen Farrell wrote:
>
> On 23/07/16 23:27, Watson Ladd wrote:
>> On Sat, Jul 23, 2016 at 1:56 PM, Stephen Farrell
>> <[e-mail]> wrote:
>>>
>>> On 23/07/16 20:14, Paterson, Kenny wrote:
>>>> Your other point regarding state is well made.
>>> So that, and the fact that implementations are going to be
>>> brand new and hence quite likely buggy implies to me that
>>> the more cautious text I suggested takes the right approach.
>> If we go by that metric, 
> I wasn't suggesting a metric, it's an argument for caution with
> new stuff.
>
>> OpenSSL's BN code will never have security
>> relevant bugs, and ref10. Oh wait, that's not true at all, because we
>> can verify ref10's correctness, and the BN code actually had bugs.
>> Maybe we should try solving the problem of writing code to not have
>> bugs (newsflash: it has been solved, the methods are not expensive,
>> and crypto is an excellent place to apply them)
> Now you're being wildly optimistic with "been solved" :-) We don't
> control how developers implement our stuff and we do know that a lot
> of systems and developers will end up using buggy things, and all
> the moreso the newer the technology involved.
>
>> We've extremely clearly documented the stateful nature of the scheme.
>> This implementation question is different from whether the scheme
>> meets the security goals it claims. We can try to design schemes to
>> avoid common programing issues, and encourage the usage of more robust
>> schemes.
>>
> All good things yes.
>
>>> Even if we're cryptographically confident of this particular
>>> scheme, we are IMO far from wanting the Internet to depend
>>> upon it (or any other proposed PQ scheme).
>> Isn't this because we aren't sure if we can deploy it safely/the
>> desirablity ? 
> Right. I think those are unquestionably good arguments even after
> we're very confident in the specific scheme.
>
> Additionally, but less convincing, I see a danger that people divert
> deployment effort to such schemes, when that'd, for now, be better
> devoted to improving and better deploying current technology. IOW,
> premature effort devoted to PQ deployment is IMO a shiny-new-thing
> danger. I do think we need text to provide readers with the right
> guidance on that. Otherwise, even those who think it premature to
> deploy PQ schemes may be pressured by their customers to do so now.
> (Note: deployment is what I consider premature, not engineering or
> research.)
>
>> Do you actually think that XMSS is insecure against
>> quantum computers? 
> I think my initial note in this thread made it clear that I am not
> making any such claim.
>
>> To be clear, if there is no hash function that isTher
>> secure against QM, game over: signatures imply hash functions.
>>
>> Of course, key exchanges are more dangerous then signatures, CA
>> hoodwinking of customers aside. We don't need to post-quantum
>> transition signatures now.
> Sorta. We do need such signature schemes to be researched and
> developed. I agree we don't yet need 'em deployed.
>
> S.
>
>>> Cautious text is better here now, rather than overly optimistic
>>> text.
>>>
>>> S.
>>>
>>>
>>> _______________________________________________
>>> Cfrg mailing list
>>> [e-mail]
>>> https://www.irtf.org/mailman/listinfo/cfrg
>>>
>>
>>
>
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg