<div dir="ltr"><div dir="ltr">On Thu, Jun 18, 2020 at 1:42 AM Olle E. Johansson <<a href="mailto:oej@edvina.net">oej@edvina.net</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><br><div><br><blockquote type="cite"><div>On 17 Jun 2020, at 17:22, Maxim Sobolev <<a href="mailto:sobomax@sippysoft.com" target="_blank">sobomax@sippysoft.com</a>> wrote:</div><br><div><div dir="ltr"><div dir="ltr"><div dir="auto">Whoever works on this needs to consider two things I think:<div dir="auto"><br></div><div dir="auto">- ability to select algorithms when challenging UAC (MD5-only, SHA256-only, <span style="font-size:13.3333px">SHA-512/256-only, all permutations</span>). 

The RFC allows UAS to include multiple HFs(*).  

MD5-only should probably be the default. I suspect there might be a significantly non-trivial population of UACs that would get confused receiving multiple digests. 

Plus enabling challenges for all protocols would expand the size of 401s messages. </div></div></div></div></div></blockquote>Agree, multiple challenges will break stuff. I’m not sure that implementations actually bother with parsing the algorithm parameter.<br></div></div></blockquote><div> </div><div>Sad but true... Checked some of my implementations and not all of them do.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><blockquote type="cite"><div><div dir="ltr"><div dir="ltr"><div dir="auto"><div dir="auto">- ability to accept response in either of supported hashing methods or any combination of thereof. The reasonable default here is probably MD5-only for now, again to prevent the possibility of foul play when we only request MD5, while for some reason getting say SHA-256 back.</div></div></div></div></div></blockquote>If you challenge with SHA512 only, you should not accept anything else.</div></div></blockquote><div><br></div><div>Right, this is what I am trying to say. Some complications here, namely how do you tell in practice what you have challenged the last transaction with when presented with a particular new request? Impossible in the stateless mode, won't work in the transaction mode (this is a new transaction), and dialog won't help either (no dialog at this point). When the RFC was discussed I suggested the need to expand upon HTTP RFC<span style="color:rgb(0,0,0);font-size:13.3333px">7616</span> to allow different nonces for different algorithms which might allow it to be possible and also improve overall security by giving more random bits to more advanced digests. However I got a response that authors trust all decisions made by RFC7616 and don't see any need to improve over that. :(</div><div><br></div><div>The only recourse I see with this is to either do some pre-selection based on *whatever* (user-agent, IP, etc) and then challenge/process requests with different but matching flags or store some inter-transaction  state somewhere and work from there.</div><div><br></div><div>-Max</div><div><br></div><div> </div></div></div>