Re: Hyatt Taipei cancellation policy?

[Eric Rescorla]

On Sat, Aug 27, 2011 at 10:05 PM, Glen Zorn  wrote:
> On 8/27/2011 10:30 PM, Eric Rescorla wrote:
>
>> On Sat, Aug 27, 2011 at 7:57 AM, Dave CROCKER  wrote:
>>>
>>>
>>> On 8/27/2011 7:48 AM, Cullen Jennings wrote:
>>>>
>>>> What I have heard is that the community would prefer going to locations
>>>> that were easy to travel to over "interesting".
>>>
>>>
>>> How do you reconcile this assertion against the clearly positive group
>>> reactions to Prague and Quebec?
>>>
>>> FYI, in relative terms, even Minneapolis is second-tier.
>>
>> I have no idea what the "community" wants--and I'm not convinced that
>> the data we
>> have available lets us assess that, for the usual reasons about the
>> difficulty of doing
>> accurate surveying--but speaking solely for myself, I'm at IETF to
>> work, so my priorities
>> center around the things that make it easy to get work done. This
>> basically boils down
>> to cost  and convenience.
>
> Good to hear.  Getting rid of cookies can save a _lot_ of money & since
> you're "at IETF to work" I'm sure you wouldn't mind if the conditions
> more closely approximated those of the typical office; no office I've
> ever worked in has provided free cookies & beverages twice a day...

I'm not sure that getting rid of food at breaks would save a lot of money.
Do you know what the actual numbers are as a percentage of the
overall cost?

With that said, it's actually quite common for workplaces to offer free
snacks and/or beverages, not only twice a day but 24/7. Maybe you
should consider a different class of employers.


>> Within these general parameters, my priorities are something like:
>> 1. Cost:
>>     - Travel
>>     - Hotel
>>
>> Rationale: airfare tends to not be that flexible, but it's generally
>> possible to find a cheaper
>> hotel if you try (as several people have observed). However, if the
>> conference hotel
>> is $300/night, then this is probably going to trickle down some into
>> cheaper hotels so
>> it's not like hotel doesn't matter.
>>
>>
>> 2. Convenience:
>>     - Length of trip.
>>     - Local services
>>
>> Rationale: travel time is time I'm not working (yeah, we all try, but
>> I'm not that effective
>> and I suspect most people are not.) Lack of local services means less
>> time meeting
>> and more time rushing around trying to find lunch before the next
>> meeting, walking to
>> and from the hotel, etc.
>
> So, do you live in your office?  Next door to the building?  Across the
> street from the office park?  If not, why are you applying criteria to
> the IETF "workplace" that you don't to everyday employment?

Funny you should mention that, since I work from home most of the time
in part to minimize commute time.


> For that
> matter, for one whose (not primary, but _only_) purpose is work,

 Strawman alert 


> finding
> lunch is a non-problem: you simply eat whatever is closest, quickest,
> most efficient, without any regard to taste or surroundings (e.g., the
> company cafeteria, analogous in this case to the hotel restaurant(s)).

Maybe you've noticed that the hotel restaurants are (a) expensive and
(b) tend to fill up quickly, which often makes it hard for people to actually
get in and out in the relevant time. This would of course be far worse if
there were no reasonable restaurants in the area.


> WRT walking to and from the hotel, I know that I, at least, am not paid
> to type (if I was, my clients would be getting a really bad deal ;-).  I
> get paid to think, and I'm pretty sure that you are, too.  I don't know
> you very well, but I think it's a sure bet that you can think & walk at
> the same time :-).

I find that I work more effectively when I have computer and Internet
available, neither of which is the situation when I'm walking to and from
the conference center. Your  mileage may vary.

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

Re: Hyatt Taipei cancellation policy?

[Eric Rescorla]

On Sat, Aug 27, 2011 at 7:57 AM, Dave CROCKER  wrote:
>
>
> On 8/27/2011 7:48 AM, Cullen Jennings wrote:
>>
>> What I have heard is that the community would prefer going to locations
>> that were easy to travel to over "interesting".
>
>
> How do you reconcile this assertion against the clearly positive group
> reactions to Prague and Quebec?
>
> FYI, in relative terms, even Minneapolis is second-tier.

I have no idea what the "community" wants--and I'm not convinced that
the data we
have available lets us assess that, for the usual reasons about the
difficulty of doing
accurate surveying--but speaking solely for myself, I'm at IETF to
work, so my priorities
center around the things that make it easy to get work done. This
basically boils down
to cost  and convenience.

Within these general parameters, my priorities are something like:
1. Cost:
- Travel
- Hotel

Rationale: airfare tends to not be that flexible, but it's generally
possible to find a cheaper
hotel if you try (as several people have observed). However, if the
conference hotel
is $300/night, then this is probably going to trickle down some into
cheaper hotels so
it's not like hotel doesn't matter.


2. Convenience:
- Length of trip.
- Local services

Rationale: travel time is time I'm not working (yeah, we all try, but
I'm not that effective
and I suspect most people are not.) Lack of local services means less
time meeting
and more time rushing around trying to find lunch before the next
meeting, walking to
and from the hotel, etc.


I'm certainly not opposed to interesting venues, but I would say it's
worth about $200-300
to me on a typical IETF trip.  I would be more than happy to have all
IETFs at some small number of convenient, economical venues. E.g.,
Vancouver, Prague,
and (insert Asian Venue here.) [0] Obviously, we can't optimize for
these criteria
at once for everyone, but it's equally the case that there are plenty
of venues which
don't really meet them that well for anyone.

-Ekr


[0] Prague isn't actually that convenient since it's one hop away from
Frankfurt. None of the
European venues have been that great for me from the standpoint of the
two criteria above,
since they're either far from a hub (Prague) or expensive (Paris). My
vote here would
probably be for Frankfurt, but that's probably just Star Alliance provincialism.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: "technical" plenary [was: A modest proposal for Friday meeting schedule]

[Eric Rescorla]

On Mon, Aug 1, 2011 at 4:52 PM, Brian E Carpenter
 wrote:

> In any case, the IRTF Report, IAB Report and RSOC Report could certainly be
> made in the other plenary.

Or omitted entirely, since they are duplicative of data which would be better
communicated in writing.

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

Re: Getting to Quebec City

[Eric Rescorla]

On Fri, Jun 17, 2011 at 5:08 PM, John Levine  wrote:
> As you may have noticed, flying to Quebec City (YQB) is incredibly
> expensive.  That's because it's a regional airport with little
> competion.  Flying to Montreal is usuallly a lot cheaper.  Getting
> from Trudeau airport in Montreal involves some planning, but it's not
> hard.  The trip is about four hours; Quebec is big, bigger than any
> state in the US.

Nitpick alert:

http://en.wikipedia.org/wiki/Quebec
http://en.wikipedia.org/wiki/List_of_U.S._states_and_territories_by_area

Quebec:   Land area=1,365,128 km2   Water Area=176,928 km2
Alaska:  Land Area: 1,481,347 km2  Water Area=236,507 km2

Perhaps you meant Continental US.

Best,
-Ekr
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [TLS] Last Call: (Additionx

[Eric Rescorla]

On Fri, Mar 11, 2011 at 8:07 AM, Martin Rex  wrote:
>> I don't recall why 12 bytes rather than 16 bytes or 20 was chosen.
>
> It is not unusual when a two group of folks (IPSEC and TLS) sourcing from
> the same pool of engineers and experts (IETF) have to do two very
> similar decisions (truncating HMAC-SHA-1) within a fairly short time,
> end up with the same conclusion.
>
>  http://www.ietf.org/html/rfc2404  Jan-1998  HMAC-SHA-1-96 (for IPSEC)
>  http://www.ietf.org/html/rfc2246  Jan-1999  TLSv1.0
>
>
> The dates vs. rfc-numbers of these two documents look strange:
> The dates indicate they were published one year apart, but given
> their rfc-numbers, one would intuitively expect their dates to
> be just the other way round.

TLS 1.0 was held up in process for a long time due to normative
dependency issues
vis-a-vis PKIX.

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

Re: [TLS] Last Call: (Additionx

[Eric Rescorla]

If your question is why did the TLS WG decide to do this back in like
1996 or so?

If so, it would require a real archive search to get a definitive
answer, but my vague
memory is that (a) it was suggested by one of the cryptographers in
the group, e.g.
Hugo Krawczyk or Ran Canetti and (b) it was motivatated by the desire to
limit the amount of information disclosed about the MS (remember that it used to
be 36 bits!). I don't recall why 12 bytes rather than 16 bytes or 20 was chosen.

Best,
-Ekr


On Thu, Mar 10, 2011 at 11:20 PM, Nikos Mavrogiannopoulos
 wrote:
> On 03/11/2011 12:28 AM, Stephen Kent wrote:
>
 It wasn't any "may have become first popular", there was only
 room for 96 bits of MAC data in the IP packet, so MD5 was
 truncated to that size.
>>>
>>> This is an odd claim, since:
>>>
>>> (a) RFC 1828 (http://tools.ietf.org/html/rfc1828) originally
>>> specified not HMAC but a keyed MD5 variant with a 128-bit output.
>>> (b) The document that Martin points to has MACs > 96 bits long.
>>>
>>> Can you please point to where in IP there is a limit that requires
>>> a MAC no greater than 96 bits.
>>>
>>> -Ekr
>>
>> What Peter probably meant to say was that IPsec chose to truncate the
>> HMAC value to 96 bits because that preserved IPv4 and IPv6
>> byte-alignment for the payload.  Also, as others have noted, the hash
>> function used here is part of an HMAC calculation, and any collisions
>> have to be real-time exploitable to be of use to an attacker.  Thus
>> 96 buts was viewed as sufficient.
>
> This sounds pretty awkward decision because HMAC per record is full
> (e.g. 160-bits on SHA-1), but the MAC on the handshake message
> "signature" is truncated to 96-bits. Why wasn't the record MAC
> truncated as well? In any case saving few bytes per handshake
> is much less of value than saving few bytes per record. Was
> there any other rationale for truncation?
>
> regards,
> Nikos
>
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [TLS] Last Call: (Additionx

[Eric Rescorla]

On Wed, Mar 9, 2011 at 7:28 AM, Nikos Mavrogiannopoulos  wrote:
> On Wed, Mar 9, 2011 at 3:34 PM, Eric Rescorla  wrote:
>
>>> I'm not a specialist in MAC algorithms but by checking
>>> the ECRYPT II[0] report of 2009-2010, I can try making some points.
>>> A MAC has a security level that depends on the size of the MAC
>>> and the size of the key. That is a 12-byte MAC has security level of
>>> MIN(2^{key_size}, 2^{96}) [1], irrespective of the key size used.
>>> As I understand the addition of SHA-384 as PRF was to increase
>>> the security margin of TLS comparing to the SHA-1 PRF. This
>>> is not occuring now because a MAC based on algorithm that
>>> returns 384-bits and truncates it  to 96 can offer nothing more
>>> than an algorithm that outputs 160 bits and are trucated to 96.
>>> Hence there is no significant difference than SHA-1 or SHA-384
>>> in that case, so why define SHA-384 anyway?
>> If you recall, the reason why TLS 1.2 was done was not primarily because
>> of concerns about SHA-1's 160-bit output being large enough but because
>> people started developing analytic attacks on MD5 and SHA-1 that brought
>> it's security level down below the nominal level.
>> In other words, there are many applications where 80 bits of security is
>> fine, but people don't want to use SHA-1 because they don't trust it.
>
> Such things should be explicit then. In any case I think there is a mistake
> here since RFC5288 defines the AES-256 ciphersuites with SHA-384 as
> PRF, and the AES-128 ciphersuites with SHA-256, thus there was
> intention to match the security strength of the cipher with the size
> of the hash.
>
> If this wasn't the intention, then it is pretty much misleading, and should
> be explicit. E.g. Although we define SHA-384 as PRF in this ciphersuite, it
> is being truncated in 96 bits. The choice for SHA-384 was because .

I'm not one of the authors of that draft, but I imagine for the usual
reason of tiling
the space of algorithms (not that I consider it a great reason.)

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

Re: [TLS] Last Call: (Additionx

[Eric Rescorla]

On Wed, Mar 9, 2011 at 1:10 AM, Nikos Mavrogiannopoulos  wrote:
> On Tue, Mar 8, 2011 at 7:51 PM, Eric Rescorla  wrote:
>>>> Perhaps, but this isn't a digest but rather a MAC, and so the attack
>>>> model is different.
>>> You seem to be forgetting that the finished messages have been reused
>>> for other purposes already:
>> No, I'm not forgetting that. That doesn't change the fact that the
>> computation is
>> a MAC.
>
> I'm not a specialist in MAC algorithms but by checking
> the ECRYPT II[0] report of 2009-2010, I can try making some points.
> A MAC has a security level that depends on the size of the MAC
> and the size of the key. That is a 12-byte MAC has security level of
> MIN(2^{key_size}, 2^{96}) [1], irrespective of the key size used.
>
> As I understand the addition of SHA-384 as PRF was to increase
> the security margin of TLS comparing to the SHA-1 PRF. This
> is not occuring now because a MAC based on algorithm that
> returns 384-bits and truncates it  to 96 can offer nothing more
> than an algorithm that outputs 160 bits and are trucated to 96.
> Hence there is no significant difference than SHA-1 or SHA-384
> in that case, so why define SHA-384 anyway?

If you recall, the reason why TLS 1.2 was done was not primarily because
of concerns about SHA-1's 160-bit output being large enough but because
people started developing analytic attacks on MD5 and SHA-1 that brought
it's security level down below the nominal level.

In other words, there are many applications where 80 bits of security is
fine, but people don't want to use SHA-1 because they don't trust it.


> For me the ciphersuites defined in TLS should have a uniform
> security level. I.E. why use AES-256 with security level of 2^256
> but use a MAC for a handshake of 2^96 bits?

Because the attack model for MACs is not the same as the attack model
for encryption. The encryption is susceptible to offline attack, whereas
with a MAC all you need to do is get the guessing probability sufficiently
low because *any* failed forgery causes connection termination.

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

Re: [TLS] Last Call: (Additionx

[Eric Rescorla]

Overflowing by another 32 bits is hardly the same as "there was only room for"

-Ekr


On Wed, Mar 9, 2011 at 1:57 AM, Peter Gutmann  wrote:
> Eric Rescorla  writes:
>
>>Can you please point to where in IP there is a limit that requires a MAC no
>>greater than 96 bits.
>
> The AH had room for exactly 96 bits of MAC value, any more and it'd have to
> overflow to another 32 bits worth (the size of the non-MAC data is 96 bits and
> the MAC data adds the other 96 bits), see RFC 2402.  The original AH used a
> 64-bit data field (RFC 1826) and didn't truncate MD5 (RFC 1828), so it was
> also 192 bits long.  With the expansion of the non-MAC data to 96 bits, it was
> necessary to truncate the MAC to keep the same overall size.
>
> Peter.
>
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [TLS] Last Call: (Additionx

[Eric Rescorla]

On Tue, Mar 8, 2011 at 3:55 PM, Peter Gutmann  wrote:
>
> Martin Rex  writes:
>
>>Truncating HMACs and PRFs may have become first popular in the IETF within
>>IPSEC.
>
> It wasn't any "may have become first popular", there was only room for 96 bits
> of MAC data in the IP packet, so MD5 was truncated to that size.

This is an odd claim, since:

(a) RFC 1828 (http://tools.ietf.org/html/rfc1828) originally specified
not HMAC but a keyed MD5 variant
with a 128-bit output.
(b) The document that Martin points to has MACs > 96 bits long.

Can you please point to where in IP there is a limit that requires a
MAC no greater than 96 bits.

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

Re: [TLS] Last Call: (Additionx

[Eric Rescorla]

On Tue, Mar 8, 2011 at 12:19 PM, Martin Rex  wrote:
> resend (Sorry, for the typos.)
>
>
> Martin Rex wrote:
>>
>> The truncation of hashes/PRFs/HMACs is a trade-off.
>>
>> A trade-off between collision-resistance and how much clue
>> is provided about the input.
>
>  TLSv1.0 (rfc2246) references RFC-2104 (HMAC)
>  TLSv1.1 (rfc4346) contains a normative reference to RFC-2104 (HMAC)
>  TLSv1.2 (rfc5246) contains a normative reference to RFC-2104 (HMAC)
>
> http://tools.ietf.org/html/rfc2104#section-5
>
>  5. Truncated output
>
>                                                            Applications
>   of HMAC can choose to truncate the output of HMAC by outputting the t
>   leftmost bits of the HMAC computation for some parameter t (namely,
>   the computation is carried in the normal way as defined in section 2
> !  above but the end result is truncated to t bits). We recommend that
> !  the output length t be not less than half the length of the hash
> !  output (to match the birthday attack bound) and not less than 80 bits
>   (a suitable lower bound on the number of bits that need to be
>   predicted by an attacker).


Ok, but this is just a handwavy rationale. As far as I'm aware, the
actual cryptographic
analysis is as Hovav has stated.

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

Re: [TLS] Last Call: (Additionx

[Eric Rescorla]

On Tue, Mar 8, 2011 at 10:45 AM, Martin Rex  wrote:
> Eric Rescorla wrote:
>>
>> Marsh Ray wrote:
>> >
>> > I think he's arguing that anything cut down to 96 bits represents a lousy
>> > hash function allowing practical collisions on today's hardware.
>>
>> Perhaps, but this isn't a digest but rather a MAC, and so the attack
>> model is different.
>
> You seem to be forgetting that the finished messages have been reused
> for other purposes already:

No, I'm not forgetting that. That doesn't change the fact that the
computation is
a MAC.


>   RFC-5929 TLS Channel Bindings
>   RFC-5746 TLS extension Renegotiation indication
>
>
> I'm sorry, but I think it is a bad idea to use a flawed design for
> the TLS finished message by subverting the collision resistence
> of stronger secure hash functions that are used for the PRF.

Yes, I realize you think that, but until you offer a cryptographic
argument for that
opinion I guess we're just going to have to disagree.

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

Re: [TLS] Last Call: (Additionx

[Eric Rescorla]

On Tue, Mar 8, 2011 at 10:30 AM, Martin Rex  wrote:
> Eric Rescorla wrote:
>>
>> On Tue, Mar 8, 2011 at 10:07 AM, Martin Rex  wrote:
>> > Eric Rescorla wrote:
>> >>
>> >> On Tue, Mar 8, 2011 at 9:20 AM, Martin Rex  wrote:
>> >> > Eric Rescorla wrote:
>> >> >>
>> >> >> I don't understand this reasoning. Why does the output size of the
>> >> >> pre-truncated PRF
>> >> >> influence the desirable length of the verify_data (provided that the
>> >> >> output size is > than
>> >> >> the length of the verify_data of course).
>> >> >
>> >> > One of the purposes of a cryptographic hash function is to protect
>> >> > from collisions (both random and fabricated collisions).
>> >> >
>> >> > Cutting down the SHA-384 output from 48 to 12 octets significantly 
>> >> > impairs
>> >> > its ability to protect from collisions.  It's comparable to
>> >> > truncating the SHA-1 output from 20 to 5 octets.
>> >>
>> >> I don't understand this analysis. Consider two ideal PRFs:
>> >>
>> >> * R-160 with a 160-bit output
>> >> * R-256 with a  256-bit output
>> >>
>> >> Now, consider the function R-256-Reduced,
>> >> which takes the first 160 bits of R-256.
>> >> Are you arguing that R-256-Reduced is weaker than R-160? If so, why?
>> >
>> > What we're having are the two cases:
>> >
>> >  1)  R-160 truncated to 96 bits
>> >  2)  R-256 truncated to 96 bits
>> >  3)  R-160 with full 160-bits
>> >
>> >
>> > If your primary focus was collision avoidance, then
>> > 3) is stronger than 1) and 2) by a huge margin.
>>
>> Yes, I totally agree.
>>
>>
>> > There may be reasons why you don't want (3), like an attackers ability
>> > to verify when he guesses keys correctly that are input to the PRF.
>> >
>> > When 20/12 is a good truncation ratio for a 160-bit PRF,
>> > then 48/12 looks like a poor truncation ratio for a 384-bit PRF
>> > (and SHA-384 is already a truncated SHA-512 anyway).
>> > Applying the 20/12 tradeoff to R-256 results in approximately (32/20)
>> > and to R-384 results in approximately (48/28) -- with (48/32) probably
>> > sufficiently close.
>>
>> I don't understand this analysis at all. Again, are you arguing that
>> (1) and (2) have different security properties?
>
> In case they were both "ideal" - no.
>
> But in that case, asking anyone for the effort to replace
> 1) with 2) would be a complete waste of resources.
>
>
> If we move in a new, stronger crypto-algorithm, then we should not
> unreasonably spoil its properties.
>
> Truncating a SHA-384 based PRF to 12 octets is like using
> an sha384WithRsaEncryption signature with a 1024 bit RSA key,
> it is an imbalanced pairing of algorithms&keys.

Again, I don't understand this: TLS already (as of TLS 1.0) truncated
the PRF down
to 12 bytes, so we are already producing an output that is
substantially shorter than
the digest that is the basis of the function. If the security
arguments for why that
is good are valid (and FWIW I think they are) then as far as I can
tell they are
equally applicable to SHA-384.

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

Re: [TLS] Last Call: (Additionx

[Eric Rescorla]

On Tue, Mar 8, 2011 at 10:15 AM, Marsh Ray  wrote:
> On 03/08/2011 11:33 AM, Eric Rescorla wrote:
>>
>> On Tue, Mar 8, 2011 at 9:20 AM, Martin Rex  wrote:

>>> Cutting down the SHA-384 output from 48 to 12 octets significantly
>>> impairs
>>> its ability to protect from collisions.  It's comparable to
>>> truncating the SHA-1 output from 20 to 5 octets.
>
> I think it's more comparable truncating SHA-1 down to 12 octets.

Yes, this matches my analysis.


>> I don't understand this analysis. Consider two ideal PRFs:
>>
>> * R-160 with a 160-bit output
>> * R-256 with a  256-bit output
>>
>> Now, consider the function R-256-Reduced, which takes the first 160
>> bits of R-256.
>> Are you arguing that R-256-Reduced is weaker than R-160? If so, why?
>
> I think he's arguing that anything cut down to 96 bits represents a lousy
> hash function allowing practical collisions on today's hardware.

Perhaps, but this isn't a digest but rather
a MAC, and so the attack model is different. Without knowing the key, you
basically have a 2^{-b} chance of producing an input which will pass the MAC
check, where b is the length of the MAC. Note that additional computational
power doesn't help much here because you still need to search the entire
key space, not the output space, in order to break the MAC.

However, the answer to *this* question is a distinct from whether a different
size hash function used as the basis for a MAC demands a different truncation.

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

Re: [TLS] Last Call: (Additionx

[Eric Rescorla]

On Tue, Mar 8, 2011 at 10:07 AM, Martin Rex  wrote:
> Eric Rescorla wrote:
>>
>> On Tue, Mar 8, 2011 at 9:20 AM, Martin Rex  wrote:
>> > Eric Rescorla wrote:
>> >>
>> >> I don't understand this reasoning. Why does the output size of the
>> >> pre-truncated PRF
>> >> influence the desirable length of the verify_data (provided that the
>> >> output size is > than
>> >> the length of the verify_data of course).
>> >
>> > One of the purposes of a cryptographic hash function is to protect
>> > from collisions (both random and fabricated collisions).
>> >
>> > Cutting down the SHA-384 output from 48 to 12 octets significantly impairs
>> > its ability to protect from collisions.  It's comparable to
>> > truncating the SHA-1 output from 20 to 5 octets.
>>
>> I don't understand this analysis. Consider two ideal PRFs:
>>
>> * R-160 with a 160-bit output
>> * R-256 with a  256-bit output
>>
>> Now, consider the function R-256-Reduced,
>> which takes the first 160 bits of R-256.
>> Are you arguing that R-256-Reduced is weaker than R-160? If so, why?
>
> What we're having are the two cases:
>
>  1)  R-160 truncated to 96 bits
>  2)  R-256 truncated to 96 bits
>  3)  R-160 with full 160-bits
>
>
> If your primary focus was collision avoidance, then
> 3) is stronger than 1) and 2) by a huge margin.

Yes, I totally agree.


> There may be reasons why you don't want (3), like an attackers ability
> to verify when he guesses keys correctly that are input to the PRF.
>
> When 20/12 is a good truncation ratio for a 160-bit PRF,
> then 48/12 looks like a poor truncation ratio for a 384-bit PRF
> (and SHA-384 is already a truncated SHA-512 anyway).
> Applying the 20/12 tradeoff to R-256 results in approximately (32/20)
> and to R-384 results in approximately (48/28) -- with (48/32) probably
> sufficiently close.

I don't understand this analysis at all. Again, are you arguing that
(1) and (2) have
different security properties?

If not, then why does it matter what the size of the input PRF is, as
long as it is >=
the size to which it is truncated?

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

Re: [TLS] Last Call: (Additionx

[Eric Rescorla]

On Tue, Mar 8, 2011 at 9:20 AM, Martin Rex  wrote:
> Eric Rescorla wrote:
>>
>> I don't understand this reasoning. Why does the output size of the
>> pre-truncated PRF
>> influence the desirable length of the verify_data (provided that the
>> output size is > than
>> the length of the verify_data of course).
>
> One of the purposes of a cryptographic hash function is to protect
> from collisions (both random and fabricated collisions).
>
> Cutting down the SHA-384 output from 48 to 12 octets significantly impairs
> its ability to protect from collisions.  It's comparable to
> truncating the SHA-1 output from 20 to 5 octets.


I don't understand this analysis. Consider two ideal PRFs:

* R-160 with a 160-bit output
* R-256 with a  256-bit output

Now, consider the function R-256-Reduced, which takes the first 160
bits of R-256.
Are you arguing that R-256-Reduced is weaker than R-160? If so, why?

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

Re: [TLS] Last Call: (Additionx

[Eric Rescorla]

I don't understand this reasoning. Why does the output size of the
pre-truncated PRF
influence the desirable length of the verify_data (provided that the
output size is > than
the length of the verify_data of course).

-Ekr


On Tue, Mar 8, 2011 at 7:59 AM, Martin Rex  wrote:
> Sean Turner wrote:
>> >
>> > Yours was the first document I noticed to use SHA384 as PRF. If there
>> > are other documents that specify that, and don't set the verify_data_length
>> > size then it applies to those as well. (just noticed that applies to 
>> > RFC5288
>> > as well).
>>
>> If the verify_data_length default is 12 (from 5246) then saying nothing
>> means that it's still 12 right?  Or, do you think an explicit statement
>> saying "the default value for verify_data_length of 12 is used" is needed?
>
>
> Truncating the PRF output to 12 octets for TLSv1.2 seems like an error.
>
> If truncating a SHA-1 based PRF in TLSv1.0/TLSv1.1 to 12 Octets is
> considered adequate (20/12), then truncation in TLSv1.2 with
> a SHA-256 based PRF should have been (32/20) and truncation for
> a SHA-384 based PRF should be more like (48/28) or (48/32).
>
> To me, Truncating the output of a SHA-384 PRF to 12 Octets looks like
> unreasonable cutdown of the security margin for the Finished messages.
>
> -Martin
> ___
> TLS mailing list
> t...@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [TLS] Last Call: (Datagram Transport Layer Security version 1.2) to Proposed Standard

[Eric Rescorla]

On Mon, Dec 20, 2010 at 11:01 AM, Juho Vähä-Herttua  wrote:
> On 20.12.2010, at 15.15, Pekka Savola wrote:
>> 3.2.3. Message Size
>>
>>   TLS and DTLS handshake messages can be quite large (in theory up to
>>   2^24-1 bytes, in practice many kilobytes).  By contrast, UDP
>>   datagrams are often limited to <1500 bytes if fragmentation is not
>>   desired.  In order to compensate for this limitation, each DTLS
>>   handshake message may be fragmented over several DTLS records.  Each
>>   DTLS handshake message contains both a fragment offset and a fragment
>>   length.
>>
>> 4.1.1. Transport Layer Mapping
>>
>>   Each DTLS record MUST fit within a single datagram.  In order to
>>   avoid fragmentation, clients of the DTLS record layer SHOULD attempt
>>   to size records so that they fit within any PMTU estimates obtained
>>   from the record layer.
>>
>> ... these seem somewhat contradictory.  Maybe I'm missing something.  The
>> latter seems to be saying that DTLS implementations should try to avoid IP
>> fragmentation, but the former seems to imply that it's de-facto mode of
>> operation.
>
> These are not contradictory. If a handshake message size and record header 
> don't fit inside single datagram, it should be fragmented into several small 
> handshake messages and each of these is put into a separate DTLS record. The 
> resulting DTLS record after encryption should not exceed the maximum UDP (or 
> DCCP or whatever) datagram size and therefore doesn't need IP level 
> fragmentation.
>
> I think what you "missed" was simply the difference of IP level fragmentation 
> and DTLS handshake protocol level fragmentation.

I think that is a lot of the issue here. We probably don't distinguish
these clearly. Given that I don't want to change terminology now
I suggest we just say "DTLS fragmentation" and "IP fragmentation".
It's clunky but serviceable.

WRT to the ICMP issue, my take on this is that ICMP Isn't reliable
both because of filtering and that it implies connected
sockets. So, the application needs to be able to determine PMTU even
if it never gets any kind of error indication. However,
I agree that if the stack does get an explicit error it MUST adjust.

The rest of Pekka's suggestions make sense and I should be able to
implement them.
-Ekr
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP

[Eric Rescorla]

On Tue, Feb 1, 2011 at 2:14 AM, Magnus Westerlund
 wrote:
> Cullen Jennings skrev 2011-01-31 18:44:
>>
>> Magnus, I agree with what you are saying here but you are avoiding the issue 
>> I am concerned with. Is allocating a second port for the secure version of a 
>> document a frivolous use case or not? I read this draft as saying it is. 
>> Others read the draft as saying it is not and that type of allocation is 
>> fine. This seems fairly easy to deal with - first lets agree if particular 
>> 2nd port for secure version is a reason to reject requests or not then see 
>> if any text needs to be adjusted in the draft to reflect that.
>
> Well, frankly I don't know. I think it is something that can be avoided
> going forward in many use cases, but not all. Simply by thinking of this
> issue in the design phase. In addition there is clearly other solutions
> there other considerations, like NAT traversal has said, yes
> multiplexing is a must, thus live with even higher complexity costs.
>
> The issue I have a problem with is that is we say on general basis that
> due to negotiation of security protocols we are allowed to use different
> ports for negotiation or simply usage of it. Then why is that different
> from different versions of the protocol, or feature support. What is the
> difference for a security protocol compared to these other issues?
>
> What I am worried here is that we will see an increased port consumption
> rather than a decreased one. At the current run rate I think the
> estimate is 50 years+ before run out. That is something that I am
> reasonably comfortable, but if the consumption rate increases four
> times, then I am suddenly not comfortable. So I am pretty certain that
> we need to aim at lowering the consumption rather than raising it.
>
> As I see it there are only one way of doing it.
>
> - State clearly that you really need to do everything reasonable so that
> your application is only for one port.
> - Be reasonably tough from the expert reviewer to ensure that applicants
> has done this.
>
> And from that perspective I don't think security is special in anyway.
> It is only one of several things that could potentially require
> additional registered ports. Yes security is important, but as
> previously discussed it doesn't appear that the actual level of security
> provided is different if you are forced to use one port or two. It might
> affect the ease of implementation and deployment of security, which is
> another aspect of impact.
>
>
> Cheers
>
> Magnus Westerlund
>
> --
> Multimedia Technologies, Ericsson Research EAB/TVM
> --
> Ericsson AB                | Phone  +46 10 7148287
> Färögatan 6                | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerl...@ericsson.com
> --
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP

[Eric Rescorla]

On Tue, Feb 1, 2011 at 10:26 AM, Joe Touch  wrote:
>
>
> On 2/1/2011 10:00 AM, Eric Rescorla wrote:
>>
>> On Tue, Feb 1, 2011 at 9:39 AM, Joe Touch  wrote:
>>>
>>> To clarify some of this discussion, providing some context that might be
>>> useful:
>>>
>>> 1) the current doc already explicitly states the procedures for
>>> assignment
>>> in each range of ports (see Sec 8.1.1).
>>>
>>> 2) Sec 8.1.1 *already* states that IESG approval through IETF process is
>>> a
>>> valid path for assignment, distinct from Expert Review. Since that
>>> appears
>>> to be a point of confusion, I'll quote it directly:
>>>
>>>   o  Ports in the User Ports range (1024-49151) are available for
>>>      assignment through IANA, and MAY be used as service identifiers
>>>      upon successful assignment.  Because assigning a port number for a
>>>      specific application consumes a fraction of the shared resource
>>>      that is the port number registry, IANA will require the requester
>>>      to document the intended use of the port number.  This
>>>      documentation will be input to the "Expert Review" procedure
>>>      [RFC5226], by which IANA will have a technical expert review the
>>>      request to determine whether to grant the assignment.  The
>>>      submitted documentation MUST explain why using a port number in
>>>      the Dynamic Ports range is unsuitable for the given application.
>>>      Ports in the User Ports range may also be assigned under the "IETF
>>>      ^^
>>>      Review" or "IESG Approval" procedures [RFC5226], which is how most
>>>      ^^
>>>      assignments for IETF protocols are handled.
>>>      ^^^
>>
>> For the purposes of clarification, then, this document has no impact
>> whatsoever
>> on ports assigned through the IESG process? I.e., if my WG submits a
>> proposed
>> standard document to the IESG and it asks for two ports, I'm not going to
>> get
>> pushback based on the claim that this document imposes a presumption that
>> that's wrong?
>
> The ONLY impact is in the format of information required for an assignment.
>
> (i.e., yes, if you're asking that there's no change to the process, that's
> correct)
>
> However, IANA can still pushback, and can use whatever advice it sees fit to
> do so, during IESG review. You can get that pushback now. This document
> doesn't change that AT ALL.

I'm sorry, but I'm still not clear.

This document has an affirmative statement against the use of multiple
ports for TLS.

AFAIK that statement is not part of present written policy. Is that correct?

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

Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP

[Eric Rescorla]

On Tue, Feb 1, 2011 at 9:39 AM, Joe Touch  wrote:
> To clarify some of this discussion, providing some context that might be
> useful:
>
> 1) the current doc already explicitly states the procedures for assignment
> in each range of ports (see Sec 8.1.1).
>
> 2) Sec 8.1.1 *already* states that IESG approval through IETF process is a
> valid path for assignment, distinct from Expert Review. Since that appears
> to be a point of confusion, I'll quote it directly:
>
>   o  Ports in the User Ports range (1024-49151) are available for
>      assignment through IANA, and MAY be used as service identifiers
>      upon successful assignment.  Because assigning a port number for a
>      specific application consumes a fraction of the shared resource
>      that is the port number registry, IANA will require the requester
>      to document the intended use of the port number.  This
>      documentation will be input to the "Expert Review" procedure
>      [RFC5226], by which IANA will have a technical expert review the
>      request to determine whether to grant the assignment.  The
>      submitted documentation MUST explain why using a port number in
>      the Dynamic Ports range is unsuitable for the given application.
>      Ports in the User Ports range may also be assigned under the "IETF
>      ^^
>      Review" or "IESG Approval" procedures [RFC5226], which is how most
>      ^^
>      assignments for IETF protocols are handled.
>      ^^^

For the purposes of clarification, then, this document has no impact whatsoever
on ports assigned through the IESG process? I.e., if my WG submits a proposed
standard document to the IESG and it asks for two ports, I'm not going to get
pushback based on the claim that this document imposes a presumption that
that's wrong?

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

Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP

[Eric Rescorla]

On Tue, Feb 1, 2011 at 8:38 AM,   wrote:
> +1 to everything Magnus says here. THis is exactly how I view the multiple 
> port
> issue.

I'll respond to this separately.


> I will also add that at least part of this fuss seems to be concern about how
> "human oversight is needed but what if the overseer misbehaves" issue. 
> Speaking
> as someone who has been doing IANA reviews for well over a decade, it is
> absolutely the case that a reviwer's actions can screw up a registry. But the
> solution to this problem is not to overconstrain the review process - we've
> tried that approach and found it causes more problems than it solves - but
> rather to have proper checks and balances in the process itself. I believe the
> current specified process - once you understand the details, which
> unfortunately are a bit difficult to track through all the various
> specifications - is sufficient to deal with this.

Others may have that concern but it's not my concern.

My concern is rather that the reviewer get the correct guidance, and
in this case
that guidance appears to be that he ought to be pushing back on protocols which
desire to use one port for the insecure version and one port for the
secure version,
and I'm not really that comfortable with that.

-Ekr


>                                Ned
>
>> Cullen Jennings skrev 2011-01-31 18:44:
>> >
>> > Magnus, I agree with what you are saying here but you are avoiding the 
>> > issue I am concerned with. Is allocating a second port for the secure 
>> > version of a document a frivolous use case or not? I read this draft as 
>> > saying it is. Others read the draft as saying it is not and that type of 
>> > allocation is fine. This seems fairly easy to deal with - first lets agree 
>> > if particular 2nd port for secure version is a reason to reject requests 
>> > or not then see if any text needs to be adjusted in the draft to reflect 
>> > that.
>
>> Well, frankly I don't know. I think it is something that can be avoided
>> going forward in many use cases, but not all. Simply by thinking of this
>> issue in the design phase. In addition there is clearly other solutions
>> there other considerations, like NAT traversal has said, yes
>> multiplexing is a must, thus live with even higher complexity costs.
>
>> The issue I have a problem with is that is we say on general basis that
>> due to negotiation of security protocols we are allowed to use different
>> ports for negotiation or simply usage of it. Then why is that different
>> from different versions of the protocol, or feature support. What is the
>> difference for a security protocol compared to these other issues?
>
>> What I am worried here is that we will see an increased port consumption
>> rather than a decreased one. At the current run rate I think the
>> estimate is 50 years+ before run out. That is something that I am
>> reasonably comfortable, but if the consumption rate increases four
>> times, then I am suddenly not comfortable. So I am pretty certain that
>> we need to aim at lowering the consumption rather than raising it.
>
>> As I see it there are only one way of doing it.
>
>> - State clearly that you really need to do everything reasonable so that
>> your application is only for one port.
>> - Be reasonably tough from the expert reviewer to ensure that applicants
>> has done this.
>
>> And from that perspective I don't think security is special in anyway.
>> It is only one of several things that could potentially require
>> additional registered ports. Yes security is important, but as
>> previously discussed it doesn't appear that the actual level of security
>> provided is different if you are forced to use one port or two. It might
>> affect the ease of implementation and deployment of security, which is
>> another aspect of impact.
>
>
>> Cheers
>
>> Magnus Westerlund
>
>> --
>> Multimedia Technologies, Ericsson Research EAB/TVM
>> --
>> Ericsson AB                | Phone  +46 10 7148287
>> Färögatan 6                | Mobile +46 73 0949079
>> SE-164 80 Stockholm, Sweden| mailto: magnus.westerl...@ericsson.com
>> --
>> ___
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP

[Eric Rescorla]

On Mon, Jan 31, 2011 at 2:11 PM, Eliot Lear  wrote:
> Eric,
>> Clearly, if you're going to do a negotiation design you want a single port.
>> If you're going to do a non-negotiated design, then I don't see a huge
>> amount of value in using a single port. It's true that there is a port
>> consumption issue, but OTOH ports are there for protocol demuxing and
>> this is clearly another protocol.
>
> Another way to look at this is that it's the same protocol running atop
> a security layer.  Same protocol engine, perhaps in a slightly different
> security context in terms of what is authorized.  And there's good
> reason to look at it this way.  Aside from the leverage it gives
> reviewers as I discussed previously, there's also the minor matter of
> port consumption, which won't be so minor if we run short.  And don't
> think that can't happen.  Additional ports are being approved for
> reasons that are clearly architecture limitations.  I'm not even sure
> this is an acceptable excuse.

Really? What fraction of the port space has been consumed?


> For one, if we look at some of the examples that have been mooted, I
> doubt that an additional port would have solved the downgrade problem.
> The case I have in mind is indeed SMTP.  The conditions that allow for
> the downgrade attack have more to do with the realities of certificate
> management than STARTTLS.

I didn't say it did, if you reread my message. What I said was that
not negotiating
addresses downgrade.


> As I wrote in a different context there is also the draft that Paul has
> written for HASTLS, which allows a server to express a policy without
> having to require a port.  While some of us have some questions about
> some of the choices Paul made in the design, on the whole I think
> everyone agrees it's a good idea.

Well, I'm not sure I see the relevance of this. The question is how
the server supports
both secure and insecure variants at once.




>>  It's simply a lot easier to have
>> your TLS stack just start its thing rather than try to autodetect
>> whether you have TLS or some other protocol.
>
> Maybe so (wasn't so hard for me),

Well, I have no idea what protocol you're thinking of, but all of the
upward negotiation
protocols have a significantly more complicated state machine than does HTTPS.


>but there now is a whole lot of free
> code out there that does just this.

And it's generally all protocol specific, so we have this problem with
every new protocol.


>>  So I would generally push
>> back on the claim that non-negotiated designs should have to have
>> demuxing in information in the dataflow rather than use the port.
>
> There is a cost that extends beyond the protocol.  That has to be taken
> into account.

Of course. Which is why I'm not saying that you should ALWAYS do a
separate port.
But I don't agree there is consensus that it's bad either.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP

[Eric Rescorla]

On Mon, Jan 31, 2011 at 11:41 AM, Eric Rescorla  wrote:
> So first, we already have a BCP that says  more or less all protocols must 
> implement a secure version but deployment is optional. This is a good BCP, 
> and it comes from the right area to say that - security. It's probably 
> impacts design work in working groups more than any other BCP. It has IETF 
> consensus. The IESG holds protocols to this.
>
> Now - I am at loss to see why forcing people to use one port will make it 
> more likely to have secure protocols. This seems crazy.  Please do enlighten 
> me.

I don't think it does.

At a high level, there are three ways in which insecure and secure
versions (by which I mostly mean channel security mechanisms such as
TLS) of the same protocol can coexist:

1. They can operate on totally different transport parameters (e.g., ports)
2. They can be demuxable by some indicator that's simply sent by one
side and accepted or rejected by the other side. (E.g., "If the first
byte is 20 this is TLS, else it's not)
3. It can be negotiated as in STARTTLS

In the first two of these, the client knows which version it wants
(secure or insecure) and there is no chance for the server to indicate
otherwise other than failing the connection. In the third, the sides
negotiate. So, I think the first question is which general design you
wish to have. Each of these have their merits: negotiation designs are
more complicated but allow for opportunistic security. Unfortunately,
they also allow for downgrade attack, as the experience with STARTTLS
for SMTP shows. By contrast, non-negotiation designs are easier to
implement and provide for referential integrity but not for
opportunistic security. IMO there is a place for both, though I
generally tend towards non-negotiated designs, in part out of a
feeling that the world would be better if people used encryption all
the time.

Clearly, if you're going to do a negotiation design you want a single port.
If you're going to do a non-negotiated design, then I don't see a huge
amount of value in using a single port. It's true that there is a port
consumption issue, but OTOH ports are there for protocol demuxing and
this is clearly another protocol. It's simply a lot easier to have
your TLS stack just start its thing rather than try to autodetect
whether you have TLS or some other protocol. So I would generally push
back on the claim that non-negotiated designs should have to have
demuxing in information in the dataflow rather than use the port.


> And on the topic, I'm still looking forward to an explanation of how the 
> current CoAP design stomping all over the TLS code points would be an 
> acceptable design.

I don't consider this an acceptable design and I've already told the
CoAP authors and chairs so. Speaking as chair, if the CoAP
authors/chairs wish to pursue this avenue they should bring it to the
TLS WG, which AFAIK they have not done.

-Ekr



>
> On Jan 31, 2011, at 9:27 , Eliot Lear wrote:
>
>>
>>
>> On 1/31/11 5:13 PM, Cullen Jennings wrote:
>>> Hmm ... I don't agree that solves the issue.
>>>
>>> Well lets say the request was coming from 3GPP for a protocol they designed 
>>> - why should IANA be able to tell them no but IETF yes.
>>
>> Who, ultimately, is the steward of this precious resource?  If it is not
>> the IANA and it is not the IETF, then who?  To say that it is everyone's
>> responsibility is to avoid responsibility entirely.  Who gets to say
>> which standards organizations are stewards and which are not?
>>
>>> I think the policy issue here is fairly clear. We do not have consensus 
>>> that in all cases that one should not have a second port for security (I'm 
>>> basing this assertion on Magnus read of WG consensus and my read of IETF LC 
>>> consensus). Therefore that should not be a ground for the expert reviewer 
>>> (or IANA) to reject the registration. The document needs to be updated to 
>>> make that clear or it does not reflect consensus. If the authors of the 
>>> draft want to propose text for conditions when it would be ok to reject a 
>>> second port for security purposes and see if they can get consensus for 
>>> that text, that seems perfectly reasonable.
>>
>> This is a VERY VERY dangerous approach you propose, Cullen.  It is akin
>> to saying, "you can think about security later, because we'll have to
>> give you a port for it later."  We don't want to be saying that.
>>
>
>
> Cullen Jennings
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>
>
>
>
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: draft-ietf-tls-renegotation: next steps

[Eric Rescorla]

At Wed, 16 Dec 2009 10:53:37 +0100,
 wrote:
> - The current draft doesn't clearly say what should be included in
> legacy (insecure) renegotiation ClientHellos. I am not sure if we have
> enough clear opinions to call consensus, but keeping it aligned with
> the initial ClientHello (either MSCV or extension) seems to be one
> simple approach (but I hope to see the actual text).

Attached is some candidate text that attempts to implement this. 

  It is possible that un-upgraded servers will request that the client
  renegotiate.  It is RECOMMENDED that clients refuse this
  renegotiation request.  Clients which do so MUST respond to such
  requests with a "no_renegotiation" alert [RFC 5246 requires this
  alert to be at the "warning" level.]  It is possible that the
  apparently un-upgraded server is in fact an attacker who is then
  allowing the client to renegotiate with a different, legitimate,
  upgraded server.  In order to detect this attack, clients which
  choose to renegotiate MUST provide either the
  TLS_RENEGO_PROTECTION_REQUEST SCSV or "renegotiation_info" in their
  ClientHello.  In a legitimate renegotiation with an un-upgraded
  server, either of these signals will be ignored by the server.
  However, if the server (incorrectly) fails to ignore extensions,
  sending the "renegotiation_info" extension may cause a handshake
  failure.  Thus, it is permitted, though NOT RECOMMENDED, for the
  client to simply send the SCSV.  This is the only situation in which
  clients are permitted to not send the "renegotiation_info" extension
  in a ClientHello which is used for renegotiation.

  Note that in the case of this downgrade attack attack above, if this
  is the initial handshake from the server's perspective, then use of
  the SCSV from the client precludes detection of this attack by the
  server.  However, the attack will be detected by the client when the
  server sends an empty "renegotiation_info" extension and the client
  is expecting one containing the previous verify data.  By contrast,
  if the client sends the "renegotiation_info" extension, then the
  server will immediately detect the attack.

After flip-flopping on this in my head a few times, however, my
personal view, is that I think this goes too far in the direction of
accomodating broken servers. Sending RI in this instance only creates
an interop problem when a server (1) is doing something we know to be
really unsafe and (2) can't even ignore extensions correctly. We've
seen a number of suggestions that we actually forbid renegotiation in
case (1) and while I suspect WG consensus doesn't go that far, it's not
clear to me that we need to not only allow it but also compensate for
servers which are broken in other respects. So, my preference would
be to simply mandate RI with the previous verify_data here as in
all other cases.


> I've asked the document editor to update the draft as soon as
> possible. The IESG will discuss this document this Thursday (December
> 17), and I hope we can have an approved specification before
> Christmas.

I'm working on revisions now.

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

Re: IETF Plenary Discussions

[Eric Rescorla]

At Wed, 11 Nov 2009 18:56:45 -0500,
Russ Housley wrote:
> 
> I did not take the comment as disrespectful.  A timer might be a very 
> good experiment.

And indeed used to be common practice.

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

Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer Security (TLS) Extensions: Extension Definitions) to Proposed Standard

[Eric Rescorla]

At Wed, 23 Sep 2009 15:04:00 -0400 (EDT),
Dean Anderson wrote:
> 
> Is that insecure?
> 
> If the client is authorized by certificate, then it seems that it has 
> that identity in addition to any application level identities.
> 
> The only insecurity is if the certifiate private key has been
> compromised, which isn't something that TLS can protect against.
> 
> One problem with using TLS for virtual web hosts is that the server
> names cannot match the single name allowed in the certificate.  I don't
> want to see that get worse; I'd like to see it get better.

The server_name extension [RFC 4366] allows this.

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

Re: Request for community guidance on issue concerning a future meeting of the IETF

[Eric Rescorla]

At Wed, 23 Sep 2009 11:17:04 -0700 (PDT),
Ole Jacobsen wrote:
> 
> 
> 
> On Wed, 23 Sep 2009, Eric Rescorla wrote:
> 
> > So, this isn't really that useful context for the rest of the
> > paragraph. To take the example of encryption, I think people
> > were arguing that it was a topic "regarding human rights".
> > 
> > With that said, it's not clear to me that saying "China's policy
> > of censoring the Internet sucks" isn't defamation. 
> 
> I would say that this DOES border on defamation, BUT I am at a loss 
> to understand why such a statement would be a required part of our 
> technical discussion. The statement is an opinion about a topic which 
> there is a lot more that can be said, but like the baby said "this 
> isn't the venue." (Let's just say that it isn't well understood in
> the west). "X policy sucks" sound like politics and not technology
> particularly if X is a country.

Sure, but I've heard plenty of stuff like this said in the IETF,
indeed in this very discussion. So, while you may not think
that those are appropriate statements, ISTM that we do in fact
have a situation in which common IETF speech potentially runs
afoul of this restriction.


> If on the other hand you were to say: "I am upset about the way 
> provider Y in country X does aggregation in BGP because this degrades 
> performance of..." you would have little to worry about beyond perhaps 
> a technical argument.

I'm not a lawyer, but my understanding is that this is in fact defamatory
speech within the legal sense that prevails in the US. (That doesn't
make it illegal in the US. First Amendment, etc.)


> > I'll rephrase my question then:
> > Is your claim that you believe that the contract would not be
> > found in a court of law to cover the described activities?
> > 
> 
> If by "activities" you mean "technical discussions" that are a normal 
> part of any IETF meeting, then yes.

In that case, can you please post your analysis of the other ORed parts
of the original clause that supports that conclusion?

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

Re: Request for community guidance on issue concerning a future meeting of the IETF

[Eric Rescorla]

At Wed, 23 Sep 2009 10:15:05 -0700 (PDT),
Ole Jacobsen wrote:
> 
> 
> On Wed, 23 Sep 2009, Eric Rescorla wrote:
> 
> > I'm sorry, I don't see the difference between (a) and (c). Either our
> > activities violate the language of the contract or they don't. You say
> > that you don't agree that our activities violate the language. If so,
> > that's good news, but it would help if you shared your analysis so
> > that people who are concerned can come to the same conclusion as you.
> 
> A litte bit of context is always helpful. Notice that the first 
> sentence in the clause says "...defamation against the Government 
> of the People's Republic of China..."
> 
> Discussing encryption and its uses, for example, is not defamation fo 
> any government unless you set it up as laundry list of "what's wrong
> with this country" (for any value of country) which isn't something
> you typically do at the IETF.

Uh, that clause is ORed with other clauses:

   "Should the contents of the Group's activities, visual or audio
   presentations at the conference,or printed materials used at the
   conference (which are within the control of the Client) contain
   any defamation against the Government of the People's Republic
   of China, or show any disrespect to the Chinese culture, or
 ^^ ^^
   violates any laws of the People's Republic of China or feature
   ^^ 
   any topics regarding human rights or religion without prior
   approval from the Government of the People's Republic of China,
   the Hotel reserves the right to terminate the event on the spot
   and/or ask the person(s) who initiates or participates in any or
   all of the above action to leave the hotel premises immediately.

So, this isn't really that useful context for the rest of the
paragraph. To take the example of encryption, Ithink people
were arguing that it was a topic "regarding human rights".

With that said, it's not clear to me that saying "China's policy
of censoring the Internet sucks" isn't defamation. 


> > > a) Not discuss our usual topics
> > > b) Stage a political rally
> > > 
> > > The offending hotel clause, simply put, is a reminder of b.
> > 
> > Now I'm really confused, because *this* sounds like my alternative
> > (b) above. 
> > 
> > Perhaps what you're saying here is that (1) the contract doesn't 
> > prohibit these activities and (2) even if if did, our counterparties 
> > can be trusted not to interpret it in a way we would find 
> > objectionable. If so, I have to say I don't find this particularly 
> > comforting: as I've seen no analysis to support (1) [and several 
> > analysis which suggest the contrary], and (2) relying on intentions 
> > rather than contract language seems like an extraordinarily unsafe 
> > practice given the costs to us of having a meeting cancelled (even 
> > if we're not on the hook for paying the hotel a bunch of money).
> 
> Any language in any law or contract in any context is subject to 
> interpretation and judgement.

Sure.

I'll rephrase my question then:
Is your claim that you believe that the contract would not be
found in a court of law to cover the described activities?

-Ekr


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

Re: Request for community guidance on issue concerning a future meeting of the IETF

[Eric Rescorla]

At Mon, 21 Sep 2009 07:01:22 -0700 (PDT),
Ole Jacobsen wrote:
> 
> 
> On Mon, 21 Sep 2009, Eric Rescorla wrote:
> 
> > I'm not really following you here. I've read the stated contract
> > terms and I'm concerned that they prohibit activities which may
> > reasonably occur during IETF. Are you saying:
> > 
> > (a) No, they don't prohibit those activities.
> > (b) Yes, they do prohibit those activities, but they won't actually
> > be enforced that way.
> > 
> > If you're saying (a), I'd be interested in seeing your analysis of 
> > why that is the case, since my own analysis indicates the contrary. 
> > Indeed, it seems to me that this very discussion we are having now 
> > (which clearly is an appropriate IETF discussion), violates a number 
> > of the terms.
> 
> What I am saying is (c) that you have listed a set of topics and 
> concluded that they violate the contract, I don't agree. 

I'm sorry, I don't see the difference between (a) and (c). Either our
activities violate the language of the contract or they don't. You say
that you don't agree that our activities violate the language. If so,
that's good news, but it would help if you shared your analysis so
that people who are concerned can come to the same conclusion as you.


> I have stated 
> what I believe to be the INTENTION of the language in the contract, 
> namely prevent political protest at the meeting. I have now attended 
> 68 out of 75 IETF meetings, but I have never seen "political protest" 
> of the form that I think might lead to a meeting being shut down in 
> China. Yes, we are a rowdy bunch at times, and we discuss a lot of 
> technical things that spill over into layer 9, but let me repeat what 
> I said earlier: There is no way the host, with the understanding of 
> the government, would invite us to meet in China if they expected us 
> to:
> 
> a) Not discuss our usual topics
> b) Stage a political rally
> 
> The offending hotel clause, simply put, is a reminder of b.

Now I'm really confused, because *this* sounds like my alternative
(b) above. 

Perhaps what you're saying here is that (1) the contract doesn't
prohibit these activities and (2) even if if did, our counterparties
can be trusted not to interpret it in a way we would find
objectionable. If so, I have to say I don't find this particularly
comforting: as I've seen no analysis to support (1) [and several
analysis which suggest the contrary], and (2) relying on intentions
rather than contract language seems like an extraordinarily unsafe
practice given the costs to us of having a meeting cancelled
(even if we're not on the hook for paying the hotel a bunch of
money).

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

Re: Request for community guidance on issue concerning a future meeting of the IETF

[Eric Rescorla]

At Tue, 22 Sep 2009 22:22:31 -0500,
Pete Resnick wrote:
> On 9/22/09 at 2:50 PM -0400, Ray Pelletier wrote:
> 
> >The language in the contract is a statement of the law and is 
> >intended to put the Host and group on notice of such. If the 
> >language were not in the contract, it would still be the law.
> 
> Certainly the part about "defamation", "show any disrespect", and 
> "violates any laws" (which, according to Marshall's original message, 
> includes certain politicial statements and protest marches) are 
> clearly a statement of the law as others have explained in this 
> thread. I've heard nothing so far that indicates that the rest of the 
> clause (with regard to terminating the event or the hotel or host 
> having responsibility for the enforcement) is any part of the law.

This is exactly right.

Reasoning by analogy is always dangerous, but let me suggest an
analogy: say that we wanted to have an IETF in an area that had
a lot of hurricanes. Now, the likelihood of a hurricane is not
something we can control--I don't expect to negotiate with 
national law--but the extent to which it effects the IETF is
at least partly within the hotel's control. So, one could imagine
a number of clauses about what happens in the event of a hurricane
in which the hotel becomes unusable:

- The event is cancelled and lose all our money.
- The event is cancelled but the hotel refunds a prorated portion
  of our money.
- The event is cancelled but the hotel pays a large indemnity
  (thus allowing us to have a replacement event).

Note that we can't get rid of the risk of hurricanes, but we can
control who bears that risk. 

Now, this isn't a perfect analogy, since in the case of an IETF
meeting, we do have limited control of the risk of the meeting being
cancelled (though the IETF's control of it is really extremely
limited, since they have such limited control over their members) and
since the hotel's control over the situation is probably more limited
here--but whether they unilaterally cancel the meeting at any hint of
wrongdoing is likely to be in their control. However, I think the
basic point remains: this contract seems to make the host and the IETF
bear a large amount of risk which could be shifted to others.  It's
not at all clear to me that that point can't be negotiated with the
hotel. Why would that be dictated by the Chinese government?

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

Re: Request for community guidance on issue concerning a future meeting of the IETF

[Eric Rescorla]

At Sat, 19 Sep 2009 15:28:06 -0700 (PDT),
Ole Jacobsen wrote:
> I don't think the rules were written with a group like the IETF in 
> mind. I also don't think, in fact I am pretty certain, that the hotel 
> staff would be the ones who decide to shut down the meeting or take 
> other action. I am sure what would happen, in practice, is that the 
> *local host* would intervene, warn the offender and that would 
> probably be the end of it. This assumes there was ever anything for 
> the hotel or host to complain about in the first place which is 
> something I also doubt,  unless someone in our community decides 
> that they want to push the boundaries and prove a point. That is 
> frankly my ONLY worry about this matter. The Chinese government is, by 
> now, well aware of what a typical IETF meeting looks like and would 
> not have granted permission for the meeting to take place if they 
> expected us to stage a political rally, but just in case we should be 
> so inclined, there is a set of rules spelled out (albeit broadly) in 
> the text we are discussing.

I'm not really following you here. I've read the stated contract
terms and I'm concerned that they prohibit activities which may
reasonably occur during IETF. Are you saying:

(a) No, they don't prohibit those activities.
(b) Yes, they do prohibit those activities, but they won't actually
be enforced that way.

If you're saying (a), I'd be interested in seeing your analysis
of why that is the case, since my own analysis indicates the
contrary. Indeed, it seems to me that this very discussion
we are having now (which clearly is an appropriate IETF discussion),
violates a number of the terms.

If you're saying (b), then I have to say I don't find that very
reassuring.


> I assure you that there is no intention to have WG materials 
> pre-screened or anything of the sort, heck they're never ready on time 
> anyway ;-) And I honestly do not think that anyone should plan on 
> being more careful than usual about what they say in general WG 
> discussions or plenaries. The meeting should be like any other IETF
> meeting in terms of content.
> 
> So, we can do what Steve Crocker suggests, go to China with a positive
> attitude or stay home and wonder what might have happened.

I'm a little puzzled by "stay home". It's not like the world
is divided into "China" and "Home". In what way are Hiroshima,
Anaheim, and Maastricht, to pick three random examples any more 
"Home" than China?

-Ekr


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

Re: Request for community guidance on issue concerning a future meeting of the IETF

[Eric Rescorla]

At Sat, 19 Sep 2009 15:55:55 -0400,
Steve Crocker wrote:
> The choice is between engaging and not engaging.  Engaging is better.   
> Not engaging isn't constructive.  The Internet and the IETF are all  
> about engaging, expanding, communicating and being open.  Much of this  
> dialog has been worried about possible extreme situations.  Let's  
> focus on the center.  More than a billion people live in China and  
> their use of the Internet is expanding rapidly.  They are building  
> much of the technology and contributing technically.  It's to  
> everyone's advantage to have comfortable, constructive interaction.   
> Our first slogan was "Networks Bring People Together."
> 
> If you prefer to focus on the negatives, here's my analysis:
> 
> If we don't go to China, we have charted a downhill course and the  
> rest of the world will come together without us.  The IETF will lose  
> relevance.
> 
> If we do go to China and something bad happens, the consequences will  
> be much worse for China than for the IETF.  The work of the IETF will  
> suffer a bit, but we'll recover quickly enough.  However, China's  
> quest for engagement with the rest of the world will be hurt more  
> seriously.
> 
> Bottom line: We should go to China with a positive attitude.  We're  
> robust enough to deal with any consequences.  If we don't go to China,  
> however, we have weakened ourselves.

I'm not necessarily disagreeing with this analysis, but I'm not sure
it's a complete analysis.

We've been offered a deal under certain terms that at least some of
the community aren't comfortable with. Now, it might well be true that
it's better to take those terms than not if those were the only two
options, but that's not the case here. In particular, we can refuse to
take those terms now and instead attempt to negotiate for terms that
we find more acceptable. It seems to me that even under the analysis
you've laid out that's a superior course of action.

-Ekr




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

Re: Request for community guidance on issue concerning a future meeting of the IETF

[Eric Rescorla]

> The Chinese government has imposed a rule on all conferences held
> since 2008 regarding political speech. A fundamental law in China
> requires that one not criticize the government. Practically, this
> has reference to public political statements or protest marches, which
> are not the IETF's custom. The government, which is a party to the issue,
> requires that people who attend conferences in China (the IETF being
> but one example) not engage in political speech during their tour
> in China. We consider this to be acceptable, on the basis that the
> IETF intends to abide by the laws of whatever nations it visits and
> we don't believe that this impacts our ability to do technical work.
>
> The rule is implemented in the Hotel agreement and reads (note that
> the "Client" would be the Host, and the "Group" would be the IETF) :
> 
>   "Should the contents of the Group's activities, visual or audio
>   presentations at the conference,or printed materials used at the
>   conference (which are within the control of the Client) contain
>   any defamation against the Government of the People's Republic
>   of China, or show any disrespect to the Chinese culture, or
>   violates any laws of the People's Republic of China or feature
>   any topics regarding human rights or religion without prior
>   approval from the Government of the People's Republic of China,
>   the Hotel reserves the right to terminate the event on the spot
>   and/or ask the person(s) who initiates or participates in any or
>   all of the above action to leave the hotel premises immediately.
> 
>   The Client will support and assist the Hotel with the necessary
>   actions to handle such situations. Should there be any financial
>   loss incurred to the Hotel or damage caused to the Hotel's
>   reputation as a result of any or all of the above acts, the Hotel
>   will claim compensation from the Client."
> 
> What does this condition mean ? The hotel staff would have, in theory,
> the legal right to shut down the meeting and ask the offending
> participants to leave the property immediately. While we do not
> foresee a situation where such action would take place, we feel that
> it is proper to disclose these conditions to the community.

It's not entirely clear to me what these conditions mean, so
maybe it's worth trying to parse them a bit. ISTM that there are
a bunch of potential questions about their interpretation:

1. What materials are covered under this? This could include any
   of [in roughly descending order of "officialness"]:
   (a) Materials printed in the program [Do we have a program?]
   (b) Materials presented by IETF management (IAB, IESG, etc.)
   (c) Speech by IETF management
   (d) Materials presented by WG participants
   (e) Speech by WG participants

2. What exactly is covered by the restriction on "any defamation
   against the Government of the People's Republic of China, or show
   any disrespect to the Chinese culture, or violates any laws of the
   People's Republic of China or feature any topics regarding human
   rights or religion"?

3. What recourse, if any, do we have if the hotel staff judge that
   the lines above have been crossed?

4. What, if anything, is the IETF on the hook for if the conference
   is cancelled?


None of these seem entirely clear from the text above. In the
maximal (and most worrisome) interpretation, the hotel staff, in their
sole discretion, could choose to cancel the entire IETF because a
single WG participant says something about Taiwan in the course of a
WG discussion. If that's in fact the controlling interpretation, then
that seems distinctly problematic. 

Is it really that bad? Let's take a deeper look at each term:

1. The materials covered are specified as:

"Should the contents of the Group's activities, visual or audio
presentations at the conference,or printed materials used at the
conference (which are within the control of the Client)"

Except for the final parenthetical, this seems to include all of
(a)-(e). The relevant question then becomes what the meaning
of the final parenthetical is, and in particular, who the
Client is. I suppose one could argue that the Client is just
IASA and so all that's relevant is presentations from IAOC
(or more liberally from the I*). However, if you argue that
the client is IETF then clearly the IETF management *could*
control what people present (E.g., require pre-clearance of
slides) and say (by cutting off the microphones). So, I don't
think this is particularly clear. It doesn't seem to me that
we would really have much of an argument that presentations
at the plenary aren't "within the control of the Client",
however. That said, I think the natural interpretation is
that anything that's on the agenda falls into this category--if
people want to interpret it differently, we should get a 
legal opinion to that effect--or better yet, get the
terms modified to make it clear.


2. The offensive topics are described a

Re: Some more background on the RFID experiment in Hiroshima

[Eric Rescorla]

At Sun, 13 Sep 2009 21:19:53 -0700 (PDT),
Ole Jacobsen wrote:
> 
> 
> Eric,
> 
> The local hosts are reading the messages on this list and will take 
> appropriate steps including:
> 
> * Not displaying the ID number <--> attendee mapping anywhere
> 
> * Not assigning numbers sequencially

That seems like a good start. As Richard and I have both indicated,
however, this system seems to have substantial residual privacy
risk, even if the identifiers are assigned completely unpredictably
(and note that non-sequential and unpredictable are not at all the
same thing). 


> Again, anyone may opt out, but this IS an experiment and it is 
> certainly hoped that people will participate.

I'm not trying to be difficult, but I'm not overly impressed with the
defense that people keep offering that this is an experiment and
people can opt out. If this were being done as an experiment at a
university, you would be expected to go in front of a human subjects
committee and demonstrate that your subjects had given informed
consent, probably wouldn't be harmed, etc. Now, obviously, this isn't
an academic setting, but I think it's fair to say that the people
running this experiment haven't done anything like full disclosure of
the relevant risks--and it's not even clear that they understand them
themselves. [It would also be consistent with common practice for
people to specifically opt in, not out.]

Now, I'm not saying that the IETF can never experiment with anything
(e.g., a new brand of pen at registration) without going through this
kind of review, but given that there has historically been quite a bit
of concern about the about the privacy implications of this sort of
RFID tagging (see, for instance, the issue of RFID tags in passports)
and that several people have raised concerns about this particular
use, ISTM that a somewhat higher bar is appropriate.  I'm not sure
exactly what I would consider meaningful for such an experiment in
order for participants to be fully informed, but it seems to me that
at minimum it would be the sort of security analysis that we would
expect to be provided in an I-D under RFC 3552.

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

Re: Some more background on the RFID experiment in Hiroshima

[Eric Rescorla]

At Fri, 11 Sep 2009 07:57:02 -0700 (PDT),
Ole Jacobsen wrote:
> 
> 
> Inline.
> 
> On Fri, 11 Sep 2009, Eric Rescorla wrote:
> 
> > At Thu, 10 Sep 2009 12:23:31 -0700 (PDT),
> 
> > > * Each attendee will be issued an RFID card at the registration desk. 
> > >   The information stored on the card is ONLY a number, no personal 
> > >   data is stored on the card. (Note: the attendee can opt out at any
> > >   time, including not collecting the card, see below).
> > 
> > Note that removing your name from the database doesn't remove the
> > ability of someone to track you via the tag.
> 
> If this is a great concern I would suggest either returning the card 
> or not collecting it in the first place. Also, the type or readers 
> used require close proximity to trigger, you literally have to touch 
> the reader with your card to make it work. So nobody from the host 
> organization at least will be tracking you. I am also not sure what 
> value there is in knowing that 3478273983421 spent 10 minutes in trill 
> and then moved on to behave (pun intended).

Well, I think it's important to distinguish two different threat
scenarios: 

1. Tracking via the sensors that IETF has emplaced.
2. Tracking via sensors that others emplace [it's important to
   note that just because the readers you have are low power
   and can only work at close range, that doesn't mean it's not
   possible to have readers that work at longer ranges.]

In the first scenario, it's probably true that you can only
gather limited amounts of information, but in the second scenario,
the amount of information that can be gathered is limited primarily
by the number of sensors you're willing to emplace. I can 
imagine a number of scenarios where it would be attractive
to know where a given individual is at all times (for starters,
people often have private side meetings with customers at IETF
and if you had positional information you might be able to learn
about this). I certainly would not want to be tracked everywhere
I went.

This brings us to the question of the identifiers: it's certainly
true that systems which are anonymous but linkable offer a higher
level of privacy than those which do not. However, it's often
possible to determine which identifier a given person has 
(e.g., by observing a specific persons card being read), then
you can of course track them by name. In addition, if the
identifier->person mapping isn't generated securely and kept
confidential, then you may be able to quickly determine a
large fraction of the mapping.


> > > * The "information" (number) on the card is not encrypted and could be 
> > >   read by any RFID reader, but again, it's only a number.
> > 
> > How are the numbers assigned?
> 
> Don't know, but I have asked. I am guessing they are pre-assigned in 
> the sense that each card has a unique ID that is later mapped to the
> database.

OK, but the details matter here. For instance, if you have a stack
of cards with sequential serial numbers and you assign them in
sequence to the people in the attendee list (e.g., at the time
right before the meeting), you wouldn't need to know too many 
mappings to determine most of the database.


I'm not trying to make an argument for or against this experiment:
I don't even expect to be in Hiroshima, so it doesn't really 
matter to me one way or the other. However, given that the IETF has
extensive experience in this kind of secure systems design and
in fact has an entire WG (GEOPRIV) devoted to thinking about the
dissemination and privacy of positional information, it seems like
it would be nice to get a little more clarity about the security
of the proposed system.

-Ekr


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

Re: Some more background on the RFID experiment in Hiroshima

[Eric Rescorla]

At Thu, 10 Sep 2009 12:23:31 -0700 (PDT),
Ole Jacobsen wrote:
> 
> 
> An Overview of the RFID Experiment for IETF 76 in Hiroshima.
> 
> 
> Some of the details are still being worked out, but here is a summary:
> 
> Basics
> --
> 
> * Each attendee will be issued an RFID card at the registration desk. 
>   The information stored on the card is ONLY a number, no personal 
>   data is stored on the card. (Note: the attendee can opt out at any
>   time, including not collecting the card, see below).

Note that removing your name from the database doesn't remove the
ability of someone to track you via the tag.


> * The "information" (number) on the card is not encrypted and could be 
>   read by any RFID reader, but again, it's only a number.

How are the numbers assigned?


> * The number is "linked" to a back-end database through the readers 
>   provided at the meeting.
>
> * The database will contain only the following information from the
>   registration data:
> 
> First Name, Last Name, Affiliation (if present), and ISO-3166 Code
> 
> * Each attendee will also be issued a username and password. This will
>   give him/her access to the back-end database (via a web interface)
>   where the user can:

Does the Web UI make sure to hide the number->attendee mapping?

-Ekr

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

Re: Important Information about IETF 76 Meeting Registration

[Eric Rescorla]

At Thu, 10 Sep 2009 05:05:08 -0700,
Joel Jaeggli wrote:
> 
> 
> 
> Eric Rescorla wrote:
> 
> > Can you clarify what, if any, the security properties of this system
> > are:
> > 
> > In particular:
> > 
> > 1. Will the RFID tag in question respond to any reader or just those
> >controlled by the secretariat?
> > 2. Is the information on the tag in the clear or encrypted?
> 
> normal 125khz tags don't contain much data. The radio equivalent of a 1
> dimensional barcode is just a serial number. any data is a product of
> association with that token stays in the network rather than the chip.
> These are vulnerable to (trivial) replay attacks. but challenge response
> requires more logic. more powerful card systems of course exist in
> profusion it's just a matter of picking one.

Yes. This is why I asked.

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

Re: Important Information about IETF 76 Meeting Registration

[Eric Rescorla]

Alexa Morris writes:
> My apologies, I actually thought that I'd responded to this.
> 
> Handheld readers will be passed around the meeting rooms, much as the  
> clipboards are now (and still will be). Individuals will swipe their  
> card through the reader and pass it on. Once collected, the data will  
> be used as the current Blue Sheet data is used, that is, to respond to  
> subpoena requests for attendance at different sessions typically  
> issued during a dispute over intellectual property. At the moment, we  
> are planning to print out a copy of the electronically obtained data  
> and store it with the regular blue sheets, then keep the source file  
> with the rest of our electronic archives.
> 
> The data collected consist solely of an individuals full name and  
> company/organization affiliation. We are not collecting email address  
> information on the e-blue sheets.

Alexa,

Can you clarify what, if any, the security properties of this system
are:

In particular:

1. Will the RFID tag in question respond to any reader or just those
   controlled by the secretariat?
2. Is the information on the tag in the clear or encrypted?

My general experience with RFID systems suggests that the answer to
these questions is likely to be "yes" and "in the clear", but I'd
certainly be pleasantly surprised to hear otherwise.

Thanks,
-Ekr








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

Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard

[Eric Rescorla]

At Wed, 22 Jul 2009 09:59:38 +,
Florian Weimer wrote:
> Anyway, those who object to the ECC infection should strive to remove
> it from the base TLS spec.  It doesn't make sense to rehash this
> discussion over and over again, for each draft produced by the WG
> which happens to be compatible with ECC algorithms and for which
> Certicom files an IPR claim.

Note: ECC isn't in the base spec, really. 

More precisely, the code points are defined in 4492. 

All the ECC that's defined in 5246 is the rules for what sorts of
certificates may be used for a given algorithm, and that's because
5246 changed the rules beyond 4346 and so we wanted to have them all
in one place.

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

Re: [TLS] Last Call: draft-ietf-tls-extractor (Keying Material Exporters for Transport Layer Security (TLS)) to Proposed Standard

[Eric Rescorla]

At Mon, 20 Jul 2009 15:15:53 -0400 (EDT),
Dean Anderson wrote:
> 
> I am against this standard because of its patent encumbrances and
> non-free licencing terms.  The working group did not get any clear
> answers on what particular patents this draft may infringe, but a patent
> holder (Certicom) did assert an IPR disclosure (1004) listing many
> patents.  We have no alternative but to accept the Certicom disclosure
> statements as meaning that the TLS Extractor draft is patent-encumbered
> without a universal, free defensive license.

This isn't really a complete description of the situation.

As others have stated, Certicom's has a variety of patents that
apply to ECC technology. When TLS Extractor (or indeed any other
IETF technology) is used with the TLS ECC cipher suites, then
there is a potential issue with regard to Certicom's patents,
but that issue is produced not by Extractor, but by the use
of ECC. After Certicom's disclosure (1004), there were
questions about whether Certicom's IPR also applied to Extractor
with non-ECC cipher suites.

During this discussion, Certicom posted a clarification:
http://www.ietf.org/mail-archive/web/tls/current/msg03508.html

It is our intention to foster broad adoption of ECC technology.  The
grant is meant to cover any necessary Certicom patents and patent
applications to implement RFC 4492, RFC 5289 or the
draft-rescorla-tls-suiteb when used with draft-ietf-tls-extractor.  It
is not making any statement to the draft-ietf-tls-extractor when used
absent of these three cipher suites.

You can find the new disclosure at: https://datatracker.ietf.org/ipr/1153/.

In addition, Certicom posted:
(see also http://www.ietf.org/mail-archive/web/tls/current/msg03526.html),
which reads in part:

   Section V of the form, "Disclosure of Patent Information (i.e.,
   patents or patent applications required to be disclosed by Section 6
   of RFC 3979)," has been updated.  Subsection C highlights the specific
   RFCs and I-Ds that are believed to be covered by the patents and
   patent applications listed in Schedule A of the linked IPR
   contribution
   
(http://www.certicom.com/images/pdfs/certicom%20-ipr-contribution-to-ietfsept08.pdf).
   Please note that no version of the draft_ietf_tls_extractor appears in
   this section.

I consider this pair of statements combined with the IPR statement quite
satisfactory. You of course are free to feel differently.

-Ekr





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

Re: Extending the Dean Anderson PR-action to lists on tools.ietf.org

[Eric Rescorla]

At Fri, 17 Apr 2009 15:43:25 -0400,
Theodore Tso wrote:
> > I'll take the liberty of assuming that there's general
> > agreement that this is not okay, and the issue under
> > discussion is how to respond.  In terms of response
> > there are two issues: 1) preventative steps, and 2)
> > punitive steps.  I'm not sure there are steps that can
> > be taken to prevent someone from doing this without
> > losing a significant degree of openness, and I think
> > it's obvious that that's too high a price to pay.
> > As for punishment, I'm just not sure.  There have
> > been a few PR actions against Anderson so far and he
> > doesn't seem to be behaving any better, so whatever
> > punitive actions that have been taken seem to have
> > been ineffective.
> 
> The question I would ask is whether Dean has started subscribing AD's,
> WG chairs, etc. using the aliases provided by Henrik.  

As far as I know, the answer to this is "no".

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

Re: Extending the Dean Anderson PR-action to lists on tools.ietf.org

[Eric Rescorla]

Hi Henrik,

Henrik Levkowetz wrote:
> As a service to the community, there are two sets of email address alias
> lists maintaned on tools.ietf.org:
> 
> One list provides aliases for the WG chairs of all active working groups
> and also of chairs of working groups which have been closed recently, and
> also equivalent aliases for working group ADs, patterned so:
> -cha...@tools.ietf.org and -...@tools.ietf.org.
> 
> Another list provides aliases for draft authors, so that they can be
> reached through aliases following the pattern @tools.ietf.org.
> 
> The service is described briefly on http://tools.ietf.org/ under the 
> "Share and Communicate" heading.

First, I want to say that this is a great service. I do a fair number of
reviews and I use these aliases all the time... It's really become a
critical part of our infrastructure.


> As maintainer of these lists, I, Henrik Levkowetz, hereby let it be known
> that I have chosen to extend the posting rights action against Dean Anderson
> (see http://www4.ietf.org/iesg/pr-action.html) to also apply to these lists,
> according to the provisions for posting rights actions described on the above
> referenced web page and the references it mentions.

While this may be technically within the limits of 3683, I don't think
it comports well with the spirit of the document. To recap, the effect
of a PR-Action is that:

   o  those identified on the PR-action have their posting rights to
  that IETF mailing list removed; and,

   o  maintainers of any IETF mailing list may, at their discretion,
  also remove posting rights to that IETF mailing list.

>From the rest of the context of the document, I think it's reasonably
clear that the purpose of allowing maintainers of other mailing lists
to remove posting rights is to allow them to quickly respond to
disruptive behavior *on those lists*. In the case of WG or other
discussion lists, this is a reasonably good fit: the
maintainer of the list is generally the chair and so is responsible
for monitoring and facilitating discussion and is well position
to determine whether the subject of a PR action is disruptive.

However, this is not really the case for these lists, which are just
expanders for the relevant chairs, ADs, or draft authors. While you
may be maintaining the list in a technical sense, the recipients are
the ones who monitor the communication and are in a position to
determine whether it's disruptive or not. I don't think it fits well
with the intent of 3683 to have a global decision to be taken on all
these services by someone who is not involved in the discussion,
regardless of whether those involved have complained. I'm not saying
that PR Actions can't be extended to these aliases (though I think
that given Sam's comments it's an open question and given the ease of
expanding them directly it seems rather pointless) but in my opinion
at minimum it should be upon request of the recipients, not the
decision of a global maintainer.

Regardless of what the IETF's global policy is and without taking a
position on Dean Anderson's postings in general, I am not aware of him
having abused these services to send any inappropriate mail to me.
I therefore see no good reason to block what is otherwise a useful
communication channel. Accordingly, I hereby request that you unblock
his posting privileges to any and all of the above mentioned aliases
that send mail to me.

Best,
-Ekr







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

Re: [Ietf-honest] Consensus Call for draft-housley-tls-authz

[Eric Rescorla]

At Wed, 11 Mar 2009 02:00:31 -0400 (EDT),
Dean Anderson wrote:
> 
> On Fri, 6 Mar 2009, Lawrence Rosen wrote:
> Historical Note: They tried the experimental route before.  But
> Experimental RFC's aren't sufficient for an IANA code point.

Actually, in this case, an Experimental RFC is sufficient to assign
a code point. The requirement is 2434 IETF Consensus.

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

Re: Consensus Call for draft-housley-tls-authz

[Eric Rescorla]

At Fri, 6 Mar 2009 13:59:04 -0800,
Kurt Zeilenga wrote:
> 
> 
> On Mar 6, 2009, at 1:59 PM, Eric Rescorla wrote:
> 
> > At Fri, 6 Mar 2009 11:34:19 -0800,
> > Kurt Zeilenga wrote:
> >> I think if the IESG chooses not to publish draft-housley-tls-authz
> >> now, the authors should immediately take it RFC Editor for  
> >> publication
> >> and the IESG should not object to its timely publication.   In this
> >> case, the authors should not be asked to wait on a WG effort as they
> >> have done well, I think, to try to publish this through the IETF.  It
> >> would be disingenuous for us to now delay independent publication of
> >> this I-D via the RFC Editor.
> >
> > This avenue is specifically precluded by RFC 5246: draft-housley-tls- 
> > authz
> > contains new ExtensionType code points, and they can only be
> > assigned by IETF Consensus:
> >
> >   -  TLS ExtensionType Registry: Future values are allocated via IETF
> >  Consensus [RFC2434].  IANA has updated this registry to include
> >  the signature_algorithms extension and its corresponding value
> >  (see Section 7.4.1.4).
> >
> > Obviously, the authors can publish a document without code point
> > assignments, but it's hard to see what the value of that is.
> 
> The IETF can hold a consensus call on the assignment of code points  
> (certainly this question has not been answered by any previous call). 
> I would hope folks would place a lessor hurdle upon assignment of code
> points then they do for IETF RFC publication.

That's not what "IETF Consensus" means in the context of
RFC 2434:

  IETF Consensus - New values are assigned through the IETF
   consensus process. Specifically, new assignments are made via
   RFCs approved by the IESG. Typically, the IESG will seek
   input on prospective assignments from appropriate persons
   (e.g., a relevant Working Group if one exists).

-Ekr


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

Re: Consensus Call for draft-housley-tls-authz

[Eric Rescorla]

At Fri, 6 Mar 2009 11:34:19 -0800,
Kurt Zeilenga wrote:
> I think if the IESG chooses not to publish draft-housley-tls-authz  
> now, the authors should immediately take it RFC Editor for publication  
> and the IESG should not object to its timely publication.   In this  
> case, the authors should not be asked to wait on a WG effort as they  
> have done well, I think, to try to publish this through the IETF.  It  
> would be disingenuous for us to now delay independent publication of  
> this I-D via the RFC Editor.

This avenue is specifically precluded by RFC 5246: draft-housley-tls-authz
contains new ExtensionType code points, and they can only be
assigned by IETF Consensus:

   -  TLS ExtensionType Registry: Future values are allocated via IETF
  Consensus [RFC2434].  IANA has updated this registry to include
  the signature_algorithms extension and its corresponding value
  (see Section 7.4.1.4).

Obviously, the authors can publish a document without code point
assignments, but it's hard to see what the value of that is.

-Ekr


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

Re: Consensus Call for draft-housley-tls-authz

[Eric Rescorla]

At Fri, 6 Mar 2009 14:26:09 -0500,
Tim Polk wrote:
> 
> Folks,
> 
> After some time reflecting on the hundreds of messages submitted to  
> the IETF discussion list, I have come to several conclusions about  
> progressing draft-housley-tls-authz.  I will summarize the conclusions  
> up front, then provide the rationale for those decisions in the  
> remainder of this message.
> 
> 1. Last Call demonstrates that the community does not support  
> progression of this document on the standards track, but sufficient  
> support exists for publication as an Experimental RFC.
> 
> 2. The community would like the TLS working group to develop a  
> standards track mechanism for TLS authorization,

I'm not trying to be difficult, but I don't think this is
actually clear, as it's not the question the LC asked.

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

Re: Internet Society joins Liberty Alliance Management Board: Why?

[Eric Rescorla]

At Sun, 1 Mar 2009 19:59:00 +0200,
Hannes Tschofenig wrote:
> As you might have noticed, the WebSSO Identity Management space is not
> running out of organizations and groups. Someone could, for example, come up
> with the question why ISOC did not join the MIT Kerberos Consortium (see
> http://www.kerberos.org/), as Kerberos is a technology developed within the
> IETF, or to support technologies like OpenID, OAuth, etc. that are closer to
> the Internet deployment. 
> 
> I am sure your team had a lot of conversations with the IAB on what
> direction would be better for the Internet (with respect to the creation of
> an identity layer) but I fear that many in the IETF community are at best
> not informed about what you are doing and why you believe that this is
> heading into the right direction.

Did ISOC in fact have these discussions with the IAB? I'd be very interested
to hear the IAB weigh in here.

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

TLS WG Chair Comments on draft-ietf-tls-authz-07

[Eric Rescorla]

As chairs of the TLS Working Group, we request that the IESG not
approve draft-ietf-tls-authz-07 as a Proposed Standard. This document
was initially brought to the TLS WG, which passed on it due to lack of
interest and it was subsequently advanced as an individual submission,
but IESG approval was rescinded after the disclosure of IPR that
affected the document. These events occurred in late 2006 and early
2007. In the nearly two years since the previous attempts at
progressing the document, the authors have not coordinated with the
TLS WG. The TLS WG was not consulted prior to the start of this new
Last Call.

Although we recognize that opinions vary about the wisdom of advancing
documents as individual submissions, this does not seem like an edge
case to us. First, there is a functioning, relevant, working group:
TLS. While it is true that the WG did not object to advancement two
years ago, that was with the impression that it would be
uncontroversial, which clearly is not the situation. On the contrary,
the IPR situation remains quite unclear and there are also technical
issues with the document (see Eric Rescorla's separate review), as
well as at least one part of the document which is obsoleted by RFC
5246.  These factors provide substantial evidence that the document
would benefit from the Working Group process.

If the authors wish to advance the document on the standards track,
the appropriate path is to submit it to the TLS WG as a work item. TLS
WG has the appropriate participation and skills to evaluate the need
for this work and the suitability of this document.  If there is
sufficient support for work in this area (including the usual RFC 3979
IPR Evaluation), then it can advance through the standards track via
the WG process. If the authors don't wish to go through the WG
process, we do not oppose advancement of this document as
Experimental. However, we do not believe that advancing a two year old
document which is clearly in scope of an active WG is an appropriate
use of the individual submission process. Therefore we urge the IESG
not to approve this document.

Eric Rescorla
Joe Salowey
[TLS WG Chairs]
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Review of draft-ietf-tls-authz-extns-07

[Eric Rescorla]

SUMMARY
I do not believe this document should be advanced to Proposed Standard
at this time. First, it is not clear that there is really sufficient
interest in this document to justify it being at the PS level. Second,
despite several revisions to the RedPhone IPR disclosure, the IPR
status of this document remains unclear. Finally, there are technical
issues that should be fixed before the document advances at all.


BACKGROUND
This document was originally brought to the TLS WG, which expressed
little interest in it. It was subsequently sponsored as an individual
submission by then SEC AD Sam Hartman and approved by the IESG. 

Subsequent to IESG approval, one of the authors (Brown) filed an IPR
statement
(https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=765)
that claims to cover the technology. The listed terms were RAND but not
necessarily royalty-free. The IESG rescinded the approval of this
document and sent it back to last call. In the interim, two other IPR
statements have been filed, one by Stephen Farrell on work that he did
and a third party disclosure one by Eric Rescorla on some IBM
work. In the subsequent last call, there was not wide support
for the document and it was not approved. Recently, Brown revised
his IPR statement to assert that at least some usages of this 
draft are not covered by the relevant patent application
(https://datatracker.ietf.org/ipr/1026/) and that encumbered
usages would be subject to RAND licensing, leading to this fourth
last call.


IPR ISSUES
IMHO the IPR situation is substantially less clear than it has
been made out to be. First, there is is not one but three 
IPR disclosures, with the other two relating to Siemens and IBM. As
I stated in my previous review, I'm not too worried about the
IBM IPR, but the Siemens one is less available and it's harder
to evaluate, though the inventor, Steve Farrell says he thinks
it may not apply.

That still leaves the RedPhone IPR. As I indicated above,
the current IPR statement asserts that only some uses of this
document, not the document itself, are covered by the 
relevant patent application:

RedPhone Security hereby asserts that the techniques for sending and
receiving authorizations defined in TLS Authorizations Extensions
(version draft-housley-tls-authz-extns-07.txt) do not infringe upon
RedPhone Security's intellectual property rights (IPR). This statement
applies only to the IETF Document draft-housley-tls-authz-extns-07.txt
(hereafter the "Protocol Document").

The values provided in, and the processing required by the
authorizations ("authz_data" in the Protocol Document) sent or
received using the techniques defined in TLS Authorizations Extensions
are not specified in the Protocol Document. When an implementation
generates the authorizations or processes these authorizations in any
of the four ways described below, then this practice may be covered by
RedPhone Security's patent claims.

I have two concerns here. First, it is not clear to me that the 
four listed ways don't actually implicate a significant fraction
of the space. In particular, one very natural use of authorization
data is in coordination with legal agreements. However, this is 
specifically two of the four listed covered uses:

2. To store Agreements and locate Agreements based on authorization
data received from a sender, where Agreements are any legally
recognizable and documented agreement between two parties, including,
without limitation (a) agreements between governing bodies
(e.g. treaties, memoranda of understanding), (b) agreements created by
governing bodies (e.g. laws, edicts, orders), and (c) other agreements
enforceable by governing bodies (e.g. contracts, negotiable
instruments).

3. To compare the sender of authorization data to a stored collection
of Agreement signers.

So, in practice, many useful applications of this document are in
fact encumbered.

More troubling, however, is potential encumbrances outside of these
four uses. The assertion by RedPhone is just that, an assertion.  It
is not a license grant. If I implement the protocol described in this
document, I would still be vulnerable to an infringement suit by
RedPhone even if I did not use it in any of the four listed
ways. RedPhone would simply have to assert that upon reexamining the
patent it had concluded that the scope was more general than they had
previously sought. All RedPhone's assertion buys me is a defense
against willful infringement. To sharpen this point, consider the case
where RedPhone sold the patent to some other entity which then decided
to file suit.  This is not a purely theoretical worry. While I have
not studied the patent, a number of the claims seem rather broader
than what is described above and quite possibly cover all uses of the
protocol described in this document.


TECHNICAL ISSUES

TLS WG Chair Comments on draft-ietf-tls-authz-07

[Eric Rescorla]

[Resent with proper addressing information]

As chairs of the TLS Working Group, we request that the IESG not
approve draft-ietf-tls-authz-07 as a Proposed Standard. This document
was initially brought to the TLS WG, which passed on it due to lack of
interest and it was subsequently advanced as an individual submission,
but IESG approval was rescinded after the disclosure of IPR that
affected the document. These events occurred in late 2006 and early
2007. In the nearly two years since the previous attempts at
progressing the document, the authors have not coordinated with the
TLS WG. The TLS WG was not consulted prior to the start of this new
Last Call.

Although we recognize that opinions vary about the wisdom of advancing
documents as individual submissions, this does not seem like an edge
case to us. First, there is a functioning, relevant, working group:
TLS. While it is true that the WG did not object to advancement two
years ago, that was with the impression that it would be
uncontroversial, which clearly is not the situation. On the contrary,
the IPR situation remains quite unclear and there are also technical
issues with the document (see Eric Rescorla's separate review), as
well as at least one part of the document which is obsoleted by RFC
5246.  These factors provide substantial evidence that the document
would benefit from the Working Group process.

If the authors wish to advance the document on the standards track,
the appropriate path is to submit it to the TLS WG as a work item. TLS
WG has the appropriate participation and skills to evaluate the need
for this work and the suitability of this document.  If there is
sufficient support for work in this area (including the usual RFC 3979
IPR Evaluation), then it can advance through the standards track via
the WG process. If the authors don't wish to go through the WG
process, we do not oppose advancement of this document as
Experimental. However, we do not believe that advancing a two year old
document which is clearly in scope of an active WG is an appropriate
use of the individual submission process. Therefore we urge the IESG
not to approve this document.

Eric Rescorla
Joe Salowey
[TLS WG Chairs]
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem

[Eric Rescorla]

At Mon, 12 Jan 2009 19:27:02 -0500,
Ed Juskevicius wrote:
> 
> Eric, Thank You for your comments and for your suggestions (below)
> 
> I like your proposal for how to clarify and improve the wording of the draft
> legend text.

Thanks.

Can you advise as to when the community can expect to see a revised
legend proposal from the trust that incorporates the community feedback
you're receiving?

Best,
-Ekr
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: ANNOUNCEMENT: The IETF Trustees invite your review and comments on a proposed Work-Around to the Pre-5378 Problem

[Eric Rescorla]

Ed,

I'd like to thank the Trustees for working to resolve this
situation. Unfortunately, after reviewing the new text, I don't think
it's really adequate. 

To recap, the the old text required the contributor to affirm (and
consequently to verify) that adequate permissions had been obtained to
publish legacy (pre-5378) material under the 5378 rules. This was
impractical both because of the difficulty of obtaining such
permissions and the difficulty of tracing every portion of the
document. This new text, reproduced below, solves the first problem,
but not the second:

This document contains material from IETF Documents or IETF
Contributions published before November 10, 2008 and, to the
Contributor?s knowledge, the person(s) controlling the copyright in
such material have not granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright, this document may not be modified outside the IETF
Standards Process, and derivative works of it may not be created
outside the IETF Standards Process, except to format it for
publication as an RFC and to translate it into languages other than
English.

The first problem here is the phrase "and, to the Contributor's
knowledge, the person(s) controlling the copyright in such material
have not granted the IETF Trust the right...". As I read this, I am
directly affirming my belief that there are copyright holders who have
not granted these rights. This is all fine if I know exactly who the
original copyright holders are and that they have not given
permission, but the more likely case is that I don't know one way or
the other, and am simply unwilling to affirm the converse.
However, I am equally unwilling to affirm my knowledge and belief
that the persons controlling the copyright have not made grants.
I simply don't know. This text should be rewritten as:

This document contains material from IETF Documents or IETF
Contributions published before November 10, 2008. Some material
may be subject to copyright claims for which the holders have not
granted the IETF Trust the right to allow modifications of such
material outside the IETF Standards Process.

In addition, the final sentence "Without obtaining..." seems overly
strong. It's phrased as if it were a condition imposed by the
contributor, i.e., I the contributor doesn't license you to use
this document unless you obtain "adequate" permission from the original
copyright holders (with the contributor to be the judge of adequate,
perhaps). But that's not what's in play here. Rather,
it's that I the contributor can't give me license to material
I don't control. So, this sentence serves as advice, not
a license restriction and should be rewritten accordingly.
Perhaps:

Modification or creation of derivative works outside of the
scope of RFC 4978 may require obtaining a license from the
person(s) controlling the copyright on the relevant sections
of the document. 

Best,
-Ekr
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Fwd: Security team successfully cracks SSL using 200 PS3's and MD5 flaw.

[Eric Rescorla]

At Sun, 4 Jan 2009 07:51:01 -0500,
Marshall Eubanks wrote:
> I think that Hank raises a very good question. There has been
> a very active discussion of this on NANOG, both re SSL, BGP and in  
> general.
> 
> Here is the original link :
> 
>   
>  >
> 
> Regards
> Marshall
> 
> Begin forwarded message:
> 
> > From: Hank Nussbacher 
> > Date: January 4, 2009 2:22:06 AM EST
> > To: Mikael Abrahamsson , "na...@nanog.org" 
> >  > >
> > Subject: Re: Security team successfully cracks SSL using 200 PS3's  
> > and MD5 flaw.
> >
> > At 06:44 PM 03-01-09 +0100, Mikael Abrahamsson wrote:
> >> On Sat, 3 Jan 2009, Hank Nussbacher wrote:
> >>
> >>> You mean like for BGP neighbors?  Wanna suggest an alternative? :-)
> >>
> >> Well, most likely MD5 is better than the alterantive today which is  
> >> to run no authentication/encryption at all.
> >>
> >> But we should push whoever is developing these standards to go for  
> >> SHA-1 or equivalent instead of MD5 in the longer term.
> >
> > Who is working on this?  I don't find anything here:
> > http://www.ietf.org/html.charters/idr-charter.html
> >
> > All I can find is:
> > http://www.ietf.org/rfc/rfc2385.txt
> > http://www.ietf.org/rfc/rfc3562.txt
> > http://www.ietf.org/rfc/rfc4278.txt
> >
> > Nothing on replacing MD5 for BGP.


Oh boy...


1. This isn't a break in SSL per se. It's an attack on a single
CA which was still unsafely using MD5. As I understand it, they
have now fixed that. So, it's not clear to what extent this has
an ongoing impact. In particular, it only affects certificate-based
authentication, not authentication with a shared secret, as is
used in TCP-MD5.

My summary of the attack can be found
here: 
http://www.educatedguesswork.org/2008/12/understanding_the_sotirov_et_a.html


2. The MAC used in TCP-MD5 is weak by modern standards (for several
reasons, not just that it uses MD5) and there is already work going
on in TCPM to replace it. See draft-ietf-tcpm-tcp-auth-opt.

-Ekr


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

Re: Review of draft-ietf-dkim-ssp-08

[Eric Rescorla]

At Fri, 2 Jan 2009 19:22:25 -0500 (EST),
John R Levine wrote:
> 
> > This document (hereafter called ADSP) allows the domain to advertise
> > its signing policy, thus allowing recipients to distinguish these
> > (and some other) cases.
> 
> ADSP is a very, very narow design, that attempts to deal with only a 
> single threat: exact forgery of an address on the From: line.  There's a 
> lot of other threats, arguably more important to address, but ADSP doesn't 
> deal with them.

OK.


> > TECHNICAL
> > S 3.
> >
> >   Hosts can look up the ADSP information of the domain(s) specified by
> >   the Author Address(es) as described in Section 4.3.  If a message has
> >   multiple Author Addresses the ADSP lookups SHOULD be performed
> >   independently on each address.  This document does not address the
> >   process a host might use to combine the lookup results.
> >
> > I'd like to see some security analysis of why this is OK. Naively,
> > it seems like one might be able to get around ADSP using this feature.
> 
> Since we don't have any real experience with signed mail with multi 
> address From: lines, any analysis would just be a guess, and not a very 
> well informed one at that, so we figured it was better not to.  Consider 
> these From: lines:
> 
> From: secur...@paypal.com, cr...@phishpharm.biz ; ADSP fail, pass
> 
> From: secur...@paypalsecurity.com, cr...@phishpharm.biz ; ADSP unknown, pass
> 
> From: fri...@knowndomain.com, some...@somewhere.com; ADSP pass, unknown
> 
> The first and second cases are probably bad guys, but the third could be 
> someone you know and trust and his friend who you don't happen to know 
> yet.
> 
> We don't see any way to tell these apart without consulting external 
> reputation databases, which are way outside the scope of ADSP and DKIM.

OK, but I don't see how it helps to put the job of making this 
judgement on the implementor, who probably has less expertise
and time to think about this than the DKIM WG has, especially
as there is at least one policy that more or less obviates
ADSP (treat all addresses as having the weakest policy 
advertised by any of them). 


> > S 6.2.
> >   An attacker might attack the DNS infrastructure in an attempt to
> >   impersonate ADSP records to influence a receiver's decision on how it
> >   will handle mail.  However, such an attacker is more likely to attack
> >   at a higher level, e.g., redirecting A or MX record lookups in order
> >   to capture traffic that was legitimately intended for the target
> >   domain.  These DNS security issues are addressed by DNSSEC [RFC4033].
> >
> > I don't understand why an attacker is more likely to redirect A or MX.
> > These are different attacks with different objectives. If I'm doing
> > phishing, then forgery seems more useful to the attacker.
> 
> Why phish if you can hijack the real traffic to the target?

Because the legitimate URL the user is dereferencing uses TLS?



> > S 2.7.
> >
> >   For example, if a message has a Valid Signature, with the DKIM-
> >   Signature field containing "i...@domain.example", then domain.example
> >   is asserting that it takes responsibility for the message.  If the
> >   message's From: field contains the address "b...@domain.example" and an
> >   ADSP query produces a "dkim=all" or "dkim=discardable" result, that
> >   would mean that the message does not have a valid Author Signature.
> >   Even though the message is signed by the same domain, it fails to
> >   satisfy ADSP.
> >
> > I think this example might benefit from a bit more explanation.
> > As I understand it, this signature is invalid per DKIM
> 
> It's valid DKIM, but ADSP has additional semantics that are incompatible 
> with common auditing usage of the DKIM i= field.  The -09 draft will have 
> a note pointing this out with a workaround.  For an example of usage of 
> i=, see the DKIM signature on this message.
>
> >   Note:   The results from DNS queries that are intended to validate a
> >  domain name unavoidably approximate the set of Author Domains that
> >  can appear in legitimate email.  For example, a DNS A record could
> >  belong to a device that does not even have an email
> >  implementation.  It is up to the checker to decide what degree of
> >  approximation is acceptable.
> >
> > I don't really understand this graf. Can you rephrase?
> 
> Many people have pointed out that in practice you can trivially circumvent 
> ADSP by using lookalike domains, e.g. paypalsecurity.com or 
> www.paypal.com.  One way to address this would be to check to see if the 
> domain is in use at all for e-mail, since the number of domains in use for 
> mail is a tiny fraction of all of the names in the DNS.  Unfortunately, 
> due to the ancient SMTP rule that use an A record, and now also , for 
> fallback if a domain has no MX record, any name with an A or  record 
> can potentially be used for mail.  There's a range of more or less 
> aggressive heuristics to see if 

Re: Review of draft-ietf-dkim-ssp-08

[Eric Rescorla]

At Fri, 02 Jan 2009 12:06:48 -0800,
Eric Rescorla wrote:
> TECHNICAL
> S 3.
> 
>Hosts can look up the ADSP information of the domain(s) specified by
>the Author Address(es) as described in Section 4.3.  If a message has
>multiple Author Addresses the ADSP lookups SHOULD be performed
>independently on each address.  This document does not address the
>process a host might use to combine the lookup results.
> 
> I'd like to see some security analysis of why this is OK. Naively,
> it seems like one might be able to get around ADSP using this feature.
> I.e., I want to forge a message apparently from example.com, which
> has "dkim-all". I generate a message with "From: e...@example.com, 
> e...@example.org"
> where I control example.org. I then serve a record for example.org 
> indicating that I don't sign. If this is accepted, that seems 
> potentially problematic.

In retrospect, this isn't very clear.

In the case where there is one author and no signature, it seems to me
that ADSP allows you to differentiate two cases:

(1) The domain does not do DKIM signing [or more precisely hasn't
bothered to publish a policy.]
(2) The domain DKIM signs and this is a forgery [or an error or something.]

Obviously a message that falls into case (2) should be treated with
extreme skepticism (and presumably discarded if discardability is
set). By contrast, a message that falls into category (1) probably
would be treated with less skepticism.
 
Now, let's try to extend that question to a message with multiple
signers. Consider the following policy for combining the results: "If
any author lacks an ADSP record, act is af no ADSP record is
available." ISTM that this allows an attacker to generate a message
with a nominal author list that includes a domain that DKIM signs but
get it treated as if it were in case (1). To the extent to which such
messages get less skepticism, that seems undesirable. By contrast,
a policy which said "treat the most strict policy as applying to all
signers" would have a very different set of security properties.

Obviously, these questions interact a lot with what treatment messages
get which fall into various categories, something I appreciate that
DKIM has tried to be agnostic about in general. Unfortunately, I think 
this is somewhere where you need to consider some plausible treatments
and the effect of various policies in the face of the natural attacker
behaviors.

-Ekr


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

Review of draft-ietf-dkim-ssp-08

[Eric Rescorla]

$Id: draft-ietf-dkim-ssp-08-rev.txt,v 1.1 2009/01/02 19:05:45 ekr Exp $

This document describes a way for domains to publish their policy
vis-a-vis signing emails with DKIM. The idea here is that when
you receive an email that is not signed you would like to be able
to distinguish (at least) two cases:

- The domain doesn't sign.
- This is a forgery.

This document (hereafter called ADSP) allows the domain to advertise
its signing policy, thus allowing recipients to distinguish these
(and some other) cases.

Generally, this approach and the protocol it describes seem sound.
However, I have some concerns as detailed below.

One general question: I see you're using TXT here. I know this
is a hot button for the DNS people. If you haven't cleared this
with them, that might be good. If you have, then ignore this
comment.



TECHNICAL
S 3.

   Hosts can look up the ADSP information of the domain(s) specified by
   the Author Address(es) as described in Section 4.3.  If a message has
   multiple Author Addresses the ADSP lookups SHOULD be performed
   independently on each address.  This document does not address the
   process a host might use to combine the lookup results.

I'd like to see some security analysis of why this is OK. Naively,
it seems like one might be able to get around ADSP using this feature.
I.e., I want to forge a message apparently from example.com, which
has "dkim-all". I generate a message with "From: e...@example.com, 
e...@example.org"
where I control example.org. I then serve a record for example.org 
indicating that I don't sign. If this is accepted, that seems 
potentially problematic.


S 4.3.
   Check Domain Scope:   An ADSP checker implementation MUST determine
  whether a given Author Domain is within scope for ADSP.  Given the
  background in Section 3.1 the checker MUST decide which degree of
  approximation is acceptable.  The checker MUST return an
  appropriate error result for Author Domains that are outside the
  scope of ADSP.

I don't really undersand how the second (and maybe third) MUSTs are
operationalizable. How would I not "decide"? I mean, I could
just ignore the issue and do exact match. Would that constitute
"deciding"? What would not "deciding"?

S 6.2.
   An attacker might attack the DNS infrastructure in an attempt to
   impersonate ADSP records to influence a receiver's decision on how it
   will handle mail.  However, such an attacker is more likely to attack
   at a higher level, e.g., redirecting A or MX record lookups in order
   to capture traffic that was legitimately intended for the target
   domain.  These DNS security issues are addressed by DNSSEC [RFC4033].

I don't understand why an attacker is more likely to redirect A or MX.
These are different attacks with different objectives. If I'm doing
phishing, then forgery seems more useful to the attacker.

In addition, to the extent to which the point of security
considerations is to give the reader an accurate picture of the
security of the system, I don't think this works that well, as due to
the very low deployment of DNSSEC, in practice these records are
easily forged.



EDITORIAL
S 2.7.

   For example, if a message has a Valid Signature, with the DKIM-
   Signature field containing "i...@domain.example", then domain.example
   is asserting that it takes responsibility for the message.  If the
   message's From: field contains the address "b...@domain.example" and an
   ADSP query produces a "dkim=all" or "dkim=discardable" result, that
   would mean that the message does not have a valid Author Signature.
   Even though the message is signed by the same domain, it fails to
   satisfy ADSP.

I think this example might benefit from a bit more explanation.
As I understand it, this signature is invalid per DKIM and so it needs
to be treated as unsigned, and that's where ADSP kicks in. But I
may have misunderstood, so some clarity here might help.


S 3.1.
   Note:   The results from DNS queries that are intended to validate a
  domain name unavoidably approximate the set of Author Domains that
  can appear in legitimate email.  For example, a DNS A record could
  belong to a device that does not even have an email
  implementation.  It is up to the checker to decide what degree of
  approximation is acceptable.

I don't really understand this graf. Can you rephrase?


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

5378: A worked example

[Eric Rescorla]

Having recently completed TLS 1.2 (RFC 5246), I thought it would be worth
going through the thought experiment of what it would be like to
submit it under the RFC 5378 terms. As I understand the general
consensus, if I were to submit RFC 5246bis, I would need to get
approval under the new terms from everyone who made a substantial
contribution to the original document (the bulk of which dates back to
TLS 1.0 in 1999). I don't have an exhaustive list, but this presumably
includes at minimum everyone listed in the Contributors section on
pages 101-102.

That list contains 14 names. Let's say that I have a 95% chance of
getting any one of those people to give consent. The joint probability
that I will obtain all the required consents is .95^14, less than 1/2.

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

5378: A Worked Example

[Eric Rescorla]

[Resending from an account that should work]

Having recently completed TLS 1.2 (RFC 5246), I thought it would be
worth going through the thought experiment of what it would be like to
submit it under the RFC 5378 terms. As I understand the general
consensus, if I were to submit RFC 5246bis, I would need to get
approval under the new terms from everyone who made a substantial
contribution to the original document (the bulk of which dates back to
TLS 1.0 in 1999). I don't have an exhaustive list, but this presumably
includes at minimum everyone listed in the Contributors section on
pages 101-102.

That list contains 14 names. Let's say that I have a 95% chance of
getting any one of those people to give consent. The joint probability
that I will obtain all the required consents is .95^14, less than 1/2.
I imagine the situation is similar for other large, old
documents such as RFC 3261 (SIP) or 2616 (HTTP).

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

Re: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary

[Eric Rescorla]

At Sat, 13 Dec 2008 09:49:09 +1300,
Brian E Carpenter wrote:
At Sat, 13 Dec 2008 09:49:09 +1300,
Brian E Carpenter wrote:
> 
> On 2008-12-13 08:20, Russ Housley wrote:
> > At 01:28 PM 12/12/2008, Simon Josefsson wrote:
> > 
> >> As far as I understand, I can no longer take RFC 4398, fix some
> >> minor problem, and re-submit it as a RFC 4398bis.  Even though I was
> >> editor of RFC 4398.  The reason is that some material in that document
> >> was written by others.  At least, I cannot do this, without getting
> >> permission from the other people who wrote the initial document.  I wish
> >> this is mistaken and that someone can explain how to reconcile this
> >> example with what Russ wrote.
> > 
> > Correct.  RFC 5378 imposes this burden on the contributor.  All of the
> > rights needed to make updates to the document within the IETF Standards
> > Process are clearly already available, but the contributor is required
> > to obtain the additional rights that are required by RFC 5378.
> 
> Formally yes. But the Trust can take the sting out of this by
> a vigorous effort to get former contributors to sign over the
> necessary rights, and by providing a convenient method for
> this to be done.

Maybe I'm missing something, but I don't see how this helps, because
we have no tracking of all the contributors to those previous
documents. So, how can the contributor know that all forme
contributors have executed those additional rights grants?

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

Re: Friday experiment

[Eric Rescorla]

At Fri, 12 Dec 2008 14:12:11 -0500,
Scott Brim wrote:
> 
> Eric Rescorla allegedly wrote, On 12/12/08 2:26 PM:
> > At Sat, 29 Nov 2008 13:15:23 +0100,
> > Julian Reschke wrote:
> >> I think it would be good to finally enforce the rules for agenda 
> >> submissions. For instance, if no agenda for a meeting is published in 
> >> time, the meeting shouldn't take place.
> > 
> > +1.
> > 
> > I find it incredibly frustrating to be a week out from IETF and 
> > not know what drafts I need to read.
> 
> They should be the ones that people have been arguing about for a month
> before that, so that it has become clear they need to be discussed in
> the meeting.

Perhaps so, but in most WGs I am involved in, plenty of new drafts
show just before the meeting and people ask for discussion time, and
then sometimes people don't show, so in practice trying to follow this
algorithm gets you a very inaccurate list.  Moreover, I (and others)
use programmatic tools to extract the list of drafts to review and
then go back and review the mailing list as necessary.

So, all this works far better if the agenda is actually accurate.

-Ekr

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

Re: Friday experiment

[Eric Rescorla]

At Sat, 29 Nov 2008 13:15:23 +0100,
Julian Reschke wrote:
> I think it would be good to finally enforce the rules for agenda 
> submissions. For instance, if no agenda for a meeting is published in 
> time, the meeting shouldn't take place.

+1.

I find it incredibly frustrating to be a week out from IETF and 
not know what drafts I need to read.

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

Missing materials

[Eric Rescorla]

As I have done for previous IETFs I just ran getdrafts 
(http://tools.ietf.org/tools/getdrafts/) on the entire agenda
and what follows is the output. 

Notes
1. Getdrafts only looks one version ahead. If you're more than
   that far off, the draft gets reported as missing.
2. Getdrafts' parser isn't perfect. If you have a draft listed
   and I didn't catch it, please let me know.
3. Some of these meetings are area meetings. I don't know if
   the are required to have agendas.
4. 6man and v6ops, marked with *** below, have only PDF agendas,
   which don't lift draft names in any case. This
   is pretty inconvenient for those of us who use automated
   tools.

-Ekr

WGs without agendas:
  apparea
  savi
  6man   ***
  ntp***
  v6ops
  autoconf
  forces
  16ng
  capwap
  rtgwg
  opsawg
  ledbat
  eai
  softwire
  l3vpn
  saag

Missing drafts
  draft-poetzl-bliss-call-completion-01.txt (wg=bliss)
  draft-ietf-port-randomization-02.txt (wg=tsvwg)
  draft-yang-multimob-mip6-mc-tunnel-opt-00.txt (wg=multimob)
  draft-xia-multimob-hybrid-00.txt (wg=multimob)
  draft-schmidt-waehlisch-mhmipv6-04.txt (wg=multimob)
  draft-xia-mipshop-fmip-multicast-01.txt (wg=multimob)
  draft-martin-managesieve-10.txt (wg=sieve)
  draft-ietf-radext-crypto-agility-requirements-02.txt (wg=radext)
  draft-morin-mpls-mcast-ethernet-00.txt (wg=mpls)
  draft-ietf-pcn-marking-behavior-01.txt (wg=pcn)
  draft-ietf-dnsext-29.txt (wg=dnsext)
  draft-ietf-roll-home-routing-reqs-00.txt (wg=roll)
  draft-ietf-dna-frd-02.txt (wg=dna)
  draft-aitken-ipfix-new-infos-01.txt (wg=ipfix)
  draft-dietz-ipfix-mib-04.txt (wg=ipfix)
  draft-ietf-msec-gdoi-update-03.txt (wg=msec)
  draft-ietf-dccp-qs-01.txt (wg=dccp)
  draft-ietf-enum-enumservices-guide-10.txt (wg=enum)

Corrected drafts
  draft-martini-pwe3-iccp-01.txt -> draft-martini-pwe3-iccp-00.txt (wg=pwe3)
  draft-clancy-emu-chbind-03.txt -> draft-clancy-emu-chbind-04.txt (wg=emu)
  draft-von-hugo-multimob-agents-02.txt -> 
draft-von-hugo-multimob-agents-03.txt (wg=multimob)
  draft-ward-l2isis-03.txt -> draft-ward-l2isis-04.txt (wg=isis)
  draft-freed-sieve-in-xml-01.txt -> draft-freed-sieve-in-xml-02.txt (wg=sieve)
  draft-muhanna-mext-binding-revocation-02.txt -> 
draft-muhanna-mext-binding-revocation-03.txt (wg=mext)
  draft-bernardos-mext-aero-nemo-ro-sol-analysis-00.txt -> 
draft-bernardos-mext-aero-nemo-ro-sol-analysis-01.txt (wg=mext)
  draft-martinelli-ccamp-optical-imp-signaling-01.txt -> 
draft-martinelli-ccamp-optical-imp-signaling-02.txt (wg=ccamp)
  draft-dekok-radext-tcp-transport-00.txt -> 
draft-dekok-radext-tcp-transport-01.txt (wg=radext)
  draft-boutros-mpls-tp-loopback-01.txt -> 
draft-boutros-mpls-tp-loopback-00.txt (wg=mpls)
  draft-channabasappa-drinks-usecases-requirements-00.txt -> 
draft-channabasappa-drinks-usecases-requirements-01.txt (wg=drinks)
  draft-schumacher-drinks-luf-lrf-diff-00.txt -> 
draft-schumacher-drinks-luf-lrf-diff-01.txt (wg=drinks)
  draft-farrel-pce-vendor-constraints-01.txt -> 
draft-farrel-pce-vendor-constraints-02.txt (wg=pce)
  draft-lee-pce-wson-routing-wavelength-02.txt -> 
draft-lee-pce-wson-routing-wavelength-03.txt (wg=pce)
  draft-kumaki-murai-pce-pcep-extension-l3vpn-00.txt -> 
draft-kumaki-murai-pce-pcep-extension-l3vpn-01.txt (wg=pce)
  draft-kumaki-pce-bgp-disco-attribute-01.txt -> 
draft-kumaki-pce-bgp-disco-attribute-02.txt (wg=pce)
  draft-ietf-tcpm-1323bis-00.txt -> draft-ietf-tcpm-1323bis-01.txt (wg=tcpm)
  draft-ietf-mboned-addrarch-05.txt -> draft-ietf-mboned-addrarch-06.txt 
(wg=mboned)
  draft-ietf-ipfix-testing-04.txt -> draft-ietf-ipfix-testing-05.txt (wg=ipfix)
  draft-ietf-psamp-sample-tech-10.txt -> draft-ietf-psamp-sample-tech-11.txt 
(wg=ipfix)
  draft-ietf-ipfix-export-per-sctp-stream-00.txt -> 
draft-ietf-ipfix-export-per-sctp-stream-01.txt (wg=ipfix)
  draft-ietf-ipfix-configuration-model-00.txt -> 
draft-ietf-ipfix-configuration-model-01.txt (wg=ipfix)
  draft-ietf-ipfix-mediators-framework-00.txt -> 
draft-ietf-ipfix-mediators-framework-01.txt (wg=ipfix)
  draft-krishnan-csi-proxy-send-00.txt -> draft-krishnan-csi-proxy-send-01.txt 
(wg=csi)
  draft-ietf-csi-hash-threat-00.txt -> draft-ietf-csi-hash-threat-01.txt 
(wg=csi)
  draft-krishnan-cgaext-send-cert-eku-01.txt -> 
draft-krishnan-cgaext-send-cert-eku-02.txt (wg=csi)
  draft-ietf-manet-timetlv-07.txt -> draft-ietf-manet-timetlv-08.txt (wg=manet)
  draft-ietf-manet-smf-07.txt -> draft-ietf-manet-smf-08.txt (wg=manet)
  draft-zimmer-dhc-dhcpv6-remote-boot-options-00.txt -> 
draft-zimmer-dhc-dhcpv6-remote-boot-options-01.txt (wg=dhc)
  draft-ietf-speermint-srv-naptr-use-04.txt -> 
draft-ietf-speermint-srv-naptr-use-03.txt (wg=speermint)
  draft-ietf-dccp-ccid4-02.txt -> draft-ietf-dccp-ccid4-03.txt (wg=dccp)
  draft-patel-ecrit-sos-parameter-00.txt -> 
draft-patel-ecrit-sos-parameter-01.txt (wg=ecrit)

Found 369 out of 387 drafts
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)

[Eric Rescorla]

At Sat, 08 Nov 2008 08:53:36 -0800,
Dave CROCKER wrote:
> 
> 
> 
> Eric Rescorla wrote:
> > Speaking as someone who just got burned by exactly such a list,
> > I think I need to agree with John: I don't object to the IETF
> > publishing an informational document on this, but a PS implies
> > that IETF endorses the practice, which I don't think we should do.
> 
> 
> Eric,
> 
> Roughly 95% of all mail is spam.  That makes email a pretty onerous 
> "practice".
> 
> So we ought to remove standards status for all email specifications.

I don't think this follows from my comment.


> Or we could consider keeping mechanism and policy separate, standardizing 
> technologies (mechanisms) and refraining from condemning them because some 
> operators have misguided policies and use the mechanisms badly.

This sounds like a false choice to me.


> Really, guys, everything we standardize has examples of misuse.  So that 
> hardly 
> makes your current line of argument substantive.

You're certainly welcome to have that opinion, but I don't think that's
what I'm saying. For the reasons Keith is suggesting, among others,
I don't think this is a very good mechanism and therefore the IETF
shouldn't endorse it. As I said, I don't have a problem with this
document being advanced as Informational, but PS is different.

-Ekr

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

Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)

[Eric Rescorla]

At Sat, 08 Nov 2008 06:46:54 -0500,
John C Klensin wrote:
> 
> Sadly, I have to agree with Keith.   While these lists are a
> fact of life today, and I would favor an informational document
> or document that simply describes how they work and the issues
> they raise, standardizing them and formally recommending their
> use is not desirable at least without some major changes in our
> email model and standards for what gets addresses onto --and,
> more important, off of-- those lists.

Speaking as someone who just got burned by exactly such a list,
I think I need to agree with John: I don't object to the IETF
publishing an informational document on this, but a PS implies
that IETF endorses the practice, which I don't think we should do.
I appreciate that there is a fine distinction here, but it seems
to me that it's precisely for cases like this where the distinction
is appropriate.

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

Re: Last Call: draft-ietf-avt-dtls-srtp - DTLS-SRTP to Proposed Standard

[Eric Rescorla]

At Thu, 02 Oct 2008 17:23:31 -0400,
Russ Housley wrote:
> 
> 
> I know these are a few hours late, but I have a few comments.  I have 
> divided them into TECHNICAL and EDITORIAL.
> 
> TECHNICAL COMMENTS
> 
> Section 1, 2nd para. It is unclear what version of DTLS is being 
> used.  The reference to RFC4347 in this paragraph leads to one 
> conclusion, but in Section 4.1.2 the authors also refer to DTLS 1.2 
> when discussing the PRF.  If this depends on a particular version of 
> DTLS, please tell us up front.

No, it doesn't depend. It's compatible with either version of DTLS.
However, because DTLS has adjustable PRFs, we simply added
this sentence to make clear what to do with DTLS 1.2.


> Appendix B, 2nd example of Multiple DTLS Handshakes.   RFC 5246, 
> section 7.4.1.2, states: "After sending the ClientHello message, the 
> client waits for a ServerHello message.  Any handshake message 
> returned by the server, except for a HelloRequest, is treated as a 
> fatal error". So, looking at the second ClientHello, the server 
> responds with ChangeCipherSpec and Finished messages associated  with 
> the first session.   What will happen?  I can imagine an 
> implementation that will consider it a fatal error.

The text you're referring to in RFC 5246 refers to a single connection,
but Appendix B is talking about two separate connections/associations
(hence the (1) and (2)). This is not an error in TLS. In fact,
in this particular case the state machines are completely uncoupled.


> EDITORIAL COMMENTS
> 
> Maybe we can avoid the possessive form of DTLS.  Should it be DTLS's 
> be just DTLS' ?
> 
> Section 1, 3rd para, 1st sentence. s/combine/combines/
> 
> Section 1, 4th para, 3rd bullet.  s/DTLS extension/DTLS extension is/
> 
> Section 3, 8th para. s/handshakes establishment exchanges./handshakes./
> 
> Section 4.1.3, 3rd para, 1st sentence. A subject is missing.  I 
> suggest: "If the client detects a nonzero-length MKI in the server's 
> response that is different than the one the client offered, then the 
> client MUST abort the handshake and SHOULD send an invalid_parameter alert."
> 
> Section 4.2, 1st para after Figure 1, 1st sentence. s/need/needed/
> 
> Section 5.1.2, 1st para after the 5 numbered statements. s/times the 
> number/times the number of/
> 
> Appendix A, 2nd para, 1st sentence. s/authenticated/authenticate/

Thanks. I'll take care of these.


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

Re: Proposals to improve the scribe situation

[Eric Rescorla]

At Mon, 4 Aug 2008 09:36:42 +0200,
Iljitsch van Beijnum wrote:
> 
> On 3 aug 2008, at 18:26, Marshall Eubanks wrote:
> 
> > I find that scribing on jabber has a number of advantages
> 
> On the other hand, having the jabber room monopolized by the scribe  
> reduces its usefulness as an additional channel for communication.
> 
> Now that we have audio for all sessions (although sometimes the  
> quality is far from ideal) is it really necessary to repeat everything  
> that's being said in jabber?
> 
> I think the jabber scribe function should be reduced to announcing new  
> speakers and giving some hints about which slides are on the screen.  
> The jabber room can then be used by local and remote participants as  
> an extra channel rather than a reduced bandwidth copy of the audio.
> 
> > 3.) A minor point, but I would urge WG chairs to formally designate  
> > someone (possibly themselves) to
> > relay questions from jabber. This seems to fall to the jabber  
> > scribe, even though it is impossible to stand at the
> > mike and scribe at the same time !
> 
> An extra microphone for the question relayer would also be useful.  
> What I always try to do in this situation is sit next to the mike...

Actually, what I think would be very useful would be to have a second
screen that shows the jabber channel. The burden of having to run
everything through the scribe is just too high to allow meaningful
participation.

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

Re: Missing Materials

[Eric Rescorla]

At Thu, 24 Jul 2008 23:33:40 +0200,
Frank Ellermann wrote:
> 
> Eric Rescorla wrote:
>  
> > Missing drafts
> [...]
> >   draft-ietf-eai-smtpext-11.txt (wg=eai)
> >   draft-ietf-eai-utf8headers-09.txt (wg=eai)
> [...]
> > Corrected dafts
> [...]
> >   draft-ietf-eai-downgrade-07.txt ->
> >   draft-ietf-eai-downgrade-08.txt (wg=eai)
> >   draft-ietf-eai-imap-utf8-02.txt ->
> >   draft-ietf-eai-imap-utf8-03.txt (wg=eai)
> [...]
> > Found 509 out of 533 drafts
> 
> Based on these four examples I'd guess that your script finds
> corrected drafts only for "+1", but not for "+2" or "+3", e.g.
> 
> http://tools.ietf.org/html/draft-ietf-eai-smtpext-13 (11+2)
> http://tools.ietf.org/html/draft-ietf-eai-utf8headers-12 (09+3)

That's right. I assume the agendas are only sort of wrong, not
wildly wrong.

Really, though, even being off by one is a bug.

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

Missing Materials

[Eric Rescorla]

As I have done for previous IETFs I just ran getdrafts 
(http://tools.ietf.org/tools/getdrafts/) on the entire agenda
and what follows is the output. As you can see, a pretty substantial
number of WGs are without agendas, about 10% of the drafts listed
are wrong, and about half of those appear to be simple version 
errors. 

-Ekr


WGs without agendas:
  softwire
  idnabis
  savi
  rtgwg
  capwap
  opsawg
  rtgarea
  pkix
  opsec
  isis
  autoconf

Missing drafts
  draft-shen-csi-ecc-00.txt (wg=csi)
  draft-ietf-ccid4-02.txt (wg=dccp)
  draft-ietf-eai-smtpext-11.txt (wg=eai)
  draft-ietf-eai-utf8headers-09.txt (wg=eai)
  draft-ietf-ntp-dhcpv6-ntp-opt-00.txt (wg=ntp)
  draft-ietf-psamp-info-07.txt (wg=ipfix)
  draft-aitken-ipfix-new-infos-01.txt (wg=ipfix)
  draft-dietz-ipfix-mib-04.txt (wg=ipfix)
  draft-kang-ccamp-wdm-switch-info-00.txt (wg=ccamp)
  draft-ietf-ntp-dhcpv6-ntp-opt-00.txt (wg=dhc)
  draft-willis-sip-infopackage-00.txt (wg=sip)
  draft-martini-pwe3-iccp-00.txt (wg=pwe3)
  draft-ietf-ecrit-location-hiding-requirements-00.txt (wg=ecrit)
  draft-ietf-pim-port-00.txt (wg=pim)
  draft-dekok-radext-dtls-01.txt (wg=radext)
  draft-mediactrl-ivr-control-package-00.txt (wg=mediactrl)
  draft-mediactrl-mixer-control-package-00.txt (wg=mediactrl)
  draft-nishioka-pce-sve-list-02.txt (wg=pce)
  draft-eardley-pcn-marking-behavior-01.txt (wg=pcn)
  draft-ietf-sieve-notify-mailto-06.txt (wg=sieve)
  draft-freed-sieve-notary-01.txt (wg=sieve)
  draft-ietf-dnsext-29.txt (wg=dnsext)
  draft-ietf-dna-frd-02.txt (wg=dna)
  draft-ietf-radext-management-authorization-03.txt (wg=isms)

Corrected drafts
  draft-ietf-mpls-remote-lsp-ping-01.txt -> 
draft-ietf-mpls-remote-lsp-ping-02.txt (wg=mpls)
  draft-kompella-mpls-entropy-label-01.txt -> 
draft-kompella-mpls-entropy-label-00.txt (wg=mpls)
  draft-sprecher-mpls-tp-oam-analysis-00.txt -> 
draft-sprecher-mpls-tp-oam-analysis-01.txt (wg=mpls)
  draft-tewari-nfsv4-federated-fs-protocol-01.txt -> 
draft-tewari-nfsv4-federated-fs-protocol-02.txt (wg=nfsv4)
  draft-ellard-nfsv4-federated-fs-00.txt -> 
draft-ellard-nfsv4-federated-fs-01.txt (wg=nfsv4)
  draft-jiang-sendcgaext-cga-config-01.txt -> 
draft-jiang-sendcgaext-cga-config-02.txt (wg=csi)
  draft-ietf-speermint-voip-consolidated-usecases-09.txt -> 
draft-ietf-speermint-voip-consolidated-usecases-08.txt (wg=speermint)
  draft-ietf-dccp-tfrc-faster-restart-05.txt -> 
draft-ietf-dccp-tfrc-faster-restart-06.txt (wg=dccp)
  draft-phelan-dccp-natencap-00.txt -> draft-phelan-dccp-natencap-01.txt 
(wg=dccp)
  draft-mohan-l2vpn-vpls-oam-00.txt -> draft-mohan-l2vpn-vpls-oam-01.txt 
(wg=l2vpn)
  draft-kamite-l2vpn-vpms-frmwk-requirements-00.txt -> 
draft-kamite-l2vpn-vpms-frmwk-requirements-01.txt (wg=l2vpn)
  draft-ietf-tsvwg-rsvp-security-groupkeying-00.txt -> 
draft-ietf-tsvwg-rsvp-security-groupkeying-01.txt (wg=tsvwg)
  draft-cotton-tsvwg-iana-ports-00.txt -> draft-cotton-tsvwg-iana-ports-01.txt 
(wg=tsvwg)
  draft-ietf-eai-downgrade-07.txt -> draft-ietf-eai-downgrade-08.txt (wg=eai)
  draft-ietf-eai-imap-utf8-02.txt -> draft-ietf-eai-imap-utf8-03.txt (wg=eai)
  draft-ietf-eai-pop-03.txt -> draft-ietf-eai-pop-04.txt (wg=eai)
  draft-ietf-ipfix-testing-04.txt -> draft-ietf-ipfix-testing-05.txt (wg=ipfix)
  draft-ietf-psamp-sample-tech-10.txt -> draft-ietf-psamp-sample-tech-11.txt 
(wg=ipfix)
  draft-boschi-ipfix-anon-00.txt -> draft-boschi-ipfix-anon-01.txt (wg=ipfix)
  draft-ietf-ccamp-gmpls-ted-mib-04.txt -> 
draft-ietf-ccamp-gmpls-ted-mib-03.txt (wg=ccamp)
  draft-deng-dhc-service-identifiers-01.txt -> 
draft-deng-dhc-service-identifiers-02.txt (wg=dhc)
  draft-ietf-rmt-pi-alc-revised-05.txt -> draft-ietf-rmt-pi-alc-revised-06.txt 
(wg=rmt)
  draft-ietf-rmt-flute-revised-05.txt -> draft-ietf-rmt-flute-revised-06.txt 
(wg=rmt)
  draft-burger-sip-info-02.txt -> draft-burger-sip-info-03.txt (wg=sip)
  draft-kaplan-sipping-dtmf-package-00.txt -> 
draft-kaplan-sipping-dtmf-package-01.txt (wg=sip)
  draft-ietf-roll-urban-routing-reqs-00.txt -> 
draft-ietf-roll-urban-routing-reqs-01.txt (wg=roll)
  draft-melnikov-digest-to-historic-00.txt -> 
draft-melnikov-digest-to-historic-01.txt (wg=sasl)
  draft-ietf-ipdvb-sec-req-07.txt -> draft-ietf-ipdvb-sec-req-08.txt (wg=ipdvb)
  draft-combes-ipdvb-mib-rcs-02.txt -> draft-combes-ipdvb-mib-rcs-03.txt 
(wg=ipdvb)
  draft-cruickshank-ipdvb-sec-04.txt -> draft-cruickshank-ipdvb-sec-05.txt 
(wg=ipdvb)
  draft-noisternig-ipdvb-ulesec-00.txt -> draft-noisternig-ipdvb-ulesec-01.txt 
(wg=ipdvb)
  draft-knoll-idr-qos-attribute-01.txt -> draft-knoll-idr-qos-attribute-02.txt 
(wg=idr)
  draft-farinacci-lisp-07.txt -> draft-farinacci-lisp-08.txt (wg=grow)
  draft-chakeres-manet-dymo-default-00.txt -> 
draft-chakeres-manet-dymo-default-01.txt (wg=manet)
  draft-ietf-manet-timetlv-04.txt -> draft-ietf-manet-timetlv-05.txt (wg=manet)
  draft-ietf-manet-nhdp-06.txt -> draft-ietf-manet-nhdp-07.txt (wg=manet)
  draft-ietf-manet-olsrv2-06.txt -> draft-ietf-manet-olsrv2-07.txt (wg=manet)
  draft-daboo-

Re: Proposed Experiment: More Meeting Time on Friday for IETF 73

[Eric Rescorla]

At Fri, 18 Jul 2008 11:41:15 +0200,
Eliot Lear wrote:
> 
> Maybe it's just me, but...
> 
> I oppose this experiment.  I already donate to my employer a significant 
> amount of travel time on weekends without wanting to add to it.  Flight 
> schedules are tightening, thanks to the cost of fuel, which means that 
> having sessions on Friday at all poses a problem now, if I want to get 
> back by Saturday.  Having afternoon sessions would put a nail in that 
> coffin.

I haven't decided whether I agree with Eliot entirely, but I think
he raises some good points here. I would add two more:

1. I've attended IETFs where there was a meeting on Friday all day
(e.g., the P2PSIP Ad Hoc at IETF 64) and it seemed to me that people
were pretty wiped at that point, so even though they felt that
they had to show up, I'm not sure much got done.

2. People's ability to meet tends to expand to fill out the available
meeting time. 

With these two points in mind, It would be nice to have some metric of
success that's more than just people showing up to the
meetings. Unfortunately, I don't have such a metric. :(


> I propose two alternative experiments:
> 
> 1.  Required agendas and Approval
> 
> No session can be approved without a posted agenda.  Many agendas are 
> late, which makes it difficult for people to know where they have to be 
> and when.

I completely agree with this. Before each IETF I attend I use automated
tools (http://tools.ietf.org/tools/getdrafts/)
to suck down each draft on the agenda and I regularly find 
a large fraction of WGs with missing agendas. As of today, the following
WGs have no agenda:

  softwire, v6ops, mip4, dime, l3vpn, idnabis, l2vpn, ntp, savi, rtgwg,
  ecrit, capwap, radext, opsawg, rtgarea, pkix, opsec, isis, keyprov,
  vcarddav, netmod, pce, saag, grow, autoconf

It's also not just an issue of knowing where to be and when but of
getting prepared. It helps to know in advance which drafts you need
to read.

-Ekr






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

Re: Subscriber List Damage

[Eric Rescorla]

At Mon, 30 Jun 2008 15:48:10 -0700,
Michael Thomas wrote:
> 
> 1) Have you brought this up with the mailman folks? I've interacted with
> them and they seem like a responsive set of folks. I'm sure that 
> this sort
> of thing would horrify them.

I agree that this is horrifying.

More importantly, doesn't this mean that this is a problem we actually
need a solution for pronto? As I understand Glen's message, he's
saying that this is a bug in mailman triggered by some problem in
TMDA. I realize that TMDA is being replaced, but presumably Henrik's
code isn't perfect, so don't we have to worry about it triggering the
same behavior?

Glen, I'm sure there are some people on this list who understand
mailman well. I realize you may not have complete info, but if you can
provide us some more information--e.g., what file(s) got stomped and
which code you think stomped it--about what you think happened, maybe
they can help track it down?

-Ekr


> 2) 3 years since the last backup? Oi.
> 
>Mike
> 
> Glen wrote:
> > All -
> >
> > I was asked by the IAOC to post a message to the IETF and SIP lists, 
> > to ensure that people were aware that the subscriber lists for the 
> > IETF and SIP lists were damaged as a result of an anomaly in TMDA and 
> > Mailman that occurred Thursday night.
> >
> > Basically, TMDA misbehaved, and, in the process, caused Mailman to 
> > encounter a transient failure in the reading of its databases for 
> > these two lists.  As a result, rather than simply holding the mail and 
> > retrying it, Mailman decided to discard the current list databases and 
> > re-create them from 3-year-old data, for both the IETF and the SIP lists.
> >
> > *sigh*
> >
> > No email was lost to the system or the archives; however, some people 
> > may have missed some messages, or may still not be resubscribed to the 
> > list.
> >
> > Of course we restored the files from backups; however, we want to make 
> > sure that everyone gets the mail they missed, and that everyone is 
> > subscribed to these lists who wishes to be subscribed.
> >
> > So...
> >
> > If you're reading this message in your email box, you're subscribed to 
> > the list identified in the subject line, and all should be okay.
> >
> > If you're reading this message in the archives, wondering why you're 
> > not getting list mail, please take a moment to resubscribe yourself to 
> > the list, which should resolve your problem.
> >
> > And regardless, if you feel you missed any mail, we do have the 
> > archives available for your reference.
> >
> > IETF List Subscription Link:  https://www.ietf.org/mailman/listinfo/ietf
> > IETF List Archive Link:  http://www.ietf.org/mail-archive/web/ietf/
> >
> > SIP List Subscription Link:  https://www.ietf.org/mailman/listinfo/sip
> > SIP List Archive Link:  http://www.ietf.org/mail-archive/web/sip/
> >
> > We are in the home stretch of getting TMDA removed and replaced on the 
> > servers, and I apologize for any inconvenience caused by this issue. 
> > Because server problems apparently happen only in the dead of night, 
> > you can be sure that we feel any and all pain anyone may be experiencing.
> >
> > If you need any assistance, please contact the IETF Secretariat, using 
> > the links at:  http://www.ietf.org/secretariat/
> >
> > Thank you,
> > Glen Barney
> > IT Director
> > AMS (IETF Secretariat)
> > ___
> > Ietf mailing list
> > Ietf@ietf.org
> > https://www.ietf.org/mailman/listinfo/ietf
> 
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: SHOULD vs MUST (was Re: Review of draft-ietf-geopriv-http-location-delivery-07)

[Eric Rescorla]

At Sat, 21 Jun 2008 14:31:03 +0100,
Lawrence Conroy wrote:
> 
> Hi Eric, folks,
>   [renamed for this specific point, and CC list trimmed]
> 
> I am puzzled by this point in your review.
> I suspect that other potential authors will be too.
> To me, the last sentence is exactly right:
> the SHOULD means "do this unless...",
> and the last phrase covers the "unless".

I'm not arguing about what intensity level this requirement
should be at. I'm pointing out that it changed and asking
why.


> I had read 2119 to mean that a MUST was unconditional
> - do this or be non-complaint.

Here's the relevant text from 2119:

2. MUST NOT   This phrase, or the phrase "SHALL NOT", mean that the
   definition is an absolute prohibition of the specification.

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

In other words, the difference between MUST and SHOULD is intensity
not conditionality.

So, if the spec read:
"You MUST do X unless Y", then an implementation which did not
do X was nonconformant unless Y obtained.

On the other hand, if the spec read:
"You SHOULD do X unless Y", then an implementation which did
not do X is still conformant even if Y does not obtain, though
the implementor is exhorted to do X unless they have some
other good reason and that Y is explicitly called out as such
a reason.


> Do you believe that MUST can have an "unless" clause?

Of course.


> Doesn't this mean that any SHOULD with an explicit "unless" will
> need to be changed into a MUST - could you expand on this, please?

No, why would it?

-Ekr



> On 20 Jun 2008, at 20:59, Eric Rescorla wrote:
> >>   The LIS MUST implement the server
> >>   authentication method described in [RFC2818]. When TLS is used,
> >>   the Device SHOULD fail a request if server authentication fails,
> >>   except in the event of an emergency.
> >>
> >> Does that address your concerns?
> > Why did this become a SHOULD when it was a MUST?



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

Re: Review of draft-ietf-geopriv-http-location-delivery-07

[Eric Rescorla]

At Thu, 29 May 2008 07:51:02 -0500,
Mary Barnes wrote:
> 
> Hi Eric,
> 
> Thanks for you review and comments.  My responses are embedded below
> [MB]. 
> 
> Mary. 
> 
> -Original Message-
> From: Eric Rescorla [mailto:[EMAIL PROTECTED] 
> Sent: Saturday, May 24, 2008 9:01 PM
> To: [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Cc: ietf@ietf.org; [EMAIL PROTECTED]
> Subject: Review of draft-ietf-geopriv-http-location-delivery-07
> 
> $Id: draft-ietf-geopriv-http-location-delivery-07-rev.txt,v 1.1
> 2008/05/24 15:03:19 ekr Exp $
> 
> TECHNICAL
> 
> 
> S 4.2.
>which a Location Recipient (LR) can use to retrieve LI.  A location
>URI provided by a LIS can be assumed to be globally-addressable; that
>is, anyone in possession of the URI can access the LIS.  However,
>this does not in any way suggest that the LIS is bound to reveal the
>location associated with the location URI.  This issue is deemed out
> 
> I don't understand this point. anyone in possession of the URI can
> access the URI but the LIS isn't required to reveal it? Those seem kind
> of contradictory.
> 
> [MB] Your comment is similar to a point made by Ben Campbell's gen-art
> review.
> The text is unclear, in particular the "However," clause.  The changes
> agreed as a result of the gen-art thread 
> http://www.ietf.org/mail-archive/web/gen-art/current/msg02995.html
> are reflected below (also incorporating another issue Ben raised, as
> well, by adding a new paragraph to that section):
> 
> NEW:
>However, this does not in any way suggest that the LIS 
>indiscriminately reveals the location associated with the location
> URI.
>The specific requirements associated with the dereference of the 
>location are specified in [I-D.ietf-geopriv-lbyr-requirements]. 
>The location dereference protocol details are out of scope of 
>this document and are specified in 
>[I-D.winterbottom-geopriv-location-deref]. 
> 
>It should also be noted that while the lybr requirements document
>specifies a requirement that a client SHOULD be able to cancel
>location references, the protocol specified in this document
>does not provide that functionality. The mechanism to
>provide this support in the protocol requires explicit management
>of Target state on the LIS. It is anticipated that extensions to HELD
>may support that requirement. 
> 
> Does the revised text help to alleviate your concern?

Well, it alleviates my concern about the security question, but it
reinforces my concern about the completeness of this specification.
Unless I'm missing something, this is a major normative dependency
on draft-winterbottom-geopriv-location-deref? I'm not sure we can
assess this protocoal with that reference unbound.


>It could also be useful for a VPN device to serve as a LIS for other
>location configuration options such as Dynamic Host Configuration
>Protocol (DHCP)[23] or Link Layer Discovery Protocol - Media Endpoint
>Discovery (LLDP-MED) [27].  VPN devices that serve as a LIS may
>acquire their own location using HELD.

Yes, I think this is an improvement.

> 
> S 5.1.
>o  The HELD protocol must provide authentication, confidentiality and
>   protection against modification per Section 10.3.
> 
> Are you talking about HELD, which doesn't seem to have these features,
> or about the transport protocol? Also, authentication for who? Based on
> what model?
> 
> [MB] Per your subsequent response to Hannes on this point, I will change
> that bullet to read:
> o  The HELD protocol REQUIRES that the underlying transport provide
> authentication, confidentiality and
>protection against modification per Section 10.3.

Agreed.


> S 6.5.
> I'm having trouble keeping straight two kinds of URIs:
> 
> - URIs that a Device uses to get its own LI.
> - LbyR references that the LIS hands out.
> 
> This text seems to imply that an LIS can hand out a helds:
> URI. Is that *also* the URI that a Device derferences?
> 
> [MB] Yes, the helds: URI that a device receives in a locationResponse is
> the URI that a device would dereference. But, it's important to note
> that the LIS does not have to return a helds: URI - other URIs may also
> be used per the text in section 6.5. [/MB]

Hmm... Then I think this needs some explanation in the main text.


> S 6.5.1.
> 
>A "locationURI" SHOULD NOT contain any information that could be used
>to identify the Device or Target.  Thus, it is RECOMMENDED that the
>"locationURI" element contain a public address for the LIS and an
>anonymous identifier, such as a local i

Re: Gen-ART LC Review of draft-ietf-tls-ecc-new-mac-07

[Eric Rescorla]

Thanks for reviewing this.

-Ekr


On Thu, Jun 5, 2008 at 2:40 PM, Ben Campbell <[EMAIL PROTECTED]> wrote:
> I have been selected as the General Area Review Team (Gen-ART)
> reviewer for this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>
> Please resolve these comments along with any other Last Call comments
> you may receive.
>
>
> Document: draft-ietf-tls-ecc-new-mac-07
> Reviewer: Ben Campbell
> Review Date:  2008-06-05
> IETF LC End Date: 2008-06-11
> IESG Telechat date: (if known)
>
> Summary:
>
> This draft is ready for publication as an informational RFC
>
> Comments:
>
> None.
>
>
>
> Thanks!
>
> Ben.
>
>
>
___
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Review of draft-ietf-geopriv-http-location-delivery-07

[Eric Rescorla]

At Sun, 25 May 2008 15:54:16 -0700,
Eric Rescorla wrote:
> 
> At Sun, 25 May 2008 22:39:24 +0300,
> Hannes Tschofenig wrote:
> > 
> > Hi Ekr,
> > 
> > Eric Rescorla wrote:
> > > At Sun, 25 May 2008 19:19:58 +0300,
> > > Hannes Tschofenig wrote:
> > >   
> > >> Hi Ekr,
> > >>
> > >> Eric Rescorla wrote:
> > >> 
> > >>> $Id: draft-ietf-geopriv-http-location-delivery-07-rev.txt,v 1.1 
> > >>> 2008/05/24 15:03:19 ekr Exp $
> > >>>
> > >>> TECHNICAL
> > >>>
> > >>>
> > >>> S 4.2.
> > >>>which a Location Recipient (LR) can use to retrieve LI.  A location
> > >>>URI provided by a LIS can be assumed to be globally-addressable; that
> > >>>is, anyone in possession of the URI can access the LIS.  However,
> > >>>this does not in any way suggest that the LIS is bound to reveal the
> > >>>location associated with the location URI.  This issue is deemed out
> > >>>
> > >>> I don't understand this point. anyone in possession of the URI can
> > >>> access the URI but the LIS isn't required to reveal it? Those
> > >>> seem kind of contradictory.
> > >>>
> > >>>   
> > >>>   
> > >> Compare this with a HTTP URL where you might know it but still there are 
> > >> access policies that control access.
> > >> Possession does not necessarily mean that you can always get the 
> > >> location.
> > >> 
> > >
> > > OK. That makes sense. Perhaps rewrite:
> > > "access the LIS and request the location associated with the URI. 
> > > However, this this does not imply that the LIS is bound to service
> > > the request. For instance, the LIS might reject the request for
> > > access control reasons."
> > >
> > >   
> > Sounds good.
> > 
> > 
> > >   
> > >>> S 4.3.1.
> > >>>Devices that establish VPN connections for use by other devices
> > >>>inside a LAN or other closed network could serve as a LIS, that
> > >>>implements the HELD protocol, for those other Devices.  Devices
> > >>>within the closed network are not necessarily able to detect the
> > >>>presence of the VPN and rely on the VPN device.  To this end, a VPN
> > >>>device should provide the address of the LIS server it provides, in
> > >>>response to discovery queries, rather than passing such queries
> > >>>through the VPN tunnel.
> > >>>
> > >>> How do you envision this happening? Isn't this going to require 
> > >>> changing every VPN protocol? I think some more text would be 
> > >>> appropriate here...
> > >>>
> > >>>   
> > >>>   
> > >> It requires location information to be obtained before the tunnel is 
> > >> setup.
> > >> 
> > >
> > > OK, but I still don't understand how this is going to work. Say that
> > > I'm on a local network with a DHCP server and the VPN server is a couple
> > > of hops away. How does the VPN device "provide the address of the LIS
> > > server" to me?
> > >
> > >
> > >   
> > When you operate a network and you want this stuff to work then you have 
> > to consider this aspect.
> > In the past a few folks have suggested to write a BCP about how 
> > different deployments may deal with this aspect but I believe it is far 
> > too early todo so for a BCP.
> 
> The problem is that I'm not sure that this is an issue that can be solved 
> by the network operator. In the example I described, it sounds to
> me like new protocol work may be required.
> 
> 
> > >> The reference points to the device. What the Target uses this reference 
> > >> either for itself (if it wants to learn it's own location) or (more 
> > >> likely) it forwards that URI to someone else, for example to a PSAP.
> > >> 
> > >
> > > OK, but then what protocol is spoken over that URI? (see my 
> > > comments on S 8 below).
> > >
> > >
> > >   
> > The answer is:
> > http://tools.ietf.org/id/draft-winterbottom-geopriv-deref-protocol-00.txt
> 
> What's the status of that document?

Oh, and doesn't this need to be a normative ref, then?

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

Re: Review of draft-ietf-geopriv-http-location-delivery-07

[Eric Rescorla]

At Sun, 25 May 2008 22:39:24 +0300,
Hannes Tschofenig wrote:
> 
> Hi Ekr,
> 
> Eric Rescorla wrote:
> > At Sun, 25 May 2008 19:19:58 +0300,
> > Hannes Tschofenig wrote:
> >   
> >> Hi Ekr,
> >>
> >> Eric Rescorla wrote:
> >> 
> >>> $Id: draft-ietf-geopriv-http-location-delivery-07-rev.txt,v 1.1 
> >>> 2008/05/24 15:03:19 ekr Exp $
> >>>
> >>> TECHNICAL
> >>>
> >>>
> >>> S 4.2.
> >>>which a Location Recipient (LR) can use to retrieve LI.  A location
> >>>URI provided by a LIS can be assumed to be globally-addressable; that
> >>>is, anyone in possession of the URI can access the LIS.  However,
> >>>this does not in any way suggest that the LIS is bound to reveal the
> >>>location associated with the location URI.  This issue is deemed out
> >>>
> >>> I don't understand this point. anyone in possession of the URI can
> >>> access the URI but the LIS isn't required to reveal it? Those
> >>> seem kind of contradictory.
> >>>
> >>>   
> >>>   
> >> Compare this with a HTTP URL where you might know it but still there are 
> >> access policies that control access.
> >> Possession does not necessarily mean that you can always get the location.
> >> 
> >
> > OK. That makes sense. Perhaps rewrite:
> > "access the LIS and request the location associated with the URI. 
> > However, this this does not imply that the LIS is bound to service
> > the request. For instance, the LIS might reject the request for
> > access control reasons."
> >
> >   
> Sounds good.
> 
> 
> >   
> >>> S 4.3.1.
> >>>Devices that establish VPN connections for use by other devices
> >>>inside a LAN or other closed network could serve as a LIS, that
> >>>implements the HELD protocol, for those other Devices.  Devices
> >>>within the closed network are not necessarily able to detect the
> >>>presence of the VPN and rely on the VPN device.  To this end, a VPN
> >>>device should provide the address of the LIS server it provides, in
> >>>response to discovery queries, rather than passing such queries
> >>>through the VPN tunnel.
> >>>
> >>> How do you envision this happening? Isn't this going to require 
> >>> changing every VPN protocol? I think some more text would be 
> >>> appropriate here...
> >>>
> >>>   
> >>>   
> >> It requires location information to be obtained before the tunnel is setup.
> >> 
> >
> > OK, but I still don't understand how this is going to work. Say that
> > I'm on a local network with a DHCP server and the VPN server is a couple
> > of hops away. How does the VPN device "provide the address of the LIS
> > server" to me?
> >
> >
> >   
> When you operate a network and you want this stuff to work then you have 
> to consider this aspect.
> In the past a few folks have suggested to write a BCP about how 
> different deployments may deal with this aspect but I believe it is far 
> too early todo so for a BCP.

The problem is that I'm not sure that this is an issue that can be solved 
by the network operator. In the example I described, it sounds to
me like new protocol work may be required.


> >> The reference points to the device. What the Target uses this reference 
> >> either for itself (if it wants to learn it's own location) or (more 
> >> likely) it forwards that URI to someone else, for example to a PSAP.
> >> 
> >
> > OK, but then what protocol is spoken over that URI? (see my 
> > comments on S 8 below).
> >
> >
> >   
> The answer is:
> http://tools.ietf.org/id/draft-winterbottom-geopriv-deref-protocol-00.txt

What's the status of that document?


> > Well, lots of protocols would benefit from not having IP address
> > spoofing, but again, you're making a levy on network operations
> > on a global scale, no?
> >
> >   
> If you want to deal with certain attacks then you may want todo 
> something about it.

Sorry, I don't think I get what you're saying here.

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

Re: Review of draft-ietf-geopriv-http-location-delivery-07

[Eric Rescorla]

At Sun, 25 May 2008 19:19:58 +0300,
Hannes Tschofenig wrote:
> 
> Hi Ekr,
> 
> Eric Rescorla wrote:
> > $Id: draft-ietf-geopriv-http-location-delivery-07-rev.txt,v 1.1 2008/05/24 
> > 15:03:19 ekr Exp $
> >
> > TECHNICAL
> >
> >
> > S 4.2.
> >which a Location Recipient (LR) can use to retrieve LI.  A location
> >URI provided by a LIS can be assumed to be globally-addressable; that
> >is, anyone in possession of the URI can access the LIS.  However,
> >this does not in any way suggest that the LIS is bound to reveal the
> >location associated with the location URI.  This issue is deemed out
> >
> > I don't understand this point. anyone in possession of the URI can
> > access the URI but the LIS isn't required to reveal it? Those
> > seem kind of contradictory.
> >
> >   
> Compare this with a HTTP URL where you might know it but still there are 
> access policies that control access.
> Possession does not necessarily mean that you can always get the location.

OK. That makes sense. Perhaps rewrite:
"access the LIS and request the location associated with the URI. 
However, this this does not imply that the LIS is bound to service
the request. For instance, the LIS might reject the request for
access control reasons."


> > S 4.3.1.
> >Devices that establish VPN connections for use by other devices
> >inside a LAN or other closed network could serve as a LIS, that
> >implements the HELD protocol, for those other Devices.  Devices
> >within the closed network are not necessarily able to detect the
> >presence of the VPN and rely on the VPN device.  To this end, a VPN
> >device should provide the address of the LIS server it provides, in
> >response to discovery queries, rather than passing such queries
> >through the VPN tunnel.
> >
> > How do you envision this happening? Isn't this going to require 
> > changing every VPN protocol? I think some more text would be 
> > appropriate here...
> >
> >   
> It requires location information to be obtained before the tunnel is setup.

OK, but I still don't understand how this is going to work. Say that
I'm on a local network with a DHCP server and the VPN server is a couple
of hops away. How does the VPN device "provide the address of the LIS
server" to me?



> > S 5.1.
> >o  The HELD protocol must provide authentication, confidentiality and
> >   protection against modification per Section 10.3.
> >
> > Are you talking about HELD, which doesn't seem to have these
> > features, or about the transport protocol? Also, authentication
> > for who? Based on what model?
> >
> >
> >   
> The solution for HELD is to provide these capabilities as part of TLS.

Perhaps this should be rewritten, then as:

"The HELD protocol assumes that the underlying transport provides..."


> For the client to LIS interaction we are talking about server-side 
> authentication and not client-side authentication.
> 
> It would be important to spell this out.

I agree.


> > S 6.5.
> > I'm having trouble keeping straight two kinds of URIs:
> >
> > - URIs that a Device uses to get its own LI.
> > - LbyR references that the LIS hands out.
> >
> > This text seems to imply that an LIS can hand out a helds:
> > URI. Is that *also* the URI that a Device derferences?
> >   
> 
> The reference points to the device. What the Target uses this reference 
> either for itself (if it wants to learn it's own location) or (more 
> likely) it forwards that URI to someone else, for example to a PSAP.

OK, but then what protocol is spoken over that URI? (see my 
comments on S 8 below).



> > S 6.5.1.
> >
> >A "locationURI" SHOULD NOT contain any information that could be used
> >to identify the Device or Target.  Thus, it is RECOMMENDED that the
> >"locationURI" element contain a public address for the LIS and an
> >anonymous identifier, such as a local identifier or unlinked
> >pseudonym.
> >
> > 1. This seems like it should be clearer about what is desired.
> >In particular it's not just "identify" but also "link".
> >Also this needs to be clarified to indicate the implications
> >of idetntifiction by position.
> >
> > 2. Shouldn't this be MUST strength?
> >
> >
> >   
> This is a MUST when possession of the reference also means access to the 
> resource without any additional authorization policy being used by the 
> LIS

Review of draft-ietf-geopriv-http-location-delivery-07

[Eric Rescorla]

$Id: draft-ietf-geopriv-http-location-delivery-07-rev.txt,v 1.1 2008/05/24 
15:03:19 ekr Exp $

TECHNICAL


S 4.2.
   which a Location Recipient (LR) can use to retrieve LI.  A location
   URI provided by a LIS can be assumed to be globally-addressable; that
   is, anyone in possession of the URI can access the LIS.  However,
   this does not in any way suggest that the LIS is bound to reveal the
   location associated with the location URI.  This issue is deemed out

I don't understand this point. anyone in possession of the URI can
access the URI but the LIS isn't required to reveal it? Those
seem kind of contradictory.


S 4.3.1.
   Devices that establish VPN connections for use by other devices
   inside a LAN or other closed network could serve as a LIS, that
   implements the HELD protocol, for those other Devices.  Devices
   within the closed network are not necessarily able to detect the
   presence of the VPN and rely on the VPN device.  To this end, a VPN
   device should provide the address of the LIS server it provides, in
   response to discovery queries, rather than passing such queries
   through the VPN tunnel.

How do you envision this happening? Isn't this going to require 
changing every VPN protocol? I think some more text would be 
appropriate here...

S 5.1.
   o  The HELD protocol must provide authentication, confidentiality and
  protection against modification per Section 10.3.

Are you talking about HELD, which doesn't seem to have these
features, or about the transport protocol? Also, authentication
for who? Based on what model?


S 6.5.
I'm having trouble keeping straight two kinds of URIs:

- URIs that a Device uses to get its own LI.
- LbyR references that the LIS hands out.

This text seems to imply that an LIS can hand out a helds:
URI. Is that *also* the URI that a Device derferences?


S 6.5.1.

   A "locationURI" SHOULD NOT contain any information that could be used
   to identify the Device or Target.  Thus, it is RECOMMENDED that the
   "locationURI" element contain a public address for the LIS and an
   anonymous identifier, such as a local identifier or unlinked
   pseudonym.

1. This seems like it should be clearer about what is desired.
   In particular it's not just "identify" but also "link".
   Also this needs to be clarified to indicate the implications
   of idetntifiction by position.

2. Shouldn't this be MUST strength?



S 8.
Does this say somewhere what "helds" actually means? I see the
definitition of the URI, but it doesn't say what the 
underlying transport is, as far as I can tell. Given
a "helds:" URI, what am I supposed to do with it?


S 9.
OK and here's how I get confusied about the two types of URI,
since this is an HTTP binding, but there's no corresponding
URI.


   The implementation of HTTP as a transport mechanism MUST implement
   TLS as described in [RFC2818].

Is this MUST implement or MUST use? Don't the next two sentences
imply MUST use?


   TLS provides message integrity and
   privacy

"privacy" -> "confidentiality"

   between Device and LIS.  The LIS MUST use the server
   authentication method described in [RFC2818]; the Device MUST fail a
   request if server authentication fails, except in the event of an
   emergency.

This is incomplete, because 2818 assumes the presence of a URI to
compare against. Where does that come from? 

How is client authentication supposed to work here?


S 10.3.
   o  The network SHOULD have mechanisms that protect against IP address
  spoofing, such as those defined in [RFC3704].

Is this WG really in a position to levy a SHOULD level requirement
for network ingress filtering? Recall that this is really a global level
technology. Or do you mean something else?


   o  The LIS and network SHOULD be configured so that the LIS is made
  aware of Device movement within the network and addressing
  changes.  If the LIS detects a change in the network that results
  in it no longer being able to determine the location of the
  Device, then all location URIs for that Device SHOULD be
  invalidated.

This probably needs some more detail about how it's going to work.


   When there are further mechanisms available to authenticate ownership
   of the IP address, the LIS SHOULD use them to authenticate that the
   client is the owner of the target IP address.  For example, in a TLS
   transaction, the client could present a certificate with a public key
   bound to an IPv6 Cryptographically Generated Address, and the LIS
   could verify this binding.

Not that I think that any situation in which the client has an IP
level cert is particularly likely, but this one seems particularly
unlikely.






EDITORIAL
Abstract:
   independent of session-layer.  This document describes the use of
   Hypertext Transfer Protocol (HTTP) as a transport for the protocol.

This should be HyperText

Also, isn't this using HTTPS, not HTTP.


S 1.
   information.  The LIS service applies to access 

Re: ISSN for RFC Series under Consideration

[Eric Rescorla]

At Wed, 21 May 2008 17:52:55 -0400,
Melinda Shore wrote:
> 
> On 5/21/08 5:39 PM, "Brian E Carpenter" <[EMAIL PROTECTED]> wrote:
> > Possibly not, but there is still a crusty old world of academic
> > publications with traditional reference styles out there, and an ISSN
> > will make it much more straightforward to cite RFCs in peer-reviewed
> > publications. +1 that it's a no-brainer.
> 
> Hi - I'm really not trying to be a contrarian, just trying to
> sort through the actual issues here.  I don't think I've ever seen
> a reference that included an ISSN.  I've also never seen one
> used as a subject header (index term) in cataloging.  The only
> time I've personally seen them used is as *descriptive* information
> in a  catalog (library catalog, publisher's catalog, etc.).  I'm
> sure someone will be happy to dig up a counterexample but
> I do think they're pretty unusual.  Really, what are the odds
> that someone knows the ISSN but not the title or the author or
> the publisher or ... ?

I agree with Melinda here. I can't remember ever seeing anything
like an ISBN or an ISSN used as a citation in an academic paper.

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

Re: Randomness of Message-ID in IMDN

[Eric Rescorla]

At Thu, 15 May 2008 18:37:51 +0200,
Frank Ellermann wrote:
> 
> Eric Rescorla wrote:
> 
> > As I understand the situation, the sender the only person
> > who has to rely on the uniqueness of this header, right?
> 
> Hi, I have not the faintest idea what you are talking about,
> but if it is in any way related to the 2822upd concept of
> a Message-ID "worldwide unique forever" is no nonsense as
> soon as a Message-ID passes mail2news gateways, and/or is
> used in an Archived-At URL.

I admit that I only spent a little while examining this, so
perhaps Eric Burger can give a more definitive answer. However,
looking at the examples in -07, it sure looks to me like
message ids are not intended to be globally unique forever,
since, since they're way too short.


> | The Message-ID header field contains a unique message identifier.
> | Netnews is more dependent on message identifier uniqueness and fast
> | comparison than Email is
> [...]
> | The global uniqueness requirement for  in [RFC2822]
> | is to be understood as applying across all protocols using
> | such message identifiers, and across both Email and Netnews
> | in particular.
> 
> > (2) It is prohibitive for an attacker who has seen one or more
> > valid  Message-IDs to generate additional valid Message-IDs.
> 
> That would match pseudo-random number, but a "worldwide unique
> forever" Message-ID can boil down to timestamp @ domain (plus
> magic to avoid collisions for various Message-ID generators
> for a given domain or subdomain).

I'm not sure I get the point you're trying to make here. Yes,
if you want to have unforgeability this is a stronger requirement
than worldwide uniquness.

-Ekr




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

Re: Randomness of Message-ID in IMDN

[Eric Rescorla]

At Thu, 15 May 2008 00:25:38 +0800,
Eric Burger wrote:
> Thanks for your very, very quick review!  On the one open item for  
> discussion, Message-ID, I would offer (1) it is not a do-or-die  
> situation but that (2) using a cryptographically secure random number
> generator. achieves the same result with better properties.  Again, I  
> will defer back to you: I know the work group will push back strong if  
> a cryptographically secure random number generator is a resource hog.
> 
> Are there memory / CPU efficient cryptographically secure random  
> number generators?

Yes. For instance, the NIST SP 800-90 PRNG requires order
256-512 bits of internal state and two hash operations for
every hash-sized (160-512 bits) chunk of output. I would 
just use OpenSSL's cryptographically secure PRNG myself :)


> Should we give guidance to the range of numbers  
> (i.e., 32-bits, 512-bits, 6 digits, etc.)?

As I understand the situation, the sender the only person who has
to rely on the uniqueness of this header, right?


I would suggest instead of recommending a given number you explain
what the issues are and why this has to be unpredictable.  Perhaps
something like this:

  Because the Message-ID is used by the sender to correlate IMDNs with
  their respective IMs, the Message-ID MUST be selected so that:
  
  (1) There is a minimal chance of any two Message-IDs accidentally
  colliding within the time period within which an IMDN might be
  received.
  
  (2) It is prohibitive for an attacker who has seen one or more valid
  Message-IDs to generate additional valid Message-IDs.
  
  The first requirement is a correctness requirement to ensure correct
  matching. The second requirement prevents off-path attackers from
  forging IMDNs. In order to meet both of these requirements, it is
  RECOMMENDED that Message-IDs be generated using a cryptographically
  secure pseudorandom number generator (see [RFC 4086] and contain at
  least 64 bits of randomness, thus reducing the chance of a
  successful guessing attack to n/2^64, where n is the number of
  outstanding valid messages. Another potential approach is to combine
  a sequence number (providing uniqueness) with a cryptographic MAC
  for unforgeability.

Cheers,
-Ekr




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

Re: Re-review of draft-ietf-simple-imdn

[Eric Rescorla]

At Wed, 14 May 2008 12:20:21 +0800,
Eric Burger wrote:
> 
> Inline
> 
> On May 4, 2008, at 5:12 AM, Eric Rescorla wrote:
> 
> > I originally reviewed version -06 of this document
> > (2008-02-8). Examining the diff, it does not appear to me that any of
> > my comments from my previous review. Looking back in my mail folder, I
> > don't see any reasponses from the authors telling me my review was
> > wrong, so I'm retransmitting it here.
> >
> > -Ekr
> >
> > $Id: draft-ietf-simple-imdn-06-rev.txt,v 1.1 2008/02/08 18:17:54 ekr  
> > Exp $
> >
> > This document describes a mechanism for IM senders to request status
> > notifications for their IMs. The sender attaches a header specifying
> > the status conditions he wants to be notified of and intermediaries
> > and the receiving UA notify the sender (or someone else of his choice)
> > subject to policy constraints.
> >
> > One thing I'm not clear on is how the recipient determines where to
> > send the IMDN. Are they supposed to read the "From" field? One thing
> > that I don't get is how the IMDN-Route header interacts here.
> > It looks to me like this gets stuffed in the "To" in the IMDN.
> 
> You are right - we go on and on about IMDN-Record-Route, but we never  
> explicitly say what to do if there is no IMDN-Record-Route.  How about  
> the following text, inserted after the IMDN-Record-Route handling  
> paragraph:
> 
> If there is no IMDN-Record-Route header field, the IM Recipient
> MUST send the IMDN to the URI in the From header field.

That seems reasonable.



> > What happens if someone puts an IMDN-Record-Route that points
> > to an IMDN-ignorant UA?
> 
> We need to make it clear that an intermediary can only intermediate on  
> its own behalf.
> 
> How about the following text change in the Intermediary Behaviour  
> section:
> OLD
> An intermediary MAY choose to remain on the path of IMDNs for a  
> specific IM. It can do so by adding a CPIM IMDN-Record-Route header  
> field as the top IMDN-Record-Route header field and populating it with  
> its own address.
> NEW
> An intermediary MAY choose to remain on the path of IMDNs for a  
> specific IM. It can do so by adding a CPIM IMDN-Record-Route header  
> field as the top IMDN-Record-Route header field. The value of this  
> field MUST be the intermediary's own address.

OK.


> I was mulling over whether this introduces a security issue.  
> Specifically, what if a malicious intermediary wants to perform a DDoS  
> attack on an unsuspecting UA? The intermediary could spew a bunch of  
> messages towards other UAs, asking them to send IMDNs to DDoS target  
> by setting the topmost Record-Route to the target machine. The good  
> news is this takes a similar amount of resources as that intermediary  
> attacking the target directly. The bad news is the IMDN-Record-Route  
> mechanism provides a mechanism for the malicious node to hide its  
> identity from the target. The same issue arises if the node simply  
> puts in the target node as the From field of the IM and requests an  
> IMDN. The only trace would be server logs, which could identify the  
> malicious node as the source of the bogus IMDN requests.
> 
> How about we add the following to the "threats in the IMDN system"  
> list in the Security Considerations section:
> 
> A malicious intermediary or node attempts to flood a target
> node with IMDNs by inserting the target's address in the From
> field or IMDN-Record-Route field
> 
> And this text towards the end of the section:
> 
> One way to address the potential for a malicious node to use
> the IMDN system to anonomize attacks is to log all IMDN
> requests on the IM Recipient User Agent.  This allows for tracking
> of attacks, if only after they occur.  Note this also puts a  
> burden on
> the IM Recipient User Agent host.  Limited User Agents may not
> be able to preserve much of a log.

This seems to accurately characterize the situation. I'm not really
ready to offer an opinion on whether this is an acceptable
security situation--that seems like a question for the WG and the
IESG...


> > Other comments: I would avoid the term "non-repudiation" if at all
> > possible in S 5.3 and later. It's just so overloaded now that it's
> > hard to know what it means.
> Fixed
> 
> > S 6.5.  A little more explanation of why IMDN-Record-Route is useful
> > would help.
> Done
> 
> > S 7.1.1.1.  Why does Message-ID need any randomness at all as opposed
> > to uniqueness?  And if it needs randomness, why

Re-review of draft-ietf-simple-imdn

[Eric Rescorla]

I originally reviewed version -06 of this document
(2008-02-8). Examining the diff, it does not appear to me that any of
my comments from my previous review. Looking back in my mail folder, I
don't see any reasponses from the authors telling me my review was
wrong, so I'm retransmitting it here.

-Ekr

$Id: draft-ietf-simple-imdn-06-rev.txt,v 1.1 2008/02/08 18:17:54 ekr Exp $

This document describes a mechanism for IM senders to request status
notifications for their IMs. The sender attaches a header specifying
the status conditions he wants to be notified of and intermediaries
and the receiving UA notify the sender (or someone else of his choice)
subject to policy constraints.

One thing I'm not clear on is how the recipient determines where to
send the IMDN. Are they supposed to read the "From" field? One thing
that I don't get is how the IMDN-Route header interacts here.
It looks to me like this gets stuffed in the "To" in the IMDN.
What happens if someone puts an IMDN-Record-Route that points
to an IMDN-ignorant UA?
   
Overall, this document seems pretty well written and clearly lays out
the security issues.

That said, I'm concerned about the bounce/reflection threats discussed
in S 14 (where the sender asks for notification to a third party
victim).  I'm particularly concerned about the "note" field, since a
natural implementation seems to be to include an excerpt from the
message you're acknowledging.  This draft identifies the threat but
doesn't specify any mechanism for ameliorating them. I think some
suggested mechanisms would be appoprirate here, or at least some
analysis of what the potential mechanisms were and why they would or
would not work.

Other comments: I would avoid the term "non-repudiation" if at all
possible in S 5.3 and later. It's just so overloaded now that it's
hard to know what it means.

S 6.5.  A little more explanation of why IMDN-Record-Route is useful
would help.

S 7.1.1.1.  Why does Message-ID need any randomness at all as opposed
to uniqueness?  And if it needs randomness, why is 32 enough?

S 7.1.3.  Note that you can pack the state into the messageid if
you're willing to make large message ids and hte stte is small.

S 11.1

   An IMDN Payload is an XML document [6] that MUST be well formed and
   MUST be valid according to schemas, including extension schemas,
   available to the validater and applicable to the XML document.  The
   IMDN Payload MUST be based on XML 1.0 and MUST be encoded using
   UTF-8.

Is this a requirement that the receiver validate the XML?


S 12.1.1.  Why can't anonymous senders request notifications?

S 14.3.  See above comemnts about nonrepudiation

-Ekr

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

Re: WG Review: NETCONF Data Modeling Language (netmod)

[Eric Rescorla]

At Wed, 23 Apr 2008 09:39:13 +0200,
Harald Alvestrand wrote:
> I congratulate the participants who worked on the charter on managing to 
> have the discussion and come to consensus on an approach. I think it's 
> up to Eric to demonstrate to the IESG that there's support in the 
> community for disagreeing with the consensus of the discussing participants.

Harald,

Thanks for your comments.

I certainly agree that there is consensus on this approach among the
proponents of the various proposals. My concern, perhaps not clearly
stated, was that that consensus had not been validated with a wider
community, either in the BOF or in a more public forum. Based on the
discussion here, I think it's clear that in fact there is broad
consensus among the people who care.

I remain concerned that this is the wrong technical approach; it
appears to me to be unnecessary and overcomplicated. However, it's
clear that's a minority opinion, so I'll drop my objection to this
charter.

Best,
-Ekr

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

Re: WG Review: NETCONF Data Modeling Language (netmod)

[Eric Rescorla]

At Tue, 22 Apr 2008 19:17:47 -0600,
Randy Presuhn wrote:
> Our ADs worked very hard to prevent us from talking about technology
> choices at the CANMOD BOF.  Our original proposal for consensus
> hums included getting a of sense of preferences among the various
> proposals.  We were told we could *not* ask these questions, for fear
> of upsetting Eric Rescorla. 

Well, it's certainly true that the terms--agreed to by the IESG and
the IAB--on which the BOF were held were that there not be a beauty
contest at the BOF but that there first be a showing that there was
consensus to do work in this area at all. I'm certainly willing to cop
to being one of the people who argued for that, but I was far
from the only one. If you want to blame me for that, go ahead.

In any case, now that consensus to do *something* has been 
established it is the appropriate time to have discussion on 
the technology. I certainly never imagined that just because
there weren't hums taken in PHL that that meant no hums would
ever be taken.


> (It's unclear to me why his perspectives
> on configuration management information models should be subject to
> special consideration, while the folk who have been doing
> active work and real products in this area over the last two decades
> are largely ignored.)

Given that the BOF was in fact held and the WG is now being
proposed, "largely ignored" isn't quite the way I would characterize
the situation.

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

Re: WG Review: NETCONF Data Modeling Language (netmod)

[Eric Rescorla]

At Tue, 22 Apr 2008 23:16:02 +0200,
Bert Wijnen - IETF wrote:
> instead of discussing if there was consensus AT THE BOF
> (we all know that at this point in time we DO have 
> consensus between all the interested WORKERS in this space, 
> albeit that the current consensus was arrived at in further
> (smaller) meetings, in extensive DT work after the IETF and
> again after review on NGO list).

Which is why it is now returned to the broader community for
additional perspectives from those not already committed to a
particular path


> I propose that you list (again) your (technical) objections
> to the the current proposal.

Sure. Based on my knowledge of modelling/protocol description
languages, the techniques that Rohan described based on RNG and
Schematron seemed to me quite adequate to get the job done and the
relatively large baggage introduced by defining another language
(YANG) which is then translated into them seems wholly unnecessary.

I appreciate that some people believe that YANG is more expressive and
better suited for this particular purpose, but I didn't see any really
convincing arguments of that (I certainly don't find the arguments in
F.2 of draft-bjorklund-netconf-yang dispositive). Given what I know of
the complexity of designing such languages, and of their ultimate
limitations and pitfalls, this seems like a bad technical tradeoff.


> If all you can tell us is that
> we need to spend just more cycles on re-hashing the pros
> and cons of many possible approaches, then I do not
> see the usefulness of that discussion and with become 
> silent and leave your opion as one input to the IESG for
> their decision making process.

Unfortunately, it's not that simple. This is precisely the technical
discussion that needs to happen in a public forum, not on some design
team and then presented as a fait accompli.

That said, I think I've stated my position as best I can and that
while I understand yours, you and I just disagree about what the
IESG should do, so I'll take your advice to become silent at this
point.

-Ekr

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

Re: WG Review: NETCONF Data Modeling Language (netmod)

[Eric Rescorla]

At Tue, 22 Apr 2008 23:10:53 +0200,
Bert Wijnen - IETF wrote:
> 
> W.r.t.
> > All this is great stuff, but it all happened after the BOF, so
> > you can't reasonably claim that it represents BOF consensus.
> > And since BOFs are our primary mechanism for open, cross area
> > assessment for WG formation, I don't think it's accurate to suggest
> > that this is anywhere as near as open as actually having the
> > discussion in the BOF and gettting consensus, nor is it a substitute
> > for that.
> > 
> 
> I do not think that forming a WG MANDATES a BOF.
> Several WGs have been formed (in the past) without a BOF.
>
> So pls do not depict a story as if a BOF is the only way how we
> reach consensus in IETF on teh question of forming a WG or not.

Yes, but when you have a BOF which doesn't come to consensus on
a technical direction, which is then shortly followed by a proposed
charter which *does* specify a technical direction, I think that's
a somewhat different story.

-Ekr



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

Re: WG Review: NETCONF Data Modeling Language (netmod)

[Eric Rescorla]

At Tue, 22 Apr 2008 23:00:53 +0200,
David Partain wrote:
> 
> Greetings,
> 
> On Tuesday 22 April 2008 18.10.10 Eric Rescorla wrote:
> > I object to the formation of this WG with this charter.
> 
> For those who haven't been involved in the discussions to date, Eric has 
> objected to this work from the very beginning, as far  back as the first 
> attempt to get a BOF and has continued to object since that time.  As such, 
> I'm not surprised that he objects now.

Of course, since the issues I was concerned about from the very
beginning remain.


> > While there was a clear sense during the BOF that there was interest
> > in forming a WG, there was absolutely no consensus on technical
> > direction. 
> 
> Not surprisingly, I disagree.

Well, it's not really like this is a matter of opinion, since
the minutes are pretty clear that no consensus calls on the
choice of technology were taken, only that some work
in this area should move forward:

http://www.ietf.org/proceedings/08mar/minutes/canmod.txt


> The O&M community in the IETF has been talking about this specific topic for 
> a 
> long time, both in official and unofficial settings.  We've had many hours of 
> meetings where people from all various viewpoints have had hashed out their 
> differences.  This all culminated during the last IETF in a rather strong 
> sense of consensus amongst those most interested in this work that it's time 
> to stop talking and move forward, and that YANG was the best way to do that.  
> No, not everyone agreed, but we DO have rough consensus in the O&M community 
> and with the APPS area people who were involved that this was a reasonable 
> approach forward.
> 
> So, what about this consensus thing?
> 
> Sometimes ADs have to make a call, and my take is that Dan & Ron did so.  
> They 
> asked people representing ALL of the proposals to work on a proposal for a 
> charter.  We spent a great many cycles doing exactly that.  All of the 
> proposals that you saw presented at the CANMOD BOF were very active in the 
> charter proposal discussions and the result is the consensus of all of those 
> people.  No one got exactly what they wanted, but I think everyone felt is 
> was a reasonable way forward.  So, we have consensus amongst the various 
> proposals' authors.

The sum of all this verbiage is that, precisely as I said, there
wasn't consensus at the BOF, but that there was some set of rump
meetings where this compromise was hashed out. 

-Ekr


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

Re: WG Review: NETCONF Data Modeling Language (netmod)

[Eric Rescorla]

At Tue, 22 Apr 2008 19:14:10 +0200,
Bert Wijnen - IETF wrote:
> 
> Eric
> 
> REALLY... 

Yes, really.


> I heard during that BOF that there was consensus to start the work.
> I also saw that quite a few liked the YANG proposal, and several
> wanted to have mappings to either XSD or RELAX or DSDL.

I don't remember any consensus call, hum, or anything else
being taken on protocol selection. Rather, I remember there being
presentations with questions and minimal discussion.


> The smaller meetings that happened after the NOF, included people
> from all of the proposals that were on the table, including people
> who were in teh Design Team for the requirements. We had
> fruitfull discussions that converged onto a single approach.
> 
> We then got all the people from the various proposls together on
> the rdcml mailing list (the one that was used by the requirements
> design team), and we had a 2 week long discussion with multiple
> hundereds of emails and opinions, and again, we converged to a
> common and acceptable draft WG charter.
> 
> That draft WG charter was then put to the NGO mailing list were
> we had further discussion with various other people. Again we seem
> to have consensus. Several non-original-netconf people are on
> that mailing list, as a result of the BOF discussions we have had
> in the past thow IETF meetings.

All this is great stuff, but it all happened after the BOF, so
you can't reasonably claim that it represents BOF consensus.
And since BOFs are our primary mechanism for open, cross area
assessment for WG formation, I don't think it's accurate to suggest
that this is anywhere as near as open as actually having the
discussion in the BOF and gettting consensus, nor is it a substitute
for that.


> Further, the change you propose to the WG charter, could be done,.
> and then in the first WG session we could declare victory for the
> milestone you want. I believe that virtually all of the interested
> people were involved in the discussion sofar. So I do not see why
> we would need long in a newly formed WG to come to the same
> conclusion again.

Perhaps that's true, but I don't see that that's an argument
against actually running an open process rather than declaring
a winner in advance and asking the IETF to ratify it.

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

Re: WG Review: NETCONF Data Modeling Language (netmod)

[Eric Rescorla]

At Tue, 22 Apr 2008 10:08:49 -0700,
Andy Bierman wrote:
> 
> Eric Rescorla wrote:
> > I object to the formation of this WG with this charter.
> > 
> > While there was a clear sense during the BOF that there was interest
> > in forming a WG, there was absolutely no consensus on technical
> > direction. Rather, a number of proposals were presented, but no
> > strawpoll, hum, or sense of the room was taken, nor, as far as I can
> > determine, has there been any such consensus call been taken on any
> > list I'm aware of. This wasn't an accident--the BOF was explicitly
> > intended only to determine whether some work in this area should
> > proceed, not to select a technical approach.
> > 
> > I understand that an approach like this was proposed in the OPSAREA
> > meeting by Chris Newman and then that there was a breakout meeting
> > where it was discussed further. The minutes don't record any consensus
> > call on this combined direction (only strawpolls on the individual
> > proposals), and even if such a consensus call had been held, the
> > OPSAREA meeting would not be the appropriate place for it: this
> > discussion needs to happen in either the BOF (to allow cross-area
> > review) or in the designated WG, when it is formed. 
> >
> 
> 
> I believe there was consensus in the CANMOD BoF that
> the requirements were sufficiently understood, and
> the purpose of that BoF had been fulfilled.

Agreed.


> After the CANMOD BoF, a 15 person design team was formed,
> which reached consensus on a technical approach, embodied
> in the charter text.  There was also unanimous agreement
> on the charter, outside the design team (on the NGO mailing list).

Neither of these has any formal standing. The precise reason we
have BOFs is to have these discussions in person at IETF.


> > Accordingly, if this WG is to be formed, the entire section (and
> > corresponding milestones) which specifies the technology needs to be
> > removed. Rather, the first work item should be to select a technical
> > approach.
> 
> I thought the charter text did specify a technical approach,
> which is to utilize YANG as a high-level DML and map YANG
> constructs to DSDL and XSD.

Yes, that's what I'm objecting to, since that's far from the
only technical approach. For instance, one could just use DSDL
or XSD without YANG.


> Can you explain this work item further?

Uh, have a charter that doesn't specify the technical approach and
then have an open discussion in the WG meetings followed by selection
of a technical approach. Compare, for instance, the process that
P2PSIP is engaging in now.

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

Re: WG Review: NETCONF Data Modeling Language (netmod)

[Eric Rescorla]

I object to the formation of this WG with this charter.

While there was a clear sense during the BOF that there was interest
in forming a WG, there was absolutely no consensus on technical
direction. Rather, a number of proposals were presented, but no
strawpoll, hum, or sense of the room was taken, nor, as far as I can
determine, has there been any such consensus call been taken on any
list I'm aware of. This wasn't an accident--the BOF was explicitly
intended only to determine whether some work in this area should
proceed, not to select a technical approach.

I understand that an approach like this was proposed in the OPSAREA
meeting by Chris Newman and then that there was a breakout meeting
where it was discussed further. The minutes don't record any consensus
call on this combined direction (only strawpolls on the individual
proposals), and even if such a consensus call had been held, the
OPSAREA meeting would not be the appropriate place for it: this
discussion needs to happen in either the BOF (to allow cross-area
review) or in the designated WG, when it is formed. 
  
Accordingly, if this WG is to be formed, the entire section (and
corresponding milestones) which specifies the technology needs to be
removed. Rather, the first work item should be to select a technical
approach.

-Ekr

> NETCONF Data Modeling Language (netmod)
> 
> Last modified: 2008-04-10
> 
> Current Status: Proposed Working Group
> 
> Chair(s): 
> 
> TBD
> 
> Operations and Management Area Director(s):
> Dan Romascanu 
> Ronald Bonica rbonica at juniper.net
> 
> Mailing Lists:
> 
> General Discussion: ngo at ietf.org
> 
> Description:
> 
> The NETCONF Working Group has completed a base protocol to be
> used for configuration management.  However, the NETCONF protocol
> does not include a standard content layer.  The specifications do
> not include a modeling language or accompanying rules that can be
> used to model the management information that is to be configured
> using NETCONF. This has resulted in inconsistent syntax and
> interoperability problems. The purpose of NETMOD is to support
> the ongoing development of IETF and vendor-defined data models
> for NETCONF.
> 
> NETMOD's requirements are drawn from the RCDML requirements draft
> (draft-presuhn-rcdml) and documents referenced therein.


> The WG will define a "human-friendly" modeling language defining
> the semantics of operational data, configuration data,
> notifications, and operations.  This language will focus on
> readability and ease of use.  This language must be able to serve
> as the normative description of NETCONF data models.  The WG will
> use YANG (draft-bjorklund-yang) as its starting point for this
> language.
> 
> Language abstractions that facilitate model extensibility and
> reuse have been identified as a work area and will be considered
> as a work item or may be integrated into the YANG document based
> on WG consensus.
> 
> The WG will define a canonical mapping of this language to
> NETCONF XML instance documents, the on-the-wire format of
> YANG-defined XML content.  Only data models defined in YANG will
> have to adhere to this on-the-wire format.
> 
> In order to leverage existing XML tools for validating NETCONF
> data in various contexts and also facilitate exchange of data
> models and schemas with other IETF working groups, the WG will
> define standard mapping rules from YANG to the DSDL data modeling
> framework (ISO/IEC 19757) with additional annotations to preserve
> semantics.
> 
> The initial YANG mapping rules specifications are expressly defined for
> NETCONF modeling.  However, there may be future areas of
> applicability beyond NETCONF, and the WG must provide suitable
> language extensibility mechanisms to allow for such future work.
> The NETMOD WG will only address modeling NETCONF devices and the
> language extensibility mechanisms.  Any application of YANG to
> other protocols is future work.
> 
> The WG will consult with the NETCONF WG to ensure that NETMOD's
> decision do not conflict with planned work in NETCONF (e.g.,
> locking, notifications).
> 
> While it is desirable to provide a migration path from existing
> MIB modules to YANG data models (modules), it is not a
> requirement to provide full compatibility between SMIv2 and YANG.
> The Working Group will determine which constructs (e.g., conformance
> statements) are not relevant for translation from SMIv2 to YANG. YANG is
> also permitted to introduce constructs that cannot be expressed in SMIv2.
> However, all basic types that can be represented in SMIv2 must be
> expressible in YANG.
> 
> Initial deliverables are below.  The working group may choose to
> combine multiple deliverables into a single document where deemed
> appropriate.
> 
> 1. An architecture document explaining the relationship
> between YANG and its inputs and outputs. (informational)
> 
> 2. The YANG data modeling language and semantics (proposed
>

Re: Blue Sheet Change Proposal

[Eric Rescorla]

At Fri, 04 Apr 2008 08:57:50 -0700,
Michael Thomas wrote:
> 
> Eric Rescorla wrote:
> > At Thu,  3 Apr 2008 20:10:12 -0400 (EDT),
> > Scott O. Bradner wrote:
> >   
> >> Ole guessed
> >> 
> >>> My understanding is that the blue sheet serves mainly as a record of 
> >>> "who was in the room" which I think is largely used to plan room 
> >>> capacities for the next meeting.
> >>>   
> >> the "blue sheets" are required as part of the basic openness  
> >> process in a standards organization - there is a need to know 
> >> "who is in the room" (see RFC 2418 section 3.1 for the actual
> >> requirement)
> >>
> >> the blue sheets become part of the formal record of the standards
> >> process and can be retrieved if needed (e.g. in a lawsuit) but are not
> >> generally made available 
> >>
> >> as pointed out by Mark Andrews - email addresses can be useful in 
> >> determining the actual identity of the person who scrawled their 
> >> name on the sheet - so it is an advantage to retain them
> >>
> >> I'm trying to understand how the blue sheets contribute in any
> >> significant way to the spam problem - someone whould have to be 
> >> surreptitiously copying  them or quickly writing down the email 
> >> addresses - both could happen but do not seem to be all that 
> >> likely there are far more efficient ways to grab email addresses
> >>
> >> so, my question is "is this a problem that needs solving"?
> >> 
> >
> > The only reason I've heard is that some claim that people don't
> > write their names on the blue sheets out of concern over spam.
> >   
> This doesn't seem very reasonable to me... if you post on any public
> list -- like this one -- your likelihood for harvest is far, far higher. 
> Let's
> face it, in 2008 trying to have "private" email addresses as a spam defense
> strategy is oh so 1998.

Oh, I agree.

My only argument here would be that if people actually do this in
significant numbers that accomodating them might be easier than
educating them.

-Ekr

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

Re: Blue Sheet Change Proposal

[Eric Rescorla]

At Thu,  3 Apr 2008 20:10:12 -0400 (EDT),
Scott O. Bradner wrote:
> 
> 
> Ole guessed
> > My understanding is that the blue sheet serves mainly as a record of 
> > "who was in the room" which I think is largely used to plan room 
> > capacities for the next meeting.
> 
> the "blue sheets" are required as part of the basic openness  
> process in a standards organization - there is a need to know 
> "who is in the room" (see RFC 2418 section 3.1 for the actual
> requirement)
> 
> the blue sheets become part of the formal record of the standards
> process and can be retrieved if needed (e.g. in a lawsuit) but are not
> generally made available 
> 
> as pointed out by Mark Andrews - email addresses can be useful in 
> determining the actual identity of the person who scrawled their 
> name on the sheet - so it is an advantage to retain them
> 
> I'm trying to understand how the blue sheets contribute in any
> significant way to the spam problem - someone whould have to be 
> surreptitiously copying  them or quickly writing down the email 
> addresses - both could happen but do not seem to be all that 
> likely there are far more efficient ways to grab email addresses
> 
> so, my question is "is this a problem that needs solving"?

The only reason I've heard is that some claim that people don't
write their names on the blue sheets out of concern over spam.

This actually seems like something we could test pretty easily
by counting room entries and blue sheet entries and comparing
the totals...

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

Re: Blue Sheet Change Proposal

[Eric Rescorla]

At Fri, 04 Apr 2008 10:22:42 +1100,
Mark Andrews wrote:
> 
> 
> > All,
> > 
> > We are considering changing the meeting Blue Sheet by eliminating the 
> > need to enter an email address to avoid spam concerns.
> > 
> > Is there any good reason to retain that info bit?
> > 
> > Ray
> > ___
> > IETF mailing list
> > IETF@ietf.org
> > https://www.ietf.org/mailman/listinfo/ietf
> 
>   It's is the only unique token on the blue sheets.  This
>   assumes no shared email accounts which is a pretty reasonable
>   assumption in this case.

I'm not getting why this is important. It's not like we're using it
to key a hash table. As Ole observes, the blue sheets are used primarily
for counting attendance, and I hear, occasionally as proof that someone was 
actually present. In both of these cases, I think we can probably
tolerate this amount of ambiguity.

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

Re: TLS vs. IPsec (Was: Re: experiments in the ietf week)

[Eric Rescorla]

At Wed, 26 Mar 2008 07:32:41 -0700,
Eric Rescorla wrote:
> 
> At Wed, 26 Mar 2008 15:01:21 +0100,
> Iljitsch van Beijnum wrote:
> > 
> > On 26 mrt 2008, at 14:36, Eric Rescorla wrote:
> > 
> > > - Modern cryptographic implementations are extremely fast. For
> > >  comparison the MacBook Air I'm typing this on will do order 10^6
> > >  HMAC-MD5s/second on 64-byte packets.  So, to consume all my
> > >  resources would require order 10^8 bits per second, which is a
> > >  pretty serious packet-based DoS ittack on many contexts.
> > 
> > This is a bogus argument. Implementations are always inferior to  
> > optimistic performance claims 
> 
> What do you mean "optimistic performance claims"? I ran
> "openssl speed". That's actually a pretty good reflection
> of what the performance of SSL implementation will be.

That said, there is a dependency on cipher suite. So, RC4-MD5
is not too much slower than HMAC-MD5 alone. By contrast, 
AES-SHA1 is maybe 4x slower. OTOH, I only was counting the 
size of the TLS records themselves, so when you add the TCP
and UDP headers, the bit rate is probably twice as high.

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

Re: TLS vs. IPsec (Was: Re: experiments in the ietf week)

[Eric Rescorla]

At Wed, 26 Mar 2008 15:01:21 +0100,
Iljitsch van Beijnum wrote:
> 
> On 26 mrt 2008, at 14:36, Eric Rescorla wrote:
> 
> > - Modern cryptographic implementations are extremely fast. For
> >  comparison the MacBook Air I'm typing this on will do order 10^6
> >  HMAC-MD5s/second on 64-byte packets.  So, to consume all my
> >  resources would require order 10^8 bits per second, which is a
> >  pretty serious packet-based DoS ittack on many contexts.
> 
> This is a bogus argument. Implementations are always inferior to  
> optimistic performance claims 

What do you mean "optimistic performance claims"? I ran
"openssl speed". That's actually a pretty good reflection
of what the performance of SSL implementation will be.


> and although maybe your laptop CAN do  
> that that doesn't mean you WANT it to spend its cycles and battery  
> power on that. (Or maybe you do, but I certainly don't.)

No, I don't, but once again you're totally missing the point:
the amount of bandwidth you'd need to perform a computational
DoS attack on the symmetric part of the system is so high
that it's basically a bandwidth-based DoS in itself.

> > - Even mounting this attack requires knowing both host/port
> >  quartets. With DTLS, as with TLS, the responder/server's
> >  port is typically known whereas the initiator/client's port
> >  is random or pseudorandom. This creates some barrier to
> >  mounting this attack.
> 
> The DTLS design to reuse the port numbers is not unreasonable as long  
> as DoS against CPU resources isn't a concern. But not using random  
> sequence numbers, like TCP has been doing since the dawn of time, is a  
> serious oversight because it costs next to nothing and buys a lot of  
> protection against spoofing attacks.

1. TCP has *not* used random sequence numbers since the dawn of
   time. On the contrary, they have been historically extremely
   predictable, hence RFC 1948 (though of course the techniques
   predate it.) And the reason that it now uses random sequence
   numbers is to block attacks much more severe than the ones
   you're describing here.
2. You're using the term "spoofing" in a way that's misleading.
   DTLS packets injected into the network by an attacker who
   does not have possession of the keying materal are quite
   correctly rejected by the DTLS stack. It's just that they
   are cryptographically verified first without being rejected
   out of hand.
3. As you say, it *is* cheap, but in keeping with our general
   principle of not improving TLS but just making it datagram
   capable, we decided to stick with TLS's 0-based sequence
   numbers.

Not to put too fine a point on it, I think this proposed attack
s basically irrelevant. I have not heard of any situation in
which anyone has mounted DoS attacks on machines by forcing
them to repeatedly perform cryptographic packet verifications
(most likely since it's so lame) and in the unlikely case that
that were to happen, we could always quickly roll out an
extension to randomize the sequence numbers.

> > - A very similar attack is available on IKE (and DTLS, of
> >  course). In order to block DoS attacks, both handshakes
> >  offer the option of doing a "stateless cookie" exchange,
> >  in which the responder gives the initiator a token which
> >  can be used to verify the client's next message (which must
> >  of course contain the token). But the way these tokens are
> >  generates is to have the responder compute a cryptographic
> >  MAC/hash over some input data. So an attacker can force
> >  any random IKE or DTLS stack to do as many digest operations
> >  as it wants.
> 
> That doesn't make sense. For such a cookie to provide additional  
> benefit over the normal HMAC, the value in the next message must be  
> present in that next message in the clear so the number of crypto  
> operations required is equal to the number of valid packets, which  
> isn't under the control of an attacker, rather than the total number  
> of packets (like a HMAC), which can be inflated by an attacker.

You might want to refamiliarize yourself with how these systems
actually work.

Let's take IKE as an example (though the situation is the same in
DTLS). Here's the initial exchange from RFC 4306 S 2.6.:

   Initiator  Responder
   ------
   HDR(A,0), SAi1, KEi, Ni   -->

 <-- HDR(A,0), N(COOKIE)

   HDR(A,0), N(COOKIE), SAi1, KEi, Ni   -->

 <-- HDR(A,B), SAr1, KEr, Nr, [CERTREQ]

So, whenever the responder gets *any* initial packet from
a plausible coun

Re: TLS vs. IPsec (Was: Re: experiments in the ietf week)

[Eric Rescorla]

At Wed, 26 Mar 2008 13:25:20 +0100,
Iljitsch van Beijnum wrote:
> 
> On 25 mrt 2008, at 16:10, Dan Wing wrote:
> 
> > ...
> >> And yes, the issues I referred to are DoS and TCP spoofing.
> >> These can only be protected against at the  network level.
> 
> > What are your thoughts on DTLS's DoS and spoofing protection?
> 
> Looks like this is mostly similar to IPsec except that the port  
> numbers rather than SA is used to demultiplex so the anti-DoS  
> protection that the sequence number / anti replay counter provides is  
> less than with IPsec.

You really need to describe the attacks you're concerned about, rather
than handwaving. After reading this a few times, I *think* you're
claiming the following:

An attacker who knows the host-port quartet of a DTLS association
can send send completely bogus but correctly formatted packets to
one side and therefore force them to attempt to decrypt the
record. This amounts to a computational DoS attack. Whereas, by
contrast, mounting this attack on IPsec requires knowing the SPI,
which presumably requires being on path, since it's random.

Do I have this right?

If so this is a pretty feeble attack. 

- Modern cryptographic implementations are extremely fast. For
  comparison the MacBook Air I'm typing this on will do order 10^6
  HMAC-MD5s/second on 64-byte packets.  So, to consume all my
  resources would require order 10^8 bits per second, which is a
  pretty serious packet-based DoS ittack on many contexts.
- Even mounting this attack requires knowing both host/port
  quartets. With DTLS, as with TLS, the responder/server's
  port is typically known whereas the initiator/client's port
  is random or pseudorandom. This creates some barrier to
  mounting this attack.
- A very similar attack is available on IKE (and DTLS, of
  course). In order to block DoS attacks, both handshakes
  offer the option of doing a "stateless cookie" exchange,
  in which the responder gives the initiator a token which 
  can be used to verify the client's next message (which must
  of course contain the token). But the way these tokens are
  generates is to have the responder compute a cryptographic
  MAC/hash over some input data. So an attacker can force
  any random IKE or DTLS stack to do as many digest operations
  as it wants.

> I assume this means in the future we'll be running TCP over DTLS over  
> UDP...
> 
> The part that I don't like about DTLS is the way it avoids dealing  
> with MTU issues and pretty much tells people to do PMTUD for IPv4 for  
> UDP even though in theory this is extremely hard to get to work and  
> practice it never works.

You've misunderstood the purpose of DTLS, which is to replicate
the semantics of UDP to the greatest extent possible, consistent
with also provided an association-based security system. Accordingly,
since UDP-based applications have to deal with PMTU, they have to
do so with DTLS as well.

-Ekr


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

Re: experiments in the ietf week

[Eric Rescorla]

At Mon, 24 Mar 2008 15:17:56 +0100,
Iljitsch van Beijnum wrote:
> 
> On 19 mrt 2008, at 1:46, Eric Rescorla wrote:
> 
> >> A more interesting experiment would be to do away with SSL for a bit
> >> and use IPsec instead.
> 
> > Why would this be either interesting or desirable?
> 
> SSL is vulnerable to more attacks than IPsec and IPsec is more general  
> than SSL. As such it would be good if we could have IPsec deployment  
> similar to SSL deployment, similar to how it would be good to have  
> IPv6 rather than IPv4 deployment, so a similar experiment could be  
> useful in showing what if any the reasons are we're still stuck with  
> the inferior SSL/TLS technology.

One of the true joys of the IETF is watching people explain why 
their favorite technology is superior to the technology people
have actually chosen to use.

Both IPsec and SSL have applications where they are the appropriate
choice. I don't think there's a lot of point in going into them in
detail. But given that the attacks you're mentioning are frankly
irrelevant in 99.9% of cases (btw, I know what TCP spoofing is, but
it's not relevant for TLS, because the application should be looking
at the cryptographic identity, not the transport layer identity), the
notion that we should tear out most of the application layer security
infrastructure to accomodate your notions of architetural
appropriateness strikes me as extremely dubious.

-Ekr




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

Re: experiments in the ietf week

[Eric Rescorla]

At Wed, 19 Mar 2008 22:59:52 +1100,
Mark Andrews wrote:
> 
> 
> > At Sun, 16 Mar 2008 19:44:12 +0100,
> > Iljitsch van Beijnum wrote:
> > > 
> > > On 16 mrt 2008, at 2:16, Mark Andrews wrote:
> > > 
> > > > Enable DNSSEC validation on the network's servers.  At a
> > > > minimum make them DNSSEC transparent.
> > > 
> > > 
> > > Is there any software out there for common OSes that does something  
> > > useful with this?
> > > 
> > > A more interesting experiment would be to do away with SSL for a bit  
> > > and use IPsec instead. 
> > 
> > Why would this be either interesting or desirable?
> 
>   DNSSEC transparency is important for machines on the IPv6
>   only net trying to validate answers off IPv4 only servers.
> 
>   Validatation is useful for protecting the resolvers themselves.

I was referring to Iljitsch's suggestion about SSL and IPsec, not
the suggestion about DNSSEC.

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

Re: experiments in the ietf week

[Eric Rescorla]

At Sun, 16 Mar 2008 19:44:12 +0100,
Iljitsch van Beijnum wrote:
> 
> On 16 mrt 2008, at 2:16, Mark Andrews wrote:
> 
> > Enable DNSSEC validation on the network's servers.  At a
> > minimum make them DNSSEC transparent.
> 
> 
> Is there any software out there for common OSes that does something  
> useful with this?
> 
> A more interesting experiment would be to do away with SSL for a bit  
> and use IPsec instead. 

Why would this be either interesting or desirable?

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