<div dir="ltr"><div>Makes sense, thank you for the quick response.<br><br></div>Mike<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 28, 2014 at 4:46 PM, Paul Wouters <span dir="ltr"><<a href="mailto:paul@nohats.ca" target="_blank">paul@nohats.ca</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Wed, 28 May 2014, Mike C wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I have a question regarding AES-GCM usage in IPsec, and the impact of the lack of padding. In RFC 4106 section 3 it states that<br>
"Implementations that do not seek to hide the length of the plaintext SHOULD use the minimum amount of padding required, which<br>
will be less than four octets.". RFC 3602 for AES-CBC usage does not make any comment regarding hiding message length, presumably<br>
because the authors are happy at the minimum 16-byte padding?<br>
<br>
The RFC does not state if implementations should or should not seek to hide the length of the plaintext. I'm curious as to the<br>
approach taken by libreswan: Does it use padding > 4 octets, and if so/if not, what's the rationale behind the decision?<br>
</blockquote>
<br></div></div>
We currently do not support AES_GCM for IKE, only for IPsec. So you<br>
should be looking at the kernel code and kernel people to answer that<br>
question for you.<br>
<br>
We do plan to add AES_GCM support for IKE, most likely in libreswan<br>
3.10. Then, your question can be answered by the NSS people.<br>
<br>
The fact that the RFC does not state this as a requirement most likely<br>
means that there was no clear consensus on whether it was a required<br>
or useful feature or not - people didn't care enough and probably<br>
thought it was an uninteresting edge case?<span class="HOEnZb"><font color="#888888"><br>
<br>
Paul<br>
</font></span></blockquote></div><br></div>