inline w/ [DC] On Mon, Apr 14, 2025 at 5:00 PM Michael Richardson <mcr+i...@sandelman.ca> wrote:
> Deb Cooley via Datatracker <nore...@ietf.org> wrote: > > Section 7.3, para 2: Pick one: either 'mutual authentication' or > 'client > > authentication'. If you pick 'mutual authentication', then in > sentence 2, it > > could be 'mTLS uses....' [one should do a global search, there are a > bunch of > > 'client authentication' instances throughout the draft] > > I don't understand your comment. > Mutual Authentication = Server Authentication + Client Authentication. > In section 7.3, paragraph we are explaining that the client authentication > uses a different kind of key. > [DC] I guess you could add that to the terminology section. From what I could see you are using mutual auth and client auth interchangeably. Although, I'm not sure even I understand what it means for client auth to use a 'different kind of key'. Since it is exactly the same sort of key, it is only the authentication that changes. Pedantic, possibly, but the goal is for a reader to understand what they need to do to implement the protocol. > > > Section 7.3, para 3: Is this suggesting that the registrar only > needs to > > verify the Registrar-Agent's connection if it doesn't already have > the > > Registrar-Agent's EE certificate? seems odd....and possibly > insecure. > > Typically, the Registrar Agent's EE certificate is issued by the Registrar. > I can't see what the exception for the SHOULD in this paragraph is though. > I agree that paragraph needs rework. [DC] cool. > > Section 12.1: Is there a resource exhaustion DOS attack on the > Pledge? > > A pledge that can maintain only n-outstanding voucher-requests could > be DoS by n+1 attackers. Each voucher-request contains a nonce which if > just > randomly generated would need to be remembered somehow for a time. > A pledge could also attempt to make the nonce stateless by > encrypting/signing > something it doesn't have to remember. There are many ways to deal with > this, which is why SC raises it. > [DC] oh so the DOS attacks that are outlined are examples? > > > Section 6.1 and 12.3: Doesn't frequent rekey of the Registrar-Agent > lead to > > synchronization issues with the Registrar? How is this mitigated? > > The new EE key is issues by the Registrar, but maybe you are asking about > the > key that would be in the agent-signed-data. Whatever the rekey interval, > the > Agent should not rekey while it has undischarged voucher-requests. > [DC] I mean the Registrar-Agent key/certificate. Where the source of that key/cert pair is out of scope of this draft. If these certs are issued by the Registrar/CA, then maybe it isn't out of scope? Again, I'm looking for clarity for an implementer. > > > > > > > -- > Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > >
_______________________________________________ Anima mailing list -- anima@ietf.org To unsubscribe send an email to anima-le...@ietf.org
