<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
On 2025-01-24 18:30, Sarath _Msft_ via devel wrote:<br>
<blockquote type="cite"
cite="mid:BL0PR1701MB2452A0EF67CB7C348F6FF4ACFCE22@BL0PR1701MB2452.namprd17.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style type="text/css" style="display:none;">P {margin-top:0;margin-bottom:0;}</style>
<div class="elementToProof"
style="line-height: 1.38; margin: 0in 0in 8pt; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">I
am a software engineer with Microsoft Corporation.</div>
</blockquote>
<p>I'm not a crypto expert nor am I speaking on behalf of the NTPsec
project, so take this with an appropriately sized grain of salt.
;)</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:BL0PR1701MB2452A0EF67CB7C348F6FF4ACFCE22@BL0PR1701MB2452.namprd17.prod.outlook.com">
<div
style="line-height: 1.38; margin: 0in 0in 8pt; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
As I understand it, the current NTPSec implementation supports
only the AEAD_AES_SIV_CMAC algorithms of various cipher lengths.
I propose including support for AEAD_AES_128_GCM,
AEAD_AES_256_GCM, AEAD_AES_128_CCM and AEAD_AES_256_CCM
algorithms in this implementation.</div>
</blockquote>
<p>My initial reaction was: doesn't NTS specify the exact
algorithms, like TLS 1.3 does? After looking at the RFC,
apparently not. But it's close. The RFC does specifically say that
"Server implementations... MUST support AEAD_AES_SIV_CMAC_256."
(RFC 8915, section 4.1.5).
</p>
<div class="moz-cite-prefix"><br>
</div>
<p><br>
</p>
<blockquote type="cite"
cite="mid:BL0PR1701MB2452A0EF67CB7C348F6FF4ACFCE22@BL0PR1701MB2452.namprd17.prod.outlook.com">
<div class="elementToProof"
style="line-height: 1.38; margin: 0in 0in 8pt; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
These specific algorithms are implemented in both OpenSSL
library and Microsoft's SymCrypt Library (<a
href="https://github.com/microsoft/SymCrypt" id="LPlnk"
moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/microsoft/SymCrypt</a>) ,
whereas the AEAD_AES_SIV_CMAC algorithms are not.</div>
</blockquote>
<br>
<p>You don't seem to have proposed building NTPsec against SymCrypt.
So it seems that you are suggesting some other NTS implementation,
perhaps written by Microsoft, will use the SymCrypt library, which
does not support AES SIV. Are you suggesting that:</p>
<p><br>
</p>
<p>A) a <i>server</i> implementation will exist that does not
support AES SIV <i>as required by the standard</i> and NTPsec
should expand its algorithm support <i>as a client</i> to
interoperate with such a server?</p>
<p><br>
</p>
<p>B) a <i>client</i> implementation will exist that do not support
AES SIV and NTPsec should expand its algorithm support <i>as a
server</i> to interoperate with such a client?</p>
<p><br>
</p>
<p>If it's the latter, is this some specialty client, or is
Microsoft intending to add NTS support to Windows itself (but
without AES SIV)?</p>
<p><br>
</p>
<p>For this to be widely useful, presumably you are making the same
proposal to multiple NTS implementations. Why go through all the
work to add AES-GCM and/or AES-CCM to multiple NTS implementations
rather than add AES-SIV to SymCrypt? Adding AES-SIV on your side
would instantly make you compatible with every server and
presumably most clients.</p>
<p><br>
</p>
<p>Also, why both GCM and CCM modes?</p>
<pre class="moz-signature" cols="72">--
Richard</pre>
</body>
</html>