<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 22 Sep 2020 at 23:09, Paul Wouters <<a href="mailto:paul@nohats.ca">paul@nohats.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, 22 Sep 2020, Andrew Cagney wrote:<br>
<br>
> On Tue, 22 Sep 2020 at 21:36, Paul Wouters <<a href="mailto:paul@nohats.ca" target="_blank">paul@nohats.ca</a>> wrote:<br>
>       On Tue, 22 Sep 2020, Andrew Cagney wrote:<br>
><br>
>       > Now that the parser can accept <aead>-NONE- <prf>-<dh>, should "NONE" be included when logging those proposals?  For<br>
>       instance:<br>
>       ><br>
>       > OLD:<br>
>       > algparse -v2 'ike=aes_gcm-sha1-dh21'<br>
>       > AES_GCM_16-HMAC_SHA1-DH21<br>
>       > algparse -v2 'ike=aes_gcm_16-none-hmac_sha1-dh21'<br>
>       > AES_GCM_16-HMAC_SHA1-DH21<br>
>       ><br>
>       > NEW:<br>
>       > algparse -v2 'ike=aes_gcm-sha1-dh21'<br>
>       > AES_GCM_16-NONE-HMAC_SHA1-DH21<br>
>       > algparse -v2 'ike=aes_gcm_16-none-hmac_sha1-dh21'<br>
>       > AES_GCM_16-NONE-HMAC_SHA1-DH21<br>
>       ><br>
>       > the main reason is to avoid any confusion over how integrity is being computed.<br>
><br>
>       I think that would be good, yes.<br>
><br>
>       > As a follow-up, what about non-AEAD algorithms; which get really unwieldy.<br>
><br>
>       I'm not sure what you mean?<br>
> <br>
> <br>
> algparse -v2 'ike=aes-sha2-dh31'<br>
> AES_CBC-HMAC_SHA2_256-DH31<br><br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> vs the canonical:<br>
> <br>
> algparse -v2 'ike=aes-sha2-dh31'<br>
> AES_CBC-HMAC_SHA2_256_128-HMAC_SHA2_256-DH31<br>
<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Oh I see. do we repeat the PRF after INTEG because these are always the<br>
same in the non-AEAD case.</blockquote></div><div class="gmail_quote"><br></div><div class="gmail_quote">When INTEGs and PRFs are a direct map only the slightly shorter PRFs are printed (if they are somehow different; say from impairing) then both are shown.</div><div class="gmail_quote"><br></div><div class="gmail_quote">The two choices I point forward were:<br></div><div class="gmail_quote"><div>  <encr>-<prf>-<dh> AES_CBC-HMAC_SHA2_256-DH31<div>  <encr>-<integ>-<prf>-<dh> AES_CBC-HMAC_SHA2_256_128-HMAC_SHA2_256-DH31</div><div>I guess technically there's also:</div><div>  <encr>-<integ>-<dh> AES_CBC-HMAC_SHA2_256_128-DH31</div><div><br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> I think I'm fine not doing it, since we don't<br>
support prf != integ unless AEAD. It would be more consistent to do it.<br>
I have no strong opinion on what's better.<br>
<br></blockquote><div><br></div><div>If we don't want to support prf!=integ then, I suspect, not showing the quad, even when the PRF/INTEG direct map, is safer.<br></div><div>So add -none- and then let the dust settle.</div><div> </div></div></div>