Subject: [Secdispatch] Clarification Question for the Comment from Eric Rescorla (

From: "Dr. Pala" <[email-masked]>
Date: Tue, 19 Nov 2019 22:18:02 +0800

Hi Eric, all,

I am sorry I had quite a hard time to understand the questions/comments 
today, however, I would like to properly address the raised concerns/points.

*Clients / Software Updates Comment:*

    I wanted to understand your questions/comments about the need to
    update clients and that would never happen.

    Could you please elaborate on this point ?

    It is my understanding that we do have to update our crypto
    libraries when we want to support a new algorithm, and that is what
    we are talking about. Any time we add a new algorithm, the software
    needs to be updated - but I do not see why this is a problem
    specific for this solution. ALL of the approaches will need software
    updates (exactly as we did for TLS 1.3).

    Personally, I think that Composite Crypto is also interesting from
    this point of view since updating the crypto layer will enable its
    use without the need to change protocols or application behavior.
     From an application-development point of view, IMHO, it is a very
    intriguing approach.

*SHA-1 Transition:*

    One of your comments, if I am not mistaken, was about comparing one
    of the possible solutions to the problem (Composite Crypto) with the
    SHA-1 transitioning period - how, in your opinion, is that
    transition process related to the specifics of the proposal ?

Again, I am sorry I could not understand the questions clearly (normal 
language barrier issues :D), but I hope I can address your concerns on 
the list.

Thanks again,

Cheers,
Max

-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 19 Nov 2019 13:48:18 -0800

Hi Max,

My point is not that it's technically difficult for the clients to add
support for composite crypto. Clearly we could do so.

My point is rather that at a high level there are two kinds of upgrades of
algorithms in an authentication system:

- Upgrading to more secure algorithms
- Upgrading to algorithms which are better in some other way (e.g., speed,
size, etc.)

With the second kind of upgrade, you get immediate benefit because your
signatures are faster or whatever, but with the first kind of upgrade, you
get benefit when you deprecate the old algorithm. As long as you still
trust the old algorithm, then the system isn't getting much benefit from
the existence of the new algorithm because the attacker just attacks the
old one and you'll still accept it. For that reason, you need to do a two
step process:

1. Introduce the new algorithm and try to get it to be ubiquitous.
2. Stop trusting the old algorithm.

In a system like the Web, you can only do (2) once there is almost no use
of the old algorithm, otherwise you cause breakage. This, of course, is
what we did with SHA-1 and it took a really long time. We're currently
doing it with TLS 1.0 and 1.1 and we have to carefully watch the statistics
to cabin the amount of breakage.

So, when we look at composite crypto and the Web, we need to ask: are we
prepared to introduce some specific set of composite algorithms, put them
in the CABF BRs and eventually require that the CAs use them and refuse to
honor their certificates if they do not. I do not believe that we are
anywhere near that stage, both due to the maturity of the algorithms (aside
from hash signatures) and the performance (mostly size) of those
algorithms. But until we are prepared to do that, then defining the
protocol syntax doesn't really help that much.

This isn't to say that I don't think that it's useful to have PQ algorithms
in some other context (e.g., code signing) but for those contexts, I'm not
sure the right move is composite signatures rather than just to transition
wholesale to hash signatures, which we have confidence in.

-Ekr

On Tue, Nov 19, 2019 at 6:18 AM Dr. Pala <[email-masked]> wrote:

> I wanted to understand your questions/comments about the need to update
> clients and that would never happen.
>
> It is my understanding that we do have to update our crypto libraries when
> we want to support a new algorithm, and that is what we are talking about.
> Any time we add a new algorithm, the software needs to be updated - but I
> do not see why this is a problem specific for this solution. ALL of the
> approaches will need software updates (exactly as we did for TLS 1.3).
>
> Personally, I think that Composite Crypto is also interesting from this
> point of view since updating the crypto layer will enable its use without
> the need to change protocols or application behavior. From an
> application-development point of view, IMHO, it is a very intriguing
> approach.
>
> *SHA-1 Transition:*
>
> One of your comments, if I am not mistaken, was about comparing one of the
> possible solutions to the problem (Composite Crypto) with the SHA-1
> transitioning period - how, in your opinion, is that transition process
> related to the specifics of the proposal ?
>
> language barrier issues :D), but I hope I can address your concerns on the
> list.
>
> Thanks again,
>
> Cheers,
> Max
>
>
> --
> Best Regards,
> Massimiliano Pala, Ph.D.
> OpenCA Labs Director
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 20 Nov 2019 01:33:18 +0000

On 19/11/2019 21:48, Eric Rescorla wrote:
> But until we are prepared to do that, then defining the

+1

Sometimes waiting a bit is better:-)

S.

---

From: "Dr. Pala" <[email-masked]>
Date: Wed, 20 Nov 2019 15:22:22 +0800

Hi Stephen, all,

I just want to add a quick consideration here. We work with hardware 
that is deployed at the customer's homes, offices, etc. When planning 
for our innovation to hit the networks, we need to plan years in advance 
- this is not something we deal with in universities, but, I assure you, 
it requires a lot more planning than you might be used to.

I do disagree with the fact that what we are doing doesn't really help 
that much. The proposed approach does provide a solution that, although 
it might not be optimized, it works.

Other solutions might come afterwards that provide (probably more 
complex) optimized paths (maybe TLS 2.0 will be quite different because 
its design will cover the new design requirements). Another possibility 
is that application specific would define their own code points: the 
"CompositCrypto" algorithm OID will allow to combine any algorithms. 
Applications can then define their own code-points that they accept by 
simply defining the appropriate OID for the algorithm identifer. For 
example, when and if TLS, for example, would like to define its own 
combination of algorithms, a set of specific code-points can be defined 
for that.

Coming back to delaying the work - I think it is wrong and I would like 
to understand why you think it is a good idea.

  * We have the interest of an industry sector
  * Plus, there has been support on the MLs for not delaying the work
    any further
  * Plus, this work is presented by a /_*committed set of Companies that
    have real interest in using this technology*_/ to protect the PKIs
    that secure the internet connectivity for hundreds of millions of users.
  * Plus, the problem has been already addressed in other institutions
    (ITU-T) - thus indicating that IETF is falling behind on this topic.
  * Plus, we are in contact with NIST to possibly collaborate on
    real-world deployment of QRC by using Composite Crypto.

I think that blocking or stalling this work within the IETF does not 
make any sense. If there are other competing/compelling proposals, 
please let's talk about that and find a common solution we standardize. 
I personally do not think that "Sometimes waiting is a little better" is 
a valid argument.

If you have technical reasons as to why this work shall not proceed, 
please let us know, we want to deploy the best solution possible.

Thanks,
Max

-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 19 Nov 2019 23:29:16 -0800

Hi Max,

I'm not presently taking a position on whether this work should proceed in
a general matter; I haven't thought it through enough to have an opinion.

What I was trying to say in the meeting is that I don't think this is
probably to be of much use in the WebPKI at this time.

-Ekr

On Tue, Nov 19, 2019 at 11:22 PM Dr. Pala <[email-masked]> wrote:

> Hi Stephen, all,
>
> I just want to add a quick consideration here. We work with hardware that
> is deployed at the customer's homes, offices, etc. When planning for our
> innovation to hit the networks, we need to plan years in advance - this is
> not something we deal with in universities, but, I assure you, it requires
> a lot more planning than you might be used to.
>
> that much. The proposed approach does provide a solution that, although it
> might not be optimized, it works.
>
> Other solutions might come afterwards that provide (probably more complex)
> optimized paths (maybe TLS 2.0 will be quite different because its design
> will cover the new design requirements). Another possibility is that
> application specific would define their own code points: the
> combination of algorithms, a set of specific code-points can be defined for
> that.
>
> Coming back to delaying the work - I think it is wrong and I would like to
> understand why you think it is a good idea.
>
>    - We have the interest of an industry sector
>    - Plus, there has been support on the MLs for not delaying the work
>    any further
>    - Plus, this work is presented by a *committed set of Companies that
>    have real interest in using this technology* to protect the PKIs that
>    secure the internet connectivity for hundreds of millions of users.
>    - Plus, the problem has been already addressed in other institutions
>    - Plus, we are in contact with NIST to possibly collaborate on
> I think that blocking or stalling this work within the IETF does not make
> any sense. If there are other competing/compelling proposals, please let's
> talk about that and find a common solution we standardize. I personally do
> not think that "Sometimes waiting is a little better" is a valid argument.
>

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 20 Nov 2019 07:33:55 +0000

*   What I was trying to say in the meeting is that I don't think this is probably to be of much use in the WebPKI at this time.

I agree with that.

But of course that’s not a “veto” on doing this work, which OF COURSE you are not saying.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 19 Nov 2019 23:37:16 -0800

On Tue, Nov 19, 2019 at 11:34 PM Salz, Rich <[email-masked]> wrote:

>
>    - What I was trying to say in the meeting is that I don't think this
>    is probably to be of much use in the WebPKI at this time.
>
>
>
> I agree with that.
>
>
>

Agreed. I think the relevant question is if there is enough demand, so just
because WebPKI doesn't want it doesn't mean that someone doesn't.

-Ekr

_______________________________________________
> Secdispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdispatch
>