Re: [Idr] Stephen Farrell's No Objection on draft-ietf-idr-error-handling-18: (with COMMENT)

[Stephen Farrell <[e-mail]>]

Hiya,

I do not and will not have any cows:-)

On 20/04/15 18:46, John G. Scudder wrote:
> Hi Stephen,
> 
> I'm doing a final update of the draft to cover comments in IE SG
> review. I'd like to discuss yours a bit.
> 
> On Mar 10, 2015, at 10:12 AM, Stephen Farrell
> <[e-mail]> wrote:
> 
>> - There is a perhaps missing security consideration. I think this
>> kind of protocol behaviour argues that any kind of BGPSEC
>> encryption needs to use an AEAD ciphersuite.  (Which we'd likely do
>> these days anyway, so that's not a biggie.) The reason is if say
>> CBC or a stream cipher were used, then an attacker could play with
>> ciphertext is various ways that might interact with this error
>> handling behaviour so as to expose information that is intended to
>> be protected by the BGPSEC mechanism. Such an attack would probably
>> be pooh-poohed by all but tin foil hat folks, but it could still be
>> worth noting (maybe in section 8?) and as we've seen recently, many
>> of the tin foil hat fears turn out to be realistic, sadly.
> 
> Since you balloted "no objection", would I be right to think you
> won't have a cow if we don't make this change? I confess to not
> knowing the difference between AEAD and a hole in the ground nor do I
> understand the attack you allude to, so at the least I would have to
> find someone to either educate me or write the text for me. So far we
> haven't considered confidentiality to be important for BGP security
> -- although you reference encryption in connection with BGPSEC,
> BGPSEC is actually entirely about integrity and authenticity and
> specifically disclaims confidentiality, see
> draft-ietf-sidr-bgpsec-threats-09.
> 
> If you feel strongly about having this covered, I'd appreciate if you
> pointed me at someone who could help with education and/or specific
> text.

I'd suggest this, but am fine if you prefer to omit it, or edit it:

"The improved error handling of this specification could in theory
interact badly with some now-known weaker cryptographic mechanisms
should such be used in future to secure BGP. For example, if a
(fictional) mechanism that did not supply data integrity was used,
an attacker could manipulate ciphertext in any attempt to change
or observe how the receiver reacts. Absent this specification, the
BGP session would have been terminated, while with this specification
the attacker could make potentially many attempts. While such a
confidentiality-only mechanism would not be defined today, we have
in the past seen mechanism definitions that result in similar though
not as obviously exploitable vulnerabilities. [RFC7366] The approach
recommended today to avoid such issues is to prefer use of
Authenticated Encryption with Additional Data (AEAD) ciphers [RFC5116]
and (thus) to discard messages that don't verify."

Cheers,
S.

PS: Other stuff below also does not produce bovine reactions.


> 
>> I noted a few nitty nits:
>> 
>> - section 2: AFI/SAFI are used without expansion
> 
> Will fix.
> 
>> - 3.d: "well-known mandatory attributes" sort of yells for a 
>> reference, doesn't it.
> 
> At first I was going to agree with you, but then I reminded myself
> that the entirety of section 3 is a set of amendments to RFC 4271,
> Section 6.3, and says so in its first paragraph. As such, one might
> think the reference in the first paragraph ought to be sufficient.
> I'm not dead set against the extra reference if you feel strongly,
> but it does seem redundant so for now I'm not adding it.
> 
>> - 3.e: "cases that specify" - specify where? I think you mean in
>> the updated RFCs but it might be nice to say that
> 
> Actually we mean the cases enumerated in RFC 4271 Section 6.3, again
> as indicated in the first paragraph. I do think this would be clear
> to someone who had reviewed that reference (which I don't fault you
> for not having done) so again, I'm going to refrain from repeating
> the reference here unless you want to make a further case for it.
> 
>> - 5: NRLI is expanded after 1st use
> 
> Okay.
> 
> Thanks for the comments,
> 
> – John
>