Subject: [Lurk] Comments: draft-erb-lurk-rsaalg

From: Yaron Sheffer <[email-masked]>
Date: Sat, 19 Mar 2016 23:03:42 +0200

Overall, this solves the LURK problem well but I think it
overemphasizes the feature of adding PFS to legacy clients, which
IMO is a "nice to have" for LURK, not a core requirement.

What I believe is core is the "don't create a signing oracle"
requirement, which is also met by this proposal.

Some more detailed comments:

Goals: I don't see why LURK needs to explicitly deal with a
compromise of the key owner. This seems to me as the
responsibility of the base TLS protocol.

On the other hand, I would expect a Goal around compromise of
the Server, which is after all what LURK is about.

I suggest to drop SSLv3 from Sec. 2, even though it is
technically correct.

RseponseStatus -> ResponseStatus

Thanks,

Yaron

---

From: "Erb, Samuel" <[email-masked]>
Date: Tue, 22 Mar 2016 17:21:41 +0000

Hi Yaron,
Thanks for your comments. Responses inline as [SE].

One additional item that is not addressed by this draft(for the TLS use case) is the communication of the certificate from the KeyOwner to the Server (using terminology from draft-erb-lurk-rsalg-00). This is addressed in https://tools.ietf.org/html/draft-fieau-https-delivery-delegation-02#section-4.2. I believe it will be important to define the revocation/rotation process for this certificate.

Thanks,
Samuel Erb

From: Yaron Sheffer <[email-masked]<mailto:[email-masked]>>
Date: Saturday, March 19, 2016 at 5:03 PM
To: LURK BoF <[email-masked]<mailto:[email-masked]>>
Subject: [Lurk] Comments: draft-erb-lurk-rsaalg

Overall, this solves the LURK problem well but I think it overemphasizes the feature of adding PFS to legacy clients, which IMO is a "nice to have" for LURK, not a core requirement.

What I believe is core is the "don't create a signing oracle" requirement, which is also met by this proposal.

  *   Goals: I don't see why LURK needs to explicitly deal with a compromise of the key owner. This seems to me as the responsibility of the base TLS protocol.

[SE]  I agree, that LURK does not need to deal with compromise of a key owner, but I believe it must handle compromise of access to a key owner.

  *   On the other hand, I would expect a Goal around compromise of the Server, which is after all what LURK is about.

[SE] agreed, this was mainly referred to as “access to the KeyOwner” in draft-erb-lurk-rsalg-00, that should be made more explicit.

  *   I suggest to drop SSLv3 from Sec. 2, even though it is technically correct.
  *   RseponseStatus -> ResponseStatus

Thanks,

    Yaron