I agree with Ilari - do not use the TLS SignatureAlgorithm and HashAlgorithm registries that were orphaned by RFC 8447. For (asymmetric) signatures, you could use the 16-bit TLS SignatureScheme registry ( https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-signaturescheme ). The draft is very light on details about where the user's key (private or symmetric) comes from. I assume that key generation/distribution/registration/etc is out of scope for this draft, but the draft should address the security properties expected of said key, e.g. can a key be used for Unprompted Authentication and another use? There's no mention of how a server should process this header and respond to it. Given that the purpose is to be unprobable, the draft should probably say something to the effect of "if a server receives a header it is unable to validate, it should process the request as if the header were not present". The security considerations should also discuss ways that a server might inadvertently reveal that it serves resources protected by this mechanism. On Thu, Oct 13, 2022 at 1:09 PM Ilari Liusvaara <ilariliusvaara@welho.com> wrote: > On Thu, Oct 13, 2022 at 11:58:56AM -0700, David Schinazi wrote: > > Hello HTTP enthusiasts, > > > > ---------- Forwarded message --------- > > Name: draft-schinazi-httpbis-unprompted-auth > > Revision: 00 > > Title: HTTP Unprompted Authentication > > Document date: 2022-10-13 > > Group: Individual Submission > > Pages: 9 > > URL: > > > https://www.ietf.org/archive/id/draft-schinazi-httpbis-unprompted-auth-00.txt > > Some quick comments: > > - I do not see requirement for TLS 1.3 or Extended Master Secret > anywhere. It is not safe to use TLS Exporters for authentication > otherwise. > > - There is no requirement to include hash algorithm in signatures. > There are TLS signature algorithms that mean totally different > things depending on hash function, and more of those could > appear in the future. E.g, signatures 7 and 8 already have double > meaning (EdDSA [hash 8] and some Chinese stuff [hash 7]). > > - The signatures do not appear to be contextualized in any way, > which is questionable. For example, one could use the same > contextualization mechanism that TLS 1.3 uses (which prepends > 64 spaces, a context label and NUL [one zero octet]). > > > > -Ilari > > > > > > >Received on Thursday, 13 October 2022 21:40:56 UTC
This archive was generated by hypermail 2.4.0 : Saturday, 28 January 2023 21:29:46 UTC