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

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

On 07/25/16 15:36, Stephen Farrell wrote:
>
> On 25/07/16 14:26, A. Huelsing wrote:
>> I have the slight feeling that we get several things mixed up in this
>> discussion.
> Such is life:-)
Yeah, life... :-)
>
> I mostly agree with your characterisation below but that omits two
> important things: 1) cfrg will be defining other PQ schemes as those
> reach the relevant level of maturity and 2) any PQ scheme RFC will
> very likely lead to some folks demanding/asking that it be deployed,
> when that may be premature, and esp. if the RFC doesn't give good
> guidance about that topic.
>
> So I think it's important to try to get to a consensus statement
> about the deployability of PQ schemes in general, and not only for
> this less-risky scheme. That way we can have the hard part of this
> discussion once and then cut'n'paste the text into other drafts
> for so long as that text is still good. (*)
>
> That's why I'm arguing that we should have a fairly conservative
> statement that can be included in more or less all PQ scheme RFCs
> that are developed for the next while.
>
> I've no problem at all if that short statement is followed by one
> that sets this particular scheme into that context.
I agree that it is important for cfrg to find a position in this. However,
I do not think that a generic statement solves the issue. The reason
being that the required solution differs. E.g., for lattice-based
key-exchange where we still got some doubts on the actual security
of specific parameter sets, the solution is to deploy it right now in
combination with a non-pq but classically secure scheme. That way,
we at least get the same security as before... For the XMSS, I think
it is more about people getting used to the state handling. Which
requires being extremely careful implementing key handling.
This is also the reason why we are first (also referring to (*)), because
we do not have these issues.

> Hence my originally proposed text.
>
> Cheers,
> S.
>
> (*) It is a bit unfortunate that yours is the 1st such document,
> and apologies again for this slowing you down, but I think overall
> getting this done now is well worthwhile.
>
>> 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
>>