I agree with Russ.
On Mon, Jun 19, 2017 at 8:35 AM, Russ Housley wrote:
>
> > On Jun 19, 2017, at 11:26 AM, Paul Wouters wrote:
> >
> > On Mon, 19 Jun 2017, Eric Rescorla wrote:
> >
> >> If manual keying is used anyway, AEAD algorithms MUST NOT be
> On Jun 19, 2017, at 11:26 AM, Paul Wouters wrote:
>
> On Mon, 19 Jun 2017, Eric Rescorla wrote:
>
>> If manual keying is used anyway, AEAD algorithms MUST NOT be used,
>> as these algorithms require additional input provided by IKE and
>> are compromised if a
> On Jun 19, 2017, at 11:16 AM, Eric Rescorla wrote:
>
>
>
> On Mon, Jun 19, 2017 at 7:45 AM, Paul Wouters wrote:
>
> Paul Wouters writes:
> -3: I wonder why "... is not to be used..." is not "... MUST NOT be
> used...". But the section goes on to say if you
On Mon, 19 Jun 2017, Eric Rescorla wrote:
If manual keying is used anyway, AEAD algorithms MUST NOT be used,
as these algorithms require additional input provided by IKE and
are compromised if a counter is accidentally re-used, such as when
a counter overflows, or when a
On Mon, Jun 19, 2017 at 7:45 AM, Paul Wouters wrote:
> On Thu, 23 Mar 2017, Tero Kivinen wrote:
>
> Paul Wouters writes:
>>
>>> -3: I wonder why "... is not to be used..." is not "... MUST NOT be
used...". But the section goes on to say if you do it anyway, you MUST
NOT
On Thu, 23 Mar 2017, Tero Kivinen wrote:
Paul Wouters writes:
-3: I wonder why "... is not to be used..." is not "... MUST NOT be
used...". But the section goes on to say if you do it anyway, you MUST
NOT use certain cryptosuites. So, does "... is not to be used..." mean
"SHOULD NOT"? Or is
[IPsec] Ben Campbell's Yes on draft-ietf-ipsecme-rfc7321bis-05:
> (with COMMENT)
>
>
> > On Mar 23, 2017, at 5:37 AM, Tero Kivinen <kivi...@iki.fi> wrote:
> >
> > Paul Wouters writes:
> >>> -3: I wonder why "... is not to be used..." is not "
> On Mar 23, 2017, at 5:37 AM, Tero Kivinen wrote:
>
> Paul Wouters writes:
>>> -3: I wonder why "... is not to be used..." is not "... MUST NOT be
>>> used...". But the section goes on to say if you do it anyway, you MUST
>>> NOT use certain cryptosuites. So, does "... is not
Paul Wouters writes:
> > -3: I wonder why "... is not to be used..." is not "... MUST NOT be
> > used...". But the section goes on to say if you do it anyway, you MUST
> > NOT use certain cryptosuites. So, does "... is not to be used..." mean
> > "SHOULD NOT"? Or is this one of those "MUST NOT BUT
On Mar 16, 2017, at 4:13 PM, Frankel, Sheila E. (Fed)
> wrote:
Hi Dave,
I don't have any strong feelings about MUST NOT vs. SHOULD NOT, but I wonder if
it would help to clarify the reasoning behind it.
For these algorithms, RFC6071
t;i...@ietf.org>; draft-ietf-ipsecme-rfc7321...@ietf.org;
> ipsec@ietf.org; ipsecme-cha...@ietf.org; Waltermire, David A. (Fed)
> <david.walterm...@nist.gov>
> Subject: Re: [IPsec] Ben Campbell's Yes on draft-ietf-ipsecme-rfc7321bis-05:
> (with COMMENT)
>
> On
Thansk for the response. This resolves all but one of my comments, where
I still have a question:
On 16 Mar 2017, at 12:07, Paul Wouters wrote:
On Wed, 15 Mar 2017, Ben Campbell wrote:
[...]
First paragraph under the table:
AUTH_NONE has been downgraded from MAY in RFC7321 to MUST
me-cha...@ietf.org; Waltermire, David A. (Fed)
> <david.walterm...@nist.gov>
> Subject: Re: [IPsec] Ben Campbell's Yes on draft-ietf-ipsecme-rfc7321bis-05:
> (with COMMENT)
>
> On Wed, 15 Mar 2017, Ben Campbell wrote:
>
> > -3: I wonder why "... is not to be us
On Wed, 15 Mar 2017, Ben Campbell wrote:
- Abtstract: "This document obsoletes RFC 7321 on the cryptographic
recommendations only."
I'm not sure what that means. Does the reader of this still need to read
7321? If so, is "obsoletes" the correct relation?
Skimming over 7321 I cannot actually
Ben Campbell has entered the following ballot position for
draft-ietf-ipsecme-rfc7321bis-05: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
15 matches
Mail list logo