Subject: [saag] NULL encryption mode in RFC 5202-bis

From: Tom Henderson <[email-masked]>
Date: Mon, 07 Jul 2014 21:54:34 -0700

Hi all,

Apologies for cross-posting, but Stephen Farrell raised a DISCUSS 
(seconded by Kathleen Moriarty) in the IESG evaluation of RFC 5202-bis: 
   Using the Encapsulating Security Payload (ESP) Transport Format with 
the Host Identity Protocol (HIP).  Stephen asked me to raise this 
question for discussion on both the HIP and SAAG lists.

Stephen's discuss questions the specification of "MUST to implement" for 
the NULL encryption option of the ESP_TRANSFORM parameter:

http://tools.ietf.org/html/draft-ietf-hip-rfc5202-bis-05#section-5.1.2

Stephen asks why is this a MUST to implement?  The history behind this 
that I'm aware of is that since HIP does not have an AH, only ESP, the 
ESP with NULL encryption mode can provide authentication.  It was also 
stated in previous drafts that this mode supports debugging.

Null encryption was also specified as a MUST to implement in RFC5202 and 
dates back to earlier versions of the HIP base draft (to 2003: 
http://tools.ietf.org/html/draft-moskowitz-hip-06#section-11.3).

- Tom

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 08 Jul 2014 11:33:02 +0100

Thanks Tom,

> http://tools.ietf.org/html/draft-moskowitz-hip-06#section-11.3).

Right. I guess my discuss has a generic part and a hip specific
part.

Generic: is it still considered a good plan to have null
confidentiality suites such as these? Or for those to be
Mandatory-To-Implement (MTI)? That clearly was the generic
consensus as we have these in a number of protocols. The
new reasons to move from that I think are: 1) we no longer
need this for debugging purposes really since libraries
and dev tools have moved on and are better now, and we
specifically no longer need these for protocols that are
no longer new, 2) BCP188 could be considered to argue
against having these as they could be misused. (All the
old arguments of course do still apply, but I think the
above are the ones that are new.) So is that enough to
shift the consensus away from having these or having
them be MTI?

Specific: is there anything specific about hip that would
trump the general point above? Note that there could be,
regardless of where consensus lies on the generic question.

FWIW, my own answers for these are that its probably a better
plan today to not have (or make MTI) these null confidentiality
ciphersuites, and I don't know that hip would have any specific
reason to diverge from that. But I'd really like to see if
there is a modified consensus on this or not. (To be clear,
if there's not a new consensus then the current one would
seem to still apply here and I'll clear my discuss.)

Cheers,
S.

---

From: ianG <[email-masked]>
Date: Tue, 08 Jul 2014 13:06:00 +0100

On 8/07/2014 05:54 am, Tom Henderson wrote:
> ESP with NULL encryption mode can provide authentication.

IIUC, this derives from old arguments that encryption is expensive so
there might be a use case [0] where it is desirable to turn it off, and
users should have that option because it's cost free.

This is more or less a deprecated argument.  Encryption is no longer
expensive.  The history of users is that they don't have a need to turn
it off, they aren't equipped to make the decision properly, and giving
them one more knob to play with creates one more support headache.

And, it isn't cost free:  null ciphers introduce a lovely downgrade
attack, and marginal internal fault possibilities.

It also relates to a bygone age where active MITM was believed a greater
enemy than passive eavesdropping, so auth was king.  History hasn't been
kind to that view.

> It was also

If it is debugging, the advice is backwards, IMHO.  NULL ciohers should
not be mandatory to implement.  Developers will do what they will, if
they need a mode like that they will add it, they don't need to be told
they must do it.

Better advice would be that that production code MUST be shipped with
all dangerous debugging modes stripped out, not implemented.

iang

[0] curiously, a modern use case might be found in Bitcoin where
encryption isn't needed because the tx are all published anyway.  I find
this a tough mental barrier.

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 08 Jul 2014 15:13:24 +0300

I think the debugging argument is still valid. For example, host-side 
debugging of IPsec with tcpdump is still somewhat broken on many Linux 
boxes.

And please bear in mind that if NULL-auth is not implemented on BOTH 
peers, you cannot use it to debug your implementation even if your side 
does have such a debug knob.

So I would recommend something like "MUST implement (or maybe SHOULD). 
MUST NOT negotiate by default".

Thanks,
	Yaron

---

From: Mouse <[email-masked]>
Date: Tue, 8 Jul 2014 09:56:21 -0400 (EDT)

> expensive.  [...]

Kinda.

It still is expensive in some fields (or, for some applications, if you
prefer).  The attitude that encryption is cheap is valid for only some
purposes.  They're important purposes, certainly, but mistaking them
for the whole world evidences a rather blinkered mindset.

> The history of users is that they don't have a need to turn it off,
> they aren't equipped to make the decision properly, and giving them
> one more knob to play with creates one more support headache.

If your target audience is mass-market end users, yes.  That is not the
only target audience.

If you want to argue that it's the only audience of relevance to
5202-bis, fine, but that's not what what you wrote sounded like to me.

> It also relates to a bygone age where active MITM was believed a
> greater enemy than passive eavesdropping, [...]

Bygone age?  For some threat models, it still is.  Assuming everyone's
threat model matches yours is about as good an idea as assuming
everyone's value of "computationally cheap" matches yours.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 8 Jul 2014 07:25:13 -0700

On Jul 8, 2014, at 5:13 AM, Yaron Sheffer <[email-masked]> wrote:

> So I would recommend something like "MUST implement (or maybe SHOULD). MUST NOT negotiate by default".

If the only reason for this is debugging, then it could be "SHOULD implement to allow debugging" and "NULL encryption MUST NOT be exposed in the administrative interface as a normal parameter, and MUST only be allowed when both endpoints are explicitly put into a debugging mode".

--Paul Hoffman

---

From: Miika Komu <[email-masked]>
Date: Tue, 08 Jul 2014 13:04:37 +0300

Hi,

> http://tools.ietf.org/html/draft-moskowitz-hip-06#section-11.3).

maybe we should keep it as it is for easier, incremental 
interoperability testing. The same issue was discussed earlier in this 
thread:

http://www.ietf.org/mail-archive/web/hipsec/current/msg01779.html

If you think this is a big problem, I'd suggest replacing NULL with 
suite id 9.

---

From: James Cloos <[email-masked]>
Date: Tue, 08 Jul 2014 11:06:03 -0400

>>>>> "TH" == Tom Henderson <[email-masked]> writes:

TH> Stephen's discuss questions the specification of "MUST to implement"
TH> for the NULL encryption option of the ESP_TRANSFORM parameter:

If those doing IP over Amateur Radio are a use case, they require NULL.

Encryption is illegal for most of them (I hear Australia allows it in
some cases; AFAIK no other country does) but authentication has value.

And that restriction is enforced.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 08 Jul 2014 08:39:09 -0400

> shift the consensus away from having these or having

I should point out that I lobbied hard for CMAC and GMAC added to 5202, 
as they are better constructs for doing auth only, or so I have been told.

I seem to recall during this discussion not to add these options as we 
have NULL which we need anyway.  I argued back that for systems that 
have AES-CCM or GCM in hardware, there would be a desire for CMAC or 
GMAC over HMAC.  SO now we have 3 suites that provide auth only with 
selection based on what MACing works best for the system(s) in question.

So given this, NULL is to balance the auth only suites or what?

I should also point out that the code we have today may not be the only 
code we have tomorrow.  That NULL does provide a valuable test tool.

So finally, a best implementation practice may to caution parties to 
accepting NULL.  Perhaps NULL when it is the only offered option. Or 
NULL when the list only contains NULL, CMAC, or GMAC.

> _______________________________________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 08 Jul 2014 16:24:32 +0100

> If those doing IP over Amateur Radio are a use case, they require NULL.

That'd be IPsec, not IP, I guess. How many people actually
use IPsec that way?

For corner cases like that (and it is utterly a corner
case regardless of how laudable a corner case) I'd not
have an issue with there being some other RFC to which
they could conform, should there be sufficient interest
in writing such. I don't myself see that can ever justify
an MTI for all implementations though.

S.

---

From: Jeffrey Walton <[email-masked]>
Date: Tue, 8 Jul 2014 11:46:02 -0400

On Tue, Jul 8, 2014 at 8:06 AM, ianG <[email-masked]> wrote:
>> ...
When we test applications, we don't force a downgrade to NULL; we set
up a Burpe or Charles proxy and MitM the connection. I've only seen
one person force a downgrade during ST&E. Perhaps others have
different experience.

That one downgrade attack was performed by Chris Paget in a mobile
security talk. She built a GNU radio and cell phones in the room
camped to her base station because it provided the strongest signal.
The base station provided A0/0 (A5/2 probably would have worked just
as well since it has nearly no security).

Jeff

---

From: James Cloos <[email-masked]>
Date: Tue, 08 Jul 2014 12:37:29 -0400

>>>>> "SF" == Stephen Farrell <[email-masked]> writes:

SF> That'd be IPsec, not IP, I guess. How many people actually
SF> use IPsec that way?

I don't know.  AIUI, hams have been specified as a reason for NULL for
most ietf work product.

For this case, though, it seems Robert's suggestion of CMAC and GMAC may
be better long term.

Although there is stil the issue of compatibility with existing users,
if there are any.

-JimC

---

From: Michael Richardson <[email-masked]>
Date: Tue, 08 Jul 2014 13:59:54 -0400

Stephen Farrell <[email-masked]> wrote:
    > Mandatory-To-Implement (MTI)? That clearly was the generic consensus as
    > we have these in a number of protocols. The new reasons to move from
    > that I think are: 1) we no longer need this for debugging purposes
    > really since libraries and dev tools have moved on and are better now,
    > and we specifically no longer need these for protocols that are no
    > longer new, 2) BCP188 could be considered to argue against having these

There are an incredible number of systems (Linux with stock-in-kernel NETKEY
IPsec for instance), where it is impossible or very very difficult to get a
packet capture of the traffic after decryption, but before it goes up the
protocol stack. 

On such systems, if you have a problem in the field with a protocol that runs
over ESP (whether HIP or IKEv2 keyed), and you can't figure out how it works,
and it appears to with without ESP, then the lack of debugging means that you
turn off all security.

ESP-authenticated-with-NULL-encryption is debuggable in the field.
Not having it, means turning off ESP; and if the problem is in the link
between the ESP layer and the upper layer, then... 

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Paul Lambert <[email-masked]>
Date: Tue, 8 Jul 2014 17:15:31 -0700

]-----Original Message-----
]From: saag [mailto:[email-masked]] On Behalf Of Yaron Sheffer
]Sent: Tuesday, July 08, 2014 5:13 AM
]To: ianG; [email-masked]
]Subject: Re: [saag] NULL encryption mode in RFC 5202-bis
]
]I think the debugging argument is still valid. For example, host-side
]debugging of IPsec with tcpdump is still somewhat broken on many Linux
]boxes.
The boxes should be fixed rather than making available 
such a bypass of encryption.

Logging and other mechanisms could be readily used and will be developed
as necessary to 'debug' systems.

]
]And please bear in mind that if NULL-auth is not implemented on BOTH
]peers, you cannot use it to debug your implementation even if your side
]does have such a debug knob.
]
]So I would recommend something like "MUST implement (or maybe SHOULD).
]MUST NOT negotiate by default".

But where is the 'negotiation bit" set?  Implementations should not be made to
leave such a back-door in the code just for developers to debug.

Paul

]
]Thanks,
]	Yaron
]
]_______________________________________________
]saag mailing list
][email-masked]
]https://www.ietf.org/mailman/listinfo/saag

---

From: Michael Richardson <[email-masked]>
Date: Tue, 08 Jul 2014 21:27:46 -0400

> such a bypass of encryption.

Let me know when you've done that.  It's open source.  Contribute a patch.
Oh. BSD kernels have the same problem (so OSX, iPhone).  I don't know
about Solaris.  

But, this is not about bypassing encryption: this is about an administrator
working with to debug a protocol in the field. 

    > as necessary to 'debug' systems.

Honestly: have you actually done this in the field?  with a remote
administrator who doesn't understand IPsec?  Remember, it's not *IPsec* we
are debugging, it is something else that lives on top of IPsec.

    > leave such a back-door in the code just for developers to debug.

Uh. Please go read about IPsec/IKEv2 and HIP.
The negotiate bit is called rfc4306 or HIP (RFC5201)

---

From: Paul Lambert <[email-masked]>
Date: Tue, 8 Jul 2014 23:57:31 -0700

On 7/8/14, 6:27 PM, "Michael Richardson" <[email-masked]> wrote:

>Honestly: have you actually done this in the field?
Yes.  I have designed and fielded very large installations of IPsec.  NULL
encryption was never required.  The larger systems had great debugging
capability without NULL encryption. The Type I network security products I
built would not even allow such a bypass for ³security² reasons.  It¹s too
easy to make a mistake or have the system made to appear to be working,
but in NULL mode.

>with a remote
>administrator who doesn't understand IPsec?
Yes. Having the remote admin turn on-and-off the encryption seems very
questionable in this case.  Reminds me of the phone call I got the other
day from a company telling me my computer was infected and I need to let
them make some changes.

>Remember, it's not *IPsec* we
Yes. So what, many other tools are possible.

>The negotiate bit is called rfc4306 or HIP (RFC5201)

Yes, I¹ve read them Š
Of course there is a bit in the protocol. My wording seems to have missed
my point, where in the configuration settings of an administrator mode are
these bits set or unset in a manner that prevents accidental or malicious
misuse.  MUST implement is clearly designing system for the developers and
not for the end-users.  What real-world IPsec challanged end user would
ever actually want this configuration set?  There are better ways to get
the information and a system debugged than to mandate NULL encryption.

Paul

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 09 Jul 2014 10:47:09 -0400

The downgrade attack in HIP (RFC 5201-bis) is hard. R1 is a signed 
payload, and in many use cases, the Initiator has pre-deteremined the 
Responder's HI and HIT so it can check the SIG before processing the ESP 
TRANSFORM parameters. In sensornets where the Initiator cannot 
pre-determine the Responder's (typically some sensor controller) HI and 
HIT, then it is a concern.

Further eventhough I1 is unsigned, the Initiator 'knows' what suites it 
wants to use, so if its list is: CBC/HMAC, or CCM and gets NULL or CMAC 
back, it MUST NOT complete the exchange. If in the R1 it gets NULL, 
CMAC, CBC/HMAC, or CCM then it SHOULD select CBC/HMAC.

If the Responder sent in R1 CBC/HMAC or CCM and got NULL in I2, it MUST 
NOT complete the exchange.

The HIP design team spent a long time working out downgrade attacks. I 
have to thank Tobias Heer and Miika Komu for a couple day design when I 
was visiting HIIT in Helsinki.

NULL, CMAC, or GMAC should only be configured as allowable suites when 
they are needed for debug, or the situation requires auth-only. And I 
should point out there are devices and situations where auth-only is the 
case, so those suites are needed. IMNSHO.

In the worst case scenario, we could cover with text that clearifies the 
privacy versus auth-only suites with requirements that these suites not 
be mixed in an exchange and if one is expected, the other not accepted. 
Of course 'servers' (I say that parenthetically, as HIP is a peer 
exchange) MIGHT need to support both classes of customers and thus need 
to respond based on the unprotectable I1 packet. Even there, the 
Initiator still can bid back if its I1 was altered by a MiTM.

---

From: Henry B Hotz <[email-masked]>
Date: Wed, 9 Jul 2014 11:48:20 -0700

Speaking to Stephen's "generic" point: it seems to me that debugging arguments are sufficient for a SHOULD and not "generically" for a MUST.

Personal email.  [email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Wed, 09 Jul 2014 17:25:22 -0400

Robert Moskowitz <[email-masked]> wrote:
    > NULL, CMAC, or GMAC should only be configured as allowable suites when they
    > are needed for debug, or the situation requires auth-only. And I should point
    > out there are devices and situations where auth-only is the case, so those
    > suites are needed. IMNSHO.

Exactly, I don't understand the concern.
If someone thinks that the AUTH-only policy should be hidden in a UI, I don't
care.   What I care about is that the kernel implementers understand that it
is important to have, because kernels are rather hard to replace on many
systems, even if the choice of key manager if fungible.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Christian Huitema <[email-masked]>
Date: Wed, 9 Jul 2014 21:56:39 +0000

> systems, even if the choice of key manager if fungible.

Maybe we should not think of HIP and IPSEC the same way we think of TLS. Packet-level encryption is pretty much part of the infrastructure, and is generally not visible to the application. Auth-only protection has value at the packet level, e.g. as a protection against various intrusions and tampering attacks. It does not provide confidentiality, but we can expect applications that require confidentiality to use TLS or other application level mechanism.

The main benefit of packet level encryption could be some protection against traffic analysis. But HIP or transport-mode IPSEC do expose the actual destination of the packet, so there is little gain from packet level encryption...

-- Christian Huitema

---

From: Paul Lambert <[email-masked]>
Date: Mon, 21 Jul 2014 16:57:03 -0700

NULL may be useful to some, but should NOT be mandated (should rather than must).
It's another knob that could be set incorrectly and bypass the encryption.  Not all products will want or need NULL.

Paul

]-----Original Message-----
]From: Hipsec [mailto:[email-masked]] On Behalf Of Michael
]Richardson
]Sent: Tuesday, July 08, 2014 11:00 AM
]To: Stephen Farrell
]Cc: [email-masked]; [email-masked]
]Subject: Re: [Hipsec] [saag] NULL encryption mode in RFC 5202-bis
]
]
]Stephen Farrell <[email-masked]> wrote:
]    > Generic: is it still considered a good plan to have null
]    > confidentiality suites such as these? Or for those to be
]    > Mandatory-To-Implement (MTI)? That clearly was the generic
]consensus as
]    > we have these in a number of protocols. The new reasons to move
]from
]    > that I think are: 1) we no longer need this for debugging purposes
]    > really since libraries and dev tools have moved on and are better
]now,
]    > and we specifically no longer need these for protocols that are no
]    > longer new, 2) BCP188 could be considered to argue against having
]these
]
]There are an incredible number of systems (Linux with stock-in-kernel
]NETKEY IPsec for instance), where it is impossible or very very
]difficult to get a packet capture of the traffic after decryption, but
]before it goes up the protocol stack.
]
]On such systems, if you have a problem in the field with a protocol that
]runs over ESP (whether HIP or IKEv2 keyed), and you can't figure out how
]it works, and it appears to with without ESP, then the lack of debugging
]means that you turn off all security.
]
]ESP-authenticated-with-NULL-encryption is debuggable in the field.
]Not having it, means turning off ESP; and if the problem is in the link
]between the ESP layer and the upper layer, then...
]
]--
]Michael Richardson <[email-masked]>, Sandelman Software Works  -=
]IPv6 IoT consulting =-
]
]

---

From: Henry B Hotz <[email-masked]>
Date: Mon, 21 Jul 2014 17:51:09 -0700

The basic issue, as always, is interoperability. NULL should not be an interoperable *operational* capability.

Every implementation will have some kind of debugging capability so it can be made operational. Do we require an interoperable debugging capability? I believe the consensus is already leaning to "no".

My own take is that we don't normally do that, and the likely debugging benefit of mandating such a thing is insufficient to justify making it a MUST.

On Jul 21, 2014, at 4:57 PM, Paul Lambert <[email-masked]> wrote:

> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Jul 2014 10:28:43 -0400

> If those doing IP over Amateur Radio are a use case, they require NULL.

If Amateur Radio's prohibition on encryption is considered to be important in making decisions about crypto in protocols, then I think we are in a situation where we can't have crypto protocols that don't disallow downgrade attacks, because implementations always have to be willing to downgrade to no encryption if the other endpoint is an Amateur Radio station.

So, by reductio ad absurdum, I claim that this isn't something the working group should consider as a deciding factor.   I think the same observation also applies to Michael's comment about debugging on stacks with limited trace capability.   If you need to disable encryption, you should have to do something fairly extraordinary to make that happen.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Jul 2014 10:49:48 -0400

On Jul 22, 2014, at 10:45 AM, Robert Moskowitz <[email-masked]> wrote:
> It is a switch to request integrity only. Or to only allow integrity only. Either party MUST be able to reject an integrity only negotiation.

That's not good enough.   It should be the case that integrity-only negotiations are rejected by default, unless there's no protocol requirement for confidentiality.   If there is no need for confidentiality, then the answer to the DISCUSS should be "there is no need for confidentiality."

---

From: Michael Richardson <[email-masked]>
Date: Tue, 22 Jul 2014 11:25:48 -0400

> If Amateur Radio's prohibition on encryption is considered to be
    > important in making decisions about crypto in protocols, then I think
    > we are in a situation where we can't have crypto protocols that don't
    > disallow downgrade attacks, because implementations always have to be
    > willing to downgrade to no encryption if the other endpoint is an
    > Amateur Radio station.

Ted, you are assuming that there are no policy knobs at all.
We are talking about IPsec ESP, as required by HIP, not UTA/TLS here.

I don't understand this fear that policy knobs will accidentally get
unstuck and start accepting something weaker without administrator
involvement.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 22 Jul 2014 11:26:48 -0400

Ted Lemon <[email-masked]> wrote:
    >> It is a switch to request integrity only. Or to only allow integrity
    >> only. Either party MUST be able to reject an integrity only
    >> negotiation.

    > That's not good enough.  It should be the case that integrity-only
    > negotiations are rejected by default, unless there's no protocol
    > requirement for confidentiality.  If there is no need for
    > confidentiality, then the answer to the DISCUSS should be "there is no
    > need for confidentiality."

All of those knobs, correctly labelled, are all there already.  Really.

---

From: Edward Lopez <[email-masked]>
Date: Tue, 22 Jul 2014 15:28:52 +0000

In my view, the underlying question is concerned with the value of a common encryption algorithm across all implementations of ESP, NULL or otherwise.  In my experience, the existence of mandatory common denominators in standards results in improved interoperability between implementations.  In the particular case of ESP, I agree that virtually no one would implement IPSec using NULL encryption, and we heavily rely on de-facto common use of US NIST-approved protocols (DES, 3DES, AES) for interoperability today.

My point is that by removing the MUST requirement for NULL encryption, should be consider the idea that we are substituting a stated common encryption protocol for a set of implied ones.  We will also be eliminating implementation choices over time for those requiring NULL encryption.

I’m not strongly advocating keeping the MUST, and would likely be ok to replace it with SHOULD.  But I did want to state that this surrendering of an mandated algorithm, and its consequences relative to maintaining interoperability, is a factor that I considered.

Ed

On Jul 21, 2014, at 8:51 PM, Henry B Hotz <[email-masked]<mailto:[email-masked]>> wrote:

On Jul 21, 2014, at 4:57 PM, Paul Lambert <[email-masked]<mailto:[email-masked]>> wrote:

Paul

]From: Hipsec [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Michael
]Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
]Stephen Farrell <[email-masked]<mailto:[email-masked]>> wrote:
]Michael Richardson <[email-masked]<mailto:[email-masked]>>, Sandelman Software Works  -=
]IPv6 IoT consulting =-
]
]

_______________________________________________
saag mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/saag

Personal email.  [email-masked]<mailto:[email-masked]>

_______________________________________________
saag mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/saag

***  Please note that this message and any attachments may contain confidential 
and proprietary material and information and are intended only for the use of 
the intended recipient(s). If you are not the intended recipient, you are hereby 
notified that any review, use, disclosure, dissemination, distribution or copying 
of this message and any attachments is strictly prohibited. If you have received 
this email in error, please immediately notify the sender and destroy this e-mail 
and any attachments and all copies, whether electronic or printed.
Please also note that any views, opinions, conclusions or commitments expressed 
in this message are those of the individual sender and do not necessarily reflect 
the views of Fortinet, Inc., its affiliates, and emails are not binding on 
Fortinet and only a writing manually signed by Fortinet's General Counsel can be 
a binding commitment of Fortinet to Fortinet's customers or partners. Thank you. ***

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 22 Jul 2014 10:28:54 -0400

> The basic issue, as always, is interoperability. NULL should not be an interoperable *operational* capability.

In this regard, I have a hard time distinguishing between NULL with 
HMAC-SHA256 and CMAC or GMAC.

With this (secure communications) context NULL means no privacy but yes 
authenticity.

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 22 Jul 2014 10:45:01 -0400

It is a switch to request integrity only. Or to only allow integrity 
only. Either party MUST be able to reject an integrity only negotiation.

---

From: Mouse <[email-masked]>
Date: Tue, 22 Jul 2014 11:43:28 -0400 (EDT)

> If Amateur Radio's prohibition on encryption is considered to be important i$

Well, can't have protocols that don't permit downgrade when configured
for ham use, at least.  I don't see any reason the protocol can't be
configured for ham use (essentially, null encryption is the only
choice) or for general-purpose Internet use (null encryption is not a
choice).

Mind you, as an implementor I'd ensure null encryption is available
even in the latter form if suitable configuration switches are flipped,
but that's a separate issue.

This doesn't address the use case of one endpoint being a ham and the
other not.  I'm not sure what I think about that; I can think of at
least three approaches, each of which would probably be preferable in
some cases.

> So, by reductio ad absurdum, I claim that this isn't something the working g$

Well, it does mean that protocols should at least be designed with
allowance for null encryption, even if it's not part of the spec.
After all, the IETF can standardize anything it wants, but if the
result doesn't support what people want to do, people will simply
ignore the spec.  (I did that with SSH, for example; as specified, it's
unimplementable on the systems I care about, so I just ignored the
problematic parts of the spec.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 22 Jul 2014 13:34:28 -0400

> All of those knobs, correctly labelled, are all there already.  Really.

The code has the knobs, but Ted's question is does the spec have the knobs.

Something like

"default transform lists MUST NOT provide any of the integrity only 
suites.  These MAY be offered only by explicit configuration."

This discussion is about NULL which is quite a misnomer...

But back in the days.........

If you look at the HIP exchange, R1 contains the offered list, and I2 
either contains the requested suite, or a counter list.  Both are signed 
(in HIP-BEX) and thus can only be spoofed for anonymous HITs.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Jul 2014 13:49:33 -0400

> Ted, you are assuming that there are no policy knobs at all.

No, I am assuming that there _are_ policy knobs, and saying what I think their default values should be.

But to be clear, I would expect surfing the web legally over a ham radio link to be pretty unsatisfying, because you would get no encrypted content, and lots of content is encrypted.   I am saying that this should not change.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 23 Jul 2014 09:54:14 -0400

Ted,

Mandatory support for NULL encryption in a protocol need not result in a 
downgrade attack
vulnerability. If peers have the ability to locally configure the set of 
algs that they will
accept, in general or on a per-peer basis, then this problem can be 
avoided. I believe that,
in this context, this is already the case.

Steve