Re: [IPsec] Comments on draft-mglt-ipsecme-implicit-iv-02.tx

[Daniel Migault]

S 2.

>This document does not consider AES-CBC ([RFC3602])as AES-CBC
>>requires the IV to be unpredictable.  Deriving it directly from the
>>packet counter as described below is insecure.
>>
>> Can you provide a cite for this?
>>
>>
>> Even RFC 3602 requires that the IV be randomly generated (and for good
>> measure requires that it be unpredictable)
>>
>
> That's just a cite to a requirement, not to it being insecure. Do you have
> a citation to the relevant threat?
>

Predictable IV can be exploited by chosen plain text attacks. RFC3602 cites
[CRYPTO-B] in teh sceurity consideration section:
"""

For more information regarding the necessary use of random IV values,
see [CRYPTO-B ].

"""
with :

[CRYPTO-B]   Bellovin, S., "Probable Plaintext Cryptanalysis of the
 IP Security Protocols", Proceedings of the Symposium on
 Network and Distributed System Security, San Diego, CA,
 pp. 155-160, February 1997.
 http://www.research.att.com/~smb/papers/probtxt.pdf

This links works:
https://www.cs.columbia.edu/~smb/papers/probtxt.pdf
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Comments on draft-mglt-ipsecme-implicit-iv-02.tx

[Yoav Nir]

> On 19 Mar 2017, at 19:30, Eric Rescorla  wrote:
> 
> 
> 
> On Sun, Mar 19, 2017 at 10:23 AM, Yoav Nir  > wrote:
> 
>> On 19 Mar 2017, at 16:55, Eric Rescorla > > wrote:
>> 
>> Overall:
>> I notice that you are using a construction different from that used
>> in TLS 1.3, which doesn't directly repeat nonces across associations.
> 
> I didn't see an answer to this.

Nonces are specified as 64-bit IV (usually counter and we are forcing it to be 
a counter) plus 32-bit salt in RFC 4106.  We saw no reason to change that.

>> 
>> S 2.
>>This document does not consider AES-CBC ([RFC3602])as AES-CBC
>>requires the IV to be unpredictable.  Deriving it directly from the
>>packet counter as described below is insecure.
>> 
>> Can you provide a cite for this?
> 
> Even RFC 3602 requires that the IV be randomly generated (and for good 
> measure requires that it be unpredictable)
> 
> That's just a cite to a requirement, not to it being insecure. Do you have a 
> citation to the relevant threat?

We could cite BEAST. Of course BEAST depends on HTTPS, so it’s not really 
applicable - it’s harder to manipulate the first 16 bytes of the IP header - 
but these have been the recommendations for using CBC in both RFCs and NIST 
documentations for years before BEAST.

> 
>> In any case, note that there are
>> straightforward algorithms for deriving a CBC IV from a counter
>> (e.g., run AES in counter mode with a different key). That structure
>> would actually be suitable for GCM as well (and would address
>> my point above).
> 
> If each implementation generates a random key and uses this to generate the 
> IVs this is fine, but you still have to transmit the IV.  If we derive an “IV 
> key” from the keying material, then we don’t have to transmit the IV.
> 
> You generate the IV from the sequence number, so you don't need to transmit 
> the IV.
> That gives you an unpredictable IV without the per-packet overhead.
> 
> 
> We did bring this idea up at a WG meeting. This was not well-received for 
> three reasons: (1) it’s unnecessarily complicated. (2) The world is going to 
> AEAD. AES-CBC is the past, and (3) The perception was that saving 8 bytes per 
> packet was important mostly for IoT, and they don’t care about CBC.
> 
> Sure, that's reasonable. I'm merely observing that there are designs which 
> work for CBC.
> 
> 
>> S 3.
>>o  IV: Initialization Vector.  Although security requirements vary,
>>   the common usage of this term implies that the value is
>>   unpredictable.
>> 
>> I don't think that this is true at all. I've frequently heard of a
>> zero IV. It's also odd in that your IV is in fact predictable.
>> 
>> 
>> S 5.
>> I'm a bit surprised that you are deciding to have duplicate
>> code points for every algorithm rather than some sort of IKE
>> negotiation payload. I see that the WG is currently defining
>> other extensions where you take that approach.
> 
> See slide #7 of 
> https://www.ietf.org/proceedings/96/slides/slides-96-ipsecme-0.pdf 
> 
> 
> The problem is that IKEv2 has strict rules about unexpected attributes in the 
> substructures of the SA payload. The sense of the room was to go with new 
> identifiers.
> 
> OK. Well, I agree it's ultimately a WG decision, but it doesn't seem very 
> elegant.

I was in the rough on this at first, but it was shown that every alternate 
negotiation mechanism had unwanted consequences.

Yoav



signature.asc
Description: Message signed with OpenPGP
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Comments on draft-ietf-ipsecme-tcp-encaps

[Eric Rescorla]

Thanks for the explanation...

-Ekr


On Sun, Mar 19, 2017 at 11:45 AM, Tommy Pauly  wrote:

> Some servers may support that, but some may not. These sessions are often
> used for VPN access, and we've seen cases in which a particular
> user/certificate combination is only allowed to be connected
> once-at-a-time. That makes switching more complicated. Also, since the
> recommendation is to try sending the UDP first packet at least twice, the
> amount of time required for the user to wait before the fallback would kick
> in is only on the order of a few RTT.
>
> I think if these session were more likely to be used for user-interactive,
> short-lived connections, I'd see more value in a nuanced racing algorithm.
> However, we often see IKE brought up in the background and stay associated
> for a very long time, making the protocol that wins the race more
> important, and the time to wait to establish slightly less important.
>
> Thanks,
> Tommy
>
> > On Mar 19, 2017, at 11:40 AM, Eric Rescorla  wrote:
> >
> > I haven't fully thought this through, but if yu can switch-hit between
> TCP
> > and UDP,
> > why can't you just race the setup between TCP and UDP and then if you
> start
> > getting packets on UDP, cut over to that.
> >
> > Maybe I'm just too influenced by ICE :)
> >
> > -Ekr
> >
> >
> > On Sun, Mar 19, 2017 at 11:25 AM, Tommy Pauly  wrote:
> >
> >>
> >> On Mar 19, 2017, at 6:47 AM, Eric Rescorla  wrote:
> >>
> >>
> >>
> >> On Sat, Mar 18, 2017 at 11:29 PM, Yoav Nir  wrote:
> >>
> >>> Hi, Eric.
> >>>
> >>> On 19 Mar 2017, at 4:04, Eric Rescorla  wrote:
> >>>
> >>> [Now with the right address]
> >>>
> >>> I just finished reading this document. Some comments below.
> >>>
> >>>
> >>> - You have a uniform 16 bit length field followed by a 4 byte all-zeros
> >>>   sentinel value to indicate that a packet is IKE rather than ESP.
> >>>   Given that in S 3 graf 2 you have a SHOULD-level requirement
> >>>   to use typical UDP payload lengths, why not instead explicitly
> >>>   limit lengths to 15 bits and use the top bit to indicate IKE versus
> >>>   ESP. This would be slightly more efficient and seems simpler.
> >>>   I suppose that the counterargument is that IKE over UDP behaves
> >>>   differently, but in terms of implementation, that doesn't seem like
> >>>  much of an argument.
> >>>
> >>>
> >>> Another counter-argument is that we sometimes need the entire
> theoretical
> >>> length of a UDP packet. The IKE_AUTH messages typically carry a
> certificate
> >>> chain and sometimes even a CRL. And there is no way to split a
> certificate
> >>> chain over several messages. With remote access VPN you also get a CFG
> >>> payload with configuration information that can also encode an
> unbounded
> >>> amount of data. So I would not want to constrain the certificate chains
> >>> that we are able to send any more than the IP packet length already
> does
>
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Comments on draft-ietf-ipsecme-tcp-encaps

[Tommy Pauly]

Some servers may support that, but some may not. These sessions are often used 
for VPN access, and we've seen cases in which a particular user/certificate 
combination is only allowed to be connected once-at-a-time. That makes 
switching more complicated. Also, since the recommendation is to try sending 
the UDP first packet at least twice, the amount of time required for the user 
to wait before the fallback would kick in is only on the order of a few RTT.

I think if these session were more likely to be used for user-interactive, 
short-lived connections, I'd see more value in a nuanced racing algorithm. 
However, we often see IKE brought up in the background and stay associated for 
a very long time, making the protocol that wins the race more important, and 
the time to wait to establish slightly less important.

Thanks,
Tommy

> On Mar 19, 2017, at 11:40 AM, Eric Rescorla  wrote:
> 
> I haven't fully thought this through, but if yu can switch-hit between TCP
> and UDP,
> why can't you just race the setup between TCP and UDP and then if you start
> getting packets on UDP, cut over to that.
> 
> Maybe I'm just too influenced by ICE :)
> 
> -Ekr
> 
> 
> On Sun, Mar 19, 2017 at 11:25 AM, Tommy Pauly  wrote:
> 
>> 
>> On Mar 19, 2017, at 6:47 AM, Eric Rescorla  wrote:
>> 
>> 
>> 
>> On Sat, Mar 18, 2017 at 11:29 PM, Yoav Nir  wrote:
>> 
>>> Hi, Eric.
>>> 
>>> On 19 Mar 2017, at 4:04, Eric Rescorla  wrote:
>>> 
>>> [Now with the right address]
>>> 
>>> I just finished reading this document. Some comments below.
>>> 
>>> 
>>> - You have a uniform 16 bit length field followed by a 4 byte all-zeros
>>>   sentinel value to indicate that a packet is IKE rather than ESP.
>>>   Given that in S 3 graf 2 you have a SHOULD-level requirement
>>>   to use typical UDP payload lengths, why not instead explicitly
>>>   limit lengths to 15 bits and use the top bit to indicate IKE versus
>>>   ESP. This would be slightly more efficient and seems simpler.
>>>   I suppose that the counterargument is that IKE over UDP behaves
>>>   differently, but in terms of implementation, that doesn't seem like
>>>  much of an argument.
>>> 
>>> 
>>> Another counter-argument is that we sometimes need the entire theoretical
>>> length of a UDP packet. The IKE_AUTH messages typically carry a certificate
>>> chain and sometimes even a CRL. And there is no way to split a certificate
>>> chain over several messages. With remote access VPN you also get a CFG
>>> payload with configuration information that can also encode an unbounded
>>> amount of data. So I would not want to constrain the certificate chains
>>> that we are able to send any more than the IP packet length already does

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

Re: [IPsec] Comments on draft-ietf-ipsecme-tcp-encaps

[Eric Rescorla]

I haven't fully thought this through, but if yu can switch-hit between TCP
and UDP,
why can't you just race the setup between TCP and UDP and then if you start
getting packets on UDP, cut over to that.

Maybe I'm just too influenced by ICE :)

-Ekr


On Sun, Mar 19, 2017 at 11:25 AM, Tommy Pauly  wrote:

>
> On Mar 19, 2017, at 6:47 AM, Eric Rescorla  wrote:
>
>
>
> On Sat, Mar 18, 2017 at 11:29 PM, Yoav Nir  wrote:
>
>> Hi, Eric.
>>
>> On 19 Mar 2017, at 4:04, Eric Rescorla  wrote:
>>
>> [Now with the right address]
>>
>> I just finished reading this document. Some comments below.
>>
>>
>> - You have a uniform 16 bit length field followed by a 4 byte all-zeros
>>sentinel value to indicate that a packet is IKE rather than ESP.
>>Given that in S 3 graf 2 you have a SHOULD-level requirement
>>to use typical UDP payload lengths, why not instead explicitly
>>limit lengths to 15 bits and use the top bit to indicate IKE versus
>>ESP. This would be slightly more efficient and seems simpler.
>>I suppose that the counterargument is that IKE over UDP behaves
>>differently, but in terms of implementation, that doesn't seem like
>>   much of an argument.
>>
>>
>> Another counter-argument is that we sometimes need the entire theoretical
>> length of a UDP packet. The IKE_AUTH messages typically carry a certificate
>> chain and sometimes even a CRL. And there is no way to split a certificate
>> chain over several messages. With remote access VPN you also get a CFG
>> payload with configuration information that can also encode an unbounded
>> amount of data. So I would not want to constrain the certificate chains
>> that we are able to send any more than the IP packet length already does.
>>
>
> OK.
>
>
>
> Early on there was a proposal to increase the length field to 4 bytes to
>> do away with these IKE limitations, but that was rejected.
>>
>> - If you're going to have a framing disambiguator, why not choose
>>   one that has higher entropy. If there is a protocol with a random
>>   start, then you are going to get some collisions with 2^48 bits.
>>
>>
>> I don’t think anyone plans to implement this on any port other than 443.
>> And on that port we’re worrying about exactly one protocol and it doesn’t
>> start with “IKETCP"
>>
>
> Fair enough.
>
>
>> - It seems like IKE associations can span TCP connections (S 6)
>>   so why not instead of doing UDP first then TCP, do happy eyeballs.
>>
>>
>> I don’t think it’s necessary to prescribe for or against this, but that
>> is what we do, and I think that is what Apple intends to do.
>>
>
> Right, but the text here actively discourages this.
> https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-09#section-5.1
>
> "   to reduce connection setup delays. It is recommended that theinitial
> message over UDP is retransmitted at least once before falling back to TCP,
> unless the Initiator knows beforehand that the   network is likely to block
> UDP."
>
>
> There's a tradeoff here between the Happy Eyeballs approach and the
> long-term benefits of choosing one option. I'm definitely a big proponent
> of Happy Eyeballs between address families, interfaces, and protocol
> options in general. However, these IKE connections will often be long-lived
> and tunnel a large amount of traffic used for many different applications.
> Since we view tunneling over UDP as so much preferable to tunneling over
> TCP, we want to weight the race more heavily in UDP's favor. The draft does
> not specifically say that attempts over UDP are ceased once the TCP attempt
> has begun, so there is room to keep 'racing' at this point. The main point
> we wanted to get across is that UDP should be given a fair shot, since it
> should be the preference.
>
> Note that a Happy Eyeballs approach should always have one option be
> attempted first anyhow, since simultaneous racing just adds extra load to
> the network and servers.
>
> Thanks,
> Tommy
>
>
> " when TLS is used on the TCP connection, both the TCP Originator and TCP
>> Responder SHOULD allow the NULL cipher to be selected for performance
>> reasons."
>>
>> This seems like you are going to have some problems with TLS 1.3
>>
>> - If you are going to use TLS, shouldn't you be using ALPN?
>>
>>
>> The idea of using TLS (rather than just IKE on port 443) is to get past
>> firewalls and IDP that examine the TCP traffic to determine that it “really
>> looks like HTTPS”. There was some discussion about whether this was a good
>> idea or whether we should in such a case either give up or standardize some
>> kind of SSL-VPN. There was no consensus to go with SSL-VPN in either this
>> group or any other (there was a bar bof a few IETFs ago)
>>
>
> OK. You're still going to have a problem with 1.3...
>
> -Ekr
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
>
>

Re: [IPsec] Comments on draft-ietf-ipsecme-tcp-encaps

[Tommy Pauly]

> On Mar 19, 2017, at 6:47 AM, Eric Rescorla  wrote:
> 
> 
> 
> On Sat, Mar 18, 2017 at 11:29 PM, Yoav Nir  > wrote:
> Hi, Eric.
> 
>> On 19 Mar 2017, at 4:04, Eric Rescorla > > wrote:
>> 
>> [Now with the right address]
>> 
>> I just finished reading this document. Some comments below.
>> 
>> 
>> - You have a uniform 16 bit length field followed by a 4 byte all-zeros
>>sentinel value to indicate that a packet is IKE rather than ESP.
>>Given that in S 3 graf 2 you have a SHOULD-level requirement
>>to use typical UDP payload lengths, why not instead explicitly
>>limit lengths to 15 bits and use the top bit to indicate IKE versus
>>ESP. This would be slightly more efficient and seems simpler.
>>I suppose that the counterargument is that IKE over UDP behaves
>>differently, but in terms of implementation, that doesn't seem like
>>   much of an argument.
> 
> Another counter-argument is that we sometimes need the entire theoretical 
> length of a UDP packet. The IKE_AUTH messages typically carry a certificate 
> chain and sometimes even a CRL. And there is no way to split a certificate 
> chain over several messages. With remote access VPN you also get a CFG 
> payload with configuration information that can also encode an unbounded 
> amount of data. So I would not want to constrain the certificate chains that 
> we are able to send any more than the IP packet length already does.
> 
> OK.
> 
> 
> 
> Early on there was a proposal to increase the length field to 4 bytes to do 
> away with these IKE limitations, but that was rejected.
> 
>> - If you're going to have a framing disambiguator, why not choose
>>   one that has higher entropy. If there is a protocol with a random
>>   start, then you are going to get some collisions with 2^48 bits.
> 
> I don’t think anyone plans to implement this on any port other than 443. And 
> on that port we’re worrying about exactly one protocol and it doesn’t start 
> with “IKETCP"
> 
> Fair enough.
>  
>> - It seems like IKE associations can span TCP connections (S 6)
>>   so why not instead of doing UDP first then TCP, do happy eyeballs.
> 
> I don’t think it’s necessary to prescribe for or against this, but that is 
> what we do, and I think that is what Apple intends to do.
> 
> Right, but the text here actively discourages this.
> https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-09#section-5.1 
>  
> 
> "   to reduce connection setup delays. It is recommended that theinitial 
> message over UDP is retransmitted at least once before falling back to TCP, 
> unless the Initiator knows beforehand that the   network is likely to block 
> UDP."

There's a tradeoff here between the Happy Eyeballs approach and the long-term 
benefits of choosing one option. I'm definitely a big proponent of Happy 
Eyeballs between address families, interfaces, and protocol options in general. 
However, these IKE connections will often be long-lived and tunnel a large 
amount of traffic used for many different applications. Since we view tunneling 
over UDP as so much preferable to tunneling over TCP, we want to weight the 
race more heavily in UDP's favor. The draft does not specifically say that 
attempts over UDP are ceased once the TCP attempt has begun, so there is room 
to keep 'racing' at this point. The main point we wanted to get across is that 
UDP should be given a fair shot, since it should be the preference.

Note that a Happy Eyeballs approach should always have one option be attempted 
first anyhow, since simultaneous racing just adds extra load to the network and 
servers.

Thanks,
Tommy
> 
>> " when TLS is used on the TCP connection, both the TCP Originator and TCP 
>> Responder SHOULD allow the NULL cipher to be selected for performance 
>> reasons."
>> 
>> This seems like you are going to have some problems with TLS 1.3
>> 
>> - If you are going to use TLS, shouldn't you be using ALPN?
> 
> The idea of using TLS (rather than just IKE on port 443) is to get past 
> firewalls and IDP that examine the TCP traffic to determine that it “really 
> looks like HTTPS”. There was some discussion about whether this was a good 
> idea or whether we should in such a case either give up or standardize some 
> kind of SSL-VPN. There was no consensus to go with SSL-VPN in either this 
> group or any other (there was a bar bof a few IETFs ago)
> 
> OK. You're still going to have a problem with 1.3...
> 
> -Ekr
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

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

Re: [IPsec] Comments on draft-mglt-ipsecme-implicit-iv-02.tx

[Eric Rescorla]

On Sun, Mar 19, 2017 at 10:23 AM, Yoav Nir  wrote:

>
> On 19 Mar 2017, at 16:55, Eric Rescorla  wrote:
>
> Overall:
> I notice that you are using a construction different from that used
> in TLS 1.3, which doesn't directly repeat nonces across associations.
>
> I didn't see an answer to this.


>
> S 2.
>This document does not consider AES-CBC ([RFC3602])as AES-CBC
>requires the IV to be unpredictable.  Deriving it directly from the
>packet counter as described below is insecure.
>
> Can you provide a cite for this?
>
>
> Even RFC 3602 requires that the IV be randomly generated (and for good
> measure requires that it be unpredictable)
>

That's just a cite to a requirement, not to it being insecure. Do you have
a citation to the relevant threat?


> In any case, note that there are
> straightforward algorithms for deriving a CBC IV from a counter
> (e.g., run AES in counter mode with a different key). That structure
> would actually be suitable for GCM as well (and would address
> my point above).
>
>
> If each implementation generates a random key and uses this to generate
> the IVs this is fine, but you still have to transmit the IV.  If we derive
> an “IV key” from the keying material, then we don’t have to transmit the
> IV.
>

You generate the IV from the sequence number, so you don't need to transmit
the IV.
That gives you an unpredictable IV without the per-packet overhead.


We did bring this idea up at a WG meeting. This was not well-received for
> three reasons: (1) it’s unnecessarily complicated. (2) The world is going
> to AEAD. AES-CBC is the past, and (3) The perception was that saving 8
> bytes per packet was important mostly for IoT, and they don’t care about
> CBC.
>

Sure, that's reasonable. I'm merely observing that there are designs which
work for CBC.


S 3.
>o  IV: Initialization Vector.  Although security requirements vary,
>   the common usage of this term implies that the value is
>   unpredictable.
>
> I don't think that this is true at all. I've frequently heard of a
> zero IV. It's also odd in that your IV is in fact predictable.
>
>
> S 5.
> I'm a bit surprised that you are deciding to have duplicate
> code points for every algorithm rather than some sort of IKE
> negotiation payload. I see that the WG is currently defining
> other extensions where you take that approach.
>
>
> See slide #7 of https://www.ietf.org/proceedings/96/slides/slides-
> 96-ipsecme-0.pdf
>
> The problem is that IKEv2 has strict rules about unexpected attributes in
> the substructures of the SA payload. The sense of the room was to go with
> new identifiers.
>

OK. Well, I agree it's ultimately a WG decision, but it doesn't seem very
elegant.

-Ekr


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

Re: [IPsec] Comments on draft-mglt-ipsecme-implicit-iv-02.tx

[Yoav Nir]

> On 19 Mar 2017, at 16:55, Eric Rescorla  wrote:
> 
> Overall:
> I notice that you are using a construction different from that used
> in TLS 1.3, which doesn't directly repeat nonces across associations.
> 
> S 2.
>This document does not consider AES-CBC ([RFC3602])as AES-CBC
>requires the IV to be unpredictable.  Deriving it directly from the
>packet counter as described below is insecure.
> 
> Can you provide a cite for this?

Even RFC 3602 requires that the IV be randomly generated (and for good measure 
requires that it be unpredictable)

> In any case, note that there are
> straightforward algorithms for deriving a CBC IV from a counter
> (e.g., run AES in counter mode with a different key). That structure
> would actually be suitable for GCM as well (and would address
> my point above).

If each implementation generates a random key and uses this to generate the IVs 
this is fine, but you still have to transmit the IV.  If we derive an “IV key” 
from the keying material, then we don’t have to transmit the IV.

We did bring this idea up at a WG meeting. This was not well-received for three 
reasons: (1) it’s unnecessarily complicated. (2) The world is going to AEAD. 
AES-CBC is the past, and (3) The perception was that saving 8 bytes per packet 
was important mostly for IoT, and they don’t care about CBC.

> S 3.
>o  IV: Initialization Vector.  Although security requirements vary,
>   the common usage of this term implies that the value is
>   unpredictable.
> 
> I don't think that this is true at all. I've frequently heard of a
> zero IV. It's also odd in that your IV is in fact predictable.
> 
> 
> S 5.
> I'm a bit surprised that you are deciding to have duplicate
> code points for every algorithm rather than some sort of IKE
> negotiation payload. I see that the WG is currently defining
> other extensions where you take that approach.

See slide #7 of 
https://www.ietf.org/proceedings/96/slides/slides-96-ipsecme-0.pdf 


The problem is that IKEv2 has strict rules about unexpected attributes in the 
substructures of the SA payload. The sense of the room was to go with new 
identifiers.

Yoav



signature.asc
Description: Message signed with OpenPGP
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Comments on draft-mglt-ipsecme-implicit-iv-02.tx

[Eric Rescorla]

Overall:
I notice that you are using a construction different from that used
in TLS 1.3, which doesn't directly repeat nonces across associations.

S 2.
   This document does not consider AES-CBC ([RFC3602])as AES-CBC
   requires the IV to be unpredictable.  Deriving it directly from the
   packet counter as described below is insecure.

Can you provide a cite for this? In any case, note that there are
straightforward algorithms for deriving a CBC IV from a counter
(e.g., run AES in counter mode with a different key). That structure
would actually be suitable for GCM as well (and would address
my point above).


S 3.
   o  IV: Initialization Vector.  Although security requirements vary,
  the common usage of this term implies that the value is
  unpredictable.

I don't think that this is true at all. I've frequently heard of a
zero IV. It's also odd in that your IV is in fact predictable.


S 5.
I'm a bit surprised that you are deciding to have duplicate
code points for every algorithm rather than some sort of IKE
negotiation payload. I see that the WG is currently defining
other extensions where you take that approach.


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

Re: [IPsec] Comments on draft-ietf-ipsecme-tcp-encaps

[Eric Rescorla]

On Sat, Mar 18, 2017 at 11:29 PM, Yoav Nir  wrote:

> Hi, Eric.
>
> On 19 Mar 2017, at 4:04, Eric Rescorla  wrote:
>
> [Now with the right address]
>
> I just finished reading this document. Some comments below.
>
>
> - You have a uniform 16 bit length field followed by a 4 byte all-zeros
>sentinel value to indicate that a packet is IKE rather than ESP.
>Given that in S 3 graf 2 you have a SHOULD-level requirement
>to use typical UDP payload lengths, why not instead explicitly
>limit lengths to 15 bits and use the top bit to indicate IKE versus
>ESP. This would be slightly more efficient and seems simpler.
>I suppose that the counterargument is that IKE over UDP behaves
>differently, but in terms of implementation, that doesn't seem like
>   much of an argument.
>
>
> Another counter-argument is that we sometimes need the entire theoretical
> length of a UDP packet. The IKE_AUTH messages typically carry a certificate
> chain and sometimes even a CRL. And there is no way to split a certificate
> chain over several messages. With remote access VPN you also get a CFG
> payload with configuration information that can also encode an unbounded
> amount of data. So I would not want to constrain the certificate chains
> that we are able to send any more than the IP packet length already does.
>

OK.



Early on there was a proposal to increase the length field to 4 bytes to do
> away with these IKE limitations, but that was rejected.
>
> - If you're going to have a framing disambiguator, why not choose
>   one that has higher entropy. If there is a protocol with a random
>   start, then you are going to get some collisions with 2^48 bits.
>
>
> I don’t think anyone plans to implement this on any port other than 443.
> And on that port we’re worrying about exactly one protocol and it doesn’t
> start with “IKETCP"
>

Fair enough.


> - It seems like IKE associations can span TCP connections (S 6)
>   so why not instead of doing UDP first then TCP, do happy eyeballs.
>
>
> I don’t think it’s necessary to prescribe for or against this, but that is
> what we do, and I think that is what Apple intends to do.
>

Right, but the text here actively discourages this.
https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-09#section-5.1

"   to reduce connection setup delays. It is recommended that theinitial
message over UDP is retransmitted at least once before falling back to TCP,
unless the Initiator knows beforehand that the   network is likely to block
UDP."


" when TLS is used on the TCP connection, both the TCP Originator and TCP
> Responder SHOULD allow the NULL cipher to be selected for performance
> reasons."
>
> This seems like you are going to have some problems with TLS 1.3
>
> - If you are going to use TLS, shouldn't you be using ALPN?
>
>
> The idea of using TLS (rather than just IKE on port 443) is to get past
> firewalls and IDP that examine the TCP traffic to determine that it “really
> looks like HTTPS”. There was some discussion about whether this was a good
> idea or whether we should in such a case either give up or standardize some
> kind of SSL-VPN. There was no consensus to go with SSL-VPN in either this
> group or any other (there was a bar bof a few IETFs ago)
>

OK. You're still going to have a problem with 1.3...

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

Re: [IPsec] Comments on draft-ietf-ipsecme-tcp-encaps

[Yoav Nir]

> On 19 Mar 2017, at 13:20, Valery Smyslov  wrote:
> 
> Hi Yoav,
> 
>> > I don't think it's a good idea. The TCP encapsulation has a lot of 
>> > drawbacks in terms of performance (see Section > 12), so it is considered
>> > as a last resort if UDP doesn't work. In general UDP (or no encapsulation) 
>> > is a preferred transport. If we start > trying TCP and UDP in parallel, 
>> > then
>> > in some cases TCP will win even if UDP works, resulting in non-efficient 
>> > connection, even when UDP could be used.
>> 
>> So as I said before, we do it, although IIRC (I’m not on the client team) 
>> the client gives TCP a one-second head start.
>> The reason is that in many places where a UDP packet can go, a fragmented 
>> UDP packet gets dropped,
>> so the first packets will work fine but the packets with the certificates 
>> (either IKE_AUTH or Main Mode #5) will get dropped.
> 
> With IKE Fragmentation that's not a problem anymore.

IKE over TCP solves the same problem (and a few others).

>> In by the end of IKE we have determined that UDP also works, we move to that 
>> for IPsec. And if TCP is blocked, we will try the IKE negotiation on UDP.
> 
> Your TCP encapsulation protocol seems to be more flexible than what is 
> described in the draft.

Yes, and we (the working group) decided to simplify things by not incorporating 
this flexibility.

> The current draft doesn't allow moving existing SA from TCP to UDP unless 
> MOBIKE is negotiated (see Section 5).
> So, if you start with TCP first (or do happy eyeballs and TCP wins), you 
> never switch back to UDP, even if it appears
> that UDP works for that path too, unless both sides support MOBIKE. And even 
> with MOBIKE it's not clear if switching
> is alowed unless interface address changes. That's why UDP is given a 
> preference.

Yes, and that’s why the cost of using this as an alternative to IKE 
fragmentation is too high.

Yoav


signature.asc
Description: Message signed with OpenPGP
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Comments on draft-ietf-ipsecme-tcp-encaps

[Valery Smyslov]

Hi Yoav,

> I don't think it's a good idea. The TCP encapsulation has a lot of drawbacks in terms of performance (see Section 
> 12), so it is considered
> as a last resort if UDP doesn't work. In general UDP (or no encapsulation) is a preferred transport. If we start 
> trying TCP and UDP in parallel, then

> in some cases TCP will win even if UDP works, resulting in non-efficient 
connection, even when UDP could be used.

So as I said before, we do it, although IIRC (I’m not on the client team) the client gives TCP a one-second head 
start.

The reason is that in many places where a UDP packet can go, a fragmented UDP 
packet gets dropped,
so the first packets will work fine but the packets with the certificates (either IKE_AUTH or Main Mode #5) will get 
dropped.


With IKE Fragmentation that's not a problem anymore.

In by the end of IKE we have determined that UDP also works, we move to that for IPsec. And if TCP is blocked, we will 
try the IKE negotiation on UDP.


Your TCP encapsulation protocol seems to be more flexible than what is 
described in the draft.

The current draft doesn't allow moving existing SA from TCP to UDP unless 
MOBIKE is negotiated (see Section 5).
So, if you start with TCP first (or do happy eyeballs and TCP wins), you never 
switch back to UDP, even if it appears
that UDP works for that path too, unless both sides support MOBIKE. And even 
with MOBIKE it's not clear if switching
is alowed unless interface address changes. That's why UDP is given a 
preference.


Yoav


Regards,
Valery.

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

Re: [IPsec] Comments on draft-ietf-ipsecme-tcp-encaps

[Valery Smyslov]

Hi Eric,

I just finished reading this document. Some comments below. 


- You have a uniform 16 bit length field followed by a 4 byte all-zeros
   sentinel value to indicate that a packet is IKE rather than ESP.
   Given that in S 3 graf 2 you have a SHOULD-level requirement
   to use typical UDP payload lengths, why not instead explicitly
   limit lengths to 15 bits and use the top bit to indicate IKE versus
   ESP. This would be slightly more efficient and seems simpler.
   I suppose that the counterargument is that IKE over UDP behaves
   differently, but in terms of implementation, that doesn't seem like
  much of an argument.


That won't work. An application protocol running over UDP
is free to send messages up to 64Kbytes. While in tunnel mode we can
first fragment these messages and then apply ESP (so that each ESP
packet is rather small) , in transport mode it's impossible, and the ESP
datagram can reach 64Kbytes in size. I agree that in wild there are few 
protocols that send such long UDP messages, but it is not prohibited.



- It seems like IKE associations can span TCP connections (S 6)
  so why not instead of doing UDP first then TCP, do happy eyeballs.


I don't think it's a good idea. The TCP encapsulation has a lot of 
drawbacks in terms of performance (see Section 12), so it is considered
as a last resort if UDP doesn't work. In general UDP (or no encapsulation) 
is a preferred transport. If we start trying TCP and UDP in parallel, then
in some cases TCP will win even if UDP works, resulting in non-efficient 
connection, even when UDP could be used. 


-Ekr


Regards,
Valery Smyslov.

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

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

Re: [IPsec] Comments on draft-ietf-ipsecme-tcp-encaps

[Yoav Nir]

Hi, Eric.

> On 19 Mar 2017, at 4:04, Eric Rescorla  wrote:
> 
> [Now with the right address]
> 
> I just finished reading this document. Some comments below.
> 
> 
> - You have a uniform 16 bit length field followed by a 4 byte all-zeros
>sentinel value to indicate that a packet is IKE rather than ESP.
>Given that in S 3 graf 2 you have a SHOULD-level requirement
>to use typical UDP payload lengths, why not instead explicitly
>limit lengths to 15 bits and use the top bit to indicate IKE versus
>ESP. This would be slightly more efficient and seems simpler.
>I suppose that the counterargument is that IKE over UDP behaves
>differently, but in terms of implementation, that doesn't seem like
>   much of an argument.

Another counter-argument is that we sometimes need the entire theoretical 
length of a UDP packet. The IKE_AUTH messages typically carry a certificate 
chain and sometimes even a CRL. And there is no way to split a certificate 
chain over several messages. With remote access VPN you also get a CFG payload 
with configuration information that can also encode an unbounded amount of 
data. So I would not want to constrain the certificate chains that we are able 
to send any more than the IP packet length already does.

Early on there was a proposal to increase the length field to 4 bytes to do 
away with these IKE limitations, but that was rejected.

> - If you're going to have a framing disambiguator, why not choose
>   one that has higher entropy. If there is a protocol with a random
>   start, then you are going to get some collisions with 2^48 bits.

I don’t think anyone plans to implement this on any port other than 443. And on 
that port we’re worrying about exactly one protocol and it doesn’t start with 
“IKETCP"

> - It seems like IKE associations can span TCP connections (S 6)
>   so why not instead of doing UDP first then TCP, do happy eyeballs.

I don’t think it’s necessary to prescribe for or against this, but that is what 
we do, and I think that is what Apple intends to do.

> " when TLS is used on the TCP connection, both the TCP Originator and TCP 
> Responder SHOULD allow the NULL cipher to be selected for performance 
> reasons."
> 
> This seems like you are going to have some problems with TLS 1.3
> 
> - If you are going to use TLS, shouldn't you be using ALPN?

The idea of using TLS (rather than just IKE on port 443) is to get past 
firewalls and IDP that examine the TCP traffic to determine that it “really 
looks like HTTPS”. There was some discussion about whether this was a good idea 
or whether we should in such a case either give up or standardize some kind of 
SSL-VPN. There was no consensus to go with SSL-VPN in either this group or any 
other (there was a bar bof a few IETFs ago)

Yoav


signature.asc
Description: Message signed with OpenPGP
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec