Subject: [Ecrit] LoST open issue: ttl

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 22 Oct 2006 23:23:03 -0400

In updating the draft, we stumbled across one open issue that  
probably needs more working group discussion. It doesn't seem all  
that important, but has wider implications.

The current draft version has the time-to-live value as an integer,  
measured in seconds. An alternative would be an absolute XML-style  
time, in GMT. (XML allows time zones, but those don't seem  
particularly useful here.)

The major trade-offs are, in my estimation:

(Sync) Relative times don't need clock sync. Whether this matters or  
not depends on one's estimation of clock sync. In our case, a few  
minutes are unlikely to matter, given that TTL values of a day or  
month are far more likely. Note also that the HTTP Date header can be  
used to detect client mis-configuration.

(Delay) Relative TTL values need to be updated each time the object  
sits in a queue somewhere. Thus, it's important that any delays  
outside the control of LoST-aware components is minimized, such as  
any caching by HTTP proxies or delayed TCP. This is probably more of  
an exception condition than something that would occur on a daily basis.

(Signing) A major issue is signing. If we want the authoritative  
source of the data to sign the object, e.g., using XML-DSIG, relative  
times aren't useful, since a receiver cannot tell if the object has  
expired or not. A malicious user can easily inject signed, but  
expired, data into the system if relative expiration times are used.  
(Alternatively, the absolute time of creation of the object can be  
included, but that has the same Sync problem, so one gets the worst  
of both approaches.)

(Caching) It would be nice to be able to cache whole  
findServiceResponse objects without having to assemble them on  
retrieval. Otherwise, it would be likely that a LoST resolver, for  
example, would have to store the DOM in some serialized fashion,  
update it for each retrieval to correct the TTL value, and then  
generate, from scratch, the actual textual XML representation. Since  
such retrievals from caches are likely to be far more common than  
from origin servers, assuming caches are useful at all, this XML  
generation may well dominate the overall computational complexity.

There may be other considerations that I'm missing.

Henning

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: Andrew Newton <[email-masked]>
Date: Mon, 23 Oct 2006 13:43:27 -0400

First, I find the argument for delay unconvincing as LoST is not a 
store-and-forward system and therefore there are no queues of the nature you 
are talking about.  I hope that anybody writing LoST code would know not to 
wait 30 days on a TCP timeout, as well.

Second, the issue of DSIG has come up many times on this list and I don't 
think we are any closer to getting consensus.  In short, in an emergency 
they will be ignored if they are invalid, so what is the point.  To add to 
that, absolute times could easily cause a signed response to be deemed 
invalid with just one minute of drift at either end, and one minute drift is 
not that uncommon.

Third, to negate re-assembly, we'd also have to take boundary references and 
address validation checks out of the protocol.

Finally, the specification of the absolute time is much more complex than 
relative time.  Since LoST uses Relax NG, the data type would be the XML 
Schema dateTime, which is a subset of ISO 8601.  That's already a source of 
interoperability problems.  Add on top of that rules for disallowing 
timezone (which only cause greater confusion), and you have two ways 
programmers could do the wrong thing very easily.  From a code standpoint, 
this is more complex than relative ttl in seconds. Here is the Java code 
doing relative time:

int ttl = Integer.parseInt( attribute.getValue() );
GregorianCalendar gc = new GregorianCalendar();
gc.add( gc.SECOND, ttl );

Here is the code for the absolute time (from 
http://www.dpawson.co.uk/relaxng/schema/datetime.html)

import java.text.DecimalFormat;
import java.text.SimpleDateFormat;
import java.util.Date;
import java.util.TimeZone;

public class Now {
   public static void main(String[] args) {
     System.out.println(Now.getISO8601DateTime());
   }

   public static String getISO8601DateTime() {
     SimpleDateFormat ISO8601Local = new SimpleDateFormat(
       "yyyy-MM-dd'T'HH:mm:ss");
     TimeZone timeZone = TimeZone.getDefault();
     ISO8601Local.setTimeZone(timeZone);
     DecimalFormat twoDigits = new DecimalFormat("00");

     Date now = new Date();
     int offset = ISO8601Local.getTimeZone().getOffset(now.getTime());
     String sign = "+";
     if (offset < 0) {
       offset = -offset;
       sign = "-";
     }
     int hours = offset / 3600000;
     int minutes = (offset - hours * 3600000) / 60000;
     // As things stand any odd seconds in the offset are silently truncated.
     // Uncomment the next 5 lines to detect that rare circumstance.
     //if (offset != hours * 3600000 + minutes * 60000) {
     //  // E.g. TZ=Asia/Riyadh87
     //  throw new RuntimeException("TimeZone offset (" + sign + offset +
     //                             " ms) is not an exact number of minutes");
     //}
     String ISO8601Now = ISO8601Local.format(now) + sign +
       twoDigits.format(hours) + ":" + twoDigits.format(minutes);
     return ISO8601Now;
   }
}

-andy

---

From: Richard Barnes <[email-masked]>
Date: Mon, 23 Oct 2006 16:33:54 -0400

Henning,

I'm not sure what the conflict is w.r.t. signing.  For example, couldn't 
the authority sign its portion of the response (URI, Service Boundary, 
etc), and then the LoST server could sign the full combination of this 
signed data with the TTL?  Some responses to Andrew are inline below.

Beyond that, I don't regard TTL as an especially sensitive issue.  If a 
client is using LoST for emergency calling, then it seems like the TTL 
is likely to be ignored in the name of keeping around some URI to try if 
everything else falls through.  That being the case, it doesn't seem 
like the TTL requires a whole lot of precision, so relative times seem 
good enough (despite caching issues).

Cheers,
--Richard

> store-and-forward system and therefore there are no queues of the nature 
> you are talking about.  I hope that anybody writing LoST code would know 
> not to wait 30 days on a TCP timeout, as well.

Actually, this seemed to me to be one of the more sticky points: LoST is 
not store-and-forward, but it operates (by default) over HTTP, and there 
are untold numbers of HTTP proxies in this world.

> Second, the issue of DSIG has come up many times on this list and I 
> don't think we are any closer to getting consensus.  In short, in an 
> emergency they will be ignored if they are invalid, so what is the 
> point.

Just like DSIG arguments, the "emergency excuse" keeps coming up on the 
list.  Even if signatures might not be used as a go/no-go criterion in 
emergency circumstances, they can provide a measure of confidence, and 
they can still be useful in other contexts.  (I'm not saying they're a 
necessity here, just that they shouldn't categorically be ruled out.)

> To add to that, absolute times could easily cause a signed 
> response to be deemed invalid with just one minute of drift at either 
> end, and one minute drift is not that uncommon.

This argues against absolute times because of clock sync, not because of 
signatures.  (Maybe that's what you meant, but I was confused by your 
placing it next to your comments on signatures.)

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 23 Oct 2006 20:52:06 -0400

On Oct 23, 2006, at 4:33 PM, Richard Barnes wrote:

> Henning,
>
> I'm not sure what the conflict is w.r.t. signing.  For example,  
> couldn't the authority sign its portion of the response (URI,  
> Service Boundary, etc), and then the LoST server could sign the  
> full combination of this signed data with the TTL?  Some responses  
> to Andrew are inline below.

Right, but it is much less likely that the recipient has any useful  
trust relationship with intermediaries, which could be operated by  
the hotel I'm staying at and the bogus LoST server it's advertising.

I don't see the advantage of this complexity.

>
> Beyond that, I don't regard TTL as an especially sensitive issue.   
> If a client is using LoST for emergency calling, then it seems like  
> the TTL is likely to be ignored in the name of keeping around some  
> URI to try if everything else falls through.  That being the case,  
> it doesn't seem like the TTL requires a whole lot of precision, so  
> relative times seem good enough (despite caching issues).

The problem is that an attacker can grab an old (stale) signed  
response and slip it to the innocent client. Take an extreme case,  
unlikely but possible: Some service has been compromised or handed  
off to somebody else and the LoST entry is changed for that service.  
Unfortunately, the bad guy will continue to waive the signed, but  
stale, version of the advertisement and can thus convince clients  
that the bad service is still good. In other words, a classical  
replay attack. Designing a system that facilitates such attacks seems  
like a bad idea.

Henning

---

From: Andrew Newton <[email-masked]>
Date: Mon, 23 Oct 2006 21:30:33 -0400

On Oct 23, 2006, at 4:33 PM, Richard Barnes wrote:
>> store-and-forward system and therefore there are no queues of the  
>> nature you are talking about.  I hope that anybody writing LoST  
>> code would know not to wait 30 days on a TCP timeout, as well.
>
> Actually, this seemed to me to be one of the more sticky points:  
> LoST is not store-and-forward, but it operates (by default) over  
> HTTP, and there are untold numbers of HTTP proxies in this world.

I agree.  The use of HTTP is a compromise (in the people working  
together sense, not as a security risk sense).  If we are willing to  
admit that HTTP proxies will cause harm to relative TTLs, then we  
ought to admit that HTTP is not right for this problem as they will  
be getting in the middle in the other ways that HTTP proxies do.   
Ultimately, we should probably recommend in the LoST draft that  
operators SHOULD NOT use ports 80 and 443.

>> Second, the issue of DSIG has come up many times on this list and  
>> I don't think we are any closer to getting consensus.  In short,  
>> in an emergency they will be ignored if they are invalid, so what  
>> is the point.
>
> Just like DSIG arguments, the "emergency excuse" keeps coming up on  
> the list.  Even if signatures might not be used as a go/no-go  
> criterion in emergency circumstances, they can provide a measure of  
> confidence, and they can still be useful in other contexts.  (I'm  
> not saying they're a necessity here, just that they shouldn't  
> categorically be ruled out.)

That's an interesting point (and we should probably change the  
subject as DSIG is really a separate topic).  But what does  
confidence in this case mean?  Do we really want to display things  
like "You dialed 911 but maybe talking to police imposters" to end  
users?  What is automata to do with this confidence, query one more  
time?  I doubt the answer will be any different the second time.  I  
continue to believe that the expense in operating the infrastructure  
to enable DSIG is worth it when in the end, invalid signatures will  
be ignored.

>> response to be deemed invalid with just one minute of drift at  
>> either end, and one minute drift is not that uncommon.
>
> This argues against absolute times because of clock sync, not  
> because of signatures.  (Maybe that's what you meant, but I was  
> confused by your placing it next to your comments on signatures.)

Exactly.  :)

-andy

---

From: Andrew Newton <[email-masked]>
Date: Mon, 23 Oct 2006 21:38:29 -0400

> the hotel I'm staying at and the bogus LoST server it's advertising.

Going with this scenario, when I visit NYC what says that I have any  
more of a relationship with the cities LoST server than I do with the  
hotel's?

> I don't see the advantage of this complexity.

Actually, I agree with Richard on this point.  Not that I'm crazy  
about digital signatures, but the order of complexity is not that  
much greater once you've gone through all the trouble of doing  
digital signatures in the first place.

>> If a client is using LoST for emergency calling, then it seems  
>> like the TTL is likely to be ignored in the name of keeping around  
>> some URI to try if everything else falls through.  That being the  
>> case, it doesn't seem like the TTL requires a whole lot of  
>> precision, so relative times seem good enough (despite caching  
>> issues).
>
> off to somebody else and the LoST entry is changed for that  
> service. Unfortunately, the bad guy will continue to waive the  
> signed, but stale, version of the advertisement and can thus  
> convince clients that the bad service is still good. In other  
> words, a classical replay attack. Designing a system that  
> facilitates such attacks seems like a bad idea.

Wouldn't the server auth at the TLS layer prevent this?

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 23 Oct 2006 21:50:33 -0400

>
> Going with this scenario, when I visit NYC what says that I have  
> any more of a relationship with the cities LoST server than I do  
> with the hotel's?
>

If we go with Brian's model, the PSAP or government agency will have  
an easily-recognized certificate, which isn't true for Alice's B&B.

> Wouldn't the server auth at the TLS layer prevent this?

No, since the old domain name is still valid, just owned by Mr. Evil  
Twin now (say).

---

From: Andrew Newton <[email-masked]>
Date: Mon, 23 Oct 2006 22:02:06 -0400

On Oct 23, 2006, at 9:50 PM, Henning Schulzrinne wrote:
> If we go with Brian's model, the PSAP or government agency will  
> have an easily-recognized certificate, which isn't true for Alice's  
> B&B.

Given that Alice's B&B is more likely to get their cert from a  
commercial CA and the government agency is more likely to get their  
cert from a government CA nobody has ever heard of, I think the  
opposite is actually true.

> No, since the old domain name is still valid, just owned by Mr.  
> Evil Twin now (say).

And just where did Mr. Evil Twin get his hands on the private key of  
that government agency?  You are not describing an evil twin attack,  
you are describing a key compromise.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 23 Oct 2006 22:07:17 -0400

> code would know not to wait 30 days on a TCP timeout, as well.

Since we have decided on HTTP, I'd rather have a solution that is  
robust even if things go boing. Just saying "since we chose  
something, bad things can't happen" isn't terribly helpful.

> don't think we are any closer to getting consensus.  In short, in  
> an emergency they will be ignored if they are invalid, so what is  
> the point.  To add to that, absolute times could easily cause a  
> signed response to be deemed invalid with just one minute of drift  
> at either end, and one minute drift is not that uncommon.

We have to remember that LoST can and hopefully will be used for many  
applications beyond the original emergency scope. Ruling out a  
reasonable security mechanism to save 10 lines of code seems like a  
rather peculiar way of designing systems.

>
> Third, to negate re-assembly, we'd also have to take boundary  
> references and address validation checks out of the protocol.

I don't see the connection for boundary references (or values), as  
they are independent of the query. It doesn't matter where you are  
within the polygon - the boundary is still the same.

I agree that validation (beyond <valid>, which is used for matching  
and thus is query-independent) is query-dependent. This naturally  
doesn't affect geospatial queries.

>
> Finally, the specification of the absolute time is much more  
> complex than relative time.  Since LoST uses Relax NG, the data  
> type would be the XML Schema dateTime, which is a subset of ISO  
> 8601.  That's already a source of interoperability problems.  Add  
> on top of that rules for disallowing timezone (which only cause  
> greater confusion),

Given the widespread use in other IETF schema, including systems such  
as EPP that have been standardized recently, I consider that a red  
herring. I don't recall seeing a last-call comment on the IETF list  
protesting the inclusion of 8601 in that context, including by yourself.

> and you have two ways programmers could do the wrong thing very  
> easily.  From a code standpoint, this is more complex than relative  
> ttl in seconds. Here is the Java code doing relative time:

[3 lines vs. 15 lines with comments elided]

Thanks for publishing the code, which then means nobody else has to  
write it...

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 23 Oct 2006 22:09:56 -0400

On Oct 23, 2006, at 10:02 PM, Andrew Newton wrote:

>> have an easily-recognized certificate, which isn't true for  
>> Alice's B&B.
>

The problem is not the CA, it's knowing whether the name for  
bobcoffeeshop (which is run by Alice's husband) has anything to do  
with the B&B.

> And just where did Mr. Evil Twin get his hands on the private key  
> of that government agency?  You are not describing an evil twin  
> attack, you are describing a key compromise.

Again, I'm talking about LoST use in general, not just government  
agencies. Domain names routinely fall into the "wrong" hands after  
expiration.

---

From: Andrew Newton <[email-masked]>
Date: Tue, 24 Oct 2006 08:45:57 -0400

> bobcoffeeshop (which is run by Alice's husband) has anything to do  

So we are displaying an X.509 distinguished names to end users now?

> agencies. Domain names routinely fall into the "wrong" hands after  

But private keys do not.  Also, what is going on here?  LoST clients  
are pointing at random domains?  I thought there was discovery and U- 
NAPTR and fancy stuff in the middle there, something a domain  
squatter would very unlikely even have knowledge of.  BTW, domain  
squatting is also not an evil twin attack.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 24 Oct 2006 09:15:41 -0400

> So we are displaying an X.509 distinguished names to end users now?

Web browsers do it today...

In reality, if signing happens, I suspect we'll see some version of  
trait-based certificates ("I'm authorized to sign PSAP boundaries"),  
such as those advocated by Brian. This is somewhat easier than  
signing locations, say, since all the entities within a country in  
the end report to a single hierarchy. I'm no expert in federal PKI,  
but efforts like http://www.entrust.com/e_government/ 
federal_bridge.htm seem related. Thus, recognizing the CA itself  
would probably be sufficient as first approximation, even without  
trait-based PKI.

> But private keys do not.  Also, what is going on here?  LoST  
> clients are pointing at random domains?  I thought there was  
> discovery and U-NAPTR and fancy stuff in the middle there,  
> something a domain squatter would very unlikely even have knowledge  
> of.  BTW, domain squatting is also not an evil twin attack.

Very simple: You get connected (via U-NAPTR or DHCP) to a shady or  
compromised LoST resolver at the friendly B&B you're staying at. It  
presents you the nicely signed (but long expired) record of some  
service provider, be it for emergencies or taxi services. The domain  
or IP address in the URL has been acquired by Mr. Evil (or just a  
competitor of the original owner). This has nothing to do with typo- 
squatting. IP address squatting is, relatively speaking, even easier:  
if the original owner outgrows or abandons their hosting provider,  
just rent that same space.

I'd rather design a system that allows us to reliably ensure  
information integrity from the authoritative source compared to  
having to backfit it, as for DNS, later, when it becomes much more  
difficult.

I'm having a hard time seeing that 12 lines more code that are  
already written by somebody else should be an argument for not  
allowing authoritatively-signed, replay-preventing records that can  
be cached as a whole. This seems like a pretty low investment for  
future-proofing.

I will note in passing that any system that implements PIDF-LO will  
already have a 8601 parser, since the <timestamp> and <retention- 
expiry> elements use that format.

I also find it peculiar that suddenly this is an issue: 4119 only  
uses absolute, 8601 timestamps. I don't recall that causing heartache  
or even discussion before. Would you like to revise that particular  
choice now, too?

---

From: Andrew Newton <[email-masked]>
Date: Tue, 24 Oct 2006 09:25:36 -0400

> something, bad things can't happen" isn't terribly helpful.

I didn't bring up HTTP.  But if you want to talk about the bad things  
that can happen because of HTTP proxies, it would seem a stale TTL,  
relative or absolute, is one of the least harmful things that can  
happen.  Far more harmful is an HTTP proxy returning a stale redirect  
or a stale serviceNotImplemented or stale service boundaries or stale  
PSAP URIs.  If you believe that HTTP proxies will cause harm to TTLs,  
then you can not honestly make that argument and suggest that the  
other really bad things won't happen either.  I'm all for opening up  
the debate on the re-use of HTTP since you are now willing to discuss  
it.

> We have to remember that LoST can and hopefully will be used for  
> many applications beyond the original emergency scope. Ruling out a  

I'd like to see your 10 line implementation of XML D-SIG.

> doesn't affect geospatial queries.

I think you missed the point.  If an authoritative server signs a  
response, and a caching server removes part of that response because  
the client asks it to do so (re the 'include' attribute), the digital  
signature will not validate.  So either address validation is always  
on, or it is to be removed from the protocol.  And we must also  
remove service boundary references.

Of course, Richard's suggestion of just signing the URI gets around  
that problem.  But you disliked his proposal.

Either way, the signed data must include something from the query  
(like a transaction ID or perhaps the query itself).  Otherwise, an  
attacker can simply take a valid answer from another query and play  
it back.

> Given the widespread use in other IETF schema, including systems  
> such as EPP that have been standardized recently, I consider that a  
> red herring. I don't recall seeing a last-call comment on the IETF  
> list protesting the inclusion of 8601 in that context, including by  
> yourself.

Actually, the issue of date and time datatypes did come up in last  
call just recently with EPP... you should have read the thread much  
more closely.  EPP itself is ready to go DS, but the reference to RFC  
3339 (ISO 8601), where the date and time datatype is specified, is  
not.  That was the central issue about the "down reference".

It should also be noted that EPP does not have the notion of caching  
intermediaries, so the issue of time synchronization is not as relevant.

But there are things we can learn from the EPP work, most notably  
that the PROVREG working group that created EPP explicitly did not  
use HTTP.  They considered it, but found that they were better off  
without it.

>> easily.  From a code standpoint, this is more complex than  
>> relative ttl in seconds. Here is the Java code doing relative time:
>

If implementers have to rely on code posted by me to get their job  
done, that is proof that this is unnecessarily complex.

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 24 Oct 2006 09:28:42 -0400

Just connecting a few dots:

I think normally location comes from a local access network LIS
I want the location signed by the LIS
I want the cert for the LIS signed by the emergency services authority CA
I think normally, the sos part of the LoST service is operated by the
emergency services authority
I want the route signed by the LoST server
I want the cert for the LoST server signed by the emergency services
authority CA

I want all of this happening before an emergency call.  If there is a
problem (like the CA of the location signature is not the CA of the LoST
server signature), I want the user to be given a simple message (if you
dialed the emergency dialstring, it's possible something will go wrong,
please have this checked out by your carrier).

We probably want a bit more sophistication to "the CA of the location
signature is not the CA of the LoST signature", but you get the idea.

Brian

> -----Original Message-----
> From: Andrew Newton [mailto:[email-masked]]
> Sent: Tuesday, October 24, 2006 8:46 AM
> To: Henning Schulzrinne
> Cc: ECRIT
> Subject: Re: [Ecrit] LoST open issue: ttl
> 
>

---

From: "Marc Linsner" <[email-masked]>
Date: Tue, 24 Oct 2006 13:47:19 -0400

Richard, 

> Just like DSIG arguments, the "emergency excuse" keeps coming 
> up on the list.  Even if signatures might not be used as a 
> go/no-go criterion in emergency circumstances, they can 
> provide a measure of confidence, and they can still be useful 
> in other contexts.  (I'm not saying they're a necessity here, 
> just that they shouldn't categorically be ruled out.)
> 

What about the level of confidence in a replay attack?  Would not confidence
be elevated falsely?  Isn't that the exact behavior attackers attempt to
achieve?

-Marc-

---

From: Ron Watro <[email-masked]>
Date: Tue, 24 Oct 2006 14:15:37 -0400

Marc,

Wouldn't timestamps and/or sequence numbers be pretty good at reducing the 
replay threat?

Ron