[IPsec] Secdir last call review of draft-ietf-ipsecme-labeled-ipsec-10

[Stephen Farrell via Datatracker]

Reviewer: Stephen Farrell
Review result: Ready

-10 is ready


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] [secdir] Secdir last call review of draft-ietf-ipsecme-labeled-ipsec-09

[Stephen Farrell]

Hi Paul,

Those changes resolve the issue and nits I saw,

Cheers,
S.

On 05/04/2023 17:21, Paul Wouters wrote:

On Tue, 4 Apr 2023, Stephen Farrell via Datatracker wrote:

Hi Stephen,

Thanks for the secdir review!


This is basically fine, but I think there's one issue that
isn't quite a nit:

1.3: "Typically, the other TS_TYPE would be of type
TS_IPV4_ADDR_RANGE and/or TS_IPV6_ADDR_RANGE." That seems a
bit vague, and maybe less future proof than might be the
case, e.g. say if someone defines a new TS type for gold,
silver etc. service level that's also intended to be
combined with address TS's, I'm not sure it'd make sense to
combine this and that (putative) new service level TS with
no address type TS's and have things make sense. Maybe
better to say this TS MUST be combined with an address type
selector? (That statement might go in section 3.)


I've changed the sentence in Section 1.3 to:

OLD:

     Typically, the other TS_TYPE would be of type
     TS_IPV4_ADDR_RANGE and/or TS_IPV6_ADDR_RANGE.

NEW:

     It MUST be used along with an IP address Traffic Selector
     type such as TS_IPV4_ADDR_RANGE and/or TS_IPV6_ADDR_RANGE.

And in section 3:

OLD:

     Because of this there MUST be some other TS_TYPEs in addition
     to TS_SECLABEL in the Traffic Selector Payload when it is used
     in negotiation.

NEW:

     There MUST be an IP address Traffic Selector type in addtion
     to the TS_SECLABEL Traffic Selector type in the Traffic Selector
     Payload.


nits:

2.2: Typo? "(with deemed the Security Label optional)"
s/with/which/ ?


Fixed.


2/3: I wasn't entirely clear what's meant by "optional" - it
doesn't seem to map to a protocol flag or simiilar but to
whether or not an implementation chooses to emit one of
these TS's - is that right? If so, it could maybe be
clearer.


That is right. But I thought that was made clear just above the
sentence you quote:

  If the Security Label traffic selector is optional from a 
configuration point of view,

  an initiator will add the TS_SECLABEL to the TSi/TSr Payloads.  [...]


3: the SHOULD level fallback to a new child SA without the
label seems a bit odd for a MAC system - is that really the
right choice? (I'll believe you if you say "yes," so just
asking in case this is an oversight:-)


It is a little odd, as you would not want to have the extra security
label being "optional", which adds no security. However, some people
wanted this to give them an upgrade path from "without" to "with" a
security label without requiring a flag day or brand new deployment
to switch a deployment from "no label" to "labeled". Note that my
own (libreswan) implementation does not support this. Connections
are configured either with or without the label and the label must
be negotiated if configured. That is, it has no concept of "optional".

All changes will appear in version 10.

Paul


OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Secdir last call review of draft-ietf-ipsecme-labeled-ipsec-09

[Stephen Farrell via Datatracker]

Reviewer: Stephen Farrell
Review result: Has Issues

This is basically fine, but I think there's one issue that 
isn't quite a nit:

1.3: "Typically, the other TS_TYPE would be of type 
TS_IPV4_ADDR_RANGE and/or TS_IPV6_ADDR_RANGE." That seems a
bit vague, and maybe less future proof than might be the
case, e.g. say if someone defines a new TS type for gold,
silver etc. service level that's also intended to be
combined with address TS's, I'm not sure it'd make sense to
combine this and that (putative) new service level TS with
no address type TS's and have things make sense. Maybe
better to say this TS MUST be combined with an address type
selector? (That statement might go in section 3.)

nits:

2.2: Typo? "(with deemed the Security Label optional)" 
s/with/which/ ?

2/3: I wasn't entirely clear what's meant by "optional" - it
doesn't seem to map to a protocol flag or simiilar but to
whether or not an implementation chooses to emit one of
these TS's - is that right? If so, it could maybe be
clearer.

3: the SHOULD level fallback to a new child SA without the
label seems a bit odd for a MAC system - is that really the
right choice? (I'll believe you if you say "yes," so just
asking in case this is an oversight:-)



___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] [lamps] New Liaison Statement, "LS on ITU-T SG17 work on quantum-safe PKI"

[Stephen Farrell]

Hiya,

On 03/10/17 21:38, Alexander Truskovsky wrote:
> This allows X.509 certificates to contain two (or more) public keys
> and issuer signatures.  The goal would be to ease the migration of
> PKI and dependent protocols to new digital signature algorithms.  The
> motivation was to make the X.509 more cryptographically agile and
> simplify the migration to quantum-safe algorithms, but it is
> algorithm agnostic.  The main benefit of this proposal is that
> current systems will be able to use these newer X.509 certificates as
> they do today without any modifications, while systems that were
> updated to support quantum-safe algorithms can also be updated to
> understand the newer X.509 format and use quantum-safe algorithm
> instead.

I don't believe the "without any modifications" claim. If that
were true, then the additional (hopefully) quantum-safe keys or
signatures would be mere chaff.

I do wonder though if it could be that the advent of a desire
for post-quantum signatures is the straw that breaks the X.509
camel's back. For example, with a view to making X.509-based
PKI evolution end up sufficiently more expensive compared to
displacing X.509 entirely. It'll be fun to see what happens
as things pan out.

One reason that that might be the case is that the

S.


> 
> We are working on a draft that mirrors the ITU-T’s work with a few
> partners and will publish it for review soon.
> 
> Alex
> 
> 
> On 2017-10-02, 9:58 PM, "IPsec on behalf of Santosh Chokhani"
> 
> wrote:
> 
> I am not sure I understand what is being said below.  The link to the
> PDF does not add to the message body.
> 
> If there is a concern about what signature algorithm is used for what
> type of subject key, X.509 already has that flexibility.
> 
> If there is a concern about using multiple signatures on an X.509 
> certificate, one can use the single signature algorithm identifier to
> define multiple algorithms, parameters, and signatures.
> 
> -Original Message- From: Spasm
> [mailto:spasm-boun...@ietf.org] On Behalf Of Liaison Statement 
> Management Tool Sent: Wednesday, September 13, 2017 11:25 AM To:
> David Waltermire ; Tero Kivinen 
> ; Russ Housley  Cc: Limited
> Additional Mechanisms for PKIX and SMIME Discussion List 
> ; Eric Rescorla ; Russ Housley 
> ; Tero Kivinen ; Scott
> Mansfield ; IP Security Maintenance and
> Extensions Discussion List ; Kathleen Moriarty 
> ; David Waltermire 
> ; itu-t-liai...@iab.org; 
> jean-paul.lema...@univ-paris-diderot.fr Subject: [lamps] New Liaison
> Statement, "LS on ITU-T SG17 work on quantum-safe PKI"
> 
> Title: LS on ITU-T SG17 work on quantum-safe PKI Submission Date:
> 2017-09-13 URL of the IETF Web page:
> https://datatracker.ietf.org/liaison/1541/
> 
> From: Jean-Paul Lemaire  To:
> David Waltermire ,Tero Kivinen 
> ,Russ Housley  Cc: David
> Waltermire ,IP Security Maintenance and 
> Extensions Discussion List
> ,itu-t-liai...@iab.org,Limited Additional Mechanisms
> for PKIX and SMIME Discussion List ,Russ Housley
> ,Scott Mansfield 
> ,Kathleen Moriarty 
> ,Tero Kivinen
> ,Eric Rescorla  Response Contacts: 
> jean-paul.lema...@univ-paris-diderot.fr Technical Contacts: Purpose:
> For information
> 
> Body: ITU-T Study Group 17 is pleased to inform you that in our 
> August/September 2017 meeting we agreed to start work on the
> inclusion of a proposal to include optional support for multiple
> public-key algorithms in Recommendation ITU-T X509 | ISO/IEC 9594-8.
> 
> The industry is preparing ICT systems to be resistant to attacks by 
> large-scale quantum computers in addition to more sophisticated
> attacks by conventional computing resources. Proposed was an optional
> feature to the X.509 certificate that provides a seamless migration
> capability to existing PKI systems, and is completely backwardly
> compatible with existing systems.
> 
> While public-key key establishment algorithms are typically
> negotiated between peers and are generally fairly simple to update,
> the authentication systems typically rely on a single digital
> signature algorithm which are more difficult to update. This is
> because of the circular dependency between PKI-based identity systems
> and the dependent communication protocols. In order to update a PKI
> system, one would typically need to create a duplicate PKI system
> that utilizes a new digital signature algorithm and then migrate all
> the 

[IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-rfc7321bis-05: (with COMMENT)

[Stephen Farrell]

Stephen Farrell 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 https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc7321bis/



--
COMMENT:
--


- I agree with Christian's secdir review [1] that this
doesn't seem justified (at least on it's face): " If
manual keying is used anyway, ENCR_AES_CBC MUST be used,
and ENCR_AES_CCM, ENCR_AES_GCM and ENCR_CHACHA20_POLY1305
MUST NOT be used as these algorithms require IKE.  " Can
you explain the reasoning that lead the WG to say that?

- ENCR_NULL IMO ought be MUST NOT - did the WG discuss
that explicitly?  If so, can you provide a pointer to the
archive?  If not, does it still have to be a MUST?  I do
wonder who wants to use AH via NAT but cannot, which seems
to be the justification.

[1] https://www.ietf.org/mail-archive/web/secdir/current/msg07262.html


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-rfc7321bis-05

[Stephen Farrell]

Stephen Farrell 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 https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc7321bis/


There are no remarks associated with this position.




___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-safecurves-05: (with COMMENT)

[Stephen Farrell]

On 13/10/16 13:27, Yoav Nir wrote:
> Hi, Stephen
> 
>> 
>> - Wouldn't it be good to encourage minimising re-use of public
>> values for multiple key exchanges? As-is, the text sort-of
>> encourages use for "many key exchanges" in section 4.
> 
> I don’t think so. 

Fair enough, though when I said "minimise" I didn't mean
"never re-use." But all you say below is correct, so not
that big a deal, but I do think it'd be better to explicitly
encourage implementers to roll their private values as
often as makes sense in their situation.

S.

> Re-use reduces the computation cost of an IKE
> Responder (or TLS server) without sacrificing security.  There was
> some discussion of this in CFRG, but I see that it didn’t make it
> into RFC 7748, so all I can find is some StackExchange question
> ([1]).
> 
> It does make the static keypair valuable. It is definitely not a good
> idea to store the private key on-disk and keep it forever, but
> generating a new key once in a while and discarding the old key is
> usually a good compromise there.
> 
> Anyway key-pair reuse is established practice. Using constant-time
> implementations is essential to making this practice safe, and the
> Security Considerations sections says just that.
> 
> Yoav
> 
> [1]
> http://crypto.stackexchange.com/questions/11012/reuse-of-a-dh-ecdh-public-key
>



smime.p7s
Description: S/MIME Cryptographic Signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-safecurves-05: (with COMMENT)

[Stephen Farrell]

Thanks Tero and sorry for forgetting:-)

Cheers,
S.

On 13/10/16 13:04, Tero Kivinen wrote:
> Stephen Farrell writes:
>> Stephen Farrell has entered the following ballot position for
>> draft-ietf-ipsecme-safecurves-05: Yes
>>
>> --
>> COMMENT:
>> --
>> - Sorry if I'm forgetting how we handle this in IPsec,
>> but is an implementation of this RFC expected to support
>> both curves? I think it'd be ok to say that 25519 is a
>> MUST for folks doing, this but that 448 is optional.  I'm
>> also fine if we mean that implementing this means you
>> have to support both btw but you don't say (here) that
>> that's the case.
> 
> In IPsec we do not specify any requirement levels in the actual
> algorithm documents. The algorithm documents just allocate the IANA
> numbers and specify how they algorithms are used.
> 
> Then we have separate documents (new versions soon to be in front of
> IESG) specifying the actual mandatory to implement algorithms.
> 
> Whether some implementation supports this new RFC is something that
> does not have well define answer, as people could say they implement
> this RFC if they support one or other, or both curves. Usually people
> are just saying they support algorithm RFC if they support one
> algorithm from there. I.e., vendors usually say they support RFC2451,
> even if they only support 3DES from there, and might not support
> CAST-128, RC5, IDEA and Blowfish.
> 
> Anyways the mandatory to implement ciphers are specified in the
> rfc4307bis [1] and rfc7321bis [2].
> 
> These curves are not mentioned there, so they are still going to be
> MAY. When we are going to update 4307bis again then we are most likely
> going to make them SHOULD+ or even MUST (if there is enough
> implementations actually implementing them at that point).
> 
> [1] https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc4307bis/
> [2] https://datatracker.ietf.org/doc/draft-mglt-ipsecme-rfc7321bis/
> 



smime.p7s
Description: S/MIME Cryptographic Signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-safecurves-05: (with COMMENT)

[Stephen Farrell]

Stephen Farrell has entered the following ballot position for
draft-ietf-ipsecme-safecurves-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 https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-safecurves/



--
COMMENT:
--


- Wouldn't it be good to encourage minimising re-use of
public values for multiple key exchanges? As-is, the text
sort-of encourages use for "many key exchanges" in
section 4.

- Sorry if I'm forgetting how we handle this in IPsec,
but is an implementation of this RFC expected to support
both curves? I think it'd be ok to say that 25519 is a
MUST for folks doing, this but that 448 is optional.  I'm
also fine if we mean that implementing this means you
have to support both btw but you don't say (here) that
that's the case.


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT)

[Stephen Farrell]

On 27/09/16 20:07, Valery Smyslov wrote:
> 
> The attacker can however gain some benefits if he/she waits some time
> until the half-open SA is expired on Responder and chooses the same SPI
> and nonce for the next connection request. He/she will receive the same
> puzzle
> if the Responder doesn't change value of secret yet. Note that RFC7296
> recommends
> changing secret frequently if under attack (RFC7296, Section 2.6):
> 
>   The responder should change the value of  frequently, especially
>   if under attack.
> 
> I think we can add some words to the draft that will recommend
> to generate cookie in such a manner, that the cookie is not repeated
> even if the same IP, SPI and nonce are used by Initiator.

Good one. Yeah I think it'd be fine to add that.

All the rest of your and Yoav's responses are good too.

Thanks,
S.



smime.p7s
Description: S/MIME Cryptographic Signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT)

[Stephen Farrell]

On 27/09/16 20:21, Yoav Nir wrote:
> Looking at the IPR statement you linked to, it does not seem relevant
> to me, but IANAL. The proof-of-work scheme described in the patent
> ([2]) involves setting a time limit for the client to complete the
> puzzle solution. The puzzle in our draft has a set difficulty level,
> but no time limit for the Initiator to solve it.

FWIW, that sounds reasonable to me. But I've given up pondering
what lawyers think about patents so folks can make up their own
minds;-)

S.



smime.p7s
Description: S/MIME Cryptographic Signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT)

[Stephen Farrell]

Stephen Farrell has entered the following ballot position for
draft-ietf-ipsecme-ddos-protection-09: 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 https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ddos-protection/



--
COMMENT:
--


This is a nicely written document... thanks!

- I vaguely recalled that puzzles and IPR rang a bell.  Did
the WG consider [1]? If not, and if it helps, I'm fine with
making a 3rd party declaration on that and last call could be
done again. Or maybe there's a better way to handle it. Or
maybe the WG considered it and are happy enough already that
it's not relevant or about to expire or abandoned or
something.  ("Not relevant" would puzzle me:-)

   [1] https://datatracker.ietf.org/ipr/417/

- section 3: "if certificates are involved" - you could note
here that involving certificates can introduce a network
based delay (OCSP, CRLs etc) that's a little different from
CPU consumption. (But it's a nit, and you do note a similar
issue in 4.7.)

- 4.2: "ratelimits should be done based on either the /48 or
/64" - would it be better to say "something between a /48 and
a /64" maybe? Don't some ISPs assign things in-between?

- 4.4: Did you consider making the "4 keys" requirement tied
to the PRF algorithm identifier? That would allow for a
future where e.g. 6 keys are needed for the same PRF, if that
were ever useful. (Without changing current implementations.)
I guess you'd need a separate IANA registry that'd initially
duplicate stuff in that case so maybe not worth doing. (And
could be done later.)

- 7.1.1 - you don't clearly say if the cookie value here can
be a new one or should be the same as one previously used (if
one was previously used). That may just be my ignorance of
IPsec cookies though, but I wondered if there are any cases
where the initiator gets to work away on the puzzle ahead of
time if the same cookie is used for multiple interactions.
There's not much (or zero) of an improvement to the attack
here, though maybe the attacker could more easily offload
puzzle solving to someone else in that case?


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Stephen Farrell's Yes on charter-ietf-ipsecme-10-00: (with COMMENT)

[Stephen Farrell]

On 30/08/16 19:55, Kathleen Moriarty wrote:
> I'll leave this text alone from the WG response, at least for now.
> Being able to work on it in months makes sense even if it isn't the
> best long term solution.

I'm ok with that. But note that my suggested wording is not meant
to commit the WG to waiting on CFRG, only to leave that call for
later.

S.



smime.p7s
Description: S/MIME Cryptographic Signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Stephen Farrell's Yes on charter-ietf-ipsecme-10-00: (with COMMENT)

[Stephen Farrell]

Stephen Farrell has entered the following ballot position for
charter-ietf-ipsecme-10-00: 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.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-ipsecme/



--
COMMENT:
--


There are some typos (s/MIT/MTI) and bits of English that
need to be tidied up.

I have a suggestion about this bit of work:

"IKEv1 using shared secret authentication was partially resistance to
quantum computers. IKEv2 removed this feature to make the protocol
more usable. The working group will add a mode to IKEv2 or otherwise
modify IKEv2 to have similar quantum resistant properties than IKEv1
had."

My suggestion is twofold:

1) - s/will add/will consider adding/

and to add to the end:

2) "In doing this work the WG will consider ongoing work on
quantum-resistance 
in the CFRG, and whether it is better to re-instate the same level of
resistance
that was present in IKEv1 or to wait for more recent work (e.g. in CFRG)
to 
mature."

The reason I suggest this is that it's possible the WG might conclude
that
it's better to wait for some newer QR stuff from CFRG. The current
wording
seems to commit the WG to firing ahead anyway, and we might overall be
better if there are fewer QR mechanisms proposed, rather than adding
some
now when it might be better to wait a while longer.


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-chacha20-poly1305-11: (with COMMENT)

[Stephen Farrell]

That change is really good thanks,
S

On 09/07/15 08:51, Yoav Nir wrote:
 So, how about replacing the first two paragraphs?
 
 OLD:
The Advanced Encryption Standard (AES - [FIPS-197]) has become the
gold standard in encryption.  Its efficient design, wide
implementation, and hardware support allow for high performance in
many areas, including IPsec VPNs.  On most modern platforms, AES is
anywhere from 4x to 10x as fast as the previous most-used cipher,
3-key Data Encryption Standard (3DES - [SP800-67]). 3DES also has a
64-bit block, which means that the amount of data that can be
encrypted before rekeying is required is not great.  These reasons
make AES not only the best choice, but the only choice.
 
The problem is that if future advances in cryptanalysis reveal a
weakness in AES, VPN users will be in an unenviable position.  With
the only other widely supported cipher being the much slower 3DES, it
is not feasible to re-configure IPsec installations away from AES.
[standby-cipher] describes this issue and the need for a standby
cipher in greater detail.
 
 NEW:
The Advanced Encryption Standard (AES - [FIPS-197]) has become the
go-to algorithm for encryption.  It is now the most commonly used 
algorithm in many areas, including IPsec virtual private networks
(VPN).  On most modern platforms AES is anywhere from 4x to 10x as 
fast as the previous popular cipher, 3-key Data Encryption Standard 
(3DES - [SP800-67]). 3DES also uses a 64-bit block, which means that 
the amount of data that can be encrypted before rekeying is required 
is limited. These reasons make AES not only the best choice, but the 
only viable choice for IPsec.

The problem is that if future advances in cryptanalysis reveal a
weakness in AES, VPN users will be in an unenviable position.  With
the only other widely supported cipher for IPsec implementations 
being the much slower 3DES, it is not feasible to re-configure IPsec 
installations away from AES. [standby-cipher] describes this issue 
and the need for a standby cipher in greater detail.
 
 
 Yoav
 

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-chacha20-poly1305-11: (with COMMENT)

[Stephen Farrell]

On 08/07/15 14:49, Paul Wouters wrote:
  Camellia is widely supported in
  browsers for example. So your text ought be fixed.
 Not in IKE or IPsec.

Then all that's needed is to qualify the only properly.
It's better to be accurate really I think.

S.

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-chacha20-poly1305-11: (with COMMENT)

[Stephen Farrell]

Hiya,

On 08/07/15 06:36, Yoav Nir wrote:
 Hi, Stephen.
 
 See below.
 
 On Jul 8, 2015, at 2:15 AM, Stephen Farrell
 stephen.farr...@cs.tcd.ie wrote:
 
 
 --

 
COMMENT:
 --



 
intro: gold standard is being a bit too keen IMO, I'd say
 toning the language down a bit would be better.
 
 AES is what I get when I’m using IPsec, TLS (at least in browsers and
 SMTP) and SSH with normal tools. It’s what disk encryption schemes
 use and what S/Mime uses. Even the DICE profile names AES as the MTI
 algorithm. Same for the current TLS 1.3 draft and HTTP/2 RFC. When
 Intel was looking to add a cryptographic algorithm to the
 general-purpose CPUs, they chose AES. IBM did the same with mainframe
 CPUs. Any paper describing a new algorithm compares the new
 algorithms to AES. Even here at the IETF we tend to call anything
 else “vanity crypto”. I think “gold standard” is appropriate. I guess
 I could rephrase it as “has become the go-to algorithm for
 encryption”, although that might be too American an idiom.

I like your suggestion to Ben, with two tweaks:

1) s/has become the go-to/is by far the most commonly used/
2) s/but the only choice// - only is factually incorrect,
   I could live with only choice that achieves broad
   interoperability

 
 intro: 3DES may be the only other widely supported cipher for
 IPsec, but that's not true more generally.
 
 Well, this is a document about IPsec. It’s also true for TLS and SSH.
 There’s also the occasional Blowfish and Camelia, but 3DES is more
 common than any of them. There is RC4 and it’s fast, but (1) you
 can’t use that in IPsec, and (2) you don’t want to use that in TLS
 and SSH anyway.

The problem is the word only - that is simply not true in general.
I'm not sure if it's true for VPNs. Camellia is widely supported in
browsers for example. So your text ought be fixed.

 
 section 2 says: As the ChaCha20 block function is not applied 
 directly to the plaintext, no padding should be necessary. That
 should could be confusing as written if a reader thinks it means
 their code doesn't have to do padding. It might be better to e.g.
 say something like In theory no padding is needed for this cipher,
 however, in keeping with…
 
 I take the point, but I don’t like using “in theory”. How about: As
 the ChaCha20 block function is not applied directly to the plaintext,
 the algorithm does not require any padding. However,

Yep, that's good.

 
 section 3: Is SHOULD inlude no padding really right?  I'd have
 thought a MAY was better there.  MUST accept any length is also a
 bit odd - what if I (try:-) add loads of padding?
 
 This pretty much follows the text in RFC 7296: o  Pad Length is the
 length of the Padding field.  The sender SHOULD set the Pad Length to
 the minimum value that makes the combination of the payloads, the
 Padding, and the Pad Length a multiple of the block size, but the
 recipient MUST accept any length that results in proper alignment.
 This field is encrypted with the negotiated cipher. Since there is no
 proper alignment requirements for this algorithm, I take that to mean
 “no padding” but “MUST accept any length”. It’s true that with a
 single-octet byte length you can’t insert more than 255 octets of
 padding, but I don’t thin this has to be spelled out.

Ah fair enough, your text is correct so.

 
 Appendices: thanks for those - I assume someone checked them for
 you? (I didn't:-)
 
 Martin Willi (implementer of StrongSwan) did, and pointed out a
 mistake in a previous version.

Thanks to you both!

Cheers,
S.


 
 Yoav
 

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-chacha20-poly1305-11: (with COMMENT)

[Stephen Farrell]

Stephen Farrell has entered the following ballot position for
draft-ietf-ipsecme-chacha20-poly1305-11: 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 https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-poly1305/



--
COMMENT:
--


intro: gold standard is being a bit too keen IMO, I'd say
toning the language down a bit would be better.

intro: 3DES may be the only other widely supported cipher
for IPsec, but that's not true more generally.

section 2 says: As the ChaCha20 block function is not applied
directly to the plaintext, no padding should be necessary.
That should could be confusing as written if a reader thinks
it means their code doesn't have to do padding. It might be
better to e.g. say something like In theory no padding is
needed for this cipher, however, in keeping with... 

section 3: Is SHOULD inlude no padding really right?  I'd
have thought a MAY was better there.  MUST accept any length
is also a bit odd - what if I (try:-) add loads of padding?

Appendices: thanks for those - I assume someone checked them
for you? (I didn't:-)


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] [Editorial Errata Reported] RFC7296 (4387)

[Stephen Farrell]

Done
S

On 04/06/15 14:40, Paul Hoffman wrote:
 Please accept this erratum and mark it has Held for document update.
 
 --Paul Hoffman
 
 On Jun 4, 2015, at 5:08 AM, RFC Errata System rfc-edi...@rfc-editor.org 
 wrote:

 The following errata report has been submitted for RFC7296,
 Internet Key Exchange Protocol Version 2 (IKEv2).

 --
 You may review the report below and at:
 http://www.rfc-editor.org/errata_search.php?rfc=7296eid=4387

 --
 Type: Editorial
 Reported by: Yoav Nir ynir.i...@gmail.com

 Section: 3.7

 Original Text
 -
   The Certificate Request payload, denoted CERTREQ in this document,
   provides a means to request preferred certificates via IKE and can
   appear in the IKE_INIT_SA response and/or the IKE_AUTH request.
   Certificate Request payloads MAY be included in an exchange when the
   sender needs to get the certificate of the receiver.

 Corrected Text
 --
   The Certificate Request payload, denoted CERTREQ in this document,
   provides a means to request preferred certificates via IKE and can
   appear in the IKE_SA_INIT response and/or the IKE_AUTH request.
   Certificate Request payloads MAY be included in an exchange when the
   sender needs to get the certificate of the receiver.

 Notes
 -
 IKE_SA_INIT is mis-spelled as IKE_INIT_SA this one time.

 Instructions:
 -
 This erratum is currently posted as Reported. If necessary, please
 use Reply All to discuss whether it should be verified or
 rejected. When a decision is reached, the verifying party (IESG)
 can log in to change the status and edit the report, if necessary. 

 --
 RFC7296 (draft-kivinen-ipsecme-ikev2-rfc5996bis-04)
 --
 Title   : Internet Key Exchange Protocol Version 2 (IKEv2)
 Publication Date: October 2014
 Author(s)   : C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, T. Kivinen
 Category: INTERNET STANDARD
 Source  : IP Security Maintenance and Extensions
 Area: Security
 Stream  : IETF
 Verifying Party : IESG

 

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-ikev2-null-auth-06: (with COMMENT)

[stephen . farrell]

On Sun May 31 16:57:43 2015 GMT+0100, Paul Wouters wrote:
 On Wed, 27 May 2015, Stephen Farrell wrote:
 
  - 2.5: hand out is an odd phrase here - would be better
  to expand on that I think and say more precisely what
  should never be done.
 
 How about:

Yep that's better.
Ta
S

 
 OLD:
 
 A rogue IKE peer could use malicious Traffic Selectors to obtain
 access to traffic that the host never intended to hand out.
 
 NEW:
 
 A rogue IKE peer could use malicious Traffic Selectors to trick
 a remote host into giving it IP traffc that the remote host never
 intended to be send to remote IKE peers. For example, if the remote
 host uses 192.0.2.1 as DNS server, a rogue IKE peer could set its
 Traffic Selector to 192.0.2.1 in an attempt to receive the remote
 peer's DNS traffic.
 
 Paul
 

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-ikev2-null-auth-06: (with COMMENT)

[Stephen Farrell]

Stephen Farrell has entered the following ballot position for
draft-ietf-ipsecme-ikev2-null-auth-06: 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 https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-null-auth/



--
COMMENT:
--


- 2.1: just wanted to check as I didn't have time to go
through it all myself - are we confident that using
SK_pi/SK_pr in this way has no cryptographic downsides? The
reference to the EAP methods convinces me this is no worse
than an existing thing, but not (by itself) that it is
cryptographically sound, so I just wanted to check as I
think prf(SK_pr,IDr') has until now been calculated but not
transmitted, so there's a tiny change here maybe, but as I
said I didn't have time to fully check. If someone just
tells me that yes, the authors/wg did consider this, that'll
be fine, no need to fully explain to me why using SK_pr like
this is safe (though if you want to, that'd be fine too).

- 2.5: hand out is an odd phrase here - would be better
to expand on that I think and say more precisely what
should never be done.


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Fwd: HOKEY draft draft-ietf-hokey-rfc5296bis

[Stephen Farrell]

In case anyone wonders, my reply to Yaron was basically:
I dunno  will be interested to find out if you're
missing something or not

S.

On 08/03/11 07:35, Yaron Sheffer wrote:
 Hi Glen,
 
 thank you for your kind words. It is always a pleasure to help a fellow
 security working group, and your positive and helpful feedback makes it
 doubly so.
 
 Back to the subject at hand: EAP is one of the rare security protocols
 that are truly reusable. And in fact it is used by multiple protocols,
 including 802.1X, IKE and the TNC protocols. With success comes
 responsibility. If your working group makes significant, architectural
 changes to the protocol, it is *your responsibility* to ensure they can
 be accommodated by users of the protocol. And in the case of IETF
 working groups, it is indeed the job of the Security AD to ensure such
 coordination takes place.
 
 ERP is such a major change because (correct me if I am wrong):
 
 - Its transport behavior is different from the base EAP, allowing
 multiple exchanges to be in flight at the same time.
 - ERP peers actually *degrade* the behavior of EAP, because of
 timeouts/retransmissions introduced when talking to non-ERP auth
 servers, and similarly for ERP auth servers with non-ERP peers (this
 behavior is spelled out quite clearly on p. 8 of the bis draft).
 
 PS: I'm glad to hear that 802.1X-2010 supports ERP. I just wonder why
 the bis draft does not recognize this fact.
 
 Best regards,
 
 Yaron
 
 On 03/08/2011 06:51 AM, Glen Zorn wrote:
 On 3/6/2011 4:43 PM, Yaron Sheffer wrote:
 Hi Stephen,

 I gather you are the incoming responsible AD for HOKEY.

 ERP (RFC 5296, now reincarnated as a bis document) is one of HOKEY's
 principal work items. The document is making major changes to EAP, and
 seems to have gotten a life of its own, despite the fact that AFAIU
 neither of its protocol users (802.1X and IKEv2) has been changed to
 accommodate it. It seems to me at best like wasted effort, more likely a
 disconnect between the working groups.


 First of all, I'd like to express my deep appreciation ( I think that I
 can speak for all the members of the hokey WG) for you kind concern for
 the use of our time. It is especially wonderful since AFAIK you have
 heretofore shown no interest at all in our activities; to extend
 yourself in this way for a group with which you have essentially no
 connection is truly magnanimous; and to go straight to the Area
 Director, the one person who might be able to save us from this terrible
 waste of effort  time! I must say that I find it hard to express in
 words how it makes me feel. Nonetheless, I admit to some puzzlement as
 to the rationale for this action: the referenced draft is a chartered
 work item of the hokey WG, adopted after a call for consensus from the
 members. Of course, you could not know about the call since you aren't a
 WG member but it did occur. So while I do appreciate your obviously deep
 and selfless concern, I am inclined to let the actual members of the WG
 decide what (if anything) they deem worthy of effort. But, thanks again!

 P.S.
 I'm pretty sure that IEEE 802.1X-2010 supports ERP.


 Am I missing anything?

 Thanks,
 Yaron

  Original Message 
 Subject: [IPsec] HOKEY draft draft-ietf-hokey-rfc5296bis
 Date: Sun, 6 Mar 2011 11:25:54 +0200
 From: Yoav Nir y...@checkpoint.com
 To: ipsec@ietf.org ipsec@ietf.org,
 draft-ietf-hokey-rfc5296...@tools.ietf.org
 draft-ietf-hokey-rfc5296...@tools.ietf.org

 Hi all

 I have just read the subject draft, and found this in section 6 (and
 similar text in the introduction):

 Note that to support ERP, lower-layer specifications may need to be
 revised. Specifically, the IEEE802.1x specification must be revised
 to allow carrying EAP messages of the new codes defined in this
 document in order to support ERP. Similarly, RFC 4306 must be
 updated to include EAP code values higher than 4 in order to use ERP
 with Internet Key Exchange Protocol version 2 (IKEv2). IKEv2 may
 also be updated to support peer-initiated ERP for optimized
 operation. Other lower layers may need similar revisions.

 Note that this is not new text, and it appears pretty much the same way
 in RFC 5296.

 There's the obvious nit with this text, that RFC 4306 is not a
 reference. If it was, the id-nits would warn about this RFC being
 obsolete. But that's the small problem here.

 A bigger problem is that this text says that IKEv2 needs to be updated,
 but there is no draft for this update, nor has there been any message to
 this list about this proposed change.

 The simple change they require is to section 3.16:
 o Code (1 octet) indicates whether this message is a Request (1),
 Response (2), Success (3), or Failure (4).

 I think this could be done with an errata or a 1-page draft, if all that
 was required was pass-through of codes (5) and (6). But I think it's
 more involved than that.

 There's peer-initiated ERP (which would require peer-initiated IKE?) and